HTTP/1.0

HTTP/1.0은 단기 커넥션(Short-lived Connection) 모델을 사용했으며, 클라이언트는 각 리소스(HTML, css, image, js)를 요청할 때마다 새로운 TCP연결을 맺어야 했다. 다시 말해 하나의 Request당 하나의 Connection을 생성하였다.

HTTP/1.1

그래서 이런 단점을 보완하기 위해 HTTP/1.1이 등장하였다.

HTTP/1.1은 영속적 커넥션(Persistent Connection)또는 ‘Keep-Alive’개념을 도입했다. 한 번 맺은 TCP 연결을 여러 요청에 재사용하여 핸드셰이크의 오버헤드를 줄였다.

하지만 이 모델도 여전히 문제가 있었다. 클라이언트는 하나의 요청에 대한 응답을 모두 받은 후에야 다음 요청을 보낼 수 있었고. 이로 인해 TCP 연결이 유휴 상태(idle)에 빠지는 새로운 병목이 발생했다.

파이프라이닝

HTTP 파이프라이닝은 이 유휴 시간 문제를 해결하기 위해 고안되었다. 클라이언트가 이전 요청의 응답을 기다리지 않고 여러 요청을 한 번에 보내는 기능이다. 목표는 네트워크 파이프를 항상 데이터로 채워 유휴 시간과 지연 시간을 단축하는 것이었다.

파이프라이닝의 작동 원리

파이프라이닝은 순차적 요청-응답 모델의 한계를 극복하기 위해 설계되었다.

전제 조건

• 영속적 커넥션: 영속적 커넥션(keep-alive) 위에서만 동작한다.
• 멱등성(Idempotent) 메서드: GET, HEAD, PUT, DELETE와 같이 여러 번 보내도 결과가 동일한 멱등성 메서드만 파이프라이닝할 수 있다. 네트워크 오류 발생 시, 클라이언트는 어떤 요청까지 성공했는지 알 수 없으므로 전체 요청 묶음을 안전하게 재전송해야 하기 때문이다. POST와 같이 멱등성이 없는 메서드는 중복 데이터 생성 문제로 인해 금지된다.

메커니즘

1. 클라이언트는 서버와 keep-alive TCP 연결을 설정한다.
2. 클라이언트는 응답을 기다리지 않고 여러 요청을 순서대로 보낸다.   
3. 서버는 요청을 받은 순서와 정확히 동일한 순서로 응답을 보낸다. 이 선입선출(FIFO) 원칙은 반드시 지켜져야 한다.

이렇게 파이프라이닝 기법은 여러 요청을 한 번의 RTT 내에 보낼 수 있어 네트워크 지연을 최소화 할 수 있었고 TCP연결의 유휴 상태를 줄이고, 여러 요청을 하나의 TCP 패킷에 담아 전송할 수 있어 네트워크 자원을 효율적으로 사용하는 이점이 있었다.

하지만 pipelining에는 치명적인 결함이 있는데 그게 HOL(Head-of-Line) 블로킹이다.

HOL 블로킹

앞서 설명했듯이 파이프 라이닝에서 서버는 요청을 받은 순서와 정확히 동일한 순서로 응답을 보낸다. HTTP/1.1은 각 요청과 응답을 고유하게 식별할 메커니즘이 없기 때문에 정확하게 동일한 순서로 처리해야지 요청에 알맞은 응답을 보내줄 수 있었다.

그래서 만약에 Queue에 가장 앞에 있는 항목의 처리가 지연될 경우, 그 뒤에 있는 모든 항목들이 대기해야하는 HOL 블로킹 현상이 일어난다.

클라이언트가 세 개의 요청을 순서대로 파이프라이닝으로 보냈다고 가정하자.

1. GET /api/complex_report (5초 소요)
2. GET /images/logo.png (10ms 소요)
3. GET /css/styles.css (10ms 소요)

서버는 로고와 CSS 파일을 즉시 준비하지만, 선입선출 규칙 때문에 5초가 걸리는 보고서 생성이 완료될 때까지 응답을 보내지 못하고 대기해야 한다. 결국 로고 이미지를 받는 데 5초 이상이 걸리게 되어, 파이프라이닝이 오히려 사용자 경험을 악화시켰다. 

이 문제는 HTTP/1.1 프로토콜 자체에 내재된 애플리케이션 계층의 문제이며, 해결이 불가능했다. 응답 순서를 바꾸려면 각 응답을 식별할 방법이 필요하지만, HTTP/1.1에는 그런 기능이 없었다.

이후 이 문제를 개선하기 위해 HTTP/2.0이 등장하게 되었다.