Чтобы активировать механизм tcp fast open в ядре linux нужно ввести команду
Обновлено: 02.07.2024
конфигурация
- Процессоры: 2 процессора x 4 ядра - Intel (R) Xeon (R) CPU E5345 @ 2,33 ГГц
- Оперативная память: 12 ГБ
- Сетевая карта: Корпорация Intel, 80003ES2LAN, гигабитный Ethernet-контроллер / 82546EB, гигабитный Ethernet-контроллер
- Сетевой коммутатор: Cisco Catalyst 2960
- Информация о данных: блоки данных прибл. каждые 10 миллисекунд. Размер блока данных составляет ок. 1000 байт.
Сетевая задержка при получении пакетов очень важна (важны десятки микросекунд). Я максимально оптимизировал программу, но у меня нет опыта настройки Ubuntu.
Что можно настроить в Ubuntu для уменьшения локальной задержки обработки / отправки пакетов?
С перечисленным оборудованием это оборудование эпохи 2008 года (процессоры Intel серии 5300). В то время не было слишком много специальных изменений оборудования с низкой задержкой. Я бы установил системный BIOS для работы в высокопроизводительном режиме и отключил C-состояния процессора. @ewwhite Да, вы правы насчет оборудования 2008 года. Я попробую ваши предложения. Спасибо! Любая возможность настроить это программное обеспечение для TCP_NODELAY?Честно говоря, я бы не стал использовать Ubuntu для этого . но есть опции, которые можно применить к любому варианту Linux.
Вы хотите увеличить ваши буферы сетевого стека:
Если приложение записывает данные на диск, возможно, потребуется изменить планировщик / лифт (например, deadline лифт).
На уровне сервера вы можете изменить регулятор ЦП и управление питанием и частотой ЦП (P-состояния, C-состояния).
На уровне ОС вы можете изменить приоритет вашего приложения в реальном времени ( chrt ), оптимизируя его для сокращения прерываний, прикрепляя его к ЦП или группе ЦП ( taskset ) и останавливая ненужные службы или демоны.
Вы также можете увидеть некоторые предложения по адресу: Как устранить задержки между двумя хостами Linux
Трудно быть более конкретным, не зная аппаратного или сетевого оборудования.
Это не совсем подходящее место для религиозных дебатов. Возьмите это в другом месте, например, в чате. @MichaelHampton В обсуждении были интересные ссылки, связанные с вопросом: Руководство по настройке Red Hat Realtime .Если вы идете по пути высокой производительности, обычно вам нужно запускать как можно меньше других (запланированных) процессов, поскольку они будут мешать вашему приложению.
Linux, как и классические операционные системы UNIX, предназначен для одновременной справедливой работы нескольких приложений и пытается предотвратить нехватку ресурсов, и вы будете стремиться к обратному, истощать все остальное, кроме вашего приложения. Простые шаги на уровне ОС меняют хороший уровень и приоритет вашего приложения в реальном времени, меняют планировщик или переходят на ядро реального времени .
TCP / IP обычно настраивается для предотвращения разрыва соединения и эффективного использования доступной пропускной способности. Чтобы получить наименьшую возможную задержку на очень быстром канале, а не на максимально возможной полосе пропускания для соединения, где некоторые промежуточные каналы более ограничены, вам нужно настроить параметры сетевого стека.
покажет вам множество настроек ядра, которые вы можете настроить. Настройки зависят от того, используете ли вы IPv4 или IPv6 и что именно вы уже делаете в своем приложении, но может представлять интерес:
- net.ipv4.tcp_window_scaling=1 RFC 1323 - поддержка размеров окна TCP IPV4 больше 64 КБ - обычно требуется в сетях с высокой пропускной способностью
- net.ipv4.tcp_reordering=3 Максимальное количество раз, когда пакет IPV4 может быть переупорядочен в потоке пакетов TCP без TCP при условии потери пакетов и медленного старта.
- net.ipv4.tcp_low_latency=1 намеревался отдавать предпочтение низкой задержке по сравнению с более высокой пропускной способностью; Параметр = 1 отключает обработку пре-очереди IPC4 tcp
- net.ipv4.tcp_sack=0 значение 1 включает выборочное подтверждение для IPV4, которое требует включения tcp_timestamps и добавляет некоторые издержки пакета, которые вам не нужны, если вы не испытываете потери пакетов
- net.ipv4.tcp_timestamps=0 Рекомендуется только в тех случаях, когда требуется мешок.
- net.ipv4.tcp_fastopen=1 Включить отправку данных в открывающем пакете SYN.
Большинство, если не все, лучше документированы в исходном коде ядра .
Конечно, вы можете кодировать необработанные TCP-сокеты и в целом обходить стек TCP / IP ядра.
Часто хорошо настроенные системы работают в доверенной сети и их локальные (iptables) брандмауэры отключаются.
Я ожидаю получить ответ от сервера с опцией TCP (Fast Open Cookie: xxxxxxx) примерно так:
Но я получил пакет tcp без опции TCP (Fast Open Cookie: xxxxxxx).
Мне интересно, есть ли что-то, что нужно настроить на моем PC2 (linux), чтобы активировать опцию TCP Fastt Open.
Для сервера TCP я запускаю скрипт php:
1 ответ
Мне нужно периодически отправлять (обмениваться) большим объемом данных с минимально возможной задержкой между 2 машинами. Сеть довольно быстрая (например, 1 Гбит или даже 2G+). ОС - это linux. Будет ли это быстрее с использованием 1 сокета tcp (для отправки и recv) или с использованием 2.
Вы должны включить TFO в прослушивающем сокете сервера с помощью:
Похожие вопросы:
Устройство Apple === маршрутизатор === WiFi модуль Устройство Apple (iPhone) подключается к порту модуля WiFi 2000 с подключением TCP. Я хочу активировать отправку пакета TCP keepalive на устройстве.
Я пишу клиент TCP на машине Linux 3.15, которая может использовать TCP Fast Open: status = sendto(sd, (const void *) data, data_len, MSG_FASTOPEN, (const struct sockaddr *) hostref->ai_addr.
Я работаю над средой виртуализации (Linux над HyperV). Драйвер Linux для виртуального NIC поддерживает TSO и GSO (сегментация tcp-это ON, а универсальная сегментация-ON). Теперь я создаю сокет TCP и.
Мне нужно периодически отправлять (обмениваться) большим объемом данных с минимально возможной задержкой между 2 машинами. Сеть довольно быстрая (например, 1 Гбит или даже 2G+). ОС - это linux.
Я хочу изменить код linux kernel, чтобы отфильтровать какой-то пакет tcp и отбросить его. Но я всегда получаю его снова и снова. Вот мой код в /net/ipv4/tcp_ipv4.c int tcp_v4_do_rcv(struct sock *sk.
Я пытался активировать драйвер Linux phyless Ethernet. В сети не так уж много информации. Я использую ARM на основе Linux kernel SOC подключается к порту RGMII 1 Гбит / с спина к спине, не имея.
Протокол Linux API и TCP имеют понятия, называемые socket. Являются ли они одной и той же концепцией, и реализует ли сокет Linux TCP концепцию сокета TCP? Связь между соединениями и розетками: Я.
Следующий скрипт проверит, открыт или закрыт порт tcp от 8079 до 8081. for port in ; do echo >/dev/tcp/127.0.0.1/$port && echo port $port is open || echo port $port is closed.
Сейчас речь пойдет о том, как можно настроить ядро Linux сервера, чтобы он смог переваривать большое количество запросов, а так же DDos. Все будет кратко с небольшим описанием.
Много материалов я вычитал, для того чтобы понять какие значения оптимальны, так же прилично всего перепробовал, и некоторые решения помогли мне уйти от той высокой нагрузки на сервере. Так же грамотная настройка ядра сервера позволит вам защититься от SYN flood. Ладно, начнем..
rp_filter
По умолчанию он отключен:
Так проверку можно включить на определенном интерфейсе:
accept_source_route
По умолчанию эта опция отключена:
accept_redirects, secure_redirects, send_redirects
По умолчанию все эти параметры включены:
Но, так как наш сервер не маршрутизатор, в них нет необходимости:
icmp_echo_ignore_broadcasts
По умолчанию включено, т.е. broadcast icmp запросы приходить не будут:
Так и рекомендуется отставить:
icmp_ignore_bogus_error_responses
Так и рекомендуется отставить:
icmp_echo_ignore_all
На ваше усмотрение, можно отключить:
Как проверить, включен ли он у нас:
Таким образом, как описано выше, мы получаем неплохую защиту от syn флуда и терпим небольшую нагрузку на ЦП..
tcp_max_syn_backlog
Если на сервере возникают перегрузки, можно попытаться увеличить это значение, например до 4096:
tcp_synack_retries
Целочисленное значение (1 байт) tcp_synack_retries определяет число попыток повтора передачи пакетов SYNACK для пассивных соединений TCP. Число попыток не должно превышать 255. Значение 5 соответствует приблизительно 180 секундам на выполнение попыток организации соединения.Это значение имеет смысл уменьшить, например до 1 (это будет 9 секунд):
tcp_max_orphans
Целочисленное значение параметра tcp_max_orphans определяет максимальное число допустимых в системе сокетов TCP, не связанных каким-либо идентификатором пользовательского файла (user file handle). При достижении порогового значения “осиротевшие” (orphan) соединения незамедлительно сбрасываются с выдачей предупреждения. Этот порог помогает предотвращать только простые атаки DoS. Не следует уменьшать пороговое значение (скорее увеличить его в соответствии с требованиями системы – например, после добавления памяти. Каждое orphan-соединение поглощает около 64 Кбайт не сбрасываемой на диск (unswappable) памяти.Рекомендуется установить 65536, а далее увеличивать, по мере необходимости:
tcp_fin_timeout
Целое число в файле tcp_fin_timeout определяет время сохранения сокета в состоянии FIN-WAIT-2 после его закрытия локальной стороной. Партнер может не закрыть это соединение никогда, поэтому следует закрыть его по своей инициативе по истечении тайм-аута. По умолчанию тайм-аут составляет 60 секунд. В ядрах серии 2.2 обычно использовалось значение 180 секунд и вы можете сохранить это значение, но не следует забывать, что на загруженных WEB-серверах вы рискуете израсходовать много памяти на сохранение полуразорванных мертвых соединений. Сокеты в состоянии FIN-WAIT-2 менее опасны, нежели FIN-WAIT-1, поскольку поглощают не более 1,5 Кбайт памяти, но они могут существовать дольше.Рекомендуется поменять на 10 секунд:
tcp_keepalive_time
Переменная определяет как часто следует проверять соединение, если оно давно не используется. Значение переменной имеет смысл только для тех сокетов, которые были созданы с флагом SO_KEEPALIVE.По умолчанию 2 часа:
Рекомендуется каждую минуту:
tcp_keepalive_intvl
Целочисленная переменная tcp_keepalive_intvl определяет интервал передачи проб. Произведение tcp_keepalive_probes * tcp_keepalive_intvl определяет время, по истечении которого соединение будет разорвано при отсутствии откликов. По умолчанию установлен интервал 75 секунд, т.е., время разрыва соединения при отсутствии откликов составит приблизительно 11 минут.tcp_keepalive_probes
Целочисленная переменная tcp_keepalive_probes задает число передач проб keepalive, после которого соединение считается разорванным. По умолчанию передается 9 проб.netdev_max_backlog
Рекомендуется так и оставить:
somaxconn
Рекомендуется установить значения в районе 15000-20000:
tcp_mem
Векторная (минимум, режим нагрузки, максимум) переменная в файле tcp_mem cодержит общие настройки потребления памяти для протокола TCP. Эта переменная измеряется в страницах (обычно 4Кб), а не байтах.Минимум: пока общий размер памяти для структур протокола TCP менее этого количества страниц, операционная система ничего не делает.
Режим нагрузки: как только количество страниц памяти, выделенное для работы протокола TCP, достигает этого значения, активируется режим работы под нагрузкой, при котором операционная система старается ограничивать выделение памяти. Этот режим сохраняется до тех пор, пока потребление памяти опять не достигнет минимального уровня.
Максимум: максимальное количество страниц памяти, разрешенное для всех TCP сокетов. В этой переменной задаются 3 значения, определяющие объем памяти, который может быть использован стеком TCP. Значения измеряются в страницах памяти. Размер одной страницы зависит от аппаратуры и конфигурации ядра. Для архитектуры i386 размер одной страницы составляет 4Кб, или 4096 байт. Некоторые, более новые аппаратные реализации, имеют размер страницы равный 16, 32 или даже 64 Кб. Все три значения по-умолчанию рассчитываются во время загрузки. Первое число задает нижний порог. Ниже этого порога, стек TCP вообще никак не беспокоится об управлении памятью, используемой различными TCP сокетами. Когда объем используемой памяти достигает второго предела (числа), то TCP начинает более энергично расталкивать память, стремясь освободить ее как можно быстрее. Этот процесс продолжается до тех пор, пока объем использумой памяти не достигнет нижнего предела. И последнее число максимальный объем памяти, который может использоваться для нужд TCP. Если используемый объем памяти достигнет этого порога, то TCP просто начинает терятьпакеты и соединения до тех пор, пока объем используемой памяти не уменьшится. Эта переменная может позволить несколько увеличить пропускную способность на толстых каналах, если должным образом настроить переменные tcp_mem, tcp_rmem и tcp_wmem. Впрочем, переменная tcp_rmem не требует особо пристального внимания, поскольку серия ядер 2.4 имеет достаточно хорошие настройки этой переменний, а вот на другие две следует взглянуть поближе. Дополнительную информацию об этом вы найдете в руководстве TCP Tuning Guide.
Можно поставить эти же значения.увеличивать имеет смысл в случае увеличения нагрузки.
tcp_rmem
Векторная (минимум, по умолчанию, максимум) переменная в файле tcp_rmem содержит 3 целых числа, определяющих размер приемного буфера сокетов TCP.Минимум: каждый сокет TCP имеет право использовать эту память по факту своего создания. Возможность использования такого буфера гарантируется даже при достижении порога ограничения (moderate memory pressure). Размер минимального буфера по умолчанию составляет 8 Кбайт (8192).
Значение по умолчанию: количество памяти, допустимое для буфера передачи сокета TCP по умолчанию. Это значение применяется взамен параметра /proc/sys/net/core/rmem_default, используемого другими протоколами. Значение используемого по умолчанию буфера обычно (по умолчанию) составляет 87830 байт. Это определяет размер окна 65535 с заданным по умолчанию значением tcp_adv_win_scale и tcp_app_win = 0, несколько меньший, нежели определяет принятое по умолчанию значение tcp_app_win.
Максимум: максимальный размер буфера, который может быть автоматически выделен для приема сокету TCP. Это значение не отменяет максимума, заданного в файле /proc/sys/net/core/rmem_max. При «статическом» выделении памяти с помощью SO_RCVBUF этот параметр не имеет значения.
Можно поставить эти же значения.увеличивать имеет смысл в случае увеличения нагрузки. В одном из источнике рекомендовали следующие значения:
tcp_wmem
Векторная переменная в файле tcp_wmem содержит 3 целочисленных значения, определяющих минимальное, принятое по умолчанию и максимальное количество памяти, резервируемой для буферов передачи сокета TCP.Минимум: каждый сокет TCP имеет право использовать эту память по факту своего создания. Размер минимального буфера по умолчанию составляет 4 Кбайт (4096)
Значение по умолчанию: количество памяти, допустимое для буфера передачи сокета TCP по умолчанию. Это значение применяется взамен параметра /proc/sys/net/core/wmem_default, используемого другими протоколами и обычно меньше, чем /proc/sys/net/core/wmem_default. Размер принятого по умолчанию буфера обычно (по умолчанию) составляет 16 Кбайт (16384)
Максимум: максимальное количество памяти, которое может быть автоматически выделено для буфера передачи сокета TCP. Это значение не отменяет максимум, заданный в файле /proc/sys/net/core/wmem_max. При «статическом» выделении памяти с помощью SO_SNDBUF этот параметр не имеет значения.
Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. В одном из источнике рекомендовали следующие значения:
rmem_default, wmem_default
Их значения по умолчанию:
Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. Например, в одном из источнике рекомендовали следующие значения:
rmem_max, wmem_max
Их значения по умолчанию:
Можно оставить эти же значения. Увеличивать их имеет смысл в случае увеличения нагрузки. Например, в одном из источнике рекомендовали следующие значения:
tcp_orphan_retries
Целочисленной значение tcp_orphan_retries определяет число неудачных попыток, после которого уничтожается соединение TCP, закрытое на локальной стороне. По умолчанию используется значение 7, соответствующее приблизительно периоду от 50 секунд до 16минут в зависимости от RTO.Рекомендуется уменьшить значение этого параметра, поскольку закрытые соединения могут поглощать достаточно много ресурсов (т.е. оставляем 0):
ip_conntrack_max
При слишком маленьких значениях ядро начинает отвергать входящие подключения с соответствующей записью в системном логе:
tcp_timestamps
По умолчанию метки включены:
Кстати, лучше отставить его включенным, иначе не будет работать опция tcp_tw_reuse.
tcp_sack
По умолчанию опция включена:
Рекомендуется включать эту опцию, если вы имеете неустойчивые соединения. Однако, если вы соединены 1.5-метровым кабелем с другой машиной, то в таком случае, для достижения наивысшей скорости обмена, следует эту опцию отключить:
tcp_congestion_control
Начиная с версии 2.6.13, Linux поддерживает подключаемые алгоритмы управления перегрузкой. Используемый алгоритм управления перегрузки можно задать, используя sysctl переменную net.ipv4.tcp_congestion_control, которая по умолчанию установлена в cubic or reno, в зависимости от версии ядра.Для получения списка поддерживаемых алгоритмов, выполните: sysctl net.ipv4.tcp_available_congestion_control
Выбор опций контроля за перегрузкой выбирается при сборке ядра. Ниже представлены некоторые из опций, доступных в 2.6.23 ядрах:
* reno: Традиционно используется на большинстве ОС. (default)
* cubic: CUBIC-TCP (Внимание: Есть бага в ядре Linux 2.6.18 Используйте в 2.6.19 или выше!)
* bic:BIC-TCP
* htcp:Hamilton TCP
* vegas:TCP Vegas
* westwood:оптимизирован для сетей с потерями
Для очень длинных и быстрых каналов я предлагаю пробовать cubic или htcp, если использование reno желательно.
Для сервера рекомендуется использовать htcp:
tcp_no_metrics_save
По умолчанию опция ничего не запрещает:
Так как это помогает повысить производительность, рекомендуется включить:
net.ipv4.route.flush
Так как в ядре 3.2 она даже не читается, менять ничего не стал.
ip_local_port_range
Содержит два целых числа, которые определяют диапазон локальных портов, которые используются в клиентских соединениях, т.е. для исходящих соединений, которые связывают нашу систему с некоторым узлом сети, где мы выступаем в качестве клиента. Первое число задает нижнюю границу диапазона, второе верхнюю. Значения по-умолчанию зависят от имеющегося объема ОЗУ. Если установлено более чем 128 Мб, то нижняя граница будет 32768, а верхняя 61000. При меньшем объеме ОЗУ нижняя граница будет 1024 а верхняя 4999 или даже меньше. Этот диапазон определяет количество активных соединений, которые могут быть запущены одновременно, с другой системой, которая не поддерживает TCP-расширение timestamp. Диапазона 1024-4999 вполне достаточно для установки до 2000 соединений в секунду с системами, не поддерживающими timestamp. Проще говоря, этого вполне достаточно для большинства применений.По умолчанию там такой диапазон:
Для тяжелых проектов диапазон рекомендуется увеличить:
tcp_tw_reuse
По умолчанию отключена:
tcp_window_scaling
По умолчанию она включена:
Лучше так и оставить:
tcp_rfc1337
По умолчанию опция отключена:
На сервере она точно не помешает:
ip_forward
По умолчанию переадресация включена:
Если сервер не является маршрутизатором, то включать эту опцию нет необходимости:
tcp_abort_on_overflow
Если ситуация требует, то ее можно включить:
Как все это применить?
Я намеренно для изменения параметров использовал утилиту sysctl, а значения этих параметров просто читал с помощью cat. Сделано это было все для того, чтобы вам было ясно что способов изменения параметров ядра много.
Например, внести изменения мы так же можем с помощью echo:
А прочитать значения мы так же можем с помощью команды sysctl:
Как применить все эти значения разом, не сохраняя их?
Для удобства ниже приведены все параметры разом, если решение вам нужно здесь и сейчас:
Как сохранить эти значения?
Если сервер работает корректно со всеми настройками указанными выше, то для их сохранения достаточно добавить все эти переменные в конец файла /etc/sysctl.conf:
Заключение
Тема настройки ядра Linux «на лету», актуальная для многих системных администраторов, уже была освещена нами в статье «Что такое sysctl». В прошлой статье был описан сам принцип настройки ядра с помощью утилиты sysctl, приведены базовые команды и даны примеры некоторых наиболее распространенных параметров ядра Linux.
В этом материале хочется остановиться на конфигурации параметров сетевого стека на базе ОС Linux. Данная статья будет полезна системным администраторам при настройке высоконагруженных серверных ОС для «тяжелых» веб-проектов, а также поможет специалистам в сфере кибербезопасности построить оптимальную защиту от DDoS атак.
Все настройки сетевого стека необходимо внести в конфигурационный файл /etc/sysctl.conf. Также можно изменить опции любого сетевого параметра ядра «на лету» с помощью команды:
Например, ниже на скриншоте показано, как изменить параметр rp_filter:
Команда sysctl -p — выводит на экран текущие настройки сетевого параметра из файла /etc/sysctl.conf
Чтобы посмотреть значение одного сетевого параметра, который вас интересует в конкретный момент, нужно выполнить следующую команду, например для ip_forward:
Еще один способ для просмотра параметров ядра Linux — это использование директории /proc/sys и команды cat, о чем вы можете более подробно прочитать в статье на нашем сайте FREEhost.UA.
Для изменения параметров таким способом используется команда ниже (например, вместо 1 указываем нужное значение параметра, на которое мы хотим изменить опцию rp_filter):
Однако, не все параметры могут быть изменены таким образом, некоторые из них задаются сразу только при загрузке ядра и на лету не меняются.
Например, ниже показано, как вывести на экран (командой cat) конкретные сетевые параметры настроек ядра Ubuntu:
В следующем разделе статьи мы приведем основные параметры сетевого стека ядра Linux, расскажем для каких целей они нужны и какие значения необходимо выставить для оптимальной работы TCP/IP и для обеспечения безопасной работы сервера.
Настройка сетевых параметров ядра Linux
Для начала выведем текущие настройки параметров ядра «по умолчанию» (раздел net). В результате, получим листинг на несколько листов, ниже на скриншоте показана только часть этого списка параметров:
Для тюнинга сетевого стека нам нужны не все эти сетевые параметры, а только наиболее важные.
1. Приступим к настройкам, и начнем с группы параметров, которые отвечают за работу протокола 3-го уровня модели OSI — ICMP (Internet Control Message Protocol), которые обычно применяются для «пингования» хоста, т.е. для выполнения команд ping и traceroute. В нашем случае, хакеры могут использовать ICMP-пакеты перенаправления, чтобы изменить таблицы маршрутизации. Поэтому, если вы не занимаетесь настройкой маршрутизатора, то для хоста необходимо выставить значение «0» для следующих параметров ядра Linux:
2. Следующим этапом настройки, идет выставление значения параметра tcp_max_orphans, в дословном переводе — это «осиротевшие» (orphan) соединения. Когда параметр достигнет своего порогового значения, такие соединения просто сбрасываются, и система выдает предупреждение. Советуем увеличить пороговое значение этого параметра (каждое «осиротевшее» соединение требует 64 Кбайт unswappable памяти). Правильная настройка данной опции поможет в защите от наиболее простых типов DDoS-атак.
3. Затем необходимо установить правильное значение для параметра tcp_fin_timeout, который обозначает время, в течении которого сокет может быть сохранен в состоянии FIN-WAIT-2, когда локальная сторона осуществила уже его закрытие. Данное соединение может быть вообще не закрыто партнером, поэтому необходимо его закрыть принудительно (когда «тайм-аут» истек). Значение «по умолчанию» для данного параметра — 60 секунд. Можно оставить значения «по умолчанию», но в случае, если вы эксплуатируете какие-то «тяжелые» веб-приложения, будет расходоваться много памяти на поддержку «мертвых соединений». Поэтому следует настроить данный параметр таким образом:
4. Сейчас настроим еще 3 важных параметра:
tcp_keepalive_time — показывает, как часто нужно проверять соединение, в том случае, если оно давно не используется (только для сокетов с флагом SO_KEEPALIVE), «по умолчанию» это значение равно 7200 секунд;
tcp_keepalive_intvl — обозначает интервал передачи проб, значение «по умолчанию» выставлено 75 сек;
tcp_keepalive_probes * tcp_keepalive_intvl = время, после истечения которого, соединение должно быть разорвано (если нет откликов), примерное значение — 11 минут;
tcp_keepalive_probes — показывает значение для передач проб keepalive, после достижения которого, соединение будет разорвано, «по умолчанию» выставлено 9.
Ниже приводятся рекомендуемые значения для данных 3-х параметров*:
*Примечание: для параметра tcp_keepalive_time рекомендованные значения от 60 до 300.
5. Следующий важный параметр, который требует нашего внимания — это
tcp_max_syn_backlog, показывающий максимум полуоткрытых соединений, т.е. запоминаемых запросов на соединение, для которых подключающийся клиент не дал подтверждение. Советуем увеличить заданное «по умолчанию» значение, особенно в случае возникновения перезагрузок сервера.
6. На этом шаге настроим параметр tcp_synack_retries, отвечающий за время удержания «полуоткрытых» соединений. Здесь задается количество попыток повтора передачи SYN-ACK пакетов для пассивных соединений TCP, которое не должно быть более 255. «По умолчанию» выставлено число 5 (соответствует 180 сек. времени, выделенного на эти попытки). Рекомендуется уменьшить это время до 9 сек, что будет соответствовать единице.
7. Параметр tcp_mem описан в виде векторной переменной, которая может принимать три значения, определяющие объем памяти, который может быть использован стеком TCP. Задается параметр в страницах памяти и зависит от архитектуры серверного оборудования, например, для i386 — это будет 4Кб (4096 байт). Три значения переменной (минимальное, значение в режиме нагрузки и максимальное) будут вычислены во время нагрузки. Если значение ниже минимального, то ОС вообще не выполняет никаких действий по управлению памятью, потребляемой сокетами TCP. Работа в режиме нагрузки: при достижении данного значения включается этот режим, и операционная система будет ограничивать выделение памяти. Причем, работа в таком режиме происходит до того момента времени, когда потребление памяти опять не снизится до минимума. И наконец, при достижении максимального значения этой переменной, TCP будет просто «терять» пакеты и соединения, пока объем используемой памяти не начнет снижаться. Для увеличения пропускной способности каналов рекомендуется оптимально настроить сразу 3 переменные tcp_mem, tcp_rmem и tcp_wmem. При настройке этих параметров советуем вам: для более мощных серверов выставлять большие параметры, а для серверов с более слабой конфигурацией — меньшие значения параметров. «По умолчанию» net.ipv4.tcp_mem настроен следующим образом*:
*Примечание: если ресурсы сервера позволяют выделить больше памяти под сеть.
В некоторых источниках рекомендуется выставить такие параметры*:
*Примечание: данные параметры рекомендованы для более слабых серверов.
8. Параметр tcp_wmem также, как и в предыдущем случае, является векторной переменной с 3-мя значениями в виде целых чисел (минимум, значение «по умолчанию», максимальное значение) и задает он размер для буфера передачи TCP сокета. При настройке данных параметров учитывайте конфигурацию и производительность ваших серверов, для более производительных серверов можно брать большие параметры. «По умолчанию», могут быть следующие параметры (можно оставить данные настройки):
Для более мощных серверов в некоторых источниках рекомендуется выставить следующие настройки:
9. Еще один подобный параметр в виде векторной переменной tcp_rmem задает размер приемного буфера сокетов TCP и также имеет 3 значения (минимальное значение, значение «по умолчанию», максимальное).
«По умолчанию», этот параметр может быть настроен таким образом:
Согласно рекомендациям из специализированных источников, можно настроить эту опцию так (для более производительных серверов):
10. Параметры rmem_default, wmem_default служат для описания значений «по умолчанию» для размера буферов приема и передачи данных соответственно, они не могут перекрывать значения переменных tcp_rmem и tcp_wmem (см. пункты выше).
Ниже рекомендованы оптимальные значения для этих параметров:
11. Параметры rmem_max, wmem_max служат для перекрытия максимальных значений переменных tcp_rmem и tcp_wmem (описания их см. выше), при увеличении нагрузки на сервер, рекомендованы следующие настройки:
12. Параметр tcp_orphan_retries задает величину, определяющую количество неудачных попыток, после достижения которой, происходит уничтожение соединения TCP, уже закрытого на локальной стороне. Закрытые соединения также расходуют ресурсы системы, поэтому советуем поставить 0, см. ниже:
15. Этот параметр (ip_conntrack_max) необходим для грамотной настройки механизма определения состояния соединений connection tracking (используется для iptables), в общем, эта опция важна для работы межсетевых экранов. Если выставить очень маленькие значения, то ядро будет отвергать входящие соединения, это можно будет увидеть затем системном логе.
16. Параметр tcp_timestamps предназначен для включения временных меток TCP (см. RFC 1323), для высокоскоростной сети и в условиях высоких нагрузок на сервера, советуем оставить ее включенной:
17. Опция tcp_sack необходима для разрешения выборочных подтверждений протокола TCP (Selective Acknowledgements — SACK, см. RFC 2883 и RFC 2883). Данная функция будет полезна на неустойчивых соединениях, где возможны обрывы связи. Включенный «по умолчанию» tcp_sack = 1, разрешает произвести передачу повторно лишь отдельных не подтвержденных фрагментов (а не всего окна TCP), работает совместно с опцией tcp_timestamps.
18. Параметр tcp_congestion_control позволяет осуществлять контроль за управлением нагрузкой в сетях TCP. Выбор настроек контроля за перегрузкой осуществляется при сборке ядра, доступны следующие режимы: reno (default), cubic:CUBIC-TCP, bic:BIC-TCP, htcp:Hamilton TCP, vegas:TCP Vegas, westwood (для сетей с потерями). Для работы сервера рекомендуется использовать htcp. Значение параметра «по умолчанию» — cubic (однако, есть ошибки в ядре Linux 2.6.18).
19. Эта настройка (tcp_no_metrics_save) не разрешает сохранение результатов изменений TCP соединения в кэше, в случае его закрытия. «По умолчанию», она в выключенном состоянии «0», но рекомендуем ее включить для увеличения производительности:
20. Параметр net.ipv4.route.flush актуален для ядра версии 2.4, если ваша ОС на этой версии ядра, то включите его:
21. Следующая группа параметров rp_filter предназначена для защиты от спуфинга (подмены адресов), отвечает за включение/выключение reverse path filter (т.е. проверку обратного адреса). Однако, если вы используете таблицы маршрутизации большой сложности, то перед настройкой этого параметра, рекомендуется изучить RFC 1812. В состоянии «по умолчанию» данные параметры выключены (значение «0»), рекомендуем включить в режим «1» (строгая проверка).
22. На этом этапе необходимо настроить запрет маршрутизации от источника (source routing), т.е. группу параметров accept_source_route; «по умолчанию», настройки находятся в состоянии «выключено» (ноль). Эта опция может предоставлять разрешение отправителю для определения пути пакета, который тот проходит по сети для достижения пункта назначения. Для сетевого инженера — это очень удобная опция, однако ей может воспользоваться и злоумышленник, поэтому рекомендуется ее оставить в выключенном состоянии.
23. Сейчас требуется настроить опцию ip_local_port_range, отвечающую за диапазон локальных портов, которые нам доступны для установки исходящих подключений. Параметр содержит 2 целых числа, где первое из них служит для задания нижней границы этого диапазона, а второе — устанавливает верхнюю границу. Значения выставляются в зависимости от объема ОЗУ сервера. Рекомендуемый диапазон для высоконагруженных проектов:
24. Параметр tcp_tw_reuse служит для разрешения повторного использования сокетов TIME-WAIT, когда это безопасно. Рекомендуется его включить:
25. Для разрешения или запрета масштабирования окна стека TCP необходима настройка параметра tcp_window_scaling (подробно см. RFC 1323). Фактически, разрешая динамическое изменение TCP-окна, можно увеличить размер канала, а также значительно снизить потери пропускной способности.
26. Для установления защиты от атак типа TIME_WAIT, стоит включить параметр tcp_rfc1337. Детально смысл этого параметра "TIME-WAIT Assassination Hazards in TCP" изложен в RFC 1337, а сама проблема заключена в том, что устаревшие дубликаты пакетов вносят помехи в новые соединения и тем самым порождают различные проблемы. Но, так как «по умолчанию» эта опция выключена (значение «0»), для сервера нам необходимо ее включить:
27. Чтобы запретить переадресацию пакетов для сервера, необходимо отключить параметр ip_forward. В случае включения ip_forward (значение «1»), операционная система будет вести себя «как маршрутизатор» и работать согласно RFC1812, т.е. перенаправлять пакеты в соответствии с таблицей маршрутизации.
28. Функция icmp_echo_ignore_broadcasts разрешает (или запрещает) отвечать на запросы ICMP ECHO, которые передаются широковещательными пакетами.
29. Полный запрет ответа на ICMP ECHO запросы (сервер не «пингуется») можно настроить таким образом:
31. Параметр somaxconn необходим для установления значения максимального количества открытых сокетов, которые ожидают соединения. Рекомендуемое значение параметра 15000 (используется для высоконагруженных систем), 65535 — максимальное значение данного параметра, используется в редких случаях:
32. Также необходимо настроить параметр netdev_max_backlog, который задает максимальное число пакетов, находящихся в очереди «на обработку», в случае, когда интерфейс получает пакеты гораздо быстрее, чем ядро их обрабатывает. Ниже приведено значение «по умолчанию» (рекомендуемое).
Пример готового файла с настройками
Для удобства мы свели все вышеописанные параметры в один список, который вам необходимо добавить в конец файла /etc/sysctl.conf и сохранить данный файл, затем перезагрузить ОС, чтобы настройки вступили в силу.
Заключение
В этой части статьи мы дали практические рекомендации для системных администраторов, как провести тюнинг сетевого стека при помощи sysctl. Мы привели только основные переменные типа net для ядра Linux, оптимально настроив которые, системные инженеры смогут выстроить грамотную защиту своей сети от атак, а также эффективно эксплуатировать высоконагруженные сервера с «тяжелыми» веб-приложениями.
Читайте также: