Сравнение сетей с коммутацией пакетов и каналов

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

Коммутация каналов	Коммутация пакетов
– Необходимость в предварительном установлении соединения	+ Отсутствие этапа установления соединения (Дейтаграммная передача)
– Нерациональное использование пропускной способности (+ трафик реального времени передается без задержек)	+ Автоматическое динамическое распределение пропускной способности физического канала между абонентами
– Сеть может отказать абоненту в установлении соединения	+ Сеть всегда готова принять данные от абонента
– Потеря соединения при выходе из строя транзитного узла либо промежуточной линии связи	+ Соединение существует, пока работает хотя бы одна линия связи (– кроме виртуального канала)
+ Адрес требуется только на этапе установления соединения	– Адрес и другая служебная информация передаются с каждым пакетом
+ Гарантированная пропускная способность (полоса пропускания) для взаимодействующих абонентов	– Пропускная способность сети для абонентов неизвестна, задержки носят случайный характер
+ Высокая надежность передачи	– Возможные потери данных из-за переполнения буферов (+ если не предусмотрен механизм проверки)

Internet Protocol v4

Существует три типа адресации, описанных в стеке TCP/IP:

• локальные (аппаратные) адреса,

• сетевые адреса,

• символьные (доменные) адреса.

На сетевом уровне, как это видно из названия, функционирует сетевая адресация. В стеке протоколом, отвечающим за адресацию сетевого уровня, является протокол IP (Internet Protocol), а адреса называются IP-адресами.

IP-адрес является 32-битовой (4-байтовой) последовательностью и в обычном своём виде выглядят так: 11000000 10101000 00011000 00000001.

Однако для восприятия человеку удобнее десятерично-точечная форма записи (нотация): 192.168.24.1. В данной форме записи адрес делится на четыре октета (по 8 бит), октеты разделяются точками.

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

1.1.1. Классовая адресация

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

Таблица 4.1.

Классы IP-адресов

Класс	Первые биты класса	Диапазон адресов в классе	Количество сетей в классе	Количество конечных адресов
A	0	0.0.0.0 – 127.255.255.255	27=128	224=16 777 216
B	10	128.0.0.0 – 191.255.255.255	214=16 384	216=65 536
C	110	192.0.0.0 – 223.255.255.255	221=2 097 152	28=256
D	1110	224.0.0.0 – 239.255.255.255	—	—
E	1111	240.0.0.0 – 255.255.255.255	—	—

Классы A, B и C были спроектированы для нужд больших, среднего размера и малых сетей соответственно. Адреса класса D были отведены для сетей многоадресной передачи. Адреса классаE были зарезервированы для экспериментальных целей.

Количество сетей в каждом классе и количество узлов в каждой подсети в классовой адресации определены однозначно, что исключает какую-либо гибкость при проектировании частной сети. Например, имеется корпоративная сеть на 200 узлов, от 10 до 50 узлов в различных отделах (бухгалтерия, отдел кадров, колл-центр и т.д.). Для общего количества узлов достаточно выделить один блок класса C (192.168.0.0 – 192.168.0.255). Однако такой сетью тяжело будет управлять. По какому принципу выдавать адреса? Как определить, в каком отделе находится узел с адресом, например, 192.168.0.108? Опять же при выдаче адресов вручную необходимо вести запись (запоминать) уже выданных номеров, чтобы отслеживать количество выданных/свободных адресов.

Другой вариант: для каждого отдела использовать свою сеть. Тогда точно известно, что в отделе кадров адреса имеют диапазон 192.168.0.(0 – 255), в бухгалтерии диапазон 192.168.1.(0 – 255), и т.д. Однако при таком подходе адресное пространство будет использоваться нерационально, поскольку очень большое количество адресов в каждой из сетей останутся неиспользованными. Отсутствие такой гибкости в классовой IP-адресации привело к созданию бесклассовой адресации.

Бесклассовая адресация

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

Маска подсети – это двоичное число из 32 бит, в котором последовательно записаны единицы в тех разрядах, которые в IP-адресе представляют номер сети, и нули – в остальных разрядах.

Маска может быть записана аналогичным адресу способом в четыре октета. Например, 192.168.0.0 255.255.255.128 – означает, что в сети с адресом 192.168.0 можно использовать следующие адреса узлов: 0-127. Эту же маску можно записать иначе: 192.168.0.0/25, где /25 означает, что в маске имеется 25 разрядов единиц.

Сеть делится на подсети с условием, что в подсети будет A=2ⁿ адресов, где n – количество нулей в маске. Одним из способов деления сети на подсети является «Метод квадратов».

В примере с корпоративной сетью одну сеть 192.168.0.0 можно разделить на подсети с помощью масок следующим образом. Известно, что в отделе кадров работает 10 сотрудников, а также имеются два сетевых принтера. Для такого количества узлов достаточно будет 12 < 2⁴=16 адресов: 192.168.0.0 – 192.168.0.15. Итак, имеем подсеть отдела кадров 192.168.0.0/28. Колл-центру требуется 50 адресов, для которых будет выделена подсеть 192.168.0.64/26 (192.168.0.64 – 192.168.0.127). И таким образом одна большая сеть класса C поделится на необходимое количество подсетей.

Особые адреса

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

Адресом подсети (Network address) является такой адрес, в записи которого все биты адреса узла имеют значение 0. Такой адрес может быть указан только в качестве адреса отправителя.

Широковещательным адресом (Broadcast address) является такой адрес, в записи которого все биты адреса узла имеют значение 1. Такой адрес может быть указан только в качестве адреса назначения. Пакет с таким адресом назначения получат все узлы сети (рассылка).

Адреса подсети и широковещательные адреса не могут быть заданы в качестве адреса узла. Таким образом, формула расчета количества узлов в подсети принимает вид: N=A–2=2ⁿ–2.

Возвращаясь к примеру с корпоративной сетью отметим, что в подсети отдела кадров адресом сети будет являться 192.168.0.0, а широковещательным – 192.168.0.15. Тогда узлы будут иметь значения 1-14 в последнем октете. Аналогично и в других подсетях – по минус два адреса в каждой.

Отсюда следует первый минус бесклассовой адресации: при увеличении количества подсетей увеличивается и количество адресов «съедаемых» адресами подсети и широковещательным.

Также особым адресом является IP-адрес, первый октет которого равен 127. Этот адрес называется обратным петлевым адресом (loopback) и является внутренним адресом стека протоколов компьютера. Он используется для тестирования программ, а также для организации клиентской и серверной частей программ, установленных на одном компьютере. Когда программа посылает данные по IP-адресу 127.x.x.x, то данные не передаются в сеть, а возвращаются на верхний уровень того же компьютера, как только что принятые из сети, образуя тем самым «петлю».

0.0.0.0 – представляет адрес шлюза по умолчанию, т.е. адрес компьютера, которому следует направлять информационные пакеты, если они не нашли адресата в локальной сети.

255.255.255.255 – широковещательный адрес. Сообщение, переданное по этому адресу, получают все узлы сети, в которой находится отправитель (сообщение передаётся только в пределах локальной сети).

    Частные и публичные адреса

Для возможности использования одних и тех же адресов в различных локальных сетях было выделено несколько диапазонов т.н. частных IP-адресов. Частный (внутренний, локальный, «серый») IP-адрес – адрес, не используемый в сети Интернет. Следующие диапазоны определены для использования в локальных сетях:

1. 10.0.0.0 – 10.255.255.255 (маска подсети /8);

2. 172.16.0.0 – 172.31.255.255 (маска подсети 255.240.0.0 или /12);

3. 192.168.0.0 – 192.168.255.255 (маска подсети /16).

