Опция заголовка TCP: согласование разрешенного SACK (выборочного подтверждения)

SACK был добавлен позже, поэтому существует необходимость в обратной совместимости, как для конечных хостов, так и для промежуточных ящиков (также см. Ниже). SACK-permitted Вариант выполняет только это.

SACK-permitted отправляется из А в В, чтобы указать, что А желает получать опции SACK. Для обработки SACK (как и для большинства обработок повторной передачи) TCP может рассматриваться как состоящий из двух симплексных соединений с различным состоянием каждое. Таким образом, совершенно законно (но редко) иметь SACK, перемещающийся только в одном направлении (обратном направлении SACK-permitted во время SYN или SYNACK).

Обычно вы можете оставить SACK включенным, так как это повышает производительность. Однако были (и, возможно, все еще есть) межсетевые экраны и блоки NAT, которые изменяют поля заголовка SEQ и ACK, но не знают о SACK и, таким образом, не адаптируют соответствующие порядковые номера в параметрах SACK. Это может привести к зависанию соединений (так как SACK подтвердил другой сегмент, который не был получен). По этой причине вы можете захотеть отключить SACK, даже если обе машины его поддерживают.

SACK можно отключить (для тестирования или при наличии вышеупомянутых некрасивых промежуточных ящиков) в системах *BSD (включая MacOS X), введя sysctl -w net.inet.tcp.sack=0 и включил, установив его обратно на 1. В Linux, sysctl -w net.ipv4.tcp_sack=0 достигает того же эффекта.

Первый абзац раздела 4 в RFC 2018 позволяет отправлять SACK, когда получено разрешение SACK. Обычно хост с поддержкой SACK объявляет о разрешении SACK. Я не могу представить себе полезного сценария, в котором хост с поддержкой SACK не будет объявлять разрешенный SACK, но будет использовать SACK (нереалистичным примером будет промежуточный ящик, плохо работающий с SACK только в одном направлении). Поэтому я не ожидаю, что SACK используется только в одном направлении.

Быстрый тест с Wireshark для Linux, MacOSX (возможно, обобщенный для *BSD) и принтера HP показывает, что они будут реагировать с разрешением SACK в SYNACK именно тогда, когда разрешение SACK было в SYN. Однако в RFC я не вижу ничего, что могло бы требовать или поощрять такое поведение.

Разрешение SACK может быть потеряно из-за потери пакетов (некоторые байты в заголовке TCP, которые были отправлены в сообщениях установления связи, отбрасываются). Возможно, это связано с тем, что PMTUD не работает должным образом с вашей стороны. Попробуйте вручную уменьшить размер MTU на своей стороне.

Это вопрос, который, если Ван Якобсен или его коллеги не будут зависать на этом форуме, скорее всего, повлечет за собой немало усилий со стороны тех, кто пытается ответить на него, как вы просили. Если вы подумаете об этом, уровень исследований, необходимых для ответа на ваш вопрос, будет таким же большим или большим, чем исследовательский проект, которым вы в настоящее время занимаетесь. Скорее всего, это поразит большинство людей, которым не хватает паритета.

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

В настоящее время у меня нет доступа с правами root в двух системах BSD-unix, но если бы я это сделал... Я знаю, что выборочные AC-файлы можно контролировать с помощью sysctl, На моем Mac запись, которая включает SACK, net.inet.tcp.sack, Когда включено, оно имеет значение 1; отключить, sysctl -w net.inet.tcp.sack=0, Я бы установил различные сценарии и использовал бы tcpdump чтобы проверить ваши проблемы.

Другие могут иметь разные советы для вас...