https verweilende TIME_WAIT-Verbindungen

Von meinem Client-PC aus verbinde ich mich mit einem Webserver. Er verwendet nur HTTPS.

Wenn ich eine Verbindung herstelle, werden in TCPView (sysinternals tool alternative zu netstat) viele TIME_WAIT-Verbindungen zum https-Endpunkt angezeigt. In TIME_WAIT sehe ich oft 11 Verbindungen, die 2 Minuten lang verweilen. Und das ist jedes Mal, wenn ich eine Anfrage mache. 2-4 Verbindungen bleiben in ESTABLISHED so lange offen, wie ich die Server eingestellt habeKeep-Alive: timeout=xx

Die letzteren Verbindungen sind in Ordnung und werden entsprechend wiederverwendet. Die früheren Verbindungen bauen sich auf und dauern die vollen 2 Minuten.

Ich habe den Datenverkehr mit WireShark erfasst und die normalen FIN-, ACK- usw. Passby-Vorgänge an den Quellports der verbleibenden Verbindung gesehen. Ich habe häufig gesehen, dass Chrome und IE (beide verwenden den Windows-HTTP-Stack) 6 TCP-Anforderungen ausgeben, bevor eine Anforderung mit echten Daten eingeht. Die Nutzlast ist klein (ca. 2000 Bytes).

Firefox gibt diese Anfragen überhaupt nicht aus ...

Es ist auch erwähnenswert, dass das Zertifikat selbstsigniert ist und nicht im Browser überprüft wird (Firefox hat eine völlig andere Art, damit umzugehen als Chrome).

Warum gibt mein Browser diese Anfragen aus? Warum gibt Firefox diese TCP-Verbindungen nicht aus?

BEARBEITEN, dies ist ein Dump von der ersten Verbindung, die Chrome herstellt (erfasst mit Wireshark):

    "https","0.000000",local-ip,dest-ip,"443","TCP","53890 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1"
    "53890","0.012749",dest-ip,local-ip,"53890","TCP","https > 53890 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1400 WS=1 SACK_PERM=1"
    "https","0.012828",local-ip,dest-ip,"443","TCP","53890 > https [ACK] Seq=1 Ack=1 Win=65792 Len=0"
    "53890","0.025979",dest-ip,local-ip,"53890","TCP","https > 53890 [ACK] Seq=1 Ack=222 Win=128578 Len=0"
    "53890","0.026099",dest-ip,local-ip,"53890","TLSv1.1","Server Hello, Certificate, Server Hello Done"
    "53890","0.038848",dest-ip,local-ip,"53890","TCP","https > 53890 [ACK] Seq=1093 Ack=436 Win=128364 Len=0"
    "53890","0.040474",dest-ip,local-ip,"53890","TLSv1.1","Change Cipher Spec, Encrypted Handshake Message"
    "https","0.041191",local-ip,dest-ip,"443","TCP","53890 > https [FIN, ACK] Seq=436 Ack=1168 Win=64512 Len=0"
    "53890","0.053312",dest-ip,local-ip,"53890","TCP","https > 53890 [ACK] Seq=1168 Ack=437 Win=128364 Len=0"
    "53890","0.053313",dest-ip,local-ip,"53890","TCP","https > 53890 [FIN, PSH, ACK] Seq=1168 Ack=437 Win=128364 Len=0"
    "https","0.053345",local-ip,dest-ip,"443","TCP","53890 > https [ACK] Seq=437 Ack=1169 Win=64512 Len=0"

Das ist völlig normal.

Jede neue Anfrage Ihres Browsers an den Webserver ist eine TCP-Verbindung, die einen neuen Socket verwendet.

Nach dem Handshake, der Datenübertragung und dem ordnungsgemäßen Schließen befinden sich die Sockets in TIME_WAIT, bis der Timer des Kernels abläuft.

Der TIME_WAIT-Timer ist im TCP-RFC (RFC 793) als 2x die maximale Segmentlebensdauer definiert. Die MSL wird willkürlich als 2 Minuten definiert.

Abhängig von der Implementierung von TCP im Betriebssystem kann dieser Timer eingehalten werden oder nicht. Beispielsweise variierten ältere BSDs TIME_WAIT zwischen 1 Minute und 4 Minuten.

• http://tools.ietf.org/html/rfc793
• http://en.wikipedia.org/wiki/Transmission_Control_Protocol
• http://en.wikipedia.org/wiki/Maximum_Segment_Lifetime
• http://www.tcpipguide.com/free/t_TCPConnectionTermination-4.htm
• http://insidethenteworks.wordpress.com/2011/11/14/after-time-wait-state-why-tcp-waits-for-2-msl-time-instead-going-to-closed-state-immediatly/