Похожие вопросы

Minecraft для Windows 10 не удается подключиться к локальному серверу в локальной сети
Два сетевых диапазона, один шлюз - двойная проблема NAT
Как настроить сеть для Ubuntu на virtualbox (win server 2008 R2)
Питание через Ethernet для Cisco EPC3928
Как сохранить конфигурацию "systemd-resolve" для конкретного сетевого интерфейса?
DNS не настроен должным образом в Debian Linux?
Создать локальное TCP соединение из программы C в Ubuntu VM в Labview в Windows (Host)
Как автоматически переподключиться к openvpn при повторном подключении к Wi-Fi на терминале Linux?
Возможно ли последовательное подключение сетевых адаптеров Powerline?
Мониторинг сетевого трафика через коммутатор
Apache httpd простой метод для возврата удаленного адреса
Шифрует ли Socks v5 весь трафик?
Как решить: сетевой драйвер Intel не будет установлен? "не поддерживается сетевое подключение", Windows 10, Dell Latitude E6420
Не удается проверить связь между двумя гостевыми ОС в Virtualbox
пинг с использованием локального lookback IP

MTU, RWIN и MSS

Я делал некоторое чтение в TCP окно приема (RWIN), максимальный размер сегмента (MSS) и максимальный блок передачи (MTU). Сразу у меня есть несколько вопросов и мне нужна помощь пользователя!

следующие вопросы основаны на моем использовании Wireshark с клиентом Win7 для просмотра кадров в потоке TCP:

  1. где вы смотрите (в потоке TCP), чтобы найти RWIN в использовании? Это SYN, SYN-ACK или ACK? У меня сложилось впечатление, что SYN пакет из 3-х этапное рукопожатие.
  2. что говорит удаленная машина по "значению размера окна" 16425 и "вычисленному размеру окна" 65700 (Wireshark указывает коэффициент масштабирования 4, т. е. 16425 * 4 = 65700) в пакете ACK?
  3. какая машина диктует значение RWIN, используемое во время передачи-клиент или удаленный компьютер?
  4. в соответствии с окончанием TCP-подключения есть FIN-ACK, который указывает, что удаленная машина хочет завершить соединение затем следует ACK от клиента, а затем RST-ACK снова клиентом, таким образом закрывающим соединение. Имеет ли значение RWIN в пакетах FIN-ACK и ACK во время этого процесса завершения какое-либо значение, потому что они очень отличаются от значений RWIN, заявленных в трехстороннем квитировании?

У меня есть еще несколько вопросов, но ответ здесь может иметь отношение к ним, так что я буду ждать некоторых ответов в первую очередь:)

спасибо.
QF

5
источник

1 ответов

OK...сначала легкие детали.

MTU-максимальный блок передачи на сетевом канале. В принципе, это определяет, насколько большой пакет, который может обрабатывать соединение локальной сети...это - "Уровень 2" Размер (обычно Ethernet), таким образом IP, TCP, UDP и другие заголовки считают против этого значения. Довольно простой.

MSS-максимальный размер сегмента. Это-значение TCP, которое передается в пакетах SYN (и SYN и SYN/ACK). Он определяет объем данных, которые могут содержаться в сегменте TCP. Это элемент уровня TCP, поэтому, если IP-пакет фрагментируется при передаче, MSS ссылается на объем данных в сегменте TCP повторно собранного пакета. Немного менее прямолинейно, но все же довольно легко понять.

теперь все усложняется.

RWIN-окно приема TCP. Это значение, заданное на стороне получателя TCP-подключения в поле "размер окна" заголовка TCP. Окно постоянно регулирует свой размер в продолжительности TCP-подключения. Существует окно для каждого направления TCP-соединения. Конечные точки TCP не будут полностью синхронизированы друг с другом относительно того, каков текущий размер окна направления TCP-соединения на время TCP-соединения.

OK, поэтому помните, что TCP представляет собой байт-поток данных. Конечная точка будет иметь буфер памяти в ОС для получения данных TCP соединения. Этот буфер представлен (по крайней мере условно) окном Размер. По мере того как данные помещаются в буфер, размер окна будет уменьшаться, а по мере считывания данных из буфера приложением размер окна будет увеличиваться.

передающая сторона TCP-соединения не будет передавать больше данных, чем размер окна, пока не получит пакеты подтверждения, увеличивающие размер окна.


OK...немного глубже, вот здесь...

рассмотрим гипотетическую одностороннюю передачу данных с размером буфера в приемнике 10 байт. В начале соединения, размер окна будет 10.

отправитель отправляет сегмент с 5 байтами данных. Отправитель теперь думает, что окно имеет размер 5 байт (его все еще удерживает эти 5 отправленных байт в случае, если ему нужно повторно передать их, пока для них не будет получено подтверждение). Получатель еще не получил пакет, поэтому он все еще думает, что его размер окна составляет 10 байтов.

