Установка соединения
Процесс начала сеанса TCP называется «тройным рукопожатием». Клиент, который намеревается установить соединение, посылает серверу сегмент с номером последовательности и флагом SYN. Сервер получает сегмент, запоминает номер последовательности и пытается создать сокет (буфера и управляющие структуры памяти) для обслуживания нового клиента. В случае успеха сервер посылает клиенту сегмент с номером последовательности и флагами SYN и ACK, и переходит в состояние SYN-RECEIVED. В случае неудачи сервер посылает клиенту сегмент с флагом RST.
Если клиент получает сегмент с флагом SYN, то он запоминает номер последовательности и посылает сегмент с флагом ACK, если он одновременно получает и флаг ACK (что обычно и происходит), то он переходит в состояние ESTABLISHED. Если клиент получает сегмент с флагом RST, то он прекращает попытки соединиться.
Если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново.
Если сервер в состоянии SYN-RECEIVED получает сегмент с флагом ACK, то он переходит в состояние ESTABLISHED. В противном случае после таймаута он закрывает сокет и переходит в состояние CLOSED.
Процесс называется «тройным рукопожатием», так как несмотря на то что возможен процесс установления соединения с использованием 4 сегментов (SYN в сторону сервера, ACK в сторону клиента, SYN в сторону клиента, ACK в сторону сервера), на практике для экономии времени используется 3 сегмента.
Завершение соединения
Завершение соединения можно рассмотреть в три этапа: 1. Посылка серверу от клиента флагов FIN и ACK на завершения соединения. 2. Сервер посылает клиенту флаги ответа ACK, FIN, что соединение закрыто. 3. После получение этих флагов клиент закрывает соединение и в подтверждение отправляет серверу ACK, что соединение закрыто.
Скользящее окно TCP
Для того, чтобы передающая сторона не отправляла данные интенсивнее, чем их может обработать приемник, TCP содержит средства управления потоком. Для этого используется поле «окно». В сегментах, направляемых от приемника передающей стороне в поле «окно» указывается текущий размер приемного буфера. Передающая сторона сохраняет размер окна и отправляет данных не более, чем указал приемник. Если приемник указал нулевой размер окна, то передача данных в направлении этого узла не происходит, до тех пор пока приемник не сообщит о большем размере окна.
В рамках установленного соединения правильность передачи каждого сегмента должна подтверждаться квитанцией получателя. Квитирование - это один из традиционных методов обеспечения надежной связи. В протоколе TCP используется частный случай квитирования - алгоритм скользящего окна. Идея этого алгоритма была изложена в главе 2, «Основы передачи дискретных данных».
Особенность использования алгоритма скользящего окна в протоколе TCP состоит в том, что, хотя единицей передаваемых данных является сегмент, окно определено на множестве нумерованных байтов неструктурированного потока данных, поступающих с верхнего уровня и буферизуемых протоколом TCP. Получающий модуль TCP отправляет «окно» посылающему модулю TCP. Данное окно задает количество байтов (начиная с номера байта, о котором уже была выслана квитанция), которое принимающий модуль TCP готов в настоящий момент принять.
Квитанция (подтверждение) посылается только в случае правильного приема данных, отрицательные квитанции не посылаются. Таким образом, отсутствие квитанции означает либо прием искаженного сегмента, либо потерю сегмента, либо потерю квитанции. В качестве квитанции получатель сегмента отсылает ответное сообщение (сегмент), в которое помещает число, на единицу превышающее максимальный номер байта в полученном сегменте. Это число часто называют номером очереди.
Н
а
рис. показан поток байтов, поступающий
на вход протокола TCP. Из потока байтов
модуль TCP нарезает последовательность
сегментов. Для определенности на рисунке
принято направление перемещения данных
справа налево. В этом потоке можно
указать несколько логических границ.
Первая граница отделяет сегменты,
которые уже были отправлены и на которые
уже пришли квитанции. Следующую часть
потока составляют сегменты, которые
также уже отправлены, так как входят в
границы, определенные окном, но квитанции
на них пока не получены. Третья часть
потока - это сегменты, которые пока не
отправлены, но могут быть отправлены,
так как входят в пределы окна. И наконец,
последняя граница указывает на начало
последовательности сегментов, ни один
из которых не может быть отправлен до
тех пор, пока не придет очередная
квитанция и окно не будет сдвинуто
вправо. Т.о., окно будто скользит по
байтовому потоку.
Повторная передача.
Надежная TCP-служба требует, чтобы все сегменты, содержащие данные, были подтверждены получателем. Когда подтвержление для сегмента не принимается в течение определенного количества времени, отправитель повторно передает сегмент.
Отправитель может повторить передачу несколько раз перед тем, как отказаться от соединения.
Для каждого соединения протокол поддерживает переменную, называемую «задержка повторной передачи» (RTO). Ее значение соответствует количеству времени, в течение которого может отсутствовать подтверждение. Как только время истекает, осуществляется повторная передача сегмента.
Период кругового обращения (RTT):
Время прохождения сегмента от отправителя к адресату (в разных сетях – разное время)
Время обработки входящего сегмента адресатом
Время на создание ответа (ACK-сегмент): создание окна, подтверждение нескольких сегментов
Время прохождения сегмента от адресата к отправителю
Время обработки ACK-сегмента
RTT меняется со временем и должно постоянно измеряться на протяжении всего сеанса связи. RTO>RTT.
RTO не должно быть слишком большим, иначе будет снижена производительность сети из-за простоя. Если RTO<RTT, то сегменты передаются повторно напрасно.
Повторная передача может случиться из-за:
ACK-сегмент отброшен маршрутизатором (из-за его перегрузки, например)
То, что посылали, не дошло до получателя - обросил маршрутизатор, не совпадает контрольная сумма, (из-за повреждения сигнала, например)