Tcp长连接和keepalive

长连接与短连接

TCP 本身并没有长短连接的区别 ,长短与否,完全取决于我们怎么用它。

  • 短连接:每次通信时,创建 Socket;一次通信结束,调用 socket.close()。这就是一般意义上的短连接,短连接的好处是管理起来比较简单,存在的连接都是可用的连接,不需要额外的控制手段。
  • 长连接:每次通信完毕后,不会关闭连接,这样可以做到连接的复用。 长连接的好处是省去了创建连接的耗时。

短连接和长连接的优势,分别是对方的劣势。想要图简单,不追求高性能,使用短连接合适,这样我们就不需要操心连接状态的管理;想要追求性能,使用长连接,我们就需要担心各种问题:比如 端对端连接的维护,连接的保活 。

长连接还常常被用来做数据的推送,我们大多数时候对通信的认知还是 request/response 模型,但 TCP 双工通信的性质决定了它还可以被用来做双向通信。在长连接之下,可以很方便的实现 push 模型。

服务治理框架中的长连接

追求性能时,必然会选择使用长连接,所以借助 Dubbo 可以很好的来理解 TCP。我们开启两个 Dubbo 应用,一个 server 负责监听本地 20880 端口,一个 client 负责循环发送请求。执行 lsof -i:20880 命令可以查看端口的相关使用情况:


image.png
  • *:20880 (LISTEN) 说明了 Dubbo 正在监听本地的 20880 端口,处理发送到本地 20880 端口的请求
  • 后两条信息说明请求的发送情况,验证了 TCP 是一个双向的通信过程,由于我是在同一个机器开启了两个 Dubbo 应用,所以你能够看到是本地的 53078 端口与 20880 端口在通信。我们并没有手动设置 53078 这个客户端端口,它是随机的。通过这两条信息,阐释了一个事实: 即使是发送请求的一方,也需要占用一个端口 。
  • 稍微说一下 FD 这个参数,他代表了 文件句柄 ,每新增一条连接都会占用新的文件句柄,如果你在使用 TCP 通信的过程中出现了 open too many files 的异常,那就应该检查一下,你是不是创建了太多连接,而没有关闭。
长连接的维护

因为客户端请求的服务可能分布在多个服务器上,客户端自然需要跟对端创建多条长连接,我们遇到的第一个问题就是如何维护长连接。

// 客户端
public class NettyHandler extends SimpleChannelHandler {

    private final Map<String, Channel> channels = new ConcurrentHashMap<String, Channel>(); // <ip:port, channel>
}
// 服务端
public class NettyServer extends AbstractServer implements Server {
    private Map<String, Channel> channels; // <ip:port, channel>
}

客户端和服务端都使用 ip:port 维护了端对端的长连接,Channel 便是对连接的抽象.

解释下为什么我认为客户端的连接集合要重要一点。TCP 是一个双向通信的协议,任一方都可以是发送者,接受者,那为什么还抽象了 Client 和 Server 呢?因为 建立连接这件事就跟谈念爱一样,必须要有主动的一方,你主动我们就会有故事 。Client 可以理解为主动建立连接的一方,实际上两端的地位可以理解为是对等的。

连接的保活

为什么需要连接的保活?当双方已经建立了连接,但因为网络问题,链路不通,这样长连接就不能使用了。需要明确的一点是,通过 netstat,lsof 等指令查看到连接的状态处于 ESTABLISHED 状态并不是一件非常靠谱的事,因为连接可能已死,但没有被系统感知到,更不用提假死这种疑难杂症了

连接的保活:KeepAlive

首先想到的是 TCP 中的 KeepAlive 机制。KeepAlive 并不是 TCP 协议的一部分,但是大多数操作系统都实现了这个机制(所以需要在操作系统层面设置 KeepAlive 的相关参数)。KeepAlive 机制开启后,在一定时间内(一般时间为 7200s,参数 tcp_keepalive_time)在链路上没有数据传送的情况下,TCP 层将发送相应的 KeepAlive 探针以确定连接可用性,探测失败后重试 10(参数 tcp_keepalive_probes)次,每次间隔时间 75s(参数 tcp_keepalive_intvl),所有探测失败后,才认为当前连接已经不可用。

在 Netty 中开启 KeepAlive:

bootstrap.option(ChannelOption.SO_KEEPALIVE, true)

Linux 操作系统中设置 KeepAlive 相关参数,修改 /etc/sysctl.conf 文件:

net.ipv4.tcp_keepalive_time=90
net.ipv4.tcp_keepalive_intvl=15
net.ipv4.tcp_keepalive_probes=2

KeepAlive 机制是在网络层面保证了连接的可用性 ,但站在应用框架层面我们认为这还不够。主要体现在三个方面:

  • KeepAlive 的开关是在应用层开启的,但是具体参数(如重试测试,重试间隔时间)的设置却是操作系统级别的,位于操作系统的 /etc/sysctl.conf 配置中,这对于应用来说不够灵活。
  • KeepAlive 的保活机制只在链路空闲的情况下才会起到作用,假如此时有数据发送,且物理链路已经不通,操作系统这边的链路状态还是 ESTABLISHED,这时会发生什么?自然会走 TCP 重传机制,要知道默认的 TCP 超时重传,指数退避算法也是一个相当长的过程。
  • KeepAlive 本身是面向网络的,并不面向于应用,当连接不可用,可能是由于应用本身的 GC 频繁,系统 load 高等情况,但网络仍然是通的,此时,应用已经失去了活性,连接应该被认为是不可用的。

我们已经为应用层面的连接保活做了足够的铺垫,下面就来一起看看,怎么在应用层做连接保活。
连接的保活:应用层心跳

网络层面的 KeepAlive 不足以支撑应用级别的连接可用性,现在就来聊聊应用层的心跳机制是实现连接保活的。

如何理解应用层的心跳?简单来说,就是客户端会开启一个定时任务,定时对已经建立连接的对端应用发送请求(这里的请求是特殊的心跳请求),服务端则需要特殊处理该请求,返回响应。如果心跳持续多次没有收到响应,客户端会认为连接不可用,主动断开连接。不同的服务治理框架对心跳,建连,断连,拉黑的机制有不同的策略,但大多数的服务治理框架都会在应用层做心跳,Dubbo/HSF 也不例外。

应用层心跳的设计细节

以 Dubbo 为例,支持应用层的心跳,客户端和服务端都会开启一个 HeartBeatTask,客户端在 HeaderExchangeClient 中开启,服务端将在 HeaderExchangeServer 开启.
文章开头埋了一个坑:Dubbo 为什么在服务端同时维护 Map<String,Channel> 呢?主要就是为了给心跳做贡献,心跳定时任务在发现连接不可用时,会根据当前是客户端还是服务端走不同的分支,客户端发现不可用,是重连;服务端发现不可用,是直接 close。

// HeartBeatTask
if (channel instanceof Client) {
    ((Client) channel).reconnect();
} else {
    channel.close();
}

注意和 HTTP 的 KeepAlive 区别对待

HTTP 协议的 KeepAlive 意图在于连接复用,同一个连接上串行方式传递请求 - 响应数据
TCP 的 KeepAlive 机制意图在于保活、心跳,检测连接错误。
这压根是两个概念。

KeepAlive 常见错误
启用 TCP KeepAlive 的应用程序,一般可以捕获到下面几种类型错误

  1. ETIMEOUT 超时错误,在发送一个探测保护包经过 (tcp_keepalive_time + tcp_keepalive_intvl * tcp_keepalive_probes) 时间后仍然没有接收到 ACK 确认情况下触发的异常,套接字被关闭
java.io.IOException: Connection timed out

  1. 链接被重置,终端可能崩溃死机重启之后,接收到来自服务器的报文,然物是人非,前朝往事,只能报以无奈重置宣告之。
java.io.IOException: Connection reset by peer

有三种使用 KeepAlive 的实践方案:

  • 默认情况下使用 KeepAlive 周期为 2 个小时,如不选择更改,属于误用范畴,造成资源浪费:内核会为每一个连接都打开一个保活计时器,N 个连接会打开 N 个保活计时器,优势很明显:
  1. TCP 协议层面保活探测机制,系统内核完全替上层应用自动给做好了
  2. 内核层面计时器相比上层应用,更为高效
  3. 上层应用只需要处理数据收发、连接异常通知即可
  4. 数据包将更为紧凑
  • 关闭 TCP 的 KeepAlive,完全使用应用层心跳保活机制。由应用掌管心跳,更灵活可控,比如可以在应用级别设置心跳周期,适配私有协议。
  • 业务心跳 + TCP KeepAlive 一起使用,互相作为补充,但 TCP 保活探测周期和应用的心跳周期要协调,以互补方可,不能够差距过大,否则将达不到设想的效果。
    各个框架的设计都有所不同,例如 Dubbo 使用的是方案三.

http长连接

一次http请求,谁会先断开TCP连接?

我们有2台内部http服务(nginx)

201:这台服务器部署的服务是account.api.91160.com,这个服务是供前端页面调用;
202:这台服务器部署的服务是hdbs.api.91160.com, 这个服务是供前端页面调用;

近期发现,这2台服务器的网络连接中,TIME_WAIT 数量差别很大,201的TIME_WAIT大概20000+,202的TIME_WAIT大概1000 ,差距20倍;2台的请求量差不多,都是以上内部调用的连接,且服务模式也没有什么差异,为什么连接数会差这么大?

