![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Кэп порадовался бы
Dec. 19th, 2011 12:14 pm$ file .git/index
.git/index: Git index, version 2, 23 entries
$
.git/index: Git index, version 2, 23 entries
$
Dec. 19th, 2011
TCP Window Scale Option
Dec. 19th, 2011 03:58 pmRFC1323. Начиная с Windows Vista по умолчанию сабж включен и может приводить к плавающим проблемам при скачивании больших файлов, отправке по SMTP писем большого размера и т.п., если трафик проходит через роутеры и межсетевые экраны, не поддерживающие сабж. Например с CBAC от IOS 12.2 проблема точно присутствует.
Отключается:
netsh interface tcp set global autotuninglevel=disabled
UPD вернуть значение по умолчанию
netsh interface tcp set global autotuninglevel=normal
Возможная причина (источник)
The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.
Отключается:
netsh interface tcp set global autotuninglevel=disabled
UPD вернуть значение по умолчанию
netsh interface tcp set global autotuninglevel=normal
Возможная причина (источник)
The details are still being figured out, but it would appear that some routers on the net are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.