Сделаем TCP быстрее

Автор оригинала: Yuchung Cheng
  • Перевод
Компания Google опубликовала ряд рекомендаций, как уменьшить задержку (latency) для TCP-соединений между веб-сервером и браузером. В этих рекомендациях обобщаются исследования, которые компания вела в течение нескольких лет.

1. Увеличьте первоначальный размер congestion window до 10 (IW10). Сейчас в начале TCP-соединения отправляется три пакета данных в три раунда (RTT) для передачи небольшой информации (15 КБ). Наши эксперименты показывают, что IW10 уменьшает сетевую задержку для веб-соединений более чем на 10%.

2. Уменьшите первоначальный таймаут с 3 секунд до 1 секунды. RTT в 3 секунды был приемлем пару десятилетий назад, но в современном интернете нужен гораздо меньший таймаут. Наше обоснование для этого хорошо задокументировано здесь.

3. Используйте TCP Fast Open (TFO). Для 33% HTTP-запросов браузеру сначала нужно потратить один RTT на установление TCP-соединения с удалённым пиром. Большинство HTTP-ответов умещаются в первое окно насыщения (congestion window) из десяти пакетов, удваивая время отклика. TFO устраняет эту избыточность, включив HTTP-запрос в первый пакет TCP SYN. Мы показывали, что TFO уменьшает время загрузки страницы в среднем на 10%, а во многих ситуациях — более чем на 40%. Есть научное исследование, а также мы подготовили драфт стандарта, которые нацелены на разрешение таких проблем, как потеря пакетов и DDoS-атаки при использовании TFO.

4. Используйте механизм PRR (Proportional Rate Reduction) для TCP. Потери пакетов указывают на нарушение или перегрузку в сети. PRR — новый алгоритм для восстановления потерь, который равномерно распределяет повторно передаваемые пакеты и восстанавливает потери, возникшие из-за перегрузки сети. Этот алгоритм быстрее, чем используемый сейчас механизм RFC 3517, поскольку способен изменять частоту передачи пакетов в зависимости от уровня потерь. Алгоритм PRR уже включён в ядро Linux и сейчас оформляется как часть стандарта TCP.

Кроме того, мы разрабатываем алгоритмы для более быстрого восстановления соединения в перегруженных сетях сотовой связи и для гарантированной доставки 2-RTT в процессе загрузки. Вся наша работа над TCP является open-source и публично доступной. Мы распространяем наши инновации через ядро Linux, предложения стандартов IETF и научные публикации. Наша цель — вместе с представителями индустрии и научными организациями усовершенствовать TCP для всего интернета.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 32

  • НЛО прилетело и опубликовало эту надпись здесь
      +5
      К сожалению, не все так радужно.
      В наших тестах UDT оказывался в среднем медленнее TCP на канале 1 Гбит/с, RTT~5-6мс. Плюс UDT демонстрировал более медленный разгон, по этому для коротких по времени сессий он может значительно проигрывать TCP. А для полной утилизации этого канала в разных условиях требовалось всего от 2 до 5 параллельных TCP-сессий.

      Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.
      • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          Да, именно такое поведение мы и наблюдали, но глубоко в теорию вопроса и формулы пока не копали.
          Но затея по написанию своего CCC, когда штатный TCP может давать неплохие результаты мне кажется странной, как и идея мультиплексирования нескольких TCP-сессий в одну UDT(это спорная часть моего мнения).

          Сессии у нас измеряются десятками гигабайт переданных данных, но нам, в текущей архитектуре, желательно поддерживать пул соединений, из которых в каждый момент времени активны будут порядка 1-10%, а TCP похоже с этим справляется получше.

          P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.
        • НЛО прилетело и опубликовало эту надпись здесь
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
            0
            А почему таймаут в 1с приемлем? Я как-то был в больнице с одной бесплатной йотой (и без телефона, чтобы авторизовать банковский платёж и закинуть денег с банковской карты) — так там у меня соединения по 5-10 секунд открывались. Не надо портить то, что уже есть.
              –7
              Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.
                +8
                Я как-то в молодости месяц выкачивал нужную мне исошку линукса на диалапе. Я вполне могу себе представить ситуацию, когда нужно, но доступен только говёный инет. И получать отлуп от сервера только на том основании, что у меня медленный канал с потерей пакетов будет очень и очень обидно. Не для этого TCP изобретался.
                  –9
                  1. Это было давно
                  2. Обычной почтой выйдет быстрее
                  3. Мне обидно потерять 10% из-за теоретических ситуаций
                  4. Когда изобретался TCP вряд ли кто-то думал о том, что файлы будут по 5Гб.

                  ЗЫ: Если владелец сервиса решит пожертвовать, то он пожертвует. Можно протестовать, рисовать на него фотожабы, писать в спортлото и устроить голодовку, но это бизнес.
                  +7
                  >Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.

                  «За мкадом жизни нет»?
                  • НЛО прилетело и опубликовало эту надпись здесь
                      0
                      Даже в Подмосковье на 3g/gprs можно получить такой ужасный канал, что просто удивительно. Я лучше пожертвую 10% канала, чтобы сеть была более надежной
                • НЛО прилетело и опубликовало эту надпись здесь
                    +1
                    1. IW10 в linux >= 2.6.38
                    4. PRR в linux >= 3.2
                      0
                      TCP Fast Open серверная часть >=3.7, клиентская часть >3.6. Про Windows ничего не сказано, но «We also coordinated with the developers of Chrome to implement TFO support within the browser». То есть если даже сделают только для Chrome, все остальные ускорения не увидят.
                      Все сервера на Centos идут лесом, включая Centos 6.3, т.к. kernel vesion 2.6.32.
                      +11
                      как всё это включить в Linux?
                        0
                        Поддерживаю! И вот комментарий в +1: habrahabr.ru/blogs/network_technologies/136926/#comment_4559184
                        Товарищи знающие, делитесь знаниями, а то раскулачим! :-)
                          0
                          Из комментариев к источнику:
                          Linux kernel versions of the changes were applied:

                          1. Initial Congestion Window of 10 packets: 2.6.39-rc1
                          2. Initial Retransmission Timeout of 1sec: 3.1-rc1
                          3. Proportional Rate Reduction: 3.2-rc1
                          4. Fast Open: not yet. It's the most complicated change. We are still testing the patches internally and will upstream when it's ready.
                          Другой комментарий утверждает, что Fast Open есть в 2.6.34, ссылаясь на [1]. Но в целом итак понятно, что разработчики ядра linux не дремлют.
                      • НЛО прилетело и опубликовало эту надпись здесь
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • НЛО прилетело и опубликовало эту надпись здесь
                          +3
                          Много разговоров ни о чем.
                          Где конкретика?
                          Как проверить и подкрутить эти параметры на реальной системе?
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Вы таки хотите сказать, коллега, что если у меня стабильный пинг с временем отклика 500 мс и канал 100 Мбит/с, то не видать мне комфортного просмотра на ютубе? Ну а если да — видать, то зачем вообще вы приводите этот ваш пинг с вашего vds по 2 мс?
                              • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  А почему до вдс-а потерь нет, а до ютуба есть? Более вероятна как раз обратная ситуация, либо равнозначные потери и там и там.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                            • НЛО прилетело и опубликовало эту надпись здесь

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое