HTTP의 역사
HTTP/0.9 - GET 메서드만 지원, HTTP 헤더 X
- 응답도 html 파일 자체만 보내줌
HTTP/1.0 - 메서드, 헤더, 상태코드 추가
- 요청헤더: http 버전이 생김
- 응답헤더: 상태코드가 생겨 브라우저에 요청에 대한 성공과 실패를 알 수 있었고, content-type이 생겨 html 파일 외 다른 타입의 파일도 전송
- 단기커넥션: connection 하나당 1요청, 1응답만 처리 가능. 이러한 short-lived connection 때문에 매번 새로운 연결로 성능 저하 및 서버 부하 비용 증가
예를 들어, 웹페이지를 요청하면 html과 그와 함께있는 css나 js 등등의 많은 자원들까지 화면에 띄울텐데, 각 자원들을 매번 따로따로 TCP 연결하고 다운받고 연결끊고, 다시 연결하고 다운받고 연결을 끊다보니 너무 느렸다고 한다....
그리고 이러한 문제는 1.1을 통해 해결되었다.
HTTP/1.1
커넥션 유지(Persistnet Connection)
지정한 timeout동안 연속적인 요청 사이에 커넥션 닫지 않음
위 그림과 같이 1.0 은 요청 컨텐츠마다 TCP 세션을 맺어야 한다.(1 GET/ 1 Conncection)
이와 다르게 1.1은 Persistent 기능을 이용하여 한 개의 TCP 세션을 통해 여러 개의 컨텐츠 요청이 가능하다.(N GET/ 1 Connection)
파이프라이닝
하나의 커넥션에서 이전 요청에 대한 응답이 완전히 전송되기 전에 다음전송을 가능하게 하여, 여러 요청을 연속적으로 보내 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방식.
HTTP 요청은 순차적으로 이루어진다.
왼쪽 그림과 같은 경우, 요청#1 ➡️ 응답#1 ➡️ 요청#2 ➡️ 응답#2 ➡️ 요청#3 ➡️ 응답#3 으로 이루어진다.
이를 해결하려고 하나의 커넥션에서 응답을 기다리지 않고 순차적인 여러 요청을 일단 연속적으로 보내서(요청#1,#2,#3 다다다 보내버림) 그 순서에 맞춰 응답을 받는 방식으로 지연 시간을 줄이는 방법
그.런.데 파이프라이이닝의 치명적인 문제가 있었으니!!
요청#1에 대한 처리가 되지 않으면, 요청#2,#3이 아무리 빨리 해결될 수 있는 문제라해도 처리될 수 없다는 것! (Head Of Line Blocking: 우선순위로 들어온 요청의 응답 시간이 길어지면 후순위에 있는 요청의 응답시간이 길어진다는 단점)
*특정 응답 지연(Head Of Line-Blocking): 네트워크에서 같은 큐에 있는 패킷이 첫번째 패킷에 의해 지연될 때 발생하는 성능 저하 현상을 말한.
그리고 이러한 문제 역시 다음 버전인 2.0을 통해 해결될 수 있었다.
HTTP/2.0
기존 1.x 버전의 성능 향상에 초점을 맞춘 프로토콜로서, 대체보다는 확장 개념이라고 생각하면 된다.
특징
HOL blocking 문제 해결
HTTP/1.1까지는 한번에 하나의 파일만 전송이 가능했다. 이로인해 여러 파일을 전송할 경우, 선행하는 파일의 전송이 늦어지면 전체 파일 전송의 시간이 늘어나는 문제가 발생하였다.
HTTP/2.0에서는 여러 파일을 한번에 병렬적으로 요청하고, 응답되도록 하였다. 이제 아무리 첫번째 파일이 시간이 걸리는 처리더라도 뒤에 요청한 파일들 먼저 받아서 보여줄 수 있다는것!
HTTP Header Data Compression(HTTP 헤더 데이터 압축)
이전 헤더의 내용과 중복되는 필드를 재전송하지 않도록 하여, 데이터를 절약한다. 기존에 HTTP header가 평문이었다면, 2버전에서는 Huffman Coding을 사용하는 HPACK이라는 헤더 압축방식을 이용하여 데이터 전송 효율을 높였다.
Server Push
클라이언트가 요청하지 않은 Javascript, CSS, Font, 이미지 파일 등과 같이 필요하게 될 특정 파일들을 서버에서 단일 HTTP 요청 응답시 함께 전송할 수 있다.
하지만 HTTP2는 여전히 TCP를 이용하기 때문에 Handshake의 RTT로 인한 지연시간 등의 문제는 남아있었다.
*양방향 지연(Round Trip Time): 네트워크 시작 지점에서 대상 지점으로 이동하고 다시 시작지점으로 이동하는데 걸리는 시간을 말한다.
QUIC
TCP는 3 way handshake, 끝날 때 4 way handshake 등 오버헤드와 HOLB 등의 문제를 피할 수 없다.
QUIC은 TCP handshake 과정을 최적화하는 것에 초점을 맞추어 설계되었다.
UDP는 데이터그램 방식을 사용하는 프로토콜이기에 각각의 패킷간 순서가 존재하지 않는 독립적인 패킷이다.
TCP에 비해 헤더가 많이 비어있기에 커스터마이징할 여지가 많고 이를 이용해 개발자가 구현을 어떻게 하느냐에 따라서 신뢰성을 확보할 수 있다.
