[Answer]

HTTP 1.1

• HTTP 1.1 특징

  • 서버-클라이언트 구조 : 클라이언트가 req 요청하면, 서버가 resp 처리
  • 비연결성 : 한 번의 연결에 하나의 req - resp를 처리
  • 추가기능 : keep-alive, pipelining으로 TCP handshake를 줄여 성능 개선 ⇒ 링크

• (단점)

  • RTT (Round Trip Time) : 비연결성이 디폴트이므로, TCP에서 동작하는 특성상 매 연결마다 handshake가 반복적으로 일어나, 불필요한 자원 소모와 RTT가 증가하니까 결국 네트워크 성능 떨어짐.

  • HOLB (Head of Line Blocking) - 특정 응답 지연 : 순차적으로 데이터를 요청하고 받아야 하므로, 먼저 들어온 request의 response가 처리되지 않으면, 나중에 들어온 request의 response가 처리되었어도 서버가 클라이언트에게 보내주지 못하고 기다리고 있어야됨.

    <aside> 💡 [HOLB 2종류]

    • HTTP의 HOLB : res에 대해 resp가 순서대로 오면 좋겠어. 따라서 이를 위해 지연 발생.

    • TCP의 HOLB : TCP는 패킷의 순서를 보장함. 순서대로 패킷이 들어와야되고, 순서대로 패킷이 처리(파싱)되어야 함. 따라서 이를 위해 지연 발생

    </aside>

HTTP 2.0

• HTTP 2.0 특징

  • Multiplexed Streams : pipelining처럼 하나의 연결에 req 연속해서 여러 번 가능. 그렇지만, resp 순서대로 도착안해도 됨. → HTTP 1.1의 Keep-Alive, Pipelining의 개선 → HTTP의 HOLB 해결! 그치만 TCP의 HOLB는 아직..

  • Server Push : 클라이언트가 req 안했어도 서버가 먼저 리소스를 보내줄 수 있음

    page.html include style.css, image.png라고 하자.

    1. client : page.html 줄래?
    2. server : page.html + style.css + image.png 줄게! (page.html읽으려면 다른 자원도 필요함. 넌 몰라서 요청 못했겠지만 style.css, image.png도 그냥 내가 알아서 push해줄게)
    • 서버 푸시 예시

  • Stream Optimization : 연계된 리소스 간 우선순위를 설정하여 브라우저의 렌더링을 매끄럽게 함.

• (단점)
  • 어쨌든 TCP를 사용하므로 handshake 과정으로 인한 RTT의 증가. latency 증가
  • HTTP의 HOLB는 해결했으나, TCP의 HOLB 해결 불가!

HTTP/1.0 HTTP/1.1 HTTP/2.0 비교~

• HTTP 1.0 : 연결 한 번에 (req-resp) 한 번
• HTTP 1.1+ keep-alive : 하나의 연결에 (req-resp) 여러 번
• HTTP 1.1 + pipelining : 하나의 연결에 req 연속해서 여러 번 가능. 단, res 순서대로 resp가 도착해야됨.
• HTTP 2.0 : pipelining처럼 하나의 연결에 req 연속해서 여러 번 가능. 그렇지만, resp 순서대로 도착안해도 됨.

HTTP 3.0

• HTTP3는 QUIC를 통해 TCP가 아닌 UDP를 사용함!
• QUIC (Quick UDP Internet Connection)
  • UDP를 기반으로 TCP+TLS+HTTP의 기능을 구현한 프로토콜
  • TCP의 handshake 과정을 최적화하기 위해 설계됨
  • TCP는 안쓰지만 신뢰성있는 연결은 하고 싶으니까, UDP를 커스터마이징 하기 위한 레이어라고 생각하면 된다! (프로토콜인 UDP를 건들일 수는 없으니.. 외부에 감싸는 라이브러리를 추가하자는 느낌..)