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

[@phprus]

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

Не буду скрывать, нас подобный результат удивил, по этому наши эксперименты в этой области продолжаются.

[@phprus]

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

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

P.S. Это не я. Да и из нашей исследовательской группы, как и из моих оффлайн друзей, на хабре есть только я.

[@amarao]

А почему таймаут в 1с приемлем? Я как-то был в больнице с одной бесплатной йотой (и без телефона, чтобы авторизовать банковский платёж и закинуть денег с банковской карты) — так там у меня соединения по 5-10 секунд открывались. Не надо портить то, что уже есть.

[@korchasa]

Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.

[@amarao]

Я как-то в молодости месяц выкачивал нужную мне исошку линукса на диалапе. Я вполне могу себе представить ситуацию, когда нужно, но доступен только говёный инет. И получать отлуп от сервера только на том основании, что у меня медленный канал с потерей пакетов будет очень и очень обидно. Не для этого TCP изобретался.

[@korchasa]

1. Это было давно
2. Обычной почтой выйдет быстрее
3. Мне обидно потерять 10% из-за теоретических ситуаций
4. Когда изобретался TCP вряд ли кто-то думал о том, что файлы будут по 5Гб.

ЗЫ: Если владелец сервиса решит пожертвовать, то он пожертвует. Можно протестовать, рисовать на него фотожабы, писать в спортлото и устроить голодовку, но это бизнес.

[@Pilat]

>Стриминг, скачка больших файлов, и еще целая куча своеобразных сервисов, не имеют смысла на плохих каналах.

«За мкадом жизни нет»?

[@den_rad]

Даже в Подмосковье на 3g/gprs можно получить такой ужасный канал, что просто удивительно. Я лучше пожертвую 10% канала, чтобы сеть была более надежной

[@bes_internal]

1. IW10 в linux >= 2.6.38
4. PRR в linux >= 3.2

[@DjOnline]

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.

[@rushman]

как всё это включить в Linux?

[@limon_spb]

Поддерживаю! И вот комментарий в +1: habrahabr.ru/blogs/network_technologies/136926/#comment_4559184
Товарищи знающие, делитесь знаниями, а то раскулачим! :-)

[@Lockal]

Из комментариев к источнику:

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 не дремлют.

[@stanlee]

Много разговоров ни о чем.
Где конкретика?
Как проверить и подкрутить эти параметры на реальной системе?

[@AstonMartin]

А почему до вдс-а потерь нет, а до ютуба есть? Более вероятна как раз обратная ситуация, либо равнозначные потери и там и там.