A configuração TCP_NODELAY e a combinação de algumas mensagens em uma única mensagem fizeram o truque, as mensagens eram muito pequenas.
Eu tenho 2 máquinas em uma LAN de 100 Gb / s que se comunicam através do TCP.
Quando eu faço um tracert ou um ping do cliente para o servidor, mesmo um ping grande, recebo uma resposta em menos de 1 ms .
No entanto, quando estou cheirando os pacotes TCP no lado do cliente, vejo que 40ms passam entre o tempo que envia a primeira mensagem do handshake de 3 vias, até o momento em que recebe a resposta de o servidor.
O servidor é dedicado a este cliente e não lida com mais nada.
Isso é razoável? Eu esperaria que fosse muito mais rápido.
Ping é normalmente tratado internamente pela pilha TCP, mas o handshake precisa ser manipulado pelo aplicativo. O sistema operacional tem que
1) wake up the application,
2) wait for it to retrieve the packet,
3) do any pre-processing required when starting a new connection then
4) tell the OS to continue with the handshake.
A parte 3 acima pode levar uma quantidade significativa de tempo (é por isso que muitos servidores pré-fork). Em que tipo de tráfego de rede você está vendo os longos RTTs de handshake? O RTT melhora após o aperto de mão?
C.
O que você quer dizer quando fala em ping grande? Pacote grande? Em qualquer caso, o ping usa pacotes ICMP , que geralmente são pequenos e com alta prioridade. Então, um caso é verificar suas configurações.
Outra coisa é tentar um não-icmp ping , como o tcpping . Ele usa pacotes TCP syn, então será o mesmo.
Tags networking latency tcp