Также к частным адресам относят адреса петлевых интерфейсов: 127.0.0.0 – 127.255.255.255.

Остальные IP-адреса (классов A, B и C) называют публичными (внешними, глобальными, «белыми»). Они условно могут использоваться в сети Интернет.

Формат заголовка IPv4

Структура IP пакетов версии 4 представлена на рисунке 4.1.

Версия – для IPv4 значение поля должно быть равно 4.

§  IHL (Internet Header Length) – длина заголовка IP-пакета в 32-битных словах (dword). Именно это поле указывает на начало блока данных в пакете. Минимальное корректное значение для этого поля равно 5.

§  Тип обслуживания (Type of Service, TOS) – байт, содержащий набор критериев, определяющих тип обслуживания IP-пакетов. Описание байта обслуживания побитно:

·    0-2 – приоритет (precedence) данного IP-пакета,

·    3 – требование ко времени задержки (delay) передачи IP-сегмента (0 – нормальная, 1 – низкая задержка),

·    4 – требование к пропускной способности (throughput) маршрута, по которому должен отправляться IP-сегмент (0 – низкая, 1 – высокая пропускная способность),

·    5 – требование к надежности (reliability) передачи IP-сегмента (0 – нормальная, 1 – высокая надежность),

·    6-7 – ECN – явное сообщение о задержке (управление IP-потоком).

§  Длина пакета - длина пакета в октетах, включая заголовок и данные. Минимальное корректное значение для этого поля равно 20, максимальное 65535.

§  Идентификатор – значение, назначаемое отправителем пакета и предназначенное для определения корректной последовательности фрагментов при сборке пакета. Для фрагментированного пакета все фрагменты имеют одинаковый идентификатор.

§  Флаги. 3 бита:

·      первый бит должен быть всегда равен нулю,

·      второй бит «Don’t fragment» определяет возможность фрагментации пакета,

·      третий бит «More fragments» показывает, не является ли этот пакет последним в цепочке пакетов.

§  Смещение фрагмента – значение, определяющее позицию фрагмента в потоке данных. Смещение задается количеством восьми байтовых блоков, поэтому это значение требует умножения на 8 для перевода в байты.

§  Время жизни (TTL) – число маршрутизаторов, которые должен пройти этот пакет. При прохождении маршрутизатора это число уменьшатся на единицу. Если значения этого поля равно нулю то, пакет должен быть отброшен и отправителю пакета может быть послано сообщение Time Exceeded (ICMP код 11 тип 0).

§  Протокол – идентификатор протокола следующего уровня указывает, данные какого протокола содержит пакет, например, TCP или ICMP.

§  Контрольная сумма заголовка – вычисляется в соответствии с RFC 1071.

§  Параметры

§  Данные, поступившие с верхнего уровня.

Принцип работы протокола IP

Алгоритм работы протокола IP на каком-либо узле сети принимающего дейтаграмму из сети показан на рисунке 4.2.

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

На пути пакета от отправителя к получателю могут встречаться локальные и глобальные сети разных типов с разными допустимыми размерами полей данных кадров канального уровня (MaximumTransfer Unit, MTU). Так, сети Ethernet могут передавать кадры, несущие до 1500 байт данных, для сетей X.25 характерен размер поля данных кадра в 128 байт, сети FDDI могут передавать кадры размером в 4500 байт, в других сетях действуют свои ограничения. Протокол IP умеет передавать дейтаграммы, длина которых больше MTU промежуточной сети, за счет фрагментирования – разбиения большого пакета на некоторое количество частей (фрагментов), размер каждой из которых удовлетворяет промежуточную сеть. После того, как все фрагменты будут переданы через промежуточную сеть, они будут собраны на узле-получателе модулем протокола IP обратно в большой пакет. Отметим, что сборку пакета из фрагментов осуществляет только получатель, а не какой-либо промежуточный маршрутизатор. Маршрутизаторы могут только фрагментировать пакеты, но не собирать их. Это связано с тем, что разные фрагменты одного пакета не обязательно будут проходить через одни и те же маршрутизаторы.

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

Если второй бит поля Флаги (More fragments) равен единице, значит данный фрагмент – не последний в пакете. Если пакет отправляется без фрагментации, флаг “More fragments” устанавливается в 0, а поле Смещение фрагмента – заполняется нулевыми битами.

Если первый бит поля Флаги (Don’t fragment) равен единице, то фрагментация пакета запрещена. Если этот пакет должен быть передан через сеть с недостаточным MTU, то маршрутизатор вынужден будет его отбросить. Этот флаг используется в случаях, когда отправителю известно, что у получателя недостаточно ресурсов по восстановлению пакетов из фрагментов.

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

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

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

Протокол ICMP

Протокол ICMP (Internet Control Message Protocol – протокол межсетевых управляющих сообщений) является вспомогательным сетевым протоколом, включенным в стек протоколов TCP/IP. Данный протокол используется для отправки сообщений об ошибках при передаче или ситуациях, когда маршрутизатор или узел не отвечает или требуемая услуга недоступна. По сути, протокол ICMP не может запросить послать потерянный пакет повторно, а просто оповещает о проблемах в работе сети. Также на ICMP возлагаются некоторые сервисные функции.

Когда протокол IP определяет, что дальнейшая передача пакета невозможна, перед тем как уничтожить пакет, он должен отослать узлу-источнику диагностическое ICMP-сообщение. Если при передаче самого ICMP-сообщения возникла ситуация препятствующая его передаче, то протокол ICMP не будет отправлять об этом диагностическое сообщения для избегания «штормов» в сетях.

При передаче по сети, сообщения ICMP инкапсулируются в поле данных IP-пакетов. Формат заголовка ICMP-пакета изображён на рисунке 4.3.

Заголовок ICMP-сообщения состоит из 8 байт:

• Тип (1 байт) – числовой идентификатор типа сообщения: 0 или 8, где 0 – ICMP-reply (ответ), 8 – ICMP-request (запрос);

• Код (1 байт) – числовой идентификатор, более точно определяющий тип ошибки;

• Контрольная сумма (2 байта) – вычисляется для всего ICMP-сообщения;

• Оставшиеся четыре байта и Поле данных зависят от значений полей типа и кода.

ICMP сообщения используются при отправке эхо-запроса (echo request) с помощью команды ping. Такой запрос обычно выполняется с целью проверки доступности узла в сети. На рисунке 4.4показаны отправленные и принятые пакеты при отправке эхо-запроса с узла 10.114.7.5 на узел 10.114.7.2.

Протокол ARP

В сетях Ethernet для идентификации узла используются IP и MAC адреса. Информация, передаваемая по сетям, содержит в себе оба этих адреса. Поскольку сами по себе эти адреса никак не связаны, такую связь обеспечивает протокол ARP (Address Resolution Protocol – Протокол определения адресов). Связь между IP адресом и MAC адресом осуществляется с помощью так называемых ARP-таблиц (рисунок 4.5), где в каждой строке указывается соответствие IP адреса MAC адресу. Просмотреть содержимое ARP-таблиц можно с помощью специальной команды arp.

Протокол RARP (Reverse Address Resolution Protocol – Обратный протокол определения адресов) выполняет обратное отображение адресов, то есть преобразует аппаратный адрес в IP-адрес.

Структура заголовка ARP изображена на рисунке 4.6:

• Hardware type (HTYPE) Каждый канальный протокол передачи данных имеет свой номер, который хранится в этом поле. Например, Ethernet имеет номер 0x0001

• Protocol type (PTYPE) Код сетевого протокола. Например, для IPv4 будет записано 0x0800

• Hardware length (HLEN) Длина физического адреса в байтах. Адреса Ethernet имеют длину 6 байт.

