https lingering TIME_WAIT connections

From my client PC I'm connecting to a webserver, it uses HTTPS only.

When I connect I see in TCPView (sysinternals tool alternative to netstat) a lot of TIME_WAIT connections to the https endpoint. Lots of the time I see 11 connections lingering for 2 minutes in TIME_WAIT. And that's each time I do a request. 2-4 connections stay open in ESTABLISHED for however long I set the server's Keep-Alive: timeout=xx

The latter connections are OK, and they are reused appropriately. The former connections build up and take the full 2 minutes.

I captured the traffic with WireShark, and saw the normal FIN, ACK etc passby on the lingering connection's source ports. I saw frequently that Chrome and IE (they both use Windows HTTP stack), issue 6 TCP requests before any request with real data comes along. The payload is small (about 2000 bytes).

Firefox doesn't issue these requests at all...

It's also worth to mention that the certificate is self-signed, and doesn't verify in the browser (Firefox has a totally different way to handle this than chrome).

Why does my browser issue these requests? Why doesn't Firefox issue these tcp connections?

EDIT, this a dump from the first connection Chrome makes (captured with 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"

This is completely normal.

Each new request your browser makes to the web server is a TCP connection which will use a new socket.

After the handshake, data transfer, and graceful close, sockets will sit in TIME_WAIT until the kernel's timer expires.

The TIME_WAIT timer is defined in the TCP RFC (RFC 793) as 2x the Maximum Segment Lifetime. The MSL is arbitrarily defined as 2 minutes.

Depending on the implementation of TCP in the operating system, this timer may or may not be adhered to. For example, older BSDs varied TIME_WAIT between 1 minute and 4 minutes.

https://www.rfc-editor.org/rfc/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/

https lingering TIME_WAIT connections

Related

Recent Posts