Какой интересный велосипед!Интересная идея использовать TLS Snap Start для уменьшения RTT.
Что такое TLS Snap Start:
http://blog.cryptographyengineering.com/2011/12/whats-tls-sn...
Но если он не поддерживается сервером, скатываемся к обычному TLS handshake.
А вообще они наступают на старые грабли под названием "А давайте использовать UDP для гарантированной доставки. Он ведь такой быстрый!".
Все равно нужно будет реализовать механизмы:
- различать между собой первый и пятый пакет;
- различать между собой пакеты от разных источников;
- защиту от повторяющихся пакетов;
- индикатор потери пакета;
- переотправку потерянных пакетов;
- фрагментацию/дефрагментацию пакета;
- контрольную сумму пакета;
- контроль перегрузки канала;
- задержку при отправке пакетов (против перегрузки канала, или при большой патере пакетов);
- и т.д.
Т.е. есть ситуация "это UDP, детка, здесь могут послать в /dev/null".
Для её решения, по сути, нужно переизобрети "TCP поверх UDP".
И получить эдакий "userspace TCP".
Ну, знаете, как есть файловые системы в userspace, через FUSE.
Так теперь появится TCP в userspace через google :)
Я не сомневаюсь в гениальности разработчиков Google, но кроме первой реализации, нужна стадия "отлов багов в реальных условиях".
А вот она может затянуться на годы.
И если им нужен инструмент, который "сразу работает", решение "переизобрести TCP" выглядит странным.
Тем более, что у них под носом есть пример такого переизобретения TCP - NFS.
Сначала в NFS тоже решили использовать UDP.
В 4 версии все равно внедрили поддержку TCP.
Хотя у UDP есть плюс - оборвать соединение по UDP проще - нет всяких таймаутов в ядре, которые есть в TCP.
Но это обрыв соединения, а не установка.
С установкой и поддержанием плюсов я не заметил.
Одни минусы - "самодельный TCP" и для UDP не так хорошо вылизан NAT.
Вообще, если так не нравится handshake и не хочется тратить на него время, можно просто держать открытым соединение с HTTP сервером.
Конечно, может понадобиться доработать клиент, чтобы он все время держал соединение.
Но я уверен - понадобится меньше доработок, чем для _этого_ (внедрения поддержки UDP на клиентах, серверах, проксях, и т.д.).
Поэтому пока "Какой интересный велосипед!".
Ну и интересно, как это будет развиваться.
