Установление и закрытие соединений

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

q Инициатор соединения посылает запрос к протоколу TCP на открытие порта для передачи.

q После открытия порта протокол TCP на стороне приложения-инициатора посылает запрос приложению, с которым требуется установить соедине­ние (принимающей стороне).

q Протокол TCP на принимающей стороне открывает порт для приема дан­ных и отсылает квитанцию, подтверждающую прием запроса.

q Принимающая сторона открывает порт для передачи и также передает запрос к противоположной стороне.

q Приложение-инициатор открывает порт для приема и возвращает квитан­цию. С этого момента соединение считается установленным. После этого начинается обмен информацией по данному соединению.

При передаче данных по соединению каждый байт информации нумеруется. Нумерация ведется и в очереди отправления и в очереди получения. Первона­чальный номер байта в очереди отправки указывается модулем TCP посылаю­щей стороны, а первоначальный номер байта в очереди приема выясняется во время установления соединения. В это время оба модуля протокола TCP долж­ны синхронизировать друг с другом первоначальные номера байтов в очередях. Синхронизация производится путем обмена сегментами, которые используются при установке соединения. Эти сегменты несут флаг синхронизации SYN и ис­ходные номера для обоих очередей. Синхронизация требует, чтобы каждая сто­рона послала свой собственный первоначальный номер в очереди и получила подтверждение о принятии этого номера. Нумеруются и сами сегменты: номе­ром сегмента считается номер первого байта в поле полезной нагрузки этого сегмента. Рассмотрим синхронизацию номеров на примере создания соединения между станцией А и станцией Б. Для синхронизации необходимо выполнить следующие действия:

1. Станция А посылает сегмент с флагом SYN и своим номером в очереди N станции Б;

2. Станция Б посылает подтверждение — «ваш номер в очереди N» — стан­ции А;

3. Станция Б посылает сегмент с флагом SYN и своим номером в очереди (обозначим его К) станции А;

4. Станция А посылает подтверждение — «ваш номер в очереди К» — стан­ции Б.

Шаги 2 и 3 можно объединить, поэтому такой обмен называется открытием соединения с подтверждением трех сообщений. Эту же процедуру открытия со­единения с подтверждением трех сообщений можно показать с фиксацией состо­яний соединения и переходов между ними (рис. 7.5). Каждая строка на рис. 7.5 пронумерована и показывает состояние соединения. Стрелки «→» означают от­правление сегмента от модуля TCP станции А в модуль TCP станции Б. Стрел­ки «←» показывают отправку сегментов в противоположном направлении. Промежуточное состояние соединения соответствует моменту посылки или по­лучения сегмента. На рис. 7.5 показано не все содержание сегментов — приведе­ны только номера в очереди, флаги управления и АСК.

Станция А указывает, что она будет использовать номер в очереди 100. В ответ станция Б посылает свой номер в очереди 300 и говорит, что ожидает получения номера 101. В последней строке после установления соединения модуль TCP станции А передает некоторую порцию данных.

На рис. 7.6 показана нормальная, штатная процедура закрытия соединения.

Как видно, при закрытии соединения происходит обмен сегментами, несу­щими управляющий флаг FIN, указывающий на отсутствие данных для пере­дачи.

Плавающее окно

Как и большинство протоколов, осуществляющих управление потоком данных (например, HDLC и Х.25), протокол TCP использует механизм плавающих окон. Протоколы HDLC и Х.25 используют этот механизм в классическом ви­де — на каждый отправленный блок данных должно быть получено подтвержде­ние. Протокол TCP несколько отходит от классической схемы.

Основной недостаток классической схемы заключается в том, что только один сегмент может быть передан за один сеанс. В данном случае под сеансом понимается посылка сегмента и получение подтверждения на его успешный прием. Такая схема не позволяет работать с максимальной производительнос­тью. Эффективность может быть значительно повышена, если разрешить пере­дачу множества сегментов за один сеанс с группировкой всех подтверждений для них в одно.

