Кришнамурти Б., Рексфорд Дж. Web-протоколы. Теория и практика

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

140 Часть III. Web-протоколы

5.1.3.

IP-адреса

Хосты в Internet идентифицируются числовыми адресами. Вернувшись к анало-

гии с почтой, можно заметить, что IP-пакет схож с отправленным письмом. Письмо

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

пересылает письмо, используя информацию об адресате; содержимое письма не

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

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

времени. Почте совершенно нет дела до взаимосвязей между этими письмами. Ка-

ждое письмо направляется независимо. Отправитель и получатель ответственны за

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

нятие решения, следует ли отправлять ответ, и когда это сделать. Заголовок IP-па-

кета содержит всю информацию, необходимую маршрутизатору для того, чтобы

доставить содержимое в соответствующее место назначения.

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

носится к конкретному компьютеру^ например, Web-серверу. В IP-заголовке адрес

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

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

вует 2^^ местам назначения. Адреса в Internet имеют иерархическую структуру.

Снова обратимся к аналогии с обычной почтой. У жителей одного района имеется

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

ответствующее данному индексу. Затем это почтовое отделение может использо-

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

IP-адрес делится на сетевую часть и часть, соответствующую хосту. Прокладка

маршрута в Internet основывается на сетевой части адреса. Большинству маршру-

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

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

щему компьютеру-получателю используется часть адреса, определяющая хост.

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

Изначально IP-адреса относились к трем классам в зависимости от числа 8-битных

октетов, выделенных для адреса сети и адреса хоста; два других класса адресов ре-

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

рис.

5.3 показано деление 32-битного IP-адреса на адрес сетевую'часть и адрес хоста:

• Класс А. Адреса класса А начинаются с

в первом бите и используют первый

октет для адреса сети, оставляя три октета (24 бита) для адреса хоста. Следо-

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

до

127 (что соответствует двоичным числам 00000000 и 01111111, соответствен-

но).

Сеть класса А включает в себя 16 777 216 (2?^) IP-адресов.

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

может быть выделена сеть класса В. Адрес класса В начинается с 10 в первых

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

два октета

—

для адреса хоста. Сеть класса В включает 65 536 (2^^) адресов.

• Класс С. Адреса класса С могут быть выделены небольшим организациям.

Адрес начинается с 110 в первых трех битах и использует первые три октета

для адреса сети и только последний октет для адреса хоста. В Internet имеется

большое число сетей класса С, каждая из которых имеет по 256 адресов.

Точнее сетевому интерфейсу.

—

Прим.

ред.

Глава

Протоколы,

связанные

HTTP

141

• Класс D. IP-адреса, относящиеся к классу D (начинаются с 1110), использу-

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

ров.

• Класс Е. Адреса класса Е (начинаются с 11110) зарезервированы для будуще-

го использования.

Класс

1 сеть (7

бит)

хост (24

бита)

Класс

1 1 0

1 сеть (14

бит)

хост (16

битов)

Класс

1 1 1 1 0

1 сеть (21 бит)

хост (8 битов)

Класс

1 1 1 1 1 1 0 1

групповое вещание (28 битов)

Класс

1 1 1 1 1 1 1

[зарезервировано (27

битов)|

Рис.

5.3. Пять классов IP-адресов

Деление на октеты обусловливает представление IP-адресов в

точечной

нотации,

при которой каждый октет записывается в виде десятичного числа в диапазоне от

до 255 (2^ - 1) и отделяется от других точкой. Например, запись 122.5.208.78 будет

корректна для IP-адреса, а запись 373.57.7.300

—

некорректна. Сеть класса А 12.0.0.0

состоит из IP-адресов в диапазоне от 12.0.0.0 до 12.255.255.255.

Ограничение размера IP-адреса 32 битами накладывает серьезное ограничение на

количество хостов в Internet. Быстрое увеличение числа компьютеров в Internet

в 90-е годы прошлого века привело к истощению доступного адресного пространст-

ва. Все больше и больше таких устройств, как телефоны, торговые автоматы и тосте-

ры,

получают собстве1П1ые IP-адреса. Однако первоначально сеть ARPANET была

разработана для поддержки относительно небольшого числа хостов. Тогда не пред-

полагалось, что Internet станет общедоступной, всеобъемлющей, глобальгюй инфра-

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

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

получила название версии 4 (IPv4) протокола IP. Проект стандарта RFC 2460

[DH98] для версии 6 протокола Internet Protocol (IPv6) ориентирован на 128-бит-

ное адресное пространство [Hui98]. Однако IPv6 требует значительных изменений

в инфраструктуре Internet. Во время подготовки этой книги к публикации широкого

распространения IPv6 не наблюдалось. Вместо этого используются альтернативные

возможгюсти решения проблемы истощения адресного пространства IPv4.

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

были разработаны различные способы. Например, некоторые организации при-

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

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

жим, что у провайдера Internet имеется 500 модемов и 20000 клиентов. В любой

заданный момент времени к сети подключено максимум 2,5% клиентов. Провайдер

может оперировать гораздо меньшим пулом IP-адресов, присваивая IP-адрес поль-

зователю, когда устанавливается модемное соединение. Точно так же, компании

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

ративной сети, и иметь один компьютер (межсетевой экран или прокси-сервер),

который координирует взаимодействие с Internet. Компьютеры внутри корпора-

тивной сети невидимы для остальной части Internet; тем самым им не нужно иметь

142

Часть

III. Web-протоколы

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

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

Однако подобные механизмы окончательно не решают проблему истощения

пространства IP-адресов. Чтобы замедлить этот процесс, инфраструктура Internet

была видоизменена с целью обеспечения большей гибкости при выделении блоков

IP-адресов. Ограничение на фиксированные размеры блока адресов было снято

с появлением бесклассовой междоменпой маршрутизации (CIDR — Classless

InterDomain Routing) в начале 90-х годов [RL93, FLYV93, FRB93]. Технология

CIDR позволила задавать разделение между сетевой частью и частью хоста IP-ад-

реса в любой точке 32-разрядного двоичного числа. Таким образом, размер блока

IP-адресов может быть любой степенью 2. Сеть CIDR идентифицируется по сете-

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

вую часть адреса. Например, рассмотрим сеть 204.70.2.0/23. Адрес сети длиной

23-бита оставляет 9 из 32 битов для представления 512 (2^) хостов в этой сети. По-

следние 9 битов могут варьироваться от 000000000 до 111111111. Младший бит

третьего октета может иметь значения

или 1, что соответствует диапазону чисел

от 00000010 до 00000011. Следовательно, IP-адреса в этом блоке находятся в диа-

пазоне от 204.70.2.0 до 204.70.3.255.

Переход к CIDR дает два важных преимущества. Во-первых, распределение бло-

ков IP-адресов стало более гибким, что позволило эффективнее использовать

32-битное адресное пространство. Например, нужные организации 512 адресов мо-

1ут быть назначены с помощью блока, имеющего 23-битную маску (что позволяет

получить 2^ = 512 адресов), вместо того, чтобы выделять целую сеть класса В

(с 2^^ = 65536 адресами). Во-вторых, CIDR дал возможность провайдерам объеди-

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

деру была выделена сеть 12.0.0.0/8. Этот большой блок адресов может быть поделен

на меньшие блоки, предоставляемые клиентам дап1Юго провайдера. Например, один

клиент может иметь сеть 12.45.0.0/16, а другой

—

сеть 12.194.34.0/23. Выделение ад-

ресных блоков может зависеть от «размеров» клиента. Большой адресный блок, на-

пример, 12.45.0.0/16, может быть выделен крупному клиенту, в то время как мень-

ший блок, такой как 12.194.34.0/23, может вполне устроить мелкого клиента.

Провайдеру необходимо знать, как осуществить доступ к каждой из этих отдель-

ных сетей. Оста7шпой же части Internet нужно лишь знать, как обратиться к сети про-

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

информацию о маршрутах для блоков 12.45.0.0/16 и 12.194.34.0/23, маршрутизаторы

остальной части Internet могут хранить один маршрут для всего блока 12.0.0.0/8. При

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

шрутизатор должен переслать пакет провайдеру, ответствен!юму за блок 12.0.0.0/8.

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

ным получателем пакета. Вернемся к aнaJЮгии с обычной почтой, в которой почтовый

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

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

лю.

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

отличием сетей CIDR является то, что число уровней иерархии и число битов, ис-

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

1Р-маршрутазации вы можете узнать в других книгах [HuiOO, НМОО, Ste99].

Глава 5. Протоколы, связанные с HTTP

143

5.1.4. Заголовок IP

Каждый IP-пакет имеет заголовок, нредставлегпхый на рис. 5.4. Поля IP-заголов-

ка обычно заполняются операционной системой хоста-отправителя. Хотя IP-мар-

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

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

вителем и получателем:

• Номер версии (4 бита). 4-битный номер версии обычно имеет значение 4, что

соответствует версии IPv4. Знание номера версии дает возможность маршрути-

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

Другие версии протокола, например, IPv6, мохут иметь игюй формат заголовка.

• Длина заголовка (4 бита). 4-битное поле длины заголовка указывает на число

4-байтовых слов в заголовке. Основная часть IP-заголовка состоит из 20 байтов

(пять 4-байтовых слов), но при использовании опций IP возможно использова-

ние более длинных заголовков. Длина IP-заголовка всегда кратна 32 блтам.

• Тип сервиса (8 битов). 8 бит типа сервиса (TOS

—

Туре Of Service) изначаль-

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

кета по сети. Например, маршруты могут иметь различные характеристики

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

ность или высокая надежность. Пакет голосового 1Р-сообш;ения должен пере-

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

вительны к времени ожидания. В противоположность этому пакет большого

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

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

сти.

Однако большинство маршрутизаторов не осуществляли выбор маршрута

на базе TOS, поэтому эти биты редко использовались. Повышение в 90-х го-

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

ной способности, заставило вновь вернуться к исхюльзованию битов TOS с це-

лью воздействовать на способ использования буферов и каналов для различ-

ных классов трафика.

0 4 8 16 20 32

версия

длина

загол.

тип сервиса

идентификация

время жизни протокол

общая длина

флаги

смещение

фрагмента

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

заголовка

IP-адрес источника

IP-адрес получателя

Рис. 5.4. Формат 1Р-пакста

144 Часть III. Web-протоколы

• Общая длина (16 битов). 16-битное ноле общей длины указывает на общее

число байтов в пакете. IP-пакет может содержать до 65536 (2^^) байтов. Одна-

ко большинство технологий канального уровня не могут обрабатывать такие

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

ются J^^бгк:cг/JW(Злъ«oй длиной пакета (MTU

—

Maximum Transmission Unit). На-

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

1500 байтов. Ограничение на MTU может реализовываться двумя способами.

При нервом подходе хост-отправитель избегает посылать IP-пакеты, длина

которых превышает MTU в сетях на пути к хосту-получателю. Но приложе-

ние обычно не может заранее знать значения MTU. При втором подходе боль-

шой IP-пакет делится отправителем или маршрутизатором на два или более

фрагмента. Фрагментация 1Р-накетов поддерживается следующими тремя

полями в IP-заголовке: 16-битпый идентификатор, 3-битные флаги и 13-бит-

пое смещение.

• Идентификация (16 битов). 16-битное поле идентификатора содержит уни-

кальное значение для каждого отправляемого IP-пакета. Перед тем, как пере-

дать пакет, IP-маршрутизатор проверяет, что размер пакета не превышает зна-

чение МТи канала. Слишком большой пакет может быть фрагментирован от-

правителем или промежуточным маршрутизатором. Каждый фрагмент пакета

имеет один и тот же идентификатор. Это дает возможность адресату распо-

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

фрагменты вновь объединяются вместе и протоколу верхнего уровня, напри-

мер,

TCP или UDP, передается один IP-пакет.

• IP-флаги (3 бита). Два из трех

1-битных

флагов относятся к процессу фраг-

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

Бит «дополнительные фрагменты» устанавливается в 1 для всех фрагментов

пакета, кроме последнего. Это гарантирует, что адресат сможет определить,

все ли фрагменты получены. Фрагментация может быть запрещена путем ус-

тановки бита «не использовать фрагменты». При получении пакета излишне

большой длины с установленным битом «не использовать фрагменты» мар-

шрутизатор отвергает пакет и уведомляет отправителя. Уведомление отправ-

ляется с использованием протокола Internet Control Message Protocol (ICMP)

[Pos81].

Этот протокол применяется для передачи сообщений об ошибках и

выборе маршрута.

• Смещение фрагмента (13 битов). 13-битное поле смещение фрагмента содер-

жит смещение (в 8-байтных блоках) этого фрагмента от начала оригиналыюго

IP-пакета. Применение 8-байтных блоков дает возможность использовать

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

до 2^^ (8x2^^) байтов, которое является максимальной допустимой длиной,

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

ное поле длины пакета в IP-заголовке устанавливается в соответствии с чис-

лом байтов в этом фрагменте. Вместе смещение и длина позволяют получате-

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

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

• Время жизни (8 битов). 8-битпое поле времени жизни (TTL

—

Time-To-Live)

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

навливает для поля TTL начальное значение. Затем каждый маршрутизатор

па пути уменьшает значение в поле на единицу или на то число секунд, кото-

рое пакет провел в маршрутизаторе. Когда значение TTL достигает О, пакет

уничтожается, а отправителю посылается сообщение об ошибке по протоко-

Глава 5. Протоколы, связанные с HTTP 145

лу ICMP. Эта процедура призвана решать проблему живучести при IP-мар-

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

отказавший канал связи могут вызвать зацикливание. Как результат, некото-

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

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

ком цикле, потребляют ресурсы сети и маршрутизатора. Пакет, в конце кон-

цов,

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

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

дение получателя. Уничтожение пакетов с истекшим временем жизни (TTL)

позволяет избежать этой проблемы.

• Протокол (8 битов). 8-бит1юе поле протокола идентифицирует высокоуров-

невый протокол, ответственный за отправку IP-пакета. Зарезервированными

являются следуюгцие значения: 1 для ICMP, 6 для TCP и 17 для UDP. Ин-

формация о протоколе имеет важное значение для интерпретации получате-

лем пакета данных, следующих за IP-заголовком. За IP-заголовком обычно

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

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

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

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

правления IP-пакета соответствующему приложению, работающему на компь-

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

головка.

• Контрольная сумма заголовка (16 битов). 16-битная контрольная сумма дает

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

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

один или несколько битов в заголовке, превратив

в 1 или 1 в 0. Повреждение

адреса места назначения может привести к доставке пакета не тому хосту. Пе-

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

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

с некорректной контрольной суммой отвергается хостом-получателем. Мар-

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

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

ние значения поля TTL. Важно заметить, что контрольная сумма применяется

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

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

колом более высокого уровня, таким как UDP или TCP, с помощью отдельной

контрольной суммы.

• IP-адрес источника (32 бита). IP-заголовок включает в себя 32-битный адрес,

который идентифицирует отправителя пакета. Включение адреса отправителя

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

Например, приложение-получатель может захотеть отправить ответное сооб-

щение. Кроме того, маршрутизаторы на пути передачи пакета должны знать

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

ках с помощью протокола ICMP (например, при истечении времени жизни

пакета). Помимо этого многие маршрутизаторы могут быть настроены так,

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

фильтрацию пакетов на основе поля адреса отправителя.

• IP-адрес получателя (32 бита). 32-бит11ый адрес гюлучателя необходим для

идентификации получателя пакета. При получении пакета маршрутизатор ис-

146 Часть III. Web-протоколы

пользует IP-адрес получателя для определения «следующего сегмента» на

пути к получателю.

• Опции IP (переменная длина). Последнее поле IP-заголовка содержит список

переменной длины для необязательной информации, общая длина опций крат-

на 32 битам. Опции IP могут использоваться для дополпрпельного управления

маршрутизацией, в целях безопасности или для добавления маршрутизаторами

в пакет отметки времени. Например, опция «исходная маршрутизация» позво-

ляет отправителю задавать маршрут для пакета. Маршрут задается как список

IP-адресов маршрутизаторов на пути передачи. Опция «исходная маршрутиза-

ция» начинается с 3 байтов, которые содержат код опции, длину опции и указа-

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

шрутизаторов. Поскольку большинство маршрутизаторов оптимизированы для

работы с 20-байтными заголовками фиксировагнюго формата, что является ти-

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

нее.

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

маршрутизаторы не поддерживают все имеющиеся опции.

Отправитель 1Р-накета управляет содержимым заголовка. На протяжении мно-

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

предназначению протокола:

• Спуфинг адресов источника. IP-адрес источника обычно соответствует IP-ад-

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

в поле адреса источника произвольное значение. Такая подмена адреса источ-

ника, или спуфинг (spoofing), обычно делается, когда отправитель хочет атако-

вать хост-получатель или сеть. Использование некорректного IP-адреса ис-

точника затрудняет установление инициатора атаки. Хотя отправитель не по-

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

хост и сеть получателя нежелательным трафиком. Это называется атакой от-

каза от обслуживания (DoS — Denial of Service).

• Определение MTU на пути следования. Бит «не фрагментировать» в IP-заго-

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

шенного для передачи маршрутизаторами на его пути в сети [MD90]. Фрагмен-

тация пакета может быть нежелателыюй но нескольким причинам [КМ87]. Вы-

полнение фрагментации и последующая сборка загружает маршрутизатор и

компьютер получателя, соответственно. Кроме того, потеря одного фрагмента

(например, вследствие переполненрш буфера следующего на пути маршрутиза-

тора) приводит к потере всего 1Р-накета, поскольку в IP отсутствует механизм

для повторной передачи утерянного фрагмента. При отказе от фрагмегпации

компьютеру-отправителю необходимо знать размер MTU на пути следования

к получателю. ЮМР-сообщения для пакетов с размером, превышающим допус-

тимый, предоставляет для отправителя возможность получить MTU на пути

к получателю. Отправитель может поэкспериментировать с отправкой пакетов

различного размера с установленным битом «не фрагментрфовать», чтобы гю-

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

вать сообщение об ошибке. На практике различия в значениях MTU для раз-

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

ственной проблемы. Коммуникационное программное обеспечение большинст-

ва компьютеров используют значением MTU но умолчанию (576 или 1500 бай-

тов) чтобы избежать фрагментации пакетов внутри сети.

Глава 5. Протоколы, связанные с HTTP 147

• Идентификация переходов на пути к получателю. Как и бит «не фрагменти-

ровать», поле времени жизни TTL дает отправителю способ получить инфор-

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

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

TTL, равным 1. После этого первый маршрутизатор отправит сообщение об

ошибке с помощью протокола ICMP, включающее информацр1ю, идентифици-

рующую маршрутизатор. Повторение процесса с увеличенными значениями

TTL дает возможность отправителю идентифицировать последующие мар-

шрутизаторы на пути. Этот процесс положен в основу популярной утилиты

traceroute

[Jac],

которая используется для диагностирования и устранения

проблем с маршрутизацией. Однако traceroute не всегда дает точный мар-

шрут от начала и до конца. Поскольку IP не гарантирует, что последующие

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

значениями TTL могут идентифицировать маршрутизаторы на различных

маршрутах. Аналогично, IP не гарантирует, что пакеты, отправляемые компь-

ютером А компьютеру В будут проходить по тому же пути, по которому следу-

ет обратный трафик от В к А. Следовательно, traceroute предоставляет ин-

формацию только о пути от А к В, по не об обратном пути от В к А. Для того

чтобы узнать обратный путь от В к А, необходимо выполнить traceroute

с компьютера В.

IP предлагает простой и устойчивый сервис по доставке пакетов, который рабо-

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

протоколов транспортного уровня.

5.2. Transmission Control Protocol

Протокол Transmission Control Protocol (TCP) координирует передачу данных

между двумя приложениями. Приложения взаимодействуют, осуществляя чтение

и запись с помощью сокетов (socket), которые позволяют представить передавае-

мые данные как упорядоченный поток байтов с гарантированной доставкой. TCP

обеспечивает логическое соединение между двумя конечными пунктами на основе

сервиса по доставке пакетов IP. TCP-отправитель делит данные на сегменты и пе-

редает каждый сегмент в IP-пакете вместе с ТСР-заголовком. Перед началом пере-

дачи данных конечные пункты должны договориться об установлении ТСР-соеди-

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

ком данных и повторной передачей утерянных IP-пакетов. Кроме того, каждый

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

жать ее перегрузки. ТСР-заголовок содержит информацию, необходимую для ко-

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

робнее о TCP вы можете узнать из других книг [Ste94, KROOJ.

5.2.1.

Абстракция сокетов

Абстракция сокетов обеспечивает падежное двунаправленное взаимодействие

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

Создание приложений, которые непосредственно передают и получают 1Р-накеты,

сопряжено с большими сложностями. Вместо этого для координации передачи

В операционных системах семейства Windows эта утилита называется traccrt.

—

Прим.

ред.

148 Часть III. Web-протоколы

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

транспортного уровня. Многим приложениям нужно, чтобы они передавали дан-

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

запись в файл или чтение из файла. Если отправитель передает 5000 байтов, полу-

чатель должен получить 5000 байтов. Процесс передачи не должен вызывать уте-

рю,

повреждение данных или изменение порядок байтов. Таким образом, передаю-

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

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

доставляет такого сервиса. Этот сервис предоставляется протоколом Transmission

Control Protocol (TCP), который обычно реализуется в операционной сисч^.ае каж-

дого хоста, подключешюго к Internet.

Приложение использует TCP путем создания сокета (двунаправлегнюго кана-

ла),

что сходно с открытием файла. Оба приложения должны иметь однозначный

способ для идентификации сокета. Знать IP-адреса двух компьютеров недостаточ-

но.

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

ложение, например, Web-сервер, может работать с несколькими сокетами. Каждый

сокет ассоциируется с номером порта на каждом конце соединения. Номер порта

представляет собой 16-битное целое число в диапазоне от О до 65535. Номера,

меньшие 1024, являются известными портами, зарезервированными для опреде-

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

HTTP. Назначение номеров портов приложениям осуществляется организацией но

административному управлению доменами Internet Assigned Number Authority

(IANA). Оставшиеся номера портов в диапазоне от 1024 до 65535 могут быть ис-

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

ный Internet-сервис может не иметь общеизвестного зарезервированного порта.

Тогда выбирается номер порта, который де-факто станет стандартным для этого

приложения.

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

ется с портом 80 на компьютере сервера. Однако не возбраняется и выбор другого

номера порта. Например, Web-сервер может быть сконфигурирован для прослуши-

вания клиентских запросов на порту 8000. В этом случае клиенту необходимо

знать, что следует запрашивать соединение с портом 8000, а не с портом 80. Это

достигается путем указания номера порта в URL. Например, если пользователь за-

прашивает ресурс http://www.foo.comiSOOO/bar.html, клиент должен создать со-

кет, который соединяется с портом 8000 сервера, а не с портом 80. Клиенту также

нужен номер порта на своей стороне соединения. В противном случае сервер не бу-

дет знать, как направлять данные клиенту. В процессе создания сокета операцион-

ная система на компьютере клиента присваивает клиентскому приложению вре-

менный номер порта (от 1024 до 65535). Сокет идентифицируется по пяти инфор-

мационным составляющим: двум IP-адресам (для компьютеров, выполняющих

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

ждой стороне соединения) и протоколу (TCP).

Приложения создают сокеты с помощью системных вызовов, реализуемых опера-

ционной системой. Допустим, приложение А (например, Web-клиент) создает сокет

для соединения с удаленным приложением В (например, Web-сервером). Приложе-

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

ме UNIX для создания нового сокета используется функция socket() [Ste98bj. Затем

приложение делает системный вызов connectQ для связывания сокета с IP-адресом и

номером порта приложения В. Во время выполнения вызова connectQ операционная

система также выбирает неиспользуемый локальный номер порта (от 1024 до 65535)

Глава 5. Протоколы, связанные с HTTP 149

для приложения А. На этот момент операционной системе, выполняющей приложе-

ние А, известны два IP-адреса и два номера порта, которые уникально идентифици-

руют двунаправленное соединение между двумя приложениями. Затем операцион-

ная система инициирует установку ТСР-соединения с приложением В. После того

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

чать чтение данных из сокета и запись данных в сокет.

В противоположность этому, приложение В первоначально играет пассивную

роль в создании соединения. Приложение В ожидает поступления запросов на оп-

ределенный порт для установления соединения. В UNIX это реализуется путем

создания сокета и вызова binclQ для назначения локального номера порта (напри-

мер,

порта 80). Затем приложение В делает системный вызов listenQ для прослу-

шивания запросов на соединение от удаленных приложений. Это заставляет опера-

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

с этим портом. Приложение узнает об этих новых ТСР-соединениях с помощью

системного вызова acceptQ. По умолчанию вызов acceptQ ждет запроса на новое

соединение. После получения запроса завершается создание сокета. С этого момен-

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

кет.

После того, как соединение установлено, любое из приложений может читать или

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

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

нал. Web-клиент (приложение А) инициирует взаимодействие. Клиент записывает

НТТР-занрос в сокет. Сервер (приложение В) ожидает получения да1П1ых через

свой сокет. Затем после поступления данных сервер читает НТТР-занрос из сокета.

После обработки запроса сервер записывает HTTP-ответ в сокет. В то же самое вре-

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

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

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

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

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

Операционная система берет на себя все действия по установке логического со-

единения между двумя приложениями и по координации передачи IP-пакетов. Для

приложения А операционная система выполняет системные вызовы socketQ и

connectQ. Если удаленный хост не отвечает, операционная система информирует

приложение А, что запрос на создание сокета окончился неудачей. Для приложе-

ния В операционная система выполняет функции socketQ, bindQ, listenQ и acceptQ.

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

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

ма направляет данные получателю на удаленный IP-адрес и порт. Точно так же,

при поступлении пакетов операционная система направляет данные соответствую-

щему сокету, основываясь на номере порта. Приложение может затем прочитать

данные из сокета. На нижнем уровне при взаимодействии приложений операцион-

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

ракции упорядоченного, надежного потока байтов.

5.2.2. Упорядоченный, надежный поток байтов

ТСР-соединепие доставляет данные в виде упорядоченного потока, гарантируя

доставку данных. Каждый IP-пакет имеет заголовок, информация в котором иден-

тифицирует хосты отправителя и получателя. Информации из IP-заголовка доста-