是因为这2个模块的调用程序由不同团队写的,调用方式不一样,导致一个是调用方(客户端,PHP程序)主动断开连接,一个是被调用方(服务端 201、202)主动断开连接;因TIME_WAIT 产生在主动断开连接的一方,因此导致一台服务器TIME_WAIT 数高,一台TIME_WAIT 数低;

这就有个细节,一次http请求,谁会先断开TCP连接?什么情况下客户端先断,什么情况下服务端先断?

主要有http1.0和http1.1之间保持连接的差异以及http头中connection、content-length、Transfer-encoding等参数有关;在nginx中,对于http1.0与http1.1也是支持长连接的。什么是长连接呢?我们知道,http请求是基于TCP协议之上的,那么,当客户端在发起请求前,需要先与服务端建立TCP连接,而每一次的TCP连接是需要三次握手来确定的,如果客户端与服务端之间网络差一点,这三次交互消费的时间会比较多,而且三次交互也会带来网络流量。当然,当连接断开后,也会有四次的交互,当然对用户体验来说就不重要了。

而http请求是请求应答式的,如果我们能知道每个请求头与响应体的长度,那么我们是可以在一个连接上面执行多个请求的,这就是所谓的长连接,但前提条件是我们先得确定请求头与响应体的长度。对于请求来说,如果当前请求需要有body,如POST请求,那么nginx就需要客户端在请求头中指定content-length来表明body的大小,否则返回400错误。也就是说,请求体的长度是确定的,那么响应体的长度呢?先来看看http协议中关于响应body长度的确定

  1. 对于http1.0协议来说,如果响应头中有content-length头,则以content-length的长度就可以知道body的长度了,客户端在接收body时,就可以依照这个长度来接收数据,接收完后,就表示这个请求完成了。而如果没有content-length头,则客户端会一直接收数据,直到服务端主动断开连接,才表示body接收完了。

2.而对于http1.1协议来说,如果响应头中的Transfer-encoding为chunked传输,则表示body是流式输出,body会被分成多个块,每块的开始会标识出当前块的长度,此时,body不需要通过长度来指定。如果是非chunked传输,而且有content-length,则按照content-length来接收数据。否则,如果是非chunked,并且没有content-length,则客户端接收数据,直到服务端主动断开连接。

从上面,我们可以看到,除了http1.0不带content-length以及http1.1非chunked不带content-length外,body的长度是可知的。此时,当服务端在输出完body之后,会可以考虑使用长连接。能否使用长连接,也是有条件限制的。如果客户端的请求头中的connection为close,则表示客户端需要关掉长连接,如果为keep-alive,则客户端需要打开长连接,如果客户端的请求中没有connection这个头,那么根据协议,如果是http1.0,则默认为close,如果是http1.1,则默认为keep-alive。如果结果为keepalive,那么,nginx在输出完响应体后,会设置当前连接的keepalive属性,然后等待客户端下一次请求。当然,nginx不可能一直等待下去,如果客户端一直不发数据过来,岂不是一直占用这个连接?所以当nginx设置了keepalive等待下一次的请求时,同时也会设置一个最大等待时间,这个时间是通过选项keepalive_timeout来配置的,如果配置为0,则表示关掉keepalive,此时,http版本无论是1.1还是1.0,客户端的connection不管是close还是keepalive,都会强制为close。

如果服务端最后的决定是keepalive打开,那么在响应的http头里面,也会包含有connection头域,其值是”Keep-Alive”,否则就是”Close”。如果connection值为close,那么在nginx响应完数据后,会主动关掉连接。所以,对于请求量比较大的nginx来说,关掉keepalive最后会产生比较多的time-wait状态的socket。一般来说,当客户端的一次访问,需要多次访问同一个server时,打开keepalive的优势非常大,比如图片服务器,通常一个网页会包含很多个图片。打开keepalive也会大量减少time-wait的数量。

http1.0
带content-length,body长度可知,客户端在接收body时,就可以依据这个长度来接受数据。接受完毕后,就表示这个请求完毕了。客户端主动调用close进入四次挥手。

不带content-length ,body长度不可知,客户端一直接受数据,直到服务端主动断开

http1.1
带content-length body长度可知 客户端主动断开

带Transfer-encoding:chunked body会被分成多个块,每块的开始会标识出当前块的长度,body就不需要通过content-length来指定了。但依然可以知道body的长度 客户端主动断开

不带Transfer-encoding:chunked且不带content-length 客户端接收数据,直到服务端主动断开连接。

如果能够有办法知道服务器传来的长度,都是客户端首先断开。如果不知道就一直接收数据。直到服务端断开

推荐阅读更多精彩内容