Погодин Евгений — ИТ Заметки
🔌Сеть Обновлено 10.11.2026

Сети с нуля 20. Скорость и производительность: полоса, задержка, MTU, фрагментация

Note

Материал сверен с официальной документацией (RFC, реестры IANA, Microsoft Learn и др.; ссылки — в конце статьи). Примеры вывода — иллюстрации: на вашей системе значения и формат могут отличаться. Перед работой на боевом оборудовании проверьте шаги на тестовом стенде.

«Интернет медленный» — самая частая и самая бесполезная жалоба: за ней может стоять перегруженный канал, слабый Wi-Fi, потери пакетов, неправильный размер пакета или медленный сервер. Чтобы найти причину, жалобу нужно превратить в измерение; для этого нужны словарь и инструменты.

В статье мы разберём:

  • чем различаются полоса, скорость передачи, полезная скорость и задержка;
  • почему скорость одного соединения TCP зависит от задержки и окна;
  • что такое MTU и MSS, как работает фрагментация и почему из-за заблокированного ICMP соединения «зависают»;
  • что смотреть в Windows и как SNMP помогает следить за каналами.

Что нужно знать заранее

Величины вместо «медленно»

  • Полоса (bandwidth, пропускная способность канала) — номинальная скорость канала в битах в секунду, как в договоре. Адаптер (LinkSpeed, статья 02) показывает скорость только своего участка, до коммутатора или роутера, а не канала до провайдера.
  • Скорость передачи (throughput) — сколько данных реально проходит за секунду. Она не превышает полосы и зависит от всего пути.
  • Полезная скорость (goodput) — часть throughput, которая является данными приложения. Заголовки пакетов и повторно переданные данные в неё не входят. Эти три названия мы используем для различения; в других источниках определения могут отличаться.
  • Задержку обычно измеряют как круговую, RTT (Round-Trip Time): время, за которое пакет доходит до узла и ответ возвращается. Его показывает time= в ping. Для нас важно, что TCP считает потерю пакета признаком перегрузки и сбавляет скорость, поэтому даже небольшие потери влияют на скорость сильнее, чем кажется.

Не путайте единицы. Скорости каналов измеряют в битах в секунду (Мбит/с, Гбит/с), а скорость копирования Windows показывает в байтах (МБ/с). В байте 8 бит, поэтому гигабитный порт теоретически даёт не больше 125 МБ/с, а на деле меньше: только заголовки IPv4 и TCP (минимум по 20 байт) отнимают 40 из 1500 байт пакета, около 2,7 %. Диск, программа копирования и протокол файлового доступа тоже вносят свой вклад.

Что видит пользователь Куда смотреть в первую очередь
Страницы открываются, но большие файлы идут медленно загрузка канала, окно TCP и RTT, потери
Всё «думает» перед ответом, голос рвётся задержка и потери (статьи 10 и 16)
Подключение есть, но большие передачи зависают MTU и заблокированный ICMP

Это ориентиры, а не диагноз: любой симптом проверяйте измерением.

Задержка, окно и скорость одного соединения

Чем труба шире и длиннее, тем больше воды в ней находится одновременно. Для сети это произведение полосы на задержку (BDP, Bandwidth-Delay Product): объём данных «в пути». Канал 100 Мбит/с с задержкой 20 мс держит в пути 100 000 000 × 0,02 = 2 000 000 бит, то есть 250 000 байт. Чтобы заполнить канал, отправитель должен иметь право послать столько данных, не дожидаясь подтверждений.

Это право ограничено: объём неподтверждённых данных не больше меньшего из двух окон, окна получателя (rwnd) и окна перегрузки отправителя (cwnd). Окно получателя записывается в 16-битное поле заголовка TCP, поэтому без расширений оно не больше 64 КиБ. Опция «Window Scale» позволяет окну вырасти до 1 ГиБ; её отправляют только в SYN-пакетах, то есть масштаб согласуется при установлении соединения. Ограничение видно из простой оценки: скорость одного соединения не выше окна, делённого на RTT.

RTT Предел одного соединения при окне 65 535 байт
1 мс около 524 Мбит/с
20 мс около 26 Мбит/с
100 мс около 5,2 Мбит/с

Расчёт: 65 535 × 8 = 524 280 бит, делим на RTT. Вывод: при RTT порядка миллисекунды окно ещё не мешает каналу в сотни Мбит/с, а при RTT в десятки миллисекунд без масштабирования одно соединение не заполнит даже канал 100 Мбит/с. Масштаб выбирается по максимальному размеру буфера приёма (по умолчанию его задаёт система, программа может изменить), отдельная настройка масштаба не нужна. В Windows за размер окна приёма отвечает автонастройка, её уровень показывает netsh int tcp show global. У Microsoft разобран случай медленной передачи по каналу с большой задержкой: причиной был не включённый Window Scale, а исправлением — вернуть автонастройку на уровень Normal. Поэтому не отключайте автонастройку по советам «оптимизаторов» (практика автора). Что стороны согласовали масштаб, видно в Wireshark: в SYN-пакете ищите параметр Window scale.

