connection

A transport layer virtual circuit established between two {1945} application programs for the purpose of communication.

接続

2つの応用プログラム間の通信目的で確立される転送層仮想回路。

After the connection is idle for one minute, Internet Explorer resets the connection.

Internet Explorer imposes a time-out limit for the server to return data. By default, the time-out limit is as follows:

Internet Explorer 4.0 and Internet Explorer 4.01 5 minutes

Internet Explorer 5.x and Internet Explorer 6.x 60 minutes

Internet Explorer 7 and Internet Explorer 8 60 minutes

Opera 11.11 – 120 seconds

Chrome 13 – at least 300 seconds (server closed after 300 second timeout)

IE 9 – 60 seconds (changeable in the registry, appears to apply to IE 8/9 as well though the page only mentions IE 5/6/7)

Firefox 4 – 115 seconds (changeable in about:config with network.http.keep-alive.timeout preference)

Interestingly one of the other things I noticed while doing this test with Wireshark is that after 45 seconds, Chrome would send a TCP keep-alive packet, and would keep doing that every 45 seconds until the 5 minute timeout. No other browser would do this.

Windows 7 delays acks very aggressively for up to 200ms. If the server is using the Nagle algorithm, it won't send new messages until the acks arrive (or the send buffer fills).

Any decent WebSocket server should have Nagle disabled, which is why we haven't seen this until now.

Fortunately (?) pywebsocket in standalone mode does not disable the Nagle algorithm, and so I was able to reproduce quite easily. I then used Wireshark to confirm that the issue was happening at the TCP/IP level.

The best fix is to disable Nagle on the server. This will avoid other, more subtle, problems that the Nagle algorithm can cause.

手元の次環境で、SleepするだけのCGIにリクエストした所、ともに受信タイムアウトは60分ちょうどでした。

Win8 & IE10

Win7 & IE9

HTTPレスポンス受信に無通信のまま60分経つと、IE側から切断していました。(最初の受信データかによらず)

レジストリにタイムアウト値(ReceiveTimeout)は設定していません。

# 「切断する」とは、FINパケットを先にどちらが送出したかで確認を行いました。

 

上記リンク先のIE9が5分後にリクエストをリトライする事象は、

最初、私もこれに引っかかってしまいましたが、

サーバにApache2.2をデフォルト設定のままで使用していると発生すると思います。

CGIがいつまでも応答がない場合に、Apacheがコネクションを切断してしまうためでした。(Timeoutの第3項も参照)

このときIE側からは、すぐに別コネクションで接続が行われ、同一のリクエストを送信していました。

(よーするに、1TCPコネクション内の再送ではなく、アプリレベルの再送)

設定変更すると5分以上経ってもIEは受信し続けてくれました。

In the first, a thoughtful web developer or operations team reasons: “Hey, HTTPS connections are expensive to maintain on the server. Let’s be sure to tear those down as soon as possible to free up the server to accept new connections.”  That, of course, completely misses the point that if the server wasn’t tearing down the connections, the server would be under significantly lighter load to begin with! Sites that were deliberately written with this bad pattern load slowly in all browsers.

We also found another root cause—ancient advice for the configuration of Apache+OpenSSL. Prior to IE6, ancient and unpatched versions of IE sometimes encountered connection failures when interacting with HTTPS servers when Keep-Alive is used. That problem was fixed nearly a decade ago, but outdated 1999-era configuration advice continues to harm performance for unaware server administrators:

// Disable TCP Keepalives - use SPDY ping instead.

rv = DisableTCPKeepalives();

- do not recurse on POST requests, as per HTTP/1.[01] (this might

change as the recommendation isn't followed by anybody else).

--http2-prior-knowledge

(HTTP) Tells curl to issue its non-TLS HTTP requests using HTTP/2 without HTTP/1.1 Upgrade. It requires prior knowledge that the server supports HTTP/2 straight away. HTTPS requests will still do HTTP/2 the standard way with negotiated protocol version in the TLS handshake.

--keepalive-time <seconds>

This option sets the time a connection needs to remain idle before sending keepalive probes and the time between individual keepalive probes. It is currently effective on operating systems offering the TCP_KEEPIDLE and TCP_KEEPINTVL socket options (meaning Linux, recent AIX, HP-UX and more). This option has no effect if --no-keepalive is used. (Added in 7.18.0)

--unix-socket <path>

(HTTP) Connect through this Unix domain socket, instead of using the network. (Added in 7.40.0)

IE8: The Performance Implications

March 7, 2008 on 1:25 am | In ajax | No Comments

Mix08 is here, and with it the first beta of IE8. John has a great roundup of the JS/Dom work, noting that “Internet Explorer 8 is our release.” He’s right.

I’ll run through a few of the items that have particular implications for performance.

This one is the most exciting for me: the IE team has finally upped the connection limit to 6 per host from the default of 2. I’ve talked before about DNS tricks to get around the 2 connection limitation, but having this support out of the box will be a great assistance in the war on round-trip latency as it’s easier to make more expensive network calls in parallel. This is especially sweet for Comet and the like where the persistent connection could previously monopolize half of the connections to your site. As you would expect, Joe Walker of DWR is happy.

One thing I haven’t seen mentioned anywhere is the total connection limit. Previous versions supported 2 per host and 6 total. Is the new version 6 per host / 6 total or 6 per host / 18 total. I really doubt it on the latter, but if no one has the answer I’ll grab the beta this weekend and test it out.

Firefox 46 has changed the way to handle broken connections so that it will no longer automatically retry unsafe requests such as POST. However, various Web sites do not work with the new behaviour, resulting in an error page “connection to the server was reset”, because they expect the browser to retry connections even for POST requests. KanColle, a popular Japanese Flash game is known to be affected.

tcpNoDelay

If set to true, the TCP_NO_DELAY option will be set on the server socket, which improves performance under most circumstances. This is set to true by default.

socket.tcpNoDelay

(bool)same as the standard setting tcpNoDelay. Default value is false

socket.soKeepAlive

(bool)Boolean value for the socket's keep alive setting (SO_KEEPALIVE). Default is false.

socket.ooBInline

(bool)Boolean value for the socket OOBINLINE setting. Default value is true

socket.soReuseAddress

(bool)Boolean value for the sockets reuse address option (SO_REUSEADDR). Default value is true

socket.soLingerOn

(bool)Boolean value for the sockets so linger option (SO_LINGER). Default value is true. This option is paired with the soLingerTime value.

socket.soLingerTime

(bool)Value in seconds for the sockets so linger option (SO_LINGER). Default value is 25 seconds. This option is paired with the soLinger value.

socket.soTimeout

(int)Value in milliseconds for the sockets read timeout (SO_TIMEOUT). Default value is 5000 milliseconds.

socket.soTrafficClass

(byte)Value between 0 and 255 for the traffic class on the socket, 0x04 | 0x08 | 0x010

Receivers should place limits on the amount of data and time they spend fetching unverified source URLs. For example, if a source URL doesn't respond within 5 seconds, it can treat that as a failure. Similarly, the receiver can fetch only the first 1mb of the page, since any reasonable HTML or JSON page will be smaller than that.

// For backup connections, we disable IPv6. That's because some users have

// broken IPv6 connectivity (leading to very long timeouts), and disabling

// IPv6 on the backup connection gives them a much better user experience

// with dual-stack hosts, though they still pay the 250ms delay for each new

// connection. This strategy is also known as "happy eyeballs".