[1주차 TIL] KnockOn Bootcamp HTTP/HTTPS

프롤로그

P가 붙은 것은 Protocol의 약자로 오늘 공부할 HTTP도 맨 뒤에 P가 붙었으므로 프로토콜이다.

 

 

HTTP

HTTP(Hypertext Transfer Protocol) : 인터넷에서 웹 클라이언트와 웹 서버 간에 데이터를 주고 받기 위한 통신 프로토콜이다. 텍스트, 이미지, 동영상 같은 다양한 리소스를 웹 브라우저에 전송하여 사용자에게 표시할 수 있도록 한다.

이 프로토콜은 웹 클라이언트가 서버에게 요청(Request)하면, 서버가 응답(Response)을 해준다. 웹 서버는 HTTP 서버를 HTTP 서비스 포트인 80번에다가 대기 시킨다. (TCP/80, TCP/8080)

텍스트 기반으로 설계되어 이해하기 쉽고 구현이 간단하다. 확장성이 높고, 다양한 애플리케이션에서 사용이 가능하다. 다만 보안이 취약하고, 서버간의 요청상태를 기억하지 못해서 추가적인 상태 유지 메커니즘이 필요하다.

 

 

HTTP의 특징

HTTP의 주요 특징으로는 다음과 같다.

1. 비연결형(Connectionless)

클라이언트와 서버 간에 요청과 응답이 한 번 이루어 지면 연결이 끊어지고, 요청마다 새로 연결을 생성하기에 연결이 유지되지 않는다.

 

2. 무상태(Stateless)

서버는 클라이언트의 상태를 기억하지 않는다. 각각의 요청은 독립적으로 이루어지기에 이전 요청과는 관계가 없다.

 

3. 텍스트 기반 프로토콜 

요청과 응답 메시지는 사람이 읽을 수 있는 텍스트 형식으로 전송된다.

 

진짜 요청 보내고 응답 받기 이게 끝이다.

 

 

HTTPS

HTTP는 데이터를 평문(Plant Text)으로 전송하기에 보안적으로 취약하고, 네트워크에서 데이터가 쉽게 도청될 수 있다.

HTTPS(HTTP Secure)는 이를 보완하기 위해 SSL/TLS 암호화를 추가하여 보안을 강화한 프로토콜이다. 데이터 전송중에 암호화를 통해 기밀성과 무결성을 보장한다. URL이 Hhttps://로 시작하며, 브라우저에서 자물쇠 아이콘으로 표시된다.

즉 웹 브라우저와 서버간의 데이터 전송을 암호화하여 기밀성, 무결성, 인증을 보장하는 보안 통신 프로토콜로써 도청, 변조, 위조를 방지한다.

443번 포트를 사용하고, HTTP보다 암호화 하는 시간으로 인하여 느릴 수 밖에 없다. 그러나 보안성이 높아 사용자 신뢰 확보를 할 수 있고, 데이터 보호 법규를 준수한다. 그래도 속도 저하, 인증서 비용, 복잡한 설정은 무시할 순 없지만 우리 대부분은 거의 다 HTTPS를 쓰지않는가?

 

 

HTTPS의 특징

1. 데이터 암호화(Encryption)

클라이언트와 서버간의 데이터를 암호화하여 도청을 방지한다. SSL/TLS 프로토콜을 사용하여 데이터를 안전하게 보호한다.

 

2. 데이터 무결성

데이터가 전송 중 변조되지 않도록 보장하고, 중간에서 수정되어있는지 확인이 가능하다.

 

3. 인증(Authentication)

서버와 클라이언트 간의 신뢰할 수 있는 통신을 보장한다. 서버의 인증서를 통해 서버가 신뢰할 수 있는지 확인한다.

 

HTTPS와 관련된 건 조금 이따가 더 알아보자..

 

 

 

HTTP 메시지

HTTP메시지는 아까 말했듯이 클라이언트가 요청하는 HTTP요청, 서버가 반환하는 HTTP 응답이 있다. 크게 HTTP 헤드와 HTTP 바디로 구성되어있다.

헤드와 바디 사이에는 한 줄의 공백이 있고, 그 공백을 기준으로 공백 밑에줄에는 HTTP 바디, 위쪽은 헤드이다.

 

헤드 같은 경우에는 맨 윗줄은 시작줄, 나머지 부분은 헤더로 칭한다.

http://www.gajai.com/web/index.html?t=1718388103556

GAJA I

에 접속하고, F12로 개발자도구를 연 다음 NETWORK 탭에서 나온 헤더 부분을 캡쳐해온 것이다. Response Headers와 Request headers를 보면, 맨 위의 시작줄이 있고, 그 밑에줄이 싹다 헤더이다.

헤더를 보면 필드 : 값 이렇게 구성되어 있고, 각 헤더는 CRLF(맨 앞으로 이동, 다음 줄로 이동) 로 구분되어있다.

 

