[GTER] Dúvida TCP ZeroWindow

[Cristiano Monteiro]

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
>