Мне посоветовали этот сайт, когда я изначально задавал вопрос в Networking SE.
У меня есть несколько вопросов о rwnd объявлениях в TCP. Я прочитал RFC, но так и остался с мыслями без ответа (или, может быть, я что-то упустил). Возможно, некоторые ответы зависят от реализации - в этом случае, пожалуйста, ответьте, используя свой опыт, поскольку я хочу знать, что происходит в общем случае.
Стандарт TCP гласит следующее:
Отправляющий TCP должен быть готов принять от пользователя и отправить по крайней мере один октет новых данных, даже если окно отправки равно нулю.
Я предполагаю, что причина этого в том, что сообщения зонда окна содержат один октет данных. Однако это заставило меня задуматься:
Я не видел, чтобы в стандарте говорилось, что пакеты зондирования должны содержать один октет новых данных. Существуют ли другие способы зондирования размера окна?
Если это единственный способ, интересно, почему повторная отправка старого сегмента (со старым порядковым номером) не будет достаточной? Должен ли получатель подтверждать только те данные, которые находятся в пределах окна в определенный момент (то есть старые данные не обязательно будут подтверждены), то есть мы должны рассматривать зондирующие пакеты как исключение из этого правила?
Вообще говоря, уведомляет ли получатель отправителя, когда его окно увеличивается в размерах? Должен ли он это делать (я понимаю, что подтверждение может быть потеряно, поэтому отправителю, возможно, придется в любом случае провести проверку)?
Отправляются ли пробные пакеты только тогда, когда это
window = 0необходимо, или их можно отправить и раньше?
решение1
Я предполагаю, что причина этого в том, что сообщения оконного зонда содержат один октет данных.
Просто для ясности: не существует специального формата пакета, заголовка или другого идентификатора для пакета проверки окна. TCP просто отправляет стандартный пакет TCP, когда ему нужно проверить окно. Он просто ограничивает данные пользователя/приложения в этом пакете TCP одним октетом.
- Я не видел в стандарте указания на то, что пакеты зондов должны содержать один октет новых данных.
Вы только что процитировали утверждение в стандарте, что пакеты зондирования должны содержать по крайней мере один октет новых данных, не так ли? Если вам нужны дополнительные утверждения, вы найдете утверждения в RFC 793 и RFC 1122, напоминающие вам, что подтверждения без новых данных приложения не транспортируются надежно (подразумевая, что вы должны передать некоторые новые данные, чтобы узнать, были ли они доставлены).
Существуют ли другие способы определения размера окна?
Можно предположить, что авторы стандарта TCP могли придумать и другие способы, но процитированный вами способ — единственный, который они предусмотрели в стандарте.
- Если это единственный способ, то мне интересно, почему повторная отправка старого сегмента (со старым порядковым номером) не будет достаточной?
Вопрос не в том, достаточно ли этого, а в том, какой способ лучше. Если у вас нет дополнительных данных для отправки, вам не нужно проверять окно. Если выделатьесть дополнительные данные для отправки, почему бы не использоватьчтодля проверки окна, а не тратить полосу пропускания на ранее отправленные (и предположительно подтвержденные) данные?
Должен ли получатель подтверждать только те данные, которые находятся в пределах окна в определенный момент (то есть старые данные не обязательно будут подтверждены)?
Получатель должен подтверждать только последние полученные данные, которые являются смежными со всеми данными, полученными с самого начала (под смежными я подразумеваю, что если у него есть дыра из-за того, что он пропустил один или несколько пакетов, но получил более поздний пакет, он не может подтвердить этот более поздний пакет; он должен продолжать подтверждать последний порядковый номер перед первой дырой).
- Вообще говоря, уведомляет ли получатель отправителя, когда его окно увеличивается в размерах?
Да, вообще говоря, получатель уведомляет отправителя об обновлениях размера окна с каждым подтверждением.
Также в разделе «Предложения по управлению окнами» на стр. 43 RFC 793 авторы предлагают, чтобы TCP-приемники «отправляли еще одно подтверждение с новой информацией об окне, когда окно больше». Этот RFC предшествовал RFC 2119, который определил стандарты терминологии MAY/SHOULD/MUST, но это предложение, похоже, будет считаться SHOULD в соответствии с требованиями RFC 2119.
Нужно ли это делать (я понимаю, что подтверждение может быть потеряно, поэтому отправителю в любом случае придется провести проверку)?
Я не знаю ни одного документа RFC, обновляющего RFC 793, который бы сделал такое поведение ОБЯЗАТЕЛЬНЫМ.
Отправляются ли тестовые пакеты только при окне = 0 или их можно отправлять и раньше?
Если бы окно не было равно нулю, то сегмент TCP с одним байтом данных на самом деле не считался бы зондом. Например, если бы у меня было соединение telnet, которое отправляло отдельные нажатия клавиш на удаленный хост, каждое нажатие клавиши могло бы быть отправлено как сегмент TCP с одним байтом данных. Их можно отправлять в случае, подобном telnet, даже если окно больше 0 или 1, но они не будут считаться зондами.
решение2
Это основано наОтвет Спифф, но с большим количеством дополнений, чем влезет в комментарий. Обратите внимание, что в августе 2022 г.RFC9293наконец-то заменила исходную спецификацию TCP и включает в себя весь язык ДОЛЖЕН/СЛЕДУЕТ/МОЖЕТ.
В1. Я не видел в стандарте указания на то, что пакеты зондирования должны содержать один октет новых данных.
Следующее требование, которое не ограничивалось одним октетом, было в исходной спецификации TCPRFC793и был дословно скопирован в RFC9293:
When the receiving TCP peer has a zero window and a segment arrives, it must
still send an acknowledgment showing its next expected sequence number
and current window (zero).
В2. Интересно, почему повторная отправка старого сегмента... недостаточна?
Это не самый эффективный способ (если окно становится достаточно большим, октет все равно придется отбросить). Но это сработает, потому что спецификации контроля перегрузки TCP всегда говорят что-то вродеRFC5681теперь говорит:
A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-
order segment arrives.
В3. Вообще говоря, уведомляет ли получатель отправителя, когда его окно увеличивается в размерах?
Я предполагаю, что вы имеете в виду, что окно получателя увеличивается, потому что принимающее приложение потребляет некоторые данные из буфера приема. Тогда, я полагаю, в спецификациях нет требования отправлять ACK для уведомления об этом. Отсюда и необходимость в зонде окна, чтобы вызвать ACK.
В4. Отправляются ли пакеты зондирования только при окне = 0?
Да, по определению. Потому что если бы пакет размером в один октет был отправлен до того, как window = 0, это был бы просто обычный пакет, который оказался размером в один октет.