Question about chrome RST behavior when conducting a https connection

[Johnson Li]

Hello, 

I am inspecting chrome's behavior when connecting to a web server via https, and got puzzled on chrome's RST behavior. 

The following snapshot contains almost all traffic of this experiment(the https server port is 8443). As can be seen, chrome sends RST package TWO times during the experiment. Since the network is localhost and I can reproduce the result easily, it should not be a network problem. Then what's the cause of this phenomenon?

My chrome version is  53.0.2785.101 (64-bit), macOS

My web server(httpd) version is  Apache/2.4.23 (Unix), installed by homebrew, and config file is the default extra/httpd-ssl.conf. So the web server only simply returns It works! as response.

[Matt Menke]

Looks like SO_LINGER=0 is set on Chrome's socket.  We normally don't do this, at least for standard HTTPS connections (some Chrome subcomponents may, like for WebRTC connections or somesuch).  Normally, sockets are kept alive some time after they're closed so the system still knows how to handle messages, and a new socket doesn't try and reuse the port.  I don't suppose you've fooled with your system's TCP settings?

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/bda3e370-fa76-4dd5-a015-281b5df80ce2%40chromium.org.

[Johnson Li]

Sorry I did not state my question clearly. 

From https://ask.wireshark.org/questions/13986/why-tcp-reset-sent-after-receive-finack-packet, it says that receiver may RST a connection after receiving a FIN package. And I suppose it's what you mean. This explains the RST package perfectly, but I am more curious about why chrome sends a FIN package to close the connection(package No. 11).

It seems chrome tried 3 times to open my web page(https://localhost:8443/), I don't know why chrome failed in the first 2 attempts, either why it succeeds at the 3rd time. Since it's a simple https request, I suppose only 1 tcp connection is sufficient and theie should be no FIN package until all application data is sent.

On Sunday, September 11, 2016 at 8:03:00 PM UTC+8, Matt Menke wrote:

Looks like SO_LINGER=0 is set on Chrome's socket.  We normally don't do this, at least for standard HTTPS connections (some Chrome subcomponents may, like for WebRTC connections or somesuch).  Normally, sockets are kept alive some time after they're closed so the system still knows how to handle messages, and a new socket doesn't try and reuse the port.  I don't suppose you've fooled with your system's TCP settings?

On Sun, Sep 11, 2016 at 5:44 AM, Johnson Li <johnso...@gmail.com> wrote:

Hello, 

I am inspecting chrome's behavior when connecting to a web server via https, and got puzzled on chrome's RST behavior. 

The following snapshot contains almost all traffic of this experiment(the https server port is 8443). As can be seen, chrome sends RST package TWO times during the experiment. Since the network is localhost and I can reproduce the result easily, it should not be a network problem. Then what's the cause of this phenomenon?

My chrome version is  53.0.2785.101 (64-bit), macOS

My web server(httpd) version is  Apache/2.4.23 (Unix), installed by homebrew, and config file is the default extra/httpd-ssl.conf. So the web server only simply returns It works! as response.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

[Matt Menke]

Since you're running the server on localhost, I assume you're clicking through Chrome's self-signed cert error page?  That path is not optimized, so will go through extra handshakes.  Http in general is generally consumer sends a request request-> server sends a response, with the cert error case, it's consumer tries to send a request -> request is not sent, since we get an error setting up a socket -> display error to user -> user overrides the error -> we *really* send the request over an unsafe socket -> server sends response.  Reusing the original socket through all that would add a bit more complexity than we care to add (And we can't just shove the bad socket back into the socket pool, until the user has chosen to ignore the cert error), so we throw away the original socket when we return the cert error.

There are a number of reasons two connections might fail (A second preconnected socket also sees the cert error, the first socket is actually a preconnect, and fails before the real request reaches the network stack, or some other fun race to the socket pool between multiple requests to the bad server).

Anyhow, the self-signed cert isn't something that Chrome is optimized for, or something that we're going to add extra complexity to improve the performance of.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

To post to this group, send email to net...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/2aaabee1-9533-4a8f-9360-1205166bd94b%40chromium.org.

[Johnson Li]

Oh, I did think about the problem of cert, thanks for your help.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/2aaabee1-9533-4a8f-9360-1205166bd94b%40chromium.org.