Для нетерпеливых:
Как изменить значение /proc/sys/net/ipv4/tcp_retries2 для одного подключения в Linux, используя setsockopt(), ioctl() или подобное, или это возможно?
Более длинное описание:
Я занимаюсь разработкой приложения, которое использует длинные запросы HTTP-запроса.На стороне сервера необходимо знать, когда клиент закрыл соединение.Точность не критична, но она не может быть 15 минут.Ближе к минуте все будет в порядке.
Для тех, кто не знаком с этой концепцией, длинный HTTP-запрос на опрос работает так:
- Клиент отправляет запрос
- Сервер отвечает HTTP-заголовками, но оставляет ответ открытым.Используется кодирование передачи по частям, позволяющее серверу отправлять биты данных, когда они становятся доступными.
- Когда все данные отправляются, сервер отправляет «закрывающий фрагмент», чтобы сообщить о завершении ответа.
В моем приложении сервер посылает «пульс» клиенту время от времени (по умолчанию 30 секунд).Сердцебиение - это просто символ новой строки, который отправляется как блок ответа.Это означает, что линия должна быть занята, чтобы мы сообщали о потере соединения.
Нет проблем, когда клиент правильно выключается.Но когда он принудительно выключается (например, клиентский компьютер теряет питание), сброс TCP не отправляется.В этом случае сервер отправляет сердцебиение, которое клиент не подтверждает.После этого сервер продолжает повторную передачу пакета в течение примерно 15 минут после отказа и сообщения о сбое на прикладной уровень (наш HTTP-сервер).И 15 минут - это слишком долго в моем случае.
Я могу контролировать время повторной передачи, записав следующие файлы в /proc/sys/net/ipv4/:
tcp_retries1 - INTEGER
This value influences the time, after which TCP decides, that
something is wrong due to unacknowledged RTO retransmissions,
and reports this suspicion to the network layer.
See tcp_retries2 for more details.
RFC 1122 recommends at least 3 retransmissions, which is the
default.
tcp_retries2 - INTEGER
This value influences the timeout of an alive TCP connection,
when RTO retransmissions remain unacknowledged.
Given a value of N, a hypothetical TCP connection following
exponential backoff with an initial RTO of TCP_RTO_MIN would
retransmit N times before killing the connection at the (N+1)th RTO.
The default value of 15 yields a hypothetical timeout of 924.6
seconds and is a lower bound for the effective timeout.
TCP will effectively time out at the first RTO which exceeds the
hypothetical timeout.
RFC 1122 recommends at least 100 seconds for the timeout,
which corresponds to a value of at least 8.
Значение по умолчанию tcp_retries2 действительно 8, и мой опыт 15 минут (900 секунд) повторной передачи соответствует приведенной выше документации ядра.
Если я, например, изменю значение tcp_retries2 на 5, соединение прекратитсянамного быстрееНо его установка влияет на все соединения в системе, и я бы очень хотел установить его только для этого длинного опрашивающего соединения.
Цитата из RFC 1122:
4.2.3.5 TCP Connection Failures
Excessive retransmission of the same segment by TCP
indicates some failure of the remote host or the Internet
path. This failure may be of short or long duration. The
following procedure MUST be used to handle excessive
retransmissions of data segments [IP:11]:
(a) There are two thresholds R1 and R2 measuring the amount
of retransmission that has occurred for the same
segment. R1 and R2 might be measured in time units or
as a count of retransmissions.
(b) When the number of transmissions of the same segment
reaches or exceeds threshold R1, pass negative advice
(see Section 3.3.1.4) to the IP layer, to trigger
dead-gateway diagnosis.
(c) When the number of transmissions of the same segment
reaches a threshold R2 greater than R1, close the
connection.
(d) An application MUST be able to set the value for R2 for
a particular connection. For example, an interactive
application might set R2 to "infinity," giving the user
control over when to disconnect.
(e) TCP SHOULD inform the application of the delivery
problem (unless such information has been disabled by
the application; see Section 4.2.4.1), when R1 is
reached and before R2. This will allow a remote login
(User Telnet) application program to inform the user,
for example.
Мне кажется, что tcp_retries1 и tcp_retries2 в Linux соответствуют R1 и R2 в RFC.RFC четко заявляет (в пункте d), что соответствующая реализация ДОЛЖНА позволять устанавливать значение R2, но я не нашел способа сделать это, используя setsockopt(), ioctl() или подобное.
Другойопция будет заключаться в получении уведомления при превышении R1 (элемент е).Это не так хорошо, как установка R2, хотя, как я думаю, R1 будет нажата довольно скоро (через несколько секунд), и значение R1 не может быть установлено для каждого соединения, или, по крайней мере, RFC не 'это не требуется.