#tcp
#tcp
Вопрос:
Я собирал пакеты с помощью Wireshark на своем ноутбуке и обнаружил, что пакет, отправленный сервером, сжимает окно приема. Это соединение с моего ubuntu18.04 на «connectivity-check.ubuntu.com «.
Я прочитал rfc793 и TCPIP Иллюстрированный volumn1, оба говорят «настоятельно не рекомендуется сжимать окно».
Вот вывод Wireshark. Я отключаю HTTP-разбиение в Wireshark, чтобы предотвратить отвлечение.
4198 0.026547255 2019-04-03 12:27:48.870761715 192.168.3.141 35.222.85.5 TCP 74 53846 → 80 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=3960112411 TSecr=0 WS=128
4199 0.281380222 2019-04-03 12:27:49.152141937 35.222.85.5 192.168.3.141 TCP 74 80 → 53846 [SYN, ACK] Seq=0 Ack=1 Win=28160 Len=0 MSS=1412 SACK_PERM=1 TSval=2281826280 TSecr=3960112411 WS=128
4200 0.000092140 2019-04-03 12:27:49.152234077 192.168.3.141 35.222.85.5 TCP 66 53846 → 80 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=3960112693 TSecr=2281826280
4201 0.000191823 2019-04-03 12:27:49.152425900 192.168.3.141 35.222.85.5 TCP 153 53846 → 80 [PSH, ACK] Seq=1 Ack=1 Win=29312 Len=87 TSval=3960112693 TSecr=2281826280
4202 0.306769219 2019-04-03 12:27:49.459195119 35.222.85.5 192.168.3.141 TCP 66 80 → 53846 [ACK] Seq=1 Ack=88 Win=26112 Len=0 TSval=2281826585 TSecr=3960112693
4203 0.000076022 2019-04-03 12:27:49.459271141 35.222.85.5 192.168.3.141 TCP 214 80 → 53846 [PSH, ACK] Seq=1 Ack=88 Win=26112 Len=148 TSval=2281826586 TSecr=3960112693
4204 0.000028644 2019-04-03 12:27:49.459299785 192.168.3.141 35.222.85.5 TCP 66 53846 → 80 [ACK] Seq=88 Ack=149 Win=30336 Len=0 TSval=3960113000 TSecr=2281826586
4205 0.000045328 2019-04-03 12:27:49.459345113 35.222.85.5 192.168.3.141 TCP 66 80 → 53846 [FIN, ACK] Seq=149 Ack=88 Win=26112 Len=0 TSval=2281826586 TSecr=3960112693
4206 0.000183562 2019-04-03 12:27:49.459528675 192.168.3.141 35.222.85.5 TCP 66 53846 → 80 [FIN, ACK] Seq=88 Ack=150 Win=30336 Len=0 TSval=3960113000 TSecr=2281826586
4207 0.245163856 2019-04-03 12:27:49.704692531 35.222.85.5 192.168.3.141 TCP 66 80 → 53846 [ACK] Seq=150 Ack=89 Win=26112 Len=0 TSval=2281826890 TSecr=3960113000
Как показывает полученный результат, кадр 4199 с сервера рекламирует окно размером 28160, но после получения 87 байт данных в 4201 окно сжимается до 26112 в 4202, что в точности равно 2048 (это потому, что сервер просто заменяет страницу памяти?)
Я хочу знать, какие могут быть причины, по которым сервер сокращает окно приема TCP? Это крайне не рекомендуется RFC, я думал, что такое поведение не будет реализовано в стеке TCPIP в ОС.
Комментарии:
1. Это может быть параметр масштабирования окна, определенный в rfc1323. Я не читал его подробно.
2. нет, это не то, что означает масштабирование Windows.
3. ну, я бы предположил, что если масштабирование окна согласовано в течение 3 часов, окно может измениться после завершения 3 часов. Первое объявленное окно в syn / ack может быть не масштабировано, а затем масштабируется второе окно в 4201. То, что что-то не рекомендуется, не означает, что это не разрешено. IW10 является стандартным, но многие используют гораздо более высокий IW.
4. @FormerNcp Нет, это не то, как работает масштабирование окна. Как только масштабирование согласовано, все окна масштабируются. Этого достаточно для одного вопроса.
Ответ №1:
Это нормальное поведение. Когда Сервер получает данные в свой буфер и не может немедленно отправить их на прикладной уровень, он уменьшает объявленный размер окна, чтобы предотвратить удаление принятых пакетов. Вы путаете это ожидаемое поведение с проблемой сокращения окна, которая возникает, когда мы сдвигаем правый край буфера отправителя влево.
Вы можете обратиться к этому для получения дополнительных указаний по сокращению проблемы с окном:http://www.tcpipguide.com/free/t_TCPWindowManagementIssues.htm
Комментарии:
1. Спасибо за ответ :). Но меня не смущают эти два понятия. В захваченном результате, который я показал, размер окна уменьшен на «2048», но сервер получил только «87» байт данных. Итак, правый край переместился влево.
2. О … понятно.. Я неправильно истолковал вопрос. Похоже, вы правы, правый край сдвинут влево.