[GTER] RES: Dúvida TCP ZeroWindow

[Rafael M. Koike]

Depois informa o resultado ;-)



-----Mensagem original-----
De: gter-bounces at eng.registro.br [mailto:gter-bounces at eng.registro.br] Em
nome de Plínio Monteiro Brandão
Enviada em: quinta-feira, 11 de novembro de 2010 14:26
Para: Rafael M. Koike
Cc: gter at eng.registro.br
Assunto: Re: [GTER] Dúvida TCP ZeroWindow

Obrigado pessoal.
--
Plínio M. Brandão
+55 51 8174.5074
+55 82 9993.5583


Em 10 de novembro de 2010 21:57, Rafael M. Koike
<r.koike at terra.com.br>escreveu:

> 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
>
>
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter