Компьютерная сеть: основные понятия и метрики

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

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

Далее рассматривается устройство Интернета как «сети сетей», классификация сетей по масштабу и топологии, а затем — метрики качества: пропускная способность, задержка и её четыре составляющие, время кругового обхода, джиттер, потери и произведение пропускной способности на задержку. Отдельный раздел посвящён очередям: без понимания того, как задержка зависит от загрузки канала, невозможно объяснить ни одно наблюдение в последующих лабораторных работах. Тема завершается обзором организаций, которые создают стандарты и распределяют адреса. Устройство уровней сетевой архитектуры здесь намеренно не затрагивается — оно составляет предмет темы 2.

Из чего состоит компьютерная сеть

Узлы, каналы и протоколы

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

Узел (англ. node) — любое устройство, подключённое к сети. Узлы делятся на две группы. Конечные узлы, или хосты (англ. host, end system), — это устройства, на которых работают прикладные программы и которые являются источниками и получателями данных: персональные компьютеры, смартфоны, серверы, камеры наблюдения, датчики. Промежуточные узлы (англ. intermediate system) данные не создают и не потребляют, а пересылают: коммутаторы (англ. switch) соединяют устройства в пределах одной локальной сети, маршрутизаторы (англ. router) — разные сети между собой. Граница между группами не абсолютна: домашний маршрутизатор пересылает пакеты, но одновременно является хостом для собственного веб-интерфейса настройки.

Канал связи (англ. communication link, или просто link) — среда и аппаратура, через которые биты передаются от одного узла к соседнему: медная витая пара, оптическое волокно, радиоэфир. Важнейшая характеристика канала — скорость передачи (англ. transmission rate), то есть число бит, которое передатчик способен выдать в среду за секунду; она измеряется в битах в секунду. В сетевой технике приставки десятичные: 1 Мбит/с — это ровно 1 000 000 бит/с, 1 Гбит/с — 10⁹ бит/с. Объём памяти и размеры файлов, напротив, часто выражают в двоичных единицах (1 КиБ = 1024 байта); путаница между битами и байтами, а также между десятичными и двоичными приставками — частый источник ошибок в расчётах, и в курсе эти единицы строго различаются.

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

Сеть существует ради сервисов (англ. service) — услуг, которые она предоставляет прикладным программам: доставить сообщение адресату, установить надёжный поток байтов, найти адрес по имени. Программа обращается к сервису через программный интерфейс (англ. application programming interface, API) операционной системы, не вникая в то, как именно данные пересекают сеть. Различие между сервисом (что делается) и протоколом (как это делается) станет одним из главных понятий темы 2.

Хост в цифрах: первый взгляд инструментами

Перечисленные понятия удобно сразу связать с тем, что можно увидеть на собственном компьютере. В Linux состояние сетевой подсистемы показывает набор утилит iproute2. Команда ip addr перечисляет сетевые интерфейсы (англ. network interface) — точки подключения хоста к каналам — и назначенные им адреса:

ip -br addr
ip route

lo               UNKNOWN        127.0.0.1/8 10.255.255.254/32 ::1/128
eth0             UP             172.27.60.185/20 fe80::215:5dff:fe5b:8b43/64
gre0@NONE        DOWN
...
default via 172.27.48.1 dev eth0 proto kernel
172.27.48.0/20 dev eth0 proto kernel scope link src 172.27.60.185

Ключ -br (англ. brief) делает вывод кратким: имя интерфейса, состояние, адреса. Вывод получен на виртуальной машине WSL2. Главных интерфейсов два: петлевой lo (англ. loopback), через который программы обращаются к самому хосту, и eth0, связанный с внешним миром; служебные туннельные интерфейсы вида gre0 создаются ядром автоматически и не используются. Вторая команда показывает таблицу маршрутизации: адреса из диапазона 172.27.48.0/20 достижимы непосредственно через eth0, а всё остальное отправляется промежуточному узлу — шлюзу по умолчанию 172.27.48.1. Что означают эти записи, подробно разбирается в темах 6 и 8; пока достаточно заметить, что даже простейший хост «знает» о сети лишь две вещи: кто его непосредственные соседи и кому отдать всё остальное.

Протоколы и сервисы видны в выводе команды ss, перечисляющей сокеты (англ. socket) — программные конечные точки обмена данными:

ss -tn state established

Recv-Q Send-Q Local Address:Port    Peer Address:Port
0      0      172.27.60.185:39178 176.114.77.211:443
0      0      172.27.60.185:43112  34.149.66.165:443

Каждая строка — установленное соединение по протоколу TCP (тема 12) с удалённым сервером на порту 443, который используется защищённым протоколом HTTPS (темы 16 и 17). Подобные наблюдения выполняются в первой лабораторной работе.

Почему сеть — это прежде всего соглашение

Из определения протокола следует важное обстоятельство: сеть работает не потому, что узлы соединены проводами, а потому, что их программное обеспечение следует одним и тем же правилам. Устройства разных производителей, с разными операционными системами и на разных континентах взаимодействуют лишь благодаря тому, что правила записаны в открытых стандартах и реализованы независимо. Поэтому в сетевой инженерии первоисточник — не учебник и не документация конкретного продукта, а текст стандарта: RFC, стандарт IEEE или рекомендация ITU. О том, кто и как создаёт эти документы, говорится в последнем разделе темы.

От телефонной сети к Интернету

Телефонная сеть и коммутация каналов

Первой глобальной сетью связи была телефонная. Её устройство определялось задачей — передачей голоса в реальном времени. Разговор длится минуты, в течение которых звук должен поступать к собеседнику непрерывно и с постоянной небольшой задержкой. Решение состояло в том, чтобы на время разговора выделить абонентам непрерывный путь через телефонные станции — канал. Сначала соединения выполняли телефонистки на коммутаторах, позднее — электромеханические, затем электронные автоматические станции; само слово «коммутация» (англ. switching, буквально «переключение») пришло в сетевую терминологию именно отсюда.

При переходе на цифровую передачу голос стали оцифровывать: 8000 отсчётов в секунду по 8 бит дают 64 000 бит/с — так называемый основной цифровой канал (англ. DS0). Несколько таких каналов передаются по одной линии с временным разделением (англ. time-division multiplexing, TDM): время делится на циклы (кадры) длительностью 125 мкс, а каждый цикл — на слоты, и каждый разговор получает в каждом цикле свой слот. Европейская система E1 объединяет 32 слота и имеет скорость 32 × 64 000 = 2 048 000 бит/с, американская T1 — 24 слота и скорость 1,544 Мбит/с с учётом служебных бит ³. Другой способ — частотное разделение (англ. frequency-division multiplexing, FDM), при котором каждому соединению отводится своя полоса частот, как радиостанциям в эфире.

Такой способ организации называется коммутацией каналов (англ. circuit switching): перед началом обмена устанавливается соединение, на всём пути резервируются ресурсы (слоты или полосы частот), и до разрыва соединения они принадлежат только ему. Достоинство очевидно — гарантированная скорость и постоянная, предсказуемая задержка. Недостаток проявляется, когда трафик неравномерен. Голос в разговоре занимает канал примерно половину времени (собеседники говорят по очереди), а компьютерные данные поступают пачками (англ. burst): пользователь открывает страницу — и несколько секунд канал загружен полностью, затем читает её минуту — и канал простаивает. Зарезервированный слот в это время пустует, и использовать его никто другой не может.

Пакетная коммутация: Баран, Дэвис, Клейнрок

В начале 1960-х годов независимо в нескольких местах возникла альтернативная идея. Пол Баран (корпорация RAND) искал способ построить сеть связи, способную сохранить работоспособность при выходе из строя значительной части узлов. Он предложил распределённую сеть с избыточными связями, в которой сообщения разбиваются на небольшие блоки, и каждый блок пересылается от узла к узлу независимо, по любому доступному пути ⁶. В Великобритании Дональд Дэвис из Национальной физической лаборатории пришёл к сходной схеме из соображений эффективности использования линий и ввёл для блоков слово «пакет» (англ. packet). Теоретическую основу для анализа сетей с очередями заложил Леонард Клейнрок ⁹.

Коммутация пакетов (англ. packet switching) устроена так. Сообщение делится на пакеты, каждый из которых снабжается заголовком (англ. header) с адресом получателя. Ресурсы заранее не резервируются. Узел, получивший пакет, определяет по адресу, в какой исходящий канал его отправить, и ставит пакет в очередь этого канала. Если канал свободен, пакет передаётся сразу; если занят — ждёт. Таким образом, канал в каждый момент занят тем, у кого действительно есть данные.

Сравнение двух способов разделения канала показано на рисунке ниже. При временном разделении слот, владельцу которого нечего передавать, простаивает. При статистическом мультиплексировании (англ. statistical multiplexing) канал загружается пакетами в порядке их поступления, и общий объём переданных данных больше, но время ожидания каждого пакета зависит от того, сколько пакетов пришло раньше него.

ARPANET, TCP/IP и рождение Интернета

Идеи пакетной коммутации впервые были реализованы в сети ARPANET, создававшейся по заказу Агентства перспективных исследовательских проектов Министерства обороны США (англ. Advanced Research Projects Agency, ARPA). Первый узел — специализированный компьютер-коммутатор IMP (англ. Interface Message Processor) — был установлен в Калифорнийском университете в Лос-Анджелесе в сентябре 1969 года, к концу года сеть объединяла четыре узла ⁵. В том же 1969 году появился первый документ серии RFC (англ. Request for Comments, «запрос комментариев») — серии, в которой и сегодня публикуются стандарты Интернета.

