2. Изучение нового учебного материала (способов действий). Цели для преподавателя: - обеспечить понимание планируемого результата деятельности, основных путей его достижения; -способствовать развитию познавательных способностей обучающихся, посредством организации самостоятельной работы. Цели для обучающихся: - рассмотреть протоколы транспортного уровня - рассмотреть протокол TCP - рассмотреть протокол UDP - рассмотреть реализации протокола TCP Цели этапа занятия достигаются посредством: - обеспечения понимания планируемого результата деятельности, основных путей его достижения; - определения критериев, позволяющих обучающимся самостоятельно определять степень достижения запланированного результата; - организации активной самостоятельной деятельности обучающихся по написанию лекции во время занятия.
| 2. Теоретическая часть. В Internet есть два основных транспортных протокола: TCP - ориентированный на соединение и UDP - не ориентированный на соединение. Поскольку сервис, реализуемый протоколом UDP - это практически сервис, реализуемый протоколом IP, с добавлением небольшого заголовка, то основное внимание здесь мы уделим протоколу TCP.
TCP (Transmission Control Protocol) - специально созданный протокол для надежной передачи потока байтов по соединению «точка-точка» через ненадежную сеть. ТСР был сознательно разработан так, чтобы он мог адаптироваться к условиям и особенностям разных сетей, устойчиво и эффективно функционировать в условиях internet (нескольких сетей). На каждой машине, поддерживающей ТСР, есть ТСР-агент, который располагается либо в ядре ОС, либо в процессе пользователя, который управляет ТСР-потоками и доступом к сервису IP-протокола.
ТСР получает поток данных от прикладного процесса, дробит их на сегменты не более чем по 65 Кбайт (на практике не более 1,5 Кбайт) и отправляет их как отдельные IP-пакеты.
Поскольку IP-уровень не гарантирует доставку каждого пакета, то в задачу ТСР входит определение потерь и организация повторной передачи потерянного. Поскольку на сетевом уровне в Internet соединения не поддерживаются, то сегменты могут поступать к получателю в неправильном порядке и задача ТСР - восстановить этот порядок.
Модель сервиса TCP.
Доступ к ТСР-сервису происходит через сокет. Сокет состоит из IP-адреса хоста и 16-разрядного локального номера на хосте, называемого порт. Сокеты создаются как отправителем, так и получателем. Порт - это TSAP для ТСР. Каждое соединение идентифицируется парой сокетов, между которыми оно установлено. Один и тот же сокет может быть использован для разных соединений. Никаких дополнительных виртуальных соединений не создается.
Порты с номерами до 256 зарезервированы для стандартного сервиса. Например, если надо обеспечить FTP-передачу файла, то надо соединяться через 21-й порт, где находится FTP-демон. Для TELNET - через 23-й порт. Полный список таких портов можно найти в RFC 1700.
Все ТСР-соединения - дуплексные, т.е. передача идет независимо в оба направления. ТСР-соединение поддерживает только соединение «точка-точка». Не существует ТСР-соединений от одного ко многим.
ТСР обеспечивает поток байтов, а не поток сообщений. Напомним, это значит, что границы сообщений не поддерживаются автоматически в потоке.
После того, как приложение передало данные ТСР агенту, эти данные могут быть отправлены сразу на сетевой уровень, а могут быть буферизованы, как поступить - решает ТСР-агент. Однако в ряде случаев надо, чтобы они были отправлены сразу, например, если эти данные представляют собой команду для удаленной машины. Для этого в заголовке ТСР-пакета есть флаг PUSH. Если он установлен, то это говорит о том, что данные должны быть переданы немедленно.
Наконец, последняя возможность ТСР-сервиса, которую здесь стоит упомянуть - срочные данные. Если для данных установлен флаг URGENT в заголовке, то все данные после этого по данному соединению передаются сразу и не буферизуются. Когда срочные данные поступают к месту назначения, то получателю передают их немедленно.
Каждый байт в ТСР соединении имеет 32-разрядный номер. В сети с пропускной способностью 10 Мбит/сек. потребуется не менее часа, чтобы исчерпать все номера с 0 до 2^32. Эти номера используются как для уведомления, так и в механизме управления окнами.
ТСР-агенты обмениваются сегментами данных. Каждый сегмент имеет заголовок от 20 байтов и более (по выбору) и тело переменной длины. Один сегмент может включать байты от разных отправителей, а может включать часть данных одного. Какой длины может быть тело, решает ТСР-агент. Длину сегмента ограничивают два фактора. Во-первых, длина сегмента не должна превышать максимальную длину IP-пакета - 64 Кбайт. Во-вторых, каждая сеть имеет максимальную единицу передачи - MTU (maximum transfer unit), и каждый сегмент должен помещаться в MTU. В противном случае маршрутизаторам придется применять фрагментацию. При этом возрастают накладные расходы на передачу в сети, так как каждый фрагмент оформляется как самостоятельный пакет (с 20-байтным заголовком).
Основным протоколом, который используется ТСР-агентом, является протокол скользящего окна. Это значит, что каждый посланный сегмент должен быть подтвержден. Одновременно с отправлением сегмента взводится таймер. Подтверждение придет либо с очередными данными в обратном направлении, если они есть, либо без данных, но с подтверждением. Подтверждение будет иметь порядковый номер очередного ожидаемого получателем сегмента. Если таймер исчерпается прежде, чем придет подтверждение, то сегмент посылается повторно.
Несмотря на кажущуюся простоту, ТСР-протокол достаточно сложен и должен решать следующие основные проблемы: восстанавливать порядок сегментов убирать дубликаты сегментов, в каком бы виде они не поступали определять разумную задержку для time_out для подтверждений в получении сегмента устанавливать и разрывать соединения надежно управлять потоком управлять перегрузками
Заголовок сегмента в ТСР показан на рисунке 6-24. Максимальная длина раздела данных – 65 495 байтов.
Поля Source port и Destination port указывают сокеты на стороне отправителя и получателя соответственно. Sequence number и Acknowledgement number содержат порядковый номер ожидаемого байта и следующего ожидаемого, а не последнего полученного байта. 6-битное поле флагов.
Бит Urg используется вместе с полем Urgent pointer, которое указывает на начало области срочных данных. ACK - 1, если поле Acknowledgement number используется, в противном случае – 0. PSH - 1, если отправитель просит транспортного агента на стороне получателя сразу передать эти данные приложению и не буферизовать их. RST – используется, чтобы переустановить соединение, которое по какой-либо причине стало некорректным. Получение пакета с таким флагом означает наличие проблемы, с которой надо разбираться. SYN – 1, при запросе на соединение. Флаг ACK указывает на наличие или отсутствие подтверждения. SYN=1 ACK=0 – запрос на соединение, SYN=1 ACK=1 – подтверждение соединения. FIN - запрос на разрыв соединения. У отправителя нет больше данных.
Поле Window size используется алгоритмом управления окном. Поле Options используется для установления возможностей, не предусмотренных стандартным заголовком. Например, здесь часто указывается максимальный размер поля данных, допустимый по данному соединению.
 Рисунок 6-24. Заголовок TCP
