[네트워크] Ch2.6 HTTP의 발전 과정(HTTP Evolution)

 

 

본 글은 학교 네트워크 수업을 들으며, "Computer Networking: A Top-Down Approach 8ed(컴퓨터 네트워킹: 하향식 접근 제8판)"을 기반으로 공부한 내용을 정리한 글입니다.

 

Ch2.6 HTTP의 발전 과정(HTTP Evolution)

https://cuffyluv.tistory.com/104

해당 글 초반부도 참고하기.

HTTP timeline

https://techdifferences.com/difference-between-http-and-ftp.html

HTTP/1.0

- Non-persistent connection 방식을 사용함.

https://c3lab.poliba.it/index.php?title=HTTP_OVER_UDP

HTTP/1.1

- Persistent connection 도입 - 여러 클라이언트들과 최대 6개의 connection을 병행 가능.

- Pipelining 도입 - response가 오지 않더라도 계속 보냄.

- Loss recovery 도입 - 손실된 TCP segment들을 다시 전송하는 기술.

 

head-of-line(HOL) blocking 문제 발생

- https://velog.io/@dnr6054/HOL-Blocking 참고.

- https://letitkang.tistory.com/79 참고.

- HTTP는 `In-order Response` 즉 순서대로 응답을 받아야 하기 때문에, 앞에서 큰 사이즈의 object를 받아야 하면 뒤에 있는 object들은 앞에 꺼 response 처리가 끝날 때까지 대기해야함.

ex. 영화 파일 ㅈㄴ 큰거 받을 끝날 때까지, 뒤에 올 사진 한 장은 못 받고 기다림.

HTTP/2

Binary message

- 대부분 헤더 필드들은 HTTP/1.1 그대로임.

- 그러나 사람이 읽을 수 있는 아스키 텍스트 형태에서, binary 형태로 메시지를 다루게 됨.

- 거기에 header compression까지 적용해서, 사람이 읽고 이해하기 어렵게 만듦.

- 이는 데이터 전송의 효율성 및 성능 최적화를 목표로 한 거지, HTTPS와 달리 보안 자체가 목적은 아님. 그래서 HTTPS와 같이 사용해야 하고.

 

Stream prioritization(스트림 우선순위)

- 무조건 먼저 도착한 순서대로(FCFS : First Come, First Served) response 보내는 게 아니라,

- request의 우선순위에 따라 더 중요한 request에 대해 먼저 response함.

- 위 사례의 경우, 2가 1보다 더 중요하다 생각해, 1이 먼저 전송돼도 2 먼저 응답하고 있음.

- Multiplexing : 묶어서 encapsulation 해서 보내는 느낌. 

Server PUSH

- 서버가 아직 request받지 않은 object에 대해서도, 다음번엔 이 object가 request 되겠지? 하고 예상해서 알아서 object를 push하는 방식.

HOL blocking mitigation(완화)

- HTTP 1.1에 있던 HOL blocking 문제는 앞에 큰 object가 있으면 (큐의) 뒤에 있는 object가 기다려야 했던 것.

- 이걸 큰 object를 작은 데이터 조각들(프레임)로 나누어서 전송하게 바꿈.

 

HTTP/2의 한계

- TCP는 복잡하고 시간도 오래걸리고 하는 단점이 있음.

- HTTP는 기본적으로 secure한 특성이 없어서 TLS가 추가로 필요해짐

=> UDP 기반의 자체적으로 secure한 HTTP 버전을 만들어보자!!

QUIC (Quick UDP Internet Connections)

- 2012년 구글에 의해 설계됨

- UDP 기반으로 빠른 속도를 지원함

- TLS와 동등한 security를 가짐.

- HTTP/2과 동등한 Multiplexing, flow control을 가짐.

- TCP와 동등한 Reliability, congestion control을 가짐.

- TCP 기능들을 좀 넣어가지고, 최대한 reliable하게 만들어놈.

- QUIC Connection Establishment과정에서도, 이미 알려진 common server면 0 RTT만에 수립이 가능해서 더 빠름.

- 최근에는 7~8%의 웹사이트에서 사용되고 있음. 크롬에서 설정 가능(default : 사용)

HTTP/3

- 2019년 등장

- QUIC를 사용한 HTTP 버전