Окончательное решение состоит в том, что RST-пакеты должны просто игнорироваться, пока сокет находится в состоянии TIME_WAIT. Вместе с установкой параметра Maximum Segment Life (MSL — максимальное время жизни сегмента) равным 2 мин. такой подход решает все три проблемы, описанные в RFC 1337.
/proc/sys/net/ipv4/tcp_sack
Разрешает Selective Acknowledgements (SACK — Выборочное Подтверждение), детальное описание вы найдете в RFC 2883 — An Extension to Selective Acknowledgement (SACK) Option for TCP и RFC 2883 — An Extension to Selective Acknowledgement (SACK) Option for TCP.
Если этот параметр включен (1), то в TCP-заголовке будет устанавливаться SACK-флаг при передаче SYN-пакета, сообщая тем самым удаленному хосту, что наша система в состоянии обрабатывать SACK, на что удаленный хост может ответить ACK-пакетом с установленным флагом SACK. Этот режим выборочно подтверждает каждый сегмент в TCP-окне. Это особенно полезно на неустойчивых соединениях, поскольку позволяет производить повторную передачу лишь отдельных, не подтвержденных фрагментов, а не всего TCP-окна, как это диктуется более старыми стандартами. Если какой либо сегмент TCP-окна был "утерян", то приемная сторона не пришлет на него SACK-подтверждение о приеме. Отправитель, поняв это, повторит передачу "потерявшихся" сегментов. Избыточные данные сохраняются в TCP-заголовке, 40 байт на сегмент. Подтверждение каждого сегмента — это два 32-битных беззнаковых целых числа, таким образом в заголовке может разместиться подтверждение 4-х сегментов. Однако, как правило, совместно с опцией SACK используется опция timestamp, которая занимает 10 байт и поэтому в одном пакете может быть подтверждено не более 3 сегментов.
Рекомендуется включать эту опцию, если вы имеете неустойчивые соединения. Однако, если вы соединены 1.5-метровым кабелем с другой машиной, то в таком случае, для достижения наивысшей скорости обмена, следует эту опцию отключить. Обычно эта опция не нужна, но лучше ее включить. Она обеспечивает 100% обратную совместимость, т.е. вы не должны испытывать никаких проблем при соединении с хостами, которые эту опцию не поддерживают.
Значение по-умолчанию — 1 (включено).
/proc/sys/net/ipv4/tcp_stdurg
Разрешает/запрещает соответствие стандарту RFC 1122. Поведение по умолчанию соответствует стандарту использования флага URG — BSD 4.2, описанному в RFC 793. Если этот параметр включен, то возможны сбои при работе с отдельными узлами Интернета, точнее — с узлами, которые придерживаются стандарта BSD 4.2. Значение по-умолчанию — 0 (выключено).
/proc/sys/net/ipv4/tcp_syn_retries
Количество попыток передачи SYN-пакета при установлении нового соединения. Это число не должно устанавливаться больше чем 255, поскольку каждая повторная попытка отнимает значительное время. На каждую попытку отводится примерно 30-40 секунд. Значение по-умолчанию — 5, что соответствует, примерно, 180 секундам.
/proc/sys/net/ipv4/tcp_synack_retries
Количество попыток передачи SYN,ACK-пакета в ответ на SYN-запрос. Другими словами — максимальное число попыток установить пассивное TCP-соединение, инициированное другим хостом. Это число не должно устанавливаться больше чем 255. Значение по-умолчанию — 5.
/proc/sys/net/ipv4/tcp_timestamps
Разрешает/запрещает использование временных меток (timestamps), в соответствии с RFC 1323. Если коротко, то это расширение TCP используется для расчета Round Trip Measurement (определение времени возврата) лучшим способом, нежели метод Retransmission timeout (RTO). Эта опция должна сохранять обратную совместимость в большинстве случаев, так что лучше оставить ее включенной, особенно если вы работаете в высокоскоростной сети (например LAN или 10mb Интернет). В случае низкоскоростного оединения (скажем модемное) – вы прекрасно обойдетесь и без этой опции, и будет даже лучше, если вы ее отключите. Значение по-умолчанию — 1 (включено).
/proc/sys/net/ipv4/tcp_tw_recycle
Разрешает/запрещает быструю утилизацию сокетов, находящихся в состоянии TIME-WAIT. Если вы не уверены в своих действиях, то вам лучше не трогать эту переменную. Значение по-умолчанию — 0.
/proc/sys/net/ipv4/tcp_window_scaling
Разрешает/запрещает масштабирование TCP-окна, как определено в RFC 1323. В этом документе описано как производится масштабирование TCP-окна при передаче по Large Fat Pipes (LFP — "толстый" канал). При передаче TCP-пакетов по "толстым" каналам возникают существенные потери пропускной способности из-за того, что они не загружены полностью во время ожидания подтверждения о приеме предыдущего TCP-окна. Основная проблема состоит в том, что окно не может иметь размер больше, чем 2**16 байт (65 Кб). Разрешая масштабирование TCP-окна мы, тем самым, можем увеличить его размер и таким образом уменьшить потери пропускной способности. Значение по-умолчанию — 1 (включено).