[GTER] RES: Dúvida TCP ZeroWindow

Rafael M. Koike r.koike at terra.com.br
Wed Nov 10 21:57:46 -02 2010


Ops!

 

Obriado pela correção ;-)

Na hora que estava respondendo me confundi.

 

 

De: Cristiano Monteiro [mailto:crmonteir at gmail.com] 
Enviada em: terça-feira, 9 de novembro de 2010 09:56
Para: r.koike at terra.com.br
Cc: "Plínio Monteiro Brandão"; gter at eng.registro.br
Assunto: Re: [GTER] Dúvida TCP ZeroWindow

 

Olá Plínio,

 

Em uma comunicação TCP há dois tipos de janelas ( send window e receive
window). do ponto e vista do cliente a receive window seria quantos dados o
cliente pode receber antes de enviar um ack. A send window seira a
quantidade de dados que ele poderia pra enviar para o servidor sem
necessidade de receber um ACK. No seu caso trata-se de um receive window que
está com o valor de zero, isto geralmente indica que o servidor envia mais
dados que o cliente pode processar. 

 

Já vi isso acontecer por motivos  de mismatch no duplex mode.

 

 

Cristiano Monteiro

 

PS: By the way o TCP trabalha como o MSS (Maximum Segment Size) e não MTU, o
MTU é mais embaixo :)

 

 

 

 

Em 8 de novembro de 2010 12:26, Rafael M. Koike <r.koike at terra.com.br>
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.com sent:

 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

[1]

 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 [2]

 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 [3]

--
gter list    https://eng.registro.br/mailman/listinfo/gter

 




More information about the gter mailing list