Второе окно, cwnd, растёт постепенно: новое соединение начинает с небольшого объёма данных (медленный старт), увеличивает его, пока нет потерь, а при потере сокращает. Поэтому короткие передачи, как правило, не успевают разогнаться, и для них важнее RTT, а не полоса (практика автора). На каналах с большим произведением полосы на задержку потери, по RFC 7323, могут сказаться на скорости катастрофически. Повторные передачи в Wireshark (только в своей сети и с разрешения её владельца, см. статью 11) показывает фильтр отображения tcp.analysis.retransmission.

MTU, MSS и фрагментация

MTU (Maximum Transmission Unit) — наибольший пакет IP, который канал передаёт целиком. Для Ethernet это 1500 байт. MSS (Maximum Segment Size) — наибольший объём данных TCP в одном сегменте. Стороны сообщают своё значение в SYN-пакете (опция MSS), и оно должно быть равно MTU за вычетом заголовков IP и TCP.

 |<---------------- MTU = 1500 байт ---------------->|
 +------------+------------+-------------------------+
 | IP: 20 Б   | TCP: 20 Б  | данные: до 1460 Б = MSS |
 +------------+------------+-------------------------+

Для IPv4 это 1500 − 20 − 20 = 1460, для IPv6 (заголовок 40 байт) — 1440. Если MSS в SYN не передан, TCP предполагает осторожные 536 байт (576 − 40) для IPv4 или 1220 (1280 − 60) для IPv6, и скорость заметно хуже.

Что делает маршрутизатор с большим пакетом

