Home

Page 41
Page 41
background image

передаваемых  в  соединении  данных  с  некоторого  заранее  известного  числа  (например,  с  нуля, 
единицы etc), то необходимости уведомлять партнера о выбранном стартовом номере не было бы, 
сразу  возникает  вопрос:  почему  бы  участникам  соединения  не  начинать  нумерацию  с  нуля  или 
единицы?  

Важно  понять,  почему  в  каждом  новом  соединении  следует  выбирать  новое,  постоянно 

увеличивающееся число, с которого начинается нумерация передаваемых байт. Предположим, что 
клиент  и  сервер  установили  последовательно  серию  коротких  (по  времени)  соединений 
(соединений,  которые  были  быстро  разорваны),  и  в  каждом  таком  соединении  использовалась 
нумерация байт передаваемых от клиента к серверу (или наоборот, не важно) начиная, положим с 
единицы.  Пусть  устанавливается  еще  одно  соединение,  и  снова  нумерация  передаваемых  байт  (в 
любом  направлении  или  обоих,  не  суть  важно)  начинается  с  единицы.  Очевидно,  возможна 
ситуация, когда какие то сегменты, передаваемые в предыдущих соединениях, могли потеряться и 
были  повторены TCP, но  не  исключено,  что  эти  сегменты  от  предыдущих  соединений  НЕ 
потерялись, а задержались в сети, не исключено, что эти сегменты еще могут быть доставлены. Что 
будет,  если  такой  сегмент,  оставшийся  от  старого  соединения  и  задержавшийся  в  сети  будет 
получен  тогда,  когда  между  этим  же  клиентом  и  сервером  установлено  и  используется  новое 
соединение? Очевидно, если такой сегмент будет интерпретирован получателем как верный, т.е. его 
номер  будет  соответствовать  тому  номеру,  который  ожидается,  то  получение  такого  сегмента 
разрушит  сетевые  коммуникации,  например  в  файл,  принимаемый  клиентом  будет  записан 
фрагмент  совсем  другого  файла,  который  был  получен  клиентом  ранее.  Ясно,  что  такая  ситуация 
может произойти только в том случае, когда предыдущее соединение было коротким и разорвано 
недавно, действительно, сегменты не могут задерживаться в сети уж очень на долго, так что данный 
эффект  может  проявиться  только  в  том  случае,  если  новое  соединение  начинается  быстро,  а  в 
старом  номера  не  успели  слишком  вырасти,  т.е.  предыдущее  соединение  было  коротким.  Может 
показаться, что описанной выше ситуации произойти не может в принципе: действительно, как нам 
известно, клиентские приложения не используют один и тот же номер динамического порта, вместо 
этого  для  каждого  нового  соединения  используется  увеличенный  на  единицу  номер  свободного 
динамического порта. Однако разработчики протокола TCP предпочли из соображений повышения 
стабильности  работы  протокола  предусмотреть  ситуацию,  когда  клиентская  сторона  «забыла»  о 
том, какой порт использовала ранее, и устанавливает соединение с того же самого динамического 
порта  с  тем  же  самым  хорошо  известным  портом  (например,  станция  успела  перезагрузиться  и 
«забыла» о том, какие номера портов использовала до перезагрузки). Для обеспечения стабильной 
работы TCP в  таком  случае  и  необходимо  использовать  в  каждом  новом TCP соединении  новый 
стартовый  номер, RFC793 рекомендует  использовать  в  качестве  стартового  номера  число, 
зависящее от показаний локальных часов узла, и инкрементировать это число на единицу каждый 4 
мкс. Таким образом, за секунду стартовый номер увеличивается примерно на 250 000, и пробегает 
полный цикл примерно за 4,77 часа (проверьте самостоятельно). Данное время относительно велико 
–  ожидается,  что  сегменты,  оставшиеся  от  старых  соединений  НЕ  смогут  задержаться  в  сети  на 
такое  время,  следовательно,  использование  увеличивающихся  таким  образом  стартовых  значений 
номера НЕ приведет к рассмотренной выше ситуации. 

В заголовке данного сегмента с флагом SYN клиент должен сообщить серверу с помощью 

поля Sequence Number, некоторое  произвольное  число,  так  называемый ISN – Initial Sequence 
Number.  Смысл ISN следующий – начиная с  числа,  следующего  за ISN, клиент  будет  нумеровать 
байты,  которые  он  впоследствии  будет  передавать  в  соединение  (если,  конечно,  оно  будет 
установлено). Т.е., например, если клиент передал в первом сегменте ISN=5566, это означает, что 
номер первого байта, который он передаст в этом соединении, будет равен 5567. C какой целью в 
сегменте, с помощью которого предлагается установить соединение передается значение ISN? Если 
стороны  собираются  передавать  друг  другу  данные  в  рамках  соединения,  то,  как  мы  знаем,  им 
необходимо  нумеровать  передаваемые  данные.  Но  для  того,  что  партнер  мог  быть  уверен,  что  он 
получил  ВСЕ  данные,  которые  ему  передали,  он  должен  знать,  какой  был  номер,  с  которого 
началась  нумерация,  приведем  пример.  Пусть  передаются  сегменты  с  данными,  соответствующие 
Sequence Number и длины поля данных: 

Sequence 

Number 

  Data 

5000 

    1000 

6000 

    1500 

7500 

    500 

8000 

400 


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

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