К началу 1970-х годов, помимо ARPANET, существовали пакетные радиосети и спутниковые сети, устроенные по-разному. Возникла задача соединения сетей между собой — межсетевого взаимодействия (англ. internetworking). В 1974 году Винтон Серф и Роберт Кан опубликовали статью «Протокол для межсетевого взаимодействия пакетных сетей», в которой предложили архитектуру, сохранившуюся до сих пор ⁴. Её основные положения: сети остаются разными и не меняются; их соединяют шлюзы (позднее названные маршрутизаторами), которые пересылают пакеты, не вникая в их содержимое; надёжность доставки обеспечивается не сетью, а программами на конечных хостах. Первоначально единый протокол TCP впоследствии был разделён на два: межсетевой протокол IP (англ. Internet Protocol), отвечающий за доставку отдельных пакетов, и протокол управления передачей TCP (англ. Transmission Control Protocol), обеспечивающий надёжный поток данных. Их спецификации — RFC 791 и RFC 793 — вышли в 1981 году, а 1 января 1983 года ARPANET полностью перешла на TCP/IP ⁵. Эту дату часто считают днём рождения Интернета.

Во второй половине 1980-х годов Национальный научный фонд США создал магистральную сеть NSFNET для соединения университетов. Её магистраль работала сначала на скорости 56 Кбит/с, в 1988 году была переведена на линии T1 (1,544 Мбит/с), а в начале 1990-х — на линии T3 (около 45 Мбит/с) ⁵. В 1995 году магистраль NSFNET была выведена из эксплуатации, и её функции перешли к коммерческим провайдерам. Примерно в то же время Интернет получил «приложение-катализатор»: Тим Бернерс-Ли в Европейской организации по ядерным исследованиям (ЦЕРН) в 1989–1991 годах разработал Всемирную паутину (англ. World Wide Web) — язык разметки HTML, протокол HTTP и первый браузер. Веб превратил Интернет из инструмента учёных в массовую среду.

История показывает характерную закономерность: Интернет никогда не проектировался как единая сеть с единым владельцем. Он вырос как объединение независимых сетей по общим протоколам — и эта особенность определяет его структуру сегодня.

Коммутация каналов и коммутация пакетов

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

Выигрыш от коммутации пакетов удобно показать на классическом примере ¹. Пусть пользователи разделяют канал со скоростью 1 Мбит/с. Каждый пользователь в активном состоянии передаёт данные со скоростью 100 Кбит/с, но активен лишь 10 % времени, а остальное время читает полученное и ничего не передаёт.

При коммутации каналов каждому пользователю нужно зарезервировать 100 Кбит/с, и канал выдержит ровно 1 000 000 / 100 000 = 10 пользователей, независимо от того, насколько они активны.

При коммутации пакетов резервирования нет. Пусть канал разделяют 35 пользователей. Перегрузка возникает, только если одновременно активны больше десяти из них. Если пользователи действуют независимо, число активных подчиняется биномиальному распределению с параметрами n = 35 и p = 0,1, и вероятность перегрузки равна

P(\text{активных} > 10) = \sum_{k=11}^{35} C_{35}^k \cdot 0{,}1^k \cdot 0{,}9^{35-k} \approx 0{,}0004

Расчёт легко проверить несколькими строками на Python:

from math import comb
n, p = 35, 0.1
print(sum(comb(n, k) * p**k * (1 - p)**(n - k) for k in range(11, n + 1)))
# 0.0004242975954508263

Таким образом, при той же скорости канала коммутация пакетов обслуживает в 3,5 раза больше пользователей, а перегрузка случается в среднем 4 раза на 10 000 моментов наблюдения. При 50 пользователях вероятность перегрузки уже около 0,0094, то есть почти 1 %: выигрыш не бесконечен, и чем ближе средняя суммарная нагрузка к ёмкости канала, тем чаще возникают перегрузки. Средняя нагрузка 35 пользователей — 35 × 0,1 × 100 Кбит/с = 350 Кбит/с, то есть 35 % ёмкости канала; при 50 пользователях — 50 %.

Существенна и вторая сторона примера. Если единственный пользователь внезапно должен передать файл, при коммутации каналов он ограничен своими 100 Кбит/с, а при коммутации пакетов в отсутствие других активных пользователей получает весь канал — 1 Мбит/с.

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

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

Временная диаграмма на рисунке ниже показывает, как пакет длиной L бит проходит через один промежуточный узел. Время по вертикали растёт вниз; наклон полосы отражает то, что первый бит пакета достигает следующего узла раньше последнего. Передатчик узла A выдаёт биты в канал за время L/R₁, каждый бит распространяется по каналу за время d₁/s, и лишь когда последний бит принят, маршрутизатор может начать передачу во второй канал.

Если пренебречь распространением, обработкой и очередями, то пакет длиной L, проходящий через N одинаковых каналов со скоростью R, достигает получателя за время N · L / R: на каждом звене он заново передаётся целиком. Если же отправляется P пакетов подряд, то конвейер работает параллельно: пока второй пакет передаётся по первому звену, первый уже идёт по второму, и общее время составляет (N + P − 1) · L / R. Например, при L = 1500 байт = 12 000 бит, R = 10 Мбит/с, N = 3 звена время передачи одного пакета по одному звену равно 12 000 / 10⁷ = 1,2 мс, один пакет дойдёт за 3,6 мс, а 100 пакетов — за (3 + 100 − 1) × 1,2 = 122,4 мс, а не за 3 × 120 = 360 мс. Отсюда понятно, зачем сообщение делится на пакеты: разбиение позволяет звеньям пути работать одновременно.

Существуют коммутаторы, начинающие передачу до окончания приёма, — режим сквозной коммутации (англ. cut-through); он применяется в некоторых коммутаторах Ethernet и рассматривается в теме 4.

Коммутация пакетов: цена гибкости

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

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

Устройство Интернета и классификация сетей

Интернет как сеть сетей

С точки зрения пользователя Интернет — единая сеть, но технически он представляет собой объединение десятков тысяч независимых сетей, каждая из которых управляется своей организацией. Такая сеть с единой политикой маршрутизации называется автономной системой (англ. autonomous system, AS) и имеет свой номер; как автономные системы обмениваются сведениями о маршрутах, рассматривается в теме 10.

Хост подключается к Интернету через сеть доступа (англ. access network) — участок от абонента до первого маршрутизатора провайдера, который часто называют «последней милей» (англ. last mile). Технологии доступа разнообразны: цифровая абонентская линия DSL по телефонной паре, кабельные модемы DOCSIS по сети кабельного телевидения, пассивные оптические сети PON, подводящие волокно в дом (англ. fiber to the home, FTTH), сотовый радиодоступ 4G/5G, Wi-Fi в публичных местах. Сеть доступа обычно оказывается самым «узким» участком пути, и именно её скорость указывается в тарифе.

Провайдер доступа сам должен быть связан с остальным Интернетом. Исторически сложилась иерархия: небольшие провайдеры покупают доступ у региональных, те — у крупных магистральных провайдеров. На вершине находятся провайдеры уровня 1 (англ. tier-1) — сети глобального масштаба, которые не покупают транзит ни у кого, а обмениваются трафиком друг с другом. Отношения между сетями бывают двух видов, как показано на рисунке ниже. Транзит (англ. transit) — коммерческая услуга: клиент платит провайдеру за доставку трафика во весь Интернет. Пиринг (англ. peering) — взаимный обмен трафиком между собственными клиентами двух сетей, часто без взаимных расчётов.

Пиринговое соединение удобно устанавливать в точках обмена трафиком (англ. Internet exchange point, IXP) — площадках, где десятки и сотни сетей подключаются к общему коммутатору и договариваются об обмене попарно. Крупнейшие точки обмена работают во Франкфурте (DE-CIX), Амстердаме (AMS-IX), Лондоне (LINX), в России — MSK-IX и другие. Их значение видно даже в простой трассировке. Ниже приведён фрагмент вывода tracepath с учебной машины к серверу example.com; каждая строка — очередной маршрутизатор на пути (как работает трассировка, объясняется в теме 7):

tracepath -n -m 12 example.com

 1:  172.27.48.1                                           0.415ms
 2:  192.168.1.1                                           0.953ms
 3:  10.0.128.65                                           4.663ms
 ...
 9:  195.98.94.206                                         3.017ms asymm  8
10:  217.150.37.50                                         3.240ms asymm  9
11:  80.81.194.117                                        48.299ms asymm 12
12:  80.81.194.180                                        43.090ms asymm 11

Первые узлы — виртуальный коммутатор WSL2, домашний маршрутизатор и сеть провайдера с частными адресами; задержка до них — единицы миллисекунд. Узлы 11 и 12 имеют адреса из блока 80.81.192.0/21 — по данным базы RIPE NCC, это пиринговая сеть точки обмена DE-CIX во Франкфурте, — и задержка скачком возрастает на 40 мс. При 5 мкс на километр 40 мс времени кругового обхода соответствуют не менее чем 8000 км пути туда и обратно, то есть около 4000 км в одну сторону: пакет покинул сеть своего провайдера и пересёк значительное расстояние, прежде чем быть переданным в сеть получателя через точку обмена.

Выравнивание иерархии: контент-провайдеры и ЦОД

Строгая иерархия провайдеров за последние двадцать лет заметно «сплющилась». Крупные поставщики содержания (поисковые системы, видеосервисы, облачные платформы) построили собственные глобальные сети, связали свои центры обработки данных (ЦОД, англ. data center) и подключились напрямую к провайдерам доступа и точкам обмена, минуя магистральных провайдеров ¹¹. Сети доставки содержимого (англ. content delivery network, CDN) размещают копии популярных данных в серверах, установленных у провайдеров доступа или рядом с ними. В результате значительная доля трафика пользователя проходит лишь две-три автономные системы. Устройство сетей внутри ЦОД рассматривается в теме 21.

Классификация сетей по масштабу

Традиционно сети классифицируют по территориальному охвату. Классификация условна, но её термины широко используются.

Локальная сеть обычно принадлежит одной организации, высокоскоростна и дешева в расчёте на бит; глобальная строится из каналов, арендуемых у операторов связи, и стоимость передачи в ней значительно выше. Именно из этого различия выросли разные семейства стандартов: локальные технологии стандартизирует комитет IEEE 802, глобальные исторически — ITU ².

Топологии

Топология (англ. topology) — конфигурация связей между узлами. Различают физическую топологию (как проложены кабели) и логическую (как распространяются сигналы или кадры); они не обязательно совпадают. Основные топологии:

• шина (англ. bus) — все узлы подключены к общей среде, и передачу одного слышат все; ранние сети Ethernet на коаксиальном кабеле;
• звезда (англ. star) — все узлы подключены к центральному устройству; современный Ethernet с коммутатором, при этом логически — набор двухточечных связей;
• кольцо (англ. ring) — каждый узел соединён с двумя соседями; Token Ring, FDDI, оптические кольца операторов;
• полносвязная сеть (англ. full mesh) — каждый узел соединён с каждым; число связей n(n − 1)/2 быстро растёт: для 10 узлов это 45 каналов, для 100 — 4950;
• частично связная сеть (англ. partial mesh) и дерево (англ. tree) — компромиссы, типичные для реальных сетей.

Выбор топологии — компромисс между стоимостью, надёжностью и простотой управления. Звезда дешева и проста, но центральный узел становится единой точкой отказа; полносвязная сеть надёжна, но дорога. Магистраль Интернета — частично связная сеть с избыточными путями, как и предлагал Баран.

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

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

Слово «скорость» в применении к сети многозначно, и для точного разговора нужно различать несколько величин.

Скорость передачи канала R — номинальная скорость, с которой передатчик выдаёт биты в среду. Её часто называют полосой пропускания (англ. bandwidth), хотя строго полоса пропускания — это ширина диапазона частот в герцах; связь между ними устанавливают теоремы Найквиста и Шеннона (тема 3).

Пропускная способность (англ. throughput) — фактическая скорость, с которой данные доставляются от отправителя получателю за некоторый интервал. Она не превышает скорости самого медленного канала на пути — узкого места (англ. bottleneck): если сервер подключён на 1 Гбит/с, магистраль работает на 100 Гбит/с, а у абонента тариф 50 Мбит/с, то файл будет загружаться не быстрее 50 Мбит/с. Если канал разделяют несколько потоков, каждому достаётся лишь часть его скорости.

Полезная пропускная способность (англ. goodput) — скорость доставки собственно данных приложения, без заголовков протоколов и повторно переданных пакетов. Она всегда меньше пропускной способности: заголовки занимают место в каждом пакете (тема 2 показывает, сколько именно), а потерянные пакеты передаются повторно (тема 13).

Наконец, важно отличать мгновенную и среднюю пропускную способность. Счётчик загрузки в браузере показывает среднее за секунды; на интервалах в миллисекунды скорость колеблется от нуля до скорости канала.

Четыре составляющие задержки

Задержка (англ. delay, latency) — время, которое пакет проводит в пути. На каждом узле пути она складывается из четырёх составляющих, показанных на рисунке ниже ¹.

Задержка обработки (англ. processing delay, d_proc) — время на разбор заголовка, проверку контрольной суммы и выбор исходящего канала. В аппаратных маршрутизаторах она составляет микросекунды и меньше; в программных реализациях может быть больше.

Задержка ожидания в очереди (англ. queuing delay, d_queue) — время, которое пакет ждёт, пока будут переданы пакеты, стоящие перед ним. Это единственная составляющая, сильно меняющаяся от пакета к пакету: от нуля при пустой очереди до сотен миллисекунд при переполненном буфере.

Задержка передачи (англ. transmission delay, d_trans) — время, необходимое передатчику, чтобы выдать в канал все биты пакета:

d_{\text{trans}} = \frac{L}{R}

где L — длина пакета в битах, R — скорость передачи канала в бит/с. Кадр Ethernet длиной 1500 байт (12 000 бит) передаётся по каналу 10 Мбит/с за 1,2 мс, по каналу 100 Мбит/с — за 120 мкс, по каналу 10 Гбит/с — за 1,2 мкс.

Задержка распространения (англ. propagation delay, d_prop) — время, за которое сигнал проходит физическое расстояние от одного узла до другого:

d_{\text{prop}} = \frac{d}{s}

где d — длина канала, s — скорость распространения сигнала в среде. В вакууме свет проходит около 300 000 км/с, в оптическом волокне с показателем преломления сердцевины около 1,47 — примерно 204 000 км/с, что даёт удобное для запоминания правило: около 5 мкс на километр. В медном кабеле скорость распространения того же порядка, примерно 0,6–0,8 скорости света.

Полная задержка на узле равна сумме: d_nodal = d_proc + d_queue + d_trans + d_prop. Сквозная задержка (англ. end-to-end delay) пути из N участков — сумма задержек на всех участках.

Самая распространённая ошибка понимания — смешение задержки передачи и задержки распространения. Первая зависит от длины пакета и скорости канала и не зависит от расстояния; вторая зависит только от расстояния и среды и не зависит ни от длины пакета, ни от скорости канала. Помогает аналогия с колонной автомобилей, проезжающей пункт оплаты: время, за которое вся колонна проходит через шлагбаум, — аналог задержки передачи, а время, за которое головная машина доезжает до следующего пункта, — аналог задержки распространения. Увеличение скорости канала с 1 до 10 Гбит/с в десять раз сокращает задержку передачи, но ни на микросекунду не сокращает задержку распространения из Москвы во Владивосток.

Подробный числовой пример: из Москвы во Франкфурт

Рассмотрим путь от сервера в Москве к серверу во Франкфурте. Расстояние по дуге большого круга — около 2021 км, однако кабели проложены не по прямой, и реальная трасса может быть длиннее в полтора-два раза. Пусть длина трассы 3000 км, пакет имеет длину 1500 байт, на пути 8 маршрутизаторов, и все каналы работают на скорости 10 Гбит/с, кроме последнего, 1 Гбит/с.

1. Распространение: 3000 км × 5 мкс/км = 15 мс в одну сторону.
2. Передача: на восьми каналах по 10 Гбит/с — 8 × 12 000 / 10¹⁰ = 8 × 1,2 мкс ≈ 0,010 мс; на последнем, девятом канале 12 000 / 10⁹ = 12 мкс = 0,012 мс. Итого около 0,022 мс.
3. Обработка: при 10 мкс на маршрутизатор — 0,08 мс.
4. Очереди: при слабой загрузке — порядка десятков микросекунд суммарно.

Итого задержка в одну сторону около 15,1 мс, из которых более 99 % приходится на распространение. Для дальних путей в магистральной сети это типичная картина: скорость каналов настолько велика, что задержка определяется в основном физикой — расстоянием и скоростью света. Совсем иначе выглядит та же оценка для абонентского канала 1 Мбит/с: передача 1500 байт по нему занимает уже 12 мс, сопоставимо с распространением на тысячи километров.

Оценку нижней границы задержки по расстоянию выполняет скрипт geo_rtt.py из окружения лабораторной работы 1:

python3 geo_rtt.py Москва Франкфурт --measured 42

Москва -> Франкфурт: по дуге большого круга 2 021 км
скорость света в волокне c/n = 204 218 км/с (4.90 мкс/км)
задержка распространения в одну сторону >= 9.9 мс
RTT >= 19.8 мс (для сравнения, в вакууме: 13.5 мс)
измерено 42.0 мс: в 2.12 раза больше нижней границы;
эквивалентная длина трассы туда и обратно ~ 8 577 км

Измеренное время более чем вдвое превосходит физический предел. Причины — непрямая трасса кабелей, обходные маршруты, выбираемые по экономическим соображениям, и добавки в сетях доступа.

Время кругового обхода и утилита ping

Задержку в одну сторону измерить трудно: для этого часы отправителя и получателя должны быть синхронизированы с точностью до долей миллисекунды. Поэтому на практике чаще измеряют время кругового обхода (англ. round-trip time, RTT) — интервал от отправки запроса до получения ответа. Его измеряют на одних часах, и синхронизация не нужна. RTT включает задержку в обе стороны и время обработки запроса получателем; пути туда и обратно в Интернете могут не совпадать (в выводе tracepath выше на это указывает пометка asymm).

Простейший инструмент измерения RTT — утилита ping, посылающая эхо-запросы протокола ICMP (тема 7) и замеряющая время до прихода ответа:

ping -c 20 -i 0.2 example.com

