[cs] HTTP II - HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0 etc.

1. HTTP/1.0
2. HTTP/1.1
3. HTTP/2.0
4. HTTP/3.0

---

1. HTTP/1.0

• HTML 문서만 날리는 HTTP/0.9와 다르게 다양한 파일(css, image 등)을 받을 수 있도록 설계됨
• 매번 새로운 연결로 성능 저하
  • 하나의 데이터를 받을 때 마다 서버 측에서 연결 끊음
  • 요청 컨텐츠마다 TCP 세션을 맺어야 함
• 서버 부하 비용 상승
  • RTT(Round Trip Time) 증가 : 패킷이 목적지에 도달하고 나서 다시 출발지로 돌아오기까지 걸리는 시간이며 패킷 왕복 시
• HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없음
• HTTP 1.0은 기본적으로 Connection 당 하나의 요청을 처리할 수 있음
  • 그렇기 때문에 동시 전송은 불가능하고 하나의 요청에 대한 응답이 온 후 다음 요청을 처리하게 되는데,
  • 수 많은 멀티미디어 리소스들이 있는 상황에서 이러한 특징은 Network Latency를 발생시킴
    
• HTTP/1.0에서 RTT 감소를 위해 이미지 스플리팅, 코드 압축, base64인코딩 등 시행

 

2. HTTP/1.1

1) HTTP/1.0 vs. HTTP/1.1

• 요청마다 매번 TCP 연결을 하는 것이 아니라 한 번 TCP 초기화를 한 이후에 keep-alive 옵션으로 여러 개의 파일을 송수신할 수 있게 됨
• HTTP/1.0에서도 keep-alive 옵션이 있었지만 표준화가 되어 있지 않았고 HTTP/1.1부터 표준화되서 기본 옵션으로 설정됨
  
  

2) HTTP/1.1 특징

• Persistent Connection
  • 지정한 timeout 동안 커넥션을 닫지 않는 방식
  • Persistent 기능을 이용하여 한 개의 TCP 세션을 통해 여러 개의 컨텐츠 요청이 가능
  • 요청 컨텐츠마다 TCP 세션을 맺어야하는 HTTP 1.0에 반해 HTTP 1.1은 TCP 세션 처리 부하를 줄일 수 있고, 그만큼 클라이언트 응답속도가 개선됨.
• Pipelining
  • 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식 (TCP 안에 두 개 이상의 HTTP 요청을 담음)
    

위 그림과 같이  HTTP 1.1은 동시에 요청을 보내고 이에 대한 각각의 응답을 받아 처리(→ 응답 속도를 높이고 페이지 뷰의 속도를 빠르게 함)

 

• Host Header
  • HTTP 1.0 환경에서는 하나의 IP에 여러 개의 도메인을 운영할 수 없음에 반해, HTTP 1.1에서 Host 헤더의 추가를 통해 버츄얼 호스팅이 가능

 

• Imporved Authentication Procdure(강력한 인증 절차)
  • HTTP 1.1 에서는 2개의 헤더(proxy-authentication, proxy-authorization)가 추가됨
  • 실제 서버에서 클라이언트 인증을 요구하는 www-authentication 헤더는 HTTP 1.0에서부터 지원이 됐으나, 클라이언트와 서버 사이에 프록시가 위치하는 경우 프록시가 사용자의 인증을 요구할 수 있는 방법이 없었음
    
    

3) HTTP/1.1의 단점

• HTTP Pipelining
  • HTTP 1.0의 Network Latency를 개선하기 위해 파이프라이닝이 도입되었지만,
  • 이는 정확히 구현하기 힘들 뿐더러, HOL Blocking이 발생함
    
• HOL(Head of Line) Blocking
  • 어떤 요청에 병목이 생겨서 전체 latency가 증가하는 것
  • CP를 사용하는 통신에서 패킷은 무조건 정확한 순서대로 처리되어야 함. 수신 측은 송신 측과 주고 받은 시퀀스 번호를 참고하여 패킷을 재조립해야 하기 때문임.
  • 따라서, 중간에 패킷이 손실될 경우 완전한 데이터로 재조립하기 어렵기 때문에 송신 측은 해당 패킷이 제대로 전달되지 않았을 경우 재전송해야 함
  • 서버는 TCP에서 요청을 받은 순서대로 응답을 해야하므로, 앞선 요청에 의해 뒤의 요청이 지연됨
    
• 무거운 Header
  • Client-Server 간 수 많은 http 요청이 발생할 것이고, header의 정보는 대부분 동일
  • 하지만 HTTP 1.1에서는 헤더를 중복해서 보낼 뿐만 아니라 cookie 정보 역시 매 요청마다 헤더에 포함되어 전송됨
  • 즉, 불필요한 데이터를 주고 받는데 네트워크 자원이 소비되는 문제가 발생

 

3. HTTP/2.0

1) HTTP/1.1 vs. HTTP/2.0

• HTTP/1.1은 기본적으로 커넥션 당 하나의 요청과 응답만 처리함(즉, 여러 개의 요청을 한 번에 전송할 수 없고 응답 또한 마찬가지)
  
  • 따라서 HTML 문서 내에 포함된 여러 개의 리소스 요청, 즉 CSS 파일을 로드하는 link 태그, 이미지 파일을 로드하는 img 태그, 자바스크립트를 로드하는 script 태그 등에 의한 리소스 요청이 개별적으로 전송되고 응답 또한 개별적으로 전송됨
    
• 이처럼 HTTP/1.1은 리소스의 동시 전송이 불가능한 구조이므로 요청할 리소스의 개수에 비례하여 응답 시간도 증가하는 단점이 있음
  
• 그에 반해 HTTP/2는 커넥션당 여러 개의 요청과 응답, 즉 다중 요청/응답이 가능함
• 여러 리소스의 동시 전송이 가능하므로 HTTP/1.1에 비해 페이지 로드 속도가 약 50% 정도 빠르다고 알려져 있음
  

2) HTTP/2.0 특징

• HTTP 메시지 전송 방식의 변화
  • 바이너리 프레이밍(binary framing) 계층 사용 → 파싱, 전송 속도↑, 오류 발생 가능성↓
    
• Request and response multiplexing (I/O Multiplexing)
  • HTTP 1.1의 HTTP Pipelining의 개선안으로 하나의 Connection을 통해 동시에 여러 개의 메세지를 주고 받을 수 있음
  • 또한, 응답은 요청 순서에 상관없이 Stream으로 받기 때문에 HOL(Head Of Line) Blocking 문제도 해결
  • 즉 여러 개의 스트림을 사용하여 송수신한다는 것. 이를 통해 특정 스트림의 패킷이 손실되었다고 하더라도 해당 스트림에만 영향을 미치고 나머지 스트림은 멀쩡하게 동작할 수 있음
• Stream Prioritization
  • 리소스간 우선 순위를 설정 가능
  • 응답에 대한 우선순위를 정해 우선순위가 높을수록 응답을 빨리 함
• Server Push
  • 클라이언트가 요청하기 전에 HTTP/2 호환 서버가 리소스를 HTTP/2 호환 클라이언트에 보낼 수 있음
  • 서버 푸시는 클라이언트가 리소스가 필요할지 알기도 전에 미리 리소스를 로드하여 대기 시간을 줄이는 것을 목표로 하는 성능 기술
  • 즉, 서버가 클라이언트의 요청없이 응답을 보내는 방법으로 클라이언트의 요청을 최소화하여 서버가 리소스를 보내주는 방식

 

• Header Compression
  • HTTP 1.1의 경우 이전 요청과 중복되는 Header도 똑같이 전송하느라 네트워크 자원을 불필요하게 낭비하였음
  • HTTP 2.0의 경우, 헤더의 크기를 줄여 페이지 로드 시간 감소
  • Header Table과 Huffman Encoding을 사용하는 HPACK 압축방식으로 이를 개선하였음
  • 클라이언트와 서버는 각각 Header Table을 관리하고 이전 요청과 동일한 필드는 table의 index만 보내고, 변경되는 값은 Huffman Encoding 후 보냄으로서 Header의 크기를 경량화

 

4. HTTP/3.0

• HTTP/3.0은 HTTP/2.0에서 사용하는 TCP 나 TLS 방식이 아닌 QUIC(Quick UDP Internet Connections)를 통해 설계됨
• http/3.0에서는 무조건 https를 사용
• HTTP/2.0 에서 장점이었던 멀티플렉싱을 가지고 있으며, "초기 연결 설정 시 지연 시간 감소"라는 대표적 특성이 있음
  
  

1) QUIC(Quick UDP Internet Connections)

• 전송 계층 프로토콜
• 순방향 오류 수정 매커니즘(FEC, Forward Error Correction) 적용
  • 전송한 패킷이 손실되었다면 수신 측에서 에러를 검출하고 수정하는 방식이며 열악한 네트워크 환경에서도 낮은 패킷 손실률을 자랑
• 헤더 압축 또는 HPACK이 아닌 QPACK사용
  
  
• Q) TCP가 아닌 UDP를 선택한 이유?
• A) TCP 헤더는 신뢰성을 확보하지만 지연을 줄이기 힘든 구조고 UDP는 데이터 전송에 집중한 설계로 별도의 기능이 없음
  따라서, 원하는 기능의 구혀이 가능하며, TCP의 Latency를 줄이면서 TCP만큼 신회성 확보가 가능함.

2) QUIC의 장점

• 전송 속도 향상
  • 첫 연결 설정에서 필요한 정보와 함께 데이터를 전송 → 연결 성공 시 설정을 캐싱하여 다음 연결 때 바로 성립 가능
• Connection UUID라는 고유한 식별자로 서버와 연결 → 커넥션 수립 필요X
• TLS(전송 계층 보안, Transport Layer Security) 기본 적용
• 독립 스트림을 이용하여 향상된 멀티플렉스 기능 제공
• IP Spoofing / Replay Attack을 방지해 보안성 향상
  • Spoofing: 근거리 통신망(LAN) 하에서 주소 결정 프로토콜(ARP) 메세지를 이용해 상대방의 데이터 패킷을 중간에서 가로채는 중간자 공격 기법