Продолжение. Часть 5 здесь.

Система доменных имен DNS (Domain Name System)

Система преобразует иерархические текстовые имена (например, https://shalaginov.com/ ) в IP-адреса, которые понимает компьютер.  Практически все программное обеспечение Интернета использует одну и ту же библиотеку для преобразования имен DNS в актуальные адреса.

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

База данных DNS – иерархическая и распределённая. Если ввести в браузере адрес https://shalaginov.com/, могут быть запрошены три разных DNS-сервера: “DNS root zone” для .com, и затем shalaginov.com, а также https://wordpress.com/shalaginov.com/ , поскольку хостинг для этого адреса предоставляется порталом wordpress.com. Иногда может запрашиваться и больше серверов, в зависимости от иерархии текстового адреса. Процедура поиска может быть довольно сложной, поэтому часто используемые запросы хранятся в кэше ближайшего распределённого DNS-сервера. Если в его базе данных искомого адреса не оказывается, то запрашиваются другие сервера, либо выполняется расширенный поиск, вплоть до корневого сервера.

Уровень транспорта

Уровень IP получает пакеты, направляющиеся от одного узла сети к другому, но для удалённой транспортировки большого сборища пакетов такой метод не очень хорошо подходит. Во-первых, IP-маршрутизация построена на принципе “best-effort”, который означает, что пакеты могут теряться, и они действительно иногда теряются при передаче по IP-сети. Во-вторых, поскольку пакеты могут идти по сети разными маршрутами, то и прибывать в место назначения они могут не в том порядке, в котором передавались. Наконец, протокол IP поддерживает только посылку пакетов только на какой-то один хост, причём, чаще всего пакеты посылаются не просто на хост, а в приложение, которое на нём работает. Однако, чаще всего, на компьютере, подключенном к Интернет, одновременно работают много процессов, которые взаимодействуют с различными сервисами в Интернете, и потоки пакетов от этих процессов не должны смешиваться между собой.

Уровень транспорта находится в иерархии OSI выше уровня IP, и может решать такие проблемы путем создания некой абстракции соединения. И раньше, и сейчас наиболее популярным механизмом на уровне транспорта является протокол управления передачей TCP (Transmission Control Protocol). Этот протокол дополняет IP следующими функциями:

• Надёжность. TCP нумерует каждый пакет, и ведёт учет пакетов, которые были потеряны или требуют повторной передачи после истечения определённого времени. Он придерживает пакеты, прибывшие ранее последовательности, в которой они передавались, чтобы доставлять их в правильном порядке. Прибытие каждого пакета данных подтверждается приёмной стороной, и повторная передача происходит в том случае, если подтверждающий пакет не получен передающей стороной в течение установленного времени.
• Ориентация на соединение. После установления соединения ТСР, приложение начинает передавать данные просто «записывая» пакеты в это соединение. Никакой адресации на уровне приложения более не требуется. Соединения управляются протоколом ТСР, а не приложением.
• Потоковая передача. Приложение, использующее ТСР-соединение, может писать в него по 1 байту, по 100 кбайт, либо с другой скоростью, а ТСР будет буферизовать этот поток и разделять его на пакеты с размером, подходящим для работы приложения.
• Номера портов. Они определяют приложение, для которого предназначены данные, а также идентифицируют приложение, посылающее пакеты.
• Управление пропускной способностью (throughput). ТСР старается транспортировать пакеты с максимально возможной скоростью, однако при этом и контролирует, не возникает ли в сети перегрузок.

Конечная точка передачи пакетов в TCP задаётся виде <host,port>. Эта пара также называется «адрес сокета», или просто «сокет» (socket). Приложения, работающие на хосте (сервере) «слушают» соединения с сокетами, которые они открыли. Когда в адресной строке браузера вводится имя хоста, от открывает ТСР-соединение к порту 80 сервера (стандартный порт для трафика Интернет). То есть будет использоваться адрес сокета <server,80>. Если в браузере открыто несколько закладок, то каждая может устанавливать соединение с одним и тем же сокетом сервера, но соединения могут различаться при использовании разных портов (и таким образом, будут иметь разные адреса сокетов) на клиентском конце, то есть, на компьютере, где открыта вкладка в браузере. 

На сервере могут быть открыты тысячи соединений к порту 80 (веб-порт) и сотни соединений к порту 25 (порт для электронной почты). Потоки пакетов веб-браузера и электронной почты разделены при помощи использования разных портов <host,port>.

Соединения ТСР разделяются при помощи пары <host,port> адреса сокета на каждом конце соединения, поэтому потоки трафика разных соединений не смешиваются. То есть, может существовать множество соединений к адресу <shalaginov.com,80>. Это немного напоминает внутренние номера телефонов в организации, когда при вызове на «общий номер рецепшена», автоответчик просит набрать внутренний номер сотрудника. При этом на общий номер могут позвонить сразу несколько человек и их вызовы будут обработаны несколькими операторами колл-центра и распределены по разным внутренним линиям. При этом разговоры по разным внутренним линиям друг другу не будет слышны, хотя все позвонили на общий номер.

Для поддержания правильной передачи пакетов в реальном времени, ТСР использует алгоритм «скользящих окон» (sliding-windows). Размер «окна» определяет число пакетов, передающихся в потоке одновременно. В ТСР размер окна обозначается в байтах, но в пакетах измерять нагляднее. Если размер окна, например, 10 пакетов, это означает, что в любой момент времени в процессе транзита находятся 10 пакетов. Причём, это могут быть 5 пакетов, передаваемых данных получателю, и 5 пакетов подтверждения от протокола ТСР.

Если считать, что потерь пакетов нет, то каждый принятый на посылающей стороне подтверждающий пакет «продвигает» скользящее окно «вперед» на один пакет.

Алгоритм «скользящего окна» минимизирует эффект задержки при продвижении пакетов через узлы сети (store-and-forward). Также этот алгоритм автоматически решает проблему переполнения очереди в маршрутизаторе, поскольку размер этой очереди не может превысить размер «скользящего окна». Это выгодно отличает метод «скользящего окна» от метода поддержания постоянной скорости передачи, когда доступная пропускная способность оказывается меньше жестко установленной скорости передачи. Это неизбежно приведёт к переполнению очередей в узлах сети, и резкому росту числа потерянных пакетов. Если же размер окна будет слишком большим, то источник пакетов может также страдать от потери пакетов, но по другой причине – от превышения допустимого времени жизни пакета.

Определить идеальный размер скользящего окна – довольно трудная задача, в частности, потому, что он будет зависеть от загрузки сети. В результате, ТСР постоянно аппроксимирует идеальный размер окна. ТСР постепенно увеличивает размер окна до появления потерь пакетов и после этого немного снижает размер окна. Затем снова увеличивает, и когда появляются потери пакетов, снова снижает до исчезновения этого нежелательного явления. Таким образом, размер окна постоянно колеблется вокруг оптимальной величины.  

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

Работа ТСР не всегда бывает удовлетворительной. В механизме ТСР заложен принцип, что если потерян пакет из медиапотока (голоса или видео), то приёмная стороны прекращает приём пакетов, до повторной передачи и приёма потерянного пакета.  Для пользователя, принимающего звонок IP-телефонии, например, такая ситуация будет выглядеть как кратковременное пропадание связи, либо «кваканье» в речи собеседника. Эта ситуация называется «head-of-line blocking» (блокировка начала очереди) и это представляет собой серьёзную проблему для голосовых и видео-коммуникаций.

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

Анимация, иллюстрирующая работу «скользящего окна».

Продолжение следует