IPv6 быстрее IPv4? Ровно настолько, насколько хороша дорога вашего оператора

«IPv6 быстрее IPv4» — это написано почти в каждой статье про сети: адресов хватает всем, значит меньше трансляции адресов по дороге, значит маршрут прямее. Мы верили в это настолько, что записали довод комментарием в собственный код и поставили IPv6 первым в очереди подключения. А потом взяли и померили — и получили разные ответы в разных сетях. Там, где дорога по IPv6 проложена хорошо, разницы между протоколами нет вовсе. Там, где её строили позже и по остаточному принципу, IPv6 отстаёт на 72 %. А на мобильной сети он, наоборот, выигрывает. Ниже — сами замеры, таблица различий, найденная причина, красивая гипотеза, которую пришлось выбросить, и понятный ответ, что вам с этим делать.

Короткий ответ

IPv6 ровно настолько быстр, насколько хороша дорога, которую дал ваш оператор. Не «быстрее» и не «медленнее» — по-разному, и разброс между сетями больше, чем разница между самими протоколами. Вот две наши точки, снятые одним и тем же способом до одной и той же цели: по 60 пакетов, оба протокола подряд с одной машины.

Одна и та же пара протоколов, один и тот же способ замера — и совершенно разные ответы. В Амстердаме, где цель стоит фактически рядом, протокол не значит ничего: 0,78 против 0,90 мс — это шум. Из России тот же самый IPv6 едет заметно длиннее. Значит дело не в протоколе, не в размере его заголовка и не в MTU — иначе разница была бы одинаковой в обоих случаях.

И третья точка, которую мы честно помечаем как наблюдение, а не как свой замер. На мобильной сети МТС в Благовещенске IPv6 у нас стабильно выигрывает у IPv4 — по оценке порядка 20 % и больше. Своим прибором мы этого пока не мерили и потому в таблицу не ставим. Но направление важно ровно настолько же: у сотового оператора дорога по IPv6 оказалась лучше, чем по IPv4. Ровно та же причина, что и в первых двух строках, только с обратным знаком.

Отсюда простой вывод, который переживает все три точки: «что быстрее, IPv4 или IPv6» — это вопрос не о протоколах, а о вашем операторе. Общее правило «IPv6 быстрее» неверно; обратное правило «IPv6 медленнее» неверно ровно так же. Проверяется это на своём канале за две минуты — как, написано в конце.

Зачем придумали IPv6, что он решал и что с ним в мире сейчас

IPv6 придумали не ради скорости. Его придумали потому, что в IPv4 кончались адреса, и это была не догадка, а арифметика: под адрес в IPv4 отведено тридцать два бита, то есть всего 4,3 млрд возможных адресов на всю планету. Протокол проектировали в начале восьмидесятых для сети из нескольких сотен организаций — тогда четыре миллиарда выглядели запасом навсегда. Телефона в каждом кармане, часов с интернетом и лампочки с Wi-Fi в этой картине не было.

К началу девяностых стало понятно, что запас кончится, и в IETF взялись за преемника. Первая редакция вышла в декабре 1995 года (RFC 1883), основная — в декабре 1998-го (RFC 2460), а действующий стандарт носит номер RFC 8200 и утверждён в июле 2017 года. Адрес в нём — сто двадцать восемь бит. Насколько это больше, числом не почувствовать, поэтому вот пересчёт: адресов IPv6 хватает примерно на 6,7·10²³ штук на каждый квадратный метр поверхности Земли, включая океаны. Задача «чтобы хватило» решена не с запасом, а навсегда.

Что именно он решал. Ровно одно: вернуть каждому устройству собственный адрес. Всё остальное, что обычно перечисляют, — следствия. Свой адрес значит, что до устройства можно достучаться снаружи: домашний сервер, камера, консоль, звонок или игра напрямую между двумя людьми перестают упираться в посредника. Заголовок пакета заодно сделали проще, а настройку адреса — автоматической, без отдельного сервера.

