Компания Google представила (http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex... планы продвижения сетевого протокола QUIC (https://www.chromium.org/quic/playing-with-quic) (Quick UDP Internet Connections), который уже около двух лет развивается в качестве альтернативы связки TCP+TLS для Web, решающей проблемы с достаточным большим временем установки и согласования соединений и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC уже не только интегрирован в серверную инфраструктуру Google и включён (https://src.chromium.org/viewvc/chrome/trunk/src/net/quic/) в состав Chrome, но и последние три месяца применяется для обслуживания примерно половины всех запросов к серверам Google из браузера Chrome. В дальнейшем планируется перевести QUIC в разряд используемого по умолчанию транспортного протокола для Chrome и мобильных приложений Google. Кроме того, Google собирается начать процесс продвижения QUIC в качестве интернет-стандарта, после проведения модернизации эталонной реализации и формата протокола. Из планов отмечается замена схемы SPDY-поверх-QUIC на HTTP2-поверх-QUIC, сокращение накладных расходов на согласование соединения, улучшение системы упреждающей коррекции ошибок, улучшение методов контроля перегрузки и добавление поддержки multipath-соединений (доставка пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам).
QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования эквивалентные TLS/SSL. Главным преимуществом протокола QUIC, особенно актуальным для мобильных систем, является возможность мгновенно установить соединение и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time). Организация работы поверх UDP, без внедрения нового первичного протокола, позволяет использовать QUIC на существующих системах без необходимости модификации сетевого стека.
Проведённая в реальных условиях оценка производительности, показала, что QUIC обеспечивает реальный прирост производительности, по сравнению с TCP. Например, реализованная в QUIC возможность отправки данных до согласования соединения позволила добиться ускорения в 75% случаев. Даже для таких оптимизированных сайтов как Google Search, в которых применяется техника упреждающей установки соединения, при использовании QUIC время загрузки сократилось на 3%. Для 1% соединений, для которых использованы плохие каналы связи, ускорение составило более секунды. Подобный эффект достигается благодаря отсутствию задержек при потере пакетов - QUIC не использует при повторной передаче пакета тот же номер в последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.
<center><a href="https://lh3.googleusercontent.com/o62Ohn1Ppxna6zz0NtavqRyetj... src="http://www.opennet.ru/opennews/pics_base/0_1429374296.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Основные особенности (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3... QUIC:
- Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
- Почти мгновенная установка соединения (часто 0-RTT, т.е. данные можно передавать сразу после отправки пакета установки соединения), похожая на комбинацию TLS Snapstart (http://tools.ietf.org/html/draft-agl-tls-snapstart-00) и TCP Fast Open (http://en.wikipedia.org/wiki/TCP_Fast_Open);
- Контроль за целостностью потока, предотвращающий потерю пакетов;
- Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета. Криптографические границы блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
- Отсутствие проблем с блокировкой очереди TCP;
- Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
- Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
- Возможность подключения расширенных механизмов контроля перегрузки соединения;
- Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов.
URL: http://blog.chromium.org/2015/04/a-quic-update-on-googles-ex...
Новость: http://www.opennet.ru/opennews/art.shtml?num=42063
