Комментарии 75
увеличение пользовательской активности на 1% оценено на десятках миллионов DAU по системе А/Б тестирования, основанной на матстатистике
которая говорит что с вероятностью 99.98% именно изменение протокола приводит как минимум к 1% роста активности )
но мы продолжаем работы над протоколом и эксперименты
Ну, если вы делаете универсальный транспорт с гарантированной доставкой, то вы в тех же условиях, как и те, кто совершенствует TCP.
А значит, драматически отличных результатов ожидать не стоит.
Но если это user space stack, можно было бы использовать дополнительную информацию, которая у вас есть в приложении – о данных, о сессиях?
TCP этого знать не может.
и это не универсальный транспорт, это транспорт доставки сообщений длинной до 1Мб в беспроводных сетях
Представил себе миллиарды маршрутизаторов по всему миру в которые залетает свежий апдейт с поддержкой новейших фич TCP прямо в день их выхода.
или сказать что есть стрим, где пакеты теряют свой смысл после задержки более 1 сек, для конференц связи или live трансляций например
для медиастриминга мы используем друго свое решение habr.com/ru/company/oleg-bunin/blog/413479
Потому как благое начинание сделать эффективный протокол мешает жить другим и тупо ломает сеть.
Google сначала они придумали BBR (congestion control в TCP), который в случае конкуренции за канал с другими congestion control-ами их выжимает
никто не знает, какой CC у google сейчас на серверах как для TCP так и для QUIC/UDP
но уверен что самый агрессивный из доступных
Ну то есть очевидно в каких-то условиях BBR имеет влияние, но оценить его крайне сложно.
В TCP только версий RFC уже две: RFC 761 и 793, не говоря про расширение RFC 1323.
А у UDP как был RFC 768, так он и остался.
Статья для сильных духом!
На самом деле любой packet loss — следствие того, что сеть перегружена
Тут, наверное, пропущена частица "не": На самом деле не любой packet loss...
Также можно зайти в сеть в браузере и тоже увидеть, что там есть GQUIC.
Интересно, что у меня в Хроме (76 версия) нет колонки Protocol, вместо нее Type. Не нашел, как включить.
Если вы будете писать свой протокол, вам нужен чек лист:
…
Если у вас нет ресурсов, готовьте свою инфраструктуру под QUIC. Он рано или поздно к вам придет.
На мой взгляд, в этих местах грех не упомянуть про Aeron, который, во многом — обобщенный фреймворк поверх UDP (с решением многих проблем, перечисленных в этом докладе) для простых смертных.
wireshark точно поможет найти quic пакеты )
например у нас есть FEC )
Aeron подойдет для высокоскоростных магистралей и сетей уровня ДЦ
но challenge accepted — сделаю тесты
По заголовку колонок щёлкаете, там можно выбрать дополнительные. У меня тоже отключено было по умолчанию. После включения, кстати, QUIC нигде не нашёл, только h2 (HTTP/2.0, видимо).
— нет IP-migration
— 4-way handshake вместо 0-RTT
— на старте соединение нужно указать кол-во потоков
— не решает проблему head-of-line-blocking для стримов
tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00
А чуть более развёрнуто можно?
— нет IP-migration
Непонятно, что alatobol имел в виду под миграцией, то ли смену адресов на ходу, то ли миграцию а-ля IPv4 -> IPv6, но в SCTP позаботились об обеих проблемах, потому два:
RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
— на старте соединение нужно указать кол-во потоков
RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
Про 4-way надо отдельно пояснить, оно типа «вроде бы правда» — на самом деле, нет, это защита от SYN flood (то, что в TCP с ограниченным успехом делают syn cookies). И такое требование, защиты от пира, которого вы еще не знаете, будет неизбежно для любого протокола. В том числи и для QUIC (и даже особенно для QUIC ввиду легкости спуфинга UDP). Зато в SCTP передача данных идет штатно уже на третьем пакете — то, что из TCP когда-то выкидывали, а сейчас пытаются возродить в виде TFO.
То есть, почувствуйте разницу и тонкость манипуляции: 4-way handshake в первый раз vs 0-RTT потом (и то вовсе не при любых условиях).
Но самое наглое вранье, конечно, про head-of-line-blocking — SCTP именно в том числе для того создавался, чтоб потеря пакета в одном потоке не тормозила остальные.
В целом, что касается современных драфтов IETF — мне попадался уже один, предлагавший API BSD-сокетов заменить, где автор плавал в теме. Так что качеству драфта от Гугла, тем более преследующего цель показать свой продукт в выгодном свете, я уже не удивляюсь.
Вот взять хотя бы один из ключевых вопросов архитектуры: мы, типа, решили в QUIC оставить семантику потока байт. А где обоснование, НАХЕРА?.. Большое количество протоколов поверх TCP вынуждено изобретать свой фрейминг, например. Что, говорите, так в HTTP было?.. Тогда тут же возникают уже 2 вопроса:
— если у вас частное решение для HTTP, тогда сравнение с общим протоколом имеет мало смысла
— если вы всё равно новую версию протокола делаете, не пора ли отойти от втискивания всего во всё тот же старый концепт безразмерного потока байт?..
И т.д.
А где обоснование, НАХЕРА?
У меня после многочисленного количества переизобретений протоколов поверх TCP разного назначения появилось стойкое ощущение, что потоковые протоколы бесполезны. Даже если ты передаешь реально какой-то поток (кроме файлов есть что-то еще?), то все равно он передается блочно и любой фреймовый протокол отлично подойдет для этого. Потоковый же протокол только постоянно требует изобретать фрейминг. Вот правильно в websocket сделали.
реально какой-то поток (кроме файлов есть что-то еще?),
Нуу… подумал и придумал рафинированный пример: несжатый 8-битный PCM audio :)
Нуу… подумал и придумал рафинированный пример: несжатый 8-битный PCM audio :)
Ну да, натянуть такое можно. Просто в реале даже аудио пишется фреймами, которые в зависимости от кодека самый разный размер могут иметь. Плюс API обычно эти фреймы пачками выдают так или иначе.
про head-of-line-blocking
Я так понял, alatobol про то, что если в каком-то одном стриме потеряется SSN, то на принимающей стороне отправка «наверх» по данному стриму приостановится, пока этот SSN не дойдет.
Не уверен, но вроде тоже был какой-то драфт про «сброс» стрима, т.е. забыть, что что-то потерялось и продолжать, как будто бы чанк с этим SSN дошел.
Я так понял, alatobol про то, что если в каком-то одном стриме потеряется SSN, то на принимающей стороне отправка «наверх» по данному стриму приостановится, пока этот SSN не дойдет.
Ну так внутри потока эта проблема будет для любого протокола, который ориентирован на собственно поток — ведь верхний уровень «дырку» не поймёт. Но не заблокируются соседние потоки, в отличие от мультиплексирования всех потоков в одном TCP-соединении.
Если протокол приложения таков, что это действительно составляет проблемы, тогда надо:
- Уменьшать размер фрейма, до «меньше типичного MTU»
- Использовать Unordered-фреймы (в SCTP есть), им пофиг
Не уверен, но вроде тоже был какой-то драфт про «сброс» стрима, т.е. забыть, что что-то потерялось и продолжать, как будто бы чанк с этим SSN дошел.
Сброс стримов тоже был (уже RFC 6525, не драфт), но Вы, судя по всему, о Partial Reliability, т.е. разрешать потерю некоторых пакетов (для гейминга, скажем) — да, такое в SCTP тоже есть (RFC 3758).
но Вы, судя по всему, о Partial Reliability
Вроде бы и да, а вроде бы и нет, надо вчитываться в RFC :-)
Слегка пробежался и вроде бы в Partial Reliability вперед пропихивается cumulative TSN, а значит это может повлиять на несколько стримов, т.е. если у нас есть стримы, по которым мы осуществляем надежную доставку и стримы, где допускается дроп чанков, то подвинуть cumulative TSN мы сможем не всегда. Например, не cможем, пока в стримах с надежной доставкой есть гапы.
Мне эта фича видится немного по другому: двигать не cumulative TSN, а SSN и с SSN, если надо, то и cumulative TSN (хотя, наверное для некоторых протоколов подойдет unordered delivery, это надо каждый случай/протокол разбирать, анализировать...).
А драйвер SCTP для Windows уже перестал ломать возможность отправки HTTP-запросов у приложений на .NET Framework?
Спасибо за отличную статью.
Описанная выгода от использования нескольких параллельных TCP совпадает и с личным опытом.
На Android 9 я видел TFO на эмуляторе
Похоже, на железе тоже уже есть. Или это Termux отсебятину показывает?
Packet pacing, TCP, disabled by TSO
Не раз сталкивался, что TSO (скорее всего из-за багов в реализации) приводит к нестабильности TCP соединений. И её отключение увеличивает как стабильность, так и скорость.
Возможно, кому-то пригодится заметка как packet pacing можно использовать с TCP на Linux в т.ч. в сочетании с параллельными соединениями.
спасибо за TCP pacing!, на досуге попробую сделать эксперимент на пользователях )
habr.com/ru/company/oleg-bunin/blog/413479
а по нашему UDP протоколу мы гоняем и API json-ы и картинки
Large send offload, в статье и комментариях упоминается как "TSO".
За статью спасибо, я ей буду пугать разработчиков если они начнут жаловаться что им тяжело
Позанудствую.
BitTorrent перешёл на UDP с delay based congestion control где-то в 2010. До четверти траффика в интернете так ходило.
И всё это при том, что не просто «надо придумать новый протокол», как думают авторы пунктов опроса, а давно уже есть SCTP, который вот это всё умеет — и несколько «соединений» внутри одной ассоциации, и разные наборы IP-адресов/multipath, и много чего еще. А главное — не просто реализован в ядрах FreeBSD и Linux, но есть и юзерспейсные драйвера, и даже режим «поверх UDP» для решения проблемы «файрволы не знают новый протокол».
ну т.е. это про то, что google не много думает об остальной сети в целом и ваших приложениях в частности
особенно хороша история с BBR vs Cubic: в ней последний страдает при congestion-е
А про Cubic — так это не противоречит моим словам, скорее наоборот.
Предположу, что частное решение всегда будет эффективнее универсального.
Ну и внедрение SCTP можно сравнивать с IPv6.
Почему автор называет транспортные протоколы сетевыми? Тот самый момент, когда программист пишет о будущем сетей со своей колокольни...
мы для стриминга видео по TCP мы используем BBR (для сетей с потерями он больше подходит чем Cubic)
Для сборки нужен tcp_vegas.h от установленной версии ядра. Модуль имеет несколько параметров которые можно менять на ходу. Минимальное окно меняется от min_cwnd (при min_rtt) до max_min_cwnd (при max_rtt) линейно в зависимости от rtt (round trip time).
В начале своей карьеры писал как раз надежный протокол поверх UDP для аналога Скайпа, которого тогда не было. Идея была в том, что гарантировалась знание о состоянии канала на обеих его сторонах и возможность управлять передачей (напр., запрашивать недоставленные пакеты).
Но в конце-концов не пошло именно из-за сетей за HTTP-прокси.
TCP против UDP или будущее сетевых протоколов