Sockets 为什么与http1保持活动连接相比，http2连接会立即关闭？

因为我们的浏览器游戏的服务器在宕机后很难为所有客户端提供服务（很多玩家刷新页面直到它重新工作），所以我正在尝试减少套接字连接。我们使用nginx1.10.3提供页面，并使用http1.1保持活动连接。游戏的后端也由nginx1.10.3提供，并使用htp1.1连接（没有保持活动！）。在这个设置过程中，我看到很多TCP套接字在最后关闭之前处于

TIME\u WAIT

状态。这是正确的（请参阅）

据我所知，每个大浏览器都支持http2，因此我尝试了一下。据我所知，http2重用了TCP连接，因此速度更快，因为当已经有一个与接收器的工作TCP连接时，整个握手部分被跳过（一些其他特性使http2也更快）

我使用

netstat

监视所有活动的internet连接，发现有时只与我的pc和服务器建立了一个连接。所有文件（jpg、css、html、js）都通过此连接传输。但有时我看到两个或三个连接。这是否意味着http2可能会打开多个TCP连接，但它会尝试优化它们的重用

我也等了几分钟，再次检查了

netstat

，发现只有一个TCP连接保持打开状态（所有其他连接都关闭了）。我关闭了浏览器，刷新了

netstat

，TCP连接消失了。但这不可能，对吧？连接/套接字应该仍然存在，但现在处于

TIME\u WAIT

、

FIN\u WAIT

或

CLOSED

状态。或者http2是否允许/添加极快的插座关闭机制？

根据

TCP连接可以由任一对等方关闭。结束流标志 在数据帧上，被视为等同于TCP FIN位。A. 客户端应发送设置了END_STREAM标志的数据帧 在接收到带有END_流标志的帧之后。代理人 接收设置了END_STREAM标志的数据帧并发送附加的 最后一个TCP段上设置了FIN位的数据。代理人 接收设置了FIN位的TCP段并发送数据帧 已设置结束流标志。请注意，最后的TCP段或数据帧 可能是空的

---

另请参见

5.1流状态

。所以，基本上，TCP TIME_WAIT状态没有必要，因为在更高的OSI级别上可以确保流的结束。

您阅读了吗？谢谢，为什么我自己没有想到这个。。。读一下吧，但看起来并不是每个浏览器都像RFC想要的那样，对吧？例如，我使用TCPView检查哪些套接字已打开。我使用了Chrome57和Firefox52。当我使用chrome并重新加载页面（CTRL+F5）时，套接字被重用。当我在firefox中执行此操作时，套接字将切换到

TIME\u WAIT

状态，并在特定时间后关闭。同时，一个新的套接字被打开并使用。Re“我关闭了浏览器，刷新了netstat，TCP连接消失了。但这不可能，对吗？”-当然可能。好吧，这也是可能的，也是可取的。仅仅是离开页面导航就足以让浏览器说“我不再需要那个连接了”[在链接的RFC中提到]；关闭浏览器当然就是这样一件事。