Чем IPv4 дотянул до сегодняшнего дня. Костылём, которым вы пользуетесь каждый день, не зная об этом, — трансляцией адресов. Сначала домашней (весь дом за одним адресом роутера), потом операторской, CGNAT: один настоящий адрес делится на сотни абонентов. Костыль оказался таким удачным, что отложил переход на четверть века — и он же виноват в половине жалоб «не заходит на мой сервер из интернета».

А адреса всё-таки кончились, и это называется по датам. Мировой запас IANA исчерпан в 2011 году. В нашем регионе — это RIPE NCC, Европа, Россия, Ближний Восток и Средняя Азия — 15 сентября 2012 года выдача перешла на последний блок из 16 млн адресов, а 25 ноября 2019 года свободные адреса кончились совсем. С тех пор новый адрес IPv4 можно только ждать в очереди или покупать у того, у кого он есть: адреса стали товаром с ценой.

Чего IPv6 не решил. Он не совместим с IPv4 сверху вниз: узел, у которого есть только IPv6, не может сам поговорить с узлом, у которого есть только IPv4. Поэтому мир не «перешёл», а живёт на двух протоколах сразу — и будет жить ещё долго. Отсюда же и вся эта статья: раз протокола два, каждое соединение начинается с вопроса, по какому из них идти.

Где IPv6 сейчас. Это уже не будущее и не эксперимент. APNIC постоянно меряет, у какой доли пользователей IPv6 реально работает — не «объявлен провайдером», а проходит живую пробу. Числа на 30 августа 2026 года:

Мировая доля растёт ровно и без рывков: 2,3 % в 2014 году, 16,9 % в 2018-м, 32,4 % в 2022-м, 43,5 % сейчас. Через несколько лет половина интернета будет ходить по IPv6 по умолчанию, и во Франции это уже так.

Российская строка в этой таблице — особая, и мы не будем делать вид, что понимаем её лучше, чем понимаем. Тот же прибор за последние годы давал по России и 9 %, и 2 %: ряд скачет от замера к замеру, чего у мировой кривой нет. Сегодняшнее значение 2,3 %, за последний год он держался между 2 и 4,5 %. Причин мы не знаем и гадать не станем; надёжно можно сказать одно: ни в один из замеров Россия не подходила близко к мировому уровню.

IPv4 и IPv6: таблица различий

Сначала — то, за чем обычно и приходят: чем эти два протокола отличаются на практике. Скорость и отклик стоят отдельными строками — это единственные две строки, которые мы проверяли замером, а не пересказывали.

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

Замер скорости: одна дорога, три пары прогонов подряд

Пинг показывает длину дороги, но людей интересует скорость. Мы прогнали её на той самой дороге, где IPv6 отставал — из России в Европу. Это замер одного конкретного маршрута, а не свойство протокола: на амстердамской точке, где отклик одинаковый, такому разрыву взяться было бы неоткуда.

Что меняли и что держали одинаковым. Один и тот же сервер, один и тот же конфиг, один и тот же туннель, одна и та же скачиваемая полезная нагрузка — 50 МБ одним TCP-соединением. Отличалось ровно одно: по какому протоколу идёт внешняя оболочка туннеля — по IPv4 или по IPv6. MTU туннеля в обоих случаях выдавался одинаковый, 1397 байт. Прогоны шли вперемежку (IPv4, IPv6, IPv4, IPv6…), чтобы разницу нельзя было списать на «канал разогнался к концу».

Главное здесь не среднее, а то, что столбцы не пересекаются: самый медленный прогон по IPv4 (145,0) быстрее самого быстрого прогона по IPv6 (114,4). Когда разброс внутри столбца меньше разницы между столбцами, это уже не шум.

Это второй такой замер, а не единственный. Восемью днями раньше, тем же способом и на том же маршруте, канал был втрое медленнее в абсолютных числах — 63 против 52 Мбит/с. Знак тот же: IPv6 проиграл и тогда, разрыв составлял 17 %. За восемь дней канал ускорился в два с половиной раза, а отставание IPv6 не только не исчезло, но выросло.

Причина: длиннее не протокол, а маршрут

Скорость одиночного TCP-соединения ограничена не только шириной канала, но и задержкой: отправитель может держать «в полёте» лишь окно данных и обязан дождаться подтверждения. Поэтому вдвое больший пинг при прочих равных срезает скорость примерно вдвое. Мы измерили время отклика между своими хостами по обоим протоколам — по десять пакетов, в один день с замером скорости.

Три пары из трёх — IPv6 длиннее. И это те же три пары, что измерялись восемь дней назад: тогда разница составляла +38, +21 и +34 мс. Ни знак, ни порядок величины за неделю не изменились, то есть перед нами устойчивое свойство маршрутов, а не разовое невезение.

Соотношение сходится по порядку величины: отклик по IPv6 больше в 1,65 раза, а скорость меньше в 1,44 раза. Точного совпадения нет, и подгонять его мы не будем — на скорость влияет не только задержка. Но направление и масштаб объясняются задержкой полностью, и никакого другого объяснения искать не потребовалось.

Почему так выходит: сети IPv6 у операторов и дата-центров строились позже и отдельно, соглашения о стыках у них свои. Два адреса на одной и той же железке могут вести к ней совершенно разными путями — и путь IPv6 нередко оказывается тем самым «через Франкфурт», которого у IPv4 давно нет. Это не недостаток протокола, это возраст его карты дорог.

Отдельно про потери — потому что здесь мы сами едва не ошиблись. В этом прогоне из десяти пакетов по IPv6 «потерялось» два: получилось звонкое «20 % потерь». А замер из начала статьи — тот, где пакетов по шестьдесят, — не показал потерь ни одной, ни по IPv4, ни по IPv6. У процента потерь есть минимальная выборка: один пропавший пакет из десяти превращается в громкую цифру, которой на самом деле нет. Приводим это здесь, чтобы вы не поймались на том же, меряя у себя.

Гипотеза «дело в MTU» проверена и отвергнута

Первое, что приходит в голову человеку, знакомому с туннелями: заголовок IPv6 занимает 40 байт против 20 у IPv4, значит полезной нагрузки в пакете меньше, значит и скорость ниже. Гипотеза красивая, проверяется одной командой — и она неверна.

Мы отправили по маршруту пакеты предельного размера с запретом дробить их по дороге (ping -M do): 1452 байта полезной нагрузки по IPv6 и 1472 по IPv4 — это ровно те числа, которые дают полный кадр в 1500 байт с учётом разных заголовков. Прошли оба, в обе стороны. То есть путь держит полный размер, дробления нет ни там ни там, и разница в 20 байт заголовка съедает около полутора процентов кадра — никак не тридцать.

Добавим к этому, что MTU самого туннеля в обоих замерах был одинаковый (1397), то есть клиент нарезал данные на одинаковые куски независимо от транспорта. Дело не в размере пакета, а в длине дороги.

Наша собственная ошибка

Самое неприятное в этой истории — что довод «IPv6 быстрее: меньше NAT, прямее маршрут» мы не вычитали у кого-то, а написали сами: он стоял комментарием в нашем коде и служил обоснованием тому, что IPv6 пробуется первым. Формулировка выглядела как знание. На деле это была догадка, которую никто не проверял — просто она совпадала с тем, что «все знают».

Теперь замер есть, и общего правила он не подтверждает. Важно, чего он при этом не отменил: само решение пробовать IPv6 первым осталось верным. Просто держится оно теперь на другом, проверяемом основании (о нём — ниже), а не на правиле, которого не существует. Хорошее решение с плохим обоснованием — это всё равно плохое обоснование, и чинить надо именно его.

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

Адрес есть — это ещё не путь

Второй практический вывод, который стоит дороже первого. Наличие у устройства глобального адреса IPv6 не означает, что по IPv6 куда-то можно доехать. Адрес выдаёт сеть, а работоспособность пути зависит от всей цепочки дальше — и она рвётся заметно чаще, чем у IPv4.

Мы измерили этот зазор на живых подключениях. За двое суток — 11 попыток пойти по IPv6 с устройств, у которых адрес IPv6 был:

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

Это же объясняет самую частую жалобу на IPv6 — когда система показывает адрес, а связи по нему нет. Ошибка не в вашей настройке: адрес и маршрут выдаются разными механизмами, и первый может работать при сломанном втором.

Почему у нас IPv6 стоит первым

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

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

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

IPv6 в конфиге WireGuard и AmneziaWG

Если вы настраиваете туннель сами, про IPv6 нужно знать три вещи, и все три легко пропустить.

1. Адрес сервера пишется в квадратных скобках. В строке Endpoint двоеточие отделяет порт, а в адресе IPv6 двоеточий полно — поэтому адрес берётся в скобки, и только потом идёт порт:

Endpoint = [2001:db8::1234]:51820

Без скобок строка разбирается неверно, и ошибка при этом бывает совсем не про адрес.

2. Внешний транспорт и то, что внутри туннеля, — разные вещи. Туннель может идти до сервера по IPv6 и при этом переносить внутри исключительно IPv4-трафик, как в замере выше. И наоборот. Не путайте «я подключаюсь по IPv6» и «мои сайты открываются по IPv6» — это две независимые настройки.

3. Без ::/0 в AllowedIPs трафик IPv6 идёт мимо туннеля. Вот это — главная ловушка. Строка AllowedIPs = 0.0.0.0/0 заворачивает в туннель весь IPv4 и ничего из IPv6. Если у вашего провайдера IPv6 есть, сайты с адресом IPv6 будут открываться в обход туннеля, с вашим настоящим адресом. Снаружи всё выглядит подключённым, и проверка «какой у меня IP» может показать адрес сервера — потому что она пришла по IPv4.

Так нужен ли IPv6

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

• Адрес достаётся каждому. Провайдеры давно раздают один внешний адрес IPv4 на сотни абонентов; IPv6 возвращает устройству собственный адрес.
• Входящие соединения работают. Всё, что требует достучаться до устройства снаружи — домашний сервер, камера, игра, работающая напрямую между игроками, — с общим адресом IPv4 упирается в трансляцию, а с IPv6 просто работает.
• Бывают сети, где IPv4 уже не выдают вовсе — тогда вопрос «нужен ли» не стоит.
• А вот «безопаснее» или «анонимнее» IPv6 не бывает. Скорее наоборот: постоянный собственный адрес узнаётся легче, чем адрес, общий на сотню соседей.

Для туннеля к серверу практический вывод такой: держите оба протокола доступными и не назначайте победителя заранее. Мы у себя именно так и поступили — пробуем IPv6 первым и остаёмся на том пути, который ответил, а не на том, который должен быть быстрее по учебнику.

Как проверить у себя

Весь замер из этой статьи повторяется тремя командами — в macOS, Linux и в PowerShell под Windows они почти одинаковы. Возьмите любой сервер, у которого есть адреса обоих видов, и спросите его дважды.

Шаг 1. Сравните время отклика — это главное число, всё остальное следствие:

• По IPv4: ping -c 20 example.com (в Windows — ping -4 -n 20 example.com)
• По IPv6: ping6 -c 20 example.com (в Windows — ping -6 -n 20 example.com)

Смотрите на среднее и на потери. Разница в 20–30 мс — это уже заметный кусок скорости для одиночной загрузки.

Шаг 2. Проверьте, доходит ли полный пакет (запрет дробления плюс предельный размер):

• По IPv4: ping -c 3 -M do -s 1472 example.com
• По IPv6: ping -6 -c 3 -M do -s 1452 example.com

Прошло — путь держит полный кадр, MTU ни при чём. Не прошло — уменьшайте размер, пока не пройдёт, и вы нашли свой предел; что с ним делать дальше, написано в разборе про MTU.

Шаг 3. Померьте скорость через сам туннель, а не мимо него. Это важно: паспортная скорость канала и скорость внутри туннеля — разные числа, и второе зависит от маршрута. Качайте один и тот же файл достаточного размера (десятки мегабайт) сначала при подключении по одному протоколу, потом по другому, и обязательно вперемежку, а не подряд. Почему замеры скорости так часто врут и что именно они меряют, разобрано отдельно: кажется, что VPN медленный.