Вордовские лекции (1115151), страница 21

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 21)

Дейтаграмма – это пакет протокола IP. Контрольная информация занимает первые пять или шесть 32-битных слов дейтаграммы. Это её заголовок (header). По умолчанию, его длина равна пяти словам, шестое является дополнительным. Для указания точной длины заголовка в нём есть специальное поле – длина заголовка (IHL, Internal Header Length).

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

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

IP доставляет дейтаграммы по адресу, записанному в поле адрес назначения (Destination Address) в слове 5 заголовка. Адрес назначения – это стандартный 32-битный адрес протокола IP. Он определяет номер сети назначения и номер хоста в этой сети. Если хост находится в локальной сети, то пакет доставляется сразу по месту назначения. Если нет, то пакет сначала отправляется на межсетевой шлюз (маршрутизатор). Шлюз – это устройство, передающее пакеты между различными сетями. Процесс выбора шлюза или маршрутизатора называется маршрутизацией. Протокол IP отвечает за маршрутизацию каждого пакета.

Маршрутизация дейтаграмм

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

Компьютерные системы могут передавать данные только внутри той сети, к которой они подключены. Поэтому передача дейтаграмм из одной сети в другую идёт через шлюзы – от одного к другому. Внутри хоста данные проходят пути от уровня прикладных программ до уровня доступа к сети (или наоборот). Дейтаграммы, которые переправляет шлюз, поднимаются только до межсетевого уровня. На этом уровне протокол IP, узнавая адрес получателя данных (на протяжении всего пути следования этот адрес не меняется – меняются промежуточные машины), принимает решение отправить дейтаграмму в одну из сетей, к которым подключен.

На рисунке показано, как используются шлюзы для ретрансляции пакетов. Внутри хостов (будем называть их конечными системами) данные проходят все четыре уровня, а внутри шлюзов (промежуточных систем) они поднимаются только до межсетевого уровня, где протокол IP и принимает решение о маршрутизации.

Поскольку данные (дейтаграммы) могут передаваться непосредственно только между устройствами, объединёнными в одну физическую сеть, то в нашем примере передача пакетов от хоста А1 хосту С1 осуществляется в несколько приёмов, через шлюзы G1 и G2. Сначала хост А1 посылает данные шлюз G1, с которым объединён в сетью А. Шлюз G1 по сети В пересылает данные шлюзу G2. Шлюз G2, наконец, пересылает данные хосту С1, благодаря тому, что они оба подключены к сети С. Очень важно, что хост А1 ничего не знает о шлюзах, находящихся дальше шлюза G1 (то есть о шлюзах, с которыми он не объединён в одну сеть). Он просто посылает данные, адресованные С1 (или вообще любому хосту в сети В или С), этому шлюзу и полностью полагается на его способность правильно ретранслировать пакеты в соответствующую сеть. Точно так же хост С1 не имеет ни малейшего понятия о шлюзе G1 и полностью полагается на свой локальный шлюз G2 при пересылке данных хостам в сети А или В.

С помощью поля время жизни (TTL, Time to live) можно указать, как долго дейтаграмма может прожить в сети. При прохождении через маршрутизаторы это поле уменьшается, как правило на 1 (если дейтаграмма задержалась в маршрутизаторе больше, чем на 1 секунду, значение поля уменьшается больше чем на 1). Как только время жизни уменьшится до 0, маршрутизатор обязан уничтожить дейтаграмму и не передавать её дальше.

Фрагментация дейтаграмм

Когда Internet Protocol готовит данные, полученные от транспортного уровня, он может обнаружить, что сегмент (или пакет) данных не может быть передан по сети целиком. Тогда он принимает решение разбить его на несколько частей – фрагментов. Этот процесс, естественно, называется фрагментацией.

Аналогичная проблема может возникнуть и у шлюза. Дело в том, что каждая физическая сеть имеет так называемый максимальный передаваемый блок (MTU, maximum transmission unit), больше которого она ничего передать не может. Разные сети имеют разные MTU, поэтому шлюз может принять решение о фрагментации и в этом случае. Когда промежуточная машина либо хост назначения получают несколько дейтаграмм, являющимися фрагментами одного и того же сегмента (пакета) данных, происходит обратный процесс – сборка. Транспортный уровень этой машины (или хоста) получает свою порцию данных в нетронутом виде – так, как её передал исходный хост.

Передача дейтаграмм транспортному уровню

Когда протокол IP какого-нибудь хоста получает дейтаграмму, он должен передать данные, содержащиеся в ней, соответствующему протоколу транспортного уровня. Для определения протокола используется поле номер протокола(Protocol Number) из третьего слова заголовка дейтаграммы. Каждый протокол транспортного уровня имеет свой уникальный номер, по которому его и отыскивает протокол IP.

8.3.3.2Протокол ICMP

Неотъемлемой частью IP и межсетевого уровня является Протокол контрольных сообщений Internet (ICMP, Internet Control Message Protocol). Он пользуется сервисом передачи дейтаграмм протокола IP для приёма и посылки собственных сообщений. Эти сообщения выполняют следующие функции:

Контроль за трафиком

Иногда возникает ситуация, когда количество получаемых дейтаграмм становится слишком большим, так что хост или шлюз не успевают их обработать. Тогда отправителю дейтаграмм посылается сообщение Source Quench Message, которое просит временно приостановить пересылку.

Обнаружение недостижимых получателей

Если система обнаруживает, что по какой-либо причине не может отправить дейтаграммы получателю, она оповещает отправителя. В этом случае передаётся сообщение о недоступности получателя (Destination Unreachable Message). Если недостижимый получатель – хост, то сообщение посылает промежуточный шлюз; если протокол транспортного уровня или прикладная программа – сам хост-получатель.

Изменение маршрута дейтаграмм

Шлюз может послать сообщение о переназначении (Redirect Message), чтобы попросить отправителя дейтаграмм использовать другой шлюз (возможно, из-за того, что он быстрее). При этом оба шлюза и отправитель должны быть соединены напрямую. Это связано с идеологией маршрутизации в Internet.

Проверка связи с хостом

С помощью ICMP можно узнать, есть ли связь с каким-нибудь устройством – шлюзом или хостом. Для этого достаточно послать сообщение Echo Message. Дело в том, что если хост или шлюз получают такое сообщение, они обязаны послать его обратно отправителю. Поэтому если ответ приходит – значит устройство работает и связь с ним есть. Если нет ответа – то с этим устройством лучше пока не связываться – всё равно ничего не получится. Кстати, команда ping ОС UNIX работает используя именно это сообщение.

По сути, протокол ICMP является надстройкой над IP, которая выполняет информационные функции, контроль за работой, и диагностирование ошибок.

8.3.3.3Протоколы разрешения адресов на примере адресации в Ethernet (ARP, RARP)

В самом начале этой главы вскользь было упомянуто о том, что IP-адрес имеет сетевой интерфейс, посредством которого устройство обменивается IP-дейтаграммами с другими компьютерами. Однако об этом адресе знает межсетевой уровень, но не имеет представления сетевой уровень. Это происходит из-за того, что в каждой физической сети используется своя схема адресации, отличная от адресации в Internet. Причём сколько разных типов физических сред – столько типов адресации. Сразу возникает вопрос – как адресовать данные, если известен только IP-адрес их получателя? Для этого нужно решить задачу отождествления физических адресов сетевых устройств и их IP-адресов.

Мы рассмотрим один из способов решения этой задачи на примере Протокола разрешения адресов (ARP, Address Resolution Protocol). Этот протокол транслирует IP-адреса в адреса Ethernet. Эти адреса состоят из 6 байт и гарантируют уникальность, то есть в мире нет двух Ethernet карт с одинаковыми адресами. Для трансляции IP-адреса в Ethernet-адрес ARP внутри себя содержит таблице соответствия одних адресов другим. Эта таблица строится автоматически. Когда ARP получает запрос на трансляцию, он сначала просматривает свою таблицу. Если IP-адрес в ней уже есть, то возвращается соответствующий ему адрес Ethernet. Если адреса в таблице ещё нет, то ARP выполняет следующие действия:

1. всем компьютерам сети Ethernet рассылается широковещательный запрос (в сетях Ethernet это возможно) с IP-адресом машины, Ethernet-адрес которой нужно узнать.

2. машины получают запрос. Если одна из них в IP-адресе узнаёт свой собственный адрес, она отсылает обратно (по Ethernet-адресу спрашивающей машины) пакет со своим Ethernet-адресом.

3. ARP получает пакет с искомым Ethernet-адресом, заносит его в свою таблицу трансляции, и отвечает на исходный запрос.

Конечно, может случиться и так, что ни одна машина не опознала свой IP-адрес в широковещательном запросе. В таком случае ARP отвечает, что машина с таким адресом недоступна в этой сети.

Протокол обратного разрешения адресов (RARP, Reverse Address Resolution Protocol) используется для перевода адресов Ethernet обратно в IP-адреса. Это нужно, например, когда хост загружает операционную систему с удалённой машины. Для этого он должен сначала узнать свой IP-адрес. Поэтому при загрузке он посылает широковещательный запрос вида «Скажите IP-адрес хоста с таким адресом Ehternet». RARP-сервер(если он вообще есть в этой сети и «слушает» запросы) должен в ответ послать IP-адрес.

8.3.4Транспортный уровень

Над межсетевым уровнем находится транспортный уровень. Протоколы этого уровня пользуются для передачи данных протоколом IP и, как правило, сами используются прикладными программами. Два очень важных протокола транспортного уровня будут в центре внимания этой главы: Протокол контроля передачи и(TCP, Transmission Control Protocol) и Протокол пользовательских дейтаграмм (UDP, User Datagram Protocol). TCP обеспечивает надежную доставку данных с автоматическим контролем и исправлением ошибок. UDP обеспечивает быструю доставку дейтаграмм , но без логического соединения.

8.3.4.1Протокол UDP

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

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

Здесь длина - это длина всего пакета UDP (всего пакета всего пакета UDP – данных вместе с заголовком. Контрольная сумма считается как поразрядное дополнение от псевдо-заголовка и пакета (вместе с данными). Кстати, нужно сказать, что такое псевдо-заголовок. Он состоит из адреса отправителя, адреса получателя номера протокола (для UDP это 17) и длины сообщения UDP (не выровненного по двум октетам). Его структура:

8.3.4.2Протокол TCP

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

TCP обеспечивает надежность с помощью механизма с хитроумным названием – Положительное подтверждение с повторной передачей (PAR, Positive Acknowledgment with Retransmission). Проще говоря, система, пользующаяся PAR, передает данные снова и снова до тех пор пока от удаленной машины не придет подтверждение о их корректной доставке. Единица данных, которой обмениваются системы с протоколом TCP называется сегментом. Каждый сегмент содержит контрольную сумму, по которой Получатель может проверить корректность доставки данных. Если данные дошли нормально, то он посылает отправителю положительное подтверждение. Если нет – данные просто игнорируются, а отправитель через некоторое время повторно посылает тот сегмент данных, о получении которого не было подтверждения.

TCP поддерживает связь с логическим соединением. Хосты обмениваются контрольной информацией, называемой оповещением (handshaking), чтобы установить контакт до передачи информации. TCP помечает сегмент как контрольный установкой соответствующего бита флагов в четвертом слове заголовка.

Способ установления соединения, используемый в TCP, называется тройным оповещением (three-way handshake), потому что для этого производится обмен тремя сегментами. На рисунке показан простейший пример применения такого способа. Хост A инициирует соединение передачей хосту B сегмента с установленным битом “ Синхронизация Номеров последовательностей” (SYN, “Synchronize sequence numbers”). Этот сегмент говорит хосту B о том, что A хочет установить соединение и будет использовать какой-то номер последовательности (Sequence Number) SN1 как стартовый для своих сегментов. (номера последовательностей используются для установления порядка в передаваемых данных). Хост B отвечает хосту A сегментом с установленными битами “ Подтверждение” (ACK, Acknowledgment) и SYN. Этим сегментом B подтверждает получение сегмента от А и информирует, с какого номера последовательности SN2 будет начинать свою передачу. Наконец, хост A передает сегмент, которым подтверждает получение сегмента от B, и в котором содержатся первые реальные данные.

Характеристики

Список файлов лекций