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

Question

Я делаю исследовательский проект, который должен разделить TCP-соединение. поэтому у меня есть несколько вопросов, которые могут возникнуть в моем развитии. Проблема заключается в понимании согласования TCP SACK. Я прочитал RFC и не могу найти ответ там.

Для трехстороннего рукопожатия tcp между двумя программами tcp: A и B. Если A отправит TCP SYN на B с разрешенным SACK, B обязательно ответит на пакет SYN/ACK с разрешенным SACK? если B отвечает TCP SYN/ACK без SACK-разрешения, значит ли это

1) SACK-permmited включен только на A. A может выборочно подтверждать tcp-пакеты от A, но A не может выборочно подтверждать tcp-пакеты от B.

или же

2) SACK-permmited не включен как на A, так и на B

если A отправляет TCP SYN на B без разрешения SACK, может ли B ответить пакетом SYN/ACK с разрешением SACK?

кроме того, почему разрешен или запрещен SACK? это зависит от операционной системы или настройки ядра или чего-то еще? можно ли это контролировать? Спасибо!

Answer 1

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

SACK-permitted отправляется из A в B, чтобы указать, что A готов принять опции 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 я не вижу ничего, что могло бы требовать или поощрять такое поведение.

Answer 2

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

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

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

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