[네트워크] 전송 후 대기 프로토콜, 파이프라인 프로토콜

전송 후 대기 프로토콜이란

전송 후 대기 프로토콜은 데이터를 전송한 후 수신자로부터 확인(ACK)을 받을 때까지 대기하는 방식이다. 
이 프로토콜은 송신자가 한 개의 프레임을 전송하고, 수신자로부터 응답을 받을 때까지 기다리는 방식으로 동작한다. 수신자는 전송받은 프레임에 대해 확인(ACK) 또는 부정(NAK) 신호를 송신자에게 되돌려 보냅니다. 송신자는 ACK 신호를 받으면 다음 프레임을 전송하고, NAK 신호를 받으면 같은 프레임을 재선송한다.

1. 송신자는 수신자에게 패킷을 전송한다.

2. 그런 다음 송신자는 패킷이 성공적으로 수신되었음을 나타내는 수신자로부터의 승인(ACK)를 기다린다.

3. 승인을 받은 후에만 발신자는 다음 패킷 전송을 진행한다.

 

이 접근 방식은 안정적인 데이터 전송을 보장하는 데 도움이 되지만 특히 발신자와 수신자 사이에 상당한 왕복 시간이 있는 경우 속도가 느려지고 네트워크 링크 활용도가 낮아질 수 있다.

파이프라인 프로토콜이란

파이프라인 프로토콜은 요청에 대한 응답을 기다리지 않고, 다음 요청을 송신하는 기능이다. HTTP/1.0은 요청을 송신한 뒤, 그 응답을 기다린 뒤 다음 쵸엉을 송신하는 방식이었다. 하지만 이 방식으로는 많은 콘텐츠로 구성된 웹사이트를 볼 때, 시간이 오래 걸릴 수밖에 없다. 파이프라인을 이용하면 여러 리퀘스트를 계속 송신할 수 있게 되므로 콘텐츠가 표시될 때까지의 시간 단축을 기대할 수 있다.

 

하지만 현실에서는 파이프라인이 기대한 만큼 성과를 올리진 못했다. 왜냐하면 HTTP/1.1은 같은 TCP 커넥션 안에서 요청과 응답의 교환을 병렬 처리할 수 없는 사양이었기 때문에 서버는 요청을 받은 순서대로 응답을 반환해야만 했다. 이 제한은 파이프라인에 직접적인 영향르 미쳤다.

예를 들어, 클라이언트가 파이프라인으로 2개의 요청을 연속해서 송신했을 때, 서버가 최처의 요청을 처리하는 데 시간이 걸려 응답을 돌려주지 않으면 이어진 요청에 대한 응답도 반환되지 않는다. 또한, 서버의 버퍼도 쓸데없이 소비된다. 이 현상을 HoL 블로킹(Head of Lock Blocking)이라 부른다. HoL 블로킹이 원인이 되어, 크롬은 물론 파이어폭스에서도 파이프라인은 기본 비활성화되어 있다.

---

참고 자료

- https://velog.io/@cjy/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%8B%A0%EB%A2%B0%EC%A0%81-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%84%EC%86%A1%EC%9D%98-%EC%9B%90%EB%A6%AC