[Network] HTTP 1, 2, 3 📌

HTTP (HyperText Transfer Protocol)

• 웹에서 정보를 교환하기 위한 전송 프로토콜
• www(world wide web)에서 하이퍼텍스트 문서를 교환하기 위해 사용되는 통신 규약
• 웹의 기반이자 웹을 이루는 기술의 자체라고 할 수 있다
• TCP/IP 프로토콜 위에서 동작하며, 80번 포트를 사용하여 통신한다
• HTML 문서, 이미지, 동영상, 오디오, 텍스트 문서 등의 모든 종류의 데이터를 전송한다

 

 

HTTP 특징

1) 비연결성 (connectionless)

• 클라이언트와 서버가 연결을 맺은 후에 응답을 마치면 기존의 연결을 끊는 특성
• 클라이언트의 연결 유지를 위한 리소스가 필요하지 않기 때문에 더 많은 연결이 가능하다
• 그러나 서버에서는 클라이언트의 반복된 요청에도 매번 연결 및 해제 과정을 수행해야 하기 때문에 이에 따른 오버헤드가 발생할 수 있다

 

2) 무상태성 (stateless)

• 비연결성으로 인해 서버는 클라이언트가 이전에 어떠한 상태를 가지고 있는지 알 수 없다
• 이를 보완하기 위해 쿠키와 세션 개념이 등장하였다

---

HTTP/0.9

• 버전 번호가 따로 없는 상태로 발표되었던 초기 HTTP
• 요청이 단일 라인으로 구성되며 가능한 메서드는 GET이 유일했다
• Header 따위는 없었고, 그 때문에 오직 HTML 파일만 전송이 가능했으며 상태 확인을 위한 코드도 존재하지 않았다
• 이는 HTTP/1.0이 나오면서 HTTP/0.9로 불리게 되었다

 

---

HTTP/1.0

제한적인 기능을 개선하여 아래의 기능들이 추가되었다

• 요청에 버전 정보가 붙어서 전송되기 시작했다
• 응답 시작 부분에 상태 코드가 추가되었다
• 모든 요청과 응답에 헤더 개념이 추가되었다

 

 

HTTP/1.0의 단점

• Connection 한 개당 하나의 요청을 처리하도록 설계되었다
  • 동시에 리소스를 주고받는 것이 불가능하다
  • 요청과 응답이 순차적으로 이루어진다
  • HTTP 문서 내에 포함된 다수의 리소스(image, css, script)를 처리하려면 요청할 리소스의 개수에 비례하여 Latency(대기시간)이 길어진다

 

 

HTTP/1.1

HTTP/1.0이 발표될 당시 다양한 표준화가 진행되고 있었고, HTTP/1.0 발표가 된지 몇 달 지나지 않아 HTTP의 첫번째 표준 버전인 1.1이 발표되었다

HTTP/1.1 버전은 많은 개선사항을 도입하였다

• Connection Keep-Alive (기존 연결에 대해서 handshake 생략 가능)
  • 이전 비연결성인 HTTP 연결은 한 번의 요청과 응답이 끝나면 연결을 끊어 매번 Handshake를 해야했기 떄문에 overhead가 발생했다
  • 이후 Kepp-Alive 기능을 통해 한 번 맺어졌던 연결을 끊지 않고 지속적으로 유지하여 성능이 개선되었다
• 파이프 라이닝이 추가되어 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능하게 하여 레이턴시를 낮췄다
• 청크된 응답을 지원한다(응답 조각)
• 캐시 제어 매커니즘
• 언어, 인코딩 타입 등을 포함한 컨텐츠 전송

 

 

 

HTTP/1.1의 단점

• HOL(Head Of Line) Blocking
  • 파이프라이닝은 한 번에 순차적인 여러 요청을 연속적으로 처리하고, 그 순서에 맞춰 응답을 받아서 지연 시간을 줄이는 방법이다
  • 순차적으로 데이터를 요청하고 받아야 하다 보니 먼저 받은 요청이 끝나지 않으면 뒤의 작업이 아무리 빨라도 기다려야 하는 HOL Blocking 문제가 발생한다
  • HOL Blocking이란 네트워크에서 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상이다
  • 그래서 모던 브라우저들은 대부분 파이프라이닝을 사용하지 못하도록 막아두고, H1으로 통신할 때 클라이언트가 요청을 병렬로 하기 위해서 6~8개의 커넥션을 이용하여 데이터를 가져오는 방식으로 성능을 개선하고 있다
