how HTTP works?

CloudFlare, AWS CloudFront는 기존 TCP, TLS 및 HTTP/2의 기능을 결합하고 개선된 사용자 데이터그램 프로토콜 기반의 스트림 멀티플렉싱 보안전송 프로토콜인 QUIC을 사용하여 HTTP/3를 지원하며 현재 HTTP/1.1, HTTP/2, HTTP/3을 통해 통신하고 있습니다.

 

HTTP/0.9: 문서화된 최초의 HTTP 버전

• 요청 메서드가 GET 하나
• 응답은 HTML 파일
• 헤더와 상태코드 없음

 

HTTP/1.0: 기존 HTTP의 기능을 확장한 버전

• 버전 정보가 명시되었고 각 요청﹒응답 사이에서 전송되었습니다.
• 요청 메서드가 GET, HEAD, POST 세 가지로 확장되었습니다.
• 상태 코드가 추가되어 클라이언트 측에서 요청 결과에 따라 동작할 수 있게 되었습니다.
• 요청과 응답에 대한 부가적인 메타데이터를 담는 헤더 필드가 추가되었습니다.
• HTTP 헤더(Content-Type)의 도움으로 HTML 이외의 파일도 전송할 수 있게 되었습니다.

 

HTTP/1.1: 표준화된 HTTP

• 다수의 HTTP 요청이 발생하며 매번 TCP 핸드 셰이크 과정, 송/수신 간 속도 문제를 해결하기 위한 흐름제어, 한 라우터에 많은 트래픽이 몰리는 혼잡제어 알고리즘을 위한 Keep-Alive가 추가되었습니다.
• HTML을 분할해서 전송하는 Chunk Transfer Encoding, 요청과 응답에 대한 메타 정보를 담은 Cache-Control, 동일 IP에 여러 도메인 호스트를 지정하는 Host 등의 헤더가 추가되며 여러 요청을 연달아 보낼 때 각 응답을 기다리고 다시 요청하지 않고 클라이언트에서 Request를 우선 보내고 서버에서 순차적으로 처리하는 HTTP Pipelining이 추가 됐습니다.
• 텍스트로만 통신하는 HTTP 통신의 신뢰성과 무결성을 추가하기 위해 대화 상대가 서로 신뢰할 수 있는 인증서를 사용하고 통신 내용은 SSL 또는 TLS라는 프로토콜로 암호화하는 HTTPS가 등장하였습니다.
  • HTTPS hand-shake 과정은 다음과 같다. [참조 - https://howhttps.works/] 
    • 브라우저는 SSL/TLS 버전 및 알고리즘 암호화 목록을 서버에 보낸다.
    • 서버는 브라우저가 보낸 목록 중 가장 좋은 SSL/TLS 버전과 알고리즘을 선택하여 내 공개키가 포함된 인증서로 내가 누군지 확인을 한다.
    • 브라우저는 다시 인증서가 합법인지 확인하고 pre-master key를 공개키로 암호화해서 서버에 보낸다.
    • 이제 서버는 개인키를 이용해 pre-master key 암호를 해독한다.
    • 비대칭 키를 사용해서 암호화할 수 있게된 브라우저와 서버는 테스트 메시지를 주고 받으며 남은 세션 기간동안 보호받을 수 있다.
• HTTP 메서드를 활용하여 CRUD를 구현하고 URI를 통해 자원을 명시하는 HTTP 통신의 특성을 활용한 REST 아키텍처가 각광받으며 비동기로 서버에 요청을 보낼 수 있는 AJAX가 보편화 됩니다.
• 요청받은 순서대로 서버에서 응답하는 HTTP/1.1에서 응답 작성 중간에 문제가 생기면 지연되는 문제가 발생해 물리적인 TCP 연결을 여러 개 병렬로 연결한 임시 해결책도 등장합니다.

 

 

HTTP/2 (HTTP over SPDY)

• 기존의 HTTP/1.1에서 알려진 성능 제한 사항을 해결하여 웹 페이지 로드 대기시간을 줄이는 것을 목표로 구글에서 만든 SPDY 프로토콜 기반으로 작동합니다.
• 기존 텍스트를 ASCII 로 작성하던 방식에서 데이터 크기를 줄이기 위해 헤더와 바디가 Binary로 인코딩 됩니다.
• 하나의 TCP 연결에서 여러개의 요청과 응답이 양방향으로 오가는 stream, 하나의 요청과 응답의 단위인 message, message를 잘개 쪼개서 frame을 만들어 전송하고 수신측에서 조립하는 단위로 세분화 하며 기존에 한 번에 하나의 요청만 처리하고 요청별 순서를 지켜야 했던 것과 달리 응답 다중화(multiplexing)을 지원합니다.
• 헤더의 달라진 부분만 다시 전송하는 헤더 필드 압축을 지원합니다.
• 요청하지 않은 리소스를 미리 클라이언트에게 보내는 서버 푸시, 스트림 별 우선순위 지정, 흐름제어도 지원합니다.

 

HTTP/3 (HTTP over QUIC)

• 신뢰성을 지향하는 TCP의 데이터 손실시 재전송으로 인한 병목 현상, 네트워크 상황이 좋음에도 전송 속도가 낮은 상태에서 높은 상태로 천천히 높이는 혼잡 제어로 인한 문제들로 패킷 재전송, 혼잡 제어, 흐름 제어를 직접 구현한 UDP를 사용한 QUIC 프로토콜을 이용합니다.
  • QUIC은 동일한 연결을 공유(캐싱)하여 새 스트림을 생성하기 때문에 추가 핸드 셰이크 및 혼잡 제어가 필요하지 않고 독립적으로 전달되므로 하나의 스트림에 영향을 미치는 패킷 손실이 다른 스트림에 영향을 주지 않습니다.
  • 일반적인 TCP 3 hand shake를 TLS 1.3과 결합하여 기본적으로 암호화 및 인증이 제공되어 세션의 초기 요청에도 더 빠릅니다.
  • IP 기반이 아닌 UUID를 이용해 연결을 식별하여 Wi-Fi와 셀룰러 데이터 변경과 같은 IP 주소/포트 변경에도 연결을 유지할 수 있습니다.

 

TLS 캐싱

 

 

 

https://wormwlrm.github.io/2022/09/02/Evolution-of-HTTP.html

웹 개발자라면 알고 있어야 할 HTTP의 진화 과정 - 재그지그의 개발 블로그

https://howhttps.works/

How HTTPS Works

https://aws.amazon.com/ko/blogs/korea/new-http-3-support-for-amazon-cloudfront/

Amazon CloudFront, HTTP/3 지원 시작 | Amazon Web Services

https://cloudflare-quic.com/

QUIC | Cloudflare

https://blog.cloudflare.com/http3-the-past-present-and-future/