Для чего увеличивать размеры буферов в tcp?

182

01 ноября 2018, 10:00

Перевожу тут man руководство и вот что пока что интересно

Linux поддерживает высокопроизводительные расширения RFC 1323 TCP.
К ним относятся защита от упакованных последовательностей (PAWS), масштабирование окон и временные метки. Масштабирование окна позволяет использовать большие (> 64 КБ) TCP-окна для поддержки ссылок с высокой задержкой или пропускной способностью.
Чтобы использовать их, размеры буфера отправки и получения должны быть увеличены. Они могут быть установлены глобально с файлами /proc/sys/net/ipv4/tcp_wmem и /proc/sys/net/ipv4/tcp_rmem или в отдельных сокетах с использованием опций сокета SO_SNDBUF и SO_RCVBUF с вызовом setsockopt (2).

Я так понимаю для больших скоростей можно использовать большие размеры буферов я правильно понимаю. Если больших скоростях, то каких, и как понять с высокой задержкой, это же значит, что отклик будет дольше идти, тогда зачем размер буфера увеличивать?

И вот например, большие скорости может поддерживать сервер, а у клиента небольшая скорость, клиент тогда будет получать размер из /proc/sys/net/ipv4/tcp_wmem ?

У меня например в tcp_wmem

4096    16384   4194304

Получаю в основном 16384. То есть мне, в программировании, нужно будет ещё обращаться к этим данным, чтобы узнать максимальные размеры буферов, или можно получить это через getsockopt?

Answer 1

Очень часто провайдеры интернета сообщают скорость интернета, но забывают о таком важном параметре как rtt (round trip time - время на прохождение пакета туда и обратно). Рассмотрим классический TCP, где каждый пакет нужно подтверждать и следующий пакет будет отправлен только после подтверждения предыдущего. В этом случае максимальная скорость будет "размер пакета" деленный на rtt. Сделать пакет бесконечно большим мы не можем - упираемся в mtu (максимальный размер пакета).

Приведем пример. У меня пинг на одного с местных провайдеров 2.5 мс, а mtu = 1472. Поэтому, в классическом варианте tcp скорость не может быть больше пол мегабайта, какую бы скорость не обещал провайдер и канал связи.

Поэтому, сделали следующий трюк - можно отправлять несколько пакетов, не требуя подтверждения сразу, такой себе буфер. И если буфер вмещает 10 пакетов, скорость может возрасти до 10 раз. Круто?

Этот буфер и называется "окном". Пока интернет был маленьким и скорость низенькой, буфера в 32-64 кб хватало всем. Оно же могло вместить 20-40 пакетов (предлагается сделать несложные расчеты и оценить допустимы задержки, если модем пропускает максимум 56кб/с. Формула такая - Полоса пропускания (бит/сек) * RTT (круговое время передачи по сети) = размер окна в битах (и здесь уже *биты, хотя выше оперировали *байтами).

Но потом поняли, что скорости всегда будет нехватать, а скорость распространения сигнала (света) хоть и большая, но конечная. И RTT уменьшить не получится - с Европы в США он будет 120-180 мс, Если даже теоретически продырявить Землю, то с полюса до полюса RTT будет 80мс (12000 км / 300000км/с * 2). И казалось бы - сейчас увеличим размер окна в заголовке пакета, но... тут помешало тяжелое наследие - менять заголовок пакета было как то не с руки, сеть развалится. Поэтому, нашли немного свободного места и добавили множитель - какая разница, окно будет мегабайт или мегабайт и десять байт? И множитель позволяет выставить размер окна где то до одного гигабайта.

Нужно ли менять размер окна для своего приложения? маловероятно. TCP стек и сам неплохо управляется с задачей. И если размер окна не меняется, значит система даже не нагружает TCP стек. А вот если Вы написали приложение для передачи файлов или видео конференции (или чего то подобного) и поняли, что канал гигабитный, а загружаете его всего то на пару мегабайт, то тут может и нужно уже "тюнить tcp стек".