Установка времени ожидания TCP

Question

Установка времени ожидания TCP

мы пытаемся настроить приложение, которое принимает сообщения через TCP, а также использует TCP для некоторых своих внутренних сообщений. Во время нагрузочного тестирования мы заметили, что время отклика значительно сокращается (а затем и вовсе останавливается), поскольку в систему поступает больше одновременных запросов. За это время мы видим много TCP-соединений в TIME_WAIT статус и кто-то предложил понижение TIME_WAIT переменная окружения по умолчанию от 60 секунд до 30.

С что я поймите на TIME_WAIT настройка по существу устанавливает время, когда ресурс TCP снова становится доступным для системы после закрытия соединения.

Я не "сетевой парень" и знаю очень мало об этих вещах. Мне нужно много того, что находится в этом связанном сообщении, но немного "приглушено".

Я думаю, что понимаю, почему TIME_WAIT значение не может быть установлено в 0, но может ли оно быть безопасно установлено в 5? Как насчет 10? Что определяет "безопасную" настройку для этого ценность?

почему по умолчанию значение 60? Я предполагаю, что люди намного умнее меня имели веские причины для выбора этого в качестве разумного дефолта.

что еще я должен знать о потенциальных рисках и преимуществах переопределения этого значения?

1589 7

tcp network-protocols

7 ответов:

Comments

Ничего не найдено.

paxdiablo · Accepted Answer · 2013-06-14 04:43:35

TCP-соединение определяется кортежем (IP-адрес источника, порт источника, IP назначения, порт назначения).

причина, по которой существует состояние TIME_WAIT после завершения сеанса, заключается в том, что в сети все еще могут быть живые пакеты на пути к вам (или от вас, которые могут потребовать ответа какого-либо рода). Если бы вы воссоздали тот же кортеж и один из этих пакетов появился, он будет рассматриваться как допустимый пакет для вашего соединения (и, вероятно, вызовет ошибка из-за секвенирования).

таким образом, время TIME_WAIT обычно устанавливается для удвоения максимального возраста пакетов. Это значение является максимальным возрастом, до которого ваши пакеты будут разрешены, прежде чем сеть отбросит их.

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

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

Len Holgate · Accepted Answer · 2011-06-24 20:36:49

обычно только конечная точка, которая выдает "активное закрытие", должна перейти в состояние TIME_WAIT. Поэтому, если это возможно, ваши клиенты выдают активное закрытие, которое оставит TIME_WAIT на клиенте, а не на сервере.

смотрите здесь: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html и http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/ для деталей (позже также объясняется, почему это не всегда возможно из-за дизайна протокола, который не учитывает TIME_WAIT).

Darron · Accepted Answer · 2008-12-03 16:05:28

Pax правильно о причинах TIME_WAIT, и почему вы должны быть осторожны о снижении настройки по умолчанию.

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

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

Synetech · Accepted Answer · 2016-05-11 02:07:59

в Windows, вы можете изменить это в реестре:
; Set the TIME_WAIT delay to 30 seconds (0x1E)

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters]
"TcpTimedWaitDelay"=dword:0000001E

andrew glynn · Accepted Answer · 2016-06-02 22:38:10

установка tcp_reuse более полезна, чем изменение time_wait, если у вас есть параметр (ядра 3.2 и выше, к сожалению, который дисквалифицирует все версии RHEL и XenServer).

удаление значения, особенно для пользователей, подключенных к VPN, может привести к постоянному восстановлению прокси-туннелей на исходящем соединении. С конфигурацией Netscaler (XenServer) по умолчанию, которая ниже, чем конфигурация Linux по умолчанию, Chrome иногда придется воссоздавать прокси туннель до десяти раз, чтобы получить одну веб-страницу. Приложения, которые не повторяются, такие как Maven и Eclipse P2, просто терпят неудачу.

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

Michael Taylor · Accepted Answer · 2016-04-28 09:54:48

Я тестировал серверное приложение (на linux) с помощью тестовой программы с 20 потоками.

в 959 000 циклов подключения / закрытия у меня было 44 000 неудачных соединений и много тысяч сокетов в TIME_WAIT.

Я установил SO_LINGER в 0 перед закрытием вызова и в последующих запусках тестовой программы не было сбоев подключения и менее 20 сокетов в TIME_WAIT.

yogman · Accepted Answer · 2008-12-03 20:04:41

TIME_WAIT не может быть виновником.
int listen(int sockfd, int backlog);
согласно Unix Network Programming Volume1, backlog определяется как сумма завершенной очереди подключения и неполной очереди подключения.

допустим, отставание составляет 5. Если у вас есть 3 завершенных соединения (установленное состояние) и 2 неполных соединения (состояние SYN_RCVD), и есть еще один запрос на соединение с SYN. Стек TCP просто игнорирует пакет SYN, зная, что он будет повторно передан другим время. Это может быть причиной деградации.

по крайней мере, это то, что я читал. ;)