HTTP
- HTTP는 HTML 문서와 같은 리소스를 가지고 올 수 있는 프로토콜
- 개별 메세지에 대해 클라이언트에서 서버에 request를 보내면 서버에서 response를 보내는 방식으로 구성
- HTTP는 애플리케이션 계층의 최상단에 위치
HTTP 0.9
- http 초기 버전에는 버전 번호가 없었음
- GET 메소드만 존재
- 헤더 X, 상태나 오류 코드 X
- HTML 파일만 전송 가능
HTTP 1.0
- 1996년 11월에 공개
- GET 요청에 HTTP/1.0 버전 정보가 같이 전송
- GET, HEAD, POST 메소드 사용 가능
- 상태 코드 포함
- 헤더 개념 포함
- Content-Type을 이용, HTML 파일 외의 파일도 전송 가능
HTTP 1.1
- 1997년 초에 공개
- GET, HEAD, POST, OPTION, PUT, DELETE, TRACE 메소드 사용 가능
- 커넥션 재사용 가능(Persistent Connection) → 시간 절약
- 한 커넥션에서 send → receive를 한 번 하고 끊는 것이 아니라, 여러 번의 송수신이 가능하다.
- 파이프라이닝 추가 → 첫 요청에 대한 응답이 완전히 전송되기 전에 두 번째 전송이 가능
- Persistent Connection보다 더 빠르게 처리 가능
- HOL Blocking 문제 발생
- 청크, 캐시 제어, 언어, 인코딩 등의 기능 추가
HTTP 1.1 문제점
- Head of Line Blocking: 가장 앞선 요청이 지연되면 그 다음 요청도 지연되는 것
- → 서버는 TCP에서 요청을 받은 순서대로 응답을 해야 한다.
- Round Trip Time 증가
- Header가 너무 무거움: 수많은 http 요청 존재, 그 요청들의 헤더가 거의 동일
HTTP 2.0
- 2015년 2월 표준으로 승인
- 성능 쪽에 초점을 맞춘 프로토콜
- Binary Framing: 요청 응답 메세지를 binary로 전송
- Multiplexed Stream: HTTP Pipeline의 개선으로 메세지를 Stream으로 송수신
- Stream Prioritization: 응답에 대한 우선순위
- Server Push: 서버가 클라이언트 요청 없이 응답을 보내는 방법
- Header Compression: Header Table과 Huffman Encoding 을 이용한 HPACK 알고리즘 사용
- Header Table: 클라이언트와 서버가 각각 관리하는 테이블로, 동일한 값은 인덱스만 전송, 다른 값은 허프만 인코딩해서 전송
HTTP 3.0
- 여전히 TCP 레이어의 handshake에서 지연 시간 발생 → UDP 기반의 QUIC을 사용
- QUIC: TCP + TLS + HTTP의 기능을 구현한 프로토콜
- 무결성 보장 + 신뢰성
QUIC
- UDP
- TCP와 달리 전송 순서를 보장 X
- 핸드셰이크 등의 과정이 없기 때문에
신뢰성 X- 신뢰성이 없는 것이 아닌, 빈 도화지 상태!
- 얼마든지 커스터마이징을 통해 기능 구현 가능!
- RTT
- TCP 연결을 위해 1 RTT 필요
- TLS까지 붙이면 3 RTT 필요
- QUIC은 TLS 인증서를 내포하고 있기 때문에 최초 연결에 인증서와 데이터를 함께 전송 → 1 RTT만에 가능
- HOL Blocking
- HTTP 2.0
- HTTP 레이어의 HOLB는 해결
- TCP 레이어의 HOLB는 여전히 존재
- 패킷 손실의 경우 없어진 패킷을 찾아 다시 전송하는 동안 TCP 연결 자체가 막힌다.
- 패킷 손실률이 증가하면 오히려 수십 개의 connection을 이용하는 HTTP 1.1보다 속도가 안나올 수 있다.
- QUIC은 독립 스트림을 이용, 각 스트림에서 HOLB가 발생해도 다른 스트림에 영향 X
- HTTP 2.0
- Connection ID
- 각 연결마다 식별자
- 네트워크가 변경되더라도 연결 유지