창 크기가 충분할 때 ACK가 수신될 때까지 패킷이 전송되지 않는 이유

창 크기가 충분할 때 ACK가 수신될 때까지 패킷이 전송되지 않는 이유

고려 중인 애플리케이션(서버)에는 연결된 클라이언트가 많습니다. 클라이언트의 모든 메시지를 처리하고 두 개의 출력 메시지를 보냅니다. 출력 메시지는 순차적으로 생성되어 소켓에 기록됩니다. 나는 때때로 클라이언트의 두 번째 출력 메시지가 오랜 시간 동안 지연되는 것을 관찰했습니다. 이유를 이해하려고 노력 중입니다.

다음은 클라이언트에서 캡처한 애플리케이션과 클라이언트 간의 필터링된 TCP 흐름입니다.

여기에 이미지 설명을 입력하세요.

  1. 14908은 클라이언트가 입력한 메시지입니다. 14910 및 15337은 두 개의 출력 메시지입니다.
  2. 14910 지연이 없습니다. 하지만 15337은 약 40ms 정도 지연됩니다.
  3. 내가 볼 수 있듯이 15337 패킷은 ack 15336이 수신될 때까지 전송되지 않습니다.

소켓이 EWOULDBLOCK 또는 EAGAIN을 반환하지 않으면 애플리케이션은 패킷을 TCP 계층으로 보냅니다. #14908에 게시된 창이 1424이고 #15336(len=229)이 EWOULDBLOCK으로 전송되어서는 안 되기 때문에 소켓이 차단되지 않았다고 가정합니다.

그렇다면 TCP 계층이 승인 #15336까지 #15337 전송을 지연시키는 원인을 이해하도록 도와주실 수 있나요?

답변1

14908은 클라이언트가 입력한 메시지입니다. 14910 및 15337은 두 개의 출력 메시지입니다.

14910은 클라이언트에 대한 응답입니다. 분명히 PSH 플래그가 설정되어 있으므로 서버는 이를 즉시 보냅니다. 그런 다음 서버는 클라이언트로부터 ACK를 기다린 다음 15337을 보냅니다.

14910 지연이 없습니다. 하지만 15337은 약 40ms 정도 지연됩니다.

이는 ACK(15336)가 클라이언트에서 서버로 이동하고, 서버에서 이를 처리하고, 다음 패킷이 서버에서 클라이언트로 이동하는 데 걸리는 시간입니다.

내가 볼 수 있듯이 15337 패킷은 ack 15336이 수신될 때까지 전송되지 않습니다.

옳은. 이것이 일반적으로 TCP가 작동하는 방식입니다.

그렇다면 이러한 지연의 원인이 무엇인지 이해하도록 도와주실 수 있나요?

귀하는 확실한 답변을 제공할 수 있을 만큼 충분한 정보를 제공하지 않았습니다. 또한 캡처된 이미지가 아닌 필터링된 캡처 이미지를 제공함으로써 우리의 이해를 제한하고 있습니다.

패킷 15337과 패킷 15756 사이에는 거의 동일한 시간 차이가 있음을 알 수 있습니다(약간 더 짧음, 각각 39.87ms 및 39.93ms). 이 교환 간의 패킷 수 차이는 419인 반면, 첫 번째 교환의 패킷 수는 426입니다.

따라서 가장 좋은 추측은 이 "지연"이 클라이언트가 서버에 ACK를 보내는 것과 서버에서 도착하는 다음 패킷 사이에 많은 다른 트래픽을 보내고 받는 결과라는 것입니다.

패킷 캡처가 없고 다른 트래픽이 무엇인지 알려줄 수 없기 때문에 더 자세히 알려드릴 수 없습니다. 또한 클라이언트가 어떤 종류의 하드웨어에서 실행되고 있는지, 클라이언트에 얼마나 많은 부하가 걸릴지 알 수 없습니다. 그러나 이러한 모든 세부 사항은 이 웹사이트의 범위를 벗어납니다.

관련 정보