Home

Page 63
Page 63
background image

 

Если бы сервер этого не делал, а просто устанавливал бы флаг RST, заполнив нулями поле 

Acknowledged Number, то  могла  бы  возникнуть  следующая  ситуация:  клиент  пытался  установить 
соединение с сервером, сервер не был готов к установке соединения и ответил сегментов с флагом 
RST,  этот  сегмент  задержался  в  сети,  затем,  спустя  некоторое  время,  клиент  снова  попытался 
установить  соединение  с  сервером  (с  того  же  динамического  порта,  как  мы  говорили,  такое 
возможно),  сервер  готов  установить  соединение,  но  клиенту  получает  задержавшийся  в  сети 
сегмент  с  флагом RST, и  рассматривает  его  как  отказ  сервера  установить  соединение.  Если  же 
сервер в сегменте с флагом RST укажет, в ответ на сегмент с каким ISN послан данный сегмент, это 
позволит избежать рассмотренной выше проблемы, так как клиент сможет идентифицировать такой 
сегмент,  как  принадлежащий  другому  соединению.  По  ходу  еще  раз  отметим,  что  механизм 
уникальных ISN в  каждом  новом  соединении  как  раз  и  предназначен  для  борьбы  с  подобными 
ситуациями, когда сегменты старых соединений могут помешать работе новых соединений.  

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

казалось  бы,  получение  сегмента  с  флагом RST явно  говорит  о  невозможности  установки 
соединения.  Тем  не  менее  стек Window  всегда  делает  оговоренное  заранее  количество  попыток 
установить  соединение  (по  умолчанию  три)  независимо  от  того,  по  какой  причине  соединение 
установить  не  удалось.  Теперь  рассмотрим  задержки  в  данном  взаимодействии.  Так  как  клиент  и 
сервер  расположены  в  одной  локальной  сети,  задержкой  сегментов  в  сети  можно  по  сути 
пренебречь,  ответ  на  посланный  сегмент  приходит  с  задержкой  порядка 1 мс.  После  того,  как 
клиент отправил первый сегмент с флагом SYN, он получает ответный сегмент с флагом RST через 
1 мс, после чего ждет 500 мс и отправляет второй сегмент с флагом SYN, ответ на который так же 
приходит немедленно. Важно обратить внимание, что в данном случае ВСЕ задержки от момента 
отправки  первого  сегмента  с  флагом SYN до  момента,  когда  клиентское  приложение  сообщает 
пользователю о невозможности коммуникаций составляют около 1000 мс (т.е. дважды по 500 мс). 
Важно  отметить,  что  в  отличие  от  предыдущего  случая,  когда  ответов  на  посланные  клиентом 
сегменты  не  было  и  клиенту  приходилось  ждать  неизвестное  заранее,  увеличивающееся  для 
каждого нового сегмента время, в данном примере клиент получает «отказ» о сервера мгновенно, 
поэтому  единственный  фактор,  определяющий  в  данном  примере  задержку  от  момента  начала 
взаимодействия  до  уведомления  пользователя  о  невозможности  его  осуществить – это  пауза, 
которую  делает  клиент  между  посылками  сегментов  с  флагом SYN. Стеку  клиента  не  нужно  бы 
увеличивать  паузу  между  посылаемыми  сегментами  с  флагом SYN – в  прошлом  примере  это 
делалось  для  того,  чтобы  увеличить  шансы  дождаться  ответа  в  условиях  неизвестных  задержек  в 
сети,  а  в  данном  случае  клиент  не  ждет  сегментов  неопределенное  время – он  получает  их 
немедленно и никакой потребности приспосабливаться к задержкам сети не имеет.  

Теперь рассмотрим обмен данными и использование полей Sequence Number и Acknowledged 

Number для квитирования передаваемых данных. Для начала рассмотрим пример, в котором только 
одна сторона – клиент будет передавать данные другой стороне – серверу. Используем в качестве 
клиента  и  сервера  утилиту sock как  было  показано  ранее,  проанализируем  трафик (TCP5.cap) с 
помощью Ethereal для удобства работы с относительными последовательными номерами. При этом 
не  забываем  вспомнить,  что  относительные  последовательные  номера  демонстрируем  нам 
анализатор,  на  самом  деле  в  соединении  используются  последовательные  номера  в  том  виде,  в 
котором это было показано ранее. 

Бегло  рассмотрим  первые  три  сегмента,  с  помощью  которых  устанавливается TCP 

соединение,  это  нами  уже  рассмотрено  на  практике.  Отметим,  что  в  третьем  сегменте  стороны 
закончили  установку  соединения  и  готовы  использовать  некоторые  последовательные  номера, 
которые в относительном представлении Ethereal равны единицам (хотя на самом деле 5e4932e2 и 
с16ecfb6).  В четвертом сегменте клиент передает серверу 11 байт данных, рассмотрим четвертый 
сегмент.  Его Sequence Number (относительный)  равен 1, так  как  еще  ни  одного  байта  клиент  не 
передавал  серверу  ранее,  клиент  ожидает  от  сервера  байт  номер 1, так  как  еще  не  получал  от 
сервера  данных.  Этот  сегмент  содержит 11 байт  данных  (цифры  от 1 до 0 + символ  возврата 
курсора 0a, который  передает  в  соединение  утилита sock). Отметим  так  же,  что  в  сегменте 4 
анализатор сообщает нам, каков будет следующий Sequence Number, используемый клиентом (12), 
это же число и будет является квитанцией на данный сегмент.    
 


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

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