PING example.com (8.6.112.5) 56(84) bytes of data.
64 bytes from 8.6.112.5 (8.6.112.5): icmp_seq=1 ttl=52 time=40.2 ms
...
--- example.com ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3815ms
rtt min/avg/max/mdev = 39.633/40.117/42.830/0.715 ms

Итоговая строка содержит минимальное, среднее и максимальное значения RTT, а также mdev — среднеквадратичное отклонение. Особенно информативен минимум: в нём меньше всего случайных добавок от очередей, и он ближе всего к сумме «постоянных» составляющих — распространения, передачи и обработки. Разность между средним и минимумом даёт оценку вклада очередей и прочих переменных задержек.

Джиттер и потери

Джиттер (англ. jitter) — изменчивость задержки от пакета к пакету. Строго в стандартах различают два определения ⁸. Вариация задержки между соседними пакетами (англ. inter-packet delay variation, IPDV) — разность задержек последовательных пакетов. Вариация задержки относительно минимума (англ. packet delay variation, PDV) — превышение задержки каждого пакета над минимальной. Протокол передачи данных в реальном времени RTP использует сглаженную оценку J, обновляемую по каждому пакету по формуле J ← J + (|D| − J)/16, где D — изменение задержки между соседними пакетами ¹⁰.

Джиттер критичен для интерактивных приложений. Аудиопоток IP-телефонии состоит из пакетов, отправляемых каждые 20 мс; если они приходят неравномерно, получатель накапливает их в буфере воспроизведения (англ. jitter buffer), добавляя задержку, равную ожидаемому разбросу. Рекомендация ITU-T G.114 указывает, что задержка в одну сторону до 150 мс приемлема для большинства разговорных приложений, а свыше 400 мс — как правило, неприемлема ¹².

Потери пакетов (англ. packet loss) измеряются долей неполученных пакетов. Их основная причина в проводных сетях — переполнение буферов в очередях маршрутизаторов; искажение бит при передаче, обнаруживаемое контрольной суммой, — вторая, значительно более редкая в проводных сетях причина, но обычная для радиоканалов. Даже небольшие потери существенно снижают производительность TCP, потому что TCP интерпретирует потерю как признак перегрузки и снижает скорость отправки (тема 13).

Произведение пропускной способности на задержку

Представим канал как трубу: скорость передачи — её поперечное сечение, задержка — длина. Объём трубы равен числу бит, которые одновременно находятся «в полёте», когда отправитель передаёт непрерывно. Эта величина называется произведением пропускной способности на задержку (англ. bandwidth-delay product, BDP):

\text{BDP} = R \times \text{RTT}

Чаще берут произведение на RTT, а не на одностороннюю задержку, потому что отправитель надёжного протокола узнаёт о доставке данных только через RTT, получив подтверждение. Пример: канал 1 Гбит/с с RTT 80 мс (Москва — Нью-Йорк) имеет BDP = 10⁹ × 0,08 = 8 × 10⁷ бит = 10 000 000 байт, то есть около 10 МБ. Это означает, что отправитель должен иметь в пути 10 МБ неподтверждённых данных, чтобы загрузить канал полностью. Если протокол разрешает держать в пути не более 64 КиБ (65 535 байт — максимум окна TCP без расширений), то максимальная пропускная способность составит 65 535 × 8 / 0,08 ≈ 6,6 Мбит/с — менее 1 % ёмкости канала. Каналы с большим BDP получили название «длинных толстых сетей» (англ. long fat network, LFN), и для них в TCP пришлось вводить расширения ⁷. Подробно это обсуждается в теме 13.

Очереди и загрузка канала

Интенсивность трафика

Задержка ожидания в очереди — самая интересная составляющая, потому что она зависит не от устройства сети, а от поведения трафика. Пусть в канал со скоростью R бит/с поступает в среднем a пакетов в секунду длиной L бит. Отношение

\rho = \frac{L \cdot a}{R}

называется интенсивностью трафика (англ. traffic intensity), или загрузкой канала (англ. utilization). Оно показывает, какую долю времени канал занят передачей. Если ρ > 1, биты поступают быстрее, чем канал успевает их передавать, очередь растёт неограниченно (на практике — до переполнения буфера), и задержка стремится к бесконечности. Отсюда первое правило проектирования: средняя загрузка канала должна быть меньше единицы.

Менее очевидно, что происходит при ρ < 1. Если пакеты поступают строго периодически — например, ровно по одному каждые L/R секунд при ρ = 1, — то каждый новый пакет приходит в момент, когда предыдущий уже передан, и очереди нет вовсе. Но реальный трафик пачечный: пакеты приходят группами, и даже при средней загрузке 50 % в отдельные моменты несколько пакетов приходят одновременно и вынуждены ждать.

Как задержка растёт с загрузкой

Количественно эффект описывает теория массового обслуживания ⁹. Для простейшей модели — одна очередь, неограниченный буфер, пакеты приходят случайно и независимо (пуассоновский поток), длины пакетов распределены экспоненциально; эта модель обозначается M/M/1 — среднее время ожидания в очереди равно

W_q = \frac{\rho}{1 - \rho} \cdot \frac{L}{R}

то есть выражается в единицах времени передачи одного пакета. При ρ = 0,5 пакет ждёт в среднем столько же, сколько длится передача одного пакета; при ρ = 0,8 — в четыре раза дольше; при ρ = 0,9 — в девять; при ρ = 0,95 — в девятнадцать. Рост нелинеен, что показывает график ниже.

Конкретные числа справедливы только для модели M/M/1, но качественный вывод верен для любых реалистичных моделей: при загрузке, далёкой от единицы, очередь мала, а при приближении к единице задержка растёт стремительно. Поэтому каналы проектируют с запасом, а загрузку свыше 70–80 % считают признаком необходимости расширения. Обратное следствие тоже важно: увеличение скорости канала вдвое не только вдвое сокращает время передачи, но и, снижая ρ, может уменьшить задержку в очереди во много раз.

Числовой пример. Канал 10 Мбит/с, пакеты по 1250 байт (10 000 бит), время передачи одного пакета 1 мс. При 500 пакетах в секунду ρ = 10 000 × 500 / 10⁷ = 0,5, среднее ожидание 1 мс. При 900 пакетах в секунду ρ = 0,9, ожидание 9 мс. При 950 пакетах в секунду ожидание 19 мс — увеличение нагрузки всего на 5,5 % удвоило задержку.

Буферы, потери и раздувание буферов

Реальный буфер конечен. Когда он заполнен, вновь прибывший пакет отбрасывается — так возникают потери. Казалось бы, большой буфер лучше: меньше потерь. Однако буфер, который постоянно заполнен, добавляет к задержке каждого пакета время его опустошения. Буфер 1 МБ на канале 10 Мбит/с — это 0,8 с дополнительной задержки. Явление, когда избыточно большие буферы в домашних маршрутизаторах и модемах создают постоянную очередь и задержку в сотни миллисекунд, получило название «раздувание буферов» (англ. bufferbloat). Оно проявляется, например, в том, что во время загрузки большого файла видеозвонок по той же линии становится невозможным. Средства борьбы с ним — алгоритмы активного управления очередью — упоминаются в темах 13 и 22.

Полезно связать очередь и задержку ещё одним соотношением, справедливым для любой устойчивой системы. Закон Литтла утверждает, что среднее число пакетов в системе N равно произведению интенсивности поступления λ на среднее время пребывания T: N = λ · T ⁹. Если маршрутизатор принимает 100 000 пакетов в секунду, а каждый пакет проводит в нём в среднем 2 мс, то в буфере в среднем находится 200 пакетов.

Стандартизация и управление ресурсами Интернета

IETF и серия RFC

Основные протоколы Интернета разрабатывает Инженерный совет Интернета (англ. Internet Engineering Task Force, IETF) — открытое сообщество без формального членства, работа которого ведётся в рабочих группах через списки рассылки и на очных встречах трижды в год. Документы IETF публикуются в серии RFC. Каждый RFC имеет номер и никогда не изменяется после публикации; исправления и новые версии выходят под новыми номерами, а старые помечаются как устаревшие (англ. obsoleted). Например, исходная спецификация TCP в RFC 793 заменена в 2022 году документом RFC 9293.

Не каждый RFC является стандартом. Процесс стандартизации описан в RFC 2026 ¹³ с последующими уточнениями: документы делятся на ряд статусов, среди которых стандарты (англ. standards track), информационные (англ. informational), экспериментальные (англ. experimental) документы и документы лучшей практики (англ. best current practice, BCP). Документ стандартной дорожки проходит уровни зрелости — с 2011 года (RFC 6410) их два: предлагаемый стандарт (англ. Proposed Standard) и стандарт Интернета (англ. Internet Standard). Проекты документов, ещё не ставшие RFC, публикуются как черновики (англ. Internet-Draft) со сроком жизни шесть месяцев. Культуру IETF выражает известная формула: «грубый консенсус и работающий код» (англ. rough consensus and running code) — решения принимаются не голосованием, а по согласию большинства, подкреплённому действующими реализациями. Как читать RFC, разбирается в теме 2.

IEEE 802, ITU и другие организации

Технологии локальных сетей стандартизирует комитет IEEE 802 Института инженеров электротехники и электроники (англ. Institute of Electrical and Electronics Engineers, IEEE), созданный в 1980 году. Его рабочие группы отвечают за отдельные семейства: 802.1 — мосты и управление (в том числе VLAN, тема 5), 802.3 — Ethernet (тема 4), 802.11 — беспроводные локальные сети Wi-Fi (тема 20), 802.15 — персональные сети. Номер группы входит в название стандарта: «IEEE 802.3» означает стандарт Ethernet.

