Интеграция и развитие технологий

Развитие стека протоколов TCP/IP

Протокол IPv6

Работа по расширению протокола IP была начата в 1992 году. Необходимость этого диктовалось тем, что практически все ресурсы старой версии протокола IP (IPv4) были исчерпаны. Быстрый рост сети Internet привел к появлению дефицита IP-адресов. Возросший трафик начал вызывать перегрузки магистральных маршрутизаторов. Изменился и характер передаваемого трафика. Все большую долю в нем стали занимать мультимедийные данные.

Новая версия протокола IP – версия 6 (IPv6) – была принята организацией IETF в 1995 году. Она описана в документе RFC 1752. В настоящее время осуществляется постепенный переход к протоколу IPv6. Существует несколько фрагментов сети Internet, в которых маршрутизаторы поддерживают обе версии IP. Эти фрагменты объединены между собой и образуют так называемую «шестую» магистраль (6 bone). Для того чтобы передать дейтаграммы протокола IPv6, магистраль 6 bone инкапсулирует их в дейтаграмму IP и передает через те части сети Internet, которые не поддерживают новую версию протокола. Этот процесс называется туннелированием. Следует помнить, что появление дополнительного заголовка при туннелировании ведет к росту сетевого трафика. Документ RFC 1933 определяет четыре конфигурации туннелей между рабочими станциями и маршрутизаторами:

q маршрутизатор–маршрутизатор;

q рабочая станция–маршрутизатор;

q рабочие станции–маршрутизаторы;

q маршрутизатор–рабочая станция.

На рис. 13.1 показан пример организации механизма туннелирования для конфигурации маршрутизатор–маршрутизатор.

Другим методом, позволяющим осуществить плавный переход на новую версию, является использование двойных стеков. Двойные стеки позволяют узлу в сети IP поддерживать обе версии протокола. Такие узлы называются IPv6/IPv4-узлами. Использование двойного стека позволяет раздельно переводить на протокол IPv6 каждое устройство в сети. При этом необходимо задействовать дополнительные ресурсы такого устройства, изменить его конфигурационную информацию и провести ряд других операций. Нужно учитывать, что маршрутизаторам может потребоваться дополнительная оперативная память, так как таблицы маршрутизации протокола IPv6 больше по объему. На рис. 13.2 показано распределение уровней узла с двойным стеком IPv4/IPv6.

Рис. 13.2. Уровни двойного стека TCP/IP

Протокол IPv6 поддерживается практически всеми современными операционными системами и производителями сетевого оборудования. Естественно, развитие протокола IP повлекло за собой модернизацию всего стека TCP/IP. Уменьшился объем маршрутной и служебной информации. Много внимания уделено функциональным составляющим TCP/IP, которые напрямую влияют на загрузку маршрутизаторов:

q реализована гибкая схема разделения адресного пространства с использованием технологий CIDR и масок подсетей переменной длины. Изменение адресной схемы позволяет сократить объем таблиц маршрутизации и ускорить их просмотр и обновление;

q введено повсеместное использование (физического адреса устройства в качестве номера узла. При этом снижается нагрузка на сеть за счет отказа от протокола ARP;

q уменьшен заголовок дейтаграмм IP;

q проведение фрагментации перенесено на конечные узлы. Узлы, поддерживающие протокол IPv6, сами определяют размер MTU, который устраивает все транзитные узлы и каналы на пути следования дейтаграммы.

Схема адресации IPv6 существенно отличается от схемы адресации протокола IP. Адреса получателя и отправителя в протоколе IPv6 задаются 128 битами. Такая длина адресного пространства позволяет на достаточно большой период времени снять проблему дефицита адресов в сети Internet. Основным механизмом, заложенным в схему адресации протокола IPv6, является введение иерархического разделения адресного пространства на уровни. Вместо прежних двух уровней – номера сети и номера устройства, – в протоколе IPv6 используется пять уровней, включая два уровня идентификации провайдеров и три уровня идентификации абонентов в сети (рис. 13.3).

Рис. 13.3. Уровни адресации протокола IPv6

Префикс определяет тип используемого адреса. Приведем пример адреса с идентификацией провайдера. Такой адрес имеет префикс 010. Этот префикс выбран согласно табл. 13.1, в которой приведено исходное распределение адресов протокола IPv6. В табл. 13.1 строка с адресом идентификации провайдера выделена.

Таблица 13.1. Исходное распределение адресов IPv6

На рис. 13.4 показан формат адреса с идентификацией провайдера.

Рис. 13.4. Формат адреса с префиксом 010

Поле «Идентификатор организации» определяет организацию, ответственную за выделение адресов провайдерам. Например, InterNIC в Северной Америке, RIPE в Европе или APNIC в Азии. Поле «Идентификатор провайдера» определяет непосредственно провайдера. Провайдер назначает поле «Идентификатор абонента». Данное поле идентифицирует конкретного пользователя. За полями «Идентификатор провайдера» и «Идентификатор абонента» следуют резервные поля, необходимые для будущего расширения. Оставшиеся 64 бита в адресе по принадлежности к провайдеру определяют номер сети и номер устройства. Идентификация сети и устройства происходит примерно по тем же правилам, что и в случае использования протокола IPv4 с классами А, В и С. Данное поле предоставляет достаточно пространства для разбиения выделенного блока адресов на адреса подсетей и рабочих станций в каждой подсети.

Такая структура адреса по принадлежности к провайдеру значительно упрощает маршрутизацию. Поле «Идентификатор провайдера» сразу определяет сеть другого провайдера. После определения сети провайдера маршрутизатор анализирует поле «Идентификатор абонента» и определяет непосредственного абонента, которому должна быть передана информация. Абонентом может выступать любая организация, которая, при необходимости, может организовать несколько уровней иерархии в своей сети.

В протоколе IPv6 отменено разделение адресов на классы. В основе распределения адресного пространства лежит технология CIDR. При этом адреса сетей каждого провайдера имеют одинаковое значение сетевого префикса и все устройства в этой сети поддерживают его передачу. С использованием технологии CIDR деление IP-адреса на адрес подсети и адрес устройства производится на основе маски подсети переменной длины, которая назначается провайдером и уже не зависит от класса адреса. Использование технологии CIDR совместно с технологией «наибольшего совпадения», реализуемой маршрутизаторами, позволяет значительно уменьшить объем их таблиц маршрутизации. Технология CIDR уже используется с четвертой версией протокола IP и поддерживается протоколами маршрутизации OSPF, RIP-2 и BGP-4. Эта технология позволяет избежать избыточного назначения адресного пространства, которое может иметь место при использовании классов адресов.

Протокол IPv6 вводит несколько типов адресов:

q Unicast – индивидуальный (единичный) адрес. Адрес определяет отдельное устройство в сети или порт маршрутизатора. В свою очередь, индивидуальный адрес подразделяется на:

o Global – глобальный. Основной тип адресов в Internet;

o Link-Local и Site-Local – адреса для линии и узла. Адреса используются в сетях, не связанных с Internet. Для того чтобы эти адреса можно было использовать в Internet, поле «Идентификатор провайдера» заполняется нулями. Термин «Link» относится к сетям Frame Relay и ATM, то есть к прямой выделенной линии или соединению с сетью Ethernet, FDDI и т. д. Локальный адрес для линии описывает устройство, не имеющее соединения с маршрутизатором или с Internet. С использованием этих адресов можно подключать к Internet сети без присвоения им новых адресов. На рис. 13.5 показаны примеры локальных адресов для линий и узлов. В формате локального адреса для линии поле уникального адреса линии содержит физический адрес локальной сети. Префикс имеет длину 10 бит, а оставшаяся часть – 118 бит. Если локальной адрес для линии используется для подключения к сети Ethernet, то физический адрес займет 48 бит (6 байт). Таким образом, использование локальных адресов для линий позволяет подключать сети Ethernet, Token Ring и FDDI без реконфигурации сетевых адресов.

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

q Multicast – адрес набора узлов (групповой адрес). В протоколе IPv6 отсутствует понятие широковещательного адреса. Широковещательная адресация заменена поддержкой групповой передачи данных. Такой механизм необходим протоколу IPv6 для регулирования пропускной способности сети при распространении мультимедийного трафика;

q Anycast – адрес набора узлов. Этот тип адресов используется для обеспечения прохождения своего трафика через маршрутизаторы отдельных провайдеров. В отличие от групповых адресов, такая дейтаграмма должна быть доставлена любому члену группы. В протоколе IPv6 широко используется маршрутизация от источника. Этот вид маршрутизации освобождает маршрутизаторы от функции анализа своих таблиц маршрутизации, уменьшает время задержки дейтаграммы для ее обработки и, естественно, повышает пропускную способность сети в целом;

q При назначении адресов каждому порту маршрутизатора вместе с физическим адресом присваивается еще один адрес, общий для всех портов всех маршрутизаторов в сети данного провайдера, который является апу-cast-адресом;

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

Для плавного перехода к протоколу IPv6 введен специальный тип адресов – IPv4-compatible (совместимые адреса). В этих адресах старшие 96 бит содержат нули, а младшие 32 бита – обычный адрес IPv4. Такие адреса позволяют решить проблему совместимости частей Internet, работающих с протоколами IP разных версий.

Для упрощения обработки заголовка дейтаграммы в протоколе IPv6 введены основной и дополнительный заголовки. Основной заголовок присутствует всегда. Дополнительный заголовок определяет некоторые необязательные параметры. Основной заголовок имеет длину 40 байт (рис. 13.6).

Поле «Следующий заголовок» по своему назначению соответствует полю «Протокол» в версии 4 и определяет тип заголовка, который следует за данными. Каждый следующий дополнительный заголовок содержит это поле. Если дейтаграмма не содержит дополнительных заголовков, то значение этого поля определяет протокол – TCP, UDP, RIP или OSPF. Поле «Лимит переходов» введено для более эффективного определения времени жизни дейтаграмм. В протоколе IPv4 поле времени жизни дейтаграммы уменьшается на единицу (по крайней мере) при прохождении каждого маршрутизатора. При этом время ожидания в очереди не учитывается. Поле «Приоритет» позволяет отправителю задать приоритет своих дейтаграмм. Возможные 16 значений этого поля разделены на две категории: значения от 0 до 7 определяют трафик, которым маршрутизатор при необходимости может пренебречь, а значения от 8 до 15 указывают на трафик, к которому эти меры применяться не могут (аудио- и видеоинформация, передаваемая с постоянной скоростью в реальном времени). Используя поля «Приоритет» и «Метка потока» устройства могут идентифицировать дейтаграммы, которым требуется нестандартное обслуживание на маршрутизаторах. В протоколе IPv6 определены следующие типы дополнительных заголовков:

q Routing – определяет полный маршрут при маршрутизации от источника. Данный заголовок позволяет отправителю указать списбк IP-адресов, которые диктуют путь передачи;

q Fragmentation – содержит сведения о проведении фрагментации на конечных узлах сети. В протоколе IPv6 фрагментацию не разрешается выполнять на промежуточных узлах; это значительно повышает производительность при маршрутизации. В том случае, если распределенная сеть состоит из сегментов с различными значениями MTU, отправитель использует дополнительный заголовок Fragmentation для разделения дейтаграммы на произвольное число небольших фрагментов. В этом дополнительном заголовке содержатся поля, которые идентифицируют фрагменты исходной дейтаграммы по присвоенным им последовательным номерам. Так как промежуточные маршрутизаторы не выполняют фрагментацию, то вся ответственность за выбор правильного размера дейтаграммы возлагается на отправителя, которому необходимо определить значения MTU каждой промежуточной сети в пути до получателя. Например, если две сети FDDI со значением MTU 4500 байт связываются через сеть Ethernet с MTU, равным 1500 байт, то отправитель должен посылать дейтаграмму с длиной не более 1500 байт или разделить ее на фрагменты той же длины. Конечные системы могут определять минимальное значение MTU в пути между ними, используя механизм MTU path discovery process (процесс выяснения значений MTU на пути), описанный в документе RFC 1191. При этом отправитель посылает дейтаграмму с длиной, равной значению MTU той сети, к которой он подключен. Если выбранный размер дейтаграммы слишком велик для некоторых промежуточных сетей, то отправителю будет послано сообщение протокола ICMP «Datagram Too Big» (Дейтаграмма слишком велика) с указанием рекомендованного значения MTU. После получения этого сообщения отправитель скорректирует размер дейтаграммы (например, с помощью фрагментации) и повторит процесс. Это будет продолжаться до тех пор, пока дейтаграмма не сможет пройти все промежуточные сети в пути до получателя;

q Authentication – служит для идентификации конечных узлов и обеспечения целостности дейтаграмм;

q Encryption – служит для шифрования и дешифровки передаваемых данных;

q Hop-by-Hop Option – используется алгоритмом «переход за переходом» при обработке дейтаграмм. Данный заголовок переносит дополнительные параметры, которые проверяются промежуточными узлами. Заголовок должен следовать первым после основного заголовка. Так как заголовок проверяется всеми маршрутизаторами, его полезно использовать для передачи управляющей или отладочной информации. В настоящее время может использоваться параметр Router Alert, который информирует маршрутизаторы, что дейтаграмма должна быть обработана целиком до ее передачи следующему маршрутизатору в пути. Данный параметр применяется, например, при работе протокола RSVP;

q Destination Option – содержит дополнительную информацию для узла назначения.

Каждый дополнительный заголовок содержит тип следующего за ним заголовка, что позволяет создать цепочку заголовков. Основной заголовок является первым в цепочке и не содержит дополнительных заголовков. Поле «Следующий заголовок» указывает, какой дополнительный заголовок следует за основным. Поле «Следующий заголовок» первого дополнительного заголовка указывает на тип второго дополнительного заголовка и т. д. Это продолжается до тех пор, пока в поле «Следующий заголовок» очередного дополнительного заголовка не встретится запись о том, что далее, например, следует заголовок протокола TCP (рис. 13.7).

Для поддержки качества обслуживания протокол IPv6 работает с «меткой потока» (flow label). Метка потока – это признак, который размещается в поле заголовка «Метка протокола» дейтаграммы IPv6. Метка указывает на принадлежность данной дейтаграммы к последовательности дейтаграмм – потоку, который требует определенных параметров обслуживания. Маршрутизаторы обрабатывают потоки на основании значения метки и идентификатора отправителя дейтаграмм. Для предоставления нестандартного качества обслуживания потоков разработан дополнительный протокол RSVP – протокол резервирования ресурсов.

Особо хочется остановиться на проблемах взаимодействия протокола IPv6 с технологией ATM. Основная проблема заключается в поддержании каналов к группе получателей без установления АТМ-соединения.

В отличие от протокола IPv4, механизмы разрешения адресов и их настройки в протоколе IPv6 реализованы на сетевом уровне, а не на канальном (протоколы ARP для широковещательных сетей и ATMARP и NHRP для сетей ATM). To есть, протокол обнаружения (Neighbor Discovery), который используется для нахождения маршрутизаторов и соседей, является интегральной частью IPv6 и любые механизмы, предназначенные для адаптации технологии ATM к IPv6, прежде всего, должны работать именно с этим протоколом. Здесь наблюдается принципиальное отличие от протокола IPv4, в котором механизмы разрешения адресов не являются частью основного протокола, а реализуются на канальном уровне – протоколом ARP для широковещательных сетей и механизмами ATMARP и NHRP для сетей ATM.

Качество обслуживания

Предоставление качества обслуживания – это технология, которая сегодня по праву занимает все более определяющее положение в современных многофункциональных сетях. Она призвана обеспечить платформу, необходимую для работы современных приложений, имеющих гораздо более жесткие требования к ширине предоставляемой полосы пропускания и времени задержки прохождения информации в сети. Кроме того, эта технология находит широкое применение при формировании SLA (см. главу 3), регламентирующего распределение стоимости различных сервисов, предоставляемых сетью передачи данных. Ранние реализации технологии предоставления качества обслуживания или, точнее, предоставления отдельных, узкофункциональных показателей качества обслуживания, зависели, в первую очередь, от различных реализаций алгоритмов организации очередей, к которым можно отнести алгоритмы «первый пришел – первый ушел» (FIFO), приоритетную очередь, справедливую очередь и т. д. Эти алгоритмы используются маршрутизаторами и другими устройствами сети.

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

Явный контроль скорости (Explicit Rate Control) трафика широко распространен и используется в течение ряда лет в сетях ATM и в сетях на базе других технологий. Он поддержан ведущими сетевыми производителями и недавно рекомендован для более широкого использования, в том числе и со стеком протоколов TCP/IP. Этот механизм может работать либо автономно, либо совместно с существующими алгоритмами организации очередей. Основные его цели – расширение пропускной способности каналов связи, уменьшение времени реакции сети и повышение детализации сетевого управления путем реализации контроля над отдельными потоками трафика.

Преимущества явного контроля скорости трафика следующие:

q возможность точного управления и контроля за распределением ширины полосы пропускания для входящих и выходящих потоков трафика;

q минимизация загрузки полосы пропускания за счет уменьшения повторных передач пакетов, которые происходят в результате ошибок;

q уменьшение очередей в маршрутизаторе и, как следствие, снижение нагрузки на его центральный процессор;

q значительное сокращение времени доставки пакета и уменьшение флуктуации этого времени;

q более быстрая адаптация к изменениям в сетевых условиях. При этом отдельное устройство может осуществлять двунаправленный непрерывный контроль потока трафика, и не требуется полный доступ к непрерывной цепочке сетевых устройств.

Ввиду этих преимуществ механизм контроля трафика необходим для тех сетей, которые переносят важный трафик при существующих ограничениях ширины полосы пропускания или при необходимости передачи такого трафика через внешние сети ATM, Frame Relay или IP-сети.

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

Сегодня среда передачи информации значительно усложнилась. Все сети специального назначения объединены в единую многофункциональную сеть, способную работать с самыми разнообразными приложениями. Расширился и спектр реализованных приложений. В связи с этим возник вопрос о разделении ресурсов единой сети между приложениями. Ответить на него призвана технология качества обслуживания (Quality of Service, QpS).

Технология качества обслуживания способна обеспечить распределение трафика по категориям для обеспечения прохождения более приоритетного трафика по сети с обеспечением заданных параметров и независимо от конкуренции со стороны другого трафика. Определяющим при использовании технологии качества обслуживания является именно предоставление защиты наиболее приоритетному трафику от различного рода «посягательств» со стороны менее приоритетного трафика, а не просто «чтобы использовать мультимедиа в сети». Очень важна роль QoS для справедливого распределения сетевых ресурсов и выработки у пользователей привычки ждать от сети выполнения именно тех параметров, что они запрашивали, – не больше и не меньше. Потребность в этой технологии увеличивается по мере того, как многочисленные магистрали сетей с различными характеристиками и разработанной системой приоритетов для различных типов трафика объединяются для создания единой сети масштаба предприятия или нескольких предприятий.

Протокол TCP

Изначально разработанный для функционирования поверх протокола IP, TCP получил «в наследство» от IP некоторые характеристики, которые сегодня вызывают проблемы в магистралях сетей предприятия.

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

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

Если в какой-либо сети конкурируют различные потоки, то каждый из них постоянно пытается захватить себе побольше полосы пропускания. Победители в этом соревновании могли бы быть определены на основании суммарного времени прохождения информации до получателя и получения подтверждения – то есть на основании минимального RTT. При этом некорректная реализация стека TCP/IP могла воспрепятствовать некоторым пользователям получить большую ширину пропускания для своих приложений. Это привело к тому, что существует мнение о том, что стек TCP/IP одного производителя более «эффективен», чем стек другого.

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

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

Доработки протокола TCP уменьшили, но не устранили полностью всех проблем, возникающих при управлении потоком данных. Одной из таких доработок является алгоритм «Медленный старт» (Slow Start). Этот алгоритм предназначен для предотвращения (или смягчения последствий) переполнения сети, которое может возникнуть при быстрой передаче большого числа сегментов. Алгоритм постепенно повышает скорость передачи до возникновения перегрузки (сегменты начинают теряться) или достижения максимальной скорости (получатель не может принимать данные быстрее). Такая схема снижает вероятность потерь сегментов в перегруженных сетях, но не разрешает основную проблему протокола TCP – захвата всей полосы пропускания.

Другое дополнение – алгоритм «Предотвращение перегрузки» (Congestion Avoidance). Он дополняет алгоритм «Медленный старт» (рис. 13.8) и призван обеспечить доставку сегментов к получателю без потерь. Его постулат: лучше исключить перегрузку вообще, чем достичь максимальной скорости передачи, а затем восстанавливать сегменты, которые были отброшены маршрутизаторами. Это алгоритм позволяет снизить скорость передачи в тех случаях, когда в сети возникает перегрузка.

Хотя протокол TCP по-прежнему будет пытаться захватить всю ширину пропускания, он делает это мягче, не так агрессивно. Протокол TCP с алгоритмом «Предотвращение перегрузки» сразу снижает скорость передачи, если происходит потеря сегментов, а затем он начинает медленно увеличивать скорость до тех пор, пока вновь не произойдет потеря. Таким образом происходит постепенное достижение максимальной скорости передачи, при которой наступает перегрузка, вместо полного освобождения полосы пропускания и дальнейших попыток передавать сегменты на той же максимальной скорости (что, естественно, снова может вызвать потери).

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

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

Поэтому второй способ использует в начальный момент функционирования соединения минимальный размер окна отсылки, который ни при каких обстоятельствах не вызовет перегрузку. «Изюминка» состоит в способе наращивания размера окна отсылки. Именно для этого используется алгоритм «Медленный старт» (RFC 1122). Протокол TCP использует новое название окна – окно перегрузки; оно измеряется не в байтах, а в количестве сегментов. В любой момент времени скорость передачи данных протоколом TCP определяется по следующему соотношению:

AWND = MIN [CREDIT, CWND],

где AWND – размер разрешенного окна передачи в сегментах. Иначе говоря, это количество сегментов, которое протоколу TCP разрешено послать на данный момент времени без получения подтверждений на успешный прием. CWND – размер окна перегрузки в сегментах. Это окно используется протоколом TCP в начальный период работы и позволяет снизить скорость передачи данных при наступлении перегрузки. CREDIT – неиспользуемый на данный момент лимит передачи сегментов, который был выдан в последнем подтверждении.

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

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

Выше события изложены с теоретической точки зрения. Правильнее было бы назвать этот алгоритм «экспоненциальным стартом», так как размер окна CWND на самом деле увеличивается экспоненциально. Когда прибывает первое подтверждение, протокол TCP увеличивает размер окна CWND в два раза и посылает сразу два сегмента. После этого окно CWND увеличивается на единицу для каждого приходящего подтверждения. Следовательно, после получения подтверждения на два последних отосланных сегмента отправитель может послать уже четыре сегмента. После того как на эти четыре сегмента поступят подтверждения, протокол может послать восемь сегментов и т. д. На рис. 13.9 показан пример работы алгоритма медленного старта. В этом примере станция А посылает сегмент, имеющий размер 100 байт. После времени, приблизительно равного четырехкратному времени обращения RTT, станция А получает возможность заполнить канал связи непрерывным потоком своих сегментов.

Медленный старт работает достаточно эффективно при создании соединения. Он позволяет протоколу TCP на стороне отправителя быстро определять оптимальный размер окна для данного соединения.

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

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

Для разрешения этой проблемы был предложен алгоритм медленного старта с линейным ростом размера окна перегрузки CWND. Теперь при наступлении перегрузки в сети выполняются следующие действия: