Вопросы к экзамену по Сетям Физическая структуризация сети. Повторитель, концентратор



Скачать 415.89 Kb.
страница3/5
Дата01.12.2016
Размер415.89 Kb.
Просмотров703
Скачиваний0
1   2   3   4   5

Разбиение IP сети на подсети

В 1985 году была определена трехуровневая схема адресации (RFC 950). Необходимость перехода к такой системе адресации можно проиллюстрировать следующим примером. Организация получила сеть класса В, позволяющую адресовать 65000 хостов. Пока в сети работали относительно немного станций – она функционировала благополучно. Но с ростом числа активных хостов неизбежно рос и широковещательный трафик, поскольку этот тип пакетов активно используется в служебных целях многими протоколами. Это обстоятельство неизбежно вело к снижению эффективной производительности сети. Кроме того, управление несколькими десятками тысяч подключений из единого административного центра представляет собой очень трудную задачу. К этим проблем следует добавить и то, что любая организация развивается в направлении роста самостоятельности своих подразделений, что также неизбежно должно отражаться и в структуре сети. Возможность же структурирования сети организации за счет получения дополнительных номеров сетей была быстро исчерпана и резкая нехватка адресного пространства стала реальностью еще во второй половине 80-х годов. Кроме того, рост числа используемых сетей вел к росту таблиц маршрутизации магистральных (межсетевых) маршрутизаторов и, следовательно, к снижению их производительности.

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

При этом поля адреса сети и адреса подсети в совокупности называют расширенным сетевым префиксом. В рассмотренном выше примере, выделение в пространстве адреса хоста 6 разрядов для адреса подсети позволяет организовать 62 подсети, содержащих до 1022 хостов каждая. Такое разбиение на подсети не требует согласования со специальным служебным органом Интернет, регулирующим распределение адресного пространства, Network Information Center.

Отрицательным следствием введения подсетей стало усложнение процедуры определения адреса хоста. Действительно, сетевые устройства используют старшие биты сетевого адреса для определения класса сети, после чего, в случае двухуровневой иерархии, легко находится граница между битами сетевого адреса и адреса хоста. В трехуровневой системе адресации этот прием работать не сможет. Для определения адреса подсети и адреса хоста потребовалось ввести сетевую маску – 32-битный адрес, в котором все биты, соответствующие битам расширенного сетевого префикса, установлены в 1, а соответствующие битам адреса хоста – в 0. Так, например, пусть необходимо в сети класса В 132.10 выделить подсеть, содержащую не более 100 хостов. Для адресации такого числа сетевых устройств достаточно располагать 7 битами (27 =128), которые и отводятся для адреса хоста; оставшиеся 9 бит отводятся для номера подсети (их можно организовать 29 -2=510) а старшие 16 бит – это адрес сети.

Таким образом, маска подсети, в которой находятся хосты с адресами:

132.10.12.129, 132.10.12.130,….,132.10.12.254

будет иметь вид

11111111 11111111 11111111 10000000 (255.255.255.128).

Если маршрутизатор получит пакет с адресом назначения

10000100 00001010 00001100 10110000 (132.10.12.176)

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

10000100 00001010 00001100 10000000,

что соответствует адресу подсети 132.10.12.128. Далее, по таблице маршрутизации будет найден следующий узел на пути к этой подсети, и пакет отправится на соответствующий интерфейс.

Необходимо заметить, что информация о маске подсети IP-пакетом не переносится (хост-источник о структуре сети, в которой находится получатель, ничего не знает). Передача этой информации является задачей протоколов маршрутизации, или она задается статически при конфигурировании маршрутизатора.

В стандартах, описывающих современные протоколы маршрутизации, часто делается ссылка на длину расширенного префикса сети, а не на маску подсети. В такой записи адрес устройства в рассмотренном выше примере имеет вид 132.10.12.176/25. В качестве примера нумерации подсетей в таблице приведено разбиение сети класса С на подсети. Указанное в таблице число хостов в каждой из подсетей на два меньше возможного числа адресов, поскольку адреса, в которых все биты поля адреса хоста установлены в единицу и в ноль, являются зарезервированными и используются как широковещательные для данной подсети. Так при подсетях, приведенных в таблице., адрес 193.10.1.0 является широковещательным лишь для подсети 193.10.1.0/24, а не для всех подсетей. Аналогично, адрес 193.10.1.255 является широковещательным только для подсети 193.10.1.224/27.

Введение подсетей, решив проблемы масштабирования адресного пространства, потребовало определенного усложнения протоколов маршрутизации, которые должны обрабатывать (и переносить) не только адрес сетевого устройства, но и его маску. В настоящее время все широко используемые протоколы маршрутизации (RIP-2, IS-IS, OSPF) переносят эту информацию.




  1. IP маршрутизация

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

Если в таблице маршрутизации станции-отправителя указано, что станция назначения является непосредственно присоединенной к той же ЛВС, то из таблицы физических адресов, которая ведется на каждой сетевой станции, извлекается физический адрес узла назначения, пакет инкансулируется в кадр канального протокола и передается к станции назначения. Если таблица маршрутизации станции-отправителя не содержит искомый сетевой адрес, то пакет отправляется по адресу маршрутизатора, который был указан при конфигурировании станции в качестве шлюза по умолчанию (default router, default gateway). Этот шлюз обязательно имеет физический интерфейс в той же ЛВС, что и станция-отправитель. При получении пакета маршрутизатор проверяет, не совпадает ли адрес назначения этого пакета с его собственным IP-адресом. Если это так, то пакет передается модулю протокола, указанного в поле «Протокол» заголовка пакета. В противном случае, маршрутизатор посредством своей таблицы определяет адрес следующего хоста, которому он должен передать этот пакет, и свой интерфейс, на который следует его направить.

Каждая строка в таблице маршрутизации содержит следующую информацию: IP-адрес сети (узла) назначения, IP-адрес следующего маршрутизатора, способного обеспечить передачу пакета в эту сеть (этому узлу), имя выходного интерфейса и некоторые флаги. Флаги содержат уточняющую информацию о каждой записи в таблице. Так например, флаг H определяет, является ли данная строка таблицы маршрутом к хосту (Н=1), или к сети (Н=0); флаг G уточняет, является ли она маршрутом к другому маршрутизатору (G=1), или определяет путь к непосредственно подключенной станции (G=0).

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

Сеть содержит три подсети: 149.100.1.0/25 149.100.1.128/25, 149.100.2.0/24, которые объединены двумя маршрутизаторами М1 и М2. При этом маршрутизатор М2 является шлюзом в Интернет. Адреса интерфейсов маршрутизаторов показаны на рисунке. Предположим, что станция С6 имеет пакет с адресом назначения 149.100.1.159.

Первая строка таблицы определяет закольцовывающий интерфейс. Вторая строка описывает маршрут по умолчанию и флаг G уточняет, что узел 149.100.2.1 является маршрутизатором. Третья запись таблицы не имеет флага Н, следовательно, она определяет сеть; нет в ней и флага G и это говорит о том, что определяется маршрут к непосредственно подключенной сети и интерфейсом к ней является внешний интерфейс станции С6, имеющий адрес 149.100.2.21. Прежде всего С6 производит поиск адреса станции (или сети) назначения в своей таблице. Поскольку ни тот, ни другой в ней не присутствуют, то пакет будет отправлен в соответствии с маршрутом по умолчанию на маршрутизатор М2 с адресом 149.100.2.1 через интерфейс Eth0.

Выполнив поиск в этой таблице маршрутизатор М2 найдет, что наиболее полно согласуется с адресом назначения маршрут, определенный в строке 5 и отправит пакет к маршрутизатору М1 через интерфейс Eth1.

В ней представлен маршрут с адресом назначения точно соответствующим адресу назначения пакета. Поэтому последний передается на интерфейс Eth0 и доставляется станции С2 с IP-адресом 149.100.1.159.




  1. Протокол ARP

Пусть хост Н1 хочет отослать пакет хосту Н3, MAC-адрес которого не известен. Хост Н1 генерирует так называемый ARP-запрос – специальный пакет, имеющий широковещательный адрес назначения. В теле этого запроса находится IP-адрес хоста, MAC-адрес которого необходимо узнать. Каждый хост сети получив такой пакет, сравнивает находящийся в нем IP-адрес со своим. Если совпадение обнаружено, то этот хост посылает запрашивающей станции ответный пакет (ARP-ответ), содержащий его физический адрес. На всех остальных станциях сети пакеты ARP-запросов уничтожаются. Для того, чтобы уменьшить количество ARP-запросов, каждое сетевое устройство имеет специальную буферную память, в которой хранится ARP-таблица. Последняя пополняется каждый раз, когда хост получает ARP-ответ.

В ARP-таблице могут быть как статические, так и динамические записи. Статические записи добавляются администратором и сохраняются в таблице до перезагрузки устройства. Кроме того, в таблице всегда содержится широковещательный адрес (%FFFFFFFFFFFF), который позволяет принимать широковещательные запросы. Динамические записи добавляются и удаляются автоматически. Каждая такая запись имеет потенциальное время жизни. После добавления записи в таблицу включается специальный таймер и, если в течении первых двух минут запись не используется, то она удаляется; в противном случае, время жизни такой записи составляет некое предустановленную величину (обычно 10 минут). Далее приведен фрагмент ARP-таблицы маршрутизатора.



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

В поле «Тип сети» для Ethernet указывается значение 1. Для других типов сетей его значения определяются соответствующим стандартом. Поля «Тип протокола», «Длина аппаратного адреса» и «Длина сетевого адреса» обеспечивают отмеченную выше универсальность формата ARP-пакета. В поле «Тип операции» для ARP-запроса указывается 1, для ARP-ответа – 2.

Устройство, отправляющее ARP-запрос, заполняет в этом пакете все поля, кроме искомого аппаратного адреса. Значение этого поля заполняется станцией, опознавшей свой IP-адрес, указанный в этом пакете в поле «IP-адрес получателя».


  1. Протокол ICMP

Если маршрутизатор не может по каким-то причинам отправить пакет к узлу назначения, то он отсылает соответствующее сообщение узлу-отправителю. Эти функции выполняет протокол ICMP – Internet Control Message Protocol, описание которого приведено в документе RFC 792. Хотя его сообщения инкапсулируются в IP-пакет, протокол ICMP является протоколом сетевого уровня. Рассматриваемый протокол обеспечивает взаимодействие между программным обеспечением протокола IP, функционирующим на разных сетевых узлах. Однако, протокол не способен информировать промежуточные узлы о возникших ошибках, поскольку в IP-пакете нет поля для записи маршрута. Соответственно, когда пакет пришел на некий маршрутизатор и в ходе его обработки обнаружилась необходимость отправки сообщения ICMP, то единственным получателем такого сообщения будет узел – отправитель исходного пакета.

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

Сообщения ICMP начинаются тремя обязательными полями: «Тип», «Код» и «Контрольная сумма». Кроме этого, большинство сообщений включают в себя заголовок и первые 64 бита пакета, в котором была обнаружена ошибка, сообщение о которой несет данный пакет ICMP. Это сделано для более точной идентификации источника ошибки на узле-отправителе. Поле «Тип» определяет содержание сообщения и его формат. На слайде приведены некоторые значения этого поля.

Сообщения «Запрос эха» и «Ответ на эхо» являются одними из самых используемых (команда ping). Поскольку эти сообщения передаются в IP-пакетах, то успешный прием ответа свидетельствует о работоспособности основных компонентов сетевой транспортной системы, т.е. успешной маршрутизации, работоспособности IP-модулей стека протоколов на станциях отправителе и получателе. На рисунке внизу слайда представлен их формат.

Поля «Идентификатор» и «Последовательный номер» используются отправителем для проверки соответствия между ответом и запросом. Поле «Необязательные данные» имеет переменную длину и содержит данные, которые необходимо вернуть отправителю.

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

Сообщение «Изменение маршрута» (Слайд 13) отправляется маршрутизатором отправителю, находящемуся с ним в одной физической сети, и свидетельствует об использовании последним неоптимального маршрута к узлу-назначения. Это сообщение содержит адрес маршрутизатора, использование которого является предпочтительным. Таким образом, начиная работу, отправитель может знать лишь один маршрут. В дальнейшем, его таблица маршрутизации, посредством этих сообщений ICMP, будет дополнена более точной информацией об «оптимальных» маршрутах. Весь этот механизм позволяет узлу отправителю минимизировать размер своей таблицы маршрутов.



  1. Протокол UDP

Протокол UDP (User Datagram Protocol) описан в документе RFC 768. Он ориентирован на сервис без установления соединений и не обеспечивает надежную передачу сегментов между сетевыми приложениями. Это очень простой протокол, который развивает возможности IP-протокола лишь в части демультиплексирования потока пакетов по признаку принадлежности их определенному приложению и контроля целостности данных. Взаимодействие между прикладными процессами UDP реализует посредством механизма протокольных портов. Протокольный порт можно определить как абстрактную точку присутствия конкретной прикладной программы, выполняющейся на конкретном хосте. Когда рабочая станция получает пакет, в котором указан ее IP-адрес, она может направить его определенной программе, используя уникальный номер порта, назначенный этой программе в ходе выполнения процедуры установления соединения. Таким образом, в стеке протоколов TCP/IP порт является механизмом поддержания рабочей станцией одновременного выполнения нескольких прикладных процессов.

Каждый порт (прикладной процесс) идентифицируется целым положительным числом (номером порта). Номера портов приложения, выполняющегося на разных станциях, указываются в заголовке UDP-сегмента. Эта информация дополняется на сетевом уровне IP-адресами взаимодействующих станций. Благодаря этому, создается видимость непосредственного обмена данными между процессами.

Сегмент данных протокола UDP (иногда его называют пользовательской дейтограммой) состоит из двух частей: заголовка и области данных (см. слайд). Заголовок имеет четыре 16-битных поля, определяющих порт отправителя, порт получателя, длину сегмента и контрольную сумму.

Поле «Длина UDP-сегмента» содержит количество байтов в дейтограмме с учетом длины ее заголовка.

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

Псевдозаголовок включается перед заголовком дейтограммы; он имеет длину 12 байтов; поле «Протокол» содержит тип протокола сетевого уровня (IP, ICMP); его значение, как и значения полей с IP-адресами, должны быть извлечены из заголовка IP пакета. Поле «Контрольная сумма» на время ее вычисления заполняется нулями.

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

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




  1. Протокол TCP

Протоколы TCP и IP являются «рабочими лошадками» Интернет. В этом разделе будут рассмотрены механизмы, посредством которых TCP обеспечивает надежный, ориентированный на установление соединений потоковый сервис в дейтограмной сети IP. В число этих механизмов входит вариант алгоритма ARQ с выборочным повторением и алгоритм управления перегрузками на базе индикации потерь сегментов. Подробно протокол описан в документах RFC 793 и RFC 1122.

Надежный потоковый сервис.

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

Аналогично UDP, каждый прикладной процесс для TCP-модуля представляется номером порта. Структура из пары переменных (порт, IP-адрес) называется сокетом. Соединение между отправителем и получателем однозначно определяется двумя сокетами. Для хранения всей информации, необходимой для установления и поддержания соединения, определена специальная структура данных – блок управления передачей (Transmission Control Block - TCB). В эту структуру, кроме двух сокетов, входят флаги безопасности и приоритета соединения, указатели буферов отправителя и получателя, указатели номеров очередного сегмента и сегмента повторной посылки, а также ряд других переменных.

ТСР не сохраняет границы сообщений и рассматривает данные, которые поступают ему от приложения, как поток байтов. Свои сегменты он формирует так, как считает необходимым, но с учетом свойств протокола сетевого уровня (сегмент должен полностью поместиться в IP-пакет). Таким образом, если приложение отсылает сообщение, размер которого составляет 1000 байтов, то на приемной стороне оно может быть представлено двумя частями по 500 байт, тремя частями по 300, 300 и 400 байт и.т.д.




  1. Адаптационные механизмы протокола TCP

Надежный потоковый сервис протокол ТСР обеспечивает посредством специальных адаптационных механизмов. Напомним, что этот протокол предполагает наличие сетевой среды, в которой пакеты могут теряться, дублироваться, приходить в узел назначения с нарушением порядка их отправки. Для идентификации таких нарушений в протоколе введена последовательная нумерация байтов сегмента. Порядковый номер первого байта сегмента передается в его заголовке и он считается порядковым номером сегмента. Номер первого байта для каждого соединения выбирается случайным образом в период установления соединения. Поскольку каждый байт сегмента оказывается пронумерованным, то легко решается задача опознания на приемной стороне нарушений порядка их доставки. Механизм подтверждения приема носит накопительный характер, т.е. подтверждение приема байта с номером N, означает, что байты с номерами N-1, N-2, … успешно получены. Диапазон возможных номеров байтов ограничен числами от 0 до 231-1. Заметим, что при скорости передачи в 100 Мбит/с полный цикл использования всего допустимого диапазона номеров составляет 5,4 минуты, что вполне достаточно для того, чтобы любой сегмент был получен приемной станцией, а все его дубли были уничтожены.


  1. Фаза установления соединения TCP

Фаза установления соединения, предшествующая фазе передачи данных, содержит следующие действия.



  1. Хост А отправляет хосту Б запрос соединения посредством установки флага SYN и инициализирует значение начального номера нумерующей последовательности (Seq_no = m).

  2. Хост Б отвечает на этот запрос установкой флага ACK и определяет поле «Порядковый номер подтверждения» значением на единицу большим m (Ack_no = m+1); одновременно, хост Б в своем ответе А отправляет запрос соединения (SYN) и также инициализирует значение начального номера своей нумерующей последовательности (Seq_no = k).

  3. Хост А отвечает на запрос соединения от хоста Б установкой флага ACK и подтверждением ожидания следующего байта данных с порядковым номером k+1 (Ack_no = k+1); при этом, значение поля «Порядковый номер сегмента» устанавливается в значение m+1 (Seq_no = m+1).

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

Заметим, что в фазе установления соединения каждый SYN-сегмент может содержать опциональные параметры и любой хост может отказать в соединении посредством отсылки сегмента с установленным флагом RST.

Протокол ТСР поддерживает два типа соединения – активное и пассивное. Так, в приложениях, построенных по клиент-серверной архитектуре, сервер выполняет пассивное соединение (формирует свой сокет и переходит в режим «прослушивания»), сообщая тем самым своему модулю ТСР о готовности принять запрос соединения. Когда клиент желает установить связь с сервером, он выполняет процедуру активного соединения. В нее входит создание сокета на клиентской стороне и выполнение описанных выше процедур TCP-соединения.



  1. Фаза передачи данных TCP

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

Пусть в момент t0 ТСР-модуль хоста В объявил величину своего окна равной 2048 байт и номер следующего ожидаемого байта 2000. Такой размер окна позволяет хосту А отправить без подтверждения 2 Кбайта данных, однако в его выходном буфере имеется лишь 1024 байта данных. Хост А отправляет эти данные нумеруя байты начиная с 2000. Одновременно, он объявляет величину своего окна равной 1024 байта и подтверждает, что номер ожидаемого первого байта от хоста Б должен быть равен 1. Хост Б задерживает выдачу подтверждения на прибывший сегмент данных, полагая, что у него появятся данные для отправки хосту А, вместе с которыми он отправит и подтверждение. Тем временем, в момент t2 модуль ТСР хоста А снова получил от своего приложения 1024 байт данных и передал их хосту Б. После этого величина окна отправки на хосте А стала равной нулю и дальнейшая отправка им данных до получения подтверждения от хоста Б оказывается невозможной. В момент t3 модуль ТСР хоста Б получил 128 байт данных для отправки; вместе с ними он отправляет подтверждение получения от хоста А двух сегментов данных, указывая Ack_no=4048. К этому моменту в буферной памяти модуля ТСР хоста Б оказывается свободными лишь 512 байт, поэтому он объявляет величину своего окна приема равной 512. Когда хост А получит этот сегмент, он установит величину окна отсылки равной 512 байт и, несмотря на то, что в момент t4 в его буфере имеется 2048 байт данных, он сможет отослать только 512 байт и не перегрузит буфер хоста Б.

Предыдущее рассмотрение показывает, что задержка отправки подтверждения позволяет более экономно использовать пропускную способность канала. Это особенно актуально в ситуациях, подобных login-сессиям, когда пользователь вводит свои аутентификационные данные по одному символу. Пересылка каждого из них, сама по себе весьма затратна (на один байт информации приходится не менее 40 байтов заголовков TCP и IP уровней), а выдача подтверждения на каждый такой сегмент еще более усугубляет ситуацию. Решение, экономящее пропускную способность канала связи, было предложено Нейглом (Nagle). Идея алгоритма достаточно проста. Когда интерактивное приложение требует отсылки символа, модуль ТСР отправляет его и ждет подтверждения. Поступающие в этот период времени от приложения символы не передаются, а буферизируются; они отправляются все вместе в одном сегменте после получения подтверждения на первый отправленный символ. В локальных сетях, где задержки доставки сегментов относительно малы и каналы связи являются достаточно широкополосными, применение рассмотренного алгоритма является нецелесообразным.

Существует еще одна ситуация, в которой механизм регулирования окна протокола ТСР может приводить к неэффективному использованию полосы пропускания. Пусть передающее приложение имеет большой объем данных для передачи, а принимающее приложение может читать буфер своего ТСР модуля лишь небольшими порциями. Ясно, что, в конце концов, это приведет к объявлению приемным модулем малого значения окна; соответственно, передающий модуль будет формировать сегменты с малым объемом данных, что и увеличит «накладные» расходы протокола при их передаче. Это явление часто называют «синдромом ленивого окна». Для уменьшения его негативного влияния ограничивают возможность объявлять малые значения приемного окна. А именно, пока размер свободного буферного пространства приемника не достигнет половины его объема, либо половины размера максимально допустимого сегмента, размер приемного окна не объявляется (т.е. считается равным нулю). Данные приложения на передающей стороне буферизируются и отправляются после объявления ненулевого приемного окна уже достаточно большими сегментами.



Рассмотрим еще проблему зацикливания нумерующей последовательности, характерную для работы протокола ТСР в высокоскоростных средах. Исходная спецификация протокола предполагала, что максимальное время жизни сегмента составляет 2 минуты. Последовательность из 232 номеров способна пронумеровать 4294967296 байт. Для их передачи по линии с пропускной способностью 2048 Кбит/с потребуется (232 х 8)/(2,048х106) = 4,5 часа, а по линии ОС-48 (2,4 Гбит/с) всего 14 секунд. Ясно, что на современных высокоскоростных линиях протокол TCP может терять работоспособность. Решение этой проблемы было найдено посредством определения в опциональном поле заголовка сегмента 4-х байтовой временной метки. Приемный модуль включает ее в свой ACK-сегмент, и таким образом объединяются два способа разметки последовательности отправляемых сегментов. Это увеличивает период нумерующей последовательности до 264. Ясно, что для реализации этого механизма таймер временных меток должен изменять свое значение, по крайней мере, один раз за время необходимое для отправки 231 байт (максимальное значение окна передачи). Это требование определяет нижнюю границу частоты этого таймера. Эта частота не должна быть и настолько высокой, чтобы полный цикл показаний таймера был пройден за время, меньшее максимального времени жизни сегмента. Значения в диапазоне от 1 Гц до 1 кГц удовлетворяют этим ограничениям. Например, при частоте в 1кГц протокол будет успешно работать на линиях с пропускной способностью до 8 Тбит/с. [RFC 1323].





  1. Поделитесь с Вашими друзьями:
1   2   3   4   5


База данных защищена авторским правом ©nethash.ru 2017
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал