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

Важной особенностью протокола IP, отличающей его от других сетевых протоколов, например от сетевого протокола IPX, является его способность выполнять динамическую фрагментацию пакетов при передаче их между сетями с различными максимально допустимыми значениями длины поля данных кадров (MTU).
Вопросы и задания
1. Сравните таблицу моста или коммутатора с таблицей маршрутизатора. Каким образом формируются эти таблицы? Какую информацию содержат? От чего зависит их объем?

2. Верно ли утверждение, что широковещательная рассылка является частным случаем групповой рассылки? Произвольной рассылки?
3. Может ли один сетевой интерфейс иметь одновременно несколько 1Ру6-адресов разных типов: уникальный адрес, адрес произвольной рассылки, групповой адрес?
4. Рассмотрим маршрутизатор на магистрали Интернета. Какие записи содержатся в поле адреса назначения его таблицы маршрутизации? Варианты ответов:
а) номера всех сетей Интернета;

б) номера некоторых сетей Интернета;
в) номера некоторых сетей и адреса некоторых конечных узлов Интернета;
г) номера сетей, подсоединенных к интерфейсам данного маршрутизатора.
5. Сколько записей о маршрутах по умолчанию может включать таблица маршрутизации?
6. Приведите примеры, когда может возникнуть необходимость в использовании специфических маршрутов?
7. Передается ли в IP-пакете маска в тех случаях, когда маршрутизация реализуется с использованием масок?

8. Какие преимущества дает технология CIDR? Что мешает ее широкому внедрению?
9. Пусть префикс непрерывного пула IP-адресов составляет 15 двоичных разрядов. Сколько адресов, входит в этот пул? Варианты ответов:
а) 215; 6)217;
в
) 215 - 2; г) 15
2
.
10. Почему в записи о маршруте по умолчанию в качестве адреса сети назначения часто указывается 0.0.0.0 с маской 0.0.0.0?
11. Какие элементы сети могут выполнять фрагментацию? Варианты ответов:
а) только компьютеры;

б) только маршрутизаторы;
в) компьютеры, маршрутизаторы, мосты, коммутаторы;
г) компьютеры и маршрутизаторы.
12. Что произойдет, если при передаче пакета он был фрагментирован и один из фрагментов не дошел до узла назначения после истечения тайм-аута? Варианты ответов:
а) модуль IP получателя сообщит о неполучении одного фрагмента, а IP-модуль узла-отправителя повторит передачу недошедшего фрагмента;

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

13. Верно ли утверждение, что широковещательная рассылка является частным случаем групповой рассылки? Произвольной рассылки?

14. В разделе «Перекрытие адресных пространств» этой главы приведен пример того, как администратор планирует сеть своего предприятия. Решите ту же задачу по планированию сети, но для случая, когда для сети Ethernet требуется 300 адресов, для сети Token Ring — 30, для DMZ — 20 и для соединительной сети — 8. Какой пул адресов необходимо получить у поставщика услуг на этот раз? (Для определенности будем считать, что поставщик услуг выделит непрерывный пул адресов.) Как администратор распределит адреса между своими четырьмя сетями? Как будут выглядеть таблицы маршрутизации R1 и R2?

ГЛАВА 17 Базовые протоколы TCP/IP

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

Далее в этой главе рассматриваются протоколы маршрутизации, предназначенные для автоматического построения таблиц маршрутизации, на основе которых происходит продвижение пакетов сетевого уровня. Протоколы маршрутизации, в отличие от сетевых протоколов, таких как IP и IPX, не являются обязательными, так как таблица маршрутизации может строиться администратором сети вручную. Однако в крупных сетях со сложной топологией и большим количеством альтернативных маршрутов протоколы маршрутизации выполняют очень важную и полезную работу, автоматизируя построение таблиц маршрутизации, а также отыскивая новые маршруты при изменениях сети: от-(азах или появлении новых линий связи и маршрутизаторов.

Мы рассмотрим также протокол ICMP, являющийся средством оповещения отправителя о причинах недоставки его пакетов адресату. Помимо диагностики ICMP используется для мониторинга сети. Так, в основе популярных утилит мониторинга IP-сетей ping и traceroute лежат ICMP-сообщения.
Протоколы транспортного уровня TCP и UDP
К транспортному уровню стека TCP/IP относятся:
□ протокол управления передачей (Transmission Control Protocol, TCP), описанный в стандарте RFC 793;

□ протокол пользовательских дейтаграмм (User Datagram Protocol, UDP), описанный в стандарте RFC 768.
Протоколы TCP и UDP, как и протоколы прикладного уровня, устанавливаются на конечных узлах.
Порты и сокеты

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

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

Рис. 17.1. Мультиплексирование и демультиплексирование на транспортном уровне
Существует и обратная задача: данные, генерируемые разными приложениями, работающими на одном конечном узле, должны быть переданы общему для всех них протокольному модулю IP для последующей отправки в сеть. Эту работу, называемую мультиплексированием, тоже выполняют протоколы TCP и UDP.

Протоколы TCP и UDP ведут для каждого приложения две системные очереди: очередь данных, поступающих к приложению из сети, и очередь данных, отправляемых этим приложением в сеть. Такие системные очереди называются портами
1
, причем входная и выходная очереди одного приложения рассматриваются как один порт. Для идентификации портов им присваивают номера.
Если процессы представляют собой популярные системные службы, такие как FTP, telnet, Нттр d^S
и т п
^
то за ними

закрепляются стандартные назначенные номера,
называемые также хорошо известными (well-known) номерами портов. Эти номера закрепляются и публикуются в стандартах Интернета (RFC 1700, RFC 3232). Так, номер 21 закреплен за серверной частью службы удаленного доступа к файлам FTP, а 23 — за серверной частью службы удаленного управления telnet. Назначенные номера из диапазона от 0 до 1023 являются уникальными в пределах Интернета и закрепляются за приложениями централизованно.

Для тех приложений, которые еще не стали столь распространенными, номера портов назначаются локально разработчиками этих приложений или операционной системой в ответ на поступление запроса от приложения. На каждом компьютере операционная система ведет список занятых и свободных номеров портов. При поступлении запроса от приложения, выполняемого на данном компьютере, операционная система выделяет ему первый свободный номер. Такие номера называют динамическими. В дальнейшем все сетевые приложения должны адресоваться к данному приложению с указанием назначенного ему динамического номера порта. После того как приложение завершит работу, его номер возвращается в список свободных и может быть назначен другому приложению. Динамические номера являются уникальными в пределах каждого компьютера, но при этом обычной является ситуация совпадения номеров портов приложений, выполняемых на разных компьютерах. Как правило, клиентские части известных приложений (DNS, WWW, FTP, telnet и др.) получают динамические номера портов от ОС.

Все, что было сказано о портах, в равной степени относится к обоим протоколам транспортного уровня (TCP и UDP). В принципе, нет никакой зависимости между назначением номеров портов для приложений, использующих протокол TCP, и приложений, работающих с протоколом UDP. Приложения, которые передают данные на уровень IP по протоколу UDP, получают номера, называемые UDP-портами. Аналогично, приложениям, обращающимся к протоколу TCP, выделяются ТСР-порты.

В том и другом случаях это могут быть как назначенные, так и динамические номера. Диапазоны чисел, из которых выделяются номера TCP- и UDP-портов, совпадают: от 0 до 1023 для назначенных и от 1024 до 65 535 для динамических. Однако никакой связи между назначенными номерами TCP- и UDP-портов нет. Даже если номера TCP- и UDP-портов совпадают, они идентифицируют разные приложения. Например, одному приложению может быть назначен ТСР-порт 1750, а другому — UDP-порт 1750. В некоторых случаях, когда приложение может обращаться по выбору к протоколу TCP или UDP (например,

{
Порт приложения не надо путать с портами (сетевыми интерфейсами) оборудования.
таким приложением является DNS), ему, исходя из удобства запоминания, назначаются совпадающие номера TCP- и UDP-портов (в данном примере — это хорошо известный номер 53).

Стандартные назначенные номера портов уникально идентифицируют тип приложения (FTP, или HTTP, или DNS и т. д.), однако они не могут использоваться для однозначной идентификации прикладных процессов, связанных с каждым из этих типов приложений. Пусть, например, на одном хосте запущены две копии DNS-сервера — DNS-сервер 1, DNS-сервер 2 (рис. 17.2). Каждый из этих DNS-серверов имеет хорошо известный UDP-порт 53. Какому из этих серверов нужно было бы направить запрос клиента, если бы в DNS-запросе в качестве идентификатора сервера был указан только номером порта?

[
Сокет DNS-сервера 1 Ц DNS-сервер 1 (IP1, UDP-порт 53).
DNS-сервер 21 Сокет DNS-сервера 2 -(IP2, UDP-порт 53)
DNS-клиент 2
]''
i:
' /v'>' , *' , ' 'цii \ ' '■i
IP1, IP2
1Р-дейтаграмма
0йS1
Порт назначения 53
IP-адрес назначения IP2
UDP-дейтаграмма---КадрРис. 17.2. Демультиплексирование протокола UDP на основе сокетов

Чтобы снять неоднозначность в идентификации приложений, разные копии связываются с разными IP-адресами. Для этого сетевой интерфейс компьютера, на котором выполняется несколько копий приложения, должен иметь соответствующее число IP-адресов -на рисунке это IP1 и IP2. Во всех IP-пакетах, направляемых DNS-серверу 1, в качестве IP-адреса указывается IP1, а DNS-серверу 2 — адрес IP2. Поэтому показанный на рисунке пакет, в поле данных которого содержится UDP-дейтаграмма с указанным номером порта 53, а в поле заголовка задан адрес IP2, буден направлен однозначно определенному адресату — DNS-серверу 2.

Прикладной процесс однозначно определяется в пределах сети и в пределах отдельного компьютера парой (!Р-адрес, номер порта), называемой сокетом (socket). Сокет, определенный IP-адресом и номером UDP-порта, называется UDP-сокетом, а IP-адресом и номером ТСР-порта—ТСР-сокетом.
ПРИМЕЧАНИЕ-

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

Протокол UDP и UDP-дейтаграммы
ПротбкШ УСЩ дейтаграммным протоколом, реализующим так называемый
который не гарантирует доставку сообщений адресату.

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

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

Далее приведен пример заголовка UDP с заполненными полями:
Source Port - 0x0035 Destination Port - 0x0411 Total length - 132 (0x84) bytes Checksum - 0x5333
В этой UDP-дейтаграмме в поле данных, длина которого, как следует из заголовка, равна (132 - 8) байт, помещено сообщение DNS-сервера, что можно видеть по номеру порта источника (Source Port = 0—0035). В шестнадцатеричном формате это значение равно стандартному номеру порта DNS-сервера — 53.

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

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

Протокол TCP и ТСР-сегменты
Протсифл основан
При работе на хосте-отправителе протокол TCP рассматривает информацию, поступающую к нему от прикладных процессов, как неструктурированный поток байтов (рис. 17.4). Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера «вырезается» некоторая непрерывная часть данных, которая называется сегментом* и снабжается заголовком.
60
Рис. 17.4. Формирование TCP-сегментов из потока байтов
ПРИМЕЧАНИЕ-

В отличие от протокола UDP, который создает свои дейтаграммы на основе логически обособленных единиц данных — сообщений, генерируемых приложениями, протокол TCP делит поток данных на сегменты без учета их смысла или внутренней структуры.
2 байта
2 байта
Порт источника (sours port)
Порт приемника (destination port)
Последовательный номер (sequence number) -номер первого байта данных в сегменте, определяет смещение сегмента относительно потока отправляемых данных

Подтвержденный номер (acknowledgement number) -максимальный номер байта в полученном сегменте,
* увеличенный на единицу
Длина
заголовка
(hlen)
Резерв
(reserved)
Контрольная сумма
(checksum)
Окно (window) - количество байтов данных, ожидаемых отправителем данного сегмента, начиная с байта, номер которого указан в поле подтвержденного номера
Указатель срочности (urgent pointer) -указывает на конец данных, которые необходимо срочно принять, несмотря на переполнение буфера
Параметры (options) -

это поле имеет переменную длину и может вообще отсутствовать, используется для решения вспомогательных задач, например, для согласования максимального размера сегмента
Заполнитель (paddind) *
это фиктивное поле может иметь переменную длину,
^ , используется для доведения
размера заголовков до целого числа 32-битовых слов
Рис. 17.5. Формат заголовка ТСР-сегмента
Логические соединения — основа надежности TCP

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

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

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

На рис. 17.6 показаны сети, соединенные маршрутизаторами, на которых установлен протокол IP. Установленные на конечных узлах протокольные модули TCP решают задачу обеспечения надежного обмена данными путем установления между собой логических соединений.
Рис. 17.6. TCP-соединение создает надежный логический канал между конечными узлами

При установлении логического соединения модули TCP договариваются между собой о параметрах процедуры обмена данными. В протоколе TCP каждая сторона соединения посылает противоположной стороне следующие параметры:
□ максимальный размер сегмента, который она готова принимать;
□ максимальный объем данных (возможно несколько сегментов), которые она разрешает другой стороне передавать в свою сторону, даже если та еще не получила квитанцию на предыдущую порцию данных (размер окна);

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

Соединение устанавливается по инициативе клиентской части приложения. При необходимости выполнить обмеЦ данными с серверной частью приложение-клиент обращается к нижележащему протоколу TCP, который в ответ на это обращение посылает сегмент-запрос на установление соединения протоколу TCP, работающему на стороне сервера (рис. 17.7, а). В числе прочего в запросе содержится флаг SYN, установленный в 1.

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

* Соединение * закрыто
а
Запрос
соединения
Состояние
ESTABLISHED
Подготовка Закрыть соединения соединен прошла успешно
Состояние
ESTABLISHED
▼
t
t
Тайм-аут
Закрытьсоединение
сервера
клиента
TCP на стороне TCP на стороне
TCP на стороне TCP на стороне клиента сервера
б
Рис. 17.7. Процедура установления и разрыва логического соединения при нормальном течении процесса

В ответ клиент посылает сегмент с флагом АСК и переходит в состояние установленного логического соединения (состояние ESTABLISHED). Когда сервер получает флаг АСК, он также переходит в состояние ESTABLISHED. На этом процедура установления соединения заканчивается, и стороны могут переходить к обмену данными.

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