Home

Page 42
Page 42
background image

и т.д. 
Ясно,  что  получатель,  принимая  такую  совокупность  сегментов  понимает,  что  никакие 

сегменты  не  были  потеряны: Sequence Number каждого  следующего  сегмента  в  точности  равен 
Sequence Number предыдущего + длина  его  поля  данных.  Если  какой-то  сегмент  их  этого  ряда 
потеряется, например, второй, получатель явно увидит это: из первого сегмента получены байты с 
номерами 5000-5999, второй потерян, а из следующего сегмента получены байты с номерами 7500-
7999, ясно, что байты с номерами 6000-6999 потеряны. Но что, если потеряется первый сегмент? В 
таком случае получатель может и не понять, что данные потеряны – ему просто будет казаться, что 
нумерация принимаемых им байт начинается не с номера 5000, а с номера 6000. Так как в рамках 
TCP соединения нумерация передаваемых каждой стороной байт начинается не с нуля (или другой 
константы) а каждый раз с произвольного значения, сторонам перед передачей данных необходимо 
сообщить  партнеру,  какой ISN будет  использоваться,  узнать,  какой ISN будет  использовать 
партнер, подтвердить партнеру, что его ISN получен и дождаться аналогичного подтверждения от 
партнера. Следовательно, в процессе установки соединения клиент должен: 

1.  Передать серверу свой ISN 
2.  Получить от сервера его ISN 
3.  Получить от сервера подтверждение того, что сервер принял ISN клиента 
4.  Подтвердить серверу получение его ISN. 

Ясно,  что  в  первом  пакете  клиент  может  только  лишь  выполнить  первый  пункт  данного 

плана – передать  серверу  свой ISN. Задачи,  описанные  в  пунктах 2 и 3 сервер  может  выполнить 
одним  сегментом – действительно,  можно  в  одном  сегменте  и  сообщить  клиенту  свой ISN и 
подтвердить  получение  его ISN (так  как  это  делается  другим  полем  заголовка – Acknowledged 
Number),  и,  наконец,  в  третьем  сегменте  клиент  подтверждает  получение ISN от  сервера.  Таким 
образом, для установки TCP соединения необходимо TPИ сегмента (а не два, как может показаться 
на первый взгляд и не четыре, как может показаться из анализа приведенной выше схемы обмена. 
Отметим,  что  часто  процедуру  установки TCP соединения  называют Three Way Handshake. Итак, 
еще раз повторяем, как должен быть устроен первый сегмент, посылаемый от сервера к клиенту: в 
нем  должен  быт  установлен  флаг SYN, кроме  того,  в  поле Sequence Number должно  быть 
установлено  значение ISN, выбранное  клиентом.  В  поле Acknowledged Number клиент  должен 
установить 00 00 00 00, так как клиент пока НЕ ожидает от сервера байтов с каким либо номером – 
сервер еще не сообщил клиенту, с какого ISN сервер будет нумеровать посылаемые байты. Вообще, 
поле Acknowledged Number интерпретируется  станциями  только  в  том  случае,  если  используется 
флаг ACK, в данном случае данный флаг не установлен и поле Acknowledged Number сервером не 
интерпретируется. Теперь рассматриваем поведение клиента после отправки такого пакета.  

Рассмотрим первый случай – на данный сегмент вообще не поступило ответа. Это возможно 

только в следующих случаях:  
•  Если данный сегмент (или ответ на него) потерялись при продвижении по сети 
•  Если  станция  получатель  сегмента  отсутствует  в  сети  (в  этом  случае  помимо  «тишины» 

возможен так же приход ICMP сообщения типа 3/1) 

•  Если имеют место проблемы с маршрутизацией между клиентом и сервером (и в таком случае 

возможен так же приход ICMP сообщения типа 3/1 или 3/0) 

В этом случае станция клиент должна отправить ЕЩЕ один сегмент, идентичный тому, на 

который  не  поступило  ответа – ведь  пакет  мог  потеряться.  Вообще  стек  отправит  некоторое 
количество  таких  сегментов,  сконфигурированное  в  настройках  стека TCP/IP. При  этом  важно 
понимать – стек будет в соответствии с некоторой стратегией каждый раз, отправляя новый сегмент 
с  флагом SYN увеличивать  время  ожидания  ответа  перед  пересылкой  нового  сегмента  с  флагом 
SYN.  Для  чего  это  делается?  Изначально  стек TCP/IP ориентирован  на  работу  в  составных  сетях 
произвольного  масштаба  с  непредсказуемыми  (в  некоторых  разумных  пределах)  задержками, 
поэтому не исключено, что в сети, в которой производится попытка установить данное соединение, 
имеют  место  значительные  задержки.  Поэтому  будет  вполне  логично,  если  стек  будет 
«настойчивым»  т.е.  будет  долго  ждать  (возможно,  десятки  секунд)  ответа  на  предложение 
установить  соединение.  Но  стоит  ли  долго  ждать  ответа  сразу,  т.е.  отправив  первый  сегмент  с 
флагом SYN? А  вдруг  задержки  в  сети  невелики  (например,  менее 1 секунды),  сегмент  банально 
потеряется,  а  стек  для  надежности  подождет 30 секунд,  и  только  затем  пошлет  второй  сегмент  с 
флагом SYN? Ясно, что в таком случае соединение будет установлено лишь через 30 секунд после 
того, как пользователь отдал команду его установить, хотя если бы стек послал повторный сегмент 


Copyright © 2021 Файлообменник files.d-lan.dp.ua

Использование любых материалов сайта возможно только с разрешения автора.