• Protocol length (PLEN) Длина логического адреса в байтах. IPv4 адреса имеют длину 4 байта.

• Operation Код операции отправителя: 1 в случае запроса и 2 в случае ответа.

• Sender hardware address (SHA) Физический адрес отправителя.

• Sender protocol address (SPA) Логический адрес отправителя.

• Target hardware address (THA) Физический адрес получателя. Поле пусто при запросе.

• Target protocol address (TPA) Логический адрес получателя.

На рисунках 4.7 и 4.8 показаны ARP-запрос и ARP-ответ. ARP-запрос является широковещательным (MAC-адрес назначения: ff:ff:ff:ff:ff:ff). При получении сообщения узлом 10.114.7.1, тот формирует ARP-ответ, отправляя его только отправителю ARP-запроса.

Способы назначения IP-адресов. DHCP

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

Протокол DHCP (Dynamic Host Configuration Protocol – протокол динамической настройки узла) предназначен для автоматической выдачи узлу таких параметров, как адрес сети, маска подсети, шлюз по умолчанию, адрес DNS-сервера и др. В ходе работы протокола между клиентом (узлом, желающим получить настройки) и сервером (узлом, выдающим эти настройки) происходит обмен сообщениями. Поля, присутствующие в этих сообщениях, описаны в таблице 4.2.

Процесс получения адреса состоит из следующих шагов:

1. Когда клиент (узел) подключается к сети, он отправляет сообщение             DHCPDISCOVER о поиске DHCP-сервера в сеть. При этом в качестве адреса отправителя указывается адрес 0.0.0.0 (т.к. у клиента пока нет своего адреса), а в качестве получателя  – 255.255.255.255 (т.к. адрес сервера также неизвестен).

2. При получении сообщения DHCPDISCOVER сервер формирует сообщение DHCPOFFER, в котором содержатся предлагаемый сервером адрес (yiaddr) и все остальные необходимые клиенту настройки. В качестве адреса-приёмника в сообщении указывается MAC-адрес клиента.

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

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

3. В ответ на DHCPOFFER клиент формирует широковещательное сообщение DHCPREQUEST, указав, что он принимает полученные параметры конфигурации. При наличии нескольких серверов DCHP клиент получит также несколько сообщений DHCPOFFER. Сообщение DHCPREQUEST является широковещательным, и клиент указывает идентификатор (xid) выбранного им сервера. Сообщение DHCPREQUEST по-прежнему будет содержать адрес источника 0.0.0.0, если клиенту все еще нельзя использовать IP-адрес, полученный в сообщении DHCPOFFER.

Не исключено, что клиента не устроит ни одно из серверных предложений. Тогда вместо DHCPREQUEST он снова выдаст в сеть запрос DHCPDISCOVER, а серверы так и не узнают, что их предложения отклонены. Именно по этой причине сервер не обязан резервировать помещенный в DHCPOFFER адрес.

4. Как только сервер получает DHCPREQUEST от клиента, он посылает DHCPACK сообщение о том, что теперь клиент может использовать IP-адрес, назначенный к нему. Клиент окончательно подключается к сети с настроенными параметрами.

Если к моменту поступления сообщения DHCPREQUEST предложенный адрес уже был присвоен другому клиенту (например, от первой станции слишком долго шёл ответ на поступившее предложение), сервер ответит сообщением DHCPNAK.

5. Получив сообщение DHCPACK, клиент обязан убедиться в уникальности IP-адреса (с помощью ARP) и зафиксировать суммарный срок его аренды. Последний рассчитывается как время, прошедшее между отправкой сообщения DHCPREQUEST и приемом ответного сообщения DHCPACK, плюс срок аренды, указанный в DHCPACK.

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

6. Для досрочного прекращения аренды адреса клиент отправляет серверу сообщение DHCPRELEASE.

Также необходимо знать, что IP-адрес сдаётся DHCP-сервером в аренду (lease). После истечения срока сервер может свободно присвоить этот адрес другому узлу. По истечении половины срока аренды клиент обычно пытается автоматически продлить её срок путем отправки DHCPREQUEST, указав в качестве адреса источника уже выданный адрес (а не 0.0.0.0, как это было при первичном получении). Получив DHCPACK, клиент будет знать, что срок аренды продлён.

Стоит отметить, что если клиент и сервер DHCP находятся в локальной подсети, сообщения в процессе работы протокола будут передаваться без посредников. Однако если сервер находится в другой подсети, то сообщения будут проходить через так называемый агент ретрансляции (DHCP Relay). При получении сообщения от клиента агент меняет адрес отправителя (0.0.0.0) на свой, адрес получателя (255.255.255.255) и пересылает пакет серверу.

Исчерпание адресного пространства

Стандарт IP-адреса версии 4 (IPv4) был принят в сентябре 1981 года. Адресное пространство его составляет 2³² = 4 294 967 296 различных адресов. Выдача адресов регулируется американской некоммерческой организацией IANA (Internet Assigned Numbers Authority). Она выдавала большие блоки адресов пяти региональным регистраторам (RIR), которые в свою очередь раздают более мелкие диапазоны между Интернет-провайдерами (ISP). Провайдеры раздают адреса штучно или небольшими блоками конечным пользователям и организациям.

Во время утверждения стандарта казалось, что адресное пространство достаточно велико, чтобы удовлетворить потребности растущего Интернета на десятилетия вперёд. Однако в период бурного роста и популяризации сети Интернет, а также развития вычислительной техники в целом, уже в 90-х стало ясно, что такого количества адресов хватит ненадолго, что адресное пространство рано или поздно (а по темпу роста – скорее рано) исчерпается. Выделяют следующие факторы исчерпания адресов IPv4:

Неэффективное использование адресов. В 80-х годах, когда ещё не предвиделось такого бурного развития сети Интернет, адреса раздавались более «щедро» целыми блоками класса. Некоторые крупные компании или университеты могли получить в то время блок адресов класса A (16 миллионов адресов), если количество узлов их сети превышало 65 тысяч, и блока адресов класса B было недостаточно.

Теоретически IANA может получить обратно эти блоки адресов, после чего распределить их более рационально. Некоторые организации, среди которых Стэнфордский университет и Министерство обороны США, уже вернули блоки адресов. Однако смена адресов в большой сети может оказаться дорогой по стоимости и времени, и организации, обладающие «лишними» адресами, просто откажутся их возвращать (у Стэнфордского университета ушло два года на перенастройку 56 тысяч единиц оборудования).

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

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

Очевидно, что с расширением самой сети Интернет росло и количество пользователей, а с ними и увеличение используемых адресов. С данным фактором можно было бороться путем перераспределения свободных публичных адресов между абонентами. Но если при использовании коммутируемого доступа такой способ работал, то следующий фактор лишил и этой возможности.

Постоянное соединение с сетью Интернет. В 90-х – начале 2000-х основным способом подключения к сети Интернет был коммутируемый удалённый доступ при помощи телефонного модема. Применялась почасовая оплата за пользование доступом, поэтому подключение устанавливалось, как правило, на некоторый короткий промежуток времени. С середины 2000-х начал преобладать широкополосный доступ. Оплата за интернет сначала стала исчисляться по объёму трафика, а затем многие провайдеры перешли на безлимитный (по времени и трафику) способ за абонентскую плату. Поскольку для рядового пользователя отпала необходимость экономить на проведенном в Интернете времени и полученном трафике, отпала и необходимость в постоянном подключении/отключении к Интернету. Т.е. подключение к Интернету осуществлено всегда, когда включен компьютер.

Ситуация усугубилась, когда начали появляться в продаже недорогие домашние маршрутизаторы, «раздающие» Интернет между несколькими устройствами фактически одного абонента. Поскольку эти маршрутизаторы потребляют небольшое количество энергии и работают достаточно тихо, никто не отключает их, например, на ночь, или в когда никого нет дома. Следовательно, абонент подключен к сети Интернет 24/7, что практически полностью исключает возможность перераспределения освободившихся публичных адресов между абонентами.

К решению проблемы подошли с другой стороны. Поскольку подавляющему большинству домашних Интернет-пользователей вовсе не обязательно наличие «белого» адреса в собственном распоряжении, провайдеры выдают абонентом не публичные, а частные адреса. Таким образом, у провайдера формируется небольшая локальная сеть (в пределах одного дома, или района), которая использует для выхода в Интернет один публичный адрес. Это реализуется с помощью технологииNAT (Network Address Translation), а точнее её разновидности – PAT (Port Address Translation).

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

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

В приведенных факторах все решения по более эффективному использованию адресного пространства позволяют лишь несколько отсрочить дату исчерпания адресов, но не решат проблему. Для полноценного решения требуется переход на новый формат адресов. Следующий стандарт IPv6был разработан ещё в 1996 году, однако по ряду причин переход на новый стандарт адресов затянулся.

TCP и UDP

Пакеты, приходящие на транспортный уровень операционной системы организованы во множества очередей к точкам входа различных приложений. В терминологии TCP/IP такие точки входа называются портами. Для идентификации портов им присваиваются номера от 0 до 65 535. Для популярных процессов зарезервированы стандартные значения портов: для HTTP – 80, FTP – 21, TELNET – 23 и т.д. Назначенные номера от 0 до 1023 являются уникальными в пределах сети Интернет и закреплены за приложениями централизованно.

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

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

Прикладной процесс однозначно определяется в пределах сети и в пределах отдельного компьютера парой {IP-адрес; номер порта}, называемой сокетом (socket).

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

На транспортном уровне работают два протокола: UDP и TCP.

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

UDP создаёт свои дейтаграммы на основе логически обособленных единиц данных. Эти данные поступают  от приложений протоколу UDP через порт в виде сообщений. Каждое из таких сообщений является в некоторой степени самостоятельной частью данных, это даёт возможность «потерять» часть сообщений при передаче без нанесения большого вреда.

Заголовок UDP (рис. 5.1) состоит из восьми байт и содержит четыре поля:

• Порт отправителя – в этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из "хорошо известных".

• Порт получателя – это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент - хост-получатель, то номер порта эфемерный, иначе (сервер - получатель) это "хорошо известный порт".

• Длина дейтаграммы – поле, задающее длину всей дейтаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка – 8 байт. Теоретически, максимальный размер поля – 65535 байт для UDP-дейтаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 – 65507 (помимо 8 байт на UDP-заголовок требуется еще 20 на IP-заголовок).

• Контрольная сумма – используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями.

Рисунок 5.1. Формат дейтаграммы UDP

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

Протокол контроля передачи или TCP (Transmission Control Protocol) основан на установлении логического соединения, что позволяет ему обеспечивать гарантированную доставку данных.

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

Заголовок TCP-сегмента (рис. 5.2) состоит из 20 байт и содержит следующие поля:

• Порядковый номер выполняет две задачи:Номер подтверждения – если установлен флаг ACK, то это поле содержит номер последовательности, ожидаемый получателем в следующий раз. Помечает этот сегмент как подтверждение получения;

• Если установлен флаг SYN, то это начальное значение номера последовательности – ISN (Initial SequenceNumber), и первый байт данных, которые будут переданы в следующем пакете, будет иметь номер последовательности, равный ISN+1

• Если SYN не установлен, номер первого байта данных в сегменте;

• Длина заголовка – задается словами по 32 бита;

• URG – флаг срочности, если 0, то поле игнорируется;

• ACK – флаг подтверждения, если 0, то поле игнорируется;

