TCP-исследование
Аргумент в пользу увеличения начального окна перегрузки TCP
Потоки TCP начинаются с начального окна перегрузки, составляющего не более четырех сегментов или примерно 4 КБ данных. Поскольку большинство веб-транзакций кратковременны, начальное окно перегрузки является критическим параметром TCP, определяющим, насколько быстро потоки могут завершиться. Хотя скорость доступа к глобальной сети в среднем резко возросла за последнее десятилетие, стандартное значение начального окна перегрузки TCP осталось неизменным. В этой статье мы предлагаем увеличить начальное окно перегрузки TCP как минимум до десяти сегментов (около 15 КБ). Посредством крупномасштабных интернет-экспериментов мы количественно оцениваем преимущества и издержки использования большего окна в зависимости от пропускной способности сети, времени прохождения туда и обратно (RTT), произведения задержки полосы пропускания (BDP) и характера приложений. Мы показываем, что средняя задержка HTTP-ответов улучшилась примерно на 10 %, причем наибольшие преимущества были продемонстрированы в сетях с высоким RTT и BDP. В наших экспериментах задержка в сетях с низкой пропускной способностью также значительно улучшилась. Средняя скорость повторной передачи увеличилась на скромные 0,5%, при этом большая часть увеличения приходится на приложения, которые эффективно обходят алгоритм медленного запуска TCP, используя несколько одновременных подключений. Основываясь на результатах наших экспериментов, мы считаем, что начальное окно перегрузки должно состоять как минимум из десяти сегментов и должно быть исследовано на предмет стандартизации IETF.
TCP быстрое открытие
В современных веб-сервисах преобладают TCP-потоки, настолько короткие, что они завершаются через несколько циклов передачи данных после установления связи; это рукопожатие является существенным источником задержки для таких потоков. В этой статье мы описываем проектирование, реализацию и развертывание протокола TCP Fast Open, нового механизма, который обеспечивает обмен данными во время первоначального установления связи TCP. При этом TCP Fast Open уменьшает задержку сети приложений на одно полное время прохождения туда и обратно, уменьшая задержку, возникающую при таких коротких передачах TCP. Мы решаем проблемы безопасности, связанные с разрешением обмена данными во время трехстороннего рукопожатия, которые мы смягчаем с помощью токена безопасности, который проверяет владение IP-адресом. Мы подробно описываем другие механизмы резервной защиты и решаем проблемы, с которыми мы столкнулись при использовании промежуточных устройств, обратной совместимости с существующими сетевыми стеками и поэтапного развертывания. На основе анализа трафика и эмуляции сети мы показываем, что TCP Fast Open уменьшит задержку сети HTTP-транзакций на 15 % и время загрузки всей страницы в среднем более чем на 10 %, а в некоторых случаях — до 40 %.
Пропорциональное снижение скорости для TCP
Потери пакетов увеличивают задержку для веб-пользователей. Быстрое восстановление является ключевым механизмом TCP для восстановления после потери пакетов. В этой статье мы исследуем некоторые недостатки стандартного алгоритма, описанного в RFC 3517, и нестандартных алгоритмов, реализованных в Linux. Мы обнаружили, что эти алгоритмы отклоняются от своего предполагаемого поведения в реальном мире из-за совокупного эффекта коротких потоков, зависаний приложений, пакетных потерь, потери и переупорядочения подтверждений (ACK), а также растягивания ACK. Linux страдает от чрезмерного сокращения окна перегрузки, в то время как RFC 3517 передает большие пакеты с высокими потерями, что наносит ущерб остальной части потока и увеличивает задержку в Интернете. Наш основной вклад — это новая конструкция для контроля передачи инфекции при быстром восстановлении, называемая пропорциональным снижением скорости (PRR). PRR восстанавливается после потерь быстро, плавно и точно, распределяя повторные передачи по полученным ACK. В дополнение к PRR мы оцениваем алгоритм ранней повторной передачи TCP (ER), который снижает порог дублирования подтверждения для коротких передач, и показываем, что задержка ранних повторных передач на короткий интервал эффективна для предотвращения ложных повторных передач при наличии небольшой степени переупорядочения. . PRR и ER уменьшают задержку TCP соединений, испытывающих потери, на 3–10 % в зависимости от размера ответа. Основываясь на наших инструментах на веб-серверах Google и YouTube в США и Индии, мы также представляем ключевые статистические данные о характере повторных передач TCP.
Ламинарный TCP
Laminar — это новая платформа для контроля перегрузки TCP, которая отделяет планирование передачи, которое точно определяет время отправки данных, от чистого контроля перегрузки, который определяет общий объем данных, отправляемых во время каждого RTT. Ожидается, что Laminar позволит использовать новые усовершенствованные алгоритмы для более точного регулирования TCP-трафика.
Черновики SSL и TLS
Фальстарт безопасности транспортного уровня (TLS)
Ложный старт — это необязательное поведение реализаций TLS. Это влияет только на синхронизацию протокола, а не на данные, передаваемые по протоколу, и может быть реализовано в одностороннем порядке. Функция TLS False Start приводит к сокращению задержки на один проход туда и обратно для определенных рукопожатий.
Безопасность транспортного уровня (TLS) Следующее расширение согласования протокола
Расширение Transport Layer Security (TLS) для согласования протокола прикладного уровня. Это позволяет прикладному уровню согласовывать, какой протокол должен выполняться через безопасное соединение, таким образом, чтобы избежать дополнительных двусторонних обходов и независимо от протоколов прикладного уровня.
Проект DNS
Подсеть клиента в DNS-запросах
В этом проекте определяется расширение EDNS0 для передачи информации о сети, отправившей DNS-запрос, и сети, для которой может быть кэширован ответ.