바디는 payload부분에서 확인할 수 있는데,

조금이따가 좀 더 자세히 알아보도록 하자.

 

 

HTTP 헤더

HTTP 헤더는 요청 또는 응답에 포함되는 메타데이터이다. 통신에 필요한 추가 정보를 전달하며, 메시지에서 맨 앞 부분에 위치한다.

Header-Name: Header-Value

로 구성이 되어있다. (헤더이름에는 대소문자 구분이 없음)

이렇게 되어있는데, 대충 이해가 될 것이다.

일반적으로 어떤 헤더들이 들어가냐?

 

(1) 일반 헤더

요청과 응답 모두에서 사용되는 헤더

Cache-Control	클라이언트와 서버 간 캐싱 동작 제어.
Connection	연결 상태를 제어 (예: Keep-Alive).
Date	메시지가 생성된 시간.
Via	프록시 서버를 통해 전달된 요청 또는 응답 정보.

 

(2) 요청 헤더(Request)

클라이언스가 서버에 요청시 포함하는 헤더

Host	요청 대상 서버의 호스트 이름.
User-Agent	클라이언트 소프트웨어 정보(브라우저, 앱 등).
Accept	클라이언트가 수락 가능한 콘텐츠 타입.
Authorization	인증 정보 전달 (예: Bearer 토큰).
Content-Type	요청 데이터의 MIME 타입(예: JSON, HTML).

 

(3) 응답 헤더(Response)

서버가 클라이언트에 응답시 포함하는 헤더

Content-Type	응답 데이터의 MIME 타입 (예: text/html).
Content-Length	응답 데이터의 길이 (바이트 단위).
Set-Cookie	클라이언트에 쿠키 설정.
Server	응답을 생성한 서버 정보.
WWW-Authenticate	클라이언트 인증 요청 (예: Basic, Bearer).

 

(4) 엔티티 헤더

요청 또는 응답 메시지의 바디에 포함된 데이터에 대한 정보를 제공

Content-Type	데이터의 MIME 타입.
Content-Length	데이터 길이(바이트).
Content-Encoding	데이터 인코딩 방식(예: gzip, deflate).
Content-Language	데이터의 언어 (예: en-US, ko-KR).

 

 

 

HTTP 바디

헤더 다음에 공백줄이 있고 그 다음 모든 줄을 의미한다.

와이어샤크로 내부를 뜯어봤을 때, 위쪽에 헤더부분이 있고 그 밑에 있는 부분들인데

주로 JSON형식으로 되어있다

{"키" : "값"} 이런형식이다.

POSTMAN으로 확인해보자

밑에 body부분에 저렇게 채워져있는 것을 확인할 수 있다. 저게 body이다.

저 body의 길이는 Content-length 에서 크기가 적혀있다.

Body가 굳이 없을 일도 있다. GET요청이나, Delete요청같은 경우에는 보통포함하지 않는다.

 

 

HTTP method

여기 보면 Request Method를 볼 거다. 지금은 GET요청인데

몇 개 있다.

• GET : 데이터 조회
• POST : 서버에 데이터 전송, 처리요청
• PUT : 기존 리소스 전체 수정
• PATCH : 기존 리스트 일부 수정
• DELETE : 삭제
• HEAD : 헤더만 반환
• OPTIONS : 서버에서 어떤 걸 지원하는가?
• TRACE : 네트워크 경로 확인
• CONNECT : 터널 연결 설정

GET	서버에서 리소스를 조회	데이터 조회 (예: 웹 페이지, 이미지)
POST	서버에 데이터를 전송하여 새로운 리소스를 생성하거나 처리 요청.	데이터 생성, 로그인 요청
PUT	서버의 기존 리소스를 완전히 수정하거나, 리소스를 새로 생성	전체 데이터 업데이트
PATCH	서버의 기존 리소스의 일부를 수정	부분 데이터 업데이트
DELETE	서버에서 특정 리소스를 삭제	데이터 삭제
HEAD	GET 요청과 동일하지만, 응답 바디 없이 헤더만 반환	리소스의 메타데이터 확인
OPTIONS	서버에서 지원하는 메서드와 옵션을 확인	서버 지원 메서드 조회
TRACE	클라이언트와 서버 간의 네트워크 경로를 확인	디버깅 용도
CONNECT	클라이언트와 서버 간의 터널 연결을 설정	SSL/TLS 연결 (HTTPS)

 

GET /users?id=123 HTTP/1.1
Host: example.com

이렇게 맨 앞에 GET인지 POST 인지 확인할 수가 있다.

PATCH는 난 거의 안 써보고 PUT만 썼던 것 같다.

 

 

 

Status Code(상태코드)

여기보면 Status Code에 200 OK적혀있는데, 저것도 다 의미가 있다.

요약부터 하자면

• 100번대 : 처리진행중
• 200번대 : 성공
• 300번대 : 되긴했는데, 리소스 이동이나 추가 작업이 필요하다
• 400번대 : 클라이언트 쪽 문제
• 500번대 : 서버쪽 문제

