Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Сети_лекции.doc
Скачиваний:
553
Добавлен:
11.03.2015
Размер:
1.38 Mб
Скачать

9.3. Протокол tcp

Основным отличием TCP от UDP является то, что протокол TCP обеспечивает надежную доставку сообщений. Протокол TCP решает задачу обеспечения надежного обмена данными между двумя узлами сети путем установления логического соединения. Благодаря этому TCP следит, чтобы передаваемые данные не были потеряны, небыли продублированы и пришли к получателю в том же порядке, в котором были отправлены.

Все TCP-соединения образуют полудуплексный канал связи. Ши­роковещательная рассылка протоколом TCP не поддерживается.

ТСР-сегмент

Протокол TCP рассматривает данные, поступающие от протоколов прикладного уровня, как неструктурированный поток байтов. Перед передачей на сетевой или прикладной уровень данные помещаются в специальные буферы TCP. Для передачи па сетевой уровень формиру­ется TCP-сегмент, который состоит из заголовка и данных из буфера. Размер сегментов определяется реализацией протокола TCP.

На рис. 9.3 представлен формат заголовка TCP-сегмента с указа­нием размеров его полей. Минимальный размер заголовок ТСР-сегмента составляет 20 байт [8].

Поля «Порт отправителя» и «Порт получателя» длиной 2 байт идентифицирует соответственно процесс-отправитель и процесс-получатель.

84

Рис. 9.3. Заголовок ТСР-cei мента

Поле «Порядковый номер» длиной 4 байта представляет собой номер байта, который определяет смещение сегмента в потоке отправ­ляемых данных. Это поле используется получателем при восстановле­нии исходного потока данных из полученных сегментов.

Поле «Номер подтверждении» длиной 4 байта содержит номер байта, ожидаемого в следующем ожидаемом сегменте. Данное поле действительно только при установленном флаге АСК.

Поле «Длина заголовка» длиной 4 бита представляет собой длину заголовка TCP-сегмента, измеряемую в 32-битовых словах. Длина за­головка не фиксирована и может изменяться в зависимости от значе­ний, устанавливаемых в поле «Параметры».

Неиспользуемое 6 битное поле. Оно зарезервировано для будуще­го использования, и на сегодняшний день его смысл еще не определен.

Поле «Флаги» длиной б бит содержит шесть 1-битных флагов, со­держащих служебную информацию о типе данного сегмента:

  1. URG - срочное сообщение;

  2. АСК - подтверждение принятия сегмента;

  3. PSH - флаг, с помощью которого отправитель просит получателя передать данные прикладному уровню сразу после получения сег­мента, а не хранить их в буфере, пока тот не заполниться;

  4. RST - используется для отказа от неверного сегмента или от по­пытки создать соединение;

  5. SYN - используется для установления соединения;

  6. FIN - используется для завершения соединения.

Поле «Размер окна» имеет длину 2 байта и используется получа­телем для передачи отправителю информации о том. какой объем дан­ных он готов принять, начиная с байта, номер которого указан в поле «Номер подтверждения».

so

Поле «Контрольная сумма» длиной 2 байта предназначено для выявления ошибок. Оно содержит контрольную сумму заголовка ТСР-сегмента, данных и псевдозаголовка TCP-сегмента. Псевдозаголовок TCP-сегмента имеет аналогичную структуру, что и псевдозаголовок UDP-дейтаграммы. Но в поле «Протокол» псевдозаголовка ТСР-сегмента указывается значение равное 6, которое соответствует прото­колу TCP.

Поле «Указатель на срочные данные» длиной 2 байта указывает на последний байт срочных данных в сегменте. Это поле используется совместно с флагом URG, которое устанавливается в единицу, если какие-то данные нужно срочно переслать вне очереди. Если флаг не установлен, поле не используется.

Поле «Параметры» имеет переменную длину, состоит минимум из одного байта и определяет параметры сегмента. С помощью одного из таких параметров каждый получатель может установить макси­мальный размер сегмента (Maximum Segment Size, MSS), который он может принять. При отсутствии параметров поле состоит из 1 байта и содержит 0, как признак конца списка параметров.