Рассмотрим схему работы этого метода на примере двух станций — А и Б, которым необходимо обмениваться данными. Станция Б выделяет буферное пространство для приема п сегментов. Поэтому станция Б может принять п сег­ментов, а станция А может послать те же п сегментов без необходимости ожи­дания подтверждений об их приеме. Для отслеживания подтверждений о принятых сегментах каждый из них помечается номером в последовательности. Станция Б подтверждает получение сегмента посылкой подтверждения на него, которое содержит номер в последовательности следующего ожидаемого сегмен­та. Это подтверждение также косвенным образом извещает станцию А о том, что станция Б готова получить следующие п сегментов, начиная с указанного номе­ра. Такая схема работы годится для подтверждения получения множества сег­ментов. Например, станция Б получает сегменты 2, 3 и 4, но воздерживалась от отправки подтверждения на сегменты 2 и 3 до получения сегмента 4. Посылая подтверждение с номером в последовательности 5, станция Б подтверждает получение сегментов 2, 3 и 4 за один раз. Таким образом, можно сказать, что станция А ведет список номеров в последовательности сегментов, которые ей разрешено посылать, а станция Б поддерживает список номеров в последова­тельности сегментов, которые она готова принять. Эти списки называют окнами сегментов, а такую схему передачи сообщений часто называют управлением по­током с использованием плавающего окна.

Так как номер в последовательности занимает одно поле в сегменте, то оче­видно, что номер не может быть слишком большим. Например, если это поле занимает 3 бита, то номер в последовательности сегментов может иметь значе­ния от 0 до 7. Соответственно, сегменты нумеруются по модулю 8, то есть за номером в последовательности 7 следует номер в последовательности 0. Таким образом, для поля номера в последовательности, состоящего из k бит, границы изменения номера равны 0 и 2^k-l, а сегменты нумеруются по модулю 2^k. С уче­том приведенных рассуждений на рис. 7.7 показаны значения передаваемых и принимаемых сегментов на принимающей и передающей сторонах с фиксацией границ плавающего окна. В этом примере для простоты размер поля «Номер в последовательности» принят равным 3 битам. Серые прямоугольники указыва­ют сегменты, которые могут быть посланы. В соответствии с рис. 7.7 отправитель может послать 5 сегментов, начиная с сегмента с номером 0. Каждый раз, когда сегмент посылается, ширина окна (серого прямоугольника) уменьшается. При получении подтверждения ширина окна увеличивается. Сегменты, находя­щиеся между черной вертикальной чертой и серым прямоугольником (окном) уже были посланы, но еще не были подтверждены. Отправитель должен хранить копии этих сегментов в своем буфере на случай, если потребуется их повторная передача.

Рассмотрим следующий пример (рис. 7.8), позволяющий проследить после­довательность обмена информацией. В этом примере для наглядности поле но­мера в последовательности имеет длину три бита, следовательно, максимальный номер равен 7 и окно не может содержать более семи номеров сегментов.

В начале работы станции А и Б имеют окна длиной семь сегментов. То есть, станция А может передать семь сегментов, начиная с сегмента SO, а станция Б — принять такое же количество сегментов. После передачи трех сегментов (SO, S1 и S2) без подтверждения станция А сокращает размер своего окна до четырех сегментов и сохраняет в буферной памяти копию трех посланных сегментов. Новый размер окна указывает на то, что станция А может передать четыре сег­мента, начиная с сегмента S3. Станция Б после получения сегментов передает сообщение RR3, в котором заложена следующая информация: «Я приняла все сегменты до номера S2 включительно и готова принять сегмент S3; в действи­тельности я готова принять семь сегментов, начиная с сегмента S3». После по­лучения подтверждения с такой информацией станция А считает себя вправе передать семь сегментов, начиная с сегмента S3. Кроме того, станция А может очистить свою буферную память от копий первых трех сегментов, так как они были успешно приняты. Теперь станция А передает сегменты S3, S4, S5 и S6. Станция Б в ответ на получение сегмента S3 отправляет подтверждение RR4 и позволяет производить передачу сегментов с номерами от S4 до S2 (этот сегмент относится уже к следующей последовательности из семи сегментов). На момент получения станцией А этого подтверждения сегменты S4, S5 и S6 уже были посланы и, следовательно, станция А может расширить свое окно и послать четыре сегмента, начиная с сегмента S7.

Пропускная способность

Рассмотрим методы определения максимально возможной пропускной способ­ности соединения протокола TCP. Пропускная способность зависит от размера окна передачи, задержки и скорости пересылки данных. Используем следующие обозначения:

q W — размер окна передачи в байтах;

q R — скорость передачи данных (бит/с) по определенному соединению, до­ступная на стороне отправителя;

q D — задержка (в секундах) при передаче данных между отправителем и получателем через определенное соединение.

Для простоты рассуждений проигнорируем влияние служебных битов в сег­менте TCP. Предположим, что отправитель начинает передавать последователь­ность байтов получателю через установленное соединение. Для того чтобы первый байт достиг получателя, потребуется время, равное D. Такое же время — D секунд — потребуется для получения подтверждения. В течение этого време­ни отправитель может передать 2RD бит, или RD/4 байт. На самом деле, отпра­витель ограничен размером окна в W байт и не может сдвигать окно, пока не получит подтверждение. Только при W> RD/4 на этом соединении достигается максимально возможная пропускная способность. Если W<RD/4, то близость пропускной способности к максимальной определяется отношением W к RD/4. Следовательно, нормированная пропускная способность S может быть выражена как:

На рис. 7.9 показан пример определения максимальной пропускной способ­ности в зависимости от произведения RD. Максимальный размер окна может составлять 2¹⁶-l=65 535 байт. Такой размер окна должен быть достаточен для большинства приложений. В качестве примера давайте разберем три различные технологии, применяемые для передачи сегментов TCP и использующие такой размер окна. Для технологии Gigabit Ethernet с длиной магистрали, равной 100 м, произведение RD будет меньше, чем 10³ бит. На больших расстояниях, пусть даже при более низких скоростях, например, в случае использования ка­нала Т1 (1.544 Мбит/с), произведение RD становится большим, следовательно, эффективность падает. Тем не менее, она остается, как видно из рис. 7.9, прием­лемой — около 0.8. На значительных расстояниях при дальнейшем увеличении скорости (допустим, речь идет о передаче информации с использованием тех­нологии SDH (канал 155 Мбит/с) между двумя городами) рассматриваемая тех­нология становится крайне неэффективной — как видим, нормализованная пропускная способность падает до 0.1. Очевидно, что в данном случае размер окна слишком мал. Необходимо использовать другой параметр масштабирова­ния окна, который позволил бы эффективно задействовать пропускную способность канала. Достаточно увеличить параметр масштабирования окна до 4 — это приведет к значительному увеличению размера окна до 2²⁰-1 » 106 байт.

Как видим, перечисленные выше параметры оказывают основное влияние на эффективность передачи протокола TCP. Однако существует множество услож­няющих факторов, которые также следует принять во внимание. Во-первых, в большинстве случаев соединения TCP мультиплексируются в один канал, так что каждое соединение получает часть его доступной пропускной способности. Это приводит к снижению скорости передачи R и, следовательно, к снижению эффективности работы протокола. Во-вторых, большинство соединений TCP проходят через маршрутизаторы. В этом случае время D будет равно сумме за­держек в каждой сети и задержек на каждом маршрутизаторе в пути. При этом суммарная задержка на маршрутизаторах часто вносит основной вклад во время задержки D, особенно при возникновении перегрузок. В-третьих, значение ско­рости R, используемое в приведенной выше формуле, определяет скорость пере­дачи данных, доступную для соединения, только на стороне отправителя. Если на одном из переходов в пути от отправителя до получателя скорость передачи меньше этой скорости, то попытка передачи на максимальной скорости приведет к образованию узкого места, что неизбежно повысит время D. И наконец, в-чет­вертых, если сегмент теряется, он должен быть передан вновь, что приводит к снижению пропускной способности. Степень влияния потерь сегментов на эф­фективность передачи зависит от политики повторных передач. В современных распределенных сетях несколько сегментов протокола TCP могут быть потеря­ны из-за ошибок на линиях. Большинство же сегментов теряются при исполь­зовании механизмов сброса пакетов на маршрутизаторах или коммутаторах (например, Frame Relay) в моменты сетевых перегрузок.

Контроль за перегрузками

Контроль за перегрузками в сетях IP достаточно сложно реализовать по целому ряду причин. К ним можно отнести следующие:

q Протокол IP не ориентирован на установление соединения. Он не обеспе­чивает обнаружение перегрузки и по этой причине не может быть исполь­зован для контроля за перезагрузками.

q Протокол TCP осуществляет контроль потока из конца в конец соедине­ния и может лишь по косвенным признакам определить перегрузку в сети. Более того, так как задержки в распределенных сетях постоянно изменя­ются, то информация, полученная на основании косвенных признаков (на­пример, размер окна), не является достоверной.

q Не существует распределенного алгоритма для связывания различных протоколов TCP. To есть, протоколы на разных компьютерах не могут взаимодействовать друг с другом для поддержания определенного уровня общего потока. Более того, на самом деле они ведут себя очень «эгоистич­но» по отношению к свободным ресурсам канала.

Сообщение «Подавление источника» (Source Quench) протокола ICMP мож­но рассматривать в качестве грубого инструмента, предназначенного для сдер­живания потока трафика от отправителя, но его нельзя назвать эффективным методом контроля за перегрузками.

Задачу контроля за перегрузками можно возложить на протокол RSVP, но его широкое распространение — еще вопрос времени.

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

Управление потоком данных

Управление потоком данных использует механизм плавающего окна, но кроме этого, применяется также более гибкая схема приема/передачи данных и отсыл­ки подтверждений на успешный прием данных. Управление потоком протокола TCP использует так называемую схему с выделением лимита на передачу дан­ных. По этой схеме каждый передаваемый байт имеет свой собственный номер в последовательности (SN). Когда протокол TCP посылает сегмент, он выстав­ляет в поле номера в последовательности номер первого байта в поле данных этого сегмента. На принимающей стороне пришедший сегмент подтверждается сообщением, в котором указывается (А= i, W=j). Такая запись имеет следующее значение: если величина А (АСК) равна г, это значит, что сообщение подтверж­дает получение всех байтов, вплоть до номера в последовательности i—1; сле­дующие ожидаемые байты имеют номер в последовательности i. Кроме того, выдается разрешение на посылку дополнительного окна W (Window) из j байтов; то есть байтов с номерами в последовательности от i до i +j - 1. На рис. 7.10 иллюстрируется работа этого механизма. В отличие от рис. 7.9, окна передачи и приема указывают количество байтов данных.

Для большей наглядности покажем поток данных, идущий только в одном направлении, и предположим, что в каждом сегменте посылаются 200 байт дан­ных. Во время установления соединения номера в последовательностях отпра­вителя и получателя синхронизированы и станция А имеет начальный лимит на отсылку данных 1400 байт, начиная с номера байта 1001. После посылки 600 байт в трех сегментах станция А уменьшает свое окно отсылки до 800 байт (номера с 1601 до 2400). После получения этого сегмента станция В подтверж­дает получение всех байтов, вплоть до 1601, и формирует свое окно приема на 1000 байт. Это означает, что станция А может посылать байты, начиная с номера 1601 и заканчивая номером 2600, то есть пять сегментов. Однако к тому момен­ту, когда сообщение от станции В доходит до станции А, последняя уже успела выслать два сегмента, содержащие байты 1601-2000, что позволял начальный лимит. Следовательно, оставшийся лимит станции А на этот момент составляет всего 400 байт или два сегмента. Во время обмена станция А продвигает левую границу своего окна каждый раз, когда осуществляет передачу. Правая граница передвигается только тогда, когда станция получает новый лимит.

На практике обе стороны одновременно задействуют режимы передачи и приема, так как данные могут передаваться в обоих направлениях (происходит полнодуплексная передача). Механизм выделения лимита является достаточно гибким. Например, рассмотрим ситуацию, при которой последнее сообщение, посланное станцией В, было (A=i, W=j). Последним байтом данных, получен­ным станцией В, был байт с номером i -1. Для увеличения лимита до значения k, при условии, что kj и дополнительные данные не поступали, станция В фор­мирует сообщение (A= i, W= k). Для подтверждения входящего сегмента, содер­жащего т байт данных (т) без выделения дополнительного лимита, станция В формирует сообщение (A =i+m, W =j-m).

Следует отметить, что от получателя не требуется немедленного подтвержде­ния приходящих сегментов. Он может ожидать некоторое время, а затем сфор­мировать подтверждение сразу на несколько сегментов. Получатель должен проводить какую-то политику, регулирующую количество данных, которое он позволяет передавать отправителю. Можно выделить две политики получателя: консервативную и оптимистическую. Консервативная схема управления пото­ком основана на том, что лимит выделяется в соответствии с имеющимся до­ступным буферным пространством. Если это правило применить к ситуации, показанной на рис. 7.10, то первое лимитирующее сообщение говорит о том, что станция В может разместить 1000 байт в своем буфере, а второе — о том, что станция В может разместить 1400 байт. Консервативная схема управления пото­ком может ограничить пропускную способность логического соединения в ситу­ации, когда в сети возникают большие задержки.

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