이렇게 되어서 웹개발할때 상태코드가 400번대가 떴다? 그럼 프론트엔드 문제니까 너네보고 고치라고 하고, 500번대가 떴으면 비상!이었다.

100	Continue	요청의 일부를 수신했으며 계속 진행할 준비가 되었음.
101	Switching Protocols	클라이언트가 요청한 프로토콜로 변경했음.
102	Processing	요청이 처리 중임을 나타냄(WebDAV).

 

200	OK	요청이 성공적으로 처리되었음.
201	Created	새로운 리소스가 성공적으로 생성되었음.
202	Accepted	요청이 수락되었지만 아직 처리되지 않았음.
204	No Content	요청이 성공했으나 응답 바디가 없음.
206	Partial Content	일부 리소스가 성공적으로 반환되었음(파일 다운로드 등).

 

301	Moved Permanently	리소스가 영구적으로 이동했으며, 새로운 URL을 사용해야 함.
302	Found	리소스가 임시적으로 다른 위치로 이동했음.
304	Not Modified	클라이언트 캐시에 저장된 버전을 사용할 수 있음.
307	Temporary Redirect	요청이 임시적으로 다른 URL로 리다이렉션됨.

 

400	Bad Request	잘못된 요청으로 인해 서버가 요청을 처리할 수 없음.
401	Unauthorized	인증이 필요하며, 유효한 인증 정보가 없음.
403	Forbidden	요청이 거부됨(권한 부족).
404	Not Found	요청한 리소스를 찾을 수 없음.
405	Method Not Allowed	지원되지 않는 HTTP 메서드를 사용.
429	Too Many Requests	클라이언트가 너무 많은 요청을 보냄(속도 제한).

 

500	Internal Server Error	서버에서 요청을 처리하는 중 알 수 없는 오류가 발생.
501	Not Implemented	요청을 처리할 기능이 서버에 구현되어 있지 않음.
502	Bad Gateway	게이트웨이 또는 프록시 서버에서 잘못된 응답을 받음.
503	Service Unavailable	서버가 과부하 상태이거나 유지 보수 중임.
504	Gateway Timeout	게이트웨이 또는 프록시 서버에서 응답 시간이 초과됨.

 

이중에서 가장 많이 봤던 게 

• 200OK (성공)
• 400 잘못된 요청
• 403 : 요청거부 (CSRF토큰등이 없음)
• 404 : 이 주소가 맞음?
• 405 : POST요청만 허용됐는데, GET을 보냈네?
• 502 : nginx 등에서 설정오류

 

이정도인 것 같다.

 

 

 

SSL인증서

SSL 인증서(Secure Sockets Layer Certicate)은 웹 서버와 클라이언트 간의 통신을 암호화 하여 데이터를 보호하고, 서버의 신뢰성을 보증하는 디지털 인증서이다. HTTPS에서 사용한다.

SSL이 뭐냐? 서버간 통신을 암호화 하는 프로토콜이다. 원래라면 TLS(Transport Layer Security)로 대체되었는데, 그냥 관습적으로 SSL이라고 부른다. 

 

데이터 암호화하고, 서버 신뢰성을 보증하고, 데이터 무결성을 인증한다.

 

이게 어떻게 인증이 되는건가?

서버 소유자가 CA(Certificate Authority 인증기관)에 SSL 인증서를 신청하고, CA는 도메인 소유권과 조직 신뢰성을 검증한 후에 인증서를 발급해주고, 서버에 해당 인증서를 설치하여 HTTPS 연결을 활성화 해준다.

 

그래서 통신되는 과정은 클라이언트가 HTTPs요청을 하면, 서버가 클라이언트에 인증서를 제공하고, 클라이언트는 해당 인증서가 신뢰할 수 있는 CA에 의해 발급되었는지 확인하고, 인증서에 포함된 공개키로 서버를 인증한다.

클라이언트와 서버가 암호화된 세션 키를 교환하여 안전한 통신 채널을 설정하고, 그 이후 데이터는 세션 키로 암호화 되어 전송한다.  

DV (Domain Validation)	도메인 소유권만 검증. 조직 정보 없음.	개인 웹사이트, 소규모 블로그
OV (Organization Validation)	도메인 소유권과 함께 조직 정보 검증. 사용자에게 신뢰를 제공.	중소기업, 비즈니스 웹사이트
EV (Extended Validation)	엄격한 검증 절차를 통해 발급. 브라우저에 회사 이름 표시.	대형 기업, 금융 웹사이트
Wildcard	하나의 인증서로 여러 서브도메인을 보호.	*.example.com (예: mail.example.com, blog.example.com)
SAN (Subject Alternative Name)	하나의 인증서로 여러 도메인 보호.	example.com, example.org

 

 

 

에필로그

생각보다 길어졌다.