Установление соединения

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

Ниже приведены несколько примеров инициализации соединений. Хотя эти примеры не показывают синхронизации соединения с помощью сегментов, несущих данные, это совершенно правомерно, поскольку программа TCP, получающая сегменты, не передаст данные своему клиенту, пока не станет очевидным корректность данных (т.е. данные должны "складироваться" пользователем до тех пор, пока соединение не перейдет в состояние ESTABLISHED). Подтверждение трех путей уменьшает вероятность появления ложных соединений. Получение информации для такой проверки достигается посредством реализации обмена между памятью компьютера и циркулирующими в сети сообщениями.

Простейшая процедура подтверждения трех путей показана ниже на рисунке 5. Рисунки следует интерпретировать следующим образом. Для удобства каждая строка пронумерована. Правые стрелки (-->) показывают отправление TCP сегмента от программы TCP A в программу TCB B, или же получение сегмента программой B из программы A. Левые стрелки (<--) показывают обратные процессы. Многоточие (...) показывает сегмент, который все еще задерживается в сети. "XXX" указывает на сегмент, который потерян или отвергнут. Комментарии появляются в скобках.

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

На строке 2 рисунка 5 программа TCP A начинает с посылки сигнала SYN, показывая тем самым, что она будет использовать номера очереди, начиная с номера 100. На строке 3 программа TCB B посылает сигнал SYN, а также подтверждение о том, что сигнал SYN со стороны программы TCP A получен. Заметим, что поле подтверждения информирует о том, что программа TCP B в данный момент ожидает получение номера 101. Последнее также подтверждает, что сигнал SYN уже занял место в очереди под номером 100.

На строке 4 для отправленного программой TCP B в строке 3 сигнала SYN программа TCP A дает ответ с помощью пустого сегмента, содержащего сигнал ACK . В строке 5 программа TCP A передает по сети уже некую порцию данных. Заметим, что сегмент в строке 5 имеет тот же номер очереди, что был у сегмента в строке 4, поскольку сигнал ACK в очереди места не занимает (если бы это было не так, то нам следовало обзавестись подтверждением -ACK- для самого подтверждения!).

На рисунке 6 показана та же инициализация с незначительными усложнениями. Каждая программа TCP проходит по очереди состояния CLOSED, SYN-SENT, SYN-RECIEVED и наконец, ESTABLISHED.

Рис. 6 Одновременная синхронизация соединения

Главной причиной для применения подтверждения трех путей является попытка предотвратить возникновение сбоев при получении старых дубликатов, инициирующих соединение. Для работы с подтверждением трех путей придумано специальное контрольное сообщение - перезагрузка (reset).

Если получающая сигнал программа TCP находится не в синхронизированном состоянии (т.е. в SYN-SENT, SYN-RECEIVED), то она возвращает сигнал LISTEN, показывая, что она получила приемлемый сигнал перезагрузки. Если же программа TCP находится в одном из синхронизированных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), то она ликвидирует соединение и проинформирует об этом своего клиента. Мы обсудим ниже такую ситуацию при рассмотрении "наполовину открытых" соединений.

В качестве простого примера рассмотрим ситуацию с получением старых дубликатов на рисунке 7. На строке 3 старый дубликат сигнала SYN достигает программу TCP B. Последняя не может определить, что это старый дубликат, и поэтому отвечает обычным образом (строка 4).

Программа TCP A обнаруживает ошибочное значение в поле ACK и поэтому возвращает сигнал RST (перезагрузка). При этом значение поля SEQ выбирается таким образом, чтобы сделать сегмент правдоподобным. Про грамма TCP B по получении сигнала RST переходит в состояние LISTEN. Когда на строке 6 сигнал SYN, действительный, а не устаревший, достигает программу TCP B, процесс синхронизации происходит нормально. Если же сигнал SYN на строке 6 достигает программу TCP B прежде сигнала RST, может возникнуть более сложная комбинация обмена с посылкой RST в обоих направлениях.

Наполовину открытые соединения и другие аномалии

Уже установившееся соединение называется "наполовину открытым", если одна из программ TCP закрыла соединение, или отказалась от него. Причем сделала это на своем конце, не предупредив своего партнера. Также такая ситуация может возникнуть, если нарушена синхронизация на концах линии вследствие сбоя, приведшего к потере информации в памяти. Если на таких соединениях делается попытка отправить данные в каком-либо направлении, то автоматически производится перезагрузка соединения. Однако предполагается, что наполовину открытые соединения являются редкостью, а процедура восстановления применяется в сети весьма умеренно.

Если на конце A соединение считается уже несуществующим, а клиент на конце B пытается послать данные, то это приведет к тому, что программа TCP на конце B получит контрольное сообщение о перезагрузке. Такое сообщение показывает программе TCP на конце B, что что-то неправильно и ей предлагается ликвидировать это соединение.

Предположим, что два клиента в точках A и B общаются друг с другом, и в этот момент происходит крах, приводящий к потере информации в памяти у программы TCP на конце A. В зависимости от операционной системы, обслуживающей программу TCP A, вероятно, будет задействован некий механизм исправления ошибки. Когда программа TCP A будет запущена вновь, она, вероятно, вновь начнет свою работу с самого начала или же с инструкции преодоления сбоя. В результате, программа A, вероятно, попытается открыть (OPEN) соединение или послать информацию (SEND) через соединение, которое, как она полагает, является открытым. В последнем случае от местной программы TCP (на конце A) будет получено сообщение "соединение не открыто". При попытке установить соединение программа TCP A будет посылать сегмент, содержащий сигнал SYN. Такой сценарий приводит к ситуации, показанной на рисунке 8. После того, как программа TCP A потерпит крах, пользователь попытается повторно открыть соединение. Программа TCP B тем временем продолжает полагать, будто соединение остается открытым.

Когда на строке 3 сигнал SYN достигает программу TCP B, находящуюся в синхронизированном состоянии, а пришедший сегмент находится за пределами окна, программа TCP B отвечает на это его подтверждением, показывает номер очереди, который она желает получить (ACK=100). Программа TCP A, видя, что сегмент на строке 4 не подтвердил отправленную ею информацию, фиксирует отсутствие синхронизации и посылает сигнал перезагрузки (RST), поскольку обнаружено, что соединение является открытым наполовину. На строке 5 программа TCP B ликвидирует соединение. Программа TCP A будет продолжать попытки установить соединение.

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

Другой интересный сюжет имеет место, если программа TCP A терпит крах, а программа TCP B, полагая, что находится в состоянии синхронизации, пытается послать данные. Эта ситуация показана на рисунке 9.

В этом случае данные, отправленные программой TCP B, и пришедшие на программу TCP A (строка 2). будут отвергнуты, поскольку используемого ими соединения не существует. На основании этого программа TCP A посылает сигнал RST. Как только сигнал RST принят программой TCP B, он будет рассмотрен, а использованное прежде соединение будет ликвидировано.

. TCP A . TCP B 1.сбой . (номер посылки 300, получения - 100) 2.(??) <-- <SEQ=300><ACK=100><DATA=10><CTL=SYN> <-- ESTABLISHED 3. . --> <SEQ=100><CTL=RST> --> (ликвидация!!)

Рис. 9 Активная сторона приводит к обнаружению
наполовину открытого соединения

На рисунке 10 показано, что две программы TCP - A и B - ,имея пассивное состояние, ждут сигнала SYN. Старый дубликат сигнала, достигает программу TCP B (строка 2), запускает ее. Возвращается сигнал SYN-ACK (строка 3) и заставляет программу TCP A генерировать сигнал RST (на строке 3 сигнал ACK неприемлем). Программа TCP B принимает команду перезагрузки и возвращается в пассивное состояние LISTEN.

Рис. 10 Старый дубликат сигнала SYN инициирует перезагрузку
на двух пассивных сокетах

