[GTER] Dúvida TCP ZeroWindow

[Rafael M. Koike]

 Foi o IP 192.168.45.182 quem enviou ZeroWindow para 192.168.63.6.
Neste caso o cliente é quem está falando para o servidor parar de
enviar que o buffer já encheu.
 On Seg 08/11/10 12:35 , Plínio Monteiro Brandão
pliniomonteiro at gmail.com sent:
  Obrigado Rafael,
 Mais uma dúvida.
 No exemplo citado usamos como referência a linha:
 98413 16:55:40.664694 192.168.45.182 192.168.63.6 TCP [TCP
ZeroWindow] 8790
 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165
 Só que o cliente é o 192.168.45.182 e o receptor (server) é o
192.168.63.6.
 Nesse caso sua explicação permanece a mesma?
 Porque no meu entendimento, o Win=0 é que a janela de recebimento
do
 receptor (192.168.63.6) está zerada, não podendo mais receber, já
que o
 cliente envia baseado na janela de recebimento do servidor (conforme
figura
 http://www.tcpipguide.com/free/diagrams/tcpswflow.png [1]). Seria
isso ou estou
 confundindo?
 --
 Plínio M. Brandão
 +55 51 8174.5074
 +55 82 9993.5583
 Em 8 de novembro de 2010 12:26, Rafael M. Koike escreveu:
 > Plinio,
 >
 > O TCP trabalha com MTU (Maximum Transfer Unit) Unidade Maxima de
 > Transferencia que é quantos bytes um unico cabeçalho TCP
transporta
 > (Geralemente configurado para 1500) mas normalmente transporta
menos.
 > E o TCP Window que é no protocolo TCP que é orientado a conexão
e
 > estabelece um hand-shake para iniciar a transmissão precisa a
cada X pacotes
 > TCP enviar uma confirmação de que aquela sequencia foi enviada
corretamente
 > e que o transmissor pode enviar a proxima sequencia de pacotes TCP
 > É uma definição de quantos bytes podem ser enviados até que o
receptor
 > envie um ACK (Acknowledge) ao transmissor par que ele contine
enviando.
 > O Window é utilizado para que a comunicação não fique
sobrecarregada de
 > ACKs a cada envio de pacote TCP (Ou seja, a cada pacote de 1500
bytes o
 > receptor envia um ACK falando que pode continuar transmitindo)
 > Dai em meios de transmissoes confiaveis voce pode definir TCP
Windows de
 > alguns KBytes ou MBytes) e com isso voce tem um overhead bem
menor.
 > No caso de um pacote do receptor para o emissor com flag Zero
Window, o
 > receptor está dizendo: Ei!, pare de enviar dados pois não tenho
 > buffer/memória para processá-los na velocidade que voce está
enviando!
 > E isto provavelmente quer dizer que apesar do transmisor e
receptor ter
 > negociado uma janela X de dados até o ACK o receptor não está
dando conta do
 > recado e não está processando dados rapido o suficiente.
 > Talvez seja devido a uma conexão gigabit muito rápida para um
servidor
 > "parrudo" enviando dados e um desktop ou servidor pequeno
recebendo.
 > Neste caso um tunning do TCP Window ou uma revisada no hardware do
receptor
 > devem resolver o problema
 >
 >
 >
 >
 >
 > *On Seg 08/11/10 10:23 , Plínio Monteiro Brandão
pliniomonteiro at gmail.comsent [3]:
 > *
 >
 > Pessoal,
 >
 > Estou com uma dúvida relacionada a Flag TCP ZeroWindow que
aparece no
 > Wireshark. O ambiente que estou vivenciando no momento é o
seguinte:
 >
 > Cliente: 192.168.45.182
 > Servidor: 192.168.45.178
 >
 > De acordo com o capture realizado aparece a seguinte linha:
 >
 > 98412 16:55:40.664670 192.168.45.182 -> 192.168.45.178 TCP [TCP
ZeroWindow]
 >
 > > 8790 > 9112 [PSH, ACK] Seq=109502 Ack=136365 Win=0 Len=165
 >
 > >
 >
 >
 > Entretanto, estamos com dúvida em relação a saída do Campo
*WIN* no
 > Wireshark. A primeira impressão é que a saída está relacionada
a Window do
 > source (192.168.45.182), mas de acordo co o TCPGUIDE, essa window
estaria
 > relacionada com o tamanho da window do servidor (192.168.45.178).
Segue o
 > texto e o link que foi usado como referência:
 >
 >
http://www.tcpipguide.com/free/t_TCPWindowSizeAdjustmentandFlowControl.htm
[4]
 >
 > We have seen the importance of the concept of *window size* to
TCP's
 > sliding
 >
 > > window mechanism. In a connection between a client and a server,
the
 > client
 >
 > > tells the server the number of bytes it is willing to receive at
one time
 >
 > > from the server; this is the client's *receive window*, which
becomes the
 >
 > > server's *send window*. Likewise, the server tells the client
how many
 >
 > > bytes of data it is willing to take from the client at one time;
this is
 > the
 >
 > > server's *receive window* and the client's *send window*.
 >
 > >
 >
 >
 > http://www.tcpipguide.com/free/diagrams/tcpswflow.png [6]
 >
 > Vocês já passaram por alguma situação desse tipo? Alguém pode
ajudar na
 > interpretação dessa saída e no conceito do TCP?
 >
 > Desde já agradeço.
 >
 > --
 > Plínio M. Brandão
 > +55 51 8174.5074
 > +55 82 9993.5583
 > --
 > gter list https://eng.registro.br/mailman/listinfo/gter [8]
 >
 >
 >
 --
 gter list https://eng.registro.br/mailman/listinfo/gter [10]