реклама
ОНЛАЙН АПТЕКА НИЗКИХ ЦЕН
цены ниже розничных точек. доставка по украине

   Любые виды проектных, дизайнерских и строительных работ в Украине и Киеве    
АПТЕКА ЭКОНОМ

proxy  статьи  библиотека  softice  free_юр.консультация  hard  iptv
рекламодателям  фирмы/add  расшифровка штрих-кодов  links/add

http://kiev-security.org.ua

3 Спецификация для функций протокола

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

 "Подтверждение трех путей" - это процедура, используемая при уста-
новлении соединения. Эта процедура обычно инициируется программой
протокола TCP в ответ на запрос другой программы TCP. Данная процеду-
ра также работает, если две программы TCP инициируют ее одновременно.
Когда попытка инициализации осуществляется с обоих концов одновремен-
но, каждая программа протокола TCP получает сегмент "SYN", который не
несет подтверждения для уже отправленного ею "SYN". Конечно, прибытие
старых дубликатов сегмента "SYN" может произвести впечатление на по-
лучателя, будто осуществляется одновременное открытие соединения.
Корректное применение сегментов "перезагрузки" может предотвратить
двусмысленность таких ситуаций.
   Ниже приведены несколько примеров инициализации соединений. Хотя
эти примеры не показывают синхронизации соединения с помощью сегмен-
тов, несущих данные, это совершенно правомерно, поскольку программа
TCP, получающая сегменты, не передаст данные своему клиенту, пока не
станет очевидным корректность данных (т.е. данные должны
"складироваться" пользователем до тех пор, пока соединение не перей-
дет в состояние ESTABLISHED). Подтверждение трех путей уменьшает ве-
роятность появления ложных соединений. Получение информации для такой
проверки достигается посредством реализации обмена между памятью ком-
пьютера и циркулирующими в сети сообщениями.
   Простейшая процедура подтверждения трех путей показана ниже на
рисунке 7. Рисунки следует интерпретировать следующим образом. Для
удобства каждая строка пронумерована. Правые стрелки (-->) показывают
отправление TCP сегмента от программы TCP A в программу TCB B, или же
получение сегмента программой B из программы A. Левые стрелки (\--)
показывают обратные процессы. Многоточие (...) показывает сегмент,
который все еще задерживается в сети. "XXX" указывает на сегмент,
который потерян или отвергнут. Комментарии появляются в скобках.
Здесь "состояния" программы протокола TCP соответствуют моменту сразу
после посылки или получения сегмента (содержимое этого сегмента пока-
зано в средней колонке каждой строки). Содержимое сегмента в приво-
дится в сокращенной форме и представляет собой номер очереди, флаги
управления и поле ACK. Остальные поля сегмента, такие как окно, длина
и поле данных остаются за рамками нашего интереса.
     TCP A                                                  TCP B
1. CLOSED                                                LISTEN
2. SYN-SENT    --> \SEQ=100>\CTL=SYN>                --> SYN-RECEIVED
3. ESTABLISHED \-- \SEQ=300>\ACK=101>\CTL=SYN,ACK>   \-- SYN-RECEIVED
4. ESTABLISHED --> \SEQ=101>\ACK=301>\CTL=ACK>       --> ESTABLISHED
5. ESTABLISHED --> \SEQ=101>\ACK=301>\CTL=ACK>\DATA> --> ESTABLISHED
           Основная процедура подтверждения трех путей для
                       синхронизации соединения
                              Рисунок 7.
   На строке 2 рисунка 7 программа 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- для самого подтверждения!).
   На рисунке 8 показана та же инициализация с незначительными услож-
нениями. Каждая программа TCP проходит по очереди состояния CLOSED,
SYN-SENT, SYN-RECIEVED и наконец, ESTABLISHED.
   TCP A                                                  TCP B
1.CLOSED                                               CLOSED
2.SYN-SENT     --> \SEQ=100>\CTL=SYN>              ...
3.SYN-RECEIVED \-- \SEQ=300>\CTL=SYN>              \-- SYN-SENT
4.             ... \SEQ=100>\CTL=SYN>              --> SYN-RECEIVED
5.SYN-RECEIVED --> \SEQ=100>\ACK=301>\CTL=SYN,ACK> ...
6.ESTABLISHED  \-- \SEQ=300>\ACK=101>\CTL=SYN,ACK> \-- SYN-RECEIVED
7.             ... \SEQ=101>\ACK=301>\CTL=ACK>     --> ESTABLISHED
                Одновременная синхронизация соединения
                              Рисунок 8
   Главной причиной для приненения подтверждения трех путей является
попытка преотвратить возникновение сбоев при получении старых дубли-
катов, инициирующих соединение. Для работы с подтверждением трех пу-
тей придумано специальное контрольное сообщение - перезагрузка
(reset). Если получающая сигнал программа TCP находится не в синхро-
низированном состоянии (т.е. в SYN-SENT, SYN-RECEIVED), то она воз-
вращает сигнал LISTEN, показывая, что она получила приемлемый сигнал
перезагрузки. Если же программа TCP находится в одном из синхронизи-
рованных состояний (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT,
CLOSING, LAST-ACK, TIME-WAIT), то она ликвидирует соединение и про-
информирует об этом своего клиента. Мы обсудим ниже такую ситуацию
при рассмотрении "наполовину открытых" соединений.
    TCP A                                               TCP B
1.CLOSED                                              LISTEN
2.SYN-SENT    --> \SEQ=100>\CTL=SYN>              ...
3.(дубликат)  ... \SEQ=90>\CTL=SYN>               --> SYN-RECEIVED
4.SYN-SENT    \-- \SEQ=300>\ACK=91>\CTL=SYN,ACK>  \-- SYN-RECEIVED
5.SYN-SENT    --> \SEQ=91>\CTL=RST>               --> LISTEN
6.            ... \SEQ=100>\CTL=SYN>              --> SYN-RECEIVED
7.SYN-SENT    \-- \SEQ=400>\ACK=101>\CTL=SYN,ACK> \-- SYN-RECEIVED
8.ESTABLISHED --> \SEQ=101>\ACK=401>\CTL=ACK>     --> ESTABLISHED
               Получение старого дубликата сигнала SYN
                              Рисунок 9
   В качестве простого примера рассмотрим ситуацию с получением ста-
рых дубликатов на рисунке 9. На строке 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. Такой сценарий приводит к ситуации, показанной на рисунке 10.
После того, как программа TCP A потерпит крах, пользователь попытает-
ся повторно открыть соединение. Программа TCP B тем временем продол-
жает полагать, будто соединение остается открытым.
    TCP A                                               TCP B
1.сбой                          (номер посылки 300, получения - 100)
2.CLOSED                                              ESTABLISHED
3.SYN-SENT    --> \SEQ=400>\CTL=SYN>              --> (??)
4.(!!)        \-- \SEQ=300>\ACK=100>\CTL=SYN>     \-- ESTABLISHED
5.SYN-SENT    --> \SEQ=100>\CTL=RST>              --> (ликвидация!!)
6.SYN-SENT                                            CLOSED
7.SYN-SENT    --> \SEQ=400>\CTL=SYN>              -->
             Обнаружение наполовину открытого соединения
                              Рисунок 10
   Когда на строке 3 сигнал SYN достигает программу TCP B, находящую-
ся в синхронизированном состоянии, а пришедший сегмент находится за
пределами окна, программа TCP B отвечает на это его подтверждением,
показывает номер очереди, который она желает получить (ACK=100). Про-
грамма TCP A, видя, что сегмент на строке 4 не подтвердил отправлен-
ную ею информацию, фиксирует отсутствие синхронизации и посылает сиг-
нал перезагрузки (RST), поскольку обнаружено, что соединение является
открытым наполовину. На строке 5 программа TCP B ликвидирует соедине-
ние. Программа TCP A будет продолжать попытки установить соедлинение.
Теперь возникшая проблема решается простым подтверждением трех путей
(рисунок 7).
   Другой интересный сюжет имеет место, если программа TCP A терпит
крах, а программа TCP B, полагая, что находится в состоянии синхрони-
зации, пытается послать данные. Эта ситуация показана на рисунке 11.
В этом случае данные, отправленные программой 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>              --> (ликвидация!!)
               Активная сторона приводит к обнаружению
                   наполовину открытого соединения
                              Рисунок 11
   На рисунке 12 показано, что две программы TCP - A и B - ,имея
пасивное состояние, ждут сигнала SYN. Старый дубликат сигнала, дости-
гает программу TCP B (строка 2), запускает ее. Возвращается сигнал
SYN-ACK (строка 3) и заставляет программу TCP A генерировать сигнал
RST (на строке 3 сигнал ACK неприемлем). Программа TCP B принимает
команду перезагрузки и волзвращается в пассивное состояние LISTEN.
    TCP A                                               TCP B
1.LISTEN                                               LISTEN
2.            ... \SEQ=Z>\CTL=SYN>                --> SYN-RECEIVED
3. (??)       \-- \SEQ=X>\ACK=Z+1>\CTL=SYN,ACK>   \-- SYN-RECEIVED
4.            --> \SEQ=Z+1>\CTL=RST>              --> возврат в LISTEN
5.LISTEN                                              LISTEN
         Старый дубликат сигнала SYN инициирует перезагрузку
                      на двух пассивных сокетах
                              Рисунок 12
Может быть множество других вариаций, которые могут быть объяснены
нижеописанными правилами для создания и обработки сигналов 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, оповещает об этом
своего клиента.

Назад | Вперед

Содержание

HOME


Если у вас есть сайт или домашняя страничка - поддержите пожайлуста наш ресурс, поставьте себе кнопочку, скопировав этот код:

<a href="http://kiev-security.org.ua" title="Самый большой объем в сети онлайн инф-ции по безопасности на rus" target="_blank"><img src="http://kiev-security.org.ua/88x31.gif" width="88" height="31" border="0" alt="security,безопасность,библиотека"></a>

Идея проекта(C)Anton Morozov, Kiev, Ukraine, 1999-2020, security2001@mail.ru