Может быть множество других вариаций, которые могут быть объяснены нижеописанными правилами для создания и обработки сигналов RST.

Создание сигнала перезагрузки

Согласно главному правилу, сигнал перезагрузки (RST) должен посылаться всякий раз, когда приходит сегмент, который очевидным образом не предназначен для данного соединения. Если непонятно, имеет ли место данный случай, следует воздержаться от перезагрузки.

Можно выделить три группы состояний для соединения:

1. Если соединения не существует (CLOSED), то сигнал перезагрузки посылается в ответ на любой пришедший сегмент, за исключением встречного сигнала перезагрузки. В частности, сигналы SYN, адресованные на несуществующее соединение, отвергаются именно таким образом. Если приходящий сегмент имеет флаг в поле ACK, то сегмент с сигналом перезагрузки получает номер для очереди из поля ACK первого сегмента. В противном случае сегмент с сигналом перезагрузки имеет нулевой номер очереди и значение в поле ACK, равным сумме номера очереди пришедшего сегмента и его же длины. Соединение остается в состоянии CLOSED.

2. Если соединение находится в каком-либо не синхронизированном состоянии (LISTEN, SYN-SENT, SYN-RECEIVED), если какие-либо подтверждения пришедшего сегмента еще не отправлены (сегмент несет неприемлемое значение в поле ACK) или пришедший сегмент имеет уровень безопасности/закрытости не соответствующий уровню и защите данного соединения, то отправляется сигнал перезагрузки.

   Если наш сигнал SYN не был подтвержден, а уровень приоритета пришедшего сегмента больше запрошенного уровня, то либо будет увеличен местный уровень приоритета (если это приемлемо для пользователя и системы), либо будет послан сигнал перезагрузки. Или же если уровень приоритета пришедшего сегмента меньше запрошенного, то обработка будет продолжена далее, как если бы уровень был таким же (если чужая программа TCP не может повысить уровень приоритета до нашего, то это будет отмечено в следующем отправляемом ею сегменте, тогда и будет закрыто соединение). Если наш сигнал SYN получил подтверждение (возможно в пришедшем к нам сегменте), то уровень приоритета пришедшего сегмента должен точно соответствовать мест ному уровню. Если последнее условие не выполняется, посылается сигнал перезагрузки.

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

3. Если соединение находится в синхронизированном состоянии (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST ACK, TIME-WAIT), то любой неприемлемый сегмент (не попадающий в окно номеров очереди, несущий неправильный номер подтверждения) должен приводить к появлению сегмента с пустым полем подтверждения, содержащего текущий номер в очереди на посылку, а также подтверждение, указывающее на следующий ожидаемый с этого соединения номер. Соединение остается в своем прежнем состоянии. Если пришедший сегмент имеет уровень защиты, изоляции или приоритета, не соответствующий местному уровню соединения, то отправляется сигнал перезагрузки, а соединение переходит в состояние CLOSED. Сигнал перезагрузки имеет номер очереди, соответствующий номеру сигнала ACK в пришедшем сегменте.

Обработка сигнала на перезагрузку

Для всех состояний, кроме SYN-SENT, все сегменты с сигналом перезагрузки (RST) проходят проверку полей SEQ. Сигнал перезагрузки признается, если его номер очереди попадает в окно. В состоянии же SYN SENT (сигнал RST получен в ответ на посылку инициирующего сигнала SYN), сигнал RST признается, если поле ACK подтверждает ранее сделанную посылку сигнала SYN.

Получатель сигнала RST сперва проверяет его, и лишь потом меняет свое состояние. Если получатель находился в состоянии LISTEN, то он игнорирует сигнал. Если получатель находился в состоянии SYN- RECEIVED, то он возвращается вновь в состояние LISTEN. В иных случаях получатель ликвидирует соединение и переходит в состояние CLOSED. Если получатель находится в каком-либо ином состоянии, то он ликвидирует соединение и прежде чем перейти в состояние CLOSED, оповещает об этом своего клиента.