Как уже было сказано, установление ТСР-соединения происходит по протоколу трехкратного рукопожатия. Флаги SYN и ASK в заголовке сегмента используются для реализации примитивов CONNECTION REQUEST и CONNECTION ACCEPTED. Флаг RST используется для реализации примитива REJECT. Это означает, что указанные выше примитивы вызывают посылку ТСР-пакета с установленным соответствующим флагом.
Когда приходит запрос на соединение по определенному порту, транспортный агент проверяет, есть ли процесс, который выполнил примитив LISTEN на этом порту. Если такой процесс есть, то ему передается управление. Если такого процесса нет, то в ответ идет отказ от установления соединения.
Если два хоста одновременно пытаются установить соединение между двумя одинаковыми сокетами (коллизия), то поскольку каждое соединение идентифицируется парой сокетов, будет установлено только одно из соединений.
Таймер для последовательных номеров сегментов тактируется с частотой 4 мксек., максимальное время жизни пакета - 120 сек. Напомним, что начальный номер сегментов никогда не равен нулю, по соображениям, приведенным ранее. Для генерации последовательных номеров сегментов используют механизм логических часов.
ТСР-соединение, как уже говорилось, - дуплексное, т.е. в каждом направлении данные передаются независимо и соединение разрывается независимо по каждому направлению. Поэтому лучше всего представлять его как два симплексных соединения. Если в очередном сегменте флаг FIN=1, то в этом направлении данных больше не будет. При получении подтверждения для этого сегмента соединение в этом направлении считается разорванным. В другом направлении передача может продолжаться сколь угодно долго. Если подтверждения на первый FIN нет в течение двух интервалов жизни пакетов, то по time-out соединение считается разорванным. Противоположная сторона также по истечении этого периода времени узнает, что никто от нее не ждет ответа. В таблице 6-18 и на рисунке 6-19 представлена процедура установления и разрыва соединения в виде диаграммы конечного автомата.
Таблица 6-18. Состояния, используемые в конечном автомате управления TCP-соединениями
Состояние | Описание | CLOSED | Нет активных или ожидающих соединений | LISTEN | Сервер ожидает входящего вызова | SYN RCVD | Запрос на соединение доставлен; ожидание подтверждения | SYN SENT | Приложение открывает соединение | ESTABLISHED | Состояние нормальной передачи данных | FIN WAIT 1 | Приложение сообщило об окончании работы | FIN WAIT 2 | Другая сторона согласилась разорвать соединение | TIMED WAIT | Ожидание, пока все пакеты прекратят свое существование | CLOSING | Попытка обоих сторон одновременно закрыть соединение | CLOSE WAIT | Противоположная сторона инициировала разрыв | LAST ACK | Ожидание, пока все пакеты прекратят свое существование |
Когда поле WIN=0, отправитель может послать сегмент в двух случаях. Первый - если это данные URGENT. Например, когда требуется убить процесс на удаленной машине. Второй - если это однобайтовый сегмент. Это может потребоваться, чтобы заставить получателя показать текущее состояние буфера, что очень важно, так как позволяет обойти тупик.
Заметим, что протокол ТСР не требует от агента-отправителя сразу передавать сегмент, как только данные поступили от приложения. Эту свободу ТСР использует, чтобы повысить свою производительность. Рассмотрим, к примеру, удаленный редактор TELNET. Если передавать по сети каждое движение пользователя мышкой или нажатие им клавиши на клавиатуре, то обмен будет очень не эффективным. На передачу одного символа будет приходиться передача сегмента в 160 байт. Поэтому часто при реализации протокола ТСР вводят специальную задержку на посылку подтверждения и состояния окна, чтобы дать отправителю накопить буфер для отправки. Другую стратегию предложил Нагл (Nagle) – если работа идет с приложением, которое генерирует однобайтные сообщения, то надо первый байт послать, а все остальные буферизовать до тех пор, пока не придет подтверждение на посланный байт. Все буферизованные байты нужно послать одним сегментом, после чего буферизовать все байты, пока не придет подтверждение на посланный сегмент.
Алгоритм Нагла работает хорошо. Однако есть приложения, где его следует отключить, – X-Windows. Здесь перемещения мыши по экрану надо пересылать сразу без буферизации.
Другая проблема, которая может существенно понизить производительность протокола ТСР – т.н. «синдром дурацкого окна» (рисунок 6-21). Он возникает, когда приложение на стороне отправителя передает ТСР-агенту данные большими блоками, а приложение на стороне получателя читает данные побайтно! В этой ситуации может произойти следующее. Буфер на стороне получателя полон и отправитель знает об этом. Приложение-получатель считывает один байт из буфера. ТСР-агент получателя радостно шлет сообщение о доступном буфере в один байт. Отправитель обязан послать один байт. После чего буфер получателя опять полон, и т.д.
Рисунок 6-21. «Синдром дурацкого окна»
Кларк предложил запретить сообщать получателю в таких случаях об освободившемся месте на один байт. Получателя принуждают ждать, пока либо не освободится размер, равный максимальной длине сегмента, объявленной при установлении соединения, либо не освободится половина буфера. Отправитель также должен стараться избегать крохотных сегментов, а посылать большие.
 У ТСР-агента получателя также есть средства улучшить производительность соединения. Например, можно запретить приложению использовать примитив READ до тех пор, пока у агента есть данные в буфере. Конечно, такое решение увеличит время отклика, но для неинтерактивных приложений это не страшно.
Другая проблема для получателя, понижающая производительность соединения, - нарушение порядка поступления сегментов. Например, если поступили сегменты 0, 1, 2, 4, 5, 6, 7, получатель может подтвердить сегменты 0-2, забуферизовать сегменты 4-7. Тогда отправитель по time-out перешлет сегмент 3, после чего получатель подтвердит 4-7 сегменты.
Здесь мы рассмотрим, как протокол ТСР борется с перегрузками. В основе всех методов лежит принцип сохранения количества пакетов: не посылать новый, пока старый не покинет сеть, т.е. не будет доставлен. Основная идея очень проста - при возникновении перегрузки не посылать новых пакетов. В протоколе ТСР это реализуется динамически с помощью механизма окон.
Прежде всего, протокол ТСР обнаруживает перегрузку по росту числа time_out. Если эта величина превышает некоторый предел, являющийся параметром протокола, то это фиксируется как перегрузка. Причин может быть две – шум в канале и сброс пакетов маршрутизатором. Различить их сложно. В наши дни каналы достаточно надежные, так что актуальной остается вторая причина.
Перегрузки возникают по двум причинам: нехватка буфера на стороне получателя – недостаточная емкость получателя; перегрузка внутри сети – недостаточная емкость сети.
В Internet эти ситуации различаются как внутренняя емкость сети и емкость получателя. Поэтому каждый отправитель поддерживает два окна - обычное окно отправителя и окно перегрузки. Каждое показывает количество байтов, которое отправитель может послать. Фактически отправляемое количество байтов - минимум из этих двух величин.
Сначала окно перегрузки полагают равным размеру максимального сегмента для данного соединения. Если сегмент успешно (без time_out) был передан, то окно перегрузки увеличивается вдвое. Это увеличение будет происходить до тех пор, пока либо не наступит time_out и произойдет возврат к предыдущему значению, либо размер окна перегрузки не достигнет размера окна получателя. Этот алгоритм называется slow start - медленный старт.
Другой параметр управления перегрузками в Internet – порог (threshold). Алгоритм медленного старта при возникновении перегрузки устанавливает этот параметр равным половине длины окна перегрузки, а окно перегрузки - равным размеру максимального сегмента. Окно перегрузки растет экспоненциально до тех пор, пока не сравняется с порогом, после чего оно растет линейно, пока не достигнет размера окна получателя. На этом рост прекращается до первой перегрузки.
Протокол ТСР использует несколько таймеров для управления передачей. Наиболее важный из них - таймер повторной передачи. Этот таймер устанавливают, когда отправляют сегмент. (Напомним, что так мы называем TPDU-пакет.) Если подтверждение пришло до исчерпания этого таймера, то его останавливают и сбрасывают. Если таймер исчерпан, то сегмент посылают повторно.
Здесь основная проблема - как удачно выбрать величину time_out: временной интервал, по истечении которого сегмент надо передать повторно. Как мы знаем, эта проблема встречается и на других уровнях. Однако на транспортном уровне она имеет особенность, которая заключается в следующем. На канальном уровне дисперсия величины задержки подтверждения имеет ярко выраженный максимум. Другими словами, ее разброс невелик. Величину time_out на этом уровне устанавливают чуть больше ожидаемой величины прихода подтверждения. На транспортном уровне функция распределения величины задержки подтверждения носит более гладкий характер, чем на канальном уровне. Поэтому предсказать величину времени, которая нужна для передачи данных от источника до получателя и передачи подтверждения от получателя до источника, очень трудно. Заведомо эта величина не должна быть постоянной в силу гладкости функции распределения.
В основе используемого в протоколе ТСР алгоритма, предложенного Якобсоном в 1988 году, лежит специальная переменная RTT для получения оптимального значения величины time_out (Round Trip Time), значение которой постоянно модифицируется. В этой переменной хранится наименьшее время подтверждения. При каждой передаче сегмента замеряется величина задержки подтверждения М. Если при очередной передаче подтверждение поступило прежде, чем наступил time_out, значение переменной RTT немного уменьшают, в противном случае - увеличивают по формуле:
RTT = λRTT + (1- λ)M, где λ=0,87.
Однако, даже зная величину RTT, определить величину ожидания оказалось непросто. Якобсон предложил вычислять величину D - отклонения между ожидаемой величиной задержки и измеренной по формуле:
D = λD + (1-λ) |RTT - M|.
Кроме этого, Якобсон показал как, зная D, вычислить величину time_out по формуле:
time_out = RTT + 4*D.
Позднее Филл Карн (Phill Karn) модифицировал эту формулу для случая повторно передаваемых сегментов. Действительно, когда поступает подтверждение для сегмента, то не ясно, то ли это подтверждение для первой передачи, толи для последней. Филла интересовал вопрос вычисления величины RTT для передачи данных по протоколам TCP/IP по КВ-радиоканалу. В результате экспериментов он показал, что для повторно передаваемых сегментов эффективно просто удваивать величину ожидания до тех пор, пока подтверждение не поступит с первого раза.
Другой важный таймер в протоколе ТСР - таймер настойчивости. Он позволяет бороться со следующего типа тупиками. Когда получатель посылает сообщение с нулевым размером окна, отправитель останавливает передачу и ждет сообщения об изменении размера окна. Наконец, получатель послал это сообщение, а оно было потеряно. Все ждут. Чтобы избежать такой ситуации, используют таймер настойчивости. Если он исчерпан, то отправитель шлет сообщение получателю, напоминая ему о проблеме размера буфера.
Еще один важный таймер - таймер функционирования. Если по какой-либо причине по соединению долго не посылали сообщений, то надо проверить, функционирует ли оно. Когда этот таймер исчерпан, то соответствующая сторона шлет другой стороне запрос: «Жива ли ты?» Если ответа не поступает, то соединение считается разорванным.
Протокол UDP.
Internet поддерживает также транспортный протокол без соединений - UDP (User Data Protocol). Протокол UDP (User Datagram Protocol) предназначен для обмена дейтаграммами между процессами компьютеров, входящих в единую сеть с коммутацией пакетов. В качестве протокола нижнего уровня UDP-протокол использует IP.
Протокол UDP предоставляет прикладным программам возможность отправлять сообщения другим приложениям, используя минимальное количество параметров протокола. Этот протокол не обеспечивает достоверность доставки пакетов, защиты от дублирования данных или от сбоев в передаче. За исключением параметров приложения - номеров портов отправителя и получателя пакета, UDP практически ничего не добавляет к IP-дейтаграмме.
Рисунок 6-25. Заголовок UDP
Протокол UDP намного проще, чем TCP, и полезен в ситуациях, когда мощные механизмы обеспечения надежности протокола TCP не требуются или будут только помехой для решения определенного рода задач, например, аутентификации пользователей. Структура UDP-заголовка показана на рисунке 6-25.
Source Port (16 бит). Порт отправителя. Это поле может содержать номер порта, с которого был отправлен пакет, когда это имеет значение (например, когда отправитель ожидает ответа). Если это поле не используется, оно заполняется нулями. Destination Port (16 бит). Порт назначения - это порт компьютера, на который пакет будет доставлен. Length (16 бит). Поле длины. Длина (в байтах) этой дейтаграммы, включая заголовок и данные. (Минимальное значение этого поля равно 8). Checksum (16 бит). Поле контрольной суммы. Контрольная сумма UDP-пакета представляет собой побитное дополнение 16-битной суммы 16-битных слов (аналогично TCP). В вычислении участвуют: данные пакета, заголовок UDP-пакета, псевдозаголовок (информация от IP-протокола), поля выравнивания по 16-битной границе (нулевые).
Преимущество протокола UDP состоит в том, что он требует минимум установок и параметров для соединения двух процессов между собой. Этот протокол используется при работе Серверов Доменов (Name Servers), протокола TFTP (Trivial File Transfer), при работе с SNMP-протоколом и построении систем аутентификации. Идентификатор UDP в IP-заголовке - число 17. Более подробное описание протокола UDP можно найти в RFC-768.
TCP и UDP в беспроводных коммуникациях.
Теоретически ТСР не должен зависеть от того, над какой средой он работает – оптической или беспроводной. Однако на практике дело обстоит иначе. ТСР-протокол тщательно оптимизировали при разных предположениях, которые не выполняются в беспроводной среде. Так, например, предполагалось, что сетевая среда достаточно надежна и рост числа time_out – это результат перегрузки, а не потери пакетов.
В беспроводной среде потеря пакета - дело частое. Поэтому применение протокола ТСР «в лоб» с протоколом Якобсона медленного старта лишь усугубит положение. Так, например, если потери составляют 20%, то при пропускной способности канала в 100 пакетов в секунду фактически будем иметь лишь 80 пакетов. Согласно алгоритму медленного старта, при увеличении числа time_out надо понизить скорость, скажем до 50 пакетов в секунду, что приведет к фактической скорости 40 пакетов.
Поэтому, если увеличилось число отказов в обычном канале, надо сбросить скорость, а если это число возросло в беспроводной среде, надо не понижать скорость, а слать пакеты повторно. Так что без знаний о среде принять решение трудно.
Основным источником проблем является то, что в беспроводной среде соединения часто неоднородные. На рисунке 6-26 показан пример. Была предложена модификация ТСР – разбить такое соединение на два так, чтобы каждое стало однородным. Есть и другие решения, связанные с модификацией не самого ТСР, а канального уровня для базовых станций.
Рисунок 6-26. Разбиение TCP-соединения на два
|
46
6
План-конспект урока по теме Протоколы транспортного уровня в Интернете 