Поле «Дополнение» имеет переменную длину. Это поле заполня­ется нулями и обеспечивает выравнивание заголовка до размера крат­ному 4 байтам.

Процесс установления ТСР-соединения

В TCP определены два способа установления соединения: актив­ный и пассивный. В первом случае одна сторона (клиент) отправляет другой стороне (серверу) TCP-сегмент с запросом на соединение. Пас­сивный способ означает, что одна сторона (сервер) предпочитает при­нять входящий запрос на соединение от другой стороны (клиента), нежели пытаться инициировать соединение самостоятельно. Установ­ление TCP-соединения представляет собой процесс, изображенный на рис. 9.4.

  1. Чтобы установить соединение, сервер пассивно ожидает входяще­го соединения.

  2. Клиент посылает TCP-сегмент и ждет ответа. Этот сегмент содер­жит стартовый порядковый помер этой стороны, номер порта назначения, максимальный размера сегмента, а также в нем уста­новлен флаг SYN и сброшен флаг АСК.

  3. Когда TCP-сегмент прибывает в пункт назначения, сервер прове­ряет, есть ли какой-нибудь процесс, который прослушивает то же порт, что содержится в поле «Порт получателя».

  1. Если такого процесса нет, он отвечает отправкой TCP-сегмента с установленным флагом RST для отката соединения.

    Рис. 9.4. Установление TCP-соединения

  2. Если такой процесс найден, то входящий сегмент передается это­му процессу. Если процесс принимает соединение, он отсылает в ответ TCP-сегмент, в котором укатывает свой стартовый порядко­вый номер и максимальный размер сегмента. Кроме того, в ответ­ном сегменте устанавливаются флаги SYN и АСК.

  3. Когда этот сегмент прибывает в пункт назначения, клиент, под­тверждая его получение, отправляя в ответ TCP-сегмент, в кото­ром установлен флаг АСК. Данный сегмент, завершает процесс установления ТСР-соединения.

Процесс завершения ТСР-соединения

Чтобы завершить TCP-соединение, любая из сторон может по­слать TCP-сегмент с установленным флагом FIN. Когда этот сегмент получает подтверждение, это направление передачи закрывается. Тем не менее, данные могут продолжать передаваться неопределенное время в противоположном направлении. Соединение завершается, ко­гда оба направления передачи закрываются. Обычно дтя завершения ТСР-соединения требуется четыре сегмента (рис. 9.5, а): по одному с флагом FIN и по одному с флагом АСК в каждом направлении. Иногда первый флаг АСК и второй флаг FIN могут включаться в один сег­мент, что уменьшит количество сегментов до трех (рис. 9.5, б).

Если ответ на посланный FIN-сегмент не приходит в течении двух максимальных интервалов времени жизни сегмента, отправитель FIN-сегмента завершает соединение. Другая сторона в конце концов заме­тит, что ей никто не отвечает, и также завершит соединение.

а б

Рис. 9.5. В процессе завершения ТСР-соединения могут использоваться четыре сегмента (а) или три сегмента (б)

Состоянии ТСР-соединения

Каждое TCP-соединение проходит несколько состояний, перечис­ленных в таблице 9.1. Новое TCP-соединение начинается в состоянии CLOSED.

Таблица 9.1. Состояния ТСР-соединения

Состояние

Описание

CLOSED

Соединение не установлено

LISTEN

Сервер ожидает входящего запроса на соединение

SYN SENT

Клиент отослал запрос на соединение и ожидает подтвер­ждения соединения

SYN RCVD

Сервер получил запрос на соединение, отправил подтвер­ждение соединения и ожидает подтверждения

Передача данных в TCP

Окончание табл. 9.1

ESTABLISHED

Соединение установлено

FIN WAIT 1

Клиент сообщил о завершении соединения, отправив FIN-сегмент, и ожидает подтверждения

FIN WAIT 2

Клиент получил подтверждение о завершении соединения

CLOSE WAIT

Сервер получил FIN-сегмент, отправил подтверждение и FIN-сегмент для закрытия соединения со своей стороны

LAST ASK

Сервер ожидает подтверждение завершения соединения

TIMED WAIT

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

CLOSING

Клиент в ответ на FIN-сегмент получил от сервера FIN-сегмент. Это значит, что обе стороны пытаются одновре­менно закрыть соединение

Для надежной передачи данных в TCP используются следующие механизмы. Во-первых, отправитель включает в TCP-сегмент кон­трольную сумму содержащихся в нем данных. Это позволяет получа­телю убедиться, что переданные данные не были повреждены в про­цессе транспортировки. Во-вторых, в TCP имеется механизм подтвер­ждения и повторной передачи, который гарантирует, что каждый сег­мент будет доставлен.

В-третьих, в TCP используется механизм скользящего окна, ко­торый гарантирует, что даже если сегменты прибывают в пункт назна­чения не в том порядке, в котором были отправлены, то получатель сможет собрать из них исходное сообщение. Для этого каждому байту присваивается порядковый номер. Разумеется, TCP не передает поряд­ковый номер вместе с каждым байтом. Вместо этого, в заголовке каж­дого сегмента хранится порядковый номер первого байта, а порядко­вые номера остальных байтов можно вычислить. На каждом конце TCP-соединения поддерживается окно приема, представляющее со­бой диапазон порядковых номеров байтов. Например, на рис. 9.6 окно приема обведено пунктиром. Наименьшее значение соответствует левой границе окна - это порядковый номер следующего ожидаемого байта. Наибольшее значение соответствует правой границе окна - это порядковый номер последнего байта, для которого у TCP есть место в буфере.

Помимо окна приема, на каждом конце TCP соединения поддер­живается окно передачи, разделенное на две части. В одной из них расположены байты, которые уже отправлены, но не подтверждены, а в другой - байты, которые еще не отправлены. На рис. 9.7 можно ви­деть окно передачи после пересылки байтов 4-8, но до подтверждения, а также байты 9-11 могут быть посланы, не дожидаясь подтверждения от получателя.

Рис. 9.6. Окно приема TCP

Окно приема

1

0

1

2

3

4

5

6

7

8

9

К)

11 ! 12

13

14

15

16

17

18

19

1

Окно передачи

<

0

1

2

3 !

4

5

6

7

8

9

10

п: 12

13

14

15

16

17

18

19

Отправлены Могут быть отправлены

Рис. 9.7. Окно передачи TCP

Рассмотрим подробнее процесс передачи данных по протоколу TCP. После отправки TCP-сегмента отправитель помечает в окне пе­редачи байты, переданные в этом сегмента, как отправленные, но не подтвержденные, и начинает отсчет тайм-аута регрансмиссин (Re­transmission Timeout. RTO).

Когда получатель принимает TCP-cei мент, все байты, порядковые номера которых оказываются вне окна приема, отбрасываются. Это касается как уже принятых ранее байтов (с порядковыми номерами левее окна приема), так и байтов, для которых нет места в буфере (с порядковыми номерами правее окна приема). Если порядковый номер первого байта в сегменте больше порядковый номера следующего ожидаемого байта, значит, сегмент прибыл не по порядку. В большин­стве реализаций TCP такой сегмент помещается в очередь и находится в ней, пока не придут пропущенные байты. Если же порядковый номер первого байта в сегменте совпадает со следующим ожидаемым, то данные становятся доступными процессу-получателя. В этом случае окно приема сдвигается вправо на число байтов в принятом сегменте. Наконец, как показано на рис. 9.8, а получатель посылает отправителю сегмент с подтверждением, содержащий порядковый номер следую­щего ожидаемого байта.

Рис. 9.8. Процесс передачи данных: а - без ошибок; б - при возникновении ошибки

После получения подтверждения отправитель сегмента сдвигает окно передачи вправо на число байтов в этом сегменте. Если подтвер­ждение не пришло до истечения времени тайм-аута ретрансмиссии, то считается, что считается произошла ошибка и TCP-сегмент был поте­рян, и отправитель посылает его повторно (рис. 9.8, б). Однако что не означает, что первоначально отправленный сегмент не дошел до полу-чаге.тя. Например, он мог задержаться в сети па время, большее чем тайм-аут ретрансмиссии, или мог потеряться сегмент с подтверждени­ем. Если первоначально отправленный сегмент все-таки прибудет, то данные повторно переданных сегментов окажутся вне окна приема и будут отброшены.

90