Чи бувало у вас таке, що ставите файл на закачування, і швидкість повільно, але вірно зростає, потім, в якийсь момент, різко знижується, потім знову зростає? Закачування файлу в один потік не забезпечує повну швидкість каналу? Запускаєте торрент-клієнт, і пінг в грі сильно стрибає? Чи використовуєте 3G-модем (або іншу лінію з відносно великою втратою пакетів) і не можете це терпіти?
Напевно ви звинувачували в усьому ваш роутер, або звинувачували свого провайдера в кривій налаштування Шейпера? Це впливає, але винні не вони.
Отже, зустрічайте:
TCP Congestion Control, або TCP congestion avoidance algorithm.
Що це таке?
Коротко - алгоритми, які намагається зробити все можливе, щоб забезпечити найбільш швидку швидкість передачі даних між двома вузлами, які передають дані через TCP. Вони управляють розміром TCP-вікна і можуть орієнтуватися на RTT (Round Trip Time - час від відправки запиту до отримання відповіді), втрату пакетів, час очікування відправки пакета з черги і т.д. Кожен алгоритм по різному веде себе в тій чи іншій ситуації і немає якогось універсального.
Які є алгоритми?
Їх досить багато. У ядрі Linux 3.7 є:
- BIC TCP
- CUBIC TCP
- Highspeed TCP
- H-TCP
- TCP Hybla
- TCP-Illinois
- TCP Low Priority
- TCP Vegas
- TCP NewReno
- TCP Veno
- TCP Westwood +
- YeAH-TCP
BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois - ці алгоритми створені для так званих long fat networks - довгих (а значить, з високим RTT) і швидких мереж. TCP Hybla здорово поводиться на супутникових линках, а Veno створений для бездротових мереж з високою втратою пакетів. TCP Low Priority взагалі складно назвати congestion алгоритмом, тому що він мало що робить, а просто намагається відправити пакет без черги, TCP Vegas іноді застосовують на серверах з великою кількістю підключень, тому що він забезпечує майже постійну швидкість, хоч і далеко не ідеальну. Westwood + - комбінований алгоритм, YeAH-TCP наймолодший з них, але найцікавіший, тому що поводиться більш-менш у всіх випадках.
Більш докладно про самих алгоритмах можна прочитати в пості casperrr
Як бачите, CUBIC в відстаючих. Він значно підвищив RTT на повній утилізації 3G каналу, в той час як Westwood + і NewReno більш-менш справляються з цією проблемою.
Давайте поглянемо на кількість ретрансміссіі:
Як видно з графіка, у CUBIC відносно велика кількість ретрансміссіі
У той же час, він лідирує в швидкості передачі даних за одиницю часу.
Що це означає? Це означає, що з використанням Westwood + або NewReno ви зможете комфортніше серфить інтернет, поки у вас скачується великий файл.
Тест високошвидкісного каналу
В ефективній передачі даних в залежності від RTT лідирує YeAH
Залежність ефективної передачі даних і втрати пакетів, знову YeAH займає перше місце
На жаль, з YeAH на ядрі 3.7 якісь проблеми, через деякий час він важить систему software interrupt'амі. Такого поведінки не спостерігається на 3.6.
Як поміняти?
Змінити Congestion Algorithm досить просто, всього один рядок:
sysctl -w net.ipv4.tcp_congestion_control = westwood
Де замість westwood можна вставити назви з /lib/modules/.../kernel/net/ipv4/tcp_....ko без префікса tcp_.
замість висновку
На каналах на кшталт домашнього вайфая, рекомендую використовувати Westwood або Veno. Для провідних каналів хорошим вибором може бути YeAH (якщо у вас не спостерігається з ним проблем), H-TCP або Illinois.
Декілька порад. Якщо у вас вже ядро 3.6+, обов'язково включите net.ipv4.tcp_fastopen. Ніяких проблем з несумісними серверами це не додасть, а handshake для підтримуваних прискорить.
Також рекомендую встановити net.ipv4.tcp_slow_start_after_idle в 0, це додасть швидкості для SPDY та інших keep-alive з'єднань.