Чернега В., Платтнер Б. Компьютерные сети. Учебное пособие для вузов

Подождите немного. Документ загружается.

Раздел 4. Компьютерная сеть Интернет

289

витель ее не подсчитывал. ICMP, IGMP, UDP и TCP протоколы имеют один

и тот же алгоритм вычисления контрольной суммы. Однако вычисление кон-

трольной суммы для UDP имеет некоторые особенности.

Во-первых, длина UDP-дейтаграммы может содержать нечетное число

байтов, в этом случае к ней добавляется нулевой байт, который служит лишь

для унификации алгоритма и никуда не выдается.

Во-вторых, при расчете контрольной суммы для UDP и TCP добавля-

ются 12-байтные псевдозаголовки, содержащие IP-адреса отправителя и по-

лучателя, код протокола и длину дейтаграммы (рисунок 4.13). Как и в случае

IP-дейтаграммы, если вычисленная контрольная сумма равна нулю, в соот-

ветствующее поле будет записан код 65535 (обратный код 0). При совпаде-

нии контрольной суммы проверяется порт назначения, указанный в заголов-

ке дейтаграммы. Если прикладной процесс подключен к этому порту, то

прикладное сообщение, содержащиеся в дейтаграмме, становится в очередь

к прикладному процессу для прочтения. В остальных случаях дейтаграмма

отбрасывается.

В случае поступления дейтаграмм быстрее, чем их успевает обрабаты-

вать прикладной процесс, при переполнении очереди сообщений поступаю-

щие дейтаграммы отбрасываются модулем UDP.

В связи с тем, что максимальная длина IP-дейтаграммы равна 65535 байтам,

максимальная протяженность информационного поля UDP-дейтаграммы со-

ставляет 65507 байтов (20 байтов минимальная длина IP-заголовка и 8 бай-

тов UDP-заголовка). Обычно на практике большинство систем работает с

UDP-дейтаграммами с длиной не более 8192 байтов.

Рисунок 4.13 – Псевдозаголовок, используемый при расчете контрольной суммы

Компьютерные сети

290

4.3.3. Протокол с установлением виртуальных соединений ТСР

Протокол TCP (Transmission Control Protocol) в отличие от UDP осу-

ществляет доставку отрезков сообщений, называемых сегментами, в виде

байтовых потоков с установлением соединения. Перед тем как какая-либо

сторона предполагает послать данные другой, между ними должно быть ус-

тановлено соединение. Протокол TCP применяется в тех случаях, когда тре-

буется гарантированная доставка сообщений. Он использует контрольные

суммы пакетов для проверки в них ошибок и освобождает прикладные про-

цессы от необходимости тайм-аутов и повторных передач с целью обеспече-

ния необходимой достоверности. Для отслеживания подтверждения достав-

ки в TCP реализуется алгоритм "скользящего" окна.

Максимальный размер сегмента MSS (Maximum Segmet Size) – это

самый большой отрезок данных, который TCP пошлет на удаленную сторо-

ну. В процессе установления соединения каждая сторона может объявить

свой MSS. IP-дейтаграмма, осуществляющая передачу ТСР-сегмента, обыч-

но на 40 байтов больше, в связи с тем, что 20 байт отводится под TCP- заго-

ловок и 20 байтов под заголовок IP.

Модуль TCP также, как и UDP, выполняет функции мультиплексо-

ра/демультиплексора между прикладными процессами и IP-модулем. При

поступлении пакета в модуль IP он будет передан в TCP- или UDP-модуль, в

зависимости от кода, записанного в поле протокола данного IP-пакета. Фор-

мат сегмента (пакета) TCP изображен на рисунке 4.14.

Каждый TCP сегмент содержит номера портов (port number) отправи-

теля и получателя, с помощью которых идентифицируются отправляющее и

принимающее приложения. Эти два значения вместе с IP-адресом источника

и получателя в IP-заголовке уникально идентифицируют каждое соединение.

Комбинация IP-адреса и номера порта называется сокетом (socket).

Пара сокетов, содержащая IP-адрес клиента, номер порта клиента, IP-адрес

сервера и номер порта сервера, указывает две конечные точки, однозначно

идентифицирующие каждое TCP-соединение.

Номер последовательности SN (sequence number) – порядковый но-

мер первого октета в поле данных сегмента среди всех октетов потока дан-

ных для текущего соединения, т.е., если в сегменте пересылаются октеты с

2001-го по 3000-й, то SN=2001. Если во время фазы установления соедине-

ния в заголовке сегмента активизирован бит SYN, то в поле SN записывается

начальный номер ISN (Initial Sequence Number). Номер первого октета дан-

ных, посылаемых после завершения фазы установления соединения, равен

ISN+1. Номер последовательности представляет собой 32-битное беззнако-

вое число, переходящее через 0 по достижению значения (2

– 1).

Раздел 4. Компьютерная сеть Интернет

291

Номер подтверждения ACK SN (acknowledgment number) – это сле-

дующий номер байта в последовательности, который ожидает получить от-

правитель сигнала подтверждения. Обратите внимание, что в ТСР-протоколе

нумеруются не сегменты, а байты потока, поступающего от приложения. В

связи с тем, что каждый байт, участвующий в обмене, пронумерован, то но-

мер подтверждения – это номер последнего успешно принятого байта дан-

ных, увеличенный на 1. Поле ACK SN принимается в рассмотрение только в

случае, если имеется сигнал подтверждения (флаг ACK установлен в едини-

цу).

Длина заголовка (header length) занимает 4 бита и указывает длину

заголовка в 32-битных словах. Введение этого поля в заголовок объясняется

переменной длиной поля опций. Максимальная длина заголовка 60 байтов.

Без опций стандартный размер заголовка составляет 20 байтов.

Флаги (Flags) занимают 6-разрядное поле, биты которого имеют сле-

дующее значение:

 URG (urgent pointer) – указатель срочности показывает, что поле

"Указатель срочности" должно приниматься во внимание;

 ACK (acknowledgment) указывает получателю, что номер подтвержде-

ния необходимо принять в рассмотрение;

 PSH (Push) - получатель должен передать приложению данные этого

сегмента немедленно;

 RST (Reset) – сбросить соединение; при получении сегмента с уста-

новленным флагом RST соединение ликвидируется, недоставленные данные

уничтожаются;

Рисунок 4.14 – Формат протокола ТСР

Компьютерные сети

292

 SYN – запрос на установление соединения;

 FIN (finish) означает, что отправитель заканчивает посылку данных.

В сегменте одновременно могут быть установлены несколько флагов.

Размера окна (window size) – это количество байт, начинающееся с

указанного в поле номера подтверждения, которое приложение готово при-

нять. Этот параметр служит для управления потоком данных TCP. Очевид-

но, что 16-битовое поле ограничивает размер окна в 65535 байтов.

Контрольная сумма (checksum) охватывает собой весь TCP-сегмент,

т.е. TCP-заголовок и TCP-данные. Это обязательное поле, которое должно

быть рассчитано и сохранено отправителем, а затем проверено получателем.

Контрольная сумма TCP рассчитывается так же, как контрольная сумма

UDP, с использованием псевдозаголовка.

Указатель срочности используется для задания длины данных, кото-

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

последнего октета со срочными данными относительно первого октета в

сегменте. Например, в сегменте передаются октеты с 2001–го по 3000–й, при

этом первые 100 октетов являются срочными данными. В этом случае в ука-

зателе срочности будет находиться число 100.

Поле "Опции" имеет переменную длину; может отсутствовать или со-

держать одну опцию либо список опций, реализующих дополнительные ус-

луги протокола ТСР. Максимальная длина опций равна 40 байтам. Наиболее

распространенными опциями являются: "Максимальный размер сегмента",

"Масштабирование окна", "Выборочные подтверждения разрешены" и др.

Поле опций состоит из октета, определяющего тип опции, затем может сле-

довать октет с длиной опции и октеты с данными для опций.

Максимальное значение размера сегмента MSS зависит от ряда факто-

ров. Если IP-адрес назначения "не локальный", MSS обычно устанавливается

по умолчанию – 536. Некоторые операционные системы объявляют MSS,

равный 1460, когда обе стороны находятся на одной сети Ethernet. В процес-

се установления соединения каждая сторона может объявить свой MSS. В

общем случае, чем больше MSS, тем лучше, до тех пор, пока не происходит

фрагментация.

Для установления TCP-соединения необходима посылка трех сегмен-

тов с получением подтверждения (рисунок 4.15). Такую процедуру называют

трехразовым рукопожатием (three-way handshake). Она осуществляется сле-

дующим образом.

 Сегмент 1: Запрашивающая сторона А отправляет с установленным

флагом синхронизации (SYN=1) сегмент с указанием номера порта удален-

ного компьютера Б, к которому станция А хочет подсоединиться, и началь-

ный номер последовательности ISN (Initial Sequence Number). В данном

примере ISN =4712, начиная с которого будут отсчитываться отправляемые

Раздел 4. Компьютерная сеть Интернет

293

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

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

 Сегмент 2: Станция Б откликается ТСР-сегментом, в заголовке кото-

рого установлен бит АСК, подтверждающий установление соединения с

компьютером А и установлен номер подтверждения ACK SN, равный ISN(А)

+1=4713, свидетельствующий о готовности Б к получению данных от ком-

пьютера А, начиная с номера 4713. В связи с тем, что протокол ТСР обеспе-

чивает полнодуплексную передачу данных, то компьютер Б в этом же сег-

менте устанавливает бит SYN, означающий запрос начала сеанса для пере-

дачи данных от Б к А, и передает свой исходный номер последовательности

(в нашем примере ISN(Б)=8136). Полезных данных этот сегмент тоже не со-

держит.

 Сегмент 3: Станция А посылает сегмент в ответ на сегмент, получен-

ный от компьютера Б. В связи с тем, что соединение считается установлен-

ным (получено подтверждение от Б), то станция А может включать в свой

сегмент данные, нумерация которых начинается с ISN(А) +1. Данные нуме-

руются по количеству отправленных октетов. В заголовке этого же сегмента

устанавливается бит АСК, подтверждающий установление соединение БА.

На временной диаграмме показан также процесс разрыва соединения,

которое произошло на этапе, когда станции А и Б успели передать по 1830

байтов каждая. Процедура разрыва соединения инициируется посылкой сег-

мента с установленным флагом FIN и номером последовательности. Разрыв

завершается передачей противоположной станций пакета подтверждения.

Рисунок 4.15 – Временная диаграмма установления и разрыва соединения

Компьютерные сети

294

Как отмечалось выше, в процессе посылки сегмента SYN с целью от-

крытия соединения активная сторона указывает исходный номер последова-

тельности ISN для этого соединения. Это значение берется с 32-битного

счетчика, который увеличивается на единицу каждые 4 микросекунды.

Счетчик номера последовательности устанавливается в 0 при начальной

инициализации ТСР-модуля, и после переполнения снова начинает счет с

нуля. Очевидно, что при установлении очередного соединения ISN будет

каждый раз разным. Использование номеров последовательностей позволяет

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

очередностью изменения ISN отбрасываются, а передающая сторона повто-

ряет сегменты, не дошедшие до узла назначения.

После установки соединения обе стороны могут начать обмен пакета-

ми данных. Источник посылает данные потребителю и ждет от него под-

тверждений об их получении. При этом каждый поступивший без ошибок

сегмент данных подтверждается посылкой сегмента с соответствующим но-

мером правильно принятых октетов. Затем источник снова посылает данные

и т.д., пока сообщение не закончится. Получатель определяет, что сообще-

ние закончилось по появлению сегмента с установленным флагом FIN, что

означает "нет больше данных".

В дуплексном TCP-соединении данные могут передаваться в любом

направлении независимо от противоположного направления. Поэтому при

завершении соединения каждое направление должно быть закрыто незави-

симо от другого. Для того чтобы разорвать соединения требуется посылка

четырех сегментов. Процесс закрытия состоит в том, что обе стороны долж-

ны после завершения обмена данными послать сегмент с установленным

флагом FIN. В момент обнаружения модулем TCP в принимаемом сегменте

установленного в "1" флага FIN, он уведомляет приложение о том, что уда-

ленная сторона разрывает соединение и прекращает передачу данных в этом

направлении.

Сторона, которая первой закрывает соединение, т.е. отправляющая

первой FIN, осуществляет так называемое активное закрытие, а другая сто-

рона, принявшая этот FIN, осуществляет пассивное закрытие. Обычно, одна

сторона выполняет активное закрытие, а другая – пассивное. Однако актив-

ное закрытие могут реализовать и обе стороны. Этот случай и изображен на

временной диаграмме.

Передача данных на транспортном уровне с использованием протоко-

ла ТСР может осуществляться в интерактивном (диалоговом) и неинтерак-

тивном (пакетном) режимах. TCP способен обрабатывать оба типа данных,

однако при передаче разных типов данных используются различные алго-

ритмы.

Рассмотрим как осуществляется передача данных при вводе интерак-

Раздел 4. Компьютерная сеть Интернет

295

тивной команды на примере соединения приложения Rlogin. Это приложе-

ние обычно посылает от клиента серверу по одному символу данных. Каж-

дое нажатие оператором клавиши генерирует один пакет данных. Причем, от

клиента серверу в пакете посылается только 1 байт данных. Передаваемые

пакеты имеют стандартный размер 41 байт: 20 байтов IP-заголовок, 20 бай-

тов TCP-заголовок и 1 байт данных. В ответ на этот пакет сервер Rlogin от-

правляет свой пакет, в котором отражает эхом символ, переданный клиентом

(рисунок 4.16).

Таким образом, на одно нажатие клавиши генерируется 4 сегмента: (1)

интерактивный ввод символа от клиента, (2) подтверждение получения сим-

вола от сервера, (3) эхо-передача сервером введенного символа и (4) под-

тверждение на эхо от клиента. Обычно сегменты 2 и 3 объединяются, т.е.

подтверждение введенного символа отправляется вместе с эхо. В приложе-

нии Telnet предусмотрена опция, которая позволяет отправить целую строку

ввода от клиента серверу. Тем самым уменьшается загрузка сети.

Маленькие пакеты, называемые тиниграммами (от англ. tiny – ма-

ленький) обычно не создают проблем для локальных сетей, так как боль-

шинство их из-за высокой пропускной способности не перегружается. Одна-

ко поток таких пакетов может привести к перегрузке глобальной сети. Для

предотвращения перегрузки Дж. Наглом был предложен простой и эффек-

тивный алгоритм, который получил название алгоритм Нагла.

Суть алгоритма состоит в том, что первый пакет с одним символом

данных отправляется обычным образом. До прибытия подтверждения на

прием этого символа данные, поступающие от источника, не передаются, а

накапливаются в буфере. После получения подтверждения на первый символ

модуль ТСР отправляет накопленные в буфере символы в одном сегменте.

Очевидно, что при этом появляется задержка от момента нажатия клавиши,

Рисунок 4.16 – Временная диаграмма передачи сегментов в интерактивном режиме

Компьютерные сети

296

до момента поступления символа на сервер.

Достоинство этого алгоритма заключается в том, что он сам настраи-

вает темп передачи: чем быстрее придет подтверждение, тем быстрее будут

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

подтверждения достаточно большая, компьютер-источник отправляет паке-

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

ность передаваемых сегментов и повышается эффективная скорость переда-

чи данных.

В ряде случаев задержка, возникающая при использовании алгоритма

Нагла, недопустима, например, передача координат перемещения манипуля-

тора "мышь". Для устранения этого недостатка предусмотрена команда от-

ключения алгоритма Нагла.

В случае передачи данных в неинтерактивном режиме в передаваемом

сегменте размещается группа символов, количество которых определяется

максимальным размером сегмента (например, MSS=1024 байта). При этом в

канал передается несколько сегментов без ожидания подтверждения пра-

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

дания подтверждения сегментов определяется шириной окна, задаваемого в

поле заголовка ТСР-сегмента.

4.3.4. Протокол динамической конфигурации сетевых компьютеров

DHCP

Протокол динамической конфигурации хоста DHCP (Dynamic Host

Configuration Protocol) предназначен для автоматической настройки пара-

метров стека TCP/IP сетевого компьютера в момент его загрузки или по тре-

бованию пользователя. Этот протокол организован по принципу клиент-

сервер: клиент запрашивает информацию, делая широковещательный запрос

в сеть, а сервер сообщает ее клиенту в ответ. Протокол DHCP использует

транспортный протокол UDP для передачи сообщений между клиентом

(порт 68) и сервером (порт 67). Протокол динамической настройки парамет-

ров имеет смысл применять в сетях с большим количеством компьютеров.

Если сеть состоит всего лишь из нескольких компьютеров, проще дать им

фиксированные IP-адреса, чем заниматься настройкой DHCP.

Серверы DHCP используются для динамического назначения IP-

адресов, а также для сообщения клиентам DHCP такой настроечной инфор-

мации, как маска сети, адрес сервера имен и т.д. Обязательно выделяется

только адрес и маска, все остальные параметры назначаются в зависимости

от настроек сервера и клиента DHCP.

Раздел 4. Компьютерная сеть Интернет

297

Протокол DHCP позволяет клиенту передавать серверу желаемое имя

и адрес компьютера. В большинстве случаев выдача IP-адреса привязана к

MAC-адресу. Компьютер, идентифицированный в DHCP по MAC-адресу, не

получает выданный IP навсегда: адрес сдается ему в "аренду" (lease) на не-

которое время. Если до истечения срока аренды абонент не подтвердил же-

лание пользоваться адресом и дальше (не послал повторный DHCP-запрос),

адрес считается незанятым. Но когда компьютер подключается к сети после

долгого перерыва, сервер DHCP сначала просматривает "арендную историю"

на предмет того, какой IP этому абоненту уже выдавался. Если этот IP не за-

нят, то будет выдан именно он. И только когда к сети подключится совсем

новый абонент (а все адреса уже когда-нибудь кому-то выдавались) среди

них будет выбран и отдан в аренду новичку тот, который дольше всех оста-

вался невостребованным. После подключения новой станции к сети, в кото-

рой может быть несколько DHCP-серверов, станция (клиент DHCP) отправ-

ляет широковещательное сообщение DHCPdiscover "Поиск адреса". В это

сообщение клиент может включить желаемые параметры конфигурации (IP-

адрес, срок аренды и т.п.). Все DHCP-серверы сети отвечают на этот запрос

предложением DHCPoffer с перечнем предлагаемых сетевых адресов. Если в

течение определенного времени не поступило ни одного предложения, то

клиент начинает процесс заново.

Получив предложение, клиент на основании своих настроек решает

принять предложение определенного сервера или первое поступившее (если

никаких настоек нет). В это время серверы DHCP резервируют предложен-

ные адреса. Затем клиент извещает соответствующий сервер о принятом ре-

шении посылкой сообщения DHCPrequest, в котором указывается идентифи-

катор данного сервера и параметры конфигурации. Сообщение DHCPrequest

регистрируют все DHCP-серверы. Те из них, которые не обнаруживают сво-

его идентификатора в этом сообщении разблокируют невыбранные адреса.

Избранный DHCP-сервер передает клиенту подтверждение с дополнитель-

ными конфигурационными параметрами. Выбранный же клиентом сервер

закрепляет за клиентом сетевой адрес, устанавливает срок аренды и под-

тверждает это посылкой сообщения DHCPack. Если же сервер по какой-либо

причине не может удовлетворить клиента (например, пакет DHCPrequest за-

держался и сервер уже выдал адрес другому клиенту), то сервер отвечает со-

общением-отказом DHCPnack.

После завершения работы клиент может освободить занимаемый адрес

путем отправления серверу сообщения DHCPrelease.

Компьютерные сети

298

4.4. Маршрутизация в IP-сетях

4.4.1. Общие принципы маршрутизации в объединенных сетях

Объединенная компьютерная сеть состоит из множества физических

сетей, связанных посредством специальных компьютеров, называемых мар-

шрутизаторами. Каждый маршрутизатор напрямую подключается как мини-

мум к двум сетям. Компьютер пользователя (хост) обычно подключен толь-

ко к одной сети. В процессе доставки IP-дейтаграмм до конечного получате-

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

хосты, за которыми работают пользователи. На рисунке 4.17 показан вари-

ант сети Б, в которой находятся два маршрутизатора М1 и М3, каждый из

которых может обеспечить доставку дейтаграмм от хоста Б1 к хосту А1 сети

А. В этом случае, несмотря на то, что хост Б1 имеет только одно сетевое

подключение, он должен самостоятельно осуществить маршрутизацию к

хосту А либо через маршрутизатор М1 или М3.

В сетях с коммутацией пакетов под термином маршрутизация

(routing) понимается процесс выбора пути, по которому должны передавать-

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

выбора пути следования пакетов до конечного получателя, называются мар-

шрутной информацией.

Программы маршрутизации должны анализировать загрузку сети,

длину дейтаграммы, а также запрошенный в ее заголовке тип обслуживания,

и на основе полученных данных выбирать оптимальный маршрут. Однако

Рисунок 4.17

–

Схема определения маршрута хостом и маршрутиз

торами