Управление перегрузкой и основные алгоритмы работы TCP

Разбить на страницы

Показывать лекцию целиком

Управление перегрузкой

Как мы уже говорили, Интернет — комбинация сетей и устройств связи, например, таких как маршрутизаторы. Пакет, стартующий от передатчика, может пройти через несколько маршрутизаторов, прежде чем достигнет своего конечного пункта назначения. Маршрутизатор имеет буфер, который накапливает входящие пакеты, обрабатывает их и передает их вперед. Если пакеты поступают к маршрутизатору быстрее, чем он может их обработать, может возникнуть перегрузка и некоторые пакеты могут быть потеряны. Если пакет не принят конечным пунктом, то конечный пункт не присылает подтверждения. Передатчик не имеет выбора, кроме как передать повторно потерянный пакет. Это может привести к перегрузке и увеличению пропадания пакетов, которое означает снова повторную передачу и большую перегрузку. Затем может быть достигнута точка, в которой система не сможет больше передавать данные. Поэтому TCP нуждается в механизмах, позволяющих избежать этой ситуации.

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

Окно перегрузки

Сегодня размер окна передатчика определяется не только приемником, но также перегрузкой в сети. Передатчик имеет два кванта информации: размер окна, объявленный приемником, и размер окна перегрузки. Действующий размер окна – минимальный из этих двух размеров.

Предотвращение перегрузки

Чтобы избежать перегрузки, передатчик TCP использует две стратегии. Мы называем одну медленный старт и дополнительное увеличение и вторую — мультипликативное уменьшение.

Медленный старт и увеличение прибавлением

Это – комбинация двух стратегий: медленного старта и дополнительного увеличения.

Медленный старт. В начале соединения TCP устанавливает размер окна перегрузки на максимальный размер сегмента. Для каждого сегмента, который подтвержден, TCP увеличивает размер окна перегрузки по одному максимальному размеру сегмента, пока он не достигнет порога половины разрешенного размера окна. Это называется медленным стартом, который полностью обманчив, потому что этот процесс не такой медленный. Размер окна перегрузки увеличивается экспоненциально. Передатчик посылает один сегмент, получает одно подтверждение, увеличивает размер до двух сегментов, посылает два сегмента, получает два сегмента, увеличивает размер до четырех сегментов, посылает четыре сегмента, получает подтверждение для четырех сегментов, увеличивает размер до восьми сегментов и так далее. Другими словами, после получения третьего подтверждения размер окна увеличивается до восьми сегментов. Скорость роста окна — экспоненциальная 2³ = 8.

Увеличение прибавлением. Чтобы избежать перегрузки, прежде чем она возникнет, нужно замедлить этот экспоненциальный рост. После того как размер достигает порога, размер окна увеличивается на единицу для каждого подтверждения, даже если подтверждаются последовательные сегменты. Стратегия дополнительного увеличения продолжается, пока подтверждения прибывают прежде срабатывания их соответствующих тайм-аутов или пока размер окна перегрузки не достигнет значения окна приемника.

Мультипликативное уменьшение

Если возникнет перегрузка, окно перегрузки должно быть уменьшено. Передатчик может единственным путем предположить, что возникла перегрузка из-за потерянного сегмента. Если передатчик не получит подтверждение, прежде чем сработает его таймер повторной передачи, он предполагает, что это перегрузка. Поскольку сети сегодня имеют сравнительно малый уровень шума, более вероятно, что сегмент потерян, чем искажен. Стратегия гласит: если окончилось контрольное время, размер текущего окна должен быть установлен на величину половины размера последнего окна перегрузки, размер окна перегрузки должен опять начинаться с единицы. Другими словами, передатчик возвращается медленно к начальной фазе. Заметим, что размер порога уменьшается экспоненциально (мультипликативное уменьшение). Рис. 11.1. показывает идею мультипликативного уменьшения.

(рис 11.1) Мультипликативное уменьшение

На Рис. 11.1. максимальный размер окна — 32 сегмента, а порог установлен до 16 сегментов (половина максимального значения размера окна). При процедуре медленный старт размер окна начинается от 1 и растет экспоненциально, пока не достигнет порога 16 при условии, что не истечет время тайм-аута.

После достижения порога процедура дополнительного увеличения позволяет наращивать линейно по 1 байту, пока не сработает тайм-аут или размер не достигнет максимального окна (32). На рисунке возник таймаут, когда был послан сегмент 8. В этот момент вступает в действие процедура мультипликативного уменьшения и уменьшает порог до половины предыдущего размера окна; предыдущий размер окна был 20, когда появился тайм-аут, так что новый порог теперь 10.

Этот цикл (медленный старт, дополнительное увеличение, мультиплексное уменьшение) продолжается с этим размером окна опять с единицы. Рис. 11.2. показывает ту же самую идею.

(рис 11.2) Стратегия предотвращения перегрузки

Сегмент

Сегмент – это единица данных, передаваемых между устройствами, которые используют TCP ( Рис. 11.3.). Формат сегмента TCP состоит из 20–60-байтных заголовков и следующих за ними данных для прикладной программы. Заголовок – это 20 байт, если не имеет опций, и 60 байт, если состоит из нескольких опций.

(рис 11.3) Формат заголовка TCP сегмента

Обсудим некоторые поля заголовков. Смысл и цель их должны быть ясными, поскольку эти поля уже неоднократно рассматривались по всей книге, правда, в других приложениях.

Адрес порта источника. Это поле длиною 16 бит, определяющее номер порта прикладной программы в хосте, в который посылает сегмент. Это обслуживание имеет ту же самую цель, что адрес источника в заголовке UDP, обсуждавшемся ранее (см. рис. 9.1.).

Адрес порта пункта назначения. Это поле длиною 16 бит, определяющее номер порта прикладной программы в хосте, который получает сегмент. Это поле имеет ту же самую цель, что и адрес порта назначения в заголовке UDP, рассмотренном ранее (см. рис. 9.1.). В течение соединения каждая сторона использует случайный номер, чтобы создать начальный порядковый номер (ISN – initial sequence number), который обычно отличается в каждом направлении. Например, если ISN – 2 368 и первый сегмент переносит 1000 байт, порядковый номер – 2 369 (2 367 и 2 368 используются для установления соединения); второй сегмент после 1000 байтного сегмента, переносит 500 байт. Он будет иметь номер 3 369, и так далее. Пункт назначения может определить номер последнего байта для определения размера блока данных. Порядковые номера рассматривались в разделе управления потоком и протокола скользящего окна.

Порядковый номер. Это поле на 32 бита определяет номер, назначенный от первого бита данных, которые содержатся в этом сегменте. Как мы уже говорили прежде, TCP — протокол транспортного уровня. Чтобы гарантировать возможность взаимодействия, каждый байт должен быть передан нумерованным. Порядковый номер говорит пункту назначения, каков байт в этой последовательности по сравнению с первым байтом сегмента.

Номер подтверждения. Это поле занимает 32 бита и определяет номер байта, который ожидает приемник сегмента от другой стороны. Если приемник сегмента успешно принял байт с номером x от другой стороны, он определяет номер подтверждения как x+1.

Длина заголовка. Это поле длиной 4 бита указывает номер 4-байтного слова в TCP заголовке. Эта длина заголовка может быть между 20 и 60 байтами. Поэтому значение этого поля может быть между 5 (5 x 4 = 20) и 15 (15 x 4 = 60).

Зарезервировано. Это поле 6 бит, зарезервировано для будущего использования.

Управление. Это поле определяет 6 различных управляющих бит, или флагов, как это показано на Рис. 11.3.

Эти биты способны управлять потоком, установлением соединения и оконечными устройствами, а также режимом передачи TCP. Короткое описание каждого из бит дано в таблиц 11.1.

Описание флагов в поле управления
Флаг	Описание
Срочно	Указатель срочности сообщения
Подтверждение	Подтверждает правильность действия
Запуск	Запуск данных
Повтор	Соединение должно быть переустановлено
Синхронизация	Порядковый номер синхронизации в течение соединения
Конечное	Оконечное соединение

Размер окна. Это поле определяет размер окна в байтах, который может использовать другая сторона. Заметим, что длина этого поля – 16 бит, что означает максимальный размер окна – 65 535 байт.

Контрольная сумма. Это поле на 16 бит, которое действительно, только если установлен срочный флаг, и используется, когда сегмент содержит срочные данные. Оно определяет, что должно быть дополнено к порядковому номеру, чтобы получить номер последнего и срочного байта в секции данных сегмента. Это будет обсуждаться позднее.

Опция. В ТСР-заголовке может быть до 40 байт информации опций. Мы обсудим различные опции, используемые в TCP-заголовках, в следующей секции.

Опции

Заголовок TCP может содержать до 40 байт информации опций. Опции передают дополнительную информацию для пункта назначения или выравнивают другие опции. Определены две категории опций: однобайтовая и многобайтовая опция. Первая категория имеет два типа опций: оконечная опция и нет операции. Вторая категория содержит три типа опций: размер максимального сегмента, коэффициент масштаба, а также метку времени ( Рис. 11.4.).

(рис 11.4) Опции

Конец опции. Это опция в 1 байт используется для заполнения поля опции, чтобы выровнять формат. Она должна быть использована только как последняя опция и только с одного конца. После этой опции приемник ищет полезную нагрузку. Иногда поле опции может содержать более чем один байт. Это означает, что необходимо выровнять поле опции, используя несколько опций типа "нет операции" (ничего не делать), после чего поставить конец опции ( Рис. 11.5.). Конец опции несет три значения информации для конечного пункта, она указывает, что:

нет больше опций в заголовке;

остаток от последнего 32-битового слова – это мусор и его можно не обрабатывать;

данные от прикладной программы стартуют с начала следующего 32-битового слова.

(рис 11.5) Конец опции

Нет операций. Эта опция ( Рис. 11.6.) в один байт используется как разделитель между опциями. Например, она может применяться для выравнивания следующей опции до 32-битовой границы.

(рис 11.6) Опция "нет операции"

Максимальный размер сегмента (MSS – Maximum segment size). Эта опция определяет размер наибольшего куска данных, который может быть получен пунктом назначения сегмента TCP. Вопреки своему имени она определяет максимальный размер данных, но не максимальный размер сегмента. В то же время, поле длиной 16 бит может быть значением 65 535 байт. Значение по умолчанию — 536.

Максимальный размер данных определяется в течение фазы установления соединения. Размер определяется пунктом назначения сегмента, но не источником. Так, сторона 1 определяет MSS стороны 2. Сторона 2 определяет, что должно быть MSS, посланным со стороны 1. Если ни та, ни другая сторона не определяет размер, он выбирается по умолчанию.

Эта опция применяется только в сегментах, которые осуществляют соединение. Она не может использоваться в сегментах в течение передачи. Рис. 11.7. показывает формат этой опции. Он содержит код опции, общую длину опции и значение опции.

(рис 11.7) Опция "максимальный размер сегмента"

Масштабный коэффициент окна. Поле размера окна в заголовке определяет размер скользящего окна. Это поле 16 бит длины, что означает, что окно может иметь рамки от 0 до 65 535. Хотя этот размер окна кажется очень большим, он еще может не быть эффективным, в частности, если данные проходят среду с высокой пропускной способностью с малыми задержками передачи.

Возьмем, например, канал оптического кабеля (OC-24), имеющего пропускную способность 1 244 160 Мбит/с и соединяющего два компьютера куском 6000 миль. Когда одна станция посылает данные другой, требуется по меньшей мере 64 мс, чтобы принять подтверждение. В течение этого периода могут быть посланы 10 Мбайт. Однако размер окна позволяет станции послать только 65 535 байт.

Для того чтобы увеличить размер окна, используется масштабный коэффициент окна. Новый размер окна находится повышением в 2 раза числа, заданного масштабным коэффициентом окна. Затем этот результат умножается на значение размера окна в заголовке.

Размер нового окна = размер окна, определенный в заголовке x 2^{масштабный элемент окна}.

Например, если значение масштабного коэффициента окна равно 3, действующий размер окна есть восьмикратное значение размера окна. Масштабный коэффициент может иметь значение не более 16 — наибольшее из позволяемых TCP/IP, то есть максимальный размер окна может быть 2¹⁶ x 2¹⁶ = 2³² и совпадать с максимальным значением порядкового номера. Заметим, что размер окна не может быть больше, чем максимальное значение порядкового номера.

Масштабный коэффициент окна может быть определен только во время фазы установления соединения. Во время передачи данных размер окна (заданный заголовком) может изменяться, но он может быть умножен на тот же самый масштабный коэффициент. Формат опции масштабного коэффициента показан на Рис. 11.8. Он содержит код опции, общую длину опции и значение масштабного коэффициента.

(рис 11.8) Опция "масштабный коэффициент окна"

Масштабный коэффициент иногда называют сдвигающим счетчиком, потому что умножение числа на величину 2 – это то же самое, что операция побитового сдвига влево.

Метка времени. Это 10-битовая опция с форматом, показанным на Рис. 11.9. Поле метки времени заполняется источником, когда сегмент покидает источник. Пункт назначения получает сегмент и накапливает значение метки времени. Когда пункт назначения посылает подтверждение байтов в этом сегменте, он вводит накопленное предыдущее значение в поле "эхо ответа". Источник, когда получает подтверждение, проверяет текущее время по сравнению с этим значением. Разность – это время прохождения "туда и обратно". Время "туда и обратно" может быть использовано TCP динамически для определения времени повторной передачи, как это уже обсуждалось.

(рис 11.9) Опция "метка времени"

Контрольная сумма

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

Тот же самый псевдозаголовок, предназначенный для тех же самых целей, дополняет сегмент. Для псевдозаголовка TCP значение поля протокола – 6 ( Рис. 11.10.).

(рис 11.10) Псевдозаголовок, дополняемый к TCP дейтаграмме

Соединение

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

В TCP передача, ориентированная на соединение, требует двух процедур: установления соединения и окончания соединения.

Установление соединения

TCP передает данные в нормальном дуплексном режиме. Когда два TCP в двух компьютерах соединены, они могут послать друг другу данные одновременно. Это предполагает, что каждая сторона может инициализировать коммутацию и получить одобрение другой стороны перед каждой передачей данных. Предпринимаются четыре действия, прежде чем названные здесь хост A и хост B смогут послать данные.

Хост A посылает сегмент, чтобы известить о своем желании установить связь, и включает в сообщение начальную информацию о трафике от A к B.

Хост B посылает сегмент для подтверждения запроса A.

Хост B посылает сегмент, который включает его начальную информацию о трафике между A и B.

Хост A посылает сегмент, чтобы подтвердить запрос B.

Это установление соединения достигается в четыре шага. Однако шаги 2 и 3 могут возникнуть одновременно, они могут быть скомбинированы в один шаг. Хост B может завершить запрос хоста A и послать свой собственный запрос в одно и то же время.

Метод взаимодействия в три шага

Установление соединения, рассмотренное выше, называется методом взаимодействия в три шага. В этой процедуре прикладная программа, называемая "клиент", желает установить связь с другой прикладной программой, называемой "сервер", используя TCP как транспортный протокол.

Процедура тройного подтверждения связи начинается с сервера. Программа сервера говорит ему, что TCP готов принять соединение. Это называется запросом пассивного открытия. Хотя сервер TCP готов принять любое соединение от любого компьютера в мире, но он не может сам установить это соединение.

Программа клиента делает запрос на активное открытие. Клиент, который хочет подключиться к серверу, сообщает своему TCP, что ему надо подсоединится к конкретному серверу. TCP может теперь начинать процесс взаимодействия в три шага, как это показано на Рис. 11.11.

Имеются следующие шаги этого процесса:

Клиент посылает первый сегмент — SYN-сегмент. Этот сегмент включает номера источника и пункта назначения. Пункт назначения явно определяет сервер, к которому клиент хочет подсоединиться. Сегмент, содержащий начальный порядковый номер клиента (ISN – Initialization Sequence Number), в примере он равен 1200, также используется для нумерации байтов данных, посылаемых от клиента к серверу. Если клиент хочет определить максимальный размер сегмента (MSS — Maximum Segment Size), который он может принимать от сервера, он может дополнить тут же соответствующую опцию. Также если клиенту надо большее окно, он задает масштабный коэффициент окна, используя соответствующую опцию. Этот сегмент определяется желанием клиента сделать соединение с определенного рода параметрами. Заметим, что этот сегмент не содержит никаких номеров подтверждения. Он не определяет размера окна; размер окна передается, только когда сегмент содержит подтверждение.

Сервер посылает второй сегмент, SYN + ACK. Этот сегмент имеет двойную цель. Первая: подтверждение получения первого сегмента, использующего флаг ACK и поле подтверждающего номера. Подтверждающий номер – это начальный номер клиента плюс один (1201). Сервер должен также определить размер окна клиента. Второй сегмент воспринимается как начальный сегмент для сервера. Он содержит начальный порядковый номер (4800), используя номер байта, посланного от сервера к клиенту. Он также содержит опцию масштабного коэффициента окна (если это надо) для использования сервером и MSS, определенный сервером. Как мы говорили раньше, это два сегмента, скомбинированные в один.

Клиент посылает третий сегмент. Это только сегмент ACK. Он подтверждает сообщение второго сегмента, использующего ACK. Он содержит поле подтверждающего порядкового номера: это начальный порядковый номер сервера плюс единица (4801). Клиент должен также определить размер окна сервера. Заметим, что данные могут быть посланы с третьим пакетом.

(рис 11.11) Метод взаимодействия в три шага

Нестандартная ситуация может возникнуть, когда оба процесса создадут активное открытие. В этом случае оба TCP пошлют друг другу сегмент SYN + ACK, и между ними будет установлено одно-единственное соединение.

Окончание соединения

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

Хост A посылает сегмент, извещающий о его желании закончить соединение.

Хост B посылает сегмент, подтверждающий запрос A. После этого завершает соединение в одном направлении, но не в другом. Хост B может продолжить послать данные к A.

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

Хост A подтверждает запрос B.

Шаги 2 и 3 могут возникнуть одновременно, соединение может быть завершено в одном направлении, но остаться открытым для другого направления.

Метод взаимодействия в четыре шага

Окончание соединения, приведенное выше, называется методом взаимодействия в четыре шага. В этой процедуре прикладная программа, обычно клиент, хочет завершить соединение.

Процедура начинается с клиента. Программа клиента говорит TCP, что она оканчивает передачу данных и желает завершить соединение. Это – запрос на действия по окончанию.

После получения запроса на действия по окончанию клиент TCP закрывает связь в направлении клиент-сервер. Однако связь в другом направлении еще открыта.

Когда программа сервера закончит посылку данных в направлении сервер-клиент, он может запросить от TCP закрыть соединение в направлении сервер-клиент. Это обычно пассивное окончание. Метод взаимодействия в четыре шага показан на Рис. 11.12.

(рис 11.12) Метод взаимодействия в четыре шага

Четыре шага – это:

Клиент TCP посылает первый сегмент, FIN-сегмент.

Сервер TCP посылает второй сегмент, ACK-сегмент, чтобы завершить получение FIN-сегмента от клиента. В этом сегменте он использует подтверждающий номер, который равен единице плюс порядковый номер, полученный в FIN-сегменте.

TCP-сервер может продолжить передачу данных в направлении сервер-клиент. Когда он не имеет больше данных, он посылает третий сегмент. Этот сегмент – FIN-сегмент.

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

Переустановление соединения

TCP может запросить переустановление соединения для несуществующего порта. Переустановление здесь означает, что текущее соединение нарушено. Это случается в одном из трех случаев:

TCP на одной стороне запросил соединение к не существующему порту. TCP на другой стороне может послать сегмент с RST(Reset — переустановление)-битом, установленным, чтобы аннулировать запрос.

Один TCP может прервать соединение из-за ненормальной ситуации. Он может послать сегмент переустановления (RST), чтобы закончить соединение.

TCP на одной стороне может обнаружить, что TCP на другой стороне свободен длительное время. Он может послать RST-сегмент для разрушения соединения.

Операции TCP

Проталкивание данных

Как уже обсуждалось, передающий TCP использует буфер, чтобы накопить поток данных, поступивших от передающих прикладных программ; а передающий TCP может выбрать размер сегментов. Принимающий TCP также применяет буферы данных, когда прибывают сегменты и доставляют их прикладным программам, когда прикладные программы готовы или когда принимающий TCP чувствует, что это удобнее с точки зрения всей сети. Эта гибкость увеличивает эффективность TCP.

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

TCP может обработать такую ситуацию. Прикладная программа на передающей стороне может запросить операцию "протолкнуть" (push). Это означает, что передающий TCP не должен ждать заполнения окна. Он должен создать сегмент и послать его немедленно. Передающий TCP должен также установить push(PSH)-бит, чтобы сказать, что сегмент включает данные, которые должны быть доставлены к принимающей прикладной программе так быстро, как это возможно, и не ждать, пока поступят другие данные.

Хотя операция "проталкивание" может быть запрошена прикладной программой, сегодня большинство реализаций игнорируют такой запрос. TCP может выбирать или нет эту операцию.

Срочные данные

TCP — протокол, ориентированный на поток. Это означает, что данные представляются прикладной программой для TCP как поток символов. Каждый байт данных имеет позицию в потоке. Однако имеются случаи, в которых прикладной программе нужно послать срочный байт. Это означает, что передающая прикладная программа хочет передать вне очереди квант данных приемной программе. Предположим, что передающая прикладная программа посылает данные, обрабатываемые приемной программой. Когда обратно поступит результат обработки, передающая прикладная программа может обнаружить серьезные нарушения. Она захочет прервать процесс, но уже послано огромное количество данных. Если дать команду остановки процесса (Control + C), эти два символа будут накоплены в буфере TCP приемного конца и эта команда будет доставлена к приемной программе после того, как все эти данные будут обработаны, то есть слишком поздно.

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

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

Блок-схема совокупности программ управления TCP

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

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

Совокупность модулей включает таблицу, называемую блоком управления передачей (transmission control block – TCB), установку таймера и три программных модуля. На Рис. 11.13. показаны 5 компонентов и их взаимодействие.

(рис 11.13) Блок-схема TCP

Поскольку в любой момент времени мы можем иметь несколько соединений, TCB сохраняет массивы TCB в форме таблицы. Таблица обычно именуются как TCB ( Рис. 11.14.).

(рис 11.14) Общий вид таблицы TCB

Алгоритм работы главного модуля TCP

Алгоритм работы главного модуля TCP показан на Рис. 11.15.

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

Ниже приводятся таблицы, в которых перечисляются состояния ( таблице 11.2.), входы ( таблице 11.3.), выходы ( таблице 11.4.), используемые в данном алгоритме.

Состояние для TCP
СОСТОЯНИЕ		Описание
Английское обозначение	Русское обозначение	Описание
CLOSED	ЗАКРЫТО	Нет соединения
LISTEN	СЛУШАЮ	Сервер ожидает вызова от клиента
SYN-SENT	ПЕРЕДАЧА	Соединение запрашивает передачу; ожидание подтверждения
SYN-RCVD	ПРИЕМ	Состояние ожидания приема
ESTABILISHED	УСТАНОВЛЕНО	Соединение установлено
FIN-WAIT1	ОЖИДАНИЕ ОКОНЧАНИЯ1	Клиент запросил закрытие соединения
FIN-WAIT2	ОЖИДАНИЕ ОКОНЧАНИЯ2	Другая сторона принимает закрытие соединения
CLOSING	ЗАВЕРШАЮЩЕЕ	Обе стороны решили закрыть соединение одновременно
TIME-WAIT	ВРЕМЯ ОЖИДАНИЯ	Ожидание повторной передачи
CLOSE-WAIT	ОЖИДАНИЕ ЗАКРЫТИЯ	Сервер ожидает закрытия приложения
LAST-ASK	ПОСЛЕДНЕЕ ПОДТВЕРЖДЕНИЕ	Сервер ожидает последнего подтверждения

Входы для TCP
ВХОД		Описание
Английское обозначение	Русское обозначение	Описание
Active open	Активное открытие	Заявка процесса на передачу данных
Passive open	Пассивное открытие	Заявка на входящую связь (ожидается заявка от процесса соединения для приема)
RST	Повторная передача	Запрос на переустановление соединения
Send	Передача	Запрос на передачу
SYN	Запрос	Запрос на соединение
SYN+ ACK	Подтверждение запроса	Подтверждение запроса на соединение
ACK	Подтверждение	Подтверждение сигнала
FIN	Отбой	Запрос на завершение соединения
FIN+ACK	Подтверждение отбоя	Подтверждение сигнала на окончательное соединение
Close	Закончить	Сигнал, о том, что данная сторона закончила соединение
Time-out	Контрольное время	Окончание установленного контрольного времени

Выходы для TCP
ВЫХОД		Описание
Английское обозначение	Русское обозначение	Описание
SYN	Заявка на передачу	Сегмент, который посылается другой стороне, как заявка на передачу
SYN+ACK	Подтверждение заявки	Подтверждение заявки на передачу
ACK	Подтверждение	Подтверждение сигнала
FIN	Отбой	Сигнал, на окончательное завершение
SYN	Запрос на прием	Заявка на соединение для приема
FIN	Отбой	Сигнал, на окончательное завершение
Time-out	Контрольное время	Окончание установленного контрольного времени

Рассмотрим работу алгоритма на Рис. 11.15. (стр. 1-3).

Алгоритм работы главного модуля совокупности программ управления TCP (стр.2)

(рис 11.15) Алгоритм работы главного модуля совокупности программ управления TCP (стр.1)(рис 11.15) Алгоритм работы главного модуля совокупности программ управления TCP (стр.2)

Алгоритм работы главного модуля совокупности программ управления TCP (стр.4)

(рис 11.15) Алгоритм работы главного модуля совокупности программ управления TCP (стр.3)(рис 11.15) Алгоритм работы главного модуля совокупности программ управления TCP (стр.4)

Исходящее соединение

Алгоритм находится в начальном состоянии ЗАКРЫТО (Оператор 1). В данном случае инициатор (клиент) вырабатывает команду для TCP активное открытие (Оператор 10); клиент подключается к прикладной программе и посылает сегмент SYN к серверу как запрос на прием (Оператор 12). После чего алгоритм включает контрольное время (Оператор 12) и переходит в состояние ПЕРЕДАЧА (SYN-SENT) пока он не получит SYN+ACK от TCP — подтверждение запроса на стороне сервера (Оператор 18). Он посылает сегмент ACK другому TCP (Оператор 19) и переходит в состояние УСТАНОВЛЕНО (ESTABLSHED) — Оператор 20 (стр.2). Это состояние передачи данных. Клиент остается в этом состоянии столько времени, сколько он посылает и получает данные.

Если алгоритм не получает сигнала подтверждения запроса SYN+ACK, то заканчивается контрольное время и поступает сигнал окончания тайм-аута (Оператор 15), ресурсы освобождаются и алгоритм переходит в начальное состояние ЗАКРЫТО (CLOSED) — Операторы 16, 17.

В состоянии ESTABLSHED (УСТАНОВЛЕНО) — Оператор 20 (стр.2) — алгоритм может получать данные (Операторы 30-32) или информацию от приложения (Операторы 33-35).

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

В этом состоянии клиент TCP может принять запрос на окончание от прикладной программы клиента. Он посылает сегмент Отбой (FIN) к другому TCP и переходит в состояния ОЖИДАНИЕ ОКОНЧАНИЯ1 – (FIN-WAIT1) — Оператор 36 (стр.3).

В этом состоянии клиент TCP ожидает получить ACK (Оператор 52, стр.3) от сервера TCP. ACK получен, клиент переходит в состояние FIN-WAIT2 (ОЖИДАНИЕ ОКОНЧАНИЯ2) — Оператор 54 (стр.3). Он не посылает ничего. Теперь соединение закрыто в одном направлении.

Клиент остается в этом состоянии, ожидая окончания соединения с другого конца. Если клиент получает сегмент FIN (Отбой) с другого конца — Оператор 55 (стр.3), он посылает сегмент ACK — Оператор 56 (стр.3) и переходит в состояние TIME-WAIT (ВРЕМЯ ОЖИДАНИЯ) — Оператор 42 (стр.3). Когда клиент в этом состоянии, он включает таймер контрольного времени и ждет, пока этот таймер закончится. Значение этого времени устанавливается равным двойному времени передачи максимального размера сегмента. Клиент остается еще некоторое в состоянии неполного закрытия, чтобы дублировать пакет, если какой-либо пакет достигает своего пункта назначения и будет отклонен. После тайм-аута клиент переходит в состояние CLOSED (ЗАКРЫТО) и алгоритм переходит в начальное состояние.

Кроме того, на Рис. 11.15.(стр.3) показаны еще два возможных случая завершения соединения: когда в этом состоянии приходит отбой с другого конца (одновременный отбой) либо отбой приходит вместе с подтверждением.

Входящее соединение

Алгоритм начинает работу в состоянии CLOSED (ЗАКРЫТО) – Оператор 1. В этом состоянии TCP алгоритм может получить запрос на пассивное открытие (Оператор 2). Он переходит в состояние LISTEN (СЛУШАЮ) – Оператор 4. Во время этого состояния TCP-сервер может получить сегмент SYN от клиента TCP – Оператор 5. В этом случае он посылает сегмент SYN+ACK – Оператор 6 — подтверждение заявки на передачу и переходит в состояние SYN–RCVD (Прием) – Оператор 7.

В этом состоянии TCP-сервер может получить сегмент ACK от клиента TCP (Оператор 58 на стр.4). Он переходит в состояние ESTABILISHED (УСТАНОВЛЕНО) – Оператор 20 (стр.2). Это состояние передачи данных. Алгоритм остается в этом состоянии на время получения и передачи данных, после чего выполняется алгоритм, указанный на Рис. 11.15.(стр.2)

В этом состоянии TCP-сервер может получить сегмент CLOSE (оператор 24) от клиента — это означает, что клиент желает завершить соединение. Он может послать сегмент FIN клиенту и перейти к состоянию FIN-WAIT1(ОЖИДАНИЕ ОКОНЧАНИЯ1). Далее выполняется алгоритм по Рис. 11.15.(стр.3)

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

Краткие итоги

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

Чтобы избежать перегрузки, передатчик TCP использует две стратегии. Мы называем одну медленный старт и дополнительное увеличение и вторую — мультипликативное уменьшение.

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

Дополнительное увеличение применяется TCP, чтобы избежать перегрузки до того, как она возникнет, — нужно замедлить этот экспоненциальный рост. После того как размер достигает порога, размер окна увеличивается на единицу для каждого подтверждения, даже если подтверждаются последовательные сегменты.

Стратегия мультипликативного уменьшения состоит в следующем: если окончилось контрольное время, размер текущего окна должен быть установлен на величину половины размера последнего окна перегрузки, размер окна перегрузки должен опять начинаться с единицы. Другими словами, передатчик медленно возвращается к начальной фазе.

Сегмент – это единица данных, передаваемых между устройствами, которые используют TCP. Формат сегмента состоит из 20–60-байтных заголовков и следующих за ними данных для прикладной программы. Заголовок – это 20 байт, если не имеет опций, и 60 байт, если состоит из нескольких полей.

Определены две категории опций: однобайтовая опция и многобайтовая опция. Первая категория имеет два типа опций: оконечная опция и нет операции. Вторая категория содержит три типа опций: размер максимального сегмента, коэффициент масштаба, а также метку времени.

Для установления соединения может быть использована одна из процедур: установление соединения методом взаимодействия в три шага или методом взаимодействия в четыре шага.

TCP может запросить переустановление соединения для несуществующего порта.

Прикладная программа на передающей стороне может запросить операцию "протолкнуть" (push). Это означает, что передающий TCP не должен ждать заполнения окна. Он должен создать сегмент и послать его немедленно. Передающий TCP должен также установить push(PSH)-бит, чтобы сказать, что сегмент включает данные, которые должны быть доставлены к принимающей прикладной программе так быстро, как это возможно, и не ждать, пока поступят другие данные.

Каждый байт данных имеет позицию в потоке. Однако есть случаи, в которых прикладной программе нужно послать срочный байт.

Простейшая блок-схема TCP включает таблицу, называемую блоком управления передачей (transmission control block — TCB), установку таймера и три программных модуля.

Задачи и упражнения

TCP-соединение находится в состоянии УСТАНОВЛЕНО (ESTABILISHED). Далее произошли следующие события:

получен сегмент FIN (ОТБОЙ);

получен сегмент ACK (ПОДТВЕРЖДЕНИЕ).

В какое состояние перейдет соединение после этих событий? Какие действия произойдут при переходе?

TCP-соединение находится в состоянии УСТАНОВЛЕНО (ESTABILISHED). Далее произошли следующие события:

приложение посылает сигнал "закрыть";

получен сегмент ACK (ПОДТВЕРЖДЕНИЕ).

В какое состояние перейдет соединение после этих событий? Какие действия произойдут при переходе?

TCP-соединение находится в состоянии ПРИЕМ (SYN-RCVD). Далее произошли следующие события:

приложение посылает сигнал "закрыть";

получен сегмент ОТБОЙ (FIN).

В какое состояние перейдет соединение после этих событий? Какие действия произойдут при переходе?

TCP-соединение находится в состоянии ПЕРЕДАЧА (SYNSENT). Далее произошли следующие события:

получен сегмент ПОДТВЕРЖДЕНИЕ ЗАПРОСА (SYN + ACK);

получен сегмент "закрыть".

В какое состояние перейдет соединение после этих событий? Какие действия произойдут при переходе?

TCP-соединение находится в состоянии ОЖИДАНИЕ ОКОНЧАНИЯ1 (FIN-WAIT1). Далее произошли следующие события:

получен сегмент ПОДТВЕРЖДЕНИЕ (ACK);

получен сегмент ОТБОЙ (FIN);

сработал тайм-аут.

В какое состояние перейдет соединение после этих событий? Какие действия произойдут при переходе?

Клиент использует TCP для того, чтобы послать данные серверу. Данные имеют размер 16 байт. Вычислите эффективность этой передачи на уровне TCP (отношение полезных байт к общему числу байт).

Дан следующий TCP-заголовок в 16-ричном формате.

05320017 00000001 00000000 500207АА 00000000

Какой номер исходного порта?

Какой номер пункта назначения?

Какой порядковый номер?

Какой подтверждающий номер?

Какова длина заголовка?

Какой тип сегмента?

Какой размер окна?

Дополнительный материал для прохождения тестирования к лекции, Вы можете скачать здесь.

Страницы: