wake-up-neo.com

Anwendungssteuerung von TCP Neuübertragung unter Linux

Für die Ungeduldigen:

Wie kann der Wert von /proc/sys/net/ipv4/tcp_retries2 für eine einzelne Verbindung in Linux geändert werden, indem setsockopt(), ioctl() oder so verwendet wird oder ist dies möglich?

Längere Beschreibung:

Ich entwickle eine Anwendung, die lange HTTP-Anfragen abruft. Auf der Serverseite muss bekannt sein, wann der Client die Verbindung geschlossen hat. Die Genauigkeit ist nicht kritisch, kann aber sicherlich nicht 15 Minuten betragen. Näher an einer Minute würde es gut gehen.

Für diejenigen, die nicht mit dem Konzept vertraut sind, funktioniert eine lange HTTP-Abfrage wie folgt:

  • Der Client sendet eine Anfrage
  • Der Server antwortet mit HTTP-Headern, lässt die Antwort jedoch offen. Es wird eine verschlüsselte Übertragungskodierung verwendet, die es dem Server ermöglicht, Datenbits zu senden, sobald sie verfügbar sind.
  • Wenn alle Daten gesendet wurden, sendet der Server einen "schließenden Block", um zu signalisieren, dass die Antwort abgeschlossen ist.

In meiner Anwendung sendet der Server ab und zu "Heartbeats" an den Client (standardmäßig 30 Sekunden). Ein Heartbeat ist nur ein Newline-Charakter, der als Antwortblock gesendet wird. Dadurch soll die Leitung besetzt bleiben, damit wir den Verbindungsverlust melden.

Es gibt kein Problem, wenn der Client ordnungsgemäß heruntergefahren wird. Wenn er jedoch mit Gewalt heruntergefahren wird (zum Beispiel der Client-Rechner verliert die Stromversorgung), wird kein TCP Reset gesendet. In diesem Fall sendet der Server einen Heartbeat, den der Client nicht akzeptiert. Danach sendet der Server das Paket für etwa 15 Minuten erneut, nachdem er aufgegeben hat und den Fehler der Anwendungsebene (unserem HTTP-Server) gemeldet hat. Und 15 Minuten ist in meinem Fall zu lang.

Ich kann die Wiederholungszeit steuern, indem ich in /proc/sys/net/ipv4/ folgende Dateien schreibe:

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.

Der Standardwert von tcp_retries2 ist in der Tat 8, und meine Erfahrung von 15 Minuten (900 Sekunden) der erneuten Übertragung stimmt mit der oben zitierten Kernel-Dokumentation überein.

Wenn ich zum Beispiel den Wert von tcp_retries2 auf 5 ändere, wird die Verbindung viel schneller beendet. Wenn Sie es so einstellen, wirkt sich dies auf alle Verbindungen im System aus, und ich möchte es wirklich nur für diese eine lange Polling-Verbindung festlegen.

Ein Zitat aus 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.

Mir scheint, dass tcp_retries1 und tcp_retries2 in Linux R1 und R2 im RFC entsprechen. Der RFC gibt eindeutig an (in Punkt d), dass eine konforme Implementierung den Wert von R2 zulassen MUSS, aber ich habe keine Möglichkeit gefunden, dies mit setsockopt(), ioctl() oder einem solchen zu tun.

Eine weitere Option wäre, eine Benachrichtigung zu erhalten, wenn R1 überschritten wird (Punkt e). Dies ist nicht so gut wie das Setzen von R2, obwohl ich denke, dass R1 ziemlich schnell (in wenigen Sekunden) getroffen wird und der Wert von R1 nicht pro Verbindung festgelegt werden kann oder zumindest der RFC dies nicht erfordert.

26
Petri Lehtinen

Sieht so aus, als wäre dies in Kernel 2.6.37 hinzugefügt worden. Commit diff aus dem Kernel Git und Excerpt from change log unter;

begehen dca43c75e7e545694a9dd6288553f55c53e2a3a3 Autor: Jerry Chu Datum: Fri Aug 27 19:13:28 2010 +0000

tcp: Add TCP_USER_TIMEOUT socket option.

This patch provides a "user timeout" support as described in RFC793. The
socket option is also needed for the the local half of RFC5482 "TCP User
Timeout Option".

TCP_USER_TIMEOUT is a TCP level socket option that takes an unsigned int,
when > 0, to specify the maximum amount of time in ms that transmitted
data may remain unacknowledged before TCP will forcefully close the
corresponding connection and return ETIMEDOUT to the application. If 
0 is given, TCP will continue to use the system default.

Increasing the user timeouts allows a TCP connection to survive extended
periods without end-to-end connectivity. Decreasing the user timeouts
allows applications to "fail fast" if so desired. Otherwise it may take
upto 20 minutes with the current system defaults in a normal WAN
environment.

The socket option can be made during any state of a TCP connection, but
is only effective during the synchronized states of a connection
(ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, or LAST-ACK).
Moreover, when used with the TCP keepalive (SO_KEEPALIVE) option,
TCP_USER_TIMEOUT will overtake keepalive to determine when to close a
connection due to keepalive failure.

The option does not change in anyway when TCP retransmits a packet, nor
when a keepalive probe will be sent.

This option, like many others, will be inherited by an acceptor from its
listener.

Signed-off-by: H.K. Jerry Chu <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
24
Kimvais

Ich schlage vor, dass, wenn die von Kimvais beschriebene TCP_USER_TIMEOUT-Socket-Option verfügbar ist, Sie diese verwenden. Bei älteren Kerneln, bei denen diese Socket-Option nicht vorhanden ist, können Sie wiederholt die Variable SIOCOUTQioctl() aufrufen, um die Größe der Socket-Sendewarteschlange zu bestimmen. Wenn die Sendewarteschlange während Ihres Timeout-Zeitraums nicht abnimmt, bedeutet dies, dass keine ACKs empfangen wurden Sie können die Steckdose schließen.

13
caf

Nach einigem Nachdenken (und googeln) kam ich zu dem Schluss, dass Sie den tcp_retries1- und tcp_retries2-Wert für einen einzelnen Socket nur ändern können, wenn Sie einen Patch auf den Kernel anwenden. Ist das für Sie machbar?

Andernfalls könnten Sie die TCP_KEEPALIVE socket-Option verwenden, deren Zweck darin besteht, zu prüfen, ob eine Verbindung noch aktiv ist (es scheint mir, dass dies genau das ist, was Sie zu erreichen versuchen, also hat es Sinn). Achten Sie auf die Tatsache, dass Sie den Standardparameter etwas anpassen müssen, da die Standardeinstellung nach ca. 2 Stunden ist.

3
Simone

Dies ist für mein Verständnis. Tcp_retries2 ist die Anzahl der erneuten Übertragungen, die vom System vor dem Löschen der Verbindung zugelassen wird. Wenn also der Standardwert von tcp_retries2 mit TCP_USER_TIMEOUT geändert werden soll, wird die maximale übertragene Datenmenge angegeben kann nicht bestätigt werden, müssen wir den Wert von TCP_USER_TIMEOUT erhöhen, oder?

In diesem Fall wartet die Verbindung eine längere Zeit und überträgt das Datenpaket nicht erneut. Bitte korrigieren Sie mich, falls etwas nicht stimmt.

0
Rndp13