Tanto quanto eu sei, tcp demora ack sempre 200ms, mas agora no meu ambiente de produção demora quase 600ms, o meu ambiente está abaixo: ubuntu 11.04 48G de memória 16 core, carga não pesada; Eu pegar pacote no servidor (6380 é porta do servidor), o pacote está abaixo, como podemos ver na hora 16: 29: 24.036999 o servidor receber um pacote do cliente, mas o não responder ack até 16: 29: 24.634244, duram quase 600ms, e o timeout do cliente é de 500ms, então fecha a conexão.
600ms+ delay ack packet
16:29:12.458770 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11504, win 1107, length 0
16:29:15.070423 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9756:9790, ack 11504, win 1107, length 34
16:29:15.070497 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11504:11514, ack 9790, win 848, length 10
16:29:15.070568 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11514, win 1107, length 0
16:29:16.951893 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9790:9842, ack 11514, win 1107, length 52
16:29:16.951983 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11514:11620, ack 9842, win 848, length 106
16:29:16.952100 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11620, win 1107, length 0
16:29:18.469622 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9842:9894, ack 11620, win 1107, length 52
16:29:18.469761 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11620:11721, ack 9894, win 848, length 101
16:29:18.469839 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11721, win 1107, length 0
16:29:20.202913 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 9894:10710, ack 11721, win 1107, length 816
16:29:20.203026 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11721:11726, ack 10710, win 863, length 5
16:29:20.203157 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11726, win 1107, length 0
16:29:21.893243 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10710:10744, ack 11726, win 1107, length 34
16:29:21.893354 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11726:11736, ack 10744, win 863, length 10
16:29:21.893487 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [.], ack 11736, win 1107, length 0
16:29:24.036999 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10744:10796, ack 11736, win 1107, length 52
16:29:24.240657 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [P.], seq 10744:10796, ack 11736, win 1107, length 52
16:29:24.536929 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [F.], seq 10796, ack 11736, win 1107, length 0
16:29:24.634244 IP 192.168.70.134.6380 > 192.168.60.71.22142: Flags [P.], seq 11736:12057, ack 10796, win 863, length 321
16:29:24.634410 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [F.], seq 10796, ack 11736, win 1107, length 0
16:29:24.634470 IP 192.168.60.71.22142 > 192.168.70.134.6380: Flags [R], seq 554218496, win 0, length 0
800ms delay ack packet
16:37:01.921951 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40135:40187, ack 42430, win 1081, length 52
16:37:01.922029 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [P.], seq 42430:42655, ack 40187, win 1345, length 225
16:37:01.922097 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [.], ack 42655, win 1081, length 0
16:37:04.569001 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:04.770636 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:05.069588 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [F.], seq 40239, ack 42655, win 1081, length 0
16:37:05.178638 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [P.], seq 40187:40239, ack 42655, win 1081, length 52
16:37:05.442263 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [P.], seq 42655:42832, ack 40239, win 1345, length 177
16:37:05.443329 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [.], ack 40239, win 1345, options [nop,nop,sack 1 {40187:40239}], length 0
16:37:05.443484 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [F.], seq 40239, ack 42655, win 1081, length 0
16:37:05.445463 IP 192.168.70.135.6380 > 192.168.60.72.23935: Flags [F.], seq 42832, ack 40240, win 1345, options [nop,nop,sack 1 {40239:40240}], length 0
16:37:05.448999 IP 192.168.60.72.23935 > 192.168.70.135.6380: Flags [R], seq 4279187611, win 0, length 0
A seção 4.2.3.2 da RFC 1122 especifica que um ACK pode ser atrasado em até 500 milissegundos:
A TCP SHOULD implement a delayed ACK, but an ACK should not be excessively delayed; in particular, the delay MUST be less than 0.5 seconds, and in a stream of full-sized segments there SHOULD be an ACK for at least every second segment.
Não há pressa para enviar um ACK. Algo é estranho aqui, porém, a retransmissão parece muito rápida.
Se você vir um pacote no tcpdump, ele apenas diz que o pacote chegou na máquina. Mas, o ACK só é criado pelo kernel se ele puder entregar o pacote no buffer de soquete do aplicativo. Isso pode falhar porque o pacote foi bloqueado pelo filtro de pacotes ou porque o sistema não tem memória suficiente, mas o caso mais provável é que o buffer de soquete do aplicativo esteja cheio porque ele recebeu uma grande quantidade de dados em pouco tempo e não capaz de processar todos eles ainda.
Neste caso, o pacote é perdido mesmo que tenha chegado ao sistema, pelo que não será gerado nenhum ACK e o pacote terá de ser retransmitido pelo remetente. Se o aplicativo estiver pronto e tiver espaço no buffer de soquete, ele poderá ser entregue agora, caso contrário, ele será perdido e, novamente, nenhum ACK será enviado.