인터넷에서 데이터를 어떻게 주고받을지 정해놓은 프로토콜 클라이언트의 요청(request)와 응답(response)로 구성됨 80 포트 사용
HTTPS
TLS(Transport Layer Security)
기존 HTTP 프로토콜은 메시지가 암호화 되어있지 않음 메시지를 암호화해서 데이터를 주고받는 프로토콜
TLS 연결과정 - 클라이언트가 서버에게 메시지 전송 - 서버는 자신이 가진 TLS 제3자 인증서를(공개키) 클라이언트에게 전송 - 클라이언트는 CA(Certified Authority)를 통해 인증서 유효성을 검증 - 클라이언트는 자신의 대칭키를 서버의 공개키로 암호화하여 서버에 전송 - 서버와 클라이언트는 대칭키를 공유하게 됨 - 통신 시 메시지를 대칭키로 암호화하여 통신
443 포트 사용
HTTP 버전
HTTP / 0.9
HTTP의 초기 형태
특징 - 헤더가 없음 - GET 요청만 존재함 - 응답에 상태코드 없음 - HTML 문서만 전송 가능함
HTTP / 1.0
헤더 개념 도입 - 프로토콜 확장 가능하도록 개선됨 POST, HEAD 추가 응답에 상태 코드 도입 Content Type 도입 - HTML 이외의 문서 전송 가능
특징 및 단점 - 하나의 Connection에 요청과 응답을 하나만 처리할 수 있음
HTTP / 1.1
Persistent Connection - 하나의 Connection에서 여러 개의 요청과 응답을 주고받을 수 있음 - 지정한 시간동안 Connection을 열어놓음 Pipelining - 앞 요청의 응답을 기다리지 않고 여러 요청을 보낼 수 있음, 서버는 요청 순서에 맞게 응답을 보냄 - 요청-응답 쌍이 종료된 후에야 다음 요청을 보낼 수 있는 기존 방식을 개선함
특징 및 단점 Head of Line Blocking(HOLB) - 앞 요청의 응답이 오래 걸리면 뒤 요청은 앞 요청의 처리를 기다려야 하는 Blocking 현상 Header의 중복 - 연속된 요청에서 헤더의 중복된 데이터를 보냄
HTTP / 2.0
Binary 메시지 전송 방식 - Binary Framing 계층을 추가하여, 보내는 메시지를 프레임(frame) 단위로 분할해서 binary로 인코딩 함 - binary 형식 사용을 통해 파싱 및 전송 속도가 빠르고 오류 발생률이 낮아짐 Multiplexed Stream - 하나의 커넥션 안에서 여러 개의 스트림(Stream)을 가질 수 있는 멀티플렉싱(Multiplexing)이 가능해짐 - Stream 방식은 고유 id로 식별하기에 순서에 상관없이 응답을 보낼 수 있음 - 이로 인해 HTTP 1.1의 HOLB 문제를 어느정도 해결함 Stream Prioritization - Stream에 우선순위를 설정하여 응답 순서를 정할 수 있음 Server Push - 서버에서 클라이언트에게 요청하지 않은 리소스를 추가적으로 보내는 기능 - ex) html만 요청했는데, css, js 같이 전송함 Header Compression - 요청과 응답의 헤더 데이터를 허프만 인코딩 방식을 통해 압축하여 오버헤드를 감소함
용어 - Frame: HTTP/2 통신에서 가장 작은 정보의 단위, Header 혹은 Data - Message: 요청(request) 혹은 응답(response)의 단위, 다수의 Frame으로 이루어짐 - Stream: 클라이언트 - 서버 연결을 통해 주고받는 하나 혹은 여러 개의 Message - Frame < Message < Stream
참고 - HTTP2에서는 Stream 하나가 여러 개의 요청, 여러 개의 응답 정보를 포함하는 구조임
특징 및 단점 TCP 고유의 HOLB 문제 - Stream에서 여러 Frame들이 뒤섞여 이동하는데, 어느 하나의 Frame에서 문제가 생기면, 그 뒤의 Frame이 문제가 해결될 때까지 기다려야 한다. - HTTP/2는 HTTP Layer의 HOLB 문제는 해결했지만, TCP Layer의 HOLB 문제는 여전히 가지고 있다.
HTTP/2 TCP 연결 상태에서의 N개의 스트림
HTTP / 3.0
QUIC 프로토콜 (Quick UDP Internet Connections) - UDP 기반의 전송 프로토콜 - TCP가 구조적 문제로 성능 향상이 어렵다고 판단하여 UDP 기반 프로토콜을 제작
Handshake 및 TLS - 첫 연결 설정에 메시지 데이터를 같이 보냄 - 첫 연결 설정에 1RTT 소요되고, 이후 곧바로 통신 가능 - 모든 데이터가 TLS 기반 암호화 통신 Connection UID - 각 연결이 고유한 ID를 가짐 - 클라이언트의 IP가 변경되어도 연결을 재수립하지 않아도 됨 독립 Stream - 각 Stream 당 독립된 Stream Chain을 구성하여 TCP HOLB 문제를 해결함 - Stream이 독립되어 있으므로 다른 Stream을 기다리지 않음
