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, чтобы мы могли помочь их интерпретировать?
Komp
2456