Путь состоит из многих каналов, и MTU в них может быть разным. Если пакет IPv4 больше MTU следующего канала, всё решает флаг DF (Don't Fragment) в заголовке:

  • DF = 0. Маршрутизатор разрезает пакет на фрагменты (общее поле Identification, флаг MF у всех, кроме последнего, смещение в единицах по 8 байт). Собирает пакет получатель; если потерян хотя бы один фрагмент, пакет не собрать, а лишние заголовки и сборка отнимают ресурсы.
  • DF = 1. Маршрутизатор пакет отбрасывает и возвращает отправителю сообщение ICMP «Destination Unreachable» (тип 3) с кодом 4, «нужна фрагментация, но DF установлен». В нём указан MTU следующего канала. Отправитель уменьшает размер пакетов.

Это и есть обнаружение MTU пути (PMTUD, Path MTU Discovery): отправитель ставит DF и ориентируется на сообщения ICMP. TCP-реализации с PMTUD работают именно так.

В IPv6 иначе: маршрутизаторы пакеты не фрагментируют, это может сделать только источник. Любой канал должен иметь MTU не меньше 1280 байт. Слишком большой пакет маршрутизатор отбрасывает и отвечает сообщением ICMPv6 Packet Too Big с MTU следующего канала, а отправитель подстраивается. Об адресах и работе IPv6 — в статье Сети с нуля 14. IPv6 для начинающих.

«Чёрная дыра» MTU

Обнаружение MTU работает, только пока сообщения ICMP доходят до отправителя. Если какой-то фильтр на пути их отбрасывает, возникает «чёрная дыра». RFC 8201 описывает её для IPv6 как соединения, которые завершают трёхстороннее рукопожатие TCP, а затем зависают при передаче данных; в IPv4 PMTUD так же зависит от ICMP, и последствия те же. Рукопожатие и короткие запросы проходят, большие пакеты исчезают молча. Типичная жалоба: «ping идёт, сайт открывается не до конца, соединение устанавливается и замирает» (практика автора).

MTU пути меньше 1500 там, где пакеты упаковываются в другие: в туннелях и VPN. Каждый дополнительный заголовок отнимает место у данных. Подробности о VPN — в статье 15.

От результата ping к MTU и MSS

Как искать MTU пути командой ping -f -l (только для IPv4), разобрано в статье 10: для MTU 1500 максимальный размер данных 1472, плюс 28 байт заголовков. Новое здесь — связать результат с настройками. Допустим, туннель добавляет 60 байт: пакет внутри него не больше 1440 байт, ping -f -l 1412 проходит, а 1413 нет. Значит, MTU туннеля 1440, а MSS внутри него должен быть 1400 (1440 − 40). Такую разницу видно сразу, если сравнить результаты при включённом VPN и без него.

Две оговорки: отсутствие ответа не доказывает проблему MTU, потому что ICMP мог быть заблокирован; а MTU адаптера (поле MtuSize в Get-NetAdapter, статья 02) относится только к первому каналу пути.

Что делать

Сначала убедитесь, что ICMP не блокируется целиком: нужные для PMTUD типы (в IPv4 «нужна фрагментация», в IPv6 Packet Too Big) должны проходить. Затем поправьте MTU на самом туннеле или шлюзе. Для TCP многие шлюзы умеют ещё уменьшать MSS в проходящих SYN-пакетах (в документации ищите «MSS clamping»). RFC 4459 называет это обходным приёмом, работающим только для TCP: для UDP и других протоколов без MSS он не помогает, так что MTU туннеля всё равно нужно настраивать правильно. Туннели разобраны в статьях Cisco с нуля 17. GRE-туннели и MikroTik с нуля 11. WireGuard: доступ в офис и туннель между офисами. Менять MTU на рабочих компьютерах — крайняя мера: сначала на одном тестовом узле, с готовым откатом. Уменьшать его «для скорости» на всех ПК не нужно: чем меньше MTU, тем больше заголовков на те же данные.

Что смотреть в Windows

Командлет Get-NetAdapterStatistics показывает байты, пакеты, отброшенные пакеты и ошибки адаптера; для всех полей добавьте Format-List:

Get-NetAdapterStatistics -Name "Ethernet" | Format-List -Property *

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

Name                     : Ethernet
ReceivedBytes            : 48210334711
ReceivedDiscardedPackets : 0
ReceivedPacketErrors     : 214
SentBytes                : 9120114532
OutboundDiscardedPackets : 0
OutboundPacketErrors     : 0

ReceivedPacketErrors — входящие пакеты, отброшенные из-за ошибок; ReceivedDiscardedPackets — отброшенные без ошибок; для исходящих поля называются Outbound…. Сравните два замера с интервалом в несколько минут и смотрите, растут ли числа. Рост ошибок может указывать на кабель, порт, несовпадение дуплекса (статья 02) или драйвер.

Загрузку канала показывает Performance Monitor. Нужны счётчики Network Interface(*): Bytes Received/sec и Bytes Sent/sec (в байтах: умножьте на 8 и сравните со скоростью линка), Packets Received Errors, Packets Outbound Discarded и из наборов TCPv4 и TCPv6 счётчик Segments Retransmitted/sec. Названия счётчиков зависят от языка системы (в русской Windows они могут быть переведены); точные имена смотрите в Performance Monitor на своём компьютере.

Счётчик Output Queue Length для оценки перегрузки малоинформативен: страница Microsoft одновременно пишет, что значение больше 2 означает задержки, и что из-за очереди, которую ведёт NDIS (Network Driver Interface Specification), оно должно быть всегда равно 0. Ориентируйтесь на загрузку, ошибки и сброшенные пакеты (практика автора).

Задержку и потери по маршруту показывают ping -t и pathping (статья 10). Для Wi-Fi проверьте сигнал и канал (статья 12): скорость в выводе адаптера — согласованная скорость радиосоединения, а не скорость интернета. Для голоса и видео смотрите QoS (статья 16).

Практика: MTU, MSS и окно на своём компьютере

Шаги только читают информацию и ничего не меняют.

  1. MTU пути с VPN и без. Найдите MTU пути до внешнего узла (например, 198.51.100.10) по статье 10 и повторите при включённом VPN: разница показывает, сколько места занимает туннель.
  2. SYN в Wireshark. Запустите захват и выполните curl.exe -s -o NUL http://www.example.com (как в статье 11). Фильтр tcp.flags.syn == 1 оставит первые пакеты рукопожатия. Откройте SYN-пакет вашего компьютера и найдите в параметрах TCP значения Maximum segment size и Window scale. При MTU 1500 в IPv4 MSS обычно равен 1460.

Результаты сохраните: при следующей жалобе у вас будет «эталон» для сравнения.

Мониторинг и SNMP

Заметить проблему до звонка пользователя помогает мониторинг: система сама опрашивает маршрутизаторы и коммутаторы и рисует графики загрузки и ошибок. Для этого используется SNMP (Simple Network Management Protocol): на устройстве работает агент, система мониторинга выступает менеджером, а данные (счётчики интерфейсов, состояние) описаны в MIB (Management Information Base). Запросы идут на UDP-порт 161, уведомления (traps) — на UDP-порт 162.

Версии отличаются безопасностью. В SNMPv1 и SNMPv2c единственная «защита» — строка community, которая передаётся открытым текстом; RFC 3410 называет такую аутентификацию фундаментально небезопасной и относит обе версии к историческим. SNMPv3 добавляет криптографическую аутентификацию, шифрование и разграничение доступа, но защищает только при включённых аутентификации и шифровании: без них он примерно равен v1 и v2c. Поэтому по возможности используйте SNMPv3 с аутентификацией и шифрованием. Если устройство умеет только v2c, задайте собственное значение community вместо стандартного, оставьте доступ только на чтение, разрешите опрос только с адреса сервера мониторинга и не открывайте UDP 161 в интернет (практика автора). Настройка — в статьях Zabbix с нуля: установка, первые узлы и уведомления, Cisco с нуля 21. Мониторинг: SNMPv3, syslog, NTP, IP SLA и MikroTik с нуля 08. Диагностика и мониторинг.

Порядок поиска узкого места

Общая последовательность «снизу вверх» описана в статье 10. Эта статья добавляет к ней четыре шага:

  1. Посмотрите загрузку канала и ошибки адаптера. Если загрузка у предела, вопрос в полосе и очередях (QoS), а не в поломке.
  2. Для одного соединения на длинном канале сравните скорость с оценкой «окно / RTT».
  3. Проверьте размер пакета, особенно если в пути VPN или туннель.
  4. Настройте мониторинг, чтобы в следующий раз видеть графики загрузки и ошибок интерфейсов до жалобы.

Если сеть чиста, причина, вероятно, в сервере, диске или программе: Поддержка пользователей 04. «Компьютер тормозит».

Состояние на ноябрь 2026 года (проверьте актуальность). Описание TCP обновлено в RFC 9293 (2022 г.): он заменил, в том числе, RFC 793, 879 и 6691; PMTUD для IPv6 описан в RFC 8201 (он заменил RFC 1981). Значения начального окна и алгоритмы управления перегрузкой зависят от версии ОС и устройства. Страница Microsoft о сетевых счётчиках последний раз обновлялась 01.11.2024, страница о проблемах производительности TCP/IP — 12.02.2026: названия счётчиков и уровни автонастройки проверяйте на своей версии Windows. RFC 3410 датирован 2002 годом; поддержку SNMPv3 уточняйте в документации конкретного устройства.

Типичные ошибки и недоразумения

  • «Купили гигабит, файл должен копироваться на 125 МБ/с». Это потолок канала, а мегабиты не равны мегабайтам: 100 Мбит/с — это 12,5 МБ/с. Реальная скорость зависит ещё от заголовков, диска, протокола и окна TCP.
  • «Тест скорости в норме, значит, сеть ни при чём». Тест измеряет путь до своего сервера; до вашего сервера путь и задержка другие (практика автора).
  • «Ping в норме, значит, с каналом всё хорошо». По умолчанию ping отправляет 32 байта: он не покажет проблемы с MTU и потери под нагрузкой.
  • «Заблокирую весь ICMP ради безопасности». Без сообщений о слишком большом пакете PMTUD не работает, соединения зависают. Фильтруйте избирательно.
  • «Отключу автонастройку TCP, станет быстрее». Можно ограничить окно и потерять скорость на длинных каналах.
  • «В SNMP v2c community — это пароль, он надёжен». Он передаётся открытым текстом; для защиты нужен SNMPv3 и ограничение доступа по адресам.

Проверьте себя

  1. Чем MTU отличается от MSS и чему равен MSS при MTU 1500 в IPv4? MTU — наибольший пакет IP на канале, MSS — наибольший объём данных TCP в сегменте. Для IPv4 MSS = 1500 − 20 − 20 = 1460.
  2. ping -f -l 1472 проходит, а -l 1473 нет. Что это значит? Пакет размером 1472 + 28 = 1500 байт проходит, а в 1501 байт не помещается: MTU пути равен 1500 (при условии, что ICMP не блокируется).
  3. Почему при RTT 100 мс одно соединение TCP без масштабирования окна не превысит примерно 5 Мбит/с? Окно не больше 65 535 байт: 524 280 бит за 0,1 с — около 5,2 Мбит/с, как бы широк ни был канал.
  4. Что такое «чёрная дыра» MTU и как она проявляется? Это ситуация, когда ICMP с требованием уменьшить пакет не доходит до отправителя: рукопожатие TCP проходит, а большие передачи зависают.
  5. Когда SNMPv3 лучше SNMPv2c? Когда включены аутентификация и шифрование: в v2c только строка community открытым текстом; без аутентификации и шифрования v3 примерно равен v2c.

Что дальше

Источники

Ещё по теме «Сеть»

Сети с нуля 01. Что такое сеть: устройства, модель TCP/IP и OSI Сети с нуля 02. Ethernet, MAC-адреса, коммутатор и кабели Сети с нуля 03. IPv4-адреса и маски подсети Сети с нуля 04. Подсети и CIDR: считаем без калькулятора Сети с нуля 05. Как пакет находит путь: шлюз, маршруты и ARP Сети с нуля 06. DHCP: как устройство получает адрес