https lingering TIME_WAIT connections

Question

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"

What exactly is your question? If you have a question about the traffic a browser is generating, please include a sample of that traffic. But your title mentions TIME_WAIT, which is something else entirely. Please try to clarify your question, and if you have two questions, post them separately. — Michael Hampton, Oct 22 '12 at 14:23
This has to do with HTTPS, there are connections being made by the windows tcp stack which linger in TIME_WAIT (netstat). Firefox doesn't issue these requests. If it'd be easy to include a tcp-dump, I would but since it's SSL, you can't really tell... — Jaap, Oct 22 '12 at 16:11
TIME_WAIT is perfectly normal and there are about 10,000 sites which explain what it is and why it's there. — Michael Hampton, Oct 22 '12 at 16:14
I know it is, read like 0.1% of them (which is a lot!), but I'm trying to understand the difference between Firefox's tcp stack and Windows (which is shared by IE and Chrome). — Jaap, Oct 22 '12 at 16:24
And, I'm describing a behaviour I'm seeing with our server, with different websites it doesn't behave this way... — Jaap, Oct 22 '12 at 16:25
All Windows programs use the Windows IP (TCP) stack. Chrome and IE don't share anything outside of Windows API calls, their HTTP protocol stacks are independent. Chrome actually uses WebKit for it's backend, which it shares with Safari and a dozen other browsers. Similarly Firefox uses Gecko, IE uses Trident, and the list goes on. — Chris S, Oct 22 '12 at 16:33

score 3 · Answer 1 · edited Oct 07 '21 at 06:47

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.

Will this keep a socket open on the server? Or is it just a matter of resources on my local machine? — Jaap, May 14 '13 at 15:05
The TCP connection itself has been closed with a proper FIN/ACK, no more data should be transmitted or received on this socket. Once the server application calls close() on its socket, the server socket will go from CLOSE_WAIT to gone and the server will have no memory of the socket anymore. A TIME_WAIT socket will not consume a file descriptor on the client, and consumes a minimal amount of memory (only a couple of hundred bytes). — suprjami, May 15 '13 at 11:33

https lingering TIME_WAIT connections

1 Answers1