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

Original author: Yuchung Cheng
  • Translation
Компания 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 для всего интернета.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 32

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

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

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

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

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

                  «За мкадом жизни нет»?
                  • UFO just landed and posted this here
                      0
                      Даже в Подмосковье на 3g/gprs можно получить такой ужасный канал, что просто удивительно. Я лучше пожертвую 10% канала, чтобы сеть была более надежной
                • UFO just landed and posted this here
                    +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 не дремлют.
                      • UFO just landed and posted this here
                        • UFO just landed and posted this here
                          • UFO just landed and posted this here
                            • UFO just landed and posted this here
                          +3
                          Много разговоров ни о чем.
                          Где конкретика?
                          Как проверить и подкрутить эти параметры на реальной системе?
                          • UFO just landed and posted this here
                              0
                              Вы таки хотите сказать, коллега, что если у меня стабильный пинг с временем отклика 500 мс и канал 100 Мбит/с, то не видать мне комфортного просмотра на ютубе? Ну а если да — видать, то зачем вообще вы приводите этот ваш пинг с вашего vds по 2 мс?
                              • UFO just landed and posted this here
                                  0
                                  А почему до вдс-а потерь нет, а до ютуба есть? Более вероятна как раз обратная ситуация, либо равнозначные потери и там и там.
                                  • UFO just landed and posted this here
                            • UFO just landed and posted this here

                              Only users with full accounts can post comments. Log in, please.