мы находимся в системе debian и пытаемся настроить стек tcp / ip в соответствии с нашими потребностями. Все мы знаем, что вы можете установить максимальный размер буфера tcp с некоторыми параметрами ядра, такими как:
net.ipv4.tcp_wmem = 4096 16384 4194304
net.ipv4.udp_wmem_min = 4096
net.core.wmem_max = 261071
Чтобы рассчитать максимальный размер буфера для ваших нужд, вам «просто» нужно его вычислить. (видеть http://fasterdata.es.net/TCP-tuning/ )
Но так как мы не знаем время обращения наших пользователей туда и обратно, это довольно сложно. Было бы нормально принять значение от 20 до 60 мс. Но для мобильной сети это примерно 100-300 мс (проверено на моем телефоне). Поэтому довольно сложно узнать, сколько данных может быть «на кону».
Мы хотели бы увидеть фактический размер буфера и его использование.
Кто-нибудь знает, как проникнуть в фактические буферы записи и приема tcp?
Но поскольку мы не знаем время приема-передачи наших пользователей
Тогда какой смысл пытаться измерить другую часть уравнения?
(прочтите справочные страницы для lsof (флаг -T), а также netstat).
Но поверьте мне, система TCP довольно умна - и ребята, которые ее написали, умнее нас с вами - и знают об этом гораздо больше. Единственное, о чем следует беспокоиться, это масштабирование окна (в наши дни должно быть отключено по умолчанию), хотя, если вы не передаете очень большие файлы через очень высокоскоростную глобальную сеть, вам, вероятно, это не нужно - если файлы не огромны или пропускная способность низкая, тогда нет никакой выгоды от использования масштаб по умолчанию.
Как они сказали, что-то подобное делать бесполезно. Это может быть полезный если бы у вас был проводной сеть с постоянный трафик, но даже тогда это не предлагается. Что вы могли бы сделать, так это определить другая реализация tcp (Вегас, Тахо, Рино и т. Д. - некоторые реализации).
Каждый из них направлен на улучшение какого-либо аспекта tcp. Например, один пытается уменьшить задержку, другой пытается импортировать джиттер и т. Д.