TCP (HTTP/1.1, HTTP/2, Head-of-Line Blocking, 파이프라이닝 vs 멀티플렉싱)

 

1. HTTP/1.1 Baseline

• 연결 과정: 클라이언트가 서버와 연결을 열고, 하나의 요청을 보내고 그에 대한 응답을 받습니다. 요청과 응답이 완료되면 다음 요청을 보냅니다.
• 특징:
  • 직렬 처리: 각 요청은 응답을 받고 나서야 다음 요청을 보낼 수 있습니다.
  • 대기 시간: 첫 번째 요청이 완료될 때까지 두 번째 요청은 대기합니다. 이로 인해 **대기 시간(latency)**이 발생하게 됩니다.
• 문제점: 네트워크 대기 시간 동안 요청을 기다려야 하기 때문에 비효율적입니다. 여러 요청이 있을 때 각 요청이 순차적으로만 처리됩니다.

2. HTTP/1.1 Pipelining

• 연결 과정: 클라이언트가 첫 번째 요청을 보내고, 응답을 기다리지 않고 두 번째, 세 번째 요청을 연달아 보냅니다. 하지만 응답은 여전히 요청 순서대로 도착해야 합니다.
• 특징:
  • 동시 요청 가능: 여러 요청을 한 번에 보낼 수 있어, 서버에서 처리할 시간이 절약될 수 있습니다.
  • 응답 순서 고정: 요청 순서대로 응답이 와야 하므로, 앞선 요청이 지연되면 뒤에 있는 요청들이 모두 지연되는 Head-of-Line Blocking(HOL 블로킹) 문제가 발생할 수 있습니다.
• 문제점: 응답이 순차적으로 와야 하기 때문에, 첫 번째 요청이 지연되면 전체 응답이 지연될 수 있습니다.

3. HTTP/2 Multiplexing

• 연결 과정: 클라이언트가 여러 요청을 동시에 보내고, 서버는 각 요청을 병렬로 처리하여 비순차적으로 응답을 보냅니다.
• 특징:
  • 동시 요청 및 응답: 요청과 응답이 순서에 상관없이 동시다발적으로 이루어집니다. 즉, 각 요청은 독립적으로 처리되고, 서버가 처리할 수 있는 순서대로 응답을 보냅니다.
  • 응답 순서 유연함: 응답 순서는 요청 순서와 다를 수 있습니다. 따라서 특정 요청이 지연되어도 다른 요청에 영향을 미치지 않습니다.
• 장점: Head-of-Line Blocking 문제가 발생하지 않으며, 네트워크 대역폭을 더 효율적으로 사용할 수 있습니다. 클라이언트는 병렬로 요청을 처리하고, 더 빠르게 응답을 받을 수 있습니다.

비교 및 분석

• HTTP/1.1 Baseline: 요청과 응답이 순차적으로 이루어지기 때문에 각 요청 사이에 대기 시간이 발생하며, 성능이 낮아집니다.
• HTTP/1.1 Pipelining: 여러 요청을 한 번에 보내어 대기 시간을 줄일 수 있지만, 요청 순서에 따라 응답이 이루어져야 하므로, HOL 블로킹 문제가 발생할 수 있습니다.
• HTTP/2 Multiplexing: 여러 요청을 독립적으로 처리하고, 응답 순서에 구애받지 않기 때문에 HOL 블로킹 문제가 해결됩니다. 결과적으로 전체 성능이 크게 향상됩니다.

결론

• HTTP/1.1 Baseline은 요청이 순차적으로 처리되기 때문에 성능이 낮고, 대기 시간이 증가합니다.
• HTTP/1.1 Pipelining은 요청을 병렬로 보낼 수 있으나, 응답 순서가 고정되기 때문에 Head-of-Line Blocking 문제가 발생할 수 있습니다.
• HTTP/2 Multiplexing은 가장 진보된 방식으로, 각 요청을 독립적으로 처리하여 네트워크 성능을 크게 향상시킵니다.ㄴ

 

---

 

**Head-of-Line Blocking(HOL Blocking)**은 네트워크 통신에서 발생하는 성능 저하 현상 중 하나로, **큐의 앞에 있는 패킷(또는 요청)**이 지연되면서 그 뒤에 있는 패킷들까지 차례로 지연되는 문제를 말합니다. 이 현상은 주로 큐 방식으로 패킷을 처리하는 네트워크 환경에서 발생하며, 네트워크 대역폭 사용 비효율성과 응답 지연을 초래할 수 있습니다.

어디서 발생하는가?

1. TCP:
   • TCP 프로토콜에서는 패킷의 순서를 보장합니다. 만약 앞선 패킷이 손실되거나 지연되면, 그 패킷이 도착하기 전까지 뒤에 오는 패킷들도 수신되지 못하고 처리되지 않습니다. 이 때문에, 하나의 패킷 지연이 전체 데이터 흐름에 영향을 주는 HOL 블로킹이 발생할 수 있습니다.
2. HTTP/1.1:
   • HTTP/1.1에서는 한 번에 하나의 요청만 처리할 수 있는 파이프라인 방식으로 여러 요청을 처리합니다. 이 경우 첫 번째 요청이 완료되지 않으면, 그 뒤의 요청들이 모두 대기 상태에 있게 되며 HOL 블로킹이 발생할 수 있습니다.
3. 스위칭 네트워크(라우터):
   • 스위치나 라우터에서 각 포트에 대한 큐가 존재하는 경우, 특정 포트로 향하는 트래픽 중 앞서 들어온 패킷이 문제를 일으키면 그 뒤에 있는 패킷들도 함께 지연됩니다. 이로 인해 패킷 전송 속도가 느려지고, 네트워크 성능이 저하됩니다.

Head-of-Line Blocking의 예

1. TCP에서의 HOL Blocking: TCP는 데이터의 신뢰성을 보장하기 위해 패킷의 순서를 유지해야 합니다. 예를 들어, 패킷 1, 2, 3이 순차적으로 전송되었을 때 패킷 2가 네트워크 문제로 손실된다면, 수신 측은 패킷 2를 다시 요청하고 재전송되기 전까지 패킷 3을 처리할 수 없습니다. 즉, 패킷 2가 지연되면서 패킷 3도 처리되지 못하는 현상이 발생합니다.
2. HTTP/1.1에서의 HOL Blocking: HTTP/1.1에서 파이프라인을 통해 여러 요청을 한 번에 보내더라도, 서버가 첫 번째 요청에 대한 응답을 보내기 전까지 그 뒤의 요청들은 응답을 받을 수 없습니다. 만약 첫 번째 요청이 느려지면 뒤의 요청들도 차례로 지연되게 됩니다.

Head-of-Line Blocking 해결책

1. HTTP/2:
   • HTTP/2에서는 HOL Blocking을 해결하기 위해 **멀티플렉싱(Multiplexing)**이라는 기술을 도입했습니다. 이를 통해 여러 요청을 동시에 처리할 수 있으며, 특정 요청이 지연되더라도 다른 요청이 독립적으로 처리됩니다. 이는 HOL 블로킹 문제를 상당 부분 완화합니다.
2. QUIC:
   • QUIC 프로토콜(구글에서 개발한 UDP 기반의 프로토콜)은 HOL Blocking을 근본적으로 해결하기 위해 스트림 독립성을 도입했습니다. 각 스트림은 독립적으로 전송 및 처리되므로, 특정 스트림에서 문제가 발생해도 다른 스트림에 영향을 주지 않게 됩니다.
3. TCP Fast Retransmit:
   • TCP의 경우 빠른 재전송(Fast Retransmit) 기능이 HOL 블로킹 문제를 완화할 수 있습니다. 손실된 패킷이 감지되면, 재전송을 통해 지연 시간을 최소화하려고 합니다.
4. 라우터의 큐 관리:
   • 네트워크 장비의 큐 관리 방식에서 HOL 블로킹을 줄이기 위해 큐를 나누거나 우선순위 큐잉을 적용하는 등의 기술도 사용됩니다.

요약

• Head-of-Line Blocking은 큐의 앞에 있는 요청이나 패킷이 지연되면서 뒤의 요청들까지 차례로 지연되는 문제입니다.
• 주로 TCP 프로토콜, HTTP/1.1, 그리고 네트워크 장비에서 발생합니다.
• HTTP/2의 멀티플렉싱, QUIC의 스트림 독립성, TCP Fast Retransmit 등 다양한 기술을 통해 해결하거나 완화할 수 있습니다.

HOL 블로킹은 성능 저하의 원인이 되므로, 이를 해결하기 위한 프로토콜이나 기술의 사용이 매우 중요합니다.

---

 

**파이프라이닝(Pipelining)**은 주로 네트워크 프로토콜에서 사용되는 기법으로, 여러 요청을 동시에 보내고, 응답을 기다리지 않고 계속해서 추가적인 요청을 보내는 방식입니다. 이를 통해 대기 시간을 줄이고 네트워크 효율성을 높일 수 있습니다.

파이프라이닝의 동작 방식

기본적으로, 파이프라이닝은 클라이언트가 서버로 여러 요청을 연속적으로 보내는 방식을 의미합니다. 이를 통해 클라이언트는 첫 번째 요청에 대한 응답을 기다리지 않고, 다음 요청들을 미리 전송할 수 있습니다. 서버는 이러한 요청들을 차례대로 처리한 후, 응답을 클라이언트에게 순차적으로 반환합니다.

이 방식은 네트워크 대기 시간(latency)을 줄이는 데 도움이 됩니다. 일반적인 HTTP 요청/응답 사이클에서는 요청을 보내고 응답을 받은 후에야 다음 요청을 보낼 수 있지만, 파이프라이닝을 사용하면 응답을 기다릴 필요 없이 여러 요청을 한 번에 보내므로 전체 응답 시간을 줄일 수 있습니다.

HTTP/1.1에서의 파이프라이닝

• HTTP/1.1은 기본적으로 파이프라이닝을 지원합니다. 클라이언트는 같은 연결에서 여러 HTTP 요청을 연속적으로 전송할 수 있습니다. 이때, 클라이언트는 첫 번째 요청에 대한 응답을 기다리지 않고 두 번째, 세 번째 요청을 계속 보냅니다.
• 예를 들어, 브라우저가 서버로부터 이미지나 스크립트 파일을 다운로드할 때 여러 파일에 대한 요청을 파이프라이닝으로 한 번에 보내면, 네트워크 대기 시간이 줄어들어 페이지 로딩 속도가 빨라질 수 있습니다.

파이프라이닝의 한계

• 순차적인 응답 처리: 파이프라이닝은 여러 요청을 보내더라도 응답은 순차적으로 처리됩니다. 즉, 첫 번째 요청의 응답이 완료되어야 두 번째 요청의 응답을 처리할 수 있습니다. 만약 첫 번째 요청이 지연되면 그 뒤의 요청들도 응답이 지연되는 문제가 발생하는데, 이를 **Head-of-Line Blocking(HOL 블로킹)**이라고 합니다.
• 서버 지원 부족: 파이프라이닝은 HTTP/1.1에서 지원되지만, 모든 서버나 프록시가 이를 완벽하게 지원하지 않으며, 클라이언트(브라우저) 측에서도 제한적으로 사용됩니다. HOL 블로킹 문제나 서버 호환성 문제로 인해 파이프라이닝의 실질적인 사용이 제한되었습니다.

파이프라이닝 vs 멀티플렉싱

• HTTP/2는 파이프라이닝의 문제를 해결하기 위해 등장한 프로토콜입니다. HTTP/2에서는 멀티플렉싱(Multiplexing) 기법을 도입하여, 여러 요청과 응답을 동시에 처리할 수 있습니다. 멀티플렉싱은 파이프라이닝과 달리 요청과 응답을 병렬로 처리하기 때문에, 특정 요청의 지연이 다른 요청에 영향을 주지 않습니다. 따라서 Head-of-Line Blocking 문제도 발생하지 않습니다.

파이프라이닝의 장단점

장점:

1. 대기 시간 감소: 여러 요청을 한 번에 보내기 때문에, 응답 대기 시간을 줄일 수 있습니다.
2. 네트워크 효율성 향상: 네트워크 연결을 재사용하면서, 다수의 요청을 연속적으로 처리할 수 있습니다.

단점:

1. Head-of-Line Blocking: 첫 번째 요청이 지연되면 뒤의 요청들이 모두 영향을 받아 응답 처리 시간이 늘어날 수 있습니다.
2. 제한된 지원: 일부 서버나 프록시에서 파이프라이닝을 제대로 지원하지 않으며, 실제로는 잘 사용되지 않는 경우가 많습니다.
3. 응답 순서 보장 필요: 응답은 항상 순차적으로 와야 하므로, 빠른 요청도 앞선 요청이 처리되기 전까지 대기해야 하는 문제가 있습니다.

파이프라이닝의 대체 기술: HTTP/2의 멀티플렉싱

HTTP/2는 파이프라이닝의 한계를 극복하기 위해 멀티플렉싱을 도입했습니다. 멀티플렉싱은 여러 요청을 동시에 처리하고, 각각의 응답을 독립적으로 받을 수 있도록 설계되어 있습니다. 이를 통해 파이프라이닝의 HOL 블로킹 문제를 해결하고, 네트워크 성능을 크게 향상시켰습니다.

요약

• 파이프라이닝은 여러 요청을 연속적으로 보내고, 응답을 기다리지 않고 추가적인 요청을 보낼 수 있는 방식입니다.
• HTTP/1.1에서 도입되었지만, Head-of-Line Blocking과 서버 지원 부족 등의 문제로 인해 널리 사용되지는 않았습니다.
• HTTP/2의 멀티플렉싱은 파이프라이닝의 문제를 해결하고, 요청과 응답을 동시에 처리할 수 있어 더 나은 성능을 제공합니다.

결론적으로, 파이프라이닝은 HTTP/1.1에서 효율성을 높이기 위해 고안된 기술이지만, HTTP/2의 멀티플렉싱으로 대체되면서 그 사용이 줄어들고 있습니다.

 

---

 

 

HOL 블로킹 문제의 원인 (HTTP/1.1 파이프라인 처리)

HTTP/1.1에서 파이프라인 방식을 사용할 경우, 여러 요청을 한 번에 보낼 수는 있지만, 서버가 첫 번째 요청에 대한 응답을 완료하기 전까지 그 뒤의 요청들은 대기해야 합니다. 즉, 앞선 요청이 지연되면 뒤에 있는 요청들도 차례로 지연됩니다. 이로 인해 Head-of-Line Blocking 문제가 발생합니다.

• 시퀀스 번호의 꼬임: TCP 연결에서는 각 패킷이 시퀀스 번호를 가지고 전송됩니다. 파이프라인에서 앞선 요청이나 패킷이 지연되면, 시퀀스가 맞지 않게 되어 뒤에 있는 패킷도 처리되지 못하는 상황이 발생합니다. 이런 HOL 블로킹 문제는 성능 저하와 함께 대기 시간이 길어지는 문제를 유발합니다.

HOL 블로킹 문제 해결책: HTTP/2의 멀티플렉싱 (Multiplexing)

이 문제를 해결하기 위해 등장한 기술이 HTTP/2의 **멀티플렉싱(Multiplexing)**입니다. 멀티플렉싱은 여러 요청을 하나의 연결 안에서 동시에 처리하는 기술로, 각각의 요청이 독립적으로 처리되기 때문에 특정 요청이 지연되더라도 다른 요청들이 영향을 받지 않습니다.

• 멀티플렉싱 동작 방식:
  • HTTP/2는 요청과 응답을 프레임 단위로 나누어 처리합니다. 이를 통해 여러 요청이 하나의 연결을 통해 동시에 전송되고, 서버는 이러한 프레임들을 비순차적으로 처리한 후 다시 클라이언트로 응답을 보냅니다.
  • 요청 간에 의존성이 없어지기 때문에, 특정 요청이 느려지더라도 나머지 요청은 독립적으로 처리될 수 있어 HOL 블로킹 문제가 해결됩니다.

서버 측에서 일어나는 멀티플렉싱, 클라이언트는 별도 처리 없음

멀티플렉싱은 서버 측에서 주로 발생하는 처리 방식입니다. 서버는 다수의 요청을 비순차적으로 처리하고 응답을 관리하지만, 클라이언트 측에서는 별도의 복잡한 처리가 필요하지 않습니다. 클라이언트는 여전히 단일 연결을 사용하며, 서버가 각 요청을 적절하게 스케줄링하여 처리한 후 결과를 받아볼 수 있습니다.

스케줄링과 성능 최적화

HTTP/2의 멀티플렉싱이 적용되면 서버는 각 요청의 우선순위를 바탕으로 스케줄링하여 요청을 처리합니다. 이를 통해 성능이 최적화되며, 네트워크 혼잡이나 지연 상황에서도 전체적인 응답 시간이 개선됩니다.

요약

1. **Head-of-Line Blocking(HOL 블로킹)**은 파이프라인 방식에서 앞선 요청이 지연되면 뒤의 요청들이 차례로 지연되는 문제.
2. HTTP/1.1 파이프라인에서 시퀀스 번호가 꼬이는 문제와 함께 성능 저하를 유발.
3. HTTP/2는 **멀티플렉싱(Multiplexing)**을 도입하여 HOL 블로킹 문제를 해결. 여러 요청을 독립적으로 처리하고, 서버에서 요청 스케줄링을 통해 성능 최적화.
4. 멀티플렉싱은 주로 서버 측에서 처리되며, 클라이언트는 별도의 복잡한 처리를 하지 않아도 됩니다.