Вы находитесь на странице: 1из 279

С-Пб ГУТ им. проф. М. А.

Бонч-Бруевича
Кафедра Сетей связи и передачи данных

TCP/IP
Алгоритмы и протоколы стека

Небаев Игорь Алексеевич


к.т.н., доц.
<inebaev[at]spbgut.ru>

tcpdumpnetstat WWW ifconfigICMPv6 ping


SSH DHCP IPX
SCTP UUCPLoopbackRARP BSD Sockets
POSIX
SFTP 10.0.0.0/8 Z-Modem
RFC-791TFTPTCP/IP eth0
TCP/IP wlan0 UDP X-Modem
PPP DNS 172.16.0.0/12
Ethernet HTTP DNS MIME224.0.0.1
802.2/802.3
127.0.0.0/8 CNAME IMAP
IP IPv6 E-Mail AAAA ARP SMTP

Конспект лекций
2015 г.
Библиография и ссылки

1. Стивенс У. Р. Протоколы TCP/IP. Практическое руководство / Пер. с


англ. и коммент. А. Ю. Глебовского. — С-Пб. : «Невский диалект» —
«БХВ-Петербург», 2003. — 672 с. — ISBN: 5-7940-0093-7.
2. Крейг Х. TCP/IP. Сетевое администрирование. Пер. с англ. — 3-e изд. —
С-Пб. : Символ-Плюс, 2006. — 816 с. — ISBN: 5-93286-056-1.
3. Кульгин М. В. Компьютерные сети. Практика построения. Для
профессионалов. — 2-e изд. — С-Пб. : Питер, 2003. — 462 с. —
ISBN: 5-94723-563-3.
4. МакКузик М. К., Невил-Нил Д. В. FreeBSD: архитектура и реализация
/ Пер. с англ. — М. : КУДИЦ-ОБРАЗ, 2006. — 800 с. —
ISBN: 5-9579-0103-2.
TCP/IP : Библиография 2/279
Электронные ресурсы

Видеокурс — opds.sut.ru → Учебная работа → Видеокурсы


http://opds.sut.ru/?page_id=1280;
Пособие — opds.sut.ru → Электронные курсы → Основы построения
Internet
opds.sut.ru/old/electronic_manuals/it_emd/index.htm;
Электронная книга — opds.sut.ru → Электронные курсы → Основы
построения Internet → Литература → R. Stevens . . .
http://opds.sut.ru/old/electronic_manuals/RStevens_
TCP_IP/index.html;
Конспект лекций — opds.sut.ru → Методическая работа → Учебные
пособия → ИТиМ (лекции)
http://opds.sut.ru/wp-content/uploads/mu/nebaev_itm/
itm.pdf;

TCP/IP : Библиография 3/279


Введение: обзор развития

Конец 1960-х г.
Запуск исследовательского проекта DARPA по разработке сети пакетной
коммутации.

Конец 1980-х — начало 1990-х гг.


Эволюция формы и методов сетевого взаимодействия между компьютерами.

Начало 2000-х г.
Реализовано большое количество открытых, свободных и проприетарных
версий стека TCP/IP — основы того, что в настоящее время называется
словом «Internet».

Исторический очерк 1993 г.


Lynch, D. C., «Historical Perspective», in Internet System Handbook, eds. D. C. Lynch
and M. T. Rose, pp. 3-14. Addison-Wesley, Reading, Mass.

TCP/IP : Введение 4/279


TCP/IP API
Существует несколько популярных интерфейсов прикладного
программирования (API — application programming interface) для
приложений, использующих протоколы TCP/IP:
«Berkeley sockets» — концепция прграммных сокетов разработанная в
университете Беркли и реализованная в 4.2BSD (1983). Помимо API
для TCP/IP сокетов, реализует интерфейс к сокетам «Unix domain
sockets», используемых для взаимодействия между процессами (IPC) в
ОС. Иногда называется «classic BSD API».
«POSIX sockets» — Portable Operating System Interface, описание
стандартного API для совместимости различных ОС. Первый выпуск в
1988г. — IEEE 1003 (международный стандарт ISO/IEC 9945).
Представляет из себя модифицированный API Berkley Sockets.
«TLI - Transport Layer Interface» — интерфейс транспортного уровня.
API разработанный в AT&T, иногда называется XTI (X/Open Transport
Interface), для некоторых коммерческих версий ОС. Разработан
международной группой поставщиков компьютеров. XTI является
расширением TLI, опиционально поддерживает сокеты BSD.

TCP/IP : Введение 5/279


Реализации стека на примере релизов BSD

1 4.2BSD 1983 — Первый широкораспространенный релиз стека TCP/IP.


2 4.3BSD 1986 — Увеличение производительности и чистка кода стека
TCP/IP.
3 4.3BSD «Tahoe» 1988 — Реализованы алгоритмы медленного старта,
защиты от переполнения памяти и т. д..
4 4.3BSD «Reno» 1990 — реализация CSLIP, основные изменения в
реализации таблиц маршрутизации.
5 4.3BSD «Tahoe» 1988 — Реализованы алгоритмы медленного старта,
защиты от переполнения памяти и т. д..
6 4.4BSD 1993 — Реализованы алгоритмы групповой рассылки, улучшена
работа модулей транспортного уровня и т. д.

BSDi, AIX, SunOS, SVR4 и т. д.


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

TCP/IP : Введение 6/279


Процесс стандартизации
Основную разработку и контроль над стандартизацией internet сетей
осуществляют несколько групп:
Internet Society (ISOC) — сообщество профессионалов, которое
отвечает за настройку и поддержку развития Internet как мировой
исследовательской коммуникационной инфраструктуры.
Internet Engineering Task Force (IETF) — группа, занимающаяся
разработкой стандартов Internet. Поделена на 9 подгрупп (приложения,
маршрутизация, адресация, безопасность. . . ).
Internet Research Task Force (IRTF) — группа перспективных и
долгосрочных проектов.

Способ представления документов


Все официальные стандарты сообщества Internet публикуются в формате
документов Request for Comment, или в RFC.

Cуществует множество RFC, которые не являются официальными


стандартами. Они публикуются в информационных целях. Размеров RFC
колеблется от 1 до почти 200 страниц. Каждый из них имеет собственный
номер.
TCP/IP : Введение 7/279
Request for Comment
Для отслеживания публикаций существует индекс RFC, который помимо
сути документа содержит метаданные об изменениях и обновлениях RFC.
Существует несколько важных типов RFC:
Assigned Numbers RFC — содержит в себе все числа и константы,
которые используются в протоколах Internet.
Internet Official Protocol Standards — официальные стандарты
протоколов Internet.
Каждый документ может находиться в некотором «состоянии публикации».

Публикация RFC
Стандарт, необязательный стандарт, рекомендованный стандарт,
экспериментальный, информационный, или исторический.

Документы имеют «уровень востребованности».

Востребованность RFC
Необходим, рекомендуется, на выбор, с ограниченным использованием, или
не рекомендуется.
TCP/IP : Введение 8/279
Requirements RFC

Требования к узлам и маршрутизаторам


Существует отдельный тип RFC описывающий условия реализации и
алгоритм функционирования узлов сети.

Host Requirements RFC — требования к реализации хостов (узлов).


Список характеристик и конкретных подробностей протоколов,
содержит требования и условия программной реализации: «должен»,
«следует», «может», «не следует» или «не должен».
Router Requirements RFC — данный RFC напоминает RFC
«требования к узлам», однако содержит уникальные требования к
реализации маршрутизаторов Internet.

Полезные ссылки RFC


http://www.rfc-editor.org/rfc.html
http://www.ietf.org/rfc.html
http://rfc2.ru/

TCP/IP : Введение 9/279


Уровни стека

В отличии от стека ISO/OSI, непосредственно в стеке TCP/IP реализованы


только некоторые функции стандартной модели взаимодействия.
Прикладной (TELNET, FTP, IMAP...)
Транспортный (TCP, UDP, SCTP...)
Сетевой (IP, ICMP, IGMP...)
Канальный (Драйвер устройства и интерфейсная плата)

Канальный уровень (link layer)


Уровень сетевого интефейса. Включает в себя драйвер устройства в ОС и
соответствующую сетевую интерфейсную плату в ПК.

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


физического соединения с сетью (с кабелем или с другой используемой
средой передачи). Реализация существенно зависит от ОС.

TCP/IP : Общая модель стека 10/279


Сетевой уровень (network layer)
Уровень межсетевого взаимодействия.
Реализует логику передачи дейтаграмм по сети (т. е. маршрутизацию) и
связывает сетевые интерфейсы удаленных узлов.

Помимо этого определяет способ адресации и выполняет задачи


фрагментации данных. Некоторые протоколы данного уровня в стеке
TCP/IP:
Internet Protocol - протокол Internet, RFC-791
Internet Control Message Protocol - протокол управления сообщениями
Internet, RFC-792
Internet Group Management Protocol - протокол управления группами
Internet, RFC-3376

TCP/IP : Общая модель стека 11/279


Транспортный уровень (transport layer)
Определяет порядок передачи потока данных между программными
интерфейсами и обеспечивает работу прикладного уровня. Позволяет
связать прикладные процессы на удаленных узлах.

TCP (Transmission Control Protocol) — реализует «надежную»


передачу данных между хостами. Обеспечивает деление данных
(сегментация), передающихся от одного приложения к другому, на
пакеты подходящего для сетевого уровня размера, подтверждение,
установку тайм-аутов, в течение которых должно придти подтверждение
на пакет, и т. д. Так как надежность передачи данных гарантируется на
транспортном уровне, на прикладном уровне эти детали игнорируются.
RFC-793
UDP (User Datagram Protocol) — реализует примитивную службу
передачи для прикладного уровня. Он просто отсылает пакеты, которые
называются дейтаграммами (datagram) от одного хоста к другому. Нет
никакой гарантии, что дейтаграмма будет доставлена до адресуемого
хоста. За надежность передачи данных, при использовании дейтаграмм
отвечает прикладной уровень. RFC-768
Для каждого транспортного протокола существуют различные приложения,
которые их используют.
TCP/IP : Общая модель стека 12/279
Прикладной уровень (application layer)
Определяет детали каждого конкретного приложения. Существует несколько
распространенных приложений TCP/IP, которые присутствуют практически
в каждой реализации.

Пример некоторых протоколов прикладного уровня:


TELNET (Teletype Network) — протокол доступа к удаленному
терминалу RFC-854
FTP (File Transfer Protocol) — протокол передачи файлов RFC-959
SMTP (Simple Mail Transfer Protocol) — простой протокол передачи
электронной почты RFC-5321
SNMP (Simple Network Management Protocol) — простой протокол
управления сетью RFC-1155

TCP/IP : Общая модель стека 13/279


Протокол FTP Прикадные
FTP клиент FTP сервер
процессы пользователей

TCP модуль Протокол TСP TCP модуль


ядра ОС ядра ОС

Интерфейсы
IP модуль Протокол IP IP модуль ядра ОС
ядра ОС ядра ОС

Протокол
Ethernet
Модуль драйвера Модуль драйвера
сетевой платы сетевой платы

Аппаратное обеспечение
Среда передачи сигналов

Рис. 1 — Пример взаимодействия узлов TCP/IP

TCP/IP : Общая модель стека 14/279


Пользовательский Пользовательский Пользовательский
процесс A процесс B процесс C

Модуль Модуль
протокола TCP протокола UDP

Модуль Модуль Модуль


протокола ICMP протокола IP протокола IGMP

Модуль Модуль драйвера Модуль


протокола ARP сетевой платы протокола RARP

Среда передачи сигналов

Рис. 2 — Взаимодействие прикладных процессов

TCP/IP : Общая модель стека 15/279


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

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


Цели, решаемые сетевым и прикладным уровнями, различны - первый
обеспечивает взаимодействие с различными средами передачи (Ethernet,
Token ring, и т. д.), второй работает с конкретными пользовательскими
приложениями (FTP, Telnet, и т. д.).

TCP/IP : Общая модель стека 16/279


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

Пример разделяемых ресурсов


Службы общих каталогов
Удаленный доступ к разделяемым устройствам (принтеры, плоттеры,
факс-машины . . . )
Базы данных

Причина развития сетевых технологий в течение 80-х годов — понимание


того, что ПК обладает гораздо меньшими вычислительными ресурсами, в
сравнении с мощной центральной машиной — мейнфреймом.
Количество выполняемых команд за такт?
Количество тактов в секунду?
Объем адресуемой памяти?
Объем накопителей для хранения данных?
Количество одновременно выполняемых процессов (пользователей)?
TCP/IP : Процессы интеграции узлов 17/279
Тенденция 1980-х г.
Массовое объединение рабочих станций (ПК) во внутренние локальные
сети (intranetworking).

Рост интранет сетей ограничен географическими признаками. Интранет


(локальная) сеть объединяющая факультеты ЛИТМО не имеет связи с
сетью факультетов ЛЭИС.

Тенденция 1990-х г.
Техническое и логическое объединение интранет сетей по географическим,
национальным и экономическим критериям.

Internet сети
Результат такого объединения получил название internetworking
(межсетевое взаимодействие). Internet сети — это совокупность
объединенных локальных (intranet) сетей, которые используют одно и то же
семейство протоколов, например TCP/IP (Internet Protocol Suite).

TCP/IP : Процессы интеграции узлов 18/279


Сеть Internet и internet сети

Internet
Сеть Internet относится к всемирной (глобальной) сети, основу архитектуры
которой составляет семейство протоколов TCP/IP. Сеть Internet — частный
случай internet сетей. В мире известна только одна сеть Internet.

Сети Internet
Интернет сети подразумевают любую совокупность взаимосвязанных сетей,
объединенных на основе некоторого общего для них семейства протоколов.

Примером интернет сетей могут быть:


Национальная сеть определенного государства
Ведомственные сети специального назначения («Военная паутина»,
milnet и т. д.)
Всемирные банковские сети
Рунет (https://ru.wikipedia.org/wiki/Runet)

TCP/IP : Процессы интеграции узлов 19/279


Объединение сетей
Прозрачность реализации процесса передачи
Концепция, при которой детали физического объединения сетей скрыты от
приложений, определяет мощность и гибкость технологии объединения
сетей.
Для осуществления межсетевого взаимодействия (internetworking)
необходимо объединить две или более сетей с помощью маршрутизатора
(router) — аппаратно-программного устройства. Маршрутизаторы internet
сетей поддерживающие протокол IP называются IP маршрутизаторами (IP
router).

Маршрутизатор или шлюз?


Маршрутизатор принято называть шлюзом (gateway), если он объединяет
несколько сетей, построенных на различных физических или программных
принципах.

Шлюзы: Fast Ethernet – WiFi, шлюз Gigabit Ethernet –


Point-to-Point, и т. д. Пример программных шлюзов: TCP/IP – IBM
SNA, шлюз TCP/IP – IPX/SPX и т. д.
TCP/IP : Процессы интеграции узлов 20/279
Протокол FTP
FTP клиент FTP сервер

TCP модуль Протокол TСP TCP модуль


ядра ОС ядра ОС
Протокол IP Протокол IP

IP модуль IP модуль IP модуль


ядра ОС ядра ОС ядра ОС
Протокол Протокол
Ethernet Token Ring

Драйвер Драйвер Драйвер Драйвер


Ethernet Ethernet Token Ring Token Ring

Среда передачи сигналов Ethernet Среда передачи сигналов Token Ring

Рис. 3 — Взаимодействие узлов через маршрутизатор

TCP/IP : Процессы интеграции узлов 21/279


Элементы сети

Оконечная система (end system)


FTP клиент и сервер
Прикладной и транспортный уровни используют протоколы,
ориентированные на соединение (end-to-end). На рисунке эти два уровня
используются только конечными системами.

Промежуточная система (intermediate system)


Маршрутизатор
Сетевой уровень использует протокол, не требующий соединения
(пересылка-за-пересылкой, hop-by-hop), он используется в данном случае
двумя конечными системами и каждой промежуточной системой.

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


сетевого уровня (если он объединяет две или более сетей). Любая система с
несколькими интерфейсами называется многоинтерфейсной (multihomed).

TCP/IP : Процессы интеграции узлов 22/279


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

Программный маршрутизатор (Soft router)


Большинство реализаций TCP/IP позволяют компьютерам с несколькими
интерфейсами функционировать в качестве маршрутизаторов. Однако
компьютеры должны быть специально сконфигурированы, чтобы решать
задачи маршрутизации.

Можно называть систему хостом (узлом), когда на нем работают такие


приложения как FTP или Telnet, или маршрутизатором, когда он
осуществляет передачу пакетов из одной сети в другую.

Шлюзы и мосты . . .
Существует еще один метод объединения сетей - с помощью мостов
(bridge). В этом случае сети объединяются на канальном уровне, тогда как
маршрутизаторы объединяют сети на сетевом уровне.

TCP/IP : Процессы интеграции узлов 23/279


Процедура инкапсуляции
Когда приложение посылает данные с использованием стека TCP/IP, данные
опускаются вниз по стеку протоколов, проходя через каждый уровень, до
тех пор пока они не будут отправлены в виде потока битов по сети.
Каждый уровень добавляет свою информацию к данным путем пристыковки
заголовков.
Байт или октет?
Все стандарты INTERNET и большинство книг про TCP/IP используют
термин октет (octet) вместо слова байт. Однако, не на всех компьютерных
архитектурах байт состоит из 8 бит.

Процедура упаковки данных приложения в блоки данных нижележащих


уровней стека TCP/IP называется инкапсуляцией. Обратная процедура
носит название демультиплесирование. Для инкапсуляции и
демультиплексирования используют некоторые поля заголовков протоколов:
Номер порта приложения отправителя и получателя транспортного
уровня в заголовке TCP/UDP (по 16 бит каждое)
Номер протокола транспортного уровня в заголовке IP (8 бит)
Тип кадра в заголовке Ethernet (16 бит)
TCP/IP : Инкапсуляция 24/279
Данные
пользователя

Заголовок Данные Приложение


приложения пользователя

Сегмент TCP

Заголовок Данные Модуль TCP


TCP приложения

Дейтаграмма IP

Заголовок Заголовок Данные Модуль IP


IP TCP приложения

Кадр Ethernet

Заголовок Заголовок Заголовок Данные Контрольная Драйвер


Ethernet IP TCP приложения сумма Ethernet

14 байт 20 байт 20 байт 4 байта

46-1500 байт

Рис. 4 — Пример инкапсуляции Ethernet

TCP/IP : Инкапсуляция 25/279


Кадр Ethernet

Заголовок Заголовок Заголовок Данные Контрольная Драйвер


Ethernet IP TCP приложения сумма Ethernet
14 байт 20 байт 20 байт 4 байта

46-1500 байт

Тип: 0x0800
Дейтаграмма IP

Заголовок Заголовок Данные Модуль IP


IP TCP приложения

Сегмент TCP
Протокол: 0x0006
Заголовок Данные Модуль TCP
TCP приложения

Порт назначения: 0x1f9a Заголовок Данные


приложения пользователя
Приложение

Данные
пользователя

Рис. 5 — Пример демультиплексирования Ethernet

TCP/IP : Инкапсуляция 26/279


Модель клиент-сервер

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


стороны присутствует клиент (client), а с другой - сервер (server). При этом
сервер предоставляет определенные сервисы и службы клиентским
приложениям.

Классы приложений типа сервер


Можно подразделить серверы на два класса:
Последовательные (iterative)
Конкурентные (concurrent)

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


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

TCP/IP : Модель взаимодействия «Клиент-Сервер» 27/279


Ожидание запроса
от клиента

Чтение очереди
входящих
сообщений

Нет
Есть
сообщения?

Да

Обработка
запроса от
клиента

Отправка ответа
клиенту

Рис. 6 — Алгоритм работы последовательного приложения сервера

TCP/IP : Модель взаимодействия «Клиент-Сервер» 28/279


Запуск нового сервера для обработки запроса клиента может выглядеть как
создание нового процесса (в зависимости от ОС). Новый сервер обрабатывает
поступивший запрос клиента целиком. По завершении сервер уничтожается.

Преимущество конкурентного приложения сервера


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

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

Типичное решение
В общем случае, серверы TCP — конкурентные, а серверы UDP —
последовательные.

TCP/IP : Модель взаимодействия «Клиент-Сервер» 29/279


Ожидание запроса
от клиента

Чтение очереди
входящих
сообщений

Нет
Есть
сообщения?

Да

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

Рис. 7 — Алгоритм работы конкурентного приложения сервера

TCP/IP : Модель взаимодействия «Клиент-Сервер» 30/279


Канальный уровень
В рамках стека TCP/IP на канальном уровне выполняется процедура
инкапсуляции — оформления дейтаграммы для передачи ее по
специфичному протоколу канального и физического уровней.

Назначение
Основная задача канального уровня в семействе протоколов TCP/IP:
1 Посылать и принимать IP дейтаграммы для IP модуля ОС;
2 Обрабатывать xARP кадры для IP модуля ОС;

Стек TCP/IP поддерживает различные канальные уровни, в зависимости от


того какой тип сетевого аппаратного обеспечения используется: Ethernet,
Token ring, FDDI (Fiber Distributed Data Interface), последовательные линии
RS-232, и т. д. Рассмотрим некоторые основные реализации канального
уровня в стеке на примере:
Ethernet и IEEE 802;
Последовательных интерфейсов (SLIP и PPP);
Программном интерфейсе loopback.

TCP/IP : Канальный уровень в стеке TCP/IP 31/279


Инкапсуляция IEEE 802 и Ethernet

Термин Ethernet обычно означает стандарт, опубликованный в 1982 году


компаниями Digital Equipment Corp., Intel Corp., и Xerox Corp (DIX).

В настоящее время. . .
Основной тип инкапсуляции и технология применяемая в локальных сетях
использующих TCP/IP.

Метод доступа CSMA/CD — множественный доступ (Multiple Access) с


определением коллизий (Collision Detection) и наличием несущей
(Carrier Sense);
Различные скорости передачи данных — 10–1000 Мбит/сек;
Собственная адресация на основе 48-битных адресов.

TCP/IP : Канальный уровень в стеке TCP/IP 32/279


Стандарт IEEE 802.3
Институт инженеров по электротехнике и радиоэлектронике (Institute of
Electrical and Electronics Engineers) опубликовал отличающийся от DIX
набор стандартов.

Стандарт 802.3 описывает полный набор сетей CSMA/CD, стандарт 802.2


определяет управление логическим каналом (LLC — Logical link control),
который является общим для большинства сетей 802.

Несовместимость
Комбинация 802.2 и 802.3 определяет форматы фрейма отличные от
Ethernet.

RFC
В стеке TCP/IP инкапсуляция IP дейтаграмм определена в RFC-894
(Ethernet) и в RFC-1042 (IEEE 802).

TCP/IP : Канальный уровень в стеке TCP/IP 33/279


Требования к узлу подключенному к Ethernet («Host Requirements RFC»):
1 Узел должен иметь возможность посылать и получать пакеты,
инкапсулированные с использованием RFC-894 (Ethernet).
2 Узел должен иметь возможность получать пакеты RFC-1042 (IEEE 802),
перемешанные с пакетами RFC-894.
3 Узел должен иметь возможность посылать пакеты с использованием
инкапсуляции RFC-1042.

Предпочтение
Если узел может посылать оба типа пакетов, то тип пакета должен быть
конфигурируемым, а конфигурация по-умолчанию должна быть настроена
на пакеты RFC-894.
На практике, используется только инкапсуляция RFC-894.

TCP/IP : Канальный уровень в стеке TCP/IP 34/279


46-1500 байт

802.3 MAC 802.2 LLC 802.2 SNAP

Адрес Адрес Код Тип Данные Контрольная


Длина DSAP SSAP Упр.
приемника передатчика орг. кадра приложения сумма

6 байт 6 байт 2 байта 1 байт 1 1 3 байта 2 байта 4 байта

38-1492 байта

0x0800 IP дейтаграмма

2 байта

38-1492 байта

Запол-
0x0806 ARP кадр
нитель

2 байта

28 байт 10 байт

Запол-
0x0835 RARP кадр
нитель

2 байта

28 байт 10 байт

Рис. 8 — Инкапсуляция IP в IEEE 802.2/802.3

TCP/IP : Канальный уровень в стеке TCP/IP 35/279


Кадр Ethernet

Адрес Адрес Тип Данные Контрольная


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

6 байт 6 байт 2 байта 4 байта

46-1500 байт

0x0800 IP дейтаграмма

2 байта

46-1500 байт

Запол-
0x0806 ARP кадр
нитель

2 байта

28 байт 18 байт

Запол-
0x0835 RARP кадр
нитель

2 байта

28 байт 18 байт

Рис. 9 — Инкапсуляция IP в Ethernet


TCP/IP : Канальный уровень в стеке TCP/IP 36/279
Особенности инкапсуляции IEEE 802

Поле длины (length) кадра 802 содержит количество следующих за ним


байт;
Поле протокола управления логическим каналом (LLC — Logical link
control) 3 байта;
Поле DSAP (точка доступа к сервису назначения — Destination Service
Access Point) имеет значение 0xAA;
Поле SSAP (точка доступа к сервису источника — Source Service Access
Point) имеет значение 0xAA;
Поле «Управление» имеет значение 0x03 (1 байт).
Поле протокола доступа к подсети (SNAP — Sub-Network Access
Protocol) 5 байт;
Поле «Код организации» имеет значение 0x00 (3 байта);
Поле «Тип кадра» 2 байта.

TCP/IP : Канальный уровень в стеке TCP/IP 37/279


Общие черты инкапсуляций Ethernet и IEEE 802

В обоих форматах фрейма используется 48-битовый (6-байтовый)


формат представления адресов источника и назначения (аппаратные
адреса — hardware addresses) — 00:00:00:00:00:00;
Поле контрольной суммы (CRC) определяет ошибки, возникшие при
транспортировке фрейма (4 байта);

Минимальный размер поля данных фреймов


38 байт для 802.3
46 байт для Ethernet.

Чтобы удовлетворить этому требованию, вставляются байты заполнения.

TCP/IP : Канальный уровень в стеке TCP/IP 38/279


Инкапсуляция SLIP
Форма инкапсуляции IP дейтаграмм для последовательных линий (Serial
Line IP). Процедура инкапсуляции SLIP описана в RFC-1055.

История SLIP
История SLIP начинается в 1984 года с реализации в 4.2BSD.

Области использования
SLIP стал широко использоваться для подключения домашних систем к
Internet с того момента, когда практически на каждом компьютере появился
последовательный порт RS-232, а также появились высокоскоростные
модемы.

CSLIP
Compressed SLIP (SLIP со сжатием) — наиболее распространенная версия
протокола SLIP на начало 2000-х г. Сокращение длины кадра удается за
счет удаления повторяющихся полей в серии нескольких дейтаграмм.

TCP/IP : Канальный уровень в стеке TCP/IP 39/279


Процедура инкапсуляции SLIP
Формирование фреймов с использованием SLIP выполняется следующим
образом:
1 IP дейтаграмма завершается специальным символом — «END» (байт
0xC0).
2 Если байт, находящийся в IP дейтаграмме, эквивалентен символу
«END», вместо него передается последовательность 0xDB, 0xDC (2
байта). Специальный символ 0xDB называется «SLIP ESC» символ.
3 Если байт IP дейтаграммы равен символу «SLIP ESC», вместо него
передается последовательность 0xDB, 0xDD (2 байта).
IP дейтаграмма

0xC0 0xDB

END ESC ESC END

0xC0 0xDB 0xDC 0xDB 0xDD 0xC0

1 байт 1 байт 1 байт 1 байт 1 байт 1 байт

Рис. 10 — Инкапсуляция IP в SLIP

TCP/IP : Канальный уровень в стеке TCP/IP 40/279


Ограничения инкапсуляции SLIP

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


Метода, с помощью которого одна оконечная система может сообщить
удаленной системе свой IP адрес, не существует;
2 Не существует поля типа («Тип кадра» в Ethernet). Если
последовательная линия используется для SLIP, она не может быть
одновременно использована для какого-либо другого протокола;
3 SLIP не использует контрольную сумму. Исправление и обнаружение
ошибок в кадре возлагается или на верхние уровни или на аппаратное
обеспечение.

TCP/IP : Канальный уровень в стеке TCP/IP 41/279


Инкапсуляция PPP

Протокол инкапсуляции PPP (Point-to-Point Protocol) предназначен для


переноса дейтаграмм по двухточечному соединению. Протокол
инкапсуляции включает следующие компоненты:
Способ инкапсуляции IP дейтаграмм в последовательный канал. PPP
поддерживает как асинхронный канал (8 бит данных без контроля
четности, последовательный интерфейс), так и бит-ориентированный
синхронный канал;
Протокол управления каналом (LCP — Link Control Protocol),
используется для установления конфигурации и тестирования
соединения PPP;
Протоколов управления сетью (NCP — Network Control Protocol),
используется для указания различных протоколов сетевого уровня (IP,
Apple Talk, DECnet).
Метод инкапсуляции PPP описан в RFC-1548. Протокол управления сетью
для дейтаграмм IP описан в RFC-1332.

TCP/IP : Канальный уровень в стеке TCP/IP 42/279


Поля кадра PPP:
Кадры начинаются и заканчиваются с байта флага 0x7E;
Байт адреса, значение которого всегда 0xFF;
Байт управления, значение которого 0x03;
Поле протокола, аналогично полю «Тип кадра» в инкапсуляции
Ethernet;
Поле контрольной суммы CRC.
Флаг Адрес Упр. Данные Контрольная Флаг
Протокол
0x7E 0xFF 0x03 сумма 0x7E

1 байт 1 байт 1 байт 2 байта 2 байта 1 байт

до 1500 байт

0x0021 IP дейтаграмма

Данные управления каналом


0xС021
LCP

Данные управления сетью


0x8021
NCP

Рис. 11 — Инкапсуляция IP в PPP

TCP/IP : Канальный уровень в стеке TCP/IP 43/279


PPP и ISO HDLC
Формат кадра PPP реализован на основе стандарта ISO для кадров HDLC
(High-level Data Link Control).

Байт 0x7E необходимо экранировать, если он появляется в поле данных.


В последовательных каналах применяется битовое заполнение (bit
stuffing);
В асинхронных каналах используется экранирование специальным
символом:
Вместо байта 0x7E передается последовательность 0x7D, 0x5E;
Вместо байта 0x7D передается последовательность 0x7D, 0x5D;
По-умолчанию, байты со значением меньше чем 0x20 (т. е. все 32
управляющих символов ASCII) также экранируется. Например, вместо
байта 0x01 передается последовательность 0x7D, 0x21, в которой
инвертирован шестой бит второго байта.

TCP/IP : Канальный уровень в стеке TCP/IP 44/279


Преимущества инкапсуляции PPP

1 Инкапсуляция PPP поддерживает несколько протоколов на одной


последовательной линии (не только IP дейтаграммы);
2 PPP вычисляет контрольную сумму (CRC) для каждого фрейма и
может обнаруживать ошибки;
3 Динамическое конфигурирование IP адресов для каждой оконечной
системы (с использованием протокола управления IP каналом (NCP));
4 Поддержка сжатие заголовков TCP/IP;
5 Расширение в виде протокола управления каналом (LCP) для
автоконфигурирования параметров передачи данных на основе
характеристик канала.

PPP vs. SLIP


Инкапсуляция IP в PPP практически вытеснила инкапсуляцию IP в SLIP с
коммутируемых подключений. На данный момент, инкапсуляция SLIP
используется только в последовательных подключениях через
последовательные порты ПК.

TCP/IP : Канальный уровень в стеке TCP/IP 45/279


Интерфейс обратной связи — loopback

Программный (виртуальный) интерфейс ОС — позволяет клиенту и серверу,


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

lo, loopback0, lo0 ...


Все реализации стека TCP/IP поддерживают интерфейс обратной связи
(loopback).

Адресация
Для интерфейса loopback зарезервирована сеть класса А с
идентификатором сети 127 (0111 1111). Де-факто, интерфейсу loopback
назначается IP адрес 127.0.0.1 (и имя узла (hostname) — localhost).

TCP/IP : Канальный уровень в стеке TCP/IP 46/279


Пример конфигурации интерфейса обратной связи

Листинг 1 — Интерфейс loopback (Linux 3.12.13)


~> sudo ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 0 (Local Loopback)
RX packets 101588 bytes 5843906 (5.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 101588 bytes 5843906 (5.5 MiB)
TX errors 0 dropped 0overruns 0 carrier 0 collisions 0

Анализ
Интерфейс loopback реализованный в системе: lo;
Флаги интерфейса (статус): UP,LOOPBACK,RUNNING;
IP адрес интерфейса: 127.0.0.1/8;
Максимально возможный MTU: 65536.

TCP/IP : Канальный уровень в стеке TCP/IP 47/279


Листинг 2 — Интерфейс loopback (FreeBSD 9.3)
~> ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000

Анализ
Интерфейс loopback реализованный в системе: lo0;
Флаги интерфейса (статус): UP,LOOPBACK,RUNNING,MULTICAST;
Опции: RXCSUM,TXCSUM, ...;
Нулевая метрика;
IP адрес интерфейса: 127.0.0.1/8;
MTU: 16384.

TCP/IP : Канальный уровень в стеке TCP/IP 48/279


Особенность интерфейса
При широковещательной или групповой рассылке посылающий хост должен
принять свои же дейтаграммы (через интерфейс обратной связи).

Все что отправляется на адрес loopback (127.0.0.1), попадает на


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

TCP/IP : Канальный уровень в стеке TCP/IP 49/279


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

MTU
Максимальное количество байт данных в поле данных кадра канального
уровня называется «максимальный блок передачи» (MTU — Maximum
Transmission Unit).

Фрагментация
Если отсылается IP дейтаграмма, которая имеет размер больше чем MTU
канального уровня, осуществляется фрагментация (fragmentation).
Дейтаграмма разбивается на фрагменты, размером меньше MTU.

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

TCP/IP : Канальный уровень в стеке TCP/IP 50/279


RFC 1191
Тип канального уровня MTU (байт)
Hyperchannel 65535
Token Ring 16 Мбит/c 17914
Token Ring 4 Мбит/c 4464
FDDI 4352
Ethernet 1500
IEEE 802.3/802.2 1492
X.25 576
PPP, SLIP 296

MTU трассы (path MTU) 296 байт

MTU=296 байт
Ethernet 802.3/802.2

Узел A Узел B Узел C Узел D

PPP
MTU=1500 байт MTU=1492 байта
Рис. 12 — MTU трассы

TCP/IP : Канальный уровень в стеке TCP/IP 51/279


Протокол определения адреса — ARP
Причина реализации
IP адреса имеют значение только в семействе протоколов TCP/IP. На
канальном уровне используется собственная схема адресации.

Ethernet, Token ring, . . . имеют собственную схему адресации (в


основном 48-битные адреса);
Сетевой уровень должен уметь использовать данные канального уровня;
Сеть Ethernet, может быть использована различными сетевыми
уровнями в одно и то же время;
ПК использующие разные сетевые протоколы могут находиться на
одном и том же физическом кабеле.

Передача кадров
Передача кадров канального уроня осуществляется по 48-битным адресам.
Драйвер сетевой платы никогда не учитывает ни IP адрес назначения, ни
IP адрес отправителя.
TCP/IP : Алгоритмы и протоколы уровня IP 52/279
Возникает необходимость установить соответствие между двумя различными
формами адресов: 32-битными IP адресами и каким-либо типом адресов
канального уровня.
Статическое отображение (настраивается вручную);
Динамическое отображение (с использованием протоколов стека).
Для решения данной задачи используются протоколы определения адреса —
ARP (Address Resolution Protocol) и RARP (Reverse Address Resolution
Protocol).

RFC-826
Официальная спецификация ARP определена в RFC-826.

Логика преобразования
ARP: IP (протокольный адрес) → MAC (аппаратный адрес);
RARP: MAC (аппаратный адрес) → IP (протокольный адрес);

TCP/IP : Алгоритмы и протоколы уровня IP 53/279


invARP
Протоколы xARP применяются только в широковещательных сетях. В
нешироковещательных сетях используется invARP.

Отличия xARP от invARP


ARP определяет аппаратный адрес удаленной машины (в ряде случаев
локальный) — IPL !MACL ! : IPR !MACR ?;
RARP определяет локальный протокольный адрес по локальному
аппаратному адресу — MACL !IPL ?;
invARP определяет протокольные адреса удаленных станций по
известному аппаратному адресу — MACL !IPL ! : MACR !IPR ?.

Каналы PtP
Каналы точка-точка не используют ARP. Когда эти каналы
конфигурируются (обычно во время загрузки), ядру необходимо указать IP
адрес для каждого конца канала. Аппаратные адреса в данном случае не
используются.

TCP/IP : Алгоритмы и протоколы уровня IP 54/279


(2) (1) (15)
DNS служба
или файл hosts FTP клиент FTP сервер

IP: A:A:A:A (3) IP: B:B:B:B (14)


TCP модуль TCP модуль
MAC: A:A:A:A:A:A ядра ОС MAC: B:B:B:B:B:B ядра ОС

(5) (4) (10) (13)


ARP модуль IP модуль ARP модуль IP модуль
ядра ОС ядра ОС ядра ОС ядра ОС
(6)

(7) (9)
Модуль драйвера Модуль драйвера
сетевой платы сетевой платы
(12)
Среда передачи сигналов
(8) Кадр Кадр (11)
запроса ответа

IP: B:B:B:B IP: B:B:B:B


MAC: ??? MAC: B:B:B:B:B:B
(9)
Модуль драйвера
сетевой платы

(10) IP: C:C:C:C


ARP модуль
ядра ОС MAC: C:C:C:C:C:C

Рис. 13 — Поиск адреса с помощью протокола ARP (локальный сегмент)


TCP/IP : Алгоритмы и протоколы уровня IP 55/279
Последовательность выполнения поиска адреса и установления соединения:
1 FTP клиент пытается установить соединение с узлом ftpserver.net;
2 Через службу DNS или локальный файл (/etc/hosts) находится IP
адрес узла ftpserver.net;
3 Модуль TCP инициирует процедуру соединения с IP адресом B:B:B:B
и портом TCP 21;
4 IP модуль формирует дейтаграмму от узла IP A:A:A:A к узлу
B:B:B:B;
5 При инкапсуляции в кадр Ethernet необходим MAC адрес удаленного
узла. Модуль ARP просматривает локальную кэш-таблицу ARP;
6 Если MAC адрес отсутствует в таблице, выполняется процедура ARP
запроса;
7 Через сетевой интерфейс рассылается широковещательный запрос ARP
(MAC адрес назначения — FF::FF);
8 В заголовке ARP кадра содержится запрос: MACL ! : IPL !; IPR !MACR ?;
9 Каждый ПК в сегменте сети принимает широковещательный кадр;

TCP/IP : Алгоритмы и протоколы уровня IP 56/279


10 Через модуль ARP и указанный в запросе протокольный адрес,
удаленные машины определяют, принадлежит ли искомый аппаратный
адрес им или нет;
11 Только искомая машина формирует ARP ответ, в котором содержится
значение искомого аппаратного адреса B::B;
12 Узел, получивший ответ, формирует одноадресатный кадр на найденный
аппаратный адрес;
13 Дейтаграмма IP, полученная на узле с IP адресом B::B передается
модулю TCP;
14 Модуль TCP отвечает на инициализацию соединения;
15 Далее взаимодействуют прикладные процессы службы FTP.

TCP/IP : Алгоритмы и протоколы уровня IP 57/279


Заголовок Ethernet
0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


Аппаратный адрес назначения Аппаратный адрес источника Тип кадра Тип аппаратных
адресов

PT Type HW Len PT Len Opcode Sender MAC Sender IP


Тип протокольных Длина Длина Код операции Аппаратный адрес отправителя Протокольный адрес отправителя
адресов апп.ад. прот.ад.

Target MAC Target IP Padding


Аппаратный адрес назначения Протокольный адрес назначения Выравнивание до границы 16 байт

Заголовок ARP
Рис. 14 — Формат кадра ARP

Заголовок Ethernet 14 байт (без CRC);


Заголовок ARP 28 байт (плюс дополнение до границы 16 байт);
Поля «Тип апп. адресов» и «Тип прот. адресов» по 2 байта;
Поля «Длина апп. адреса» и «Длина прот. адреса» по 1 байту;
Поле «Код операции» 2 байта;
Поле «Апп. адрес отпр.» 6 байт;
Поле «Прот. адрес отпр.» 4 байта;
Поле «Апп. адрес назначения» 6 байт;
Поле «Прот. адрес назначения» 4 байта;
TCP/IP : Алгоритмы и протоколы уровня IP 58/279
0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


0xFF:FF:FF:FF:FF:FF 0x1E:2A:3B:4E:5C:DA 0x0806 0x0001
PT Type HW Len PT Len Opcode Sender MAC Sender IP
0x0800 0x06 0x04 0x0001 0x1E:2A:3B:4E:5C:DA 0x0A:0A:0C:09
Target MAC Target IP Padding
0x00:00:00:00:00:00 0x0A:0A:0C:01 0x000000000000

Рис. 15 — Пример кадра запроса ARP

Анализ
Заголовок Ethernet (14 байт) и заголовок ARP (28 байт);
Широковещательный кадр Ethernet (FF:FF:FF:FF:FF:FF);
Тип кадра Ethernet: ARP (0x0806);
Аппаратные адреса: Ethernet MAC (0001);
Протокольные адреса: IP (0800);
Длины адресов: MAC — 6 байт (06), IP — 4 байта (04);
Код процедуры: «Запрос» (0001);
Апп. адрес назначения неизвестен (00:00:00:00:00:00);

TCP/IP : Алгоритмы и протоколы уровня IP 59/279


0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


0xFF:FF:FF:FF:FF:FF 0x1E:2A:3B:4E:5C:DA 0x0806 0x0001
PT Type HW Len PT Len Opcode Sender MAC Sender IP
0x0800 0x06 0x04 0x0001 0x1E:2A:3B:4E:5C:DA 0x0A:0A:0C:09
Target MAC Target IP Padding
0x00:00:00:00:00:00 0x0A:0A:0C:01 0x000000000000

Destination MAC Source MAC Type HW Type


0x1E:2A:3B:4E:5C:DA 0x2F:33:F6:DF:F8:99 0x0806 0x0001
PT Type HW Len PT Len Opcode Sender MAC Sender IP
0x0800 0x06 0x04 0x0002 0x2F:33:F6:DF:F8:99 0x0A:0A:0C:01
Target MAC Target IP Padding
0x1E:2A:3B:4E:5C:DA 0x0A:0A:0C:09 0x000000000000

Рис. 16 — Пример кадров запроса и ответа ARP (обмен значений в заголовках)

Анализ изменений
Одноадресатный кадр Ethernet;
Код процедуры: «Ответ» (0002);
Искомое отображение содержится в полях «Sender MAC» и «Sender IP»
В поля «Target MAC» и «Target IP» копируются значения из кадра запроса.

TCP/IP : Алгоритмы и протоколы уровня IP 60/279


0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


0x1E:2A:3B:4E:5C:DA 0x2F:33:F6:DF:F8:99 0x0806 0x0001
PT Type HW Len PT Len Opcode Sender MAC Sender IP
0x0800 0x06 0x04 0x0001 0x2F:33:F6:DF:F8:99 0x0A:0A:0C:01
Target MAC Target IP Padding
0x00:00:00:00:00:00 0x0A:0A:0C:09 0x000000000000

Рис. 17 — Пример кадра повторного запроса ARP

Анализ изменений
Одноадресатный кадр Ethernet;
Поле «Target MAC» содержит нули как и в обычном запросе.

Причина возникновения
Кадры повторного запроса возникают при обновлении записи в кэш-таблице
ARP.

TCP/IP : Алгоритмы и протоколы уровня IP 61/279


0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


Запрос 0xFF:FF:FF:FF:FF:FF 0x2F:33:F6:DF:F8:99 0x0806 0x0001
PT Type HW Len PT Len Opcode Sender MAC Sender IP
0x0800 0x06 0x04 0x0001 0x2F:33:F6:DF:F8:99 0x0A:0A:0C:01
Target MAC Target IP Padding
0x00:00:00:00:00:00 0x0A:0A:0C:0A 0x000000000000

0 5 6 11 12 13 14 15

Destination MAC Source MAC Type HW Type


0x2F:33:F6:DF:F8:99 0x1E:2A:3B:4E:5C:DA 0x0806 0x0001
Валидный
ответ

PT Type HW Len PT Len Opcode Sender MAC Sender IP


0x0800 0x06 0x04 0x0002 0x1E:2A:3B:4E:5C:DA 0x0A:0A:0C:0A
Target MAC Target IP Padding
0x2F:33:F6:DF:F8:99 0x0A:0A:0C:01 0x000000000000

0 5 6 11 12 13 14 15
подстановкой

Destination MAC Source MAC Type HW Type


0x2F:33:F6:DF:F8:99 0xEF:12:33:77:AA:B9 0x0806 0x0001
Ответ с

PT Type HW Len PT Len Opcode Sender MAC Sender IP


0x0800 0x06 0x04 0x0002 0xEF:12:33:77:AA:B9 0x0A:0A:0C:0A
Target MAC Target IP Padding
0x2F:33:F6:DF:F8:99 0x0A:0A:0C:01 0x000000000000

Рис. 18 — Пример кадров ответа ARP с подстановкой

TCP/IP : Алгоритмы и протоколы уровня IP 62/279


Листинг 3 — Пример tcpdump
~> sudo tcpdump -e -XX -l -n -vvv -ttt -i eth0 arp
00:1f:d0:59:4e:b5 > ff:ff:ff:ff:ff:ff,
ethertype ARP (0x0806)
length 42: Ethernet (len 6), IPv4 (len 4),
Request who-has 10.10.12.3 tell 10.10.12.9, length 28
0x0000: ffff ffff ffff 001f d059 4eb5 0806 0001
0x0010: 0800 0604 0001 001f d059 4eb5 0a0a 0c09
0x0020: 0000 0000 0000 0a0a 0c03
-----------------------------------
90:2b:34:8e:ad:83 > 00:1f:d0:59:4e:b5,
ethertype ARP (0x0806)
length 60: Ethernet (len 6), IPv4 (len 4),
Reply 10.10.12.3 is-at 90:2b:34:8e:ad:83, length 46
0x0000: 001f d059 4eb5 902b 348e ad83 0806 0001
0x0010: 0800 0604 0002 902b 348e ad83 0a0a 0c03
0x0020: 001f d059 4eb5 0a0a 0c09 0000 0000 0000
0x0030: 0000 0000 0000 0000 0000 0000

TCP/IP : Алгоритмы и протоколы уровня IP 63/279


Листинг 4 — Утилита arp — Кэш-таблица
~>sudo arp -ve
Address HWtype HWaddress Flags M
skoll.radiocoder.net ether f4:ec:38:d0:1a:77 C
atlas.radiocoder.net ether 14:d6:4d:a7:d4:fe C
titan.radiocoder.net ether 90:2b:34:8e:ad:83 C
Entries: 3 Skipped: 0 Found: 3

Время жизни записи


Для записей, вводимых в ARP кэш, устанавливается тайм-аут.
Berkeley-подобные реализации (BSD) — 20 мин.;
Распространенное время жизни — 180 сек.;
Статические записи хранятся постоянно.

TCP/IP : Алгоритмы и протоколы уровня IP 64/279


Статические записи можно вносить вручную или хранить в файле —
/etc/ethers:

Листинг 5 — Файл ethers


#Ethernet MAC IP
f4:ec:38:d0:1a:77 10.10.12.1

Статические записи
Записи из файла читаются каждый раз при загрузке ОС. Записи внесенные
вручную (утилитой arp) теряются после перезагрузки.

Поддерживаемые типы аппаратных адресов


arcnet, dlci, fddi, hippi, irda, x25, infiniband, eui64 . . .

TCP/IP : Алгоритмы и протоколы уровня IP 65/279


Стек IPv6
В стеке IPv6 ARP не используется, его функции возложены на ICMPv6.

Не рассмотренные вопросы
ARP самоопрос (или беспричинный ARP);
Proxy ARP.

TCP/IP : Алгоритмы и протоколы уровня IP 66/279


Протокол обратного преобразования адресов — RARP

Область применения
Любое устройство, требующее IP адрес на раннем этапе загрузки.
Бездисковые ПК;
Тонкие клиенты и т. д.

1 Каждая система в сети имеет уникальный аппаратный адрес;


2 ПК считывает апп. адрес с интерфейсной платы;
3 Формирует RARP запрос (широковещательный кадр);
4 В ответ RARP сервер сообщает IP адрес закрепленный за данным
аппаратным адресом.

RFC-903
Официальная спецификация RARP определена в RFC-903.

TCP/IP : Алгоритмы и протоколы уровня IP 67/279


Изменения в кадре по сравнению с ARP
1 Поле «Тип кадра» имеет значение 0x8035;
2 Поле «Код операции» имеет значения:
0x03 для RARP запроса;
0x04 для RARP ответа.

Тип рассылки
RARP запрос является широковещательным, RARP ответ одноадресатный.

Листинг 6 — Утилита arp — Кэш-таблица


~> sudo tcpdump -e -l -n -i eth0 rarp
8:0:20:3:f6:42 ff:ff:ff:ff:ff:ff rarp 60:
rarp who-is 8:0:20:3:f6:42 tell 8:0:20:3:f6:42
-----------------------------------
0:0:c0:6f:2d:40 8:0:20:3:f6:42 rarp 42:
rarp reply 8:0:20:3:f6:42 at 0a:0a:0c:09

TCP/IP : Алгоритмы и протоколы уровня IP 68/279


Развитие протоколов сетевой загрузки
RARP → BOOTP → DHCP → DHCPv6

Не рассмотренные вопросы
Реализация RARP сервера;
Несколько RARP серверов в сети;
Основы протокола BOOTP (Bootstrap protocol);
Понятие PXE (Preboot Execution Environment).

TCP/IP : Алгоритмы и протоколы уровня IP 69/279


§9

Протокол Интернет версии 4

Internet Protocol version 4

TCP/IP : Протокол Internet v4 70/279


IP: протокол Internet
Connectionless protocol

Протокол не поддерживающий соединений. IP ненадежный протокол,


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

Под термином «ненадежный» подразумевается, что не существует гарантии


того, что IP дейтаграмма успешно достигнет узел назначения. Однако,
существует несколько механизмов сигнализации:
При отбрасывании дейтаграмм (datagram drop), модуль IP должен
послать ICMP сообщение отправителю;
Любая требуемая «надежность» доставки должна обеспечиваться
верхними уровнями (TCP, SCTP и т. д.).
Пример неполадки вызывающей отбрасывание

Переполнение памяти;
Некорректная дейтаграмма, не поддерживаемый протокол и т. д.

TCP/IP : Протокол Internet v4 71/279


Порядок следования бит/байт

7 . . . 0 — Big endian — старший значащий бит или байт стоит


первым (слева). Иногда называется сетевым порядком следования
байт (network byte order);
0 . . . 7 — Little endian — младший значащий бит или байт стоит
первым.

Поля дейтаграммы IPv4:


1 Версия протокола (4 бита);
2 Длина заголовка (Header length) — количество 32-x битных слов в
заголовке, включая любые опции (4 бита). Мин. 0x5, макс. 0xF ;
3 Тип службы (ToS — Type of Service) — RFC-1349 (8 бит);
4 Полная длина дейтаграммы (Total length) — полная длина дейтаграммы
в байтах (16 бит). Поле изменяется при фрагментации;
5 Идентификатор (Identification) — уникальный номер дейтаграммы (16
бит);
6 Флаги фрагментации (Flags) — указывают на наличие фрагментов или
запрет фрагментации (3 бита);
TCP/IP : Протокол Internet v4 72/279
7 Смещение фрагмента (Fragmentation offset) — определяет положение
фрагмента относительно исходной дейтаграммы (13 бит);
8 Время жизни (Time to live) — максимальное количество транзитных
узлов, через которые может проследовать дейтаграмма. Значение
ограничивает время жизни дейтаграммы и предотвращает бесконечное
блуждание дейтаграмм (8 бит);
9 Протокол (Protocol) — используется при демультиплексировании и
указывает на протокол верхнего уровня (8 бит);
10 Контрольная сумма заголовка (Header checksum) — рассчитывается
только для IP заголовка, т. е. не включает в себя данные, которые
следуют за заголовком (16 бит);
11 Адрес источника (Source IP address) — 32 бита;
12 Адрес назначения (Destination IP address) — 32 бита;
13 Опции (Options) — список дополнительной информации переменной
длины.

TCP/IP : Протокол Internet v4 73/279


Опции
Поле опций используются редко, не все узлы поддерживают опции.
Поле опций всегда ограничено 32 битами. Байты заполнения (0x0),
добавляются по необходимости. Заголовок всегда кратен 32 битам!

Определены следующие опции:


Безопасность и обработка ограничений (RFC-1108);
Запись маршрута — сохранение в заголовке IP адресов транзитных
узлов;
Временная метка — заголовок дополняется отметками времени на
транзитных узлах;
Свободная маршрутизация от источника — список IP адресов, через
которые может маршрутизироваться дейтаграмма;
Жесткая маршрутизация от источника — список IP адресов, через
которые должна маршрутизироваться дейтаграмма

TCP/IP : Протокол Internet v4 74/279


4 бита 4 бита 8 бит 16 бит

0 3 4 7 8 15 16 18 19 31

Версия Длина Тип Длина


протокола заголовка службы дейтаграммы IP
IP IP

Флаги
Идентификатор дейтаграммы фрагмен- Смещение фрагмента
тации

Время жизни Протокол


20 байт

Контрольная сумма заголовка дейтаграммы


дейтаграммы верхнего уровня

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

IP адрес назначения

Опции (переменной длины)

Поле данных

Рис. 19 — Формат дейтаграммы IPv4

TCP/IP : Протокол Internet v4 75/279


Листинг 7 — Пример дейтаграммы IP
~> sudo tcpdump -i wlan0 -lvvvn -e -XX ip
0x0000: 14d6 4da7 d4fe 6817 2989 222c 0800 4500
0x0010: 003c cffa 4000 4011 3e9d 0a0a 0c05 0a0a
0x0020: 0c01 b745 0035 0028 6617 c36b 0100 0001
0x0030: 0000 0000 0000 0a72 6164 696f 636f 6465
0x0040: 7203 6e65 7400 0001 0001

Анализ дейтаграммы

0x4 — версия протокола (4), 0x5 — длина заголовка (20 байт);


0x00 — ToS, 0x003c — длина дейтаграммы (60 байт);
0xcffa — идентификатор (53242);
0x4000 — флаги фрагментации и смещение (отсутствует);
0x40 — ttl (64), 0x11 — UDP (17);
0xcffa — идентификатор (53242), 0x3e9d — КC;
0x0a0a0c05 — IP адрес источника (10.10.12.5);
0x0a0a0c01 — IP адрес отправителя (10.10.12.1);

TCP/IP : Протокол Internet v4 76/279


Алгоритм расчета контрольной суммы
Контрольная сумма заголовка IPv4 рассчитывается только по
значениям полей заголовка IP.

RFC-1071, RFC-1141

1 Поле контрольной суммы устанавливается в 0x0000;


2 Выполняется сложение «по модулю один», т. е. сложение в обратном
коде с циклическим переносом из старшего разряда в младший;
3 Результат сложения инвертируется и записывается в поле контрольной
суммы;
4 Приемный модуль IP вновь рассчитывает контрольную сумму с учетом
значения поля контрольной суммы;
5 Если результат равен 0xffff — ошибки в принятой дейтаграмме
отсутствуют или не обнаружены;
6 Если результат сложения отличен от 0xffff, т. е. в дейтаграмме
присутствуют ошибки, она отбрасывается.
TCP/IP : Протокол Internet v4 77/279
Листинг 8 — Расчет контрольной суммы заголовка IP
4500 003c cffa 4000 4011 [0000] 0a0a 0c05 0a0a 0c01

Манипуляции на передаче

4500 453c 1537 5537 9548 9f52 ab57 b561


+ 003c + cffa + 4000 + 4011 + 0a0a + 0c05 + 0a0a + 0c01
453c 11536 5537 9548 9f52 ab57 b561 c162
1537

0xc162 → 1100 0001 0110 0010


0011 1110 1001 1101 → 0x3e9d

Манипуляции на приеме

4500 453c 1537 ... b561 3e9d


+ 003c + cffa + 4000 ... + 0c01 + c162
453c 11536 5537 ... c162 ffff
1537

TCP/IP : Протокол Internet v4 78/279


Принципы адресации IPv4
RFC
Принципы адресации и требования к узлам описаны в RFC-950.

После получения от InterNIC идентификатора сети определенного класса


(или блок IP адресов), системный администратор решает, делить ли сеть на
подсети или нет, а если делить, то сколько бит будет отведено на адресацию
подсети и сколько на адрес узла.

Причины деления IP сетей на подсети


Разделение на подсети скрывает детали внутренней организации сети от
внешних маршрутизаторов;
Разделение на подсети уменьшает размер таблиц маршрутизации
Internet.

Глубина адресации
Адресное пространство IPv4 равно 232 = 4294967296 адресов IP.
TCP/IP : Протокол Internet v4 79/279
Принцип конфигурирования интерфейса ПК:
1 В момент загрузки узла (или перенастройки интерфейса),
осуществляется установка IP адреса. Например: 10.10.12.1;
2 В дополнение к IP адресу, хосту также необходимо установить
адресную маску подсети. Например: 255.0.0.0.

Адресная маска
Адресная маска (префикс) — это 32-x битное значение, которое содержит
биты, установленные в единицу для идентификатора сети и идентификатора
подсети, и биты, установленные в 0 для идентификатора хоста.

255.255.255.0 — 1111 1111.1111 1111.1111 1111.0000 0000

n бит k бит 32-n+k бит

Префикс
Префикс сети Адрес узла
подсети

32 бита
Рис. 20 — Пример представления адреса IPv4
TCP/IP : Протокол Internet v4 80/279
Адреса IPv4 могут быть представлены в нескольких формах записи:
Десятичная запись с точками или без: 10.10.12.1 или 168430593;
BIN запись: 0000 1010.0000 1010.0000 1100.0000 0001;
HEX запись с точками или без: 0x0A.0A.0C.01 или 0x0A0A0C01;
OCT запись с точками или без: 012.012.014.001 или 01202406001;
Существует несколько способов записи (нотации) пространства адресов
IPv4:
1 Классовая адресация (устарела);
2 Адресация с масками подсетей переменной длины (Variable Length
Subnet Mask);
3 Бесклассовая междоменная маршрутизация (Classles Interdomain
Routing);
4 Смешанная адресация VLSM и CIDR.

Пример указания адреса


Классовый способ указания адреса и маски:
172.16.101.87 255.255.252.0

TCP/IP : Протокол Internet v4 81/279


Любой адрес в классовой нотации может быть представлен в форме нотации
бесклассовой. Например, адрес сети 10.10.12.0 255.255.255.240
может быть представлен в CIDR нотации 10.10.12.0/28:

10.10.12.0 — 0000 1010.0000 1010.0000 1100.0000 0000


255.255.255.240 — 1111 1111.1111 1111.1111 1111.1111 0000

Блоки адресов в классовой нотации могут быть представлены в нотации


CIDR:
Класс Пространство адресов и маска CIDR
A 1.0.0.0–126.0.0.0 255.0.0.0 /8
B 128.0.0.0–191.255.0.0 255.255.0.0 /16
C 192.0.0.0–223.255.255.0 255.255.255.0 /24

TCP/IP : Протокол Internet v4 82/279


RFC
В RFC-5735 указаны специальные диапазоны адресов IPv4.

Маршрутизация Пространство адресов Назначение RFC


Не допустима 0.0.0.0/8 Текущая подсеть 1122
Допустима внутри блока 10.0.0.0/8 Выделенная подсеть 1918
Не допустима 127.0.0.0/8 Петлевой интерфейс 1122
Допустима внутри блока 169.254.0.0/16 Локальная связь 3927
Допустима внутри блока 172.16.0.0/12 Выделенная подсеть 1918
Допустима внутри блока 192.168.0.0/16 Выделенная подсеть 1918
Частично допустима 224.0.0.0/4 Групповая рассылка 3171
Не допустима 255.255.255.255/32 Ограниченная 919
широковещательная
рассылка

TCP/IP : Протокол Internet v4 83/279


Пример №1 планирования подсетей IPv4

Исходные данные
Выделенная сеть: 172.100.30.0/23 (255.255.254.0);
Выделенных подсетей: 12;
Узлов в каждой подсети: 17;
Запланировать резерв.

1 12 подсетей можно адресовать используя минимум 4 бита — 24 = 16 IP


адресов;
2 17 узлов можно адресовать используя минимум 5 бит — 25 = 32 IP
адреса;
3 Исходная сеть позволяет спланировать адресное пространство до
29 = 512 IP адресов.

TCP/IP : Протокол Internet v4 84/279


172.100.30.0 — 1010 1100.0110 0100.0001 1110.0000 0000
255.255.254.0 — 1111 1111.1111 1111.1111 1110.0000 0000
1010 1100.0110 0100.0001 1110.0000 0000
Красные биты отведены для адресации подсетей;
Синие биты отведены для адресации узлов.
Подсеть Двоичное представление
172.100.30.0/27 1010 1100.0110 0100.0001 111 0.000 00000
172.100.30.32/27 1010 1100.0110 0100.0001 111 0.001 00000
172.100.30.64/27 1010 1100.0110 0100.0001 111 0.010 00000
172.100.30.96/27 1010 1100.0110 0100.0001 111 0.011 00000
172.100.30.128/27 1010 1100.0110 0100.0001 111 0.100 00000
172.100.30.160/27 1010 1100.0110 0100.0001 111 0.101 00000
172.100.30.192/27 1010 1100.0110 0100.0001 111 0.110 00000
172.100.30.224/27 1010 1100.0110 0100.0001 111 0.111 00000
172.100.31.0/27 1010 1100.0110 0100.0001 111 1.000 00000
172.100.31.32/27 1010 1100.0110 0100.0001 111 1.001 00000
172.100.31.64/27 1010 1100.0110 0100.0001 111 1.010 00000
................................
172.100.31.224/27 1010 1100.0110 0100.0001 111 1.111 00000
TCP/IP : Протокол Internet v4 85/279
Пример подсети
Рассмотрим подсеть 172.100.31.224/27

IP адреса Двоичное представление


172.100.31.225 1010 1100.0110 0100.0001 111 1.111 00001
172.100.31.226 1010 1100.0110 0100.0001 111 1.111 00010
172.100.31.227 1010 1100.0110 0100.0001 111 1.111 00011
172.100.31.228 1010 1100.0110 0100.0001 111 1.111 00100
172.100.31.229 1010 1100.0110 0100.0001 111 1.111 00101
172.100.31.230 1010 1100.0110 0100.0001 111 1.111 00110
172.100.31.231 1010 1100.0110 0100.0001 111 1.111 00111
172.100.31.232 1010 1100.0110 0100.0001 111 1.111 01000
..............................
172.100.31.254 1010 1100.0110 0100.0001 111 1.111 11110
172.100.31.255 1010 1100.0110 0100.0001 111 1.111 11111

172.100.31.224 — адрес подсети;


172.100.31.255 — широковещательный адрес подсети;

TCP/IP : Протокол Internet v4 86/279


Схематичный план организации сети 172.100.30.0/23

172.100.30.0/23
Шлюз провайдера
172.100.30.0/27
PPP
G R 30.1
Маршрутизатор абонента
R 30.4 R 30.3 R 30.2

.30.32 .30.64 .31.224


Рис. 21 — Физическая и логическая организация сети

TCP/IP : Протокол Internet v4 87/279


Пример №2 планирования подсетей IPv4

Пусть для планирования выделен блок N


Sa
10.0.0.0/16. Необходимо разделить все
доступное адресное пространство на 4 части:
1 Подсеть Sa — занимает половину всего
Sd
адресного пространства N; Sb
Sc
2 Подсеть Sb — занимает четверть
адресного пространства N или Sa /2;
3 Подсети Sc и Sd — занимают по 1/8
адресного пространства N или Sb /2.
Рис. 22 — План сети

TCP/IP : Протокол Internet v4 88/279


Исходная сеть 10.0.0.0/16 имеет адресное пространство 216 = 65536
адресов:

10.0.0.0 — 0000 1010.0000 0000.0000 0000.0000 0000


255.255.0.0 — 1111 1111.1111 1111.0000 0000.0000 0000

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


Поделим сеть на две равные подсети увеличив маску на 1 бит, т. е. введем
префикс подсети. Получим подсеть Sa :

10.0.0.0 — 0000 1010.0000 0000.0000 0000.0000 0000


255.255.128.0 — 1111 1111.1111 1111.1000 0000.0000 0000

Оставшаяся подсеть (N/2):

10.0.128.0 — 0000 1010.0000 0000.1000 0000.0000 0000


255.255.128.0 — 1111 1111.1111 1111.1000 0000.0000 0000

TCP/IP : Протокол Internet v4 89/279


Для подсети Sb необходимо выделить четверть оставшегося пространства
или половину исходного. Вновь разделим остаток пополам, увеличив
префикс подсети еще на 1 бит. Получим две подсети с пространством N/4:

10.0.128.0 — 0000 1010.0000 0000.1000 0000.0000 0000


255.255.192.0 — 1111 1111.1111 1111.1100 0000.0000 0000
10.0.192.0 — 0000 1010.0000 0000.1100 0000.0000 0000
255.255.192.0 — 1111 1111.1111 1111.1100 0000.0000 0000

Адреса из пространства 10.0.128.0/18 выделим для подсети Sb .


Пространство 10.0.192.0/18 разделим между подсетями Sc и Sd .

TCP/IP : Протокол Internet v4 90/279


Аналогичным способом, из оставшегося пространства выделим подсети Sc и
Sd емкостью N/8 каждая:

10.0.192.0 — 0000 1010.0000 0000.1100 0000.0000 0000


255.255.224.0 — 1111 1111.1111 1111.1110 0000.0000 0000
10.0.224.0 — 0000 1010.0000 0000.1110 0000.0000 0000
255.255.224.0 — 1111 1111.1111 1111.1110 0000.0000 0000

Т. о. подсеть Sc располагает адресным пространством 10.0.192.0/19,


подсеть Sd — 10.0.224.0/19.

TCP/IP : Протокол Internet v4 91/279


План выделенных подсетей
10.0.0.0/17
10.0.0.0/16
Sa

Sd
Sb
Sc 10.0.224.0/19
10.0.128.0/18
10.0.192.0/19

Рис. 23 — План сети

Адрес подсети Маска подсети Емкость Диапазон


10.0.0.0 /17 (255.255.128.0) 32 768 10.0.0.0–10.0.127.255
10.0.128.0 /18 (255.255.192.0) 16 384 10.0.128.0–10.0.191.255
10.0.192.0 /19 (255.255.224.0) 8 192 10.0.192.0–10.0.223.255
10.0.224.0 /19 (255.255.224.0) 8 192 10.0.224.0–10.0.255.255

TCP/IP : Протокол Internet v4 92/279


Листинг 9 — Утилита ifconfig (из набора «nettools»)
~> sudo ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
mtu 1500
inet 10.10.12.5 netmask 255.255.255.240
broadcast 10.10.12.15
ether 68:17:29:89:22:2c txqueuelen 1000 (Ethernet)
RX packets 67626 bytes 65961377 (62.9 MiB)
RX errors 0 dropped 1 overruns 0 frame 0
TX packets 63980 bytes 26932724 (25.6 MiB)
TX errors 0 dropped 0 overruns 0
carrier 0 collisions 0

Листинг 10 — Установка IP адреса


~> sudo ifconfig wlan0 172.16.101.87/22

TCP/IP : Протокол Internet v4 93/279


Листинг 11 — Утилита ip (из набора «iproute2»)
~> sudo ip link
1: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP mode DORMANT
group default qlen 1000
link/ether 68:17:29:89:22:2c brd ff:ff:ff:ff:ff:ff

2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP>
mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT
group default qlen 1000
link/ether 2c:d4:44:9f:c3:dc brd ff:ff:ff:ff:ff:ff

Листинг 12 — Утилита ip (из набора «iproute2»)


~> sudo ip -d addr show wlan0
1: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP>
mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 68:17:29:89:22:2c brd ff:ff:ff:ff:ff:ff
inet 172.16.101.87/22 brd 172.16.103.255
scope global wlan0
valid_lft forever preferred_lft forever
TCP/IP : Протокол Internet v4 94/279
Принципы маршрутизации IPv4
Основные понятия
IP маршрутизация — процесс поиска в таблице маршрутизации и
определение интерфейса, куда будет передана дейтаграмма.
Политика маршрутизации — устанавливает правила, по которым
решается, какой маршрут будет внесен в таблицу маршрутизации.
Модуль IP осуществляет механизм маршрутизации, тогда как служба
маршрутизации (daemon) определяет политику маршрутизации.

Daemon — Disk And Execution MONitor


Для реализации IP маршрутизации используются прикладные
«демоны маршрутизации». Демон (аналог «службы» — services)
исполняется в фоновом режиме. Демоны запускаются при загрузке
ОС, и выполняются все время, пока система работает. Демоны
маршрутизации «UNIX-like OS»:
routed
gated

TCP/IP : Протокол Internet v4 95/279


Принцип пересылки
IP маршрутизация осуществляется по принципу пересылка-за-пересылкой
(hop-by-hop).

Если пункт назначения напрямую включен в локальную сеть (Ethernet


или PPP-подключение), IP дейтаграмма направляется непосредственно
в пункт назначения;
Иначе узел посылает дейтаграмму на маршрутизатор по умолчанию
(если отсутствует другой маршрут), предоставляя маршрутизатору
решать как доставить дейтаграмму;
Предварительные условия:
1 Модуль IP не знает полный маршрут к пункту назначения (за
исключением непосредственно подключеных к сети назначения);
2 Известен только IP адрес маршрутизатора следующей пересылки, на
который посылается дейтаграмма (если не задана «маршрутизация от
источника»);
3 Предпологается, что маршрутизатор следующей пересылки ближе к
пункту назначения, чем посылающий узел.
TCP/IP : Протокол Internet v4 96/279
1 1
Запрос
1
Ra Rb Rc 1
2 2
2 2
Ns Ответ Nd
3 3
Rd Re Ответ
3
Рис. 24 — Пример симметричной и ассиметричной маршрутизации IP

Симметрия маршрута
При симметричной маршрутизации путь, по которому отправлялся
запрос совпадает с маршрутом, по которому возвращается ответ;
При несимметричной маршрутизации путь, по которому отправлялся
запрос несовпадает с маршрутом, по которому возвращается ответ;

TCP/IP : Протокол Internet v4 97/279


Принятие решения о маршрутизации на узле
Алгоритм
Вычислить IP подсеть отправителя (S/IP (AND) S/SN);
Вычислить IP подсеть получателя (D/IP (AND) S/SN);
Сравнить адреса подсетей (S/SN (AND) D/SN);
При совпадении адресов, дейтаграмма передается узлу назначения;
При несовпадении, дейтаграмма передается маршрутизатору.

10.10.12.18 — 0000 1010.0000 1010.0000 1100.0001 0010


255.255.255.240 — 1111 1111.1111 1111.1111 1111.1111 0000
10.10.12.16 — 0000 1010.0000 1010.0000 1100.0001 0000

10.10.12.1 — 0000 1010.0000 1010.0000 1100.0000 0001


255.255.255.240 — 1111 1111.1111 1111.1111 1111.1111 0000
10.10.12.0 — 0000 1010.0000 1010.0000 1100.0000 0000
TCP/IP : Протокол Internet v4 98/279
Для маршрутизации IP модуль должен выполнить следующие действия:
1 Осуществляется поиск в таблице маршрутизации, при этом ищется
пункт, который совпадет с полным адресом пункта назначения (должен
совпасть идентификатор сети и идентификатор хоста);
Если пункт найден в таблице маршрутизации, пакет посылается на
указанный маршрутизатор следующей пересылки или на непосредственно
подключенный интерфейс (в зависимости от поля флагов). Как правило,
так определяются каналы точка-точка, при этом другой конец такого
канала, как правило, является полным IP адресом удаленного хоста;
2 Осуществляется поиск в таблице маршрутизации пункта, который
совпадет, как минимум, с идентификатором сети назначения;
Если пункт найден, пакет посылается на указанный маршрутизатор
следующей пересылки или на непосредственно подключенный интерфейс
(в зависимости от поля флагов);
3 В таблице маршрутизации ищется пункт, помеченный
"по умолчанию"(default gateway, или дежурный маршрутизатор). Если
пункт найден, пакет отсылается на указанный маршрутизатор по
умолчанию;
4 Если ни один из шагов не дал положительного результата, дейтаграмма
считается недоставленной (возвращается ошибка «хост недоступен»
(host unreachable) или «сеть недоступна» (network unreachable).
TCP/IP : Протокол Internet v4 99/279
ICMP TCP UDP
модуль модуль модуль
Процесс
маршрутизации
(gated)
Да

Буфер Перенаправление IP-назначения


Утилита Таблица
IP-вывода совпадает с
route маршрутизации Нет IP нашего узла?
(очередь)

На
Утилита сетевой Маршрутизация Опции IP
netstat интерфейс от источника

Ethernet Буфер
Ethernet IP-ввода
От сетевого
(очередь)
интерфейса

Рис. 25 — Взаимодействие процессов в модуле IP при маршрутизации

TCP/IP : Протокол Internet v4 100/279


Листинг 14 — Пример таблицы маршрутизации (утилита ip)
~> sudo ip -d -r route show
unicast default via atlas.radiocoder.net dev wlan0

Листинг 15 — Пример таблицы маршрутизации (утилита netstat)


~> sudo netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags Iface
0.0.0.0 10.10.12.1 0.0.0.0 UG wlan0
10.10.12.0 0.0.0.0 255.255.255.240 U wlan0

Анализ
Установлен маршрут «по умолчанию» через шлюз 10.10.12.1/28;
Флаги: U — маршрут используется, G — узел является шлюзом;
Все записи закреплены за интерфейсом wlan0.

TCP/IP : Протокол Internet v4 101/279


Шлюз провайдера 91.122.40.0/30 Маршрутизатор
Internet абонента
PPP .1
G R
10.10.12.16/28 10.10.12.0/28

.19 .17 .14 .10


R

Рис. 26 — Пример маршрутизации IP

Листинг 16 — Таблица маршрутизации узла 10.10.12.10


Destination Gateway Genmask Flags Iface
0.0.0.0 10.10.12.1 0.0.0.0 UG wlan0
10.10.12.0 0.0.0.0 255.255.255.240 U wlan0
10.10.12.16 10.10.12.14 255.255.255.240 UG wlan0

Листинг 17 — Таблица маршрутизации узла 10.10.12.19


Destination Gateway Genmask Flags Iface
0.0.0.0 10.10.12.17 0.0.0.0 UG wlan0
10.10.12.16 0.0.0.0 255.255.255.240 U wlan0

TCP/IP : Протокол Internet v4 102/279


Шлюз IP маршрутизации
Узлы и шлюзы
По умолчанию, IP узлы не допускают выполнения пересылки дейтаграмм
между интерфейсами.
Для выполнения пересылки дейтаграмм (ip forwarding) необходимо как
минимум:
1 Разрешить пересылку нелокальных (т. е. не только собственных)
дейтаграмм;
2 Сконфигурировать правила пересылки.
Internal Внутренний Внешний
External
network интерфейс интерфейс network
(int.interface) (ext.interface)

Ethernet Ethernet

ip.forwarding=1
packet filter

Рис. 27 — Шлюз IP маршрутизации

TCP/IP : Протокол Internet v4 103/279


IP forwarding
В UNIX-подобных ОС, разрешение на пересылку устанавливается с
помощью системных переменных ядра ОС (sysctl) или виртуальной ФС
процессов proc (Linux).

Листинг 18 — Linux 3.12.26 и FreeBSD 9.3


linux~> sysctl net.ipv4.ip_forward = 1
bsd~> sysctl net.inet.ip.forwarding=1

Packet filter
Правила пересылки дейтаграмм реализуются с помощью пакетных
фильтров. Например:
Iptables — интерфейс к пакетному фильтру netfilter ядра Linux;
IPFW, IPF, PF — пакетные фильтры BSD.

Модуль ОС
Обычно, пакетные фильтры функционируют в области памяти ядра ОС, и
реализуются в форме модуля ядра.
TCP/IP : Протокол Internet v4 104/279
Пример IP шлюза
Листинг 19 — Файл pf.conf и утилита pfctl (FreeBSD 9.3)
# options
set loginterface tun0
set skip on lo
# scrub
scrub in
# nat
nat on tun0 from 10.10.12.0/28 to any -> tun0
# filter rules
block in
pass out
pass quick on vr0
pass in on tun0 proto { tcp, udp } from any to (tun0) port { 30000:65000 }
----
TRANSLATION RULES:
nat on tun0 inet from 10.10.12.0/28 to any -> 91.122.40.4
FILTER RULES:
block drop in all
pass out all flags S/SA keep state
pass quick on vr0 all flags S/SA keep state
pass in on tun0 proto tcp from any to (tun0) port 30000:65000 keep state
pass in on tun0 proto udp from any to (tun0) port 30000:65000 keep state

TCP/IP : Протокол Internet v4 105/279


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

ICMP перенаправление отправляется маршрутизатором на узел, пославший


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

ICMP Тип:5 Код:0–3


ICMP Redirect message — сообщение о перенаправлении (0 — для сети; 1 —
для узла; 2,3 — TOS)

Листинг 20 — Linux 3.12.26 и FreeBSD 9.3


net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
---
net.inet.ip.redirect: 1
net.inet.icmp.drop_redirect: 1
net.inet.icmp.log_redirect: 1

TCP/IP : Протокол Internet v4 106/279


Маршрутизатор
абонента
2
.1
R
10.10.12.16/28 10.10.12.0/28 1 3

.19 .17 .14 .10


R

Рис. 28 — Перенаправление ICMP

Листинг 21 — Таблица маршрутизации по умолчанию


Destination Gateway Genmask Flags Iface
0.0.0.0 10.10.12.1 0.0.0.0 UG wlan0
10.10.12.0 0.0.0.0 255.255.255.240 U wlan0

Листинг 22 — Таблица маршрутизации после перенаправления


0.0.0.0 10.10.12.1 0.0.0.0 UG wlan0
10.10.12.0 0.0.0.0 255.255.255.240 U wlan0
10.10.12.16 10.10.12.14 255.255.255.240 UGD wlan0
TCP/IP : Протокол Internet v4 107/279
Фрагментация IP

Фрагментация — одна из важнейших функций модуля IP, которая позволяет


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

Последовательность:
При получении IP дейтаграммы для пересылки, IP модуль определяет,
на какой локальный интерфейс поступит дейтаграмма, и MTU
интерфейса;
Модуль IP сравнивает MTU с размером пересылаемой дейтаграммы и,
при необходимости, осуществляет фрагментацию.

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

TCP/IP : Протокол Internet v4 108/279


При фрагментации, IP дейтаграммы не собирается вновь до тех пор, пока не
достигнут конечного адреса назначения. Т. е. сборка исходной дейтаграммы
осуществляется модулем IP узла назначения. Поля заголовка IP, которые
используются в процессе фрагментации:
1 Идентификатор дейтаграммы (16 бит) — значение копируется в каждый
фрагмент конкретной датаграммы;
2 Поле флагов (3 бита):
001 — Далее следуют фрагменты (More Fragmets, MF). Значение
устанавливается для каждого фрагмента дейтаграммы, кроме последнего.
010 — Не фрагментировать (Do not Fragment, DF). Модуль IP не должен
фрагментировать дейтаграмму;
3 Поле смещения фрагмента (13 бит) — содержит смещение текущего
фрагмента от начала исходной дейтаграммы. При фрагментировании,
поле полной длины каждой фрагментированной дейтаграммы
изменяется, так чтобы соответствовать размеру фрагмента.

DF, не фрагментировать
Если длина дейтаграммы более MTU исходящего интерфейса, она должна
быть отброшена. При этом отправителю может быть послано ICMP
сообщение «необходима фрагментация, однако установлен бит не
фрагментировать» (fragmentation needed but don’t fragment bit set).
TCP/IP : Протокол Internet v4 109/279
Размножение дейтаграмм
При фрагментации каждый фрагмент становится дейтаграммой, с
собственным IP заголовком, и маршрутизируется независимо от других
пакетов. В связи с этим, возможно предположить, что дейтаграммы будут
прибывать адресату случайном порядке.

Избежать фрагментации
Если один фрагмент потерялся, дейтаграмма должна быт повторно передана
целиком. Из-за наличия промежуточного фрагментирования (например на
маршрутизаторе) не существует способа повторно передать только один
фрагмент дейтаграммы.

Листинг 23 — Отсылка дейтаграмм длиной 1528 байт


~> ping -s 1500 atlas
PING atlas (10.10.12.1) 1500(1528) bytes of data.
1508 bytes from atlas (10.10.12.1): icmp_seq=1 ttl=64 time=1.84 ms
1508 bytes from atlas (10.10.12.1): icmp_seq=2 ttl=64 time=1.98 ms
^C

TCP/IP : Протокол Internet v4 110/279


1528 байт

20 байт 8 байт 1500 байт

Заголовок Заголовок Данные


IP UDP приложения

1500 байт

Заголовок Заголовок Данные


IP UDP приложения

20 байт 8 байт 1472 байт

48 байт

Заголовок Данные
Заголовок
IP приложения
UDP

20 байт 28 байт

Рис. 29 — Схема фрагментации (MTU=1500 байт)

TCP/IP : Протокол Internet v4 111/279


Фрагмент 1
14 d6 4d a7 d4 fe 68 17 29 89 22 2c 08 00 45 00
05 dc 11 b0 20 00 40 01 17 58 0a 0a 0c 05 0a 0a
0c 01 .. .. .. .. .. .. .. .. .. .. .. .. .. ..

Flags <<MF>>: 001...


Frag offset: ...0000000000000
ID Frag: 4528
Фрагмент 2
14 d6 4d a7 d4 fe 68 17 29 89 22 2c 08 00 45 00
00 30 11 b0 00 b9 40 01 3c 4b 0a 0a 0c 05 0a 0a
0c 01 .. .. .. .. .. .. .. .. .. .. .. .. .. ..

Flags: 000...
Frag offset: ...0000010111001 (1480)
ID Frag: 4528
Рис. 30 — Пример полей фрагментированной дейтаграммы
TCP/IP : Протокол Internet v4 112/279
ICMP требование фрагментации
Данное ICMP сообщение может быть отправлено с транзитного
маршрутизатора, при необходимости фрагментирования дейтаграммы, в поле
флагов которой установлены биты 010 (DF).
ICMP Тип:3 Код:4
ICMP fragmentation needed message — сообщение о необходимости
фрагментирования.

Листинг 24 — ICMP сообщение с требованием фрагментирования


~> tcpdump -i wlan0 icmp -vvvlnnn -XX
IP (tos 0x0, ttl 64, id 56976, offset 0, flags [none], proto ICMP (1),\
length 56)
10.10.12.1 > 10.10.12.5:
ICMP 91.122.61.1 unreachable - need to frag (mtu 1492), length 36
IP (tos 0x0, ttl 2, id 0, offset 0, flags [DF], proto UDP (17),\
length 1500)
10.10.12.5.46485 > 91.122.61.1.44446: UDP, length 1472
6817 2989 222c 14d6 4da7 d4fe 0800 4500
0038 de90 0000 4001 701b 0a0a 0c01 0a0a
0c05 0304 786f 0000 05d4 4500 05dc 0000
4000 0211 c487 0a0a 0c05 5b7a 3d01 b595
ad9e 05c8 15bc
TCP/IP : Протокол Internet v4 113/279
§10

Протокол Интернет версии 6

Internet Protocol version 6

TCP/IP : Протокол Internet v6 114/279


Интермедиа: IPv5

Протокол IPv5 (Stream protocol 2, ST2) — экспериментальный,


«нестабильный» в терминах программирования протокол. Ориентирован на
потоковую передачу дейтаграмм. Часть алгоритмов ST2 реализованы в
многопротокольной коммутации по меткам (Multiprotocol Label Switching,
MPLS). Документация — RFC-3031.

IPv5 RFC
1 RFC-1190 «Experimental Internet Stream Protocol»
(Version 2 (ST-2), 1990);
2 RFC-1819 «Internet Stream Protocol» (Version 2 (ST2), 1995).

Структура заголовка ST2 отлична от IPv4;


Совместимая адресация IPv4;
Поле ethertype в заголовке кадра Ethernet: 0x0800;
Поле IP version в заголовке IP: 0x5

TCP/IP : Протокол Internet v6 115/279


IPv6: важные отличия от IPv4
Существенно расширенное адресное пространство —
2128 = 340 282 366 920 938 463 463 374 607 431 768 211 456 адресов;
В таблицах маршрутизации хранятся только агрегированные адреса
сетей, что уменьшает средний размер таблицы маршрутизации до 8192
записей;
Транзитные маршрутизаторы не выполняют фрагментацию. Для
зондирования MTU трассы, узел отправитель использует метод «Path
MTU discovery». Минимальный MTU сокращен до 1280 байт
(минимальное MTU для IPv4 — 576 байт);
Из заголовка IP исключено поле контрольной суммы — определение
целостности данных происходит только на канальном и транспортном
уровне;
IPv6 реализует автоконфигурирование (link-local address, RFC-2462);
Групповая рассылка дейтаграмм может выполняться только некоторым
участникам группы (узлы-доверители);
В структуру дейтаграммы IPv6 встроена поддержка IPsec
(аутентификация, проверка целостности и шифрование дейтаграммы);
TCP/IP : Протокол Internet v6 116/279
Типовой (регулярный) заголовок IPv6 имеет более простую структуру,
расширяемую за счет опциональных полей;
Минимальная длина заголовка в два раза длинее IPv4 — 40 байт;
Различным типам данных можно присваивать классы, благодаря полю
«класс трафика» в заголовке IPv6 дейтаграммы — это позволяет
обрабатывать данные в соответствии с заднным QoS;
Серия дейтаграмм IPv6 может быть объединена в поток,
идентифицируемый уникальной «меткой потока»;

Заголовок Основная открытая реализация протокола IPv6 — KAME


Сайт проекта: http://www.kame.net

TCP/IP : Протокол Internet v6 117/279


Дейтаграмма IPv6

Дейтаграмма IPv6 состоит из регулярного (обязательного) заголовка


фиксированного размера (40 байт) и дополнительного расширения,
имеющего переменную длину.

Поля дейтаграммы IPv6:


1 Версия протокола (4 бита);
2 Класс данных (Traffic class) — поле используется для определения типа
данных переносимых дейтаграммой (6 бит) и уведомления о перегрузке
(2 бита);
3 Метка потока (Flow label) — содержит псевдослучайное число,
генерируемое узлом отправителем. Метка задает правила обработки
серии дейтаграмм на маршрутизаторе. Все дейтаграммы относящиеся к
одному потоку должны иметь одинаковое значение метки (20 бит);
4 Длина пользовательских данных (Payload length) — содержит длину
полезной нагрузки без учета длины заголовка IPv6 (16 бит);

TCP/IP : Протокол Internet v6 118/279


5 Следующий заголовок (Next header) — значение поля указывает номер
заголовка вложенного в дейтаграмму. Следующим заголовком может
быть расширение основного заголовка IPv6 или заголовки
транспортного уровня (8 бит);
6 Предел транзитных переходов (Hop limit) — значение поля
ограничивает количество транзитных маршрутизаторов, через которые
может проследовать дейтаграмма (8 бит). Аналог поля TTL в заголовке
дейтаграммы IPv4;
7 Адрес источника (Source address) — 128 бит адреса отправителя
дейтаграммы;
8 Адрес назначения (Destination address) — 128 бит адреса получателя
дейтаграммы.

TCP/IP : Протокол Internet v6 119/279


Формат дейтаграммы IPv6
4 бита 8 бит 20 бит

0 3 4 11 12 15 16 23 24 31

Версия
протокола Класс данных Метка потока
IP

Длина дейтаграммы Номер заголовка


следующего протокола Hop limit (TTL)
(без заголовка)

IP адрес источника
40 байт

IP адрес назначения

Поле данных или подзаголовок IPv6

Рис. 31 — Формат основного заголовка дейтаграммы IPv6

TCP/IP : Протокол Internet v6 120/279


Расширенные заголовки IPv6
Расширенные заголовки аналогичны полям опций IPv4, но оформляются
в виде отдельных подзаголовков дейтаграммы и размещены между
регулярным заголовком и заголовком протокола более высокого уровня
(ICMP, TCP и т. д.);
Размер каждого расширенного заголовка кратен 8;
Тип расширенного заголовка определяется в поле Next header
регулярного заголовка IPv6. Каждый расширенный заголовок имеет
поле «Next header», в котором хранится тип следующего заголовка;
Поле «Next header» последнего расширенного заголовка содержит
номер протокола транспортного уровня.
Обработка подзаголовков

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


Исключение — подзаголовок транзитных опций (Hop-By-Hop options),
который обрабатывается каждым транзитным узлом.

Если узел не способен обработать расширенный заголовок IPv6, то


дейтаграмма отбрасывается. Для уведомления об ошибке формируется
сообщение ICMPv6 «Parameter problem» (Тип 4, код 1).
TCP/IP : Протокол Internet v6 121/279
Список подзаголовков IPv6

Тип Подзаголовок Назначение


0 Транзитные опции (Hop-by-hop Транзитные параметры
options) для обработки на каждом
маршрутизаторе
60 Опции узла назначения Параметры передаваемые узлу
(Destination options) назначения
43 Опции маршрутизации (Routing Список транзитных узлов
options) маршрутизации (IPv4:
маршрутизация от источника)
44 Параметры фрагментации Параметры фрагментации
(Fragment options) текущей дейтаграммы
51 Подзаголовок аутентификации Параметры IPsec для
(Authentification header) аутентификации дейтаграммы
50 Параметры шифрованния Параметры шифрования данных
данных (Encapsulating security помещенных в дейтаграмму IPv6
payload) (IPsec)

TCP/IP : Протокол Internet v6 122/279


Обработка подзаголовков на транзитных узлах

Дейтаграмма IPv6

Next header:17
Next header:43
Next header:0

Подзаголовок Подзаголовок
Заголовок Заголовок Заголовок
Hop-by-hop Routing options
Ethernet IPv6 UDP
options
Расширение заголовка IPv6
14 байт 40 байт
Заголовок IPv6

R1 R2 R3
Рис. 32 — Обработка дейтаграммы с подзаголовком Hop-by-hop options

TCP/IP : Протокол Internet v6 123/279


Обработка подзаголовков на транзитных узлах

Дейтаграмма IPv6

Next header:17
Next header:44

Подзаголовок
Заголовок Заголовок Подзаголовок Заголовок
Hop-by-hop
Ethernet IPv6 Fragment options UDP
options

14 байт 40 байт Расширение


заголовка IPv6

R1 R2 R3

Рис. 33 — Обработка дейтаграммы без подзаголовка Hop-by-hop options

TCP/IP : Протокол Internet v6 124/279


Адресная нотация IPv6
Регулярный IPv6 адрес имеет длину 128 бит и hex-форму записи
x:x:x:x:x:x:x:x. Каждый блок между знаками двоеточия (:x:)
определяет 16 бит адреса.

febc:a574:382b:23c1:aa49:4592:4efe:9982

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


серию нулей в адресе:

fe80::1→fe80:0000:0000:0000:0000:0000:0000:0001
fe80::382b:0000:0000:4efe:0001→
fe80:0000:0000:382b:0000:0000:4efe:0001

Иногда используется классическая IPv4 десятичная запись для последних 4


байт:
fc00:0000:0000:0000:0000:0000:0a0a:0c01→
fc00::10.10.12.1

TCP/IP : Протокол Internet v6 125/279


Типы адресов IPv6
Существует несколько типов адресов IPv6:
1 Одноадресатный тип (unicast) — любая дейтаграмма отправленная на
данный адрес, в точности достигает сетевого интерфейса с указанным
адресом;
2 Групповой тип (anycast) — могут использоваться только
маршрутизаторами. Аналогичны одноадресатному типу, но могут
адресовать целую группу сетевых интерфейсов. Любая дейтаграмма
отправленная на данный адрес, достигнет ближайшего (учитывая
метрику маршрута) сетевого интерфейса назначенного адресата;
3 Многоадресатный тип (multicast) — также определяют группу
интерфейсов, но любая дейтаграмма отправленная на данный адрес
будет доставлена на все интерфейсы, включенные в многоадресатную
группу.

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


информация описана в RFC-3513.

TCP/IP : Протокол Internet v6 126/279


Одноадресатные типы (unicast) адресов

1 Глобальный одноадресатный адрес — адреса вида 2000::/3,


аналогичны глобально маршрутизируемым адресам IPv4;
2 Локальный одноадресатный адрес (link-local) — используется для
автоконфирурирования адреса на сетевом интерфейсе fe80::/10.
Аналогичны диапазону 169.254.0.0/16;
3 Внутренние одноадресатные адреса (Uniquie link-local) — диапазон
fc00::/7, используется в качестве внутренних (частных) адресов не
поддерживающих глобальную маршрутизацию. Аналог в IPv4 —
диапазоны 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16;

TCP/IP : Протокол Internet v6 127/279


Многоадресатные типы (multicast) адресов

1 Назначенные адреса (assigned multicast address) — зарезервированные


многоадресатные адреса для определённых групп устройств.
Дейтаграмма, отправленная на такой адрес, будет доставлена всем
устройствами, входящим в группу.
2 Запрошенные адреса (solicited multicast address) — многоадресатные
адреса, которые могут использоваться устройствами для прикладных
задач. Адрес такого типа конфигурируется системой автоматически,
когда на сетевом интерфейсе устанавливается любой одноадресатный
адрес.
Адрес формируется из диапазона: ff02:0:0:0:0:1:ff00::/104, где
последние 24 бита копируются у unicast-адреса интерфейса.

TCP/IP : Протокол Internet v6 128/279


Зарезервированные адреса IPv6
Адрес/префикс Назначение Замечания
::/128 Адрес не определен IPv4: 0.0.0.0
::1/128 Интерфейс lo IPv4: 127.0.0.1
::00:xx:xx:xx:xx/96 Встроенные диапазон Младшие 32 бита
IPv4 адресов заняты совместимыми
адресами IPv4
::ff:xx:xx:xx:xx/96 IPv4 адреса Для узлов не
отображенные в поддерживающих
формате IPv6 адреса IPv6
fe80::–feb::/10 Локальные IPv4: 169.254.0.0/16
адреса для
автоконфигурирования
fec0::–fef::/10 Внутренние IPv4: 10.0.0.0/8,
(частные) адреса 172.16.0.0/12,
192.168.0.0/16
ff::/8 Многоадресатные
адреса
0012 /3 Глобальные адреса
IPv6
TCP/IP : Протокол Internet v6 129/279
Листинг 25 — IPv6 адрес (FreeBSD 9.3)
#> ifconfig
rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,
SIMPLEX,MULTICAST>
mtu 1500
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::200:21ff:fe03:8e1
ether 00:00:21:03:08:e1
media: Ethernet autoselect (100baseTX)
status: active

Откуда получен данный адрес IPv6?

Данный адрес сконфигурирован автоматически с помощью части


аппаратного адреса:
inet6 fe80::200:21ff:fe03:8e1
ether 00:00:21:03:08:e1

TCP/IP : Протокол Internet v6 130/279


Интермедиа: подключение к сетям IPv6

Интернет-провайдер предоставляет подключение с адресом IPv6;


Установка туннеля через брокера www.sixxs.net;
Установка туннеля через брокера www.tunnelbroker.net;
Туннелирование по принципу 6-to-4 (RFC-3068);
Коммутируемое подключение через шлюз freenet6
(http://www.gogo6.com/freenet6).

TCP/IP : Протокол Internet v6 131/279


Практические детали IPv6

Отображение IPv4/IPv6

Опция отображения адресов IPv4 в формате IPv6 предназначена


для сохранения совместимости сетевых приложений. Данная опция
позволяет приложениям IPv6 взаимодействовать с сетевым ПО
предназначенным для работы в IPv4, когда одновременно используется
двойной стек протоколов IPv4/IPv6.

Описание опции и принцип отображения приведен в RFC-3493 и


RFC-4038.

Листинг 26 — rc.conf (FreeBSD 9.3)


ipv6_ipv4mapping="YES"

TCP/IP : Протокол Internet v6 132/279


Статическое назначение адреса

Сетевой интерфейс может иметь статический (постоянный) адрес IPv6


и адрес дежурного маршрутизатора.

Листинг 27 — rc.conf (FreeBSD 9.3)


ifconfig_fxp0_ipv6="inet6 2001::5344 prefixlen 64"
ipv6_defaultrouter="2001:db8:4672:6565::1"

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


IPv6 с помощью сообщений ICMPv6 о периодическом объявлении (анонсе)
маршрутизатора (router advertisment). Для поддержки автоматического
конфигурирования посредством сообщений с анонсом маршрутизатора
необходимо запустить службу (демона) обнаружения маршрутизатора (router
solicitation).

Листинг 28 — rc.conf (FreeBSD 9.3)


ifconfig_re0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"

TCP/IP : Протокол Internet v6 133/279


Туннельный интерфейс IPv6

При подключении к сетям IPv6 через брокеров необходимо


использовать туннелирование.

Туннель — программный интерфейс, соединение по которому


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

Листинг 29 — Cоздание туннельного интерфейса (FreeBSD 9.3)


gif_interfaces="gif0"
gifconfig_gif0="178.16.100.26 91.122.61.174"
ifconfig_gif0_ipv6="inet6 2001::5344 prefixlen 64"
ipv6_defaultrouter="2001:db8:4672:6565::1"

TCP/IP : Протокол Internet v6 134/279


Планирование подсетей IPv6
Наследование
Принципы разработки плана адресации в сетях IPv6 практически
польностью наследуются из методов описанных для сетей IPv4. Однако
существуют некоторые нюансы.

Из-за возросшей емкости адресного пространства нет необходимости


использовать подсети с локальными адресами;
Глобально маршрутизируемые адреса доступны всем узлам в подсети
без использования транслирующих шлюзов и прокси;
Региональные распределители (Regional Internet Registry, RIR)
выделяют блоки с сетевым префиксом /32;
Для конечных систем по-умолчанию выделяется адрес с сетевым
префиксом /64;
При необходимости построения большего количества подсетей может
быть получен адресный блок с префиксом /56 или /48.

Основные документы RFC-4291, RFC-3177, RFC-6177.

TCP/IP : Протокол Internet v6 135/279


Пример планирование подсетей IPv6

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


2001:db8:beff::/48. Запишем данный блок в полном виде:

2001:0db8:beff:0000:0000:0000:0000:0000

Первые 48 бит определяют сеть IPv6. Для адресации подсетей можно


использовать 16 бит, реализуя таким образом 65536 подсетей с
18446744073709551616 адресам в каждой подсети. Вычислим возможные
адреса подсетей, представив байты 7 и 8 (слева) в двоичном виде:

0000 — 0000 0000 0000 0000


0001 — 0000 0000 0000 0001
...
01ff — 0000 0001 1111 1111
...
afff — 1010 1111 1111 1111
...
ffff — 1111 1111 1111 1111
TCP/IP : Протокол Internet v6 136/279
Например, подсеть 2001:db8:beff:afff:/64 включает следующие
адреса:

2001:0db8:beff:afff:0000:0000:0000:0000
2001:0db8:beff:afff:0000:0000:0000:0001
2001:0db8:beff:afff:0000:0000:0000:0002
...
2001:0db8:beff:afff:0000:0000:0000:ffff
2001:0db8:beff:afff:0000:0000:0000:ffff
...
2001:0db8:beff:afff:0000:0000:afff:ffff
...
2001:0db8:beff:afff:ffff:ffff:ffff:ffff

TCP/IP : Протокол Internet v6 137/279


ICMP — Internet Control Message Protocol

Протокол ICMP представляет собой часть реализации стека TCP/IP.


Средствами ICMP передаются сообщения об ошибках и сообщения о
возникновении условий и ситуаций, которые требуют к себе особого
внимания. ICMP сообщения обрабатываются IP уровнем или более
высокими уровнями (TCP или UDP). При появлении некоторых ICMP
сообщений генерируются сообщения об ошибках, которые передаются
пользовательским процессам.

Заголовок
Сообщение ICMP
IP

Рис. 34 — Инкапсуляция ICMP в дейтаграмму IP

ICMP RFC
Официальная спецификация ICMP — RFC-792

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 138/279


8 бит 8 бит 16 бит

Тип
Код Контрольная сумма
сообщения

Содержимое сообщения

Рис. 35 — Дейтаграмма ICMP

Структура сообщений
Первые 4 байта дейтаграммы ICMP одинаковы для всех сообщений,
остальные отличаются в зависимости от типа сообщения.

Существует 15 различных значений для поля типа (Type), которые


указывают на конкретныей тип ICMP сообщения;
ICMP сообщения одного типа могут иметь различные значения в поле
кода (Code);
Поле контрольной суммы рассчитывается по всей длине ICMP
дейтаграммы. Алгоритм расчета аналогичен алгоритму расчета
контрольной суммы для заголовка IP.
TCP/IP : Управление дейтаграммами Internet и протокол ICMP 139/279
Типы сообщений ICMP

Существует два вида сообщений ICMP:


ICMP сообщение запрос (query);
ICMP сообщение ошибка (error).

Сообщение об ошибке и дейтаграмма IP


Cообщение об ошибке всегда содержит IP заголовок и первые 8 байт IP
дейтаграммы, которая вызвала генерацию ICMP ошибки.

Это позволяет принимающему ICMP модулю установить соответствие


между полученным сообщением, одним из конкретных протоколов (TCP,
UDP и т. д.) и пользовательским процессом.

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 140/279


Ответ на ошибки
Сообщение об ошибке ICMP никогда не генерируется в ответ на. . .
. . . ICMP сообщение об ошибке;
. . . дейтаграмму, направляющуюся на широковещательный или
групповой адрес IP;
. . . дейтаграмму, которая посылается широковещательным запросом на
канальном уровне;
. . . фрагмент дейтаграммы IP, который не является первым (т. е. поле
«Смещение» (offset) в заголовке IP не равно нулю);
. . . дейтаграмму, адрес источника которой не указывает на конкретный
узел — нулевой (0.0.0.0), loopback (127.0.0.0/8) ,
широковещательный или групповой адрес (224.0.0.0/4).

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 141/279


Наиболее важные сообщения ICMP

Тип Код Назначение


0 0 Эхо-отклик (echo reply)
Тип «Назначение недоступно» (destination unreachable):
0 Сеть недоступна (network unreachable)
1 Хост недоступен (host unreachable)
2 Протокол недоступен (protocol unreachable)
3
3 Порт недоступен (port unreachable)
4 Необходима фрагментация, однако установлен бит
DF (fragmentation needed but DF bit set)
.............................
13 Связь административно закрыта путем
фильтрации (communication administratively
prohibited by filtering)
Тип «Перенаправление» (redirect):
5 0 Перенаправление в сеть (redirect for network)
1 Перенаправление на хост (redirect fot host)
8 0 Эхо-запрос (echo request)

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 142/279


Тип Код Назначение
9 0 Объявление маршрутизатора (router
advertisement)
10 0 Запрос маршрутизатора (router solicitation)
Тип «Время истекло» (time exceeded):
11
0 Время жизни стало равным 0 в процессе передачи
(time-to-live equals 0 during transit)
................................

Дейтаграмма IP

Сообщение ICMP

Раздел данных в ICMP сообщений

Заголовок IP дейтаграммы,
Заголовок Заголовок Заголовок Заголовок
которая сгенерировала
Ethernet IP ICMP UDP
ошибку

14 байт 20 байт 8 байта 8 байта

20 байт

Рис. 36 — Инкапсуляция заголовка дейтаграммы IP, вызвавшего ошибку

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 143/279


Пример ICMP: ошибка недоступности порта
Если транспортный модуль ОС принимает дейтаграмму, порт назначения
которой не соответствует ни одному обслуживаемому приложением
(активному) порту, то транспортный модуль генерирует ICMP сообщение о
недоступности порта (port unreachable).

Листинг 30 — Подключение на необслуживаемый порт (atftp)


~> atftp
tftp> connect 10.10.12.1 1000
tftp> get ios_3640.image
timeout: retrying...
timeout: retrying...
tftp: aborting
tftp>

Листинг 31 — Пример ICMP «port unreachable» (tcpdump)


~> sudo tcpdump -vvvln -i wlan0 icmp
listening on wlan0, link-type EN10MB (Ethernet) capture size 65K bytes
IP(ttl 64,id 34062,offset 0,flags [none],proto ICMP (1),length 56)
10.10.12.1>10.10.12.5: ICMP 10.10.12.1 udp port 1000 unreachable
-:IP(ttl 64,id 15286,offset 0,flags [DF],proto UDP (17),length 51)
-:10.10.12.5.57310 > 10.10.12.1.1000: UDP, length 23

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 144/279


ICMPv6: управляющие сообщения IPv6
ICMPv6 RFC
Описание управляющих сообщений для IPv6 определено в RFC-4443.

Принцип исполнения протокола аналогичен определениям данным для


ICMP IPv4. Однако, за счет включения в протокол функций ARP, ICMPv6
расширяет протокол предыдущей версии. Код заголовка в поле дейтаграммы
IPv6 Next header — 58.
Формат дейтаграммы ICMP
Формат дейтаграммы и назначение полей полностью унаследовано от
предыдущей версии (см. рис. ??), но изменен алгоритм расчета контрольной
суммы, который включает псевдозаголовок IPv6.

Все сообщения ICMPv6 образуют два класса — «сообщения об ошибках» и


«информационные сообщения»:
Сообщения об ошибках имеют тип 0–127 (старший бит в поле
заголовока тип равен 0);
Информационные сообщения имеют тип 128–255;
TCP/IP : Управление дейтаграммами Internet и протокол ICMP 145/279
Сообщения ICMPv6
Тип Код Назначение
Тип «Назначение недоступно»:
0 Нет маршрута до места назначения
1 1 Связь с адресатом административно прикрыта
2 Не сосед
3 Адрес не достижим
4 Порт не достижим
2 0 Пакет слишком велик (MTU)
Тип «Превышено время»
3 0 При передаче превышен лимит числа транзитных
узлов (Hop Limit)
1 Превышено время восстановления сообщения из
фрагментов
Тип «Конфликт параметров»
0 Встретилась ошибка в поле заголовка
4
1 Встретился неопознанный код поля Next header
2 Встретилась неопознанная опция IPv6
128 0 Эхо-запрос
129 0 Эхо-отклик
TCP/IP : Управление дейтаграммами Internet и протокол ICMP 146/279
Приложения и утилиты ICMP I

1 ping — утилита предназначена для проверки доступности удаленного


хоста. Программа отправляет ICMP сообщение «эхо-запрос» на хост и
ожидает возврата ICMP сообщения «эхо-отклика». С помощью утилиты
ping можно оценить время возврата пакета от удаленного узла RTT —
Round Trip Time. Для работы с IPv6 используется утилита ping6.
Руководство — man ping, Р. Стивенс Протоколы TCP/IP (Глава 7);
2 traceroute — утилита позволяет выявить маршрут, по которому
пересылаются IP дейтаграммы от одного узла к другому. Используется
поле TTL заголовка IP и сообщения ICMP «не доступен порт
назначения». Руководство — man traceroute, Р. Стивенс Протоколы
TCP/IP (Глава 8);
3 tracepath — утилита предназначена для определения MTU
транзитных участков, MTU трассы и построения списка транзитных
узлов. Использует дейтаграммы IP с флагом DF, переменный MTU и
сообщение ICMP «требуется фргаментация, но установлен флаг DF».
Руководство — man tracepath, Р. Стивенс Протоколы TCP/IP
(Глава 11);

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 147/279


Приложения и утилиты ICMP II

4 mtr — my traceroute, расширение утилиты traceroute, с


псевдографическим текстовым интерфейсом. Утилита позволяет следить
за обновлением маршрута в интерактивном режиме. Руководство — man
mtr;
5 tracemap — скрипт-программа на языке Perl, предназначенная для
визуализации маршрутной трассы. Работа скрипта основывается на
выполнении программы traceroute к нескольким узлам, заданным в
качестве аргументов. Вывод и построение карты маршрута реализовано
с помощью библиотеки векторной графики graphviz.
...
@prefixes=load_prefixes();
for $dest (@dests)
{
say("Tracing path to $dest");
open (TRACE,"traceroute $traceroute_options $dest|")
or die "Can’t run traceroute:$!";
my $hop=’’;
$ttl=0;
...

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 148/279


b.root-servers.net
asia.pool.ntp.org 4.69.155.81

1.08
0.32 4.69.134.70
12.122.131.94 140.109.255.214
198.172.117.163 h.root-servers.net
0.58
129.250.5.86
4.69.137.78

202.169.174.78 138.18.1.3 138.18.21.54


6.74
40.86 2.74
221.28 4.69.143.142 75.55
0.57
152.179.75.130
europe.pool.ntp.org 138.18.49.25
south-america.pool.ntp.org 1.47

9.03 152.63.36.210
202.169.174.146 4.69.148.193 6.45 152.63.40.81
22.45
129.250.4.4
80.64.128.171 0.05 3.12
4.69.158.37 4.68.62.134
9.81 129.250.9.206 4.69.140.29
190.220.179.197
0.53 4.69.140.1
80.64.128.249 77.52
4.69.143.222 1.44
28.30
11.55
187.174.64.17 123.35 129.250.4.69 4.69.154.62
82.91
8.05
4.69.137.58
6.18 129.250.3.180 3.12
14.97
129.250.3.20 4.69.143.138
157.238.179.126
193.203.0.81 4.69.140.13
129.250.2.111
202.40.161.227 4.69.154.254
94.80 l.root-servers.net
128.25
212.162.19.29

6.29
africa.pool.ntp.org 0.40 3.43
8.38
41.216.193.81 193.232.226.250
0.22
129.250.2.13 129.250.4.162
0.03 194.226.29.34 1.42
87.245.233.54
-129.42 ripn.net
129.250.5.217 0.06 87.245.232.138 87.245.233.138
185.99 0.69 4.38

0.45 72.52.92.81
213.198.77.213 opds.sut.ru 194.190.255.106
216.66.84.250 0.60 193.232.188.17 130.09
7.24 87.245.232.150 212.188.29.138
72.52.92.45
sut.ru
3.35 194.226.100.33
170.04 0.15
24.83 39.51 194.85.40.217
100.94 0.74 0.23
59.13 3.54
149.6.141.9 194.68.123.187 47.05 194.85.40.137 7.49
154.54.40.62
75.103.237.110 0.58 17.47 194.85.40.146
128.8.0.229 212.188.28.174
6.50 194.146.105.187
2.32 194.190.254.53
1.60 154.54.42.121 0.78 178.18.224.11
0.62 12.35
38.104.236.106 87.245.233.134 0.82 j.root-servers.net 8.31
0.25
d.root-servers.net 77.72.228.46
13.88
i.root-servers.net 194.68.123.73
87.245.251.21 55.32 87.245.232.102
91.210.16.63

0.30 92.62.48.173 7.18


14.16 193.232.246.140
0.40 212.188.28.142
0.58 0.15 11.92
113.69
198.32.160.42 40.26
188.65.69.65 212.188.18.93 f.root-servers.net 0.18
0.66
0.77 117.97
87.245.233.114 212.188.42.58 193.232.87.51
0.68 195.34.53.189
86.59 188.65.69.54 42.66
206.132.169.206 198.32.160.214
1.14 87.245.233.126
2.56 k.root-servers.net
195.34.59.49
1.30 1.42 2.04 212.188.29.82
2.80 195.34.53.193
198.32.160.95 darkstar.su
66.192.241.38
72.56 195.66.225.238
203.29.135.33 202.7.162.246
149.20.65.137 0.68 188.65.69.82
7.92 87.245.232.118 212.188.1.185
206.132.169.249 2.11 195.34.53.138
3.59 77.78 134.23
77.77 0.03
0.78 0.20
103.82 206.126.236.198 2.48 0.77 66.162.129.150
e.root-servers.net 212.188.1.194 195.34.59.114
1.61
kernel.org 68.1.1.7 188.65.64.77 212.188.1.190
0.46
iana.org ripe.net
195.34.59.45
10.40.91.5 212.188.42.90
0.03 206.132.169.161 8.05 16.81
206.223.115.205 195.66.224.198 3.11
58.138.80.114 32.29
8.92 30.86
210.173.176.242
3.29 4.06

92.62.48.162 31.12
m.root-servers.net icann.org
98.172.152.14
188.65.69.45 212.188.42.22
130.18
195.34.53.102
192.149.252.131 180.82 203.194.59.191 16.18
saturn.darkstar.su 1.33
80.81.192.245
188.65.69.6
apnic.net
opds.sut.ru arin.net 195.34.53.58 195.69.146.82

193.232.188.17 2.23 0.66


1.34

201.48.46.174

sut.ru
50.97.18.213
199.16.95.114
149.6.141.97
0.71 -0.09
168.209.201.62 199.7.71.158
194.226.100.33 201.48.44.6
0.29
5.97
168.209.1.168
2.29
-4.49
0.74
3.54 196.37.155.180
a.root-servers.net
10.27 50.97.18.210
154.54.61.165 0.03
0.03
17.47 4.61 154.54.36.218 50.97.18.206

201.48.44.14
130.117.2.222
69.53
178.18.224.11
196.216.3.132
87.245.251.21 11.69
c.root-servers.net
50.97.18.204

55.32 87.245.232.102 afrinic.net


201.48.44.93

0.30 92.62.48.173 187.32.53.69 19.53


173.192.18.132

173.192.18.171

TCP/IP : Управление дейтаграммами Internet и протокол ICMP 149/279


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

Расширенные функции транспортных протоколов:


Установить перманентное логическое соединение между удаленными
узлами;
Определить последовательность передачи прикладных данных;
Обеспечить обнаружение ошибок и контроль целостности.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 150/279


Протокол FTP
FTP клиент FTP сервер

TCP модуль Протокол TСP TCP модуль


ядра ОС ядра ОС
Протокол IP Протокол IP

IP модуль IP модуль IP модуль


ядра ОС ядра ОС ядра ОС
Протокол Протокол
Ethernet Token Ring

Драйвер Драйвер Драйвер Драйвер


Ethernet Ethernet Token Ring Token Ring

Среда передачи сигналов Ethernet Среда передачи сигналов Token Ring

Рис. 37 — Взаимодействие удаленных процессов)

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 151/279


Механизм связывания приложений
Механизм связывания удаленных приложений основан на применении
«сокетов» (sockets — гнезда).

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


прикладной службы: IP:port. Длина адреса IPv4 составляет 32 бита,
длина номера порта 16 бит (0–65535).
Набор характеризующий узел отправителя, узел получателя и прикладные
процессы с номерами портов принято называть «кортежем»:
Source-IP:Source-port::Destination-IP:Destination-Port.

Назначение номера порта


Каждой сетевой прикладной службе назначается номер транспортного порта.
Стандартизированным приложениям, которые поддерживаются IEEE и IETF
назначаются официальные номера портов из списка IANA (Internet Assigned
Numbers Authority). Список официально закрепленных
(зарегистрированных) портов —
http://www.iana.org/assignments/port-numbers.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 152/279


Существует по крайней мере три диапазона транспортных портов:
1 Системные номера портов — диапазон значений 0–1023. Закреплены за
стандартизированными службами Internet — WWW (80), FTP (20, 21),
TELNET (23) и т. д. Распределяются организацией IANA («Well known
ports»), при использовании прикладными процессами требуют особых
прав и привилегий суперпользователя (или администратора).
Практически полностью принадлежит серверным приложениям;
2 Пользовательские номера портов — диапазон значений 1024–49151.
Частично занят зарегистрированными в IANA службами и
приложениями сторонних разработчиков, например —WINS (1512),
RADIUS (1812), Subversion (3690) и т. д. Данный диапазон
используется некоторыми серверными и практически всеми известными
клиентскими приложениями;
3 Номера портов выделяемые по запросу — диапазон значений
49152–65535. Не зарегистрированный диапазон, предназначенный для
динамического выделения портов ОС сетевым приложениям по запросу.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 153/279


Листинг 32 — Файл /etc/services
# Network services, Internet style
# Some References:
# http://www.iana.org/assignments/port-numbers
# http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services
# Each line describes one service, and is of the form:
# service-name port/protocol [aliases ...] [# comment]
#
# IANA Assignments [Well Known Ports]
# The Well Known Ports are assigned by the IANA and on most systems can
# only be used by system (or root) processes or by programs executed by
# privileged users.
# The range for assigned ports managed by the IANA is 0-1023.
#
tcpmux 1/tcp # TCP port service multiplexer
tcpmux 1/udp
...
echo 7/tcp # Echo
echo 7/udp
...
qotd 17/tcp # Quote of the Day
qotd 17/udp
...
ftp-data 20/tcp # File Transfer [Default Data]
ftp-data 20/udp

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 154/279


Основные транспортные протоколы I

В семействе протоколов TCP/IP существует несколько транспортных


протоколов:
UDP — Протокол передачи пользовательских дейтаграмм (User
Datagram Protocol). Простейший протокол транспортного уровня,
RFC-768;
TCP — Протокол управления передачей дейтаграмм (Transmission
Control Protocol). Базовый транспортный протокол стека Internet,
RFC-793;
TCPCrypt — Расширение протокола TCP реализующее шифрование
данных. Обратно совместим со стандартной реализацией, спецификация
находится в состоянии черновика («internet-draft»),
URL:http://www.ietf.org/id/draft-bittau-tcpinc-01.txt;
SCTP — Протокол управления потоковой передачей дейтаграмм (Stream
Control Transmission Protocol). Основан на TCP, но поддерживает
многопоточность и транкинг логического соединения с использованием
нескольких каналов передачи данных, описание дано в RFC-4690;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 155/279


Основные транспортные протоколы II

DCCP — Протокол управления очередями дейтаграмм (Datagram


Congestion Control Protocol). Предоставляет возможность установления
двунаправленных одноадресатных соединений с помощью дейтаграмм
UDP и контролируемых очередей. Узкоспециализированный протокол,
предназначенный для обработки очередей и накоплений дейтаграмм.
Теоретически востребован в приложениях реального времени, однако
реализован только в сетевой инфраструктуре ядра Linux. Описание
протокола приведено в RFC-4340;
RDP — Надежный транспортный протокол передачи данных (Reliable
Data Protocol). Может рассматриваться как существенно упрощенный
вариант реализации TCP, поскольку обеспечивает управление
логическим соединением, подтверждение передачи данных и повторную
пересылку. Описание дано в RFC-1151.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 156/279


Протокол передачи пользовательских дейтаграмм
UDP — простой протокол транспортного уровня ориентированный на
передачу дейтаграмм (connectionless). За один такт обработки данных
процесс выдает одну UDP дейтграмму, в результате чего передается одна IP
дейтаграмма. Номер протокола следующего уровня (Protocol) в заголовке
IP — 17.
Дейтаграмма IP

Дейтаграмма UDP

Заголовок Заголовок Заголовок Данные приложения


Ethernet IP UDP

14 байт 20 байт 8 байта

Рис. 38 — Инкапсуляция UDP

Unreliable Datagram Protocol


UDP является «ненадежным» протоколом — он не поддерживает механизмов
определения доставки сообщения до процесса на адресуемом узле.
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 157/279
Службы Internet использующие UDP
Номер порта Служба Описание
7 echo Сетевое эхо
53 nameserver Служба доменных имен
67 dhcps (bootps) Сервер службы DHCP
68 dhcpc (bootpc) Клиент службы DHCP
69 tftp Сервер простейшего протокола
передачи файлов
88 kerberos Служба аутентификации Kerberos
123 ntp Служба синхронизации сетевого
времени
161 snmp Служба протокола сетевого
управления

Основная область применения


Основное назначение протокола UDP — перенос данных службы Domain
Name System и Trivial FTP. Протокол UDP может служить «оберткой» для
приложений более высокого уровня. Как правило, сервер использующий
UDP выполняет обработку запросов в последовательном режиме (см. 1).
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 158/279
Формат дейтаграммы UDP

Дейтаграмма UDP имеет регулярную структуру и постоянную длину


заголовка:
1 Порт источника (Source port) — поле содержит номер транспортного
порта, с которого отправляется дейтаграмма (16 бит);
2 Порт назначения (Destination port) — поле содержит номер
транспортного порта, на который необходимо доставить дейтаграмму
(16 бит). Номер порта назначения используется для
демультиплексирования данных на адресуемом узле;
3 Длина дейтаграммы (UDP length) — поле содержит длину (в байтах)
заголовка и данных UDP. Длина поля — 16 бит. Минимальное
значение для этого поля составляет 8 байт;
4 Контрольная сумма (UDP checksum) — Значение в поле контрольной
суммы (длиной 16 бит) UDP охватывает заголовок и данные UDP.
Алгоритм расчета аналогичен алгоритму расчета контрольной суммы
для заголовка IP, однако необходимо учитывать наличие
псевдозаголовка UDP.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 159/279


16 бит 16 бит

0 15 16 31

Номер порта Номер порта


источника назначения
8 байт

Длина дейтаграммы Контрольная сумма

Данные

Рис. 39 — Формат дейтаграммы UDP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 160/279


Листинг 33 — Пример дейтаграммы UDP
~> sudo tcpdump -i wlan0 -lvvvn -e -XX udp
0x0000: 14d6 4da7 d4fe 6817 2989 222c 0800 4500
0x0010: 003c cffa 4000 4011 3e9d 0a0a 0c05 0a0a
0x0020: 0c01 b745 0035 0028 6617 c36b 0100 0001
0x0030: 0000 0000 0000 0a72 6164 696f 636f 6465
0x0040: 7203 6e65 7400 0001 0001

Анализ
Указатель протокола транспортного уровня в заголовке IP 0x11 — UDP
(17);
0xb745 — порт источника дейтаграммы (46917);
0x0035 — порт назначения дейтаграммы (53);
0x0028 — длина дейтаграммы UDP (40 байт);
0x6617 — Контрольная сумма дейтаграммы.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 161/279


Алгоритм расчета контрольной суммы UDP I

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

Контрольная сумма UDP рассчитывается аналогично алгоритму расчета


контрольной суммы заголовка IP (сумма 16 битных слов с переносом);
Если UDP дейтаграмма состоит из нечетного количества байт, при
расчете контрольной суммы на передатчике и приемнике, в конец
дейтаграммы добавляются нулевые байты заполнения (байты
заполнения не передаются);
Для расчета контрольной суммы UDP формируется псевдозаголовок IP
длиной 12 байт. Псевдозаголовок используется для проверки того, что
данные достигли именно адресуемого узла;
Если рассчитанная контрольная сумма равна 0, значение инвертируется
и поле КС заполняется единицами;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 162/279


Алгоритм расчета контрольной суммы UDP II

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


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

Отключенная КС
На некоторых системах, расчет контрольной суммы UDP может быть
отключен по умолчанию. Это делается в целях повышения
проивзодительности сетевого приложения, например, при интенсивном
обмене данными по протоколу сетевой файловой системы NFS (Network File
System).

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 163/279


0 78 15 16 31

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

IP адрес назначения
Destination address

Заполнитель Протокол Длина UDP


Zero Protocol UDP Length

Рис. 40 — Формат псевдозаголовка IP для расчета КС UDP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 164/279


Листинг 34 — Дейтаграмма UDP
14 d6 4d a7 d4 fe 00 1f d0 59 4e b5 08 00 45 00
00 3d 8f 47 40 00 40 11 7f 4c 0a 0a 0c 08 0a 0a
0c 01 ec 16 00 35 00 29 ** ** ff 3f 01 00 00 01
00 00 00 00 00 00 03 66 74 70 08 64 61 72 6b 73
74 61 72 02 73 75 00 00 1c 00 01

Листинг 35 — Заголовок IP
45 00 00 3d 8f 47 40 00 40 11
7f 4c 0a 0a 0c 08 0a 0a 0c 01

Листинг 36 — Заголовок UDP


ec 16 00 35 00 29 ** **

Листинг 37 — Данные UDP


ff 3f 01 00 00 01 00 00 00 00 00 00 03 66 74 70 08
64 61 72 6b 73 74 61 72 02 73 75 00 00 1c 00 01

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 165/279


0 78 15 16 31

0x0A0A0C08
Source address

0x0A0A0C01
Destination address

0x00 0x11 0x0029


Zero Protocol UDP Length

Рис. 41 — Псевдозаголовок IP для полученной дейтаграммы

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 166/279


Манипуляции на передаче

0a 0a 16 12 20 1c 2c 1d 2c 2e 2c 57 ... dc 06
+ 0c 08 + 0a 0a + 0c 01 + 00 11 + 00 29 + ec 16 ...+ 01 00
16 12 20 1c 2c 1d 2c 2e 2c 57 18 6e ... dd 06

0xDD06 → 1101 1101 0000 0110


0010 0010 1111 1001 → 0x22F9

Манипуляции на приеме

0a 0a 16 12 ... ....
+ 0c 08 + 0a 0a ... ....
16 12 + 20 1c ... FFFF

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 167/279


Транспортный протокол управления передачей данных
Основной транспортный протокол стека TCP/IP. Номер протокола
следующего уровня (Protocol) в заголовке IP — 6.

Спецификация
Основная спецификация TCP находится в RFC-793.

Экземпляр протокола TCP предоставляет основанную на соединении


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

Организация логической связи


В отличие от протокола UDP, в соединении TCP всегда существует две
конечные (удаленные) точки — сокеты. Логическая топология такого
подключения представляет собой двухточечное соединение (Point to Point).
В связи с этим протокол TCP не может использоваться для групповой
или широковещательной рассылки данных.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 168/279


Механизмы обеспечения надежности I

1 Данные от приложения разбиваются на блоки (сегменты) заданной


длины. В связи с этим, генерирование одного сегмента может привести
к возникновениб множества дейтаграмм IP;
2 При пересылке сегмента включается таймер, ожидающий
подтверждения (квитирования) приема сегмента на удаленном конце
соединения. Если подтверждение не получено по истечении времени,
сегмент передается повторно;
3 Квитирование приема сегментов может происходить сепаративно (на
каждый сегмент) или группировано (одна квитанция на серию
сегментов);
4 Модуль TCP осуществляет обязательный расчет контрольной суммы
заголовка сегмента и поля данных. Контрольная сумма, рассчитываемая
на удаленных концах соединения, позволяет выявить ошибки передачи.
Если сегмент прибывает с неверной контрольной суммой, сегмент
отбрасывается без квитирирования. По истечению таймера, узел
отправителя должен осуществить повторную передачу;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 169/279


Механизмы обеспечения надежности II

5 Сегменты TCP инкапсулируются в дейтаграмму IP, при этом


дейтаграммы могут достигнуть адресуемый узел в случайном порядке.
Использую номера последовательностей, модуль TCP удаленного узла
может переупорядочивать принятые сегменты для восстановления
исходной длины сообщения;
6 Каждый взаимодействующий узел в соединении TCP резервирует
определенное пространство памяти для накопления и
переупорядочивания сегментов (накопитель — buffers). За счет
накопителей, удаленные узлы посылают данные только в том случае,
если их можно уместить в принимающий буфер. Механизм накопителей
позволяет предотвратить переполнение буферов в конфигурациях с
медленным приемником и быстрым отправителем.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 170/279


Службы Internet использующие TCP

Порт Служба Описание


20 ftp-data Порт сервера FTP для приема и передачи данных в
активном режиме
21 ftp Управляющее соединение сервера FTP
22 ssh Защищенный удаленный доступ к виртуальному
терминалу
25 smtp Служба передачи электронной почты по протоколу
SMTP
80 www Служба «глобальной паутины» (World Wide Web)
110 pop3 Служба получения электронной почты (POP3)
873 rsync Служба удаленной синхронизации данных

Основная область применения


Основное назначение протокола TCP — службы передачи данных Internet.
Протокол TCP обеспечивает дуплексное двухточечное соединение с
квитированием для приложений более высокого уровня. Как правило, сервер
TCP функционирует в итеративном режиме (см. 1).
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 171/279
Формат сегмента TCP

Дейтаграмма IP

Сегмент TCP

Заголовок Заголовок Заголовок Данные приложения


Ethernet IP TCP

14 байт 20 байт 20 байт

Рис. 42 — Инкапсуляция TCP в дейтаграмму IP

Длина заголовка сегмента


Регулярная длина заголовка сегмента TCP равна 20 байтам, однако за счет
дополнительных опций заголовок может быть расширен до длины 60 байт.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 172/279


1 Порт источника (Source port) — поле указывает номер порта
приложения отправителя (16 бит);
2 Порт назначения (Destination port) — поле указывает номер порта
приложения получателя (16 бит);
3 Номер последовательности (Sequence number) — поле содержит
уникальный инкрементальный «счетчик» байт, передаваемых в текущем
сегменте. Каждый байт, переносимый сегментом, должен увеличивать
значение счетчика на единицу (32 бита);
4 Номер подтверждения (Acknowledgement number) — поле содержит
номер последовательности, ожидаемый в следующей посылке.
Учитывается только при установленном флаге ACK. Предназначено для
квитирования (подтверждения приема) переданных сегментов (32 бита);
5 Длина заголовка (Header length) — поле указывает размер заголовка
сегмента TCP в 32 битных словах (4 бита);
6 Поле управляющих флагов (TCP header flags) — предназначено для
сопровождения процедур установления, поддержания и разрушения
соединения TCP, а также указания типа сегмента (6 бит);

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 173/279


7 Размер окна приема (Window size) — содержимое поля указывает на
количество байт, начинающееся с указанного в поле номера
подтверждения, которое приложение может принять и поместить в
буфер (16 бит);
8 Контрольная сумма (Checksum) — значение поля контрольной суммы
охватывает собой весь TCP сегмент: заголовок и данные. Алгоритм
расчета контрольной суммы полностью аналогичен алгоритму расчета
контрольной суммы дейтаграммы UDP (32 бита);
9 Указатель срочности (Urgent pointer) — значение поля указывает на
смещение байт, которое необходимо добавить к номеру
последовательности для выделения блока срочных данных. Учитывается
только при установленном флаге URG;
10 Опции (Options) — поле опций содержит расширенные опции TCP и
имеет переменную длину. Поле опций должно быть выравнено по
границе 32 бит и при необходимости дополняется нулями.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 174/279


0 3 4 9 10 15 16 31

Номер порта источника Номер порта назначения


Source port Destination port

Номер последовательности
Sequence number
20 байт

Номер подтверждения
Acknowledgment number

Длина U A P R S F
заголовка Резерв R C S S Y I Размер окна приема
Header length Reserved G K H T N N Window size

Контрольная сумма Указатель срочности


Checksum Urgent pointer

Опция
Options

Данные
Data

Рис. 43 — Формат заголовка сегмента TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 175/279


Флаг Назначение
URG «Указатель срочности», флаг используется совместно с
одноименным полем заголовка.
ACK «Номер подтверждения», флаг означает что данный сегмент
содержит квитанцию с номером последнего принятого сегмента,
используется совместно с одноименным полем.
PSH «Не буферизировать данные», флаг означает что желательно
передать данный сегмент приложению как можно скорее.
RST «Сброс соединения», флаг используется для принудительного
разрыва соединения TCP.
SYN «Синхронизация», флаг используется только при инициализации
соединения в процедуре «троекратного рукопожатия» (three
way handshaking) для согласования номера начальной
последовательности (Initial Sequnce Number). Флаг увеличивает
номер последовательности на 1.
FIN «Завершение соединения», флаг используется для уведомления
удаленного узла о закрытии соединения TCP. После передачи
сегмента с таким флагом, узел не может продолжать передачу
сегметов с данными, но может принимать данные от удаленного
узла и производить их квитирование. Флаг увеличивает номер
TCP/IP : Алгоритмыпоследовательности на 1.
и протоколы транспортного уровня Internet 176/279
Листинг 38 — Пример сегмента TCP
~> sudo tcpdump -i wlan0 -lvvvn -XX -c 1 tcp
0x0000: 14d6 4da7 d4fe 6817 2989 222c 0800 4500
0x0010: 0072 711f 4000 4006 711c 0a0a 0c05 5bee
0x0020: e64d eb38 008f 8ae8 e7fc 371c cda1 5018
0x0030: 0b5b 6113 0000 0101 080a 0004 e3a8 90fe
0x0040: a26a 3434 2053 5441 5455 5320 494e 424f
0x0050: 5820 284d 4553 5341 4745 5320 5245 4345
0x0060: 4e54 2055 4944 4e45 5854 2055 4944 5641
0x0070: 4c49 4449 5459 2055 4e53 4545 4e29 0d0a

Анализ
Указатель протокола транспортного уровня в заголовке IP 0x06 — TCP (6);
0xeb38, 0x008f — порт источника 60216, порт назначения 143;
0x8ae8 e7fc — номер последовательности байт (2330519548);
0x371c cda1 — номер подтверждающей квитанции (924634529);
0x5, 0x018 — длина заголовка (20 байт), флаги ACK PSH;
0x0b5b, 0x6113 — размер окна приема, контрольная сумма сегмента;
0x0000 — указатель срочности;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 177/279


Конечный автомат состояний сокетов TCP I
Диаграмма состояний или конечный автомат состояний сокетов TCP
описывает все стандартные (RFC-793) состояния, в которые может быть
переведен программный сокет TCP. Каждое состояние сокета однозначно
определяет текущее состояние логического соединения TCP между двумя
удаленными узлами.

TCP sockets finite state machine


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

Сокет TCP, в зависисмости от конфигурации полученных или отправленных


флагов SYN, ACK, RST, FIN или по обработке таймера, может
находиться в одном из 11 стандартных состояний:
1 Closed — сокет TCP закрыт, т. е. конечная точка логического
соединения TCP (порт) не доступен. ОС может удерживать выделенный
порт в данном состоянии после разрыва предыдущего соединения.
Данные не передаются и не принимаются;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 178/279


Конечный автомат состояний сокетов TCP II
2 Listen — сокет TCP открыт, т. е. ОС выделила порт и ожидает приема
или передачи сегментов для начала инициализации соединения TCP.
Данное состояние характерно для серверной части
приложений (например, веб-сервер WWW ожидающий запросов от
клиентов). После обработки всех запросов, принятых в рамках
заданного соединения, «серверный сокет» должен вернуться в данное
состояние;
3 SYN received — открытый сокет TCP принял сегмент с флагом
SYN, т. е. запускается процедура инициализации соединения (пассивное
открытие);
4 SYN sent — открытый сокет TCP отправил сегмент с флагом SYN, т. е.
запускается процедура инициализации соединения (активное
открытие);
5 Established — между удаленными сокетами открыто соединение
TCP, по которому пересылаются данные приложений. В данном
состоянии сокет может обрабатывать флаги URG, PSH, FIN, ACK,
PSH;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 179/279


Конечный автомат состояний сокетов TCP III

6 Close wait — локальный сокет TCP принял уведомление (FIN) о


завершении удаленного соединения, т. о. инициализируется процедура
пассивного закрытия сокета. Удаленный сокет больше не может
передавать данные, но может отправлять сегменты
подтверждения (ACK);
7 Last ACK — локальный сокет TCP ожидает подтверждения закрытия
соединения, т. е. входящий сегмент с флагом ACK;
8 FIN wait 1 — локальный сокет TCP отправил уведомление (FIN) о
завершении соединения, т. о. инициализируется процедура активного
закрытия сокета. Локальный сокет больше не может передавать
данные, но может отправлять сегменты подтверждения (ACK);
9 FIN wait 2 — локальный сокет получил подтверждение ACK от
удаленного узла на уведомление о закрытии соединения FIN.
Локальный сокет больше не может передавать данные, но может
отправлять сегменты подтверждения (ACK). Данное состояние
называется «полузакрытым соединением» TCP;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 180/279


Конечный автомат состояний сокетов TCP IV

10 Closing — состояние «одновременного закрытия» сокетов, т. е. после


отправки сегмента с флагом FIN, локальный сокет TCP принял сегмент
с флагом FIN от удаленного сокета. В данном состоянии высылается
подтверждение ACK на закрытие логического соединения;
11 Time wait — логическое соединение TCP закрыто, включается таймер
удержания сокета равный удвоенному максимальному времени жизни
сегмента (2 Maximum Segment Lifetime). Данное состояние (ожидание
2MSL) предоставляет защиту от опоздавших дейтаграмм,
принадлежащих ранним соединениям TCP.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 181/279


Maximum Segment Lifetime
В каждой реализации стека выбирается значение для максимального
времени жизни сегмента. MSL представляет собой время, в течение
которого сегмент может существовать в сети, перед тем как он будет
отброшен. RFC-793 указывает, что MSL должно быть равно 2 минутам. В
разных реализациях эта величина имеет значение 30 секунд, 1 минута или 2
минуты.

Использование таймера MSL позволяет обработать две задачи:


При «активном закрытии» сокета TCP данный таймер позволяет
повторно послать последний ACK в том случае, если первый сегмент
ACK был утерян;
Пока TCP соединение находится в ожидании 2MSL, кортеж,
выделенный для этого соединения, не может быть повторно
использован.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 182/279


Приложение:
Активное открытие
Отправлен: [SYN]
Closed
(Закрыт)

Приложение: Приложение:
Пассивное открытие Отправка данных
Отправлен: [SYN]
Принят: [SYN]
Отправлен: [SYN,ACK] Listen
(Прослушивается)

Принят: [RST]
Принят: [SYN]
Отправлен: [SYN,ACK]

SYN_rcvd SYN_sent
(Принят SYN) Одновременное открытие (Отправлен SYN)

Принят: [SYN,ACK]
Приложение: Закрытие
Принят: [ACK] Отправлен: [ACK]
Выход по тайм-ауту

Established Close_wait
(Соединение установлено
Приложение: Закрытие Передача данных) (Принят FIN)
Отправлен: [FIN]
Принят: [FIN]
Отправлен: [ACK] Приложение: Закрытие
Отправлен: [FIN]
Приложение: Закрытие
Отправлен: [FIN]
Last_ACK
Принят: [FIN] (Отправлен FIN)
Отправлен: [ACK]
Одновременное закрытие
Принят: [ACK]
FIN_wait_1 Closing
(Отправлен FIN) (Закрытие)
Пассивное закрытие
Принят: [FIN,ACK]
Принят: [FIN] Отправлен: [ACK]
Принят: [ACK]
Отправлен: [ACK] Принят: [FIN,ACK]
Отправлен: [ACK]

FIN_wait_2 Time_wait
(Принят ACK) (Тайм-аут удержания сокета)

Активное закрытие

Рис. 44 — Автомат конечных состояний сокетов TCP


TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 183/279
Утилита netstat — network statistics
Утилита предназначена для вывода текущих сетевых соединения, состояния
сокетов, таблицы маршрутизации, данных об использовании сетевых
интерфейсов, принадлежности к групповым рассылкам и т. д. Руководство —
man netstat. Аналог в наборе утилит iproute2 — ss.

Листинг 39 — Утилита netstat (пакет net-tools)


~> netstat -lant
Active Internet connections (servers and established)
Proto Local Address Foreign Address State
tcp 10.10.12.5:58597 213.158.11.52:443 ESTABLISHED
tcp 127.0.0.1:7634 127.0.0.1:46983 TIME_WAIT
tcp 10.10.12.5:43042 91.238.230.77:143 ESTABLISHED
tcp 127.0.0.1:7634 127.0.0.1:46984 TIME_WAIT
tcp 127.0.0.1:7634 127.0.0.1:46985 TIME_WAIT
tcp 127.0.0.1:7634 127.0.0.1:46980 TIME_WAIT
tcp 10.10.12.5:38619 93.158.134.124:993 ESTABLISHED
tcp 10.10.12.5:58599 213.158.11.52:443 ESTABLISHED
tcp 127.0.0.1:7634 127.0.0.1:46978 TIME_WAIT

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 184/279


Установление cоединения TCP I
Процедура установления нового соединения TCP реализуется согласно
автомату конечных состояний сокетов TCP. Регулярная процедура
установления соединения вызывает генерирование 3 сегментов TCP, в
которых синхронизируются номера начальных сегментов
(последовательностей) ISN (Initial Sequence Number). Данная процедура
получила распространенное обозначение «трехкратное
рукопожатие» (three-way handshaking). Этапы процедуры установления
соединения TCP:
1 Удаленный узел (клиент) отправляет сегмент с флагом SYN, указывая
номер порта целевого узла (сервера), к которому необходимо установить
соединение, а также исходный номер последовательности ISNc , с
которого начнется отсчет потока пересылаемых байт;
2 Сервер отвечает сегментом с флагами SYN, ACK. Данный сегмент
содержит исходный номер последовательности сервера ISNs . Флагом
ACK сервер подтверждает приход сегмента с флагом SYN от клиента,
при этом, согласно механизму подтверждения принятых сегментов, поле
подтверждения заголовка TCP (Acknowledgement sequence) содержит
значение ISN, принятое от клиента плюс один (ISNc + 1);
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 185/279
Установление cоединения TCP II
3 Клиент подтверждает приход сегмента с номером ISNs от сервера,
отпракой сегмента с флагом ACK. При этом поле подтверждения
заголовка TCP содержит значение ISNs + 1.

Сокет сервера
SYN ISN_s
t(с) ACK ISN_c+1 Established
Сервер Listen SYN_rcvd
(server)

Клиент
(client) SYN_sent
Established ACK ISN_s+1
SYN ISN_c

Сокет клиента
Рис. 45 — Временная диаграмма установления соединения TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 186/279


Листинг 40 — Вывод tcpdump (часть вывода опущена)
~> sudo tcpdump -i wlan0 -vvvnlS -c 4 tcp
21:52:45.726693
10.10.12.5.43221 > 91.122.46.252.21: Flags [S], seq 2921047820
21:52:45.727310
.21 > .43221: Flags [S.], seq 4150798953, ack 2921047821
21:52:45.727335
.43221 > .21: Flags [.], seq 2921047821, ack 4150798954
21:52:45.728659
.21 > .43221: Flags [P.], seq 4150798954:4150798997, ack 2921047821

Сокет 91.122.46.252:21

[SA], seq 4150798953 [PA], seq 4150798954:4150798997


ack 2921047821 ack 2921047821
Сервер
(server)

~
Клиент
(client)

[S], seq 2921047820 [A], seq 2921047821


ack 4150798954

Сокет 10.10.12.5:43221

Рис. 46 — Временная диаграмма установления соединения TCP


TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 187/279
Некоторые детали процедуры установления соединения TCP:
Сокет, инициирующий соединение TCP, т. е. сокет отправляющий
сегмент с флагом SYN (состояние SYN sent) выполняет активное
открытие соединения. Сокет принимающий инициирующий сегмент
SYN (состояние SYN received) выполняет пассивное отркрытие
соединения;
Исходный номер последовательности (ISN) генерируется для каждого
логического соединения TCP независимо. RFC-793 указывает, что ISN
должен увеличиваться на единицу каждые 4 · 10−6 c. Благодаря
номерам последовательностей, дейтаграммы IP, задержавшиеся в сети и
доставленные позже, не воспринимаются как часть существующего
соединения;
В большинстве реализаций при инициализации системы исходный
номер последовательности устанавливается в 1. Затем эта величина
увеличивается на 64000 каждые полсекунды и возвращается в значение
0 через каждые 9,5 часов, что соответствует счетчику, который
увеличивается на единицу каждые 8 · 10−6 c. Кроме того, каждый раз,
когда устанавливается новое соединение TCP, номер ISN должен
увеличиваться еще на 64000.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 188/279


Одновременное открытие соединения TCP
Существует вероятность того, что два удаленных приложения могут
одновременно осуществить активное открытие (simultaneous open).
Модуль TCP разработан таким образом, чтобы обрабатывать одновременное
открытие, при этом результатом является одно соединение, а не два.
Одновременное открытие требует обмена четырьмя сегментами.
Сокет сервера
SYN ISN_s
SYN ISN_s ACK ISN_c+1
Established
SYN_sent SYN_rcvd

~
SYN_sent SYN_rcvd

Established
SYN ISN_c SYN ISN_c
ACK ISN_s+1
Сокет клиента
Рис. 47 — Временная диаграмма одновременного установления соединения TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 189/279


Завершение cоединения TCP I
Процедура завершения соединения TCP реализуется согласно автомату
конечных состояний сокетов TCP. Регулярная процедура вызывает
генерирование 4 сегментов TCP. Так как соединение TCP полнодуплексное,
каждое направление должно быть закрыто независимо от другого. Этапы
процедуры завершения соединения TCP:
1 Приложение (клиента) завершает передачу данных и вставляет в
сегмент флаг FIN (активное закрытие). Отправляющий сокет (клиент)
переключается в режим ожидания подтверждения от удаленной
стороны;
2 Удаленный сокет (сервер) подтверждает ACK прием сегмента с флагом
FIN. Сокет может продолжать передачу данных и принимать
подтверждения. Сокет (клиент) получивший подтверждение на сегмент
FIN переводится в симплексный режим, т. е. может только потвержадть
принятые сегменты, но не отправлять данные;
3 Если данных для пересылки больше нет, сокет (сервер) формирует
сегмент с флагом FIN и так же ожидает подтверждения завершения
соединения от удаленной стороны (клиента);

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 190/279


Завершение cоединения TCP II
4 Если подтверждение ACK поступило, то соединение TCP считается
полность закрытым. Сокеты закрываются и освобождаются системой.

Сокет сервера

t(с) ACK C+1 FIN S

Сервер Established Close_wait Last_ACK


(server)

Клиент
(client) FIN_wait_1 Time_wait
FIN_wait_2
FIN C ACK S+1

Сокет клиента
Рис. 48 — Временная диаграмма завершения соединения TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 191/279


Листинг 41 — Вывод tcpdump (часть вывода опущена)
~> sudo tcpdump -i eth0 -vvvnlS tcp
17:41:20.288426
.21 > .52834: Flags [F.], seq 3374642807, ack 1727981476
17:41:20.288747
.52834 > .21: Flags [F.], seq 1727981476, ack 3374642808
17:41:20.288931
.21 > .52834: Flags [.], seq 3374642808, ack 1727981477

Сокет 10.10.12.5:52834

[F.], seq 1727981476


ack 3374642808

Клиент

.
(client)

~
Сервер
(server)

[F.], seq 3374642807 [.], seq 3374642808


ack 1727981476 ack 1727981477

Сокет 91.122.46.252:21

Рис. 49 — Временная диаграмма завершения соединения TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 192/279


Одновременное закрытие соединения TCP
Аналогично процедуре одновременного открытия соединения TCP,
существует вероятность одновременного активного закрытия. Протокол TCP
поддерживает процедуру одновременного закрытия (simultaneous close). При
одновременном закрытии происходит обмен таким же количеством
сегментов, как и при обычном закрытии.
Сокет сервера

FIN S ACK C+1

Established FIN_wait_1 Closing Time_wait

Established FIN_wait_1 Closing Time_wait

FIN C ACK S+1

Сокет клиента
Рис. 50 — Временная диаграмма одновременного завершения соединения TCP
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 193/279
Передача данных по соединению TCP I

В протоколах транспортного уровня модели ISO распространенно несколько


алгоритмов обработки потока данных между двумя удаленными узлами:
Алгоритм передачи с обратной связью и ожиданиями (старт-стопный
механизм перезапроса данных — SAW ARQ (Stop And Wait Automatic
Repeat Request)). Алгоритм SAW предполагает паузу в передаче
каждого блока данных до получения подтверждения. Если
подтверждение отсутствует, то блок передается заново. Данный способ
прост в реализации, но приводит к низкой эффективности загрузки
физического канала;
Алгоритм непрерывной передачи с обратной связью и возвратом на N
кадров (GBN ARQ — Go Back N ARQ). В данном режиме блоки
передаются непрерывно, и одновременно сохраняются в буферной
памяти, до момента их подтверждения. При отсутствии подтверждения,
повторяется передача хранящихся в буфере блоков, начиная с
последнего неподтвержденного блока. Т. о. все блоки переданные после
определенного момента также необходимо передавать заново;

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 194/279


Передача данных по соединению TCP II

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


повтором (SR ARQ — Selective Repeat ARQ). Принцип работы
алгоритма аналогичен GBN ARQ, однако повторяются только
неподтвержденные блоки данных. Такой алгоритм наиболее эффективен,
но требует наличия буферов памяти на передатчике и приемнике.
Протокол TCP использует алгоритм GBN ARQ, который в рамках стека
TCP/IP принято называть «алгоритмом с изменяющимся окном» (sliding
window) . Такой механизм позволяет отправителю передать сразу несколько
блоков данных, перед тем как станет необходимым остановится и ожидать
подтверждения. Подобный алгоритм позволяет оптимизированить передачу
данных и ускорить процесс доставки блоков данных, так как отправитель не
должен останавливаться и ждать подтверждения каждый раз после
отправки порции данных.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 195/279


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

t1

1 2 3 4 5 6 7 8 9 10 11

Передано Передано, Готово Не готово


и подтверждено но неподтверждено к передаче к передаче

t2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Передано Передано, Готово Не готово


и подтверждено но неподтверждено к передаче к передаче

Рис. 51 — Смещение буфера окна передачи TCP

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 196/279


Отложенные подтверждения
По умолчанию, модуль TCP не отправляет подтверждение сразу после
приема данных. Задержка сегментов с подтверждением выполняется в
расчете на то, что в данном направлении будут пересылаться данные, таким
образом подтверждение может быть отправлено вместе с «попутными»
данными.

Время задержки
Большинство реализаций стека используют задержку равную 2 · 10−1 c.
Требования к реализиции узлов (Host requirement RFC) указывают на то,
что TCP должен применять отложенные подтверждения, однако задержка
должна быть меньше чем 5 · 10−1 c.

Листинг 42 — Вывод tcpdump (часть вывода опущена)


.41940 > .21: [P.], seq 825759627:825759645, ack 2898349004, length 18
.21 > .41940: [P.], seq 2898349004:2898349075, ack 825759645, length 71
.21 > .41940: [P.], seq 2898349075:2898349099, ack 825759645, length 24
.41940 > .21: [.], seq 825759645, ack 2898349099, length 0

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 197/279


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

Максимальный размер сегмента


Самая большая порция данных, которую TCP пошлет удаленному сокету.
При установлении соединения, каждый сокет может объявить свой MSS.

Распространенное значение в различных реализациях — 1024 байта.


Регулярная дейтаграмма IP обычно на 40 байт больше: 20 байт отводится
под TCP заголовок и 20 байт под IP заголовок.
Оптимальный MSS
В общем случае, чем больше MSS тем лучше, до тех пор пока не
происходит фрагментация. Большие размеры сегмента позволяют послать
больше данных в каждом сегменте, что уменьшает относительную
«стоимость» IP и TCP заголовков.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 198/279


По договоренности
В некоторых публикациях говорится, что эта опция устанавливается "по
договоренности". В действительности, договоренность в данном случае не
используется. Когда соединение устанавливается, каждая сторона объявляет
MSS, которой она собирается принимать. Опция MSS может быть
использована только в SYN сегменте!
Если одна сторона не принимает опцию MSS от другой стороны,
используется размер по умолчанию в 536 байт. В этом случае, при 20
байтах заголовка IP и 20 байтах заголовка TCP, длина дейтаграммы
составляет минимальную длину — 576 байт.

Листинг 43 — Вывод tcpdump (часть вывода опущена)


.49992 > .33051: [S] 517312000 <mss 1460>
.33051 > .49992: [S.] 509556225 ack 517312001 <mss 536>
.49992 > .33051: [.] ack 509556226

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 199/279


В некоторых случаях может быть установлено значение MSS равное MTU
исходящего интерфейса минус размер фиксированных TCP и IP заголовков.
Для Ethernet MSS может достигать 1460 байт.

MSS в реализациях
Большинство BSD реализаций требует, чтобы MSS было кратно 512. Solaris,
SunOS, IBM AIX объявляют MSS равный 1460, когда оба сокета находятся
в одной сети Ethernet.
Если IP адрес назначения не локальный, т. е. узлы находятся в различных
физических сетях, MSS устанавливается по умолчанию — 536 байт. Пункт
назначения, IP адрес которого имеет тот же самый идентификатор сети и ту
же самую маску подсети, что и у отправителя является локальным; пункт
назначения, IP адрес которого полностью отличается от идентификатора
сети, является нелокальным; пункт назначения с тем же самым
идентификатором сети, однако с другой маской подсети, может быть как
локальным, так и нелокальным.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 200/279


Размер окна, предлагаемый получателем, обычно определяется получающим
процессом. Данная опция оказывает важное влияние на производительность
TCP.
Реализации
В реализациях BSD приемные и отправляющие буферы по умолчанию
устанавливаются в 4096 байт каждый. Другие системы, Solaris, AIX
используют по умолчанию большие размеры буферов, 8192 или 16384 байта.

API сокетов позволяют процессу устанавливать размеры отправляющего и


приемного буферов. Размер принимающего буфера равен максимальному
размеру объявленного окна для данного соединения. Некоторые приложения
изменяют размеры буферов для увеличения производительности.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 201/279


Листинг 44 — Вывод tcpdump (часть вывода опущена)
.11261 > .56612: [S] 1227520000:1227520000 (0)
|--> <win 4096, mss 1460>
.56612 > .11261: [S.] 2363371521:2363371521 (0)
|--> ack 1227520001 <win 6144 mss 1024>
.11261 > .56612: [.] ack 1 <win 4096>
.11261 > .56612: [.] 1:1025(1024) ack 1 <win 4096>
.11261 > .56612: [.] 1025:2049(1024) ack 1 <win 4096>
.11261 > .56612: [.] 2049:3073(1024) ack 1 <win 4096>
.11261 > .56612: [P.] 3073:4097(1024) ack 1 <win 4096>
.11261 > .56612: [.] 4097:5121(1024) ack 1 <win 4096>
.11261 > .56612: [.] 5121:6145(1024) ack 1 <win 4096>
.56612 > .11261: [.] ack 6145 <win 2048>
.11261 > .56612: [.] 6145:7169(1024) ack 1 <win 4096>
.11261 > .56612: [FP.] 7169:8193(1024) ack 1 <win 4096>
.56612 > .11261: [.] ack 6145 <win 4096>
.56612 > .11261: [.] ack 8194 <win 2048>
.56612 > .11261: [.] ack 8194 <win 4096>
.56612 > .11261: [.] ack 8194 <win 6144>
.56612 > .11261: [F.] 1:1(0) ack 8194 <win 6144>
.11261 > .56612: [.] ack 2 <win 4096>
TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 202/279
Опции TCP

TCP заголовок может содержать опции. Каждая опция начинается с байта


«тип» (kind), который указывает на тип опции. Опции, тип которых равен 0
и 1, занимают 1 байт. Другие опции имеют поле длины, которое следует за
байтом типа. Длина включает байт типа и байт длины. Некоторые опции,
которые определены в спецификации TCP RFC-793 и RFC-1323:
1 Конец списка опций — тип 0;
2 Нет операции (No operations, NOP) — тип 1;
3 Максимальный размер сегмента — тип 2;
4 Коэффициент масштабирования окна — тип 3;
5 Временная метка — тип 8.
Опция «нет операции» необходима, чтобы отправитель мог заполнить поля,
которые должны быть кратны 4 байтам.

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 203/279


Тип Тип Тип Длина
MSS
0 1 2 4

1 байт 1 байт 1 байт 1 байт 2 байт

Тип Длина Счетчик


3 3

1 байт 1 байт 1 байт

Тип Длина Временная Эхо временной


8 10 метка метки

1 байт 1 байт 4 байт 4 байт

Рис. 52 — Опции TCP

Листинг 45 — Вывод tcpdump (часть вывода опущена)


.43291 > .33531: [S] 71312001
<mss 512, nop, wscale 0, nop, nop, timestamp 146647 0>

TCP/IP : Алгоритмы и протоколы транспортного уровня Internet 204/279


Служба системы доменных имен
Система доменых имен (Domain Name System, DNS) — служба прикладного
уровня стека TCP/IP. Представляет собой распределенную базу данных,
которая используется приложениями TCP/IP, для установления
соответствия между именами хостов и IP адресами.
Важное приложение DNS
Cистема DNS используется для маршрутизации электронной почты (Internet
E-Mail).
БД системы DNS имеет распределенную структуру — ни на одном узле сети
Internet не хранится вся информация, лишь некоторая ее часть, которая
позволяет определить адрес узла. Каждый крупный узел сети Internet
(автономная система, сеть, подсеть и т. д.) поддерживает собственую
информационную базу данных и выполняет программу сервер, которая
обрабатывает запросы к другим узлам сети.
Описание службы
RFC-1034 описывает основы DNS, RFC-1035 содержит подробности
разработки и спецификации DNS.
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 205/279
Эпоха до DNS
При отсутствии службы DNS, данные об именах узлов можно хранить в
файле /etc/hosts.

Листинг 46 — Файл /etc/hosts


# /etc/hosts: Local Host Database
# IPv4 and IPv6 localhost aliases
127.0.0.1 hyperion hyperion.radiocoder.net localhost
::1 hyperion hyperion.radiocoder.net localhost
# local network aliases
10.19.0.1 gateway.mysite.org
10.19.0.21 ftp.mysite.net
10.22.2.1 email.mysite.net

Недостатки
Быстрый рост размера файла;
Медленное обновление информации (время сходимости данных);
Необходимость репликации файла на все узлы.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 206/279


Служба, система, протокол
DNS представляет собой службу отображения имен сети Internet, систему
связанных узлов, предназначенных для выполнения определенной задачи
(распределенную облачную систему) и формат протокола, который позволяет
клиентам и серверам обмениваться информацией.

С точки зрения приложения, доступ к DNS осуществляется посредством


процесса «разборщика имен» (resolver) — подпрограммы, которая
используются для создания, отправки и интерпретации дейтаграмм DNS,
используемых серверами имен Internet.

DNS resolver
Разборщик (преобразователь) — это часть сетевого приложения, который не
входит в ядро операционной системы как протоколы TCP/IP. Приложение
должно конвертировать имя хоста в IP адрес, перед тем как оно попросит
TCP открыть соединение или послать дейтаграмму с использованием UDP.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 207/279


DNS и UNIX
В системах UNIX, к разборщику можно получить доступ через
библиотечные функции, gethostbyname и gethostbyaddr, которые
линкуются (build with linking) с приложением, когда оно строится. Первая
воспринимает в качестве аргумента имя хоста и возвращает IP адрес
(прямое преобразование), а вторая воспринимает в качестве аргумента IP
адрес и возвращает имя хоста (обратное преобразование). Разборщик
обращается к серверу DNS (name server), чтобы установить соответствие
между адресом IP и символьным именем.

Транспорт DNS
Служба DNS в качестве основного протокола транспортного уровня
использует UDP, инкапсулированный в дейтаграмму IP. Порт серверной
службы 53, порт клиента выбирается ОС произвольно из диапазона
пользовательских портов. Однако, не следует забывать, что служба DNS
использует протокол TCP в нескольких случаях:
Клиенту поступил «обрезанный» (truncated) ответ на запрос;
Ретрансфер файл зон между первичным и вторичным сервером DNS.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 208/279


Пространство имен DNS имеет иерархическую структуру, напоминающую
файловую систему.
Корневой домен
.
Служебный
домен

... ... ... Домены


arpa com net org uk ... ru ... su
первого (верхнего) уровня

in-addr fido Домен


второго уровня
175 Тематические Географические
домены домены Домен
web
третьего уровня
61

122

91 PTR: 91.122.61.175.in-addr.arpa.

Рис. 53 — Иерархическая организация DNS

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 209/279


Каждый узел имеет метку длиной до 63 символов;
Корень дерева (.) — специальный узел без метки;
Метки могут содержать заглавные буквы или маленькие;
Имя домена (domain name) для любого узла в дереве —
последовательность меток, которая начинается с узла выступающего в
роли корня, при этом метки разделяются точками;
Каждый узел дерева должен иметь уникальное имя домена, однако
одинаковые метки могут быть использованы в различных точках дерева.

FQDN — Fully Qualified Domain Name


Имя домена, которое заканчивается точкой, называется абсолютным
именем домена или полным именем домена. Например:
sun.tux.org. — абсолютное имя домена;
sun.daemon.co — незаконченное имя домена, или относительное имя.
Если данный домен имеет локальный суффикс uk, то полный домен
будет выглядеть как sun.daemon.co.uk.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 210/279


Домены верхнего уровня поделены на три зоны:
arpa — это специальный домен, используемый для обратного
отображения (IP → hostname);
3 символьные домены называются общими (generic) или тематическими
доменами;
2 символьные домены, основанные на кодах стран (ISO 3166),
называются доменами стран (country) или географическими
(geographical) доменами.

Принцип делегирования
Система DNS использует принцип делегирования полномочий по
управлению зонами внутри домена. Не существует организации, которая бы
управляла и обслуживала все дерево в целом и каждую метку в
отдельности. Вместо этого, одна организация (NIC — Network Information
Center) обслуживает только домены верхнего уровня, а ответственность за
определенные зоны передает другим организациям.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 211/279


Корневые серверы DNS
В сети Internet существует 13 корневых серверов системы DNS (root name
servers), которые располагают информацией о доменах первого уровня.
Поиск адреса, начинающийся с верхнего домена, выполняется с запроса к
корневому серверу. Корневые серверы работают только в итеративном
режиме.
Список корневых серверов
Список корневых серверов и их зеркал доступен на FTP сайте NIC
(ftp://ftp.rs.internic.net/domain/named.root) или на сайте
корневых серверов http://www.root-servers.org

Листинг 47 — Фрагмент файла корневых серверов


. 3600000 NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:ba3e::2:30
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 192.228.79.201
B.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:84::b

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 212/279


Рис. 54 — Карта географического размещения корневых серверов и их зеркал

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 213/279


Зона DNS
Зона DNS (zone) — это отдельно администрируемая часть дерева DNS.
Например, домен второго уровня sut.ru это отдельная зона. Домены
второго уровня поделены на меньшие зоны (ikss.sut.ru и т. д.).

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


DNS:
1 Первичный (primary) — сервер DNS содержит БД с отображением всей
необходимой информации на диске. Все изменения зоны выполняются
на первичном сервере;
2 Вторичный (secondary) — сервер DNS, который получает
информационную БД в сетевом режиме (реплекативно) с первичного
сервера.
Файл зон содержит несколько типов записей, которые однозначно
определяют цель отображения:
Тип Назначение
A Адрес IP
NS Сервер DNS
CNAME Каноническое имя
PTR Запись указателя
MX Сервер электронной почты

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 214/279


Листинг 48 — Пример файла зоны
site.net. IN SOA atlas.site.net. admin.site.net. (
2006051501 ; Serial
10800 ; Refresh
3600 ; Retry
604800 ; Expire
300 ; Negative Response TTL
)
;DNS
IN NS atlas.site.net.
IN NS titan.site.net.
;Origin IP
IN A 91.122.46.25
;Mail
IN MX 10 meteor.site.net.
IN MX 20 comet.site.net.
;Hosts
atlas IN A 91.122.46.99
titan IN A 91.122.46.100
meteor IN A 91.122.46.101
comet IN A 91.122.46.102
skoll IN A 91.122.47.1
imir IN A 91.122.47.2
;Aliases
www IN CNAME site.net.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 215/279


Если сервер DNS не содержит необходимой информации о запрашиваемом
узле, необходимо выполнить запрос к вышестоящему серверу. При этом
обработка запроса может выполняться в двух режимах:
Итеративный режим обработки запросов — опрашиваемый сервер DNS
передает информацию о удаленном сервере, который отвечает за
целевой домен;
Локальный
DNS-клиент Сервер DNS
10.10.12.3 1.Запрос: web.sut.ru IN A ? 10.10.12.5

2.Ответ: sut.ru NS 172.31.100.1

3.Запрос: web.sut.ru IN A ?

Компетентный сервер DNS


172.31.100.1

4.Ответ: web.sut.ru IN A 172.17.101.11

Рис. 55 — Итеративный режим

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 216/279


Рекурсивный режим обработки запросов — опрашиваемый сервер DNS
самостоятельно разыскивает целевое доменное имя через запрос к
компетентному (authoritative) серверу DNS.
Локальный
DNS-клиент 1.Запрос: web.sut.ru IN A ? Сервер DNS
10.10.12.3 10.10.12.5

4.Ответ: web.sut.ru IN A 172.17.101.11

2.Запрос: web.sut.ru IN A ?

3.Ответ: web.sut.ru IN A 172.17.101.11

Компетентный сервер DNS


172.31.100.1

Рис. 56 — Рекурсивный режим

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 217/279


Листинг 49 — Пример запроса к службе DNS
~> sudo tcpdump -vvvln -i wlan0 udp and \( dst port 53 or src port 53 \)
IP (tos 0x0, ttl 64, id 10587, offset 0, DF, proto UDP (17), length 60)
10.10.12.5.37122 > 10.10.12.1.53:
|-[udp sum ok] 56414+ A? opds.spbsut.ru. (32)

IP (tos 0x0, ttl 64, id 17459, offset 0, proto UDP (17), length 182)
10.10.12.1.53 > 10.10.12.5.37122:
|-[udp sum ok] 56414 q: A? opds.spbsut.ru.
|--1/3/3 opds.spbsut.ru. [1h] A 91.238.230.164
|---ns: spbsut.ru. [1h] NS ns.itut.ru.,
|----ar: ns.itut.ru. [3d11h4m41s] A 91.238.230.70.

Листинг 50 — Файл /etc/resolv.conf


search site.org
domain site.org
nameserver 10.19.0.2
nameserver 10.19.0.3

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 218/279


Некоторые детали службы DNS
Порядок поиска отображения
При поиске адреса IP, клиент не сразу обращается к серверу DNS:
1 Поиск в файле /etc/hosts;
2 Поиск в локальном временном кэше;
3 Запрос к серверу DNS.

Национальные кодировки
Национальные символы в доменных именах поддерживаются с помощью
кодировки «Punycode».

Hostname и IP
Hostname и адрес IP не тождественны, т. е. на запрос определения адреса
одного домена, может придти ответ с множеством адресов (выравнивание
нагрузки на сервера). За одним адресом может быть закреплено множество
доменных имен (виртуальный хостинг web-сервера Apache).

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 219/279


Основные реализации серверов DNS
1 BIND — Berkeley Internet Name Daemon;
2 djbdns — D. J. Bernstein DNS;
3 NSD — Name Server Daemon (только итеративная обработка);
4 Microsoft DNS Server — встроен в сетевую подсистему NT.

Основные утилиты для работы с DNS


1 host — маленькая утилита для опроса сервера DNS по заданному
имени или зоне;
2 dig — domain information groper, утилита из состава BIND, для
отладки и извлечения данных из системы DNS;
3 nslookup — name server lookup , аналогична утилите dig, но обладает
гораздо меньшим функционалом, однако портирована на многие ОС.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 220/279


Служба точного времени сети Internet

«Тот, у кого есть часы, всегда знает точное время. Тот, у кого двое
часов, никогда не знает точного времени»

Служба сетевого времени представляет возможность синхронизации


программных часов ОС с помощью распределенной компьютерной системы.
Помимо системы связанных узлов, служба точного времени включает в себя
сетевой протокол Network Time Protocol (NTP), благодаря которому
происходит сетевой обмен сообщениями. Служба NTP разработана в
1985 году и обновляется до настоящего времени, в связи с этим является
одной из старейших служб стека TCP/IP и сети Internet.
Протокол и алгоритм работы описаны в RFC-5905 (для версии протокола 4).

Транспорт и архитектура
Служба использует дейтаграммы UDP инкапсулированные в IP.
Зарегистрированнй номер порта службы NTP 123 UDP/TCP. Служба
характеризуется клиент-серверной архитектурой связи. При этом серверная
часть разделяется по специальным иерархическим уровням.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 221/279


Система серверов NTP использует иерархическую систему «часовых
уровней» (stratum — уровень, слой). Номер уровня определяет удаленность
от источника эталонных часов и существует, чтобы предотвратить
циклические зависимости в иерархии.

Порядок синхронизации
Сервер вышестоящего уровня не может производить подстройку часов
(синхронизацию) по времени нижестоящей машины.

Иерархия
Номер уровня не является показателем качества и надежности источника
времени. Уровни служат для сетевого распределения нагрузки, обеспечения
отказоустойчивости и территориального разнесения машин по
географическому, политического и др. признаку.

Устройства уровня 0 (stratum 0) представляют собой аппаратные


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

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 222/279


Сервер уровня 1 (stratum 1) имеет физическое аппаратное подключени
(через аппаратные интерфейсы) к устройству высокоточных часов
stratum 0. Сервер уровня 1 может осуществлять сетевую (NTP)
синхронизацию времени с аналогичным сервером уровня 1. Сервер
уровня 1 в сетевом режиме обслуживает машины уровня 2;
Сервер уровня 2 (stratum 2) не располагает собственными аппаратными
высокоточными часами, но имеет непосредственный сетевой доступ к
машине уровня 1, и также может осуществлять синхронизацию времени
с аналогичным сервером уровня 2. Сервер уровня 2 в сетевом режиме
обслуживает машины уровня 3;
Сервер уровня 3 в сетевом режиме синхронизируется с машинами
своего уровня и обслуживает машины нижестоящего уровня;
Протокол NTP поддерживает всего 256 уровней синхронизации.

Для устойчивой работы клиента службы NTP необходимо как минимум


3 сервера;
Для серверов, входящих в пул, рекомендуется использовать не менее 4,
но не более 7 серверов.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 223/279


A A A
Установка Установка Установка
часов RS-232 часов IEEE-1284 часов IEEE-1394

S1 S1 S1
Сетевая Сетевая
синхронизация синхронизация

Сетевая Сетевая
синхронизация синхронизация
S2 S2 S2

Сетевая Сетевая Сетевая Сетевая


синхронизация синхронизация синхронизация синхронизация
S3 S3 S3 S3 S3

Рис. 57 — Иерархия уровней системы NTP

Алгоритм выбора времени


Для синхронизации данных от многих источников, служба NTP использует
алгоритм «пересечения и согласования данных», который позволяет выбрать
более точный источник для оценки точного времени из ряда источников
времени, разной степени точности и усреднения времени, полученными от
разных серверов NTP.
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 224/279
Реализации NTP версии 4 способны обеспечить точность 10 · 10−3 c при
работе через Internet;
При работе в локальной сети достигается точность порядка 0.2 · 10−3 с;
В системе NTP время представляется 64 битным числом, состоящим из
32 битного счётчика секунд и 32 битного счётчика долей секунды,
позволяя передавать время в диапазоне 232 с., с теоретической
точностью 2−32 с.;
Время отсчитывается с 00:00 1 января 1900 года (UTC), а не с 00:00 1
января 1970 (UTC), поэтому из времени NTP нужно вычитать почти 70
лет (с учётом високосных лет), чтобы корректно совместить время с
Windows или системами UNIX.
http://www.pool.ntp.org — это кластер серверов точного времени
Internet, предоставляющий надежный и простой в использовании сервис
NTP для клиентов сети. Если есть сервер с внешним статическим
адресом IP и устойчивым соединением можно включить его в пул;
http://ntp.org/ — главная страница проекта NTP;
http://www.vniiftri.ru — ФГУП «Всероссийский
научно-исследовательский институт физико-технических и
радиотехнических измерений» предоставляет открытый доступ к
серверам синхронизации шкалы времени по протоколу NTP.
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 225/279
Группа NTP vniiftri.ru
Группировка из 4-х серверов уровня stratum 1, подключенных к
государственному первичному эталону времени РФ;
Группировка из 4-х серверов stratum 1, подключенных к вторичным
эталонам;
Один сервер stratum 2 синхронизирующийся с основной группировкой
серверов.

Машина Стек и порт Уровень Аппаратные часы


ntp1.vniiftri.ru IPv4 UDP 123 stratum 1
ntp2.vniiftri.ru IPv4 UDP 123 stratum 1 Meinberg M300/MRS
ntp3.vniiftri.ru IPv4 UDP 123 stratum 1
ntp21.vniiftri.ru IPv4 UDP 123 stratum 2 Intel Xeon, ntpd 4.2.4p8

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 226/279


Листинг 51 — Пример запроса к службе NTPv4
~> sudo tcpdump -i wlan0 -lvn udp and \( src port 123 or dst port 123 \)
10.10.12.5.123 > 10.10.12.1.123: [udp sum ok] NTPv4, length 48
Client, Leap indicator: clock unsynchronized (192)
Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
Reference Timestamp: 0.000000000
Originator Timestamp: 0.000000000
Receive Timestamp: 0.000000000
Transmit Timestamp: 3626080117.284741491 (2014/11/27 15:28:37)
Originator-Receive Timestamp: 0.000000000
Originator-Transmit Timestamp: 3626080117.284741491 (2014/11/27 15:28:37)

10.10.12.1.123 > 10.10.12.5.123: [udp sum ok] NTPv4, length 48


Server, Leap indicator: (0), Stratum 2 (secondary reference)
Root Delay: 0.029754, Root dispersion: 0.043258
Reference Timestamp: 3626079275.349624961 (2014/11/27 15:14:35)
Originator Timestamp: 3626080117.284741491 (2014/11/27 15:28:37)
Receive Timestamp: 3626080117.284362643 (2014/11/27 15:28:37)
Transmit Timestamp: 3626080117.284408271 (2014/11/27 15:28:37)
Originator - Receive Timestamp: -0.000378835
Originator - Transmit Timestamp: -0.000333213

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 227/279


Листинг 52 — Файл /etc/ntp.conf
server atlas.radiocoder.net iburst
# Pools for Gentoo users
#server 0.gentoo.pool.ntp.org
#server 1.gentoo.pool.ntp.org
#server 2.gentoo.pool.ntp.org
# you should not need to modify the following paths
driftfile /var/lib/ntp/ntp.drift

# Allow only time queries, at a limited rate, sending KoD when in excess.
# Allow all local queries (IPv4, IPv6)
#restrict default nomodify nopeer noquery limited kod
#restrict 127.0.0.1
#restrict [::1]

# To allow machines within your network to synchronize


# their clocks with your server, but ensure they are
# not allowed to configure the server or used as peers
# to synchronize against, uncomment this line.
#
#restrict 192.168.0.0 mask 255.255.255.0 nomodify nopeer notrap

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 228/279


Служба автоматического конфигурирования узлов
Служба автоматического (динамического) конфигурирования узлов
(Dynamic Host Configuration Protocol, DHCP) предназначена для
автоматизации процесса назначения адресов и типовой конфигурации
сетевых интерфейсов узлов. DHCP предполагает наличие системы
взаимодействующей по модели «клиент-сервер», протокольных сообщений и
службу обработки запросов.

Описание службы
Протокол и алгоритм работы описаны в RFC-2131.

Совместимость и развитие
Служба DHCP обратно совместима со службой BOOTP (Boot Protocol),
предназначенной для сетевой загрузки бездисковых станций (см. раздел
RARP). Номера портов сервера и клиента DHCP зарегистрированны IANA
за службой BOOTP. Сервер использует порт 67 UDP, а клиент 68 UDP.
В сетях IPv6 используется новая версия службы — DHCPv6 (RFC-3315).

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 229/279


Служба DHCP может быть сконфигурирована в нескольких режимах
исполнения:
Ручной режим — за определенным аппаратным адресом (MAC)
закрепляется протокольный адрес (IP);
Арендный режим — по запросу клиента, указанному интерфейсу
выделяется протокольный адрес, который арендуется на заранее
определенный срок (по умолчанию, несколько часов). После истечения
аренды клиенту необходимо перезапросить адрес у сервера заново или
получить новый адрес.
В регулярном случае служба DHCP предназначена для конфигурирования
адреса IP и маски подсети. Однако в качестве дополнительных опций могут
быть переданы адреса служебных серверов сети:
Широковещательный адрес подсети;
Адрес дежурного маршрутизатора;
Статические записи маршрутизации;
Список серверов службы DNS;
Зарегистрированное имя узла и суфикс локального домена;
Адрес сервера точного времени (NTP) и т. д.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 230/279


Листинг 53 — Пример запроса к серверу службы DHCP
~> sudo tcpdump -i wlan0 -lvn udp and \( src port 67 or dst port 68 \)
f8:01:13:7a:12:2d > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP
-> Request from 68:17:29:89:22:2c, length 389, xid 0x7554abca
--> Flags [none] (0x0000)
Client-Ethernet-Address 68:17:29:89:22:2c
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255,
-> 29:89:22:2c:00:01:00:01:1a:53:11:59:2c:d4:44:9f:c3:dc
Requested-IP Option 50, length 4: 10.10.12.5
MSZ Option 57, length 2: 1500
Vendor-Class Option 60, length 68: "dhcpcd-6.3.2:Linux-3.12.26-gentoo"
Hostname Option 12, length 23: "hyperion.radiocoder.net"
T145 Option 145, length 1: 1
Parameter-Request Option 55, length 14:
Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway
Domain-Name-Server, Hostname, Domain-Name, BR
NTP, Lease-Time, Server-ID, RN
RB, Option 119
END Option 255, length 0

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 231/279


Листинг 54 — Пример ответа сервера службы DHCP
14:d6:4d:a7:d4:fe > 68:17:29:89:22:2c, ethertype IPv4 (0x0800)
10.10.12.1.67 > 10.10.12.5.68: [udp sum ok] BOOTP/DHCP
-> Reply, length 300, xid 0x7554abca, Flags [none] (0x0000)
Your-IP 10.10.12.5
Client-Ethernet-Address 68:17:29:89:22:2c
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.10.12.1
Lease-Time Option 51, length 4: 3600
Subnet-Mask Option 1, length 4: 255.255.255.240
Default-Gateway Option 3, length 4: 10.10.12.1
Domain-Name-Server Option 6, length 8: 10.10.12.1,10.10.12.2
Domain-Name Option 15, length 14: "radiocoder.net"
BR Option 28, length 4: 10.10.12.15
END Option 255, length 0

Листинг 55 — Клиент dhcpcd


~> sudo dhcpcd wlan0
dhcpcd[4320]: wlan0: rebinding lease of 10.10.12.5
dhcpcd[4320]: wlan0: leased 10.10.12.5 for 3600 seconds
dhcpcd[4320]: wlan0: adding route to 10.10.12.0/28
dhcpcd[4320]: wlan0: adding default route via 10.10.12.1
dhcpcd[4320]: forked to background, child pid 4362
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 232/279
Листинг 56 — Пример конфигурации сервера ISC-DHCP службы DHCP
option domain-name "site.org";
option domain-name-servers ns1.site.org;
option subnet-mask 255.255.255.0;

default-lease-time 600;
max-lease-time 72400;

subnet 10.254.239.0 netmask 255.255.255.224 {


range 10.254.239.10 10.254.239.20;
option routers rtr-239-0-1.site.org, rtr-239-0-2.site.org;
}

host fantasia {
hardware ethernet 08:00:07:26:c0:a5;9
fixed-address fantasia.site.org;
}

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 233/279


Служба доступа к сети всемирной паутины

Немного истории
В 1989 г. Тим Бернерс-Ли (Tim Berners-Lee) изложил идею глобальной
гипертекстовой системы, позволившую сначала соединить связями текст, а в
дальнейшем — графику, звуки, видео . . . .

Гипертекст
Гипертекст — структурированный текст имеющий логические ссылки на
внутренние и внешние тексты.

Глобальность этой системы предполагала, что данные будут распределяться


по всему миру, а ее основой станет Internet. Система узлов, связанная
гипертекстом получила название World Wide Web, (W3). Впервые
реализация за пределами лабораторий, была осуществлена в декабре 1990 г.
Однако, система постоянно дорабатывалась вплоть до 1993 г.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 234/279


Стабилизация
За три года был предложен и реадизован протокол передачи гипертекстовых
данных (Hyper-Text Transfer Protocol, HTTP), а в ISO был разработан и
описан первый стандарт языка построения гипертекстовых данных
(Hyper-Text Markup Language, HTML). Предложена и реализована
универсальная система адресов (Universal Resourse Locator, URL) для
адресации документов в системе WWW. Появился первый
веб-браузер (web-brouser), в привычном для современного пользователя
виде.

Причины популярности
Решающее значение для всемирного распространения WWW имело то, что
все эти стандарты были сделаны общедоступными.

Гипертекстовая среда WWW и средства мультимедиа вместе образовали


систему «гипермедиа».

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 235/279


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

Архитектура и транспорт
Служба WWW построена по схеме клиент-сервер (веб-браузер и
веб-сервер). В качестве основного транспортного протокола используется
TCP, с зарегистрированным IANA портом 80 (сервер).

Клиент является интерпретатором языка HTML, который в зависимости от


команд (тегов, tags) выполняет различные функции: размещение текста на
экране, обмен информацией с сервером по мере анализа полученного
HTML-текста и др. Сервер обрабатывает запросы клиента на получение
файлов, выполнение программ и др.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 236/279


Для работы с ресурсами в службе используются следующие механизмы:
HTML (Hyper-Text Markup Language) — язык гипертекстовой разметки
документов;
URL (Universal Resource Locator) — унифицированный указатель
ресурсов (адрес ресурса в сети). Каждый ресурс имеет уникальный для
Web адрес, называемый унифицированным (универсальным)
идентификатором ресурса (URI, Universal Resource Identifier);
HTTP (Hyper-Text Transfer Protocol) –– протокол обмена
гипертекстовой информацией;
CGI (Common Gateway Interface) — общий интерфейс шлюза. Создан
для взаимодействия HTTP-сервера с другими программами,
установленными на сервере (например, СУБД).

Описания и спецификации
RFC-1866 — «Hyper-Text Markup Language — HTML 2.0»;
RFC-1945 — «Hyper-Text Transfer Protocol — HTTP/1.0»;
RFC-2616 — «Hyper-Text Transfer Protocol — HTTP/1.1».

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 237/279


Hyper-Text Transfer Protocol — протокол передачи гипертекстовых данных,
используется службой WWW для передачи Web-страниц.
Первый документ RFC-1945 Hypertext Transfer Protocol —
HTTP/1.0 (T. Berners-Lee, R. Fielding, H. Frystyk May 1996);
Последняя версия RFC-2616 Hypertext Transfer Protocol —
HTTP/1.1 (R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach
Tранспортным протоколом для HTTP является протокол TCP, причем сервер
HTTP (сервер Web) находится в состоянии ожидания соединения со
стороны клиента стандартно по порту 80 TCP, а клиент HTTP (браузер
Web) является инициатором соединения.

Адресация ресурсов Web


Регулярный формат URL:
protocol://user:password@host:port/path/file?paremeters#fragment

1 protocol — прикладной протокол, посредством которого получают


доступ к ресурсу;
2 user –– пользователь, от имени которого получают доступ к ресурсу;

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 238/279


3 password — пароль пользователя для аутентификации при доступе к
ресурсу;
4 host –– адрес IP или имя сервера, на котором расположен ресурс;
5 port –– номер порта, на котором работает сервер, предоставляющий
доступ к ресурсу;
6 path –– путь к файлу, содержащему ресурс;
7 file –– файл, содержащий ресурс;
8 paremeters –– параметры для обработки ресурсом-программой;
9 fragment –– точка в файле (якорь, anchor), начиная с которой
следует отображать ресурс.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 239/279


Взаимодействие между клиентом и сервером Web осуществляется путем
обмена сообщениями. Сообщения HTTP делятся на запросы клиента
серверу и ответы сервера клиенту. Формат запросов и ответов выглядит
следующим образом:
1 начальная строка;
2 заголовок 1;
3 заголовок 2;
4 ...;
5 заголовок N;
6 пустая строка;
7 тело сообщения (может отсутствовать).
Формат начальной строки (start-line) клиента и сервера различаются.
Заголовки бывают четырех видов:
1 общие заголовки (general-headers), которые могут присутствовать как в
запросе, так и в ответе;
2 заголовки запросов (request-headers), которые могут присутствовать
только в запросе;
3 заголовки ответов (response-headers), которые могут присутствовать
только в ответе;
4 заголовки объекта (entity-headers), которые относятся к телу
сообщения и описывают его содержимое;
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 240/279
Каждый заголовок состоит из названия, символа двоеточия : и значения.

Заголовок Назначение
Заголовки объекта
Content-Encoding Способ, которым закодировано тело сообщения,
например, с целью уменьшения размера.
Content-Length Длина сообщения в байтах.
Expires Дата и время, когда ресурс на сервере будет
изменен, и его нужно получать заново.
Last-Modified Дата и время последней модификации
содержимого.
Заголовки ответа
Location URI ресурса, к которому нужно обратиться для
получения содержимого.
Server Название программного обеспечения сервера,
приславшего ответ.
Age Число секунд, через которое нужно повторить
запрос для получения нового содержимого.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 241/279


Заголовок Назначение
Заголовки запроса
Accept-Charset Кодировки символов, в которых клиент может
принимать текстовое содержимое.
Accept-Encoding Способ, которым сервер может закодировать
сообщение.
Host Хост и номер порта, с которого запрашивается
документ.
User-Agent Название программного обеспечения клиента.
Общие заголовки
Connection Указывает серверу на завершение (close) или
продолжение (keep-alive) сеанса.
Date Дата и время формирования сообщения.
Pragma Специальные, зависящие от реализации
команды, касающиеся передаваемого
содержимого.
Transfer-Encoding Способ кодирования сообщения при передаче.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 242/279


Запрос от клиента к серверу
Запрос от клиента к серверу состоит из строки запроса (request-line),
заголовков (общих, запросов, объекта) и, возможно, тела сообщения.

Регулярный формат строки запроса:


<Команда HTTP> <Идентификатор запрашиваемого ресурса> <Версия HTTP>
Основные команды протокола HTTP:

Команда Назначение
OPTIONS Запрос информации об опциях соединения (например,
методах, типах документов, кодировках), которые
поддерживает сервер для запрашиваемого ресурса.
GET Позволяет получить информацию, связанную с
запрашиваемым ресурсом. Если идентификатор
запрашиваемого ресурса указывает на документ,
то сервер возвращает содержимое этого документа
(содержимое файла). Если запрашиваемый ресурс является
приложением (программой), формирующим в процессе
своей работы некоторые данные, то в теле сообщения
ответа возвращаются эти данные.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 243/279


Команда Назначение
HEAD Идентична команде GET, за исключением того, что сервер
не возвращает в ответе тело сообщения.
POST Используется для запроса, при котором адресуемый сервер
принимает данные, включенные в тело сообщения (объект)
запроса, и отправляет их на обработку приложению,
указанному как запрашиваемый ресурс..
PUT Тело сообщения, которое передается в запросе, сохраняется
на сервере, причем идентификатор запрашиваемого ресурса
будет идентификатором сохраненного документа.
DELETE Запрос на удаление ресурса, имеющего запрашиваемый
идентификатор.
TRACE Используется для тестирования или диагностики.
Получатель запроса (сервер Web) отправляет полученное
сообщение обратно клиенту как тело сообщения ответа.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 244/279


После получения и интерпретации сообщения запроса, сервер отвечает
сообщением HTTP ответа.

Ответ сервера клиенту


Ответ сервера клиенту состоит из строки состояния (status-line) и имеет
регулярный формат:
<Версия HTTP> <Код состояния> <Поясняющая фраза>

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

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


цифры не имеют определенной роли в классификации. Имеется 5 значений
первой цифры:

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 245/279


1 1xx — Информационные коды — запрос получен, продолжается
обработка;
2 2xx — Успешные коды — действие было успешно получено, понято и
обработано;
3 3xx — Коды перенаправления — для выполнения запроса должны быть
предприняты дальнейшие действия;
4 4xx — Коды ошибок клиента — запрос имеет ошибку синтаксиса или
не может быть выполнен;
5 5xx — Коды ошибок сервера — сервер не в состоянии выполнить
допустимый запрос.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 246/279


Важные особенности протокола

Экземпляр протокола HTTP устанавливает отдельное соединение TCP


на каждый запрос; в более поздних версиях HTTP разрешено делать
несколько запросов в ходе одного соединения TCP, однако, по
умолчанию, веб-браузер запрашивают только страницу и включённые в
неё объекты (изображения, каскадные стили и т. п.), а затем закрывает
соединение;
При пересылке данных по протоколу HTTP передаётся заголовок
«Сontent-Type: тип/подтип», позволяющую клиенту однозначно
определить, каким образом обрабатывать получаемые данные;
Благодаря команде «POST» HTTP позволяет клиенту присылать на
сервер параметры, которые передаются подпрограмме
CGI (скрипт-программе). Для таких задач в поздних версиях HTML
введены формы. Механизм передачи запросов позволил, например,
реализовать клиентский интерфейс к поисковой машине.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 247/279


Архитектура серверной службы
Современная служба WWW состоит из нескольких прослоек. Основу
службы как и ранее составляет веб-сервер, обрабатывающий запросы
клиентов. Однако, для расширения мультимедийный и функциональных
возможностей службы используется ряд надстроек над протоколом HTTP
(SSL, WebDAV и т. д.). С другой стороны, для построения веб-приложений
существует устоявшийся набор дополнительных служб (применяемый
де-факто стандартно), для которых веб-сервер является лишь транспортной
прослойкой, передающей данные к приложениям выполняющимся на
сервере.
Архитектура LAMP. Современный веб-сервер (многопользовательский сайт,
форум, блог, галлерея и т. д.) состоит из набора приложений:
1 Многопользовательскиая сетевая операционная система (например,
хост-сервер GNU/Linux);
2 Веб-сервер (например, Apache);
3 Реляционная БД и СУБД (например, MySQL);
4 Скрипт-программа или препроцессор для разборки и обработки
запросов к приложению и БД (например, PHP).

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 248/279


Основные реализации

Веб-серверы
Apache — a patchy server, т. е. исправленный сервер;
IIS — Internet Information Services, поддерживает службы IIS HTTP,
HTTPS, FTP, POP3, SMTP, NNTP;
nginx — engine x, веб-сервер и почтовый прокси-сервер, разработчик
Игорь Сысоев (http://www.sysoev.ru/);
lighttpd — lighty http daemon, веб-сервер, разрабатываемый с
расчётом на быстроту и защищённость.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 249/279


Листинг 57 — Пример запроса страницы у сервера службы WWW
~> telnet 10.10.12.1 80
Trying 10.10.12.1...
Connected to 10.10.12.1.
Escape character is ’^]’.
GET http://10.10.12.1/index.html http/1.0

HTTP/1.0 200 OK
Date: Thu, 04 Dec 2014 20:55:22 GMT
Server: Apache/2.2.23 (FreeBSD) mod_scgi/1.12 PHP/5.4.12 DAV/2
Last-Modified: Thu, 04 Dec 2014 20:54:27 GMT
ETag: "c7413-7b-5096a2a7446c0"
Accept-Ranges: bytes
Content-Length: 123
Content-Type: text/html
X-Cache: MISS from atlas
Via: 1.1 atlas:3128 (squid/2.7.STABLE9)
Connection: close

<html>
<title>Welcome page</title>
<head>Welcome to site!</head>
<body>This is the main site page</body>
</html>
Connection closed by foreign host.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 250/279


Листинг 58 — Вывод утилиты tcpdump
~> sudo tcpdump -i wlan0 -lvn tcp and \( src port 80 or dst port 80 \) \
and ip host 10.10.12.1
10.10.12.5.42946 > 10.10.12.1.80: [S], seq 4157395191, length 0
.80 > .42946: [S.], seq 2524975084, ack 4157395192, length 0
.42946 > .80: [.], seq 1, ack 1, length 0
.42946 > .80: [P.], seq 1:44, ack 1, length 43
.80 > .42946: [.], seq 1, ack 44, length 0
.42946 > .80: [P.], seq 44:46, ack 1, length 2
.80 > .42946: [P.], seq 1:352, ack 46, length 351
.42946 > .80: [.], seq 46, ack 352, length 0
.80 > .42946: [P.], seq 352:475, ack 46, length 123
.42946 > .80: [.], seq 46, ack 475, length 0
.80 > .42946: [F.], seq 475, ack 46, length 0
.42946 > .80: [F.], seq 46, ack 476, length 0
.80 > .42946: [.], seq 476, ack 47, length 0

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 251/279


Службы альтернативные W3 I

W3 и FTP
До реализации и распространения службы W3, основную нагрузку по
обмену данными выполняла служба передачи файлов FTP. В современной
сети Internet служба FTP также является одной из основных служб
файлового обмена.

Существует большое количество анонимных серверов службы FTP,


предназначенных для исполнения различных задач — частные и публичные
файловые хранилища, точки коллективного обмена файлами, резервные
хранилища, хостинг и т. д. Однако, ресурсы распростраяемые на условиях
коммерческой лицензии, или ресурсы требующие соблюдения авторских
прав, практически полностью вытеснены в пиринговые оверлейные сети
обмена информацией (BitTorrent, eD2k и т. д.).

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 252/279


Службы альтернативные W3 II

Archie — индекс ресурсов анонимных серверов FTP в сети Internet.


Индекс-сервер Archie осуществляет поиск файла, имя которого
содержит указанное регулярное выражение. В ответ формируется
список серверов FTP, для которых было найдено совпадение с именами
файлов. Для непосредственного доступа (загрузки файлов)
используется клиент FTP. До широкого распространения W3 в сети
Internet существовало множество публичных индекс-серверов Archie;
WAIS — Wide Area Information Servers — «информационные серверы
глобальных сетей». В отличии от Archie, производит поиск по
регулярному выражению содержащемуся внутри ресурса, а не только в
его названии (имени файла). Сервер WAIS хранит информацию в БД,
разделенную по тематическим направлениям, например связанным с
компьютерами и т. д. При использовании WAIS, необходимо указать
базы данных для поиска и ключевые слова;

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 253/279


Службы альтернативные W3 III
Gopher — сетевой протокол поиска и передачи файлов в сети Internet, а
также одноименное меню-ориентированное приложение gopher для
работы с разнообразными сервисами Internet (Archie, WAIS и
анонимный FTP). Служба сервера отображает список документов,
доступных через Internet, в виде иерархической файловой структуры, в
вершине которой расположены каталоги, содержащие тематические
документы (файлы). Особое распространение приобрел до реализации
HTTP и W3. С 2000 года реализации (исходные тексты) эталонного
клиента и сервера выпущены под некоммерческой лицензией (GNU
GPL). Принцип взаимодействия основан на клиент-серверной
архитектуре, в качестве основного протокола транспортного уровня
используется TCP, имеет закрепленный IANA номер порта
70 (TCP/UDP). Официальное описание и спецификация — RFC-1436;
Veronica — Very Easy Rodent-Oriented Netwide Index to Computerized
Archives — «очень простая система поиска в архивах Gopher».
Индекс (служба поиска) заголовков каталогов и ресурсов в сети
системы Gopher. Veronica, по сути поисковый робот, осуществляля
поиск по серверам Gopher.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 254/279


Службы альтернативные W3 IV

FidoNet — международная некоммерческая офлайновая компьютерная


сеть построенная поверх глобальной всемирной телефонной системы.
Первая реализация датируется 1984 годом. Помимо названия сети, под
данным термином также подразумевается набор протоколов обмена
данными и процедур, которые позволяют узлам сети обмениваться
данными, файлами и электронной почтой. Сообщения и файлы хранятся
на компьютере пользователя, и обрабатываются и подготавливаются к
отправке в то время, когда пользователь отключен от сети. Передача
почты или файлов обычно осуществляется в «зоновый почтовый
час» (Zone mail hour). Литература — Н. Филимонов, 64 Кбайта о
FidoNet, ссылка — http://www.fidonet.org.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 255/279


Служба пересылки электронной почты I
Существует несколько основных служб пересылки электронной почты:
X.400 — набор рекомендаций ITU (International Telecommunication
Union, Международный Союз Электросвязи) для прикладного уровня
и протокол, описывающий систему и службу передачи электронных
сообщений. Описание службы полностью основывается на модели
ЭМВОС (ISO/OSI), поэтому не имеет зависимостей от конкретных
реализаций физического, канального, сетевого, транспортного и прочих
уровней модели;
UUCP — служба обмена электронной почтой, основанная на
использовании утилиты uucp (Unix-to-Unix CoPy) и одноименного
протокола. Фактически является расширением утилиты cp,
предназначенной для копирования файлов внутри файловой системы
локальной машины. Протокол UUCP и утилита uucp позволяют
копировать электронные сообщения (фактически файлы) на удаленную
машину используя телефонное модемное соединение или соединение
поверх протоколов TCP/IP. Серверная служба (демон uucpd)
использует зарегистрированный IANA порт 540 (TCP/UDP). Описание
службы — RFC-976;
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 256/279
Служба пересылки электронной почты II

FidoNet EchoMail — служба передачи электронной почты в форме


эхоконференции в сети FidoNet;
SMTP — Simple Mail Transfer Protocol, простой протокол передачи
электронной почты. Основной протокол передачи электронной почты
для сетей TCP/IP, обеспечивающий работу службы электронной почты
в сети Internet. Стандарт электронной почты де-факто. Используется
для передачи почтовых сообщений от почтовой программы отправителя
до электронного почтового ящика получателя. Описание службы,
основные принципы построения и функционирования электронной
почты приведены в RFC-2821.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 257/279


Формат электронного сообщения

Формат сообщения электронной почты описан в документе RFC-2822.


Электронное письмо состоит из трех частей:
1 Конверт (Envelope), содержащий адреса отправителя и получателей
сообщения, эта информация используется только при пересылке
сообщения по протоколу SMTP, получателю она недоступна;
2 Заголовок (Header), содержащий служебную информацию,
формируемую программами, участвующими в передаче сообщения,
такую как адреса отправителя и получателей, которые могут отличаться
от используемых в конверте, тему сообщения, время отправки, сведения
о пересылке и об используемых для создания сообщения программах и
т. д., заголовок завершается пустой строкой;
3 Тело (Body), содержащее само сообщение, созданное отправителем и
подлежащее доставке получателю.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 258/279


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

Символы кодировки
В заголовке допускается использование только символов в кодировке
ASCII (US). Преобразование текстовых кодировок в электронной почте
описано в документе RFC-2047.

Тело сообщения
Тело сообщения, если это не просто текст, записанный латинскими буквами,
должно быть закодировано в соответствии со спецификацией
MIME (RFC-2045). На приемной стороне оно при необходимости
декодируется и преобразуется в понятный пользователю вид.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 259/279


Поле заголовка Назначение
Date: Время отправки сообщения.
From: Адрес отправителя.
Reply-To: Адрес для ответа.
To: Адреса получателей.
Cc: Адреса получателей копий.
Bcc: Адреса получателей скрытых копий.
Message-ID: Уникальный идентификатор сообщения.
In-Reply-To: Уникальный идентификатор сообщения, на которое
отвечает данное сообщение.
References: Уникальные идентификаторы всех сообщений в
цепочке ответов.
Subject: Тема сообщения.
Return-Path: Адрес отправителя, указанный на конверте
сообщения.
Received: Информация о прохождении сообщения. Каждый
узел, через который прошло сообщение,
должен добавить в заголовок поле Received:,
содержащее имена и адреса IP узлов, пославших и
принявших сообщение, время прохождения и т. д.
MIME-Version: Используемая версия MIME.
Content-type: Тип данных, используемых в теле сообщения.
Content-Transfer-Encoding: Способ кодирования символов не входящих в набор
ASCII, используемый в тексте сообщения.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 260/279


Адресация электронной почты в Internet

Маршрутно-независимую адресация
Электронная почта в Internet использует маршрутно-независимую
адресацию. Это значит, что адрес пользователя остается неизменным
независимо от того, откуда посылается сообщение.

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


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

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

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 261/279


Формат электронного адреса описан в RFC-2822. В общем виде он имеет
следующий формат: имя_пользователя@почтовый_домен
Имя_пользователя — идентификатор пользователя, уникальный в
пределах одного почтового домена;
@ ([at]) — символ-разделитель;
Почтовый_домен — уникальный идентификатор почтовой системы,
обслуживающей указанный домен.

Символы в именах
Имя пользователя может состоять из цифр, латинских букв и символов
стандартного набора ASCII.
Имя почтового домена имеет тот же формат, какой используется в
доменных именах Internet RFC-1034.
Кроме значимой части, используемой при маршрутизации сообщения, адрес
может содержать комментарии в виде произвольных текстовых строк до и
после значимой части:
комментарий <имя_пользователя@почтовый_домен> комментарий
Небаев И.А. <inebaev@spbgut.ru> (Каф. СС и ПД С-Пб ГУТ)
Информация по обе стороны угловых скобок при доставке сообщения
игнорируется.
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 262/279
Маршрутизация электронной почты

Принцип маршрутизации
Для маршрутизации электронной почты в Internet, как и для установления
соответствия между доменными именами узлов сети и их адресами IP ,
используется система DNS.

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


посылает запрос DNS с указанием имени почтового домена получателя;
2 В ответ почтовый сервер получает список узлов, принимающих почту
для данного домена. Список представляется в виде записей MX (Mail
eXchange).
Одному имени почтового домена могут соответствовать несколько записей
МХ с различными приоритетами. Приоритеты обозначаются целыми числами,
с их помощью определяется, в каком порядке следует обращаться к узлам,
принимающим почту для данного домена.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 263/279


Листинг 59 — Вывод утилиты dig — запрос mx
~> dig sut.ru mx
; DiG 9.9.5
;; QUESTION SECTION:
;sut.ru. IN MX
;; ANSWER SECTION:
sut.ru. 86400 IN MX 10 mail.sut.ru.
sut.ru. 86400 IN MX 50 mail1.sut.ru.
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 11 21:35:27 MSK 2014
;; MSG SIZE rcvd: 78

Листинг 60 — Вывод утилиты dig — запрос a


~> dig mail.sut.ru a
; DiG 9.9.5
;; QUESTION SECTION:
;mail.sut.ru. IN A
;; ANSWER SECTION:
mail.sut.ru. 86400 IN A 91.238.228.4
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Dec 11 21:38:15 MSK 2014
;; MSG SIZE rcvd: 56
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 264/279
Архитектура электронной почты Internet
Электронная почта сети Internet представляет собой систему обмена
почтовыми сообщениями (E-Mail), службу реализующую хранение и
обработку почтовых сообшений (E-Mail server daemon), и набор протоколов
(SMTP, POP, IMAP), формализующий формат пересылаемых сообщений и
алгоритм взаимодействия удаленных почтовых машин.
Структурные элементы системы электронной почты:
Mail User Agent, MUA — пользовательский агент, или клиентская
почтовая программа;
Mail Transfer Agent, MTA — транспортный агент, или почтовый сервер;

Отправитель Получатель

MUA SMTP MTA MTA POP MUA


IMAP
Почтовый сервер Почтовый сервер
отправителя получателя

Рис. 58 — Упрощенная архитектура E-Mail

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 265/279


Почтовый сервер Почтовый сервер Почтовый сервер
отправителя пересылки получателя

MTA 1 MTA 2 MTA N

SMTP SMTP
Агент локальной
доставки

SMTP LDA

POP E-Mail Хранилище


MUA MUA электронной
IMAP Storage почты
Клиент Клиент
отправителя получателя

Рис. 59 — Детализировання архитектура E-Mail

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 266/279


Mail User Agent
MUA предназначен для подготовки, отправки, получения и просмотра
электронных писем. Это программа, установленная на компьютере
пользователя.
Задача электронной почты, по сути дела, сводится к тому, чтобы доставить
сообщение от MUA отправителя на MUA получателя. Подготовка к
отправке заключается в приведении сообщения к принятому в Internet
формату, описанному в RFC-2822.
MUA посылает сообщения по протоколу SMTP через локальный MTA,
используемый для отправки почты RFC-821. В качестве транспортного
протокола используется TCP, зарегистрированный IANA номер порта 25
TCP/UDP (465 TCP SMTPs TLS/SSL).
Входящие письма MUA забирает из хранилища сообщений по протоколу,
предназначенному для получения почты. Как правило для этой цели
используется один из двух протоколов:

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 267/279


Post Office Protocol, Version 3 (POP3) –– протокол почтового
отделения, версия 3, описанный в RFC-1939, позволяющий
просматривать сообщения в почтовом ящике, забирать и удалять их. В
качестве транспортного протокола используется TCP,
зарегистрированный IANA номер порта 110 TCP/UDP (995 POP3s
TLS/SSL);
Internet Message Access Protocol (IMAP) –– протокол доступа к
сообщениям, описанный в RFC-3501, обладающий более широкими
возможностями манипулирования почтовыми ящиками, чем POP3, в
частности он позволяет работать с несколькими ящиками одновременно,
не только считывать и удалять, но и создавать и исправлять сообщения.
В качестве транспортного протокола используется TCP,
зарегистрированный IANA номер порта 143 TCP/UDP (993 IMAP4s
TLS/SSL).

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 268/279


Реализации MUA
Основные реализации клиентов электронной почты:
Microsoft Outlook;
Mozilla Thunderbird (ранее Netscape Communicator);
The Bat!;
Sylpheed;
Eudora, Elm, Pine, Alpine и др.;
Web E-mail;

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 269/279


Mail Transfer Agent
MTA представляют собой узлы, через которые передаются электронные
сообщения. Письмо, сформированное MUA, достигает хранилище
сообщений, содержащее почтовый ящик получателя, проходя через один или
несколько MTA, последний из которых передает письмо агенту локальной
доставки (Local Delivery Agent, LDA).

На MTA возлагаются следующие задачи:


Разбор адресов получателей;
Раскрытие списков рассылки и почтовых псевдонимов;
Определение маршрута сообщения на основании анализа адресов
получателей и записей МХ, получаемых от сервера DNS.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 270/279


Проверки MTA
MTA должен проверять соответствие действительности идентификационных
данных получаемых им от удаленного MTA. Следует проверять соответствие
доменного имени, которое клиент сообщает в приветствии, его адресу
IP (см. обратный запрос DNS). Также нужно удостовериться в
существовании почтового домена, указанного в почтовом адресе
отправителя. Если в доменной части адреса получателя указан почтовый
домен, обслуживаемый данным MTA, то следует проверить, зарегистрирован
ли в этом домене указанный адресат.

Документ RFC-2505 рекомендует принимать почту только при выполнении


хотя бы одного из следующих условий:
1 Адрес IP клиента входит в список адресов клиентов, обслуживаемых
данным MTA;
2 Получатель сообщения зарегистрирован в почтовом домене,
обслуживаемом данным MTA;
3 Клиент прошел процедуру аутентификации.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 271/279


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

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

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

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


в очередь. MTA регулярно предпринимает новые попытки отправить
сообщения из очереди. Если это не удается за определенный срок, обычно
за четыре часа, то отправителю посылается предупреждение о задержке
доставки. Но сообщение остается в очереди, и попытки его отправить
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 272/279
продолжаются. Если в течение длительного времени, обычно пяти дней,
сообщение так и не удается доставить, оно удаляется из очереди, а
отправителю посылается сообщение о невозможности доставки письма.

Требования к MTA
Основные требования к MTA и к MUA описаны в RFC-1123 и уточнены в
RFC-2821 и в RFC-2822.

Реализации MTA
Основные реализации серверов электронной почты:
Microsoft Exchange;
Sendmail;
Postfix;
Exim;
Qmail.

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 273/279


Листинг 61 — Отправка E-Mail с помощью утилиты telnet
~> telnet foo.org 25
S. 220 foo.org Service Ready
C. EHLO bar.org
S. 250-foo.org greets bar.org
S. 250-8 BITMIME
S. 250-SIZE
S. 250-DSN
S. 250 HELP
C. MAIL FROM:<johnsmith@bar.org>
S. 250 OK
C. RCPT TO:<jjones@foo.org>
S. 250 OK
C. RCPT TO:<green@foo.org>
S. 550 No such user here
C. RCPT TO:<brown@foo.org>
S. 250 OK
C. DATA
S. 354 Start mail input; end with <CRLF>.<CRLF>
C. Hello everybody!
C. .
S. 250 OK
C. QUIT
S. 221 foo.org Service closing transmission channel

TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 274/279


Листинг 62 — Получение E-Mail с помощью утилиты telnet
~> telnet foo.org 110
S. +OK ready <6584.1077893295@foo.org>
C. USER brown
S. +OK Password required for brown.
C. PASS *****
S. +OK brown has 3 visible messages in 223385 octets.
C. LIST
S. +OK 3 visible messages (223385 octets)
S. 1 111293
S. 2 111285
S. 3 807
S. .
C. TOP 3 1
S. +OK Message follows
S. Return-Path: <johnsmith@bar.org>
S. ...
S. Status: RO
S. Hello everybody!
S. .
C. DELE 3
S. +OK Message 3 has been deleted.
C. STAT
S. + OK 2 222578
C. QUIT
S. +OK Pop server at foo.org signing off.
TCP/IP : Службы и протоколы прикладного уровня стека TCP/IP 275/279
Приложение: Темы экзаменационных вопросов I

1 Интерфейсы прикладного программирования (API) стека TCP/IP;


2 Процессы стандартизации стека TCP/IP и типы основных
стандартизирующих документов;
3 Архитектура стека TCP/IP;
4 Объединение интернет-сетей и сеть Internet (основные понятия и
элементы интернет-сетей);
5 Понятие инкапсуляции и описание процедуры инкапсуляции;
6 Описание клиент-серверной модели стека TCP/IP;
7 Канальный уровень стека TCP/IP. Инкапсуляция IEEE 802 и Ethernet;
8 Канальный уровень стека TCP/IP. Инкапсуляция SLIP и PPP;
9 Канальный уровень стека TCP/IP. Интерфейс обратной связи;
10 Протокол определения адреса (ARP), протокол обратного
преобразования адресов (RARP);
11 Протокол Internet, формат дейтаграммы;
12 Протокол Internet, принципы адресации сетей IPv4;
TCP/IP : Приложение: Темы экзаменационных вопросов 276/279
Приложение: Темы экзаменационных вопросов II
13 Протокол Internet, принципы маршрутизации в сетях IPv4;
14 Протокол Internet, понятие процедуры фрагментации;
15 Протокол Internet v6, основные отличия от предыдущих версий и
формат дейтаграммы;
16 Протокол Internet v6, расширенные заголовки;
17 Протокол Internet v6, принципы адресации сетей IPv6;
18 Протокол управляющих сообщений Internet (ICMP), основные понятия
и типы сообщений;
19 Протокол управляющих сообщений Internet v6 (ICMPv6), приложения и
утилиты ICMP;
20 Алгоритмы и протоколы транспортного уровня, основные понятия;
21 Протокол передачи пользовательских дейтаграмм (UDP), формат
дейтаграммы и основные службы;
22 Транспортный протокол управления передачей данных (TCP), основные
понятия и формат сегмента;

TCP/IP : Приложение: Темы экзаменационных вопросов 277/279


Приложение: Темы экзаменационных вопросов III
23 Транспортный протокол управления передачей данных (TCP), конечный
автомат состояния сокетов, утилита netstat;
24 Транспортный протокол управления передачей данных (TCP), алгоритм
установления логического соединения;
25 Транспортный протокол управления передачей данных (TCP), алгоритм
завершения логического соединения;
26 Транспортный протокол управления передачей данных (TCP),
механизмы обеспечения надежности и алгоритмы передачи данных по
соединению TCP;
27 Транспортный протокол управления передачей данных (TCP), важные
параметры передачи данных TCP, опции TCP;
28 Прикладной уровень стека TCP/IP, служба системы доменных имен
(DNS);
29 Прикладной уровень стека TCP/IP, служба точного времени сети
Internet (NTP);
30 Прикладной уровень стека TCP/IP, служба автоматического
конфигурирования узлов (DHCP);
TCP/IP : Приложение: Темы экзаменационных вопросов 278/279
Приложение: Темы экзаменационных вопросов IV

31 Прикладной уровень стека TCP/IP, служба доступа к сети всемирной


паутины (WWW);
32 Прикладной уровень стека TCP/IP, службы передачи файлов сети
Internet (xFTP);
33 Прикладной уровень стека TCP/IP, служба электронной почты сети
Internet (E-Mail), адресация и маршрутизация.
34 Прикладной уровень стека TCP/IP, архитектура службы электронной
почты сети Internet (E-Mail).

TCP/IP : Приложение: Темы экзаменационных вопросов 279/279