Международный союз электросвязи (англ. International Telecommunication Union, ITU) — специализированное учреждение ООН, основанное в 1865 году как Международный телеграфный союз. Его сектор стандартизации ITU-T выпускает рекомендации, касающиеся телефонии, транспортных сетей операторов и качества обслуживания (как упомянутая G.114). Стандарты мобильной связи 4G и 5G разрабатывает консорциум 3GPP, веб-технологии — консорциум W3C и сообщество WHATWG.

Распределение адресов и имён: ICANN, IANA и RIR

Чтобы адреса и номера в Интернете были уникальны, их распределением кто-то должен управлять. Глобальные реестры — адресного пространства IP, номеров автономных систем, номеров портов и параметров протоколов, корневой зоны системы доменных имён — ведёт служба IANA (англ. Internet Assigned Numbers Authority), функционирующая под эгидой некоммерческой корпорации ICANN (англ. Internet Corporation for Assigned Names and Numbers), созданной в 1998 году.

IANA не раздаёт адреса конечным пользователям. Она передаёт крупные блоки пяти региональным интернет-регистратурам (англ. Regional Internet Registry, RIR), которые распределяют адреса провайдерам и организациям своего региона ¹⁴:

Иерархическое распределение — IANA, RIR, провайдер, организация — объясняет многие свойства адресации, которые будут рассмотрены в теме 6. Исчерпание свободного пространства IPv4 (IANA выдала последние блоки в 2011 году) стало главной причиной распространения трансляции адресов (тема 14) и перехода на IPv6 (тема 11).

Итоги темы

Компьютерная сеть состоит из узлов, соединённых каналами, и существует ради сервисов, предоставляемых прикладным программам; взаимодействие узлов определяется протоколами — соглашениями о формате, смысле и порядке сообщений. Интернет не спроектирован как единая сеть: он вырос из ARPANET как объединение независимых сетей, соединённых маршрутизаторами по общим протоколам TCP/IP, и сегодня представляет собой «сеть сетей» из десятков тысяч автономных систем, связанных отношениями транзита и пиринга, часто в точках обмена трафиком.

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

Поведение сети описывается метриками. Скорость канала, пропускная способность и полезная пропускная способность — разные величины, и последняя всегда ограничена узким местом пути. Задержка на каждом участке складывается из обработки, ожидания в очереди, передачи (L/R, зависит от длины пакета и скорости канала) и распространения (d/s, зависит только от расстояния); на дальних путях доминирует распространение, ограниченное скоростью света в волокне — около 5 мкс на километр. RTT измеряется на одних часах, его минимум отражает постоянные составляющие, а разброс — очереди; джиттер и потери определяют качество интерактивных приложений. Произведение скорости на RTT показывает, сколько данных должно быть в пути, чтобы загрузить канал, и станет ключевой величиной при изучении TCP.

Задержка в очереди нелинейно зависит от загрузки канала: при приближении загрузки к единице она растёт неограниченно, поэтому каналы проектируют с запасом. Протоколы, в которых закреплены эти механизмы, создаются в открытом процессе IETF, IEEE и ITU, а адреса и номера распределяются иерархически через IANA и региональные регистратуры.

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

Литература

1. Kurose J. F., Ross K. W. Computer Networking: A Top-Down Approach. 8th ed. — Pearson, 2021.
2. Tanenbaum A. S., Feamster N., Wetherall D. J. Computer Networks. 6th ed. — Pearson, 2021.
3. Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы. 5-е изд. — СПб.: Питер, 2016.
4. Cerf V. G., Kahn R. E. A Protocol for Packet Network Intercommunication. — IEEE Transactions on Communications, 1974, Vol. 22, No. 5, С. 637–648, DOI: 10.1109/TCOM.1974.1092259.
5. Leiner B. M., Cerf V. G., Clark D. D., Kahn R. E., Kleinrock L., Lynch D. C., Postel J., Roberts L. G., Wolff S. A Brief History of the Internet. — ACM SIGCOMM Computer Communication Review, 2009, Vol. 39, No. 5, С. 22–31, DOI: 10.1145/1629607.1629613.
6. Baran P. On Distributed Communications Networks. — IEEE Transactions on Communications Systems, 1964, Vol. 12, No. 1, С. 1–9, DOI: 10.1109/TCOM.1964.1088883.
7. Jacobson V., Braden R. TCP Extensions for Long-Delay Paths. — RFC 1072, IETF, 1988. https://www.rfc-editor.org/rfc/rfc1072
8. Morton A., Claise B. Packet Delay Variation Applicability Statement. — RFC 5481, IETF, 2009. https://www.rfc-editor.org/rfc/rfc5481
9. Kleinrock L. Queueing Systems. Vol. 1: Theory. — Wiley, 1975.
10. Schulzrinne H., Casner S., Frederick R., Jacobson V. RTP: A Transport Protocol for Real-Time Applications. — RFC 3550, IETF, 2003. https://www.rfc-editor.org/rfc/rfc3550
11. Labovitz C., Iekel-Johnson S., McPherson D., Oberheide J., Jahanian F. Internet Inter-Domain Traffic. — Proceedings of ACM SIGCOMM 2010, 2010, DOI: 10.1145/1851182.1851194.
12. ITU-T Recommendation G.114. One-way transmission time. — ITU, 2003.
13. Bradner S. The Internet Standards Process — Revision 3. — RFC 2026, IETF, 1996. https://www.rfc-editor.org/rfc/rfc2026
14. Housley R., Curran J., Huston G., Conrad D. The Internet Numbers Registry System. — RFC 7020, IETF, 2013. https://www.rfc-editor.org/rfc/rfc7020

Дополнительные материалы

Вопросы для самопроверки

1. Назовите три составляющие компьютерной сети и приведите для каждой по два примера.
2. Чем протокол отличается от сервиса? Приведите пример сервиса, который может быть реализован разными протоколами.
3. Почему коммутация каналов неэффективна для пачечного трафика? В каком случае она, наоборот, предпочтительна?
4. Канал 2 Мбит/с, пользователи активны 20 % времени и в активном состоянии передают 200 Кбит/с. Сколько пользователей выдержит канал при коммутации каналов? Как оценить допустимое число пользователей при коммутации пакетов?
5. Какой вклад внесла статья Серфа и Кана 1974 года? Какие её идеи сохранились в современном Интернете?
6. Сообщение 1 МБ передаётся через 4 звена по 100 Мбит/с с промежуточным хранением. Сравните время доставки при передаче одним пакетом и пакетами по 1500 байт (без учёта заголовков, распространения и очередей).
7. Почему увеличение скорости магистрального канала почти не влияет на RTT между Москвой и Нью-Йорком?
8. Что такое узкое место пути и почему пропускная способность не может его превысить?
9. Чем различаются определения джиттера IPDV и PDV?
10. Рассчитайте BDP для канала 10 Гбит/с с RTT 30 мс. Какой размер окна TCP нужен, чтобы загрузить такой канал?
11. Загрузка канала выросла с 0,6 до 0,9. Во сколько раз, согласно модели M/M/1, выросло среднее ожидание в очереди?
12. Почему большой буфер в домашнем маршрутизаторе может ухудшить качество видеозвонка?
13. Чем транзит отличается от пиринга? Зачем сетям точки обмена трафиком?
14. Чем отличается RFC со статусом Proposed Standard от информационного RFC? Можно ли изменить текст опубликованного RFC?
15. Какие организации выделяют IP-адреса провайдеру в России и в чём состоит роль IANA?

Глоссарий темы

Шпаргалка по инструментам

Обзор хоста:

ip -br link                       # интерфейсы: имя, состояние, MAC
ip -br addr                       # интерфейсы и адреса
ip route                          # таблица маршрутизации
ip route get 8.8.8.8              # какой маршрут выбран для адреса
ip neigh                          # таблица соседей (ARP)
ss -tn state established          # установленные соединения TCP
ss -tunlp                         # прослушивающие сокеты и их процессы
resolvectl status                 # DNS-серверы (systemd-resolved)

Измерение задержки и пути:

ping -c 50 -i 0.2 адрес           # 50 запросов с интервалом 0,2 с
ping -s 1400 адрес                # данные ICMP размером 1400 байт
ping -q -c 100 адрес              # только итоговая статистика
tracepath -n адрес                # путь и MTU пути
mtr -n -r -c 50 адрес             # статистика по каждому узлу пути

Захват трафика:

sudo tcpdump -i eth0 -n                   # вывод на экран, без имён
sudo tcpdump -i eth0 -n -e icmp           # с заголовками Ethernet, только ICMP
sudo tcpdump -i eth0 -w f.pcap -c 100     # 100 пакетов в файл
tcpdump -n -r f.pcap                      # чтение файла

Пространства имён:

sudo ip netns add h1                      # создать
sudo ip netns list                        # перечислить
sudo ip netns exec h1 bash                # оболочка «внутри» h1
sudo ip -n h1 addr                        # команда ip в h1
sudo ip link add a type veth peer name b  # пара veth
sudo ip link set a netns h1               # перенести конец в h1
sudo ip netns del h1                      # удалить

Что почитать и посмотреть