• RTT(Round Trp Time) 증가
  • Connection 하나에 요청 한 개를 처리하는 특성때문에 매번 요청별로 Connection을 만들게 되고, TCP 상에서 동작하는 HTTP의 특성상 3-way handshake가 반복적으로 일어난다
  • 이는 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 지연시킨다
• 무거운 Header 구조
  • HTTP/1.1의 헤더에는 많은 메타 정보들이 저장되어 있다
  • 매 요청마다 중복된 헤더 값을 전송하게 되며, 서버 도메인에 관련된 쿠키 정보도 헤더에 함께 포함되어 전송된다
  • 이러한 반복적인 헤더 전송, 쿠키 정보로 인해 헤더 크기가 증가한다

 

 

 

---

 

SPDY

• 구글은 더 빠른 Web을 실현하기 위해 Latency 관점에서 HTTP를 고속화한 SPDY(스피디) 프로토콜을 구현
• HTTP를 대치하는 프로토콜이 아닌,, HTTP를 통한 전송을 재정의하는 형태로 구현
• SPDY는 실제로 HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여주었고, 이는 HTTP/2 초안의 참고 규격이 되었다

 

 

 

 

HTTP/2

완전히 새로운 프로토콜이 아닌, SPDY의 개선사항을 적용하여 수정된 성능 향상에 초점을 맞춘 프로토콜이다

• Multiplexed Streams
  • 멀티플렉싱을 사용하여 한 번의 연결(Handshake)에 여러 요청을 처리한다
  • 한 커넥션으로 동시에 여러 개의 메시지를 주고 받을 수 있으며, 응답은 순서에 상관없이 Stream으로 주고 받는다
  • HTTP/1.1의 Connection Keep-Alive, Pipelining의 개선
• Stream Prioritization
  • 클라이언트가 요청한 HTML 문서 안에 CSS 파일 1개와 Image 파일 2개가 존재하고, 이를 클라이언트가 각각 요청한다고 가정해보자
  • 이 때 만약 Image 파일보다 CSS 파일 수신이 늦어지는 경우, 브라우저의 렌더링이 늦어지는 문제가 발생한다
  • 그러나 HTTP/2의 경우 리소스 간 의존관계(우선순위)를 설정하여 이러한 문제를 해결하였다
• Server Push
  • 서버는 클라이언트의 요청에 대해 요청하지도 않은 리소스를 보내줄 수 있게 되었다
  • 클라이언트가 HTML 문서를 요청하고 해당 HTML에 여러 리소스가 포함되어 있는 경우, HTTP/1.1에서는 클라이언트가 요청한 HTML 문서를 수신한 후 HTML 문서를 해석하면서 필요한 리소스를 재요청하였다
  • 반면 HTTP/2는 Server Push 기법을 통해 클라이언트가 요청하지 않은 HTML 문서에 포함된 리소스를 Push 해주는 방법으로 클라이언트의 요청을 최소화하여 성능 향상을 이뤄냈다
• Handshake 과정을 줄임으로써 Latency를 낮춤

 

 

 

HTTP/2 의 단점

• 여전히 TCP를 사용하기 때문에 Handshake의 RTT로 인한 Latency와 TCP의 HOLB 문제는 해결할 수 없었다

 

 

 

---

QUIC

• Quick UDP Internet Connections의 약자
• UDP를 기반으로 TCP + TLS + HTTP의 기능을 모두 구현한 프로토콜이다
• 구글에서 개발한 프로토콜로, HTTP/3의 기반 기술이 되었다

 

 

 

HTTP/3

TCP 방식을 사용하는 HTTP/1, HTTP/2와 달리 UDP 방식을 사용한다

정확히는 UDP 기반의 프로토콜인 QUIC을 사용하여 통신하는 프로토콜이다

UDP를 사용하지만 기존의 신뢰성 있는 통신을 포기한 것은 아니다

기존의 TCP는 수정하기 어려운데다 백지 상태나 다름이 없었던 UDP를 사용함으로써 QUIC의 기능을 확장하기 쉬웠기 때문에 가능했다고 한다

 

• RTT 감소로 인한 지연시간 단축
  • QUIC은 TCP를 사용하지 않기 때문에 통신을 시작할 때 번거로운 3-way Handshake 과정을 거치지 않아도 된다
  • QUIC은 첫 연결 설정에 필요한 정보와 함께 데이터도 보내기 때문에 1 RTT만 소요된다
  • 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 그에 응답하기만 하면 바로 기본 통신을 시작할 수 있다!
  • 단, 클라이언트가 서버로 첫 요청을 보낼 때는 서버의 세션 키를 모르는 상태이기 때문에 목적지인 서버의 Connection ID를 사용하여 생성한 특별한 키인 초기화 키(Initial Key)를 사용하여 통신을 암호화한다
• 패킷 손실 감지에 걸리는 시간 단축
  • QUIC도 TCP와 마찬가지로 전송하는 패킷에 대한 흐름 제어를 해야 한다
  • 통신 과정에서 발생한 에러를 재전송을 통해 에러를 복구하는 ARQ 방식을 사용하기 때문이다
  • TCP는 여러 ARQ 방식 중 Stop anw Wait ARQ 방식을 사용한다
  • 이는 송신 측이 패킷을 보낸 후 타이머를 사용하여 시간을 재고, 일정 시간이 경과해도 수신 측이 적절한 답변을 주지 않는다면 패킷이 손실된 것으로 판단하여 해당 패킷을 다시 보내는 방식이다
  • QUIC은 헤더에 별도의 패킷 번호 공간을 부여하여 TCP가 RTT 계산에서 패킷 손실 감지에 걸리는 시간을 단축하였다
• 멀티 플렉싱 지원
  • HTTP/2와 마찬가지로 멀티플렉싱을 지원한다
  • 하나의 스트림에서 문제가 발생해도 다른 스트림은 지킬 수 있기 때문에 보다 자유롭다
• 클라이언트의 IP가 바뀌어도 연결이 유지된다
  • TCP의 경우 소스의 IP 주소와 포트, 연결 대상의 IP 주소와 포트로 연결을 식별하기 때문에 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어져 버린다
  • 즉, 다시 Handshake 과정을 거쳐야 하기 때문에 Latency가 발생한다
  • 반면에 QUIC은 Connection ID를 이용하여 서버의 연결을 생성한다
  • Connection ID는 랜덤한 값일 뿐, 클라이언트의 IP와는 전혀 무관한 데이터이기 떄문에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지가 가능하다

 

💡 RTT (Round Trip Time)
- 클라이언트가 보낸 요청을 서버가 처리한 후 다시 클라이언트로 응답해주는 사이클
- TCP는 연결을 생성하기 위해 기본적으로 1 RTT가 필요하고, 여기에 TLS를 사용한 암호화까지 하려고 한다면 TLS의 자체 Handshake까지 더해져 총 3 RTT가 필요하게 된다

💡 RTO (Retransmission Time Out)
- TCP에서 패킷 손실 감지에 대해 송신 측이 패킷을 수신 측으로 보내고 난 후, Time out을 언제 낼 것인지 동적으로 계산하는 시간을 의미한다
- RTO에서 필요한 데이터는 RTT들의 샘플이다
- RTT 샘플을 측정하기 위해서는 반드시 송신 측으로부터 ACK를 받아야 하는데, 정상적인 상황에서는 문제가 없으나 Time out이 발생하여 패킷 손실이 발생하게 되면 RTT 계산이 애매해진다
- 이러한 경우를 위해 헤더에 별도의 패킷 번호 공간을 부여하여 패킷 고유의 번호를 가지고 있는다

 

---

참고)

https://sujinhope.github.io/2020/10/04/Network-TCP%EC%99%80-UDP,-HTTP1,2,3,-HOLB%EB%9E%80.html

[network] tcp와 udp, http1,2,3, holb란 - Break Out of Your Comfort Zone

https://velog.io/@wiostz98kr/HTTP1.1%EA%B3%BC-HTTP2.0%EC%9D%98-%EC%B0%A8%EC%9D%B4-e2v4x4t1

HTTP1.1과 HTTP2.0의 차이

https://github.com/InJun2/TIL/blob/main/CS-topic/network/HTTP_1-2-3.md