php 长连接心跳_客户端发送TCP心跳，服务器需要回吗？

问题描述

如果服务端不回心跳，客户端体验会比较差！如果回的话，单机在上百万或者千万的连接下，性能影响有多大？答案是肯定的！

没有听过单机可以支持几百万、千万的连接数的，对CPU资源的影响肯定有一些，毕竟要处理心跳以及回复心跳。

至于影响程度要看心跳的频率与连接数。如果答案就写到这，跟没写有什么区别？

也许有的读者会觉得，一句话就可以说完的问题，为何要写一篇文章？

我想说的是，在千千万万个问题选中它，说明它非常重要，以至于必须写一篇文章。

为何要有TCP Keepalive？

最早的http交易是这样的：

三次握手建立TCP连接HTTP Request/ Response 完成交易四次挥手关闭TCP连接。

TCP短连接

这是典型的TCP短连接，TCP连接的生存周期只持续了0点几、或几秒不等。

如果用户点击页面的链接，又要重复以上http交易过程。

为了打开一个新的页面，会有建立连接、关闭连接的时间开销，这些等待时间不是每个用户都可以忍受的。

TCP长连接

如果每次http交易完成时，TCP不关闭，而是保持连接状态。那么下次http交易时，依然可以使用这个TCP，效率无疑是高效的。

这个很简单，只需要应用程序提前通知TCP，自己将使用长连接即可。

长连接带来的挑战

在客户端与服务器之间，可能有一个或多个NAT设备，这些NAT设备动态维护着客户端与服务器之间的连接状态。

连接状态表，有一个老化回收机制，一段时间没有流量经过时，将会被删除。如果客户端与服务器有流量经过，会不断刷新这个定时器，从而让状态表一直赖在内存里，为流量转发服务。

假设由于没有流量穿梭，状态表消失了。当流量再次到达时，由于没有状态表，流量会被丢弃，并触发双方再次建立全新的TCP连接，并完成交易。

本来想快的，结果没快成，反而更慢了。

痛定思痛，协议设计者发明了“心跳机制”，为了周期性刷新赖在NAT设备的内存状态表，让他们一直活着。

这样，用户每打开一个新的页面，立马就可以直奔主题，完成http交易流程。

任何事物都有正反面，当给用户提供实时响应交易，必须承担“心跳机制”带来的CPU开销。

另外需要指出的是，如果连续几次没有收到对方的心跳回复，将会重置TCP连接。

由于TCP没有自身报文完整性保护措施，所以TCP的报文非常容易伪造，这其中自然包括心跳报文、ACK报文、Reset报文。

有读者会问，如何采用TLS来保护http交易，那TCP心跳报文可以伪造吗？

当然可以伪造！因为TLS的安全防护并没有覆盖TCP报文头部分。