• Kurose J., Ross K. Computer Networking: A Top-Down Approach, глава 1 — классическое введение: составляющие задержки, статистическое мультиплексирование, структура Интернета. На сайте авторов https://gaia.cs.umass.edu/kurose_ross/ есть интерактивные упражнения и анимации задержек.
• Leiner B. et al. A Brief History of the Internet — история Интернета, написанная его создателями: internetsociety.org. Короткий и авторитетный текст.
• Cerf V., Kahn R. A Protocol for Packet Network Intercommunication (1974) — статья, с которой начался TCP/IP; полезно прочесть первые разделы и сопоставить с устройством современного Интернета.
• RFC 2026 «The Internet Standards Process» и RFC 8179 о правах в IETF — как работает стандартизация; более доступное введение — «The Tao of IETF» на ietf.org.
• Jim Gettys, Kathleen Nichols. Bufferbloat: Dark Buffers in the Internet. — ACM Queue, 2011 — статья, давшая имя явлению раздувания буферов; сайт bufferbloat.net содержит тесты и рекомендации.
• Julia Evans. Networking! ACK! и другие «zines» — популярные иллюстрированные введения в сетевые инструменты: wizardzines.com.
• Карта подводных кабелей TeleGeography — submarinecablemap.com: наглядно показывает, почему реальная трасса длиннее дуги большого круга.
• Статистика и аналитика APNIC Labs и RIPE Labs (labs.ripe.net) — исследования задержек, точек обмена и распределения адресов на реальных данных.
• Jeff Dean, Peter Norvig. Latency numbers every programmer should know — таблица характерных задержек от кеша процессора до межконтинентального RTT; полезна для развития «чувства масштаба».
• Документация ip-netns(8) на man7.org — устройство пространств имён и команды работы с ними.

Углубление (по желанию)

Скорость света как предел и бизнес

Задержка распространения — единственная составляющая, которую нельзя уменьшить ни деньгами, ни технологиями передачи, только сокращением пути. Поэтому для приложений, где миллисекунда стоит денег, прокладываются специальные трассы. В 2010 году был построен оптический кабель между Чикаго и Нью-Йорком, проложенный максимально прямо, что сократило RTT между биржами примерно с 14,5 до 13 мс. Через несколько лет для той же задачи стали использовать цепочки микроволновых радиорелейных станций: в воздухе сигнал идёт почти со скоростью света в вакууме, примерно в полтора раза быстрее, чем в стекле. Другой подход — волокно с полой сердцевиной (англ. hollow-core fiber), в котором свет идёт в основном по воздуху. Эти примеры показывают, что расчёт d/s — не школьное упражнение, а основа реальных инженерных решений.

Почему 64 Кбит/с

Скорость основного цифрового канала телефонии 64 Кбит/с выведена из двух чисел. Голос в телефонии ограничен полосой примерно 300–3400 Гц; по теореме отсчётов для восстановления такого сигнала нужно брать отсчёты с частотой не менее удвоенной верхней частоты, и выбрана частота 8000 Гц с запасом. Каждый отсчёт кодируется 8 битами с нелинейной шкалой (законы A и μ рекомендации ITU-T G.711), что даёт 8000 × 8 = 64 000 бит/с. Отсюда же длительность цикла TDM 125 мкс — интервал между отсчётами. Эти числа пережили саму аналоговую телефонию: длительность голосового пакета IP-телефонии 20 мс — это ровно 160 отсчётов G.711. Теорема отсчётов и её связь со скоростью передачи подробно рассматриваются в теме 3.

Закон Литтла в повседневной диагностике

Соотношение N = λT, упомянутое в теме, применимо далеко за пределами маршрутизаторов. Если веб-сервер обрабатывает 2000 запросов в секунду, а среднее время ответа 50 мс, то одновременно в обработке находится в среднем 100 запросов, и пул из 64 рабочих потоков заведомо станет узким местом. Если в TCP-соединении «в полёте» 1 МБ данных, а скорость доставки 80 Мбит/с, то время пребывания байта в сети — 100 мс: это и есть RTT, и рассуждение повторяет определение BDP. Закон Литтла не требует никаких предположений о распределениях, поэтому им удобно проверять согласованность измерений: если три величины, измеренные независимо, не удовлетворяют соотношению, значит, одна из них измерена неверно.

Лабораторная работа 1. Рабочее место сетевого инженера

• Раздел курса: тема 1 «Компьютерная сеть: основные понятия и метрики»

Введение

Сетевой инженер работает с объектом, который невозможно увидеть непосредственно: пакеты существуют доли миллисекунды, а сеть, по которой они идут, принадлежит десяткам организаций. Поэтому первое, чему необходимо научиться, — наблюдать сеть инструментами: узнавать конфигурацию собственного хоста, измерять задержку и потери, видеть путь пакета и сами пакеты. Настоящая работа готовит рабочее место, которое будет использоваться во всём курсе, и связывает метрики темы 1 — RTT, джиттер, потери, задержки передачи и распространения — с реальными измерениями.

Работа состоит из шести частей. В первой части устанавливаются инструменты и изучается конфигурация хоста. Во второй и третьей измеряются RTT до узлов на разном удалении и прослеживается путь пакетов. В четвёртой измеренные значения сопоставляются с физическим пределом — скоростью света в волокне. В пятой выполняется первый захват трафика и строится первая учебная топология из двух сетевых пространств имён; в ней же вносится и устраняется неисправность. Шестая часть — продвинутая: на эмулированном канале задержка RTT разлагается на составляющие передачи и распространения.

Части 1–5 составляют базовую часть. Часть 6 выполняется по желанию.

Цель работы

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

После выполнения работы можно будет:

• установить и проверить набор сетевых инструментов курса в Ubuntu 24.04 или WSL2;
• определить по выводу ip, ss и resolvectl интерфейсы, адреса, шлюз по умолчанию, DNS-серверы и открытые соединения хоста;
• измерить RTT и потери утилитой ping и рассчитать статистику (минимум, медиана, джиттер) по выборке;
• проследить путь пакетов утилитами tracepath и mtr и указать участки с наибольшим приростом задержки;
• оценить нижнюю границу RTT по расстоянию и объяснить расхождение с измерением;
• выполнить захват трафика tcpdump и открыть его в Wireshark;
• построить топологию из двух сетевых пространств имён, соединённых парой veth, и найти в ней внесённую неисправность.

Теоретический минимум

Необходимый материал изложен в теме 1: разделы «Метрики производительности сети» (составляющие задержки, RTT, джиттер, потери) и «Очереди и загрузка канала». Ниже приведена сжатая справка.

Задержка пакета на одном участке складывается из обработки, ожидания в очереди, передачи L/R (L — длина в битах, R — скорость канала) и распространения d/s (d — длина канала, s — скорость сигнала в среде; в волокне около 204 000 км/с, или примерно 4,9 мкс/км). RTT — время от отправки запроса до получения ответа; его минимум по выборке ближе всего к сумме постоянных составляющих, а разность среднего и минимума характеризует очереди. Джиттер — изменчивость задержки; в работе он оценивается как среднее модуля разности соседних RTT.

Основные команды работы:

Сетевое пространство имён (англ. network namespace) — механизм ядра Linux, дающий группе процессов собственный, изолированный набор интерфейсов, адресов, маршрутов и сокетов. С точки зрения сети процесс в отдельном пространстве имён находится на отдельном «компьютере». Пара veth (англ. virtual Ethernet) — два виртуальных интерфейса, соединённых, как концы кабеля: кадр, отправленный в один конец, появляется на другом. Учебная топология работы:

Полезные фильтры. Фильтр захвата tcpdump (синтаксис BPF): icmp, arp, host 10.0.0.2, icmp or arp. Фильтр отображения Wireshark: icmp, arp, ip.addr == 10.0.0.2, frame.len > 1000.

Перечень оснащения

• Ubuntu 24.04 (физическая или виртуальная машина) либо Ubuntu 24.04 в WSL2 под Windows 10/11; для WSL2 желательна версия с WSLg, позволяющая запускать графический Wireshark.
• Права администратора (sudo) — нужны для захвата трафика и работы с пространствами имён.
• Доступ в Интернет для частей 1–4.
• Пакеты курса устанавливаются командой:

sudo apt update
sudo apt install -y iproute2 iputils-ping iputils-tracepath traceroute mtr-tiny \
    tcpdump tshark wireshark ethtool bridge-utils iperf3 netcat-openbsd socat curl \
    bind9-dnsutils dnsmasq nftables conntrack wireguard-tools openssl python3 nmap

При установке wireshark система спросит, разрешить ли захват непривилегированным пользователям; ответ «Да» и добавление себя в группу wireshark (sudo usermod -aG wireshark $USER, затем повторный вход) позволит запускать Wireshark без sudo.

• Архив окружения lr-env: скрипты топологии up.sh, down.sh, break.sh, delay.sh и программы анализа ping_stats.py, geo_rtt.py, size_sweep.py. Распакуйте его в ~/lab01 и сделайте скрипты исполняемыми: chmod +x ~/lab01/*.sh ~/lab01/*.py.

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

Все команды выполняются в каталоге ~/lab01. Команды, изменяющие сетевую конфигурацию или захватывающие трафик, требуют sudo. Учебная топология поднимается командой sudo ./up.sh и разбирается командой sudo ./down.sh; разбор безопасен и при повторном вызове, поэтому при любой путанице достаточно выполнить sudo ./down.sh && sudo ./up.sh. Пространства имён не переживают перезагрузку системы.

В заданиях встречается требование «предскажите». Предсказание записывается в журнал до выполнения эксперимента, вместе с обоснованием; неверное предсказание не страшно, если в журнале работы объяснено, почему результат оказался иным. Именно расхождение между ожиданием и наблюдением — главный источник понимания.

Журнал ведётся по ходу работы: для каждой части сохраняются команды, их выводы (текстом, а не снимками экрана, кроме снимков Wireshark) и ответы на вопросы.

Часть 1. Установка инструментов и обзор своего хоста

Задание

1. Установите пакеты курса командой из раздела «Перечень оснащения». Проверьте версии ключевых инструментов:

ip -V
tcpdump --version
tshark --version | head -1
python3 --version

2. Выведите сведения об интерфейсах хоста в краткой и полной форме:

ip -br link
ip -br addr
ip addr show dev lo

Для каждого интерфейса запишите имя, состояние (UP, DOWN, UNKNOWN), MAC-адрес и IPv4-адрес с длиной префикса. Определите, какой интерфейс связывает хост с внешней сетью.

3. Выведите таблицу маршрутизации и найдите шлюз по умолчанию:

ip route
ip route get 1.1.1.1

Команда ip route get показывает, каким маршрутом, через какой интерфейс и с каким адресом источника был бы отправлен пакет на заданный адрес.

4. Определите DNS-серверы, к которым обращается система:

resolvectl status | grep -E 'DNS Server|Current DNS'
cat /etc/resolv.conf

В Ubuntu с systemd-resolved файл /etc/resolv.conf обычно указывает на локальный адрес 127.0.0.53, а реальные серверы видны в resolvectl. В WSL2 systemd-resolved может быть не запущен; тогда resolvectl сообщит об ошибке, и сведения берутся из /etc/resolv.conf, который WSL генерирует автоматически.

5. Откройте в браузере любую страницу и, пока она загружается, выведите установленные соединения:

ss -tn state established
ss -tunlp

Первая команда показывает установленные соединения TCP, вторая — сокеты TCP и UDP в состоянии прослушивания (-l) с процессами-владельцами (-p, для чужих процессов требуется sudo). Определите, какие порты удалённых серверов встречаются чаще всего.

Что должно получиться

Таблица интерфейсов хоста (имя, состояние, MAC, IPv4), адрес шлюза по умолчанию и интерфейс, через который он достижим, адреса DNS-серверов, список из 3–5 установленных соединений с указанием удалённого порта. Ответ на вопрос: почему у интерфейса lo нет MAC-адреса, отличного от нулевого, и зачем хосту петлевой интерфейс.

Часть 2. Задержка и её разброс: ping

Задание

1. Выберите три цели:

   • шлюз по умолчанию из части 1;
   • сервер в своём городе или регионе (например, сайт своего университета или городского портала);
   • сервер на другом континенте (например, сайт университета в США, Австралии или Японии).

   Для каждой цели предскажите минимальный RTT и запишите предсказание с обоснованием.

2. Выполните по 50 запросов к каждой цели с интервалом 0,2 с и сохраните вывод в файлы:

ping -c 50 -i 0.2 192.168.1.1 > gw.txt        # адрес шлюза — свой
ping -c 50 -i 0.2 www.example.ru > local.txt   # сервер своего региона — свой
ping -c 50 -i 0.2 www.example.edu > far.txt    # сервер другого континента — свой
tail -2 far.txt

Некоторые серверы не отвечают на эхо-запросы ICMP (это решение их администраторов, тема 18); в таком случае выберите другую цель.

3. Обработайте выборки скриптом ping_stats.py, который вычисляет потери, минимум, среднее, медиану, 95-й процентиль, максимум RTT и две оценки джиттера:

python3 ping_stats.py gw.txt local.txt far.txt --csv rtt.csv

Пример вывода для двух целей — шлюза WSL2 и удалённого сервера:

== gw.txt: 172.27.48.1
   отправлено 50, получено 50, потери 0.0 %
   RTT, мс: min 0.285  среднее 0.369  медиана 0.354  p95 0.478  max 0.522
   разброс, мс: mdev 0.066  джиттер (ср. |dRTT|) 0.070  джиттер RFC 3550 0.055
   доля очереди и прочих переменных задержек: среднее - min = 0.084 мс
== far.txt: example.com
   отправлено 50, получено 50, потери 0.0 %
   RTT, мс: min 39.600  среднее 40.125  медиана 39.900  p95 41.185  max 42.800
   разброс, мс: mdev 0.710  джиттер (ср. |dRTT|) 0.542  джиттер RFC 3550 0.286
   доля очереди и прочих переменных задержек: среднее - min = 0.525 мс

Оценка джиттера по RFC 3550 — экспоненциально сглаженное среднее J ← J + (|dRTT| − J)/16, начинающееся с J = 0. На выборке из 20–50 пакетов фильтр не успевает «разогнаться», поэтому эта оценка систематически занижена по сравнению со средним модулем разности соседних RTT; рассчитана она на длинные потоки RTP.

4. Повторите измерение до удалённого сервера, одновременно создав нагрузку на свой канал доступа: начните загрузку большого файла или видео высокого разрешения. Предскажите, какие из величин (минимум, медиана, p95, джиттер, потери) изменятся сильнее всего. Сравните результат с выборкой без нагрузки.

5. По файлу rtt.csv постройте график RTT от номера запроса для трёх целей (любым средством: Python и matplotlib, табличный процессор).

Что должно получиться

Таблица «цель — предсказание — минимум — медиана — p95 — джиттер — потери» для трёх целей и для измерения под нагрузкой; график RTT. Объяснение: почему минимальный RTT, а не средний, следует использовать для оценки расстояния; какая составляющая задержки выросла под нагрузкой и где, по вашему мнению, образовалась очередь.

Часть 3. Путь пакетов: tracepath и mtr

Задание

1. Проследите путь до удалённого сервера из части 2:

tracepath -n far.example.edu      # адрес — свой

Пример фрагмента вывода:

 1?: [LOCALHOST]                      pmtu 1280
 1:  172.27.48.1                                           0.415ms
 2:  192.168.1.1                                           0.953ms
 3:  10.0.128.65                                           4.663ms
 ...
10:  217.150.37.50                                         3.240ms asymm  9
11:  80.81.194.117                                        48.299ms asymm 12

Каждая строка — номер шага, адрес ответившего маршрутизатора и RTT до него. Пометка asymm N означает, что ответ, судя по оставшемуся времени жизни пакета, вернулся по пути другой длины. Строка no reply — маршрутизатор не ответил, что само по себе не означает неисправности. Механизм работы трассировки разбирается в теме 7; в этой работе инструмент используется как «чёрный ящик».

2. Выполните то же с помощью mtr в режиме отчёта, который отправляет по 50 зондов на каждый шаг и считает статистику:

mtr -n -r -c 50 far.example.edu

В столбцах отчёта: Loss% — потери, Snt — отправлено зондов, Last, Avg, Best, Wrst — последнее, среднее, лучшее и худшее RTT, StDev — стандартное отклонение.

3. Найдите в пути:

   • участок с наибольшим приростом минимального RTT между соседними шагами;
   • шаги, на которых mtr показывает потери, и проверьте, сохраняются ли эти потери на последующих шагах.

4. Определите принадлежность адресов участка с наибольшим приростом задержки. Для этого воспользуйтесь командой whois (пакет whois) или веб-интерфейсом базы своей региональной регистратуры, например https://apps.db.ripe.net/db-web-ui/query. Определите, принадлежит ли какой-либо адрес на пути точке обмена трафиком.

Что должно получиться

Вывод tracepath и отчёт mtr; таблица из 3–5 «ключевых» шагов (номер, адрес, владелец, минимальный RTT). Объяснение: почему потери на промежуточном шаге, не сохраняющиеся на последующих, не являются потерями пользовательского трафика (подсказка: маршрутизатор отвечает на зонды с низким приоритетом и ограничением частоты, а транзитные пакеты пересылает аппаратно).

Часть 4. Задержка распространения и скорость света

Задание

1. Для удалённого сервера из части 2 определите (приблизительно) город его размещения — по данным whois, по имени узла, по сведениям на сайте. Учтите, что крупные сайты обслуживаются из сетей доставки содержимого и могут отвечать из ближайшего к вам города.

2. Рассчитайте нижнюю границу RTT по расстоянию скриптом geo_rtt.py, подставив измеренный минимальный RTT:

python3 geo_rtt.py --list
python3 geo_rtt.py Москва Франкфурт --measured 42
python3 geo_rtt.py 55.75,37.62 40.71,-74.01        # широта,долгота

Москва -> Франкфурт: по дуге большого круга 2 021 км
скорость света в волокне c/n = 204 218 км/с (4.90 мкс/км)
задержка распространения в одну сторону >= 9.9 мс
RTT >= 19.8 мс (для сравнения, в вакууме: 13.5 мс)
измерено 42.0 мс: в 2.12 раза больше нижней границы;
эквивалентная длина трассы туда и обратно ~ 8 577 км

3. Выполните тот же расчёт вручную для одной из целей: расстояние по карте, деление на 204 000 км/с, удвоение. Сравните с выводом скрипта.

4. Повторите расчёт для сервера своего региона. Предскажите, будет ли отношение «измерено / нижняя граница» для него больше или меньше, чем для удалённого сервера, и проверьте.

Что должно получиться

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

Часть 5. Первый захват трафика и первая учебная топология

Задание

1. Захватите на внешнем интерфейсе хоста (из части 1, например eth0) десять эхо-запросов и ответов:

sudo -v
sudo tcpdump -Z root -i eth0 -n -c 20 -w ping.pcap icmp &
ping -c 10 1.1.1.1
sleep 1; sudo pkill -INT tcpdump
tcpdump -n -r ping.pcap | head -4

Ключ -Z root запрещает tcpdump после запуска переключаться на служебного пользователя tcpdump, которому в Ubuntu не разрешена запись в домашний каталог пользователя; -i задаёт интерфейс, -n запрещает преобразовывать адреса в имена, -c 20 останавливает захват после 20 пакетов, -w записывает пакеты в файл формата pcap, последний аргумент icmp — фильтр захвата. Команда sudo -v заранее запрашивает пароль, чтобы его запрос не смешался с выводом фоновой команды, а pkill -INT завершает захват, даже если из-за потерь 20 пакетов так и не набралось. Откройте ping.pcap в Wireshark (wireshark ping.pcap; в WSL2 без WSLg — скопируйте файл в Windows, например в /mnt/c/Users/имя/, и откройте в Wireshark для Windows). Найдите в Wireshark пару «запрос — ответ» и сравните разность их меток времени со значением time=, выведенным ping.

2. Поднимите учебную топологию и изучите её:

sudo ./up.sh
sudo ip netns list
sudo ip -n h1 -br addr
sudo ip -n h1 route

Ключ -n h1 выполняет команду ip в пространстве имён h1; для произвольных команд используется sudo ip netns exec h1 команда. Прочитайте up.sh и для каждой команды запишите, что она делает.

3. Предскажите, какие кадры будут переданы по «кабелю» между h1 и h2 при первом выполнении ping -c 2 и сколько их будет. Затем запустите захват на стороне h2 и выполните ping из h1:

sudo ip netns exec h2 tcpdump -i eth0 -n -e icmp or arp &
sudo ip netns exec h1 ping -c 2 10.0.0.2
sudo kill %1

Ключ -e выводит заголовок канального уровня: MAC-адреса отправителя и получателя и тип содержимого. Ожидаемый вывод:

02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.0.0.2 tell 10.0.0.1, length 28
02:00:00:00:00:02 > 02:00:00:00:00:01, ethertype ARP (0x0806), length 42: Reply 10.0.0.2 is-at 02:00:00:00:00:02, length 28
02:00:00:00:00:01 > 02:00:00:00:00:02, ethertype IPv4 (0x0800), length 98: 10.0.0.1 > 10.0.0.2: ICMP echo request, id 24840, seq 1, length 64
02:00:00:00:00:02 > 02:00:00:00:00:01, ethertype IPv4 (0x0800), length 98: 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 24840, seq 1, length 64
...

Первые два кадра — работа протокола разрешения адресов ARP, который находит MAC-адрес получателя по его IP-адресу (подробно — в теме 7). Без фильтра icmp or arp в захвате видны также служебные пакеты IPv6, которые хосты рассылают при поднятии интерфейса (тема 11). Сравните RTT между пространствами имён с RTT до шлюза из части 2 и объясните разницу.

4. Сломайте и почините. Внесите неисправность первого вида, не читая break.sh:

sudo ./break.sh 1
sudo ip netns exec h1 ping -c 3 10.0.0.2

Пользуясь только командами ip (-br addr, -br link, route, neigh) в обоих пространствах имён и захватом tcpdump на h2, найдите причину. Захват в этом случае показывает только повторяющиеся ARP-запросы без ответа, а ping сообщает Destination Host Unreachable. Восстановите связность командами ip (не перезапуская топологию). Затем выполните sudo ./down.sh && sudo ./up.sh и повторите для неисправности второго вида sudo ./break.sh 2; обратите внимание на флаг NO-CARRIER в выводе ip -n h1 link show eth0.

Что должно получиться

Снимок окна Wireshark с выделенной парой «запрос — ответ»; описание каждой команды up.sh; предсказание и фактический список кадров при первом ping с объяснением; для каждой из двух неисправностей — симптомы, команды диагностики, найденная причина, команда исправления и ответ: на каком «уровне» (физическое соединение, адресация) находилась неисправность.

Часть 6. Продвинутая: разложение RTT на составляющие

Задание

1. Поднимите топологию (если она разобрана) и включите на исходящем направлении h1 → h2 модель канала: задержку распространения 20 мс и скорость передачи 1 Мбит/с:

sudo ./delay.sh on 20 1mbit

qdisc netem 8001: root refcnt 2 limit 1000 delay 20ms rate 1Mbit

Используется дисциплина очереди netem ядра Linux; подробно она изучается в лабораторной работе 3.

2. Предскажите минимальный RTT для ping -s 56 и ping -s 1400 (ключ -s задаёт размер данных ICMP; к нему добавляются 8 байт заголовка ICMP, 20 байт IPv4 и 14 байт Ethernet). Учтите, что модель действует только в одном направлении.

3. Измерьте зависимость минимального RTT от размера пакета скриптом size_sweep.py; он аппроксимирует результаты прямой RTT = a + b · L:

sudo ip netns exec h1 python3 size_sweep.py 10.0.0.2 --count 5

 ping -s  кадр, байт  min RTT, мс
      56          98       20.900
     200         242       22.000
     400         442       23.600
...
    1400        1442       31.600

RTT ~ 20.086 мс + 7.979 мкс/байт * L
оценка скорости узкого звена: R = 8 / b ~ 1.003 Мбит/с
постоянная часть (распространение + обработка): ~ 20.086 мс

4. Объясните смысл коэффициентов: наклон b — время передачи одного байта, a — составляющие, не зависящие от размера. Повторите измерение с параметрами sudo ./delay.sh on 5 10mbit и с sudo ./delay.sh on 50 100kbit; во втором случае уменьшите --sizes до 56 200 400 600, чтобы опыт не длился долго. Сравните оценки a и R с заданными значениями.

5. Модель канала с ограничением скорости имеет очередь. Не выключая её (delay.sh on 20 1mbit), запустите в одном терминале «тяжёлый» поток больших пакетов, а в другом — обычный ping:

sudo ip netns exec h1 ping -s 1400 -i 0.005 -c 2000 -q 10.0.0.2      # терминал 1
sudo ip netns exec h1 ping -c 20 10.0.0.2                             # терминал 2

Предскажите RTT во втором терминале. Поток в первом терминале пытается создать нагрузку 1442 × 8 / 0,005 ≈ 2,3 Мбит/с — больше скорости канала. Опишите, что произошло с задержкой обычного ping. Сравните фактическую длительность первого опыта (поле time в итоговой строке) с ожидаемой 2000 × 0,005 = 10 с и объясните, почему потерь может не быть: очередь netem находится на том же хосте, что и отправитель, и при её заполнении ядро приостанавливает отправку, пока не освободится место в буфере сокета (в опыте автора 2000 пакетов были отправлены за 23 с без потерь, а RTT обычного ping вырос с 21 до 50–59 мс). Отключите модель: sudo ./delay.sh off.

Что должно получиться

Таблицы и прямые для трёх наборов параметров, сравнение оценок с заданными значениями; результат опыта с перегрузкой (RTT обычного ping, длительность и потери «тяжёлого» потока) и его объяснение через загрузку канала ρ и очередь перед узким звеном.

По окончании работы разберите топологию: sudo ./down.sh.

Журнал работы

Ведите для себя журнал: для каждой части записывайте предсказание, сделанное до эксперимента, команду, фактический вывод и объяснение расхождений. Таблицы, графики и файлы захватов, перечисленные в разделах «Что должно получиться», удобно хранить там же. В конце полезно сформулировать несколько предложений собственных выводов по работе.

Контрольные вопросы

1. Чем задержка передачи отличается от задержки распространения? Какая из них уменьшится при замене канала 100 Мбит/с на канал 10 Гбит/с той же длины, а какая — при сокращении расстояния вдвое?
2. Почему минимальный RTT лучше характеризует расстояние до узла, чем средний? В каких случаях минимум тоже может вводить в заблуждение?
3. Измеренный RTT до сервера в соседнем городе составил 25 мс, а нижняя граница по расстоянию — 2 мс. Перечислите возможные причины расхождения.
4. Почему потери, которые mtr показывает на промежуточном шаге, могут не означать потерь пользовательского трафика? По какому признаку в отчёте mtr это можно определить?
5. Почему при первом ping между свежими пространствами имён по каналу прошли кадры ARP, а при втором — нет?
6. Чем отличаются симптомы двух неисправностей части 5 на уровне ip link и на уровне захвата трафика? Почему при одной из них ping сообщает Destination Host Unreachable, а при другой может не выводить ничего?
7. В опыте части 6 RTT растёт с размером пакета линейно. Какая составляющая задержки определяет наклон прямой и почему наклон не зависит от параметра delay?
8. Почему в опыте с перегрузкой в части 6 выросла задержка обычного ping, хотя его пакеты маленькие? Как этот результат связан с графиком зависимости ожидания в очереди от загрузки?
9. Канал 100 Мбит/с, RTT 50 мс. Сколько данных должно находиться «в пути», чтобы загрузить канал полностью? Что произойдёт, если отправитель держит в пути не более 64 КиБ?
10. Чем сетевое пространство имён отличается от виртуальной машины? Что общего у двух пространств имён на одном компьютере, а что у каждого своё?