Добрый день, уважаемые хабрапользователи, несмотря на тенденцию падения Oracle в глазах системных инженеров и компаний заказчиков. Операционная система, теперь уже Oracle Solaris продолжает жить и радовать наш глаз.
Недавно столкнулся с вопросом оптимизации некоторых параметров TCP/IP стека. Данная тема показалась мне интересна, многим она может показаться уже избитый, а кого то познакомит с новыми интересными моментами настройки. Итак начнем…
Для начала рассмотрим такие два параметра как tcp_conn_req_max_q и tcp_conn_req_max_q0, зачем они вообще нужны, какие значения для данных параметров являются самыми подходящими.
Говоря простым языком данные параметры отвечают за максимальное количество запросов на IP адрес и на порт, которые будут обработаны сервером.tcp_conn_req_max_q — это максимальное количество входящих соединений которые будут обработаны портом.tcp_conn_req_max_q0 — это максимальное количество «полуоткрытых» TCP сессий которые могут существовать на порту.
Данные параметры на Solaris позволяют администратору для того, обеспечить блокирование SYN пакетов, для предотвращения атак типа «denial of service», в простанородии DDOS.
Значение по умолчанию для для параметра tcp_conn_req_max_q на Solaris всего 128, а для параметра tcp_conn_req_max_q0 1024. Данные параметры в принципе являются достаточными для сервера обслуживающего небольшое количество клиентов, но если на сервер ожидается большее количество обращений чем указанное по дефолту, то это существенно попортит нервы системному администратору. Изначала это выглядит примерно так.
root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q
128
root@T1000-spare # ndd /dev/tcp tcp_conn_req_max_q0
1024
Когда же наступает момент изменения данных параметров, на самом деле его определить достаточно просто, если количество дропнутых пакетов будет зашкаливать, значит время пришло. Как же определить это количество, воспользуемся обычной выборкой:
root@T1000-spare # netstat -s | fgrep -i listendrop
tcpListenDrop = 0 tcpListenDropQ0 = 0
sctpListenDrop = 0 sctpInClosed = 0
В моем случае, тут стоят нули, так как сервер тестовый показать изменение значений не могу. Но схема такая: если значение tcpListenDrop не равно нулю, увеличиваем tcp_conn_req_max_q, а ежели tcpListenDropQ0 отлично от нуля, соответственно увеличим значение параметра tcp_conn_req_max_q0.
Но, есть одно НО, если очень сильно увеличить tcp_conn_req_max_q сразу, то она естественно будет уязвима к DDOS с использованием SYN пакетов. Как раз таки для этого нам и нужен второй параметр, которые идеально создан для предотвращения таких случаев. Второй параметр отвечает за сессии, которые будут становится в очередь на сервере, после получения SYN пакета. К сожалению, его также нельзя увеличивать безразмерно, так как в случае медленной работы приложения клиенты будут попадать в очередь и оставаться там, так и не соединившись на сервер.
Любые изменения данных значений легко проводятся с помощью команды ndd, как пример, приведу значения одного из высоконагруженных серверов, данные параметры могут быть использованы в работе:
# ndd -set /dev/tcp tcp_conn_req_max_q 16384 <====
# ndd -set /dev/tcp tcp_conn_req_max_q0 16384 <====
# ndd -set /dev/tcp tcp_max_buf 4194304
# ndd -set /dev/tcp tcp_cwnd_max 2097152
# ndd -set /dev/tcp tcp_recv_hiwat 400000
# ndd -set /dev/tcp tcp_xmit_hiwat 400000
В заключении об этих параметрах хочу сказать, что к изменению данных параметров необходимо относить с должной скурпулезностью и не менять их без надобности.
P.S. Если у кого-либо возникнет интерес касательно других параметров, в следующей статье можно будет и их описать. Спасибо за внимание.
