![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Так сложилось, что в интернете лишь два кроссплатформенных протокола транспортного уровня: TCP и UDP. А всё остальное работает уже поверх них. TCP подходит (хоть и имеет врождённые недостатки) для пересылки длинных кусков информации, UDP для пересылки коротких датаграмм. Беда в том, что одному и тому же приложению по-хорошему нужно во время одной и той же сессии пересылать то и другое. Причём, иметь несколько каналов TCP-типа. Причём часть TCP-каналов и все UDP-каналы обычно лучше держать зашифрованными. Но вот беда, шифрование и инициализация сессии для каждого канала требуется отдельно. Чтобы это дело победить, ещё в 8 лет назад придумали протокол транспортного уровня (на самом деле тут склеиваются уровни с 4 по 6, но так и надо, если хочется эффективности) под названием SST (Structured Stream Transport), о котором я уже неоднократно писал: идея там в том, что сперва открывается сессия (опционально с шифрованием сразу или начиная с какого-то момента, когда оно нужно), а потом в её рамках открываются TCP-образные каналы, и можно посылать отдельные датаграммы. Естественно датаграммы быстры, с шифрованием и флагом «с уведомлением о вручении», если он поставлен, то датаграммы будут ресендиться, если долго не приходит ACKа. В общем удобный интерфейс для датаграмм и привычный по TCP интерфейс для, по существу обычные сокеты, только с небольшой дополнительной QoS-конфигурацией и фичами клёвыми.
Но просто так сделать протокол на замену TCP и UDP можно было только когда интернет был во младенчестве. Сейчас шансы произвести модернизацию только у гигантов. И гиганты пытаются. И пугает насколько плохо с этим справляются даже гиганты!
Несколько лет назад Google начал активно разрабатывать протокол QUIC, замену TCP для нужд веба (это менее амбициозная задача, чем SST). Так вот, интернет весь насквозь (начиная с магистральных маршрутизаторов и ядер операционных систем, и заканчивая домашними модемами и внутренностями браузеров) полон виртуозно оптимизированных костылей для обхода врождённых пороков TCP, и эти костыли встают дыбом против всего нового.
По своему дизайну QUIC просто со всех сторон лучше TCP, но победить TCP в боевых условиях одновременно по утилизации канала и скорости загрузки вебстраницы QUICу удаётся далеко не во всём спектре возможных условий, мягко говоря. По-моему, QUIC стабильно и воспроизводимо работает заведомо лучше отработанной сцепки HTTP (с агрессивным мультиплексингом) и TCP пока что менее чем в половине пространства параметров [продолжительность RTT, ширина канала, процент потерь, устойчивость канала].
Я очень надеюсь, что QUIC не только научится побеждать во всех случаях, но и станет когда-нибудь основой самостоятельного транспортного протокола (как гугловский SPDY уже стал основой для HTTP/2), без "over UDP", обретя в процессе стандартизации функционал SST, чтобы TCP и UDP можно было спокойно отправить на пенсию. Но когда мы дождёмся тех светлых времён?.. Ох не скоро.
Но просто так сделать протокол на замену TCP и UDP можно было только когда интернет был во младенчестве. Сейчас шансы произвести модернизацию только у гигантов. И гиганты пытаются. И пугает насколько плохо с этим справляются даже гиганты!
Несколько лет назад Google начал активно разрабатывать протокол QUIC, замену TCP для нужд веба (это менее амбициозная задача, чем SST). Так вот, интернет весь насквозь (начиная с магистральных маршрутизаторов и ядер операционных систем, и заканчивая домашними модемами и внутренностями браузеров) полон виртуозно оптимизированных костылей для обхода врождённых пороков TCP, и эти костыли встают дыбом против всего нового.
По своему дизайну QUIC просто со всех сторон лучше TCP, но победить TCP в боевых условиях одновременно по утилизации канала и скорости загрузки вебстраницы QUICу удаётся далеко не во всём спектре возможных условий, мягко говоря. По-моему, QUIC стабильно и воспроизводимо работает заведомо лучше отработанной сцепки HTTP (с агрессивным мультиплексингом) и TCP пока что менее чем в половине пространства параметров [продолжительность RTT, ширина канала, процент потерь, устойчивость канала].
Я очень надеюсь, что QUIC не только научится побеждать во всех случаях, но и станет когда-нибудь основой самостоятельного транспортного протокола (как гугловский SPDY уже стал основой для HTTP/2), без "over UDP", обретя в процессе стандартизации функционал SST, чтобы TCP и UDP можно было спокойно отправить на пенсию. Но когда мы дождёмся тех светлых времён?.. Ох не скоро.
