Выбрать главу

Принимает целое число. Значение по-умолчанию — 7, что соответствует, примерно, от 50 секунд до 16 минут, в зависимости от внличины Retransmission Timeout (RTO — Таймаут для Повторной Передачи. прим. перев.). Детальное описание RTO вы найдете в разделе "3.7. Data Communication" RFC 793 — Transmission Control Protocol.

Кроме того, посмотрите описание переменной tcp_max_orphans.

/proc/sys/net/ipv4/tcp_max_syn_backlog

Определяет максимальное время хранения SYN-запросов в памяти до момента получения третьего, завершающего установление соединения, пакета. Эта опция работает только тогда, когда включен параметр tcp_syncookies. Если сервер испытывает серьезные нагрузки, то можно попробовать немного увеличить этот параметр.

Значение по-умолчанию зависит от количества памяти, имеющейся в системе. Если объем памяти менее 128 Мб, то значение по-умолчанию равно 128, если больше, то значение по-умолчанию равно 1024.

Note

Если вы увеличиваете эту переменную до величины более чем 1024, то было бы неплохо изменить величину TCP_SYNQ_HSIZE и пересобрать ядро. TCP_SYNQ_HSIZE находится в файле linux/include/tcp.h. Эта величина рассчитывается по формуле: TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog 

/proc/sys/net/ipv4/tcp_max_tw_buckets

Максимальное число сокетов, находящихся в состоянии TIME-WAIT одновременно. При превышении этого порога — "лишний" сокет разрушается и пишется сообщение в системный журнал. Цель этой переменной — предотвращение простейших разновидностей DoS-атак.

Целое число. Значение по-умолчанию — 180000. На первый взгляд может показаться, что это очень много, но на самом деле это не так. Если у вас начинают возникать ошибки, связанные с этим параметром, то попробуйте увеличить его. 

Warning

Вам не следует уменьшать значение этой переменной. Вместо этого, если начали поступать сообщения в системный журнал, ее следует увеличить, однако, это может потребовать наращивания памяти в системе. 

/proc/sys/net/ipv4/tcp_retrans_collapse

Включает/выключает эмуляцию ошибки протокола TCP, делая возможным сетевое взаимодействие с некоторыми устройствами, в которых реализация стека TCP имеет эту ошибку. Без ее эмуляции было бы невозможным работать с отдельными моделями принтеров. Ошибка заключается в отправке полноразмерных пакетов при повторной передаче.

Может принимать два значения — 0 (выключено) и 1 (включено). Значение по-умолчанию — 1 (включено). Эмуляция ошибки никак не повредит взаимодействию с другими узлами сети, но при этом позволит общаться с устройствами, имеющими ошибку в реализации стека TCP. Вообще эта опция совершенно безопасна, однако, если в журнал пишутся непонятные сообщения — можете попробовать отключить ее.

/proc/sys/net/ipv4/tcp_retries1

Максимальное количество попыток повторной передачи пакетов по установленному соединению прежде, чем сообщение об ошибке будет передано сетевому уровню, в результате чего может быть выбран другой маршрут для отправки последующих пакетов. Минимальное значение этого параметра равно 3. Это число является значением по-умолчанию, что соответствует интервалу времени от 3 секунд до 8 минут, в зависимости от величины Retransmission timeout (RTO). Детальное описание RTO вы найдете в разделе "3.7. Data Communication" RFC 793 — Transmission Control Protocol.

Целое число. Значение по-умолчанию – 3. Стандарты определяют диапазон изменения этого параметра от 3 до 100.

/proc/sys/net/ipv4/tcp_retries2

Максимальное количество попыток повторной передачи пакетов, до того как соединение будет считаться разорванным. Это ограничение определено в RFC 1122 и равно 100, но обычно его уменьшают.

Значение по-умолчанию — 15, что соответствует примерно 13-30 минутам в зависимости от величины Retransmission timeout (RTO).

/proc/sys/net/ipv4/tcp_rfc1337

Является реализацией решения проблемы, описываемой в "RFC 1337 — TIME-WAIT Assassination Hazards in TCP". Проблема связана с "устаревшими" дубликатами пакетов, которые могут вносить помехи во вновь устанавливаемые соединения и порождать три различные проблемы. Первая – "устаревший" дубликат пакета с данными может быть ошибочно воспринят в новом соединении, что приведет к передаче неверных данных. Вторая – соединение может быть десинхронизировано и "уйти" в ACK-цикл из-за "устаревших" дубликатов, которые порождают новые соединения (здесь автор имеет ввиду "устаревшие" дубликаты SYN-пакетов, прим. перев.). И третья проблема — "устаревшие" дубликаты могут "проникнуть" в недавно созданное соединение и ошибочно уничтожить его.

Согласно упомянутому RFC существуют три возможных решения, однако, одно из них решает эту проблему лишь частично, другие требуют внесения значительных изменений в протокол TCP.