HTTP 지속연결성과 파이프라이닝 (22.10.03 TIL)

 HTTP는 세션이 없는 프로토콜이다. HTTP 의 각 요청 및 응답 시퀀스는 서로 독립적이다. 즉, HTTP 자체적으로 각 요청에 고유한 연결이 있어야 한다. 이것을 더 효율적으로 만들려면 HTTP Keep-Alive가 필요하다.

HTTP 1.0과 HTTP 1.1 의 가장 큰 차이점은 연결의 지속성(Connection: Keep-alive)이다.  HTTP 는 기본적으로 TCP 를 이용하여 통신한다. 이 때 클라이언트가 서버에 요청을 보낸 다음 응답으로 응답하는 요청-응답 패러다임에서 HTTP 1.0 은 TCP 세션을 유지하지 않는다. 매번 데이터를 요청하고 수신 할 때마다 TCP 세션을 닫고 열고를 반복한다.

 반면 HTTP 1.1 은 TCP 세션을 한 번만 맺으면 여러개의 요청을 보내고 응답을 수신할 수 있다. 결과적으로 TCP 세션을 열고 닫는 시간이 줄어들기 때문에 비용을 줄이고 응답속도를 개선할 수 있게 된다.

 HTTP 1.1 은 지속적인 연결에 의존하기 때문에 이를 사용하여 여러 쿼리를 연속적으로 보내고, 동일한 순서로 응답을 기대할 수 있다. 이를 HTTP 파이프라이닝 이라고 한다.

 파이프라이닝을 사용하면 브라우저가 지속적 연결을 통해 여러 요청을 보낼 수 있기 때문에 지속연결성의 이점이 더욱 커진다. 예를 들어 파이프라이닝을 통해 3개의 요청을 한 번에 보내면 왕복 시간을 줄일 수 있어 응답 지연에 매우 좋은 효과를 기대할 수 있다. 하지만 만약 첫 번째 요청의 처리가 서버에서 오래 걸릴 경우, 두 번째~세 번째의 응답이 같이 지연된다. 이것을 HOL (Head of Line) Blocking 이라고 한다.

 HTTP 2 에서는 멀티플렉싱 기능에 의해 HOL Blocking 이 해소된다. HTTP 2 에서 요청은 하나의 연결에서 병렬적으로 보내진다. 1, 2, 3 번의 요청이 모두 병렬적으로 보내지기 때문에 1번에서 시간이 소요되어도, 2번, 3번은 먼저 요청에 대한 응답을 보여줄 수 있다는 것이다.

 여기서 의문은 HTTP 1.1 에서는 왜 굳이 순서대로 응답을 주어서 HOL Blocking 을 발생하게 하는 것인가? 이다. 먼저 처리할 수 있는 것들은 먼저 응답해주면 안되는 것일까? 

 이러한 의문의 답은 RFC 문서에 있다. (링크의 8.1.2.2 섹션 참고)

8.1.2.2 Pipelining

A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.

-> 서버는 반드시 요청이 수신된 것과 동일한 순서(in the same order)로 해당 요청에 대한 응답을 보내야 한다.

 
 이렇듯 웹 서버는 파이프라이닝을 통해 한 번에 여러개의 요청을 받을 수 있으나, 응답 순서는 요청 순서에 따라야 하는 것이 HTTP 프로토콜의 규칙이다. 

 

 

참고 :

HTTP Keep-Alive, Pipelining, Multiplexing and Connection Pooling - HAProxy Technologies

 

HTTP/1.1: Connections