затем отправитель отправляет сегмент с 3 байты данных в нем. Отправитель считает окне теперь 2 байта (10 - 5 = 5, 5 - 3 = 2). Получатель все еще не получил пакетов, таким образом, он все еще думает, что размер окна 10. Отправитель теперь удерживает 8 байт данных для возможной повторной передачи.

получатель получает первый сегмент, сохраняет данные в буфер и отправляет подтверждение. Важно отметить, что ОС получила данные и подтверждает их получение, но приложение по-прежнему не хватает данных. Подтверждение будет иметь ACK 5 (относительно начальных порядковых номеров, которые были выбраны) и размер окна 5 (потому что данные все еще сидят в буфере, принимающем 5 байтов 10-байтового буфера).

отправитель получает подтверждение 5 байт, поэтому он может бросить первые 5 байт, которые он держал для повторной передачи, потому что он знает, что они успешно достигли получателя. Свое все еще держа на остальные 3 байта из второго сегмента, хотя, потому что они еще не были подтверждены. Отправитель видит, что размер окна, отправленного получателем, равен 5, но представляет собой 5 байт от номера подтверждения. Отправитель знает, что он уже отправил еще 3 байта, для которых он не получил подтверждения, поэтому он по-прежнему считает, что размер окна составляет 2 байта.

отправитель отправляет сегмент с 2 байтами данных. Теперь он видит нулевое окно TCP, что означает невозможно отправить больше данных, пока получатель не откроет окно. Отправитель снова удерживает 5 байт данных для возможной повторной передачи (3 из второго сегмента и 2 из третьего сегмента).

получатель получает второй сегмент размером 3 байта. Теперь в буфере содержится 8 байт данных. Он отправляет пакет подтверждения с номером подтверждения 8 (относительно начального порядкового номера) и размером окна 2. Эти 8 байт данные все еще находятся в буфере ОС.

теперь, приложение считывает 7 байт данных из буфера. Буфер теперь имеет 1 байт данных. Общий размер окна был 10, но с одним байтом данных в нем, что оставляет 9 байт, что приемник посылает пакет с номером подтверждения 8 (ибо никаких новых данных не поступало), но размер окна теперь 9 (против 2 это было ранее). Это-способ, которым окно выращивается так, отправитель может передать больше данные.

отправитель получает ACK из 8 байт с размером окна 2. Отправитель может бросить 3 байта данных из 2-го сегмента, но он уже отправил еще 2 байта, а размер окна в этом пакете равен 2, поэтому отправитель по-прежнему видит окно нулевого размера и больше не может отправлять данные.

получатель получает 3-й сегмент с 2 байтами в нем. Помещает 2 байта в буфер, оставляя 7 байтов свободными. Its передает пакет с ACK 10 (5 + 3 + 2), и a размер окна 7.

отправитель получает ACK с номером подтверждения 8 и размером окна 9. Он уже отправил всего 10 байт, поэтому он все еще видит два байта, поэтому он видит размер окна 7 (9 - 2).

отправитель имеет только 5 байт для отправки. Что полностью вписывается в размер окна, поэтому он отправляет 5 байт. Теперь он видит окно размером 2, но это не имеет значения, потому что у него больше нет данных для отправки. Он теперь держит на 7 байт данных для потенциальной ретрансляции.

отправитель получает ACK с номером подтверждения 10 и размером окна 7. Он бросает 2 байта из 3-го сегмента, все еще имеет 5 байтов, которые он держит для потенциальной повторной передачи.

получатель получает 4-й сегмент с 5 байтами данных, добавляет эти данные в свой буфер (не содержащий 8 байт), отправляет ACK с номером подтверждения 15 и размером окна 2.

приложение считывает 8 байт сидит в буфере, буфер пуст. Получатель передает ACK с номером подтверждения 15 и размером окна назад в полных 10.

отправитель получает ACK с номером подтверждения 15 и размером окна 2. Теперь он может бросить последнюю из данных, которые он держался за потенциальной ретрансляции. Он знает, что все его данные попали в приемник. Он действительно не заботится о размере окна 2, так как у него больше нет данных для отправки в любом случае.

отправитель получает последний ACK с номером подтверждения 15 и размером окна 10.


ОК, это все гипотетически...надеюсь, это поможет вам понять, как работает окно приема и обрабатывается обеими сторонами. То же самое происходит с помощью порядковых номеров, номера подтверждения и размер окна для любых данных на TCP-соединение.

значения RWIN в пакетах с битами FIN должно иметь такое же значение. Можете ли вы привести пример того, что вы видите в wireshark, чтобы мы могли помочь их интерпретировать?

3
отвечен Jeff McAdams 2013-05-06 15:21:02
источник

Другие вопросы networking performance performance-tuning tcp windows-7