HTTP 버전별 비교 - (3) HTTP/3, QUIC

HTTP/3

---

• 아직 표준안이 확정된 것은 아니지만, 기반 기술인 QUIC의 표준인 RFC9000은 2021년에 확정된 상태
• 탄생년도: 진행 중
• L4 전송계층에서의 변화

QUIC

• 2013년에 공개
• UDP기반의 전송 프로토콜
• 탄생 배경:
  • 페이지 로드 타임을 HTTP/2보다 개선하기 위해

QUIC은 왜 UDP를 선택했을까?

TCP의 한계: 느림

느린 이유

• 연결을 위한 3 & 4 Way Handshake
• TCP레벨의 HOLB 문제

UDP의 장점

• Handshake을 사용하지 않아서 빠름
• 강력한 확장성 => 커스터마이징이 용이함
  • TCP는 신뢰성을 확보하기 위해 필수 헤더가 많고 그로 인해 옵션으로 사용할 수 있는 헤더의 크기가 작음
    

QUIC의 특징

1) 커넥션 설정 시간 감소

• 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송하며 1RTT만 소요
  • TCP(1RTT) + TLS(2RTT) 사용시 3RTT 소요
    • RTT(Round Trip Time): 패킷을 전송하는 시점부터 해당 패킷에 대한 ACK를 받는데까지 걸리는 시간00
• 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 성립 가능하여 이 경우 0RTT
  • TCP Fast Open + TLS 1.3 사용시 QUIC과 비슷한 연결 설정 속도를 낼 수 있지만, 처음 데이터를 전송할때 TCP SYN 패킷 당 약 1460 byte의 제한이 있는 반면 UDP는 전체 데이터를 보낼 수 있어서 데이터가 큰 경우에 여전히 UDP가 유리
    • TCP Fast Open: 쿠키를 이용하여 더 빠르게 TCP 연결하는 기술
    • TLS 1.3: 2RTT가 소요되던 1.2버전에 비해 1RTT로 감소

2) Multiplexing without head of line blocking

• 독립 스트림을 통한 향상된 멀티플렉싱 기능 지원 => TCP HOLB 문제 해결
  • TCP의 가상회선 방식 => 스트림이 하나의 커넥션 상에서 존재
    
  • UDP의 데이터그램 방식 => 스트림이 각기 독립되어 있음 => TCP HOLB 문제 해결
    

3) 패킷 손실 감지에 걸리는 시간 단축(Improved congestion control feedback)

• QUIC은 다양한 기술을 통해 패킷 손실 감지에 걸리는 시간을 단축
  • 자세한 것은 RFC9002의 4. Relevant Differences between QUIC and TCP를 참고
• 그 기술 중 대표적인 것이 헤더에 별도로 단순 증가하는 패킷 번호 공간을 부여한 것
  • 매 전송마다 패킷 번호가 증가하므로 재전송시에도 패킷의 전송 순서를 파악가능하여 재전송 모호성(Retransmission Ambiguity)의 문제를 해결
• TCP는 Stop and Wait ARQ(Automatic Repeat Request)방식을 사용, 재전송 모호성의 문제 존재
  • 패킷을 보낸 후 제한 시간 안에 ACK를 받지 못한 경우 패킷을 재전송 하는 방식
  • 동적으로 제한 시간을 정하는 데, 타임 아웃 발생시 재전송 모호성 문제 존재
    • 지난 RTT샘플 시간을 토대로 제한 시간을 동적으로 설정
    • 예시) 패킷 전송 -> 타임 아웃 -> 패킷 재전송 -> ACK 수신
      이러한 경우, TCP는 재전송할 때 시퀀스 번호가 동일하므로 언제 보낸 패킷에 대한 ACK인지 식별하기 어렵기에 RTT를 결정하기 어려움

4) Connection migration

• TCP는 서버와 클라이언트의 IP 주소와 PORT 번호로 커넥션을 식별 => 클라이언트의 IP 주소 변경 시 다시 handshake...
  • 모바일에서 Wi-fi 및 셀룰러 전환시 IP 전환 되는 일은 빈번
• 반면 QUIC은 랜덤하게 결정되는 Connection ID이란 값으로 커넥션을 식별 => IP주소 변화에도 커넥션 유지

5) 보안 관련

• TLS 1.3 기본 적용하며 커넥션 설정에서 동시에 TLS Handshake
  
• 기존에 암호화되지 않았던 영역까지 암호화에 포함하여 보안성 강화
  

HTTP/3의 장단점

장점

• 빠른 속도
  • 신뢰성 점검 관련 오버 헤드를 피할 수 있음
  • 빠른 응답이 필요한 경우 효과적

단점

• DDoS 공격이 용이
  • 커넥션 설정 단계서부터 많은 데이터가 패킷에 담아서 주고 받을 수 있음
  • 이를 이용하면, 요청 패킷의 크기는 적더라도 응답 패킷의 크기는 커질 수 있음
    => 적은 양의 요청으로 DDoS 공격이 용이해짐
  • 이를 방지 하고자 초기 응답 패킷의 크기가 1200Byte를 넘지 않아야한다는 조건 & 응답 데이터 크기가 요청 데이터의 3배를 넘기지 않아야한다는 조건 추가
• 커널에서의 최적화가 부족
  • 전송 계층(L4)은 OS에서 구현됨
  • 오래 사용된 TCP는 커널과의 최적화가 잘되어 있음
  • UDP는 잘 사용되지 않았기에 커널에서의 최적화가 부족
• 신뢰성의 문제
  • 패킷 손실, 순서 보장 결여, 오류 및 중복 문제 등

적합한 사용처

• 실시간 스트리밍과 같이 빠른 통신이 필요한 애플리케이션
• IoT, 빅데이터, VR, 마이크로 서비스 등에서 사용될 수 있음

결론

• HTTP는 이전의 단점들을 보완하며 발전해왔음
• 그러나 단순히 가장 최신의 기술만을 사용하는 것은 문제가 생길 수 있음
  • 가령 QUIC의 경우 최적화 및 표준화의 부재, DDoS 공격에 대한 위험 등을 고려해야함
• 어떠한 버전을 사용해야하는진 좀 더 다양한 측면에서 살펴볼 필요
  • 제공하고자 하는 서비스에서 가장 널리 사용되는 버전은 무엇인지
  • 버전별 특성 중 무엇이 장점과 단점으로 작용할지

기타 주제

OSI 7 layer

네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것

• 나눈 이유?
  • 통신이 일어나는 과정을 단계별로 파악하기 위해
  • 흐름을 한눈에 파악하기 용이
  • 이상이 생긴 단계만 타겟팅하여 보수 가능
• 4번째 계층(L4): 전송 계층(Transport layer)
  • 종단간 신뢰성 있는 데이터 전송을 담당(End-To-End Reliable Delivery)
    • 이를 위해 분할과 재조합, 연결제어, 흐름제어, 오류제어, 혼잡제어 수행
  • 종단(Host)의 구체적인 목적지(Process)까지 데이터가 도달할 수 있도록 합니다.(Process-To-Process Communication)
    • Procees를 특정하기 위한 주소로 Port Number를 이용
  • 이 계층에서 사용하는 규약이 TCP/UDP

TCP(Transmission Control Protocol) vs UDP(User Datagram Protocol)

	TCP	UDP
연결 방식	연결형 서비스	비연결형 서비스
패킷 교환 방식	가상 회선 방식	데이터그램 방식
수신 여부 확인	확인	확인 하지 않음
전송 순서	보장	바뀔 수 있음
신뢰성	높음	낮음
속도	느림	빠름

• 패킷 교환 방식
  • 가상 회선 방식
    발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정
    • 가상회선은 hop에 해당하는 라우터의 RAM에 위치한 라우팅 테이블을 통해 기억됨

      라우팅 테이블이란?
      최적 라우팅 정보(목적지, 방향, 거리)를 나타낸 표이며 라우터는 이곳에 담긴 정보를 바탕으로 패킷 전달
      윈도우 cmd창에서 route print 명령어로 확인 가능

  • 데이터그램 방식
    논리적 경로를 설정하지 않고, 패킷들이 각기 독립적으로 전송되는 방식