Управление приложениями повторной передачи TCP в Linux

Для нетерпеливых:

Как изменить значение /proc/sys/net/ipv4/tcp_retries2 для одного соединения в Linux, используя setsockopt(), ioctl() или такое, или это возможно?

Более длинное описание:

Я разрабатываю приложение, которое использует длинные запросы HTTP-запросов. На стороне сервера это должно быть известно, когда клиент закрыл соединение. Точность не является критичной, но она, конечно, не может быть 15 минут. Ближе к минуте все будет хорошо.

Для тех, кто не знаком с этой концепцией, запрос HTTP с длительным опросом работает следующим образом:

• Клиент отправляет запрос
• Сервер отвечает HTTP-заголовками, но оставляет ответ открытым. Используется кодирование с канальной передачей, позволяющее серверу отправлять биты данных по мере их появления.
• Когда все данные отправляются, сервер отправляет "закрывающий блок", чтобы сигнализировать, что ответ завершен.

В моем приложении сервер отправляет "сердцебиение" клиенту каждый раз (30 секунд по умолчанию). Сердцебиение - это символ новой строки, который отправляется как ответный кусок. Это означает, что линия занята так, чтобы мы сообщали о потере соединения.

Нет проблем, когда клиент будет отключен правильно. Но когда он отключается с усилием (например, клиентская машина теряет мощность), TCP reset не отправляется. В этом случае сервер отправляет пульс, который клиент не делает ACK. После этого сервер продолжает ретранслировать пакет примерно через 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 (пункт e). Это не так хорошо, как установка R2, хотя, как мне кажется, R1 попадает довольно быстро (через несколько секунд), а значение R1 не может быть установлено для каждого соединения, или, по крайней мере, t требуется.

Ответы

int name[] = {CTL_NET, NET_IPV4, NET_IPV4_TCP_RETRIES2};
long value = 0;
size_t size = sizeof(value);
if(!sysctl(name, sizeof(name)/sizeof(name[0]), &value, &size, NULL, 0) {
  value // It contains current value from /proc/sys/net/ipv4/tcp_retries2
}
value = ... // Change value if it needed
if(!sysctl(name, sizeof(name)/sizeof(name[0]), NULL, NULL, &value, size) {
  // Value in /proc/sys/net/ipv4/tcp_retries2 changed successfully
}