Durante o handshake de três vias, o remetente (10.16.0.128) e o destinatário (10.16.0.5) anunciaram o tamanho da janela de 42.340 e 65.535, respectivamente.
Do terceiro pacote (syn+ack+ack) em diante, o remetente anunciou novamente o tamanho da viúva como 166, enquanto o receptor anunciou 512.
Você pode me informar por que o tamanho da janela foi reduzido sem enviar nenhum segmento? Ele continua mudando a cada confirmação? Por que eles não comprometeram o tamanho da janela durante as negociações.
10.16.0.128.59570 > 10.16.0.5.22: Flags [S], cksum 0x7da0 (incorrect -> 0xf0a5), seq 2355031382, win 42340, options [mss 1460,sackOK,TS val 4284732064 ecr 0,nop,wscale 8], length 0
09:50:58.661172 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
10.16.0.5.22 > 10.16.0.128.59570: Flags [S.], cksum 0x2d67 (correct), seq 1148159519, ack 2355031383, win 65535, options [mss 1460,sackOK,TS val 216174882 ecr 4284732064,nop,wscale 7], length 0
09:50:58.661229 IP (tos 0x0, ttl 64, id 49621, offset 0, flags [DF], proto TCP (6), length 52)
10.16.0.128.59570 > 10.16.0.5.22: Flags [.], cksum 0x7d98 (incorrect -> 0x5b8c), seq 1, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 0
09:50:58.661455 IP (tos 0x0, ttl 64, id 49622, offset 0, flags [DF], proto TCP (6), length 98)
10.16.0.128.59570 > 10.16.0.5.22: Flags [P.], cksum 0x7dc6 (incorrect -> 0x5b5f), seq 1:47, ack 1, win 166, options [nop,nop,TS val 4284732065 ecr 216174882], length 46
09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0
09:50:58.661543 IP (tos 0x0, ttl 64, id 8746, offset 0, flags [DF], proto TCP (6), length 52)
10.16.0.5.22 > 10.16.0.128.59570: Flags [.], cksum 0x5a03 (correct), seq 1, ack 47, win 512, options [nop,nop,TS val 216174883 ecr 4284732065], length 0```
Durante SYN/SYN+ACK, um tamanho de janela é fornecido. Além disso, o fator de escala de janela ( também conhecido como escala de janela, que é o
wscaleda captura do OP) é transmitido para toda a instância TCP, como uma opção TCP válida apenas para pacotes SYN (SYN ou SYN/ACK) conforme escrito em RFC 7323 :A escala da janela é a única parte que será fixa (um valor em cada direção) posteriormente, caso seja realmente negociada, pois é uma opção . Como inicialmente o sistema não pode saber se tal negociação terá sucesso, ou seja: se o lado peer suporta o dimensionamento de janela e também enviará esta opção em seu SYN/ACK, ele enviará um tamanho de janela provisório "normal". Após a negociação, o tamanho inicial da janela normalmente será dividido pelo fator de escala para permanecer praticamente o mesmo.
Portanto, o remetente informa inicialmente que pode suportar até 42.340 bytes e, se a negociação for bem-sucedida, posteriormente esse tamanho de janela será fornecido como pedaços de 2 ^ 8 = 256. Observe como roundup (42340 / 2 ^ 8) = 166: o próximo valor visível .
O respondente informa que pode suportar até 65535 (o máximo sem dimensionamento de janela) e, se negociado, usará blocos posteriores de 2 ^ 7 = 128 bytes. Observe novamente como roundup(65535/2^7) = 512, novamente o próximo valor visível.
O tamanho da janela não foi realmente alterado. Ainda pode mudar posteriormente devido a outros fatores, como a disposição de um aplicativo em aceitar mais dados, mas não foi isso que aconteceu aqui. Aqui o tamanho quase não mudou, apenas foi enviado "redimensionado" pelo uso da escala da janela.
Para esclarecer este caso e abordar o comentário adicional:
Para cada segmento TCP subsequente, o valor da janela no segmento deve ser multiplicado por 2^wscale para obter o valor real da janela. Nesta conexão TCP, o peer remetente usa wscale=8 e o peer respondedor usa wscale=7 (esses dois valores não mudarão durante a vida desta conexão).
Se o respondente usasse o win 599, isso significaria aceitar um tamanho de janela real de 599*2^7=76672.