• PSH – флаг требует выполнения операции push, модуль TCP должен срочно передать пакет программе (отправка сообщения без ожидания заполнения буфера);

• RST – флаг прерывания соединения, используется для отказа в соединении;

• SYN – флаг синхронизации, используется для синхронизации счётчиков переданных данных при установлении соединения;

• FIN – флаг окончания передачи со стороны отправителя;

• Размер окна – количество байт, которые готов принять получатель без подтверждения;

• Контрольная сумма – включает псевдо заголовок, заголовок и данные;

• Указатель срочности – указывает последний байт срочных данных, на которые надо немедленно реагировать;

• Дополнительные параметры (необязательное поле) – используется для решения вспомогательных задач, например, для согласования максимального размера сегмента;

• Заполнение (нули) – фиктивное поле, используется для доведения размера заголовка до целого числа 32-битовых слов.

Рисунок 5.2. Формат сегмента TCP

 Установка логического соединения

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

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

• Максимальный размер сегмента, который сторона готова принять;

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

• Начальный порядковый номер байта, с которого она начинает отсчёт потока данных в рамках соединения.

Некоторые параметры являются постоянными в течение всего соединения, другие адаптивно изменяются, например, в зависимости от загруженности буфера принимающей стороны и надёжности работы сети динамически изменяется размер окна.

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

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

Рисунок 5.3. Установка логического соединения (а) и завершение соединения (б)

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

Соединение может быть разорвано в любой момент по инициативе любой стороны. Для этого клиент и сервер должны обменяться сегментами FIN и ACK(рис. 5.3 б). Соединение считается закрытым по прошествии некоторого времени, в течение которого сторона-инициатор убеждается, что её завершающий сигнал ACK дошёл нормально и не вызвал никаких «аварийных» сообщений с противоположной стороны.

Методы квитирования

Один из приёмов, используемых для организации надёжной передачи – это квитирование. Отправитель отсылает данные и ждёт, пока к нему не придёт квитанция, подтверждающая, что его данные благополучно дошли до адресата. Существует два метода организации процесса обмена квитанциями: метод простоя источника и метод скользящего окна.

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

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

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

При установке соединения источник и получатель договариваются о начальном размере окна. Пусть в данном соединении установлено окно в размере пяти сегментов. Источник начинает передавать сегменты и через какое-то время получать в ответ квитанции. Предположим, что квитанции поступают в той же последовательности, что и отправленные кадры. В момент получения отправителем квитанции 1 окно сдвигается на одну позицию вверх, определяя новый диапазон разрешенных к отправке сегментов: от 2 до 6. Процессы отправки сегментов и получения квитанции идут независимо друг от друга. В нашем примере отправитель продолжает передавать сегменты, но некоторое время не получает квитанции. Допустим, после передачи кадра 6 не было получено квитанций по сегментам 2-6, т.о. окно исчерпалось, и источник приостанавливает передачу.

При отправке сегмента в источнике устанавливается тайм-аут. Если за установленное время квитанция на отправленный сегмент не придёт, то сегмент (или его квитанция) считается утерянным, и сегмент передаётся снова.

После получения квитанции 2 окно сдвигается, и источник может передать еще один сегмент. «Скольжение» окна происходит после получения каждой квитанции: окно сдвигается на один сегмент, но его размер при этом не меняется и остаётся равным пяти. Если поток квитанций поступает регулярно, то скорость обмена достигает максимально возможной величины для данного канала и принятого протокола.

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

Метод скользящего окна является более сложным в реализации, чем метод простоя источника, т.к. источник должен хранить в буфере копии всех кадров, на которые пока не получены квитанции. Кроме того, здесь требуется отслеживать несколько параметров алгоритма: размер окна, номер кадра, на который получена квитанция, номер кадра, который ещё можно передать до получения новой квитанции, счётчики тайм-аутов и пр.