一 前言

TCP在真正开始进行数据传输之前Server 和 Client 之间必须建立一个连接。当数据传输完成后双方不再需要这个连接时就可以释放这个连接。

TCP连接的建立是通过三次握手而连接的释放是通过四次挥手。所以说每个TCP连接的建立和释放都是需要消耗资源和时间成本的。

二 TCP短连接

模拟一种TCP短连接的情况

client 向 server 发起连接请求

server 收到连接请求双方建立TCP连接

client 向 server 发送消息

server 回应 client 消息

一次读写完成此时双方任何一方都可以发起关闭连接请求即close操作。

在步骤5中一般都是 client 先发起close操作。从上面的描述来看短连接一般只会在 client 和 server 之间传递一次读写操作。

短连接的操作过程建立连接 ——> 传输数据 ——> 关闭连接。

三 TCP长连接

模拟一种长连接的情况

client 向 server 发起连接请求

server 收到连接请求双方建立TCP连接

client 向 server 发送消息

server 回应 client 消息

一次读写完成TCP连接不关闭

后续读写操作...

长时间操作之后client 发起关闭连接请求

TCP长连接是指在连接成功建立之后即使通信双方没有数据传输也要保持连接使其不断开。

长连接的操作步骤建立连接 ——> 传输数据 ——> ... (保持连接) ... ——> 传输数据 ——> 关闭连接

四 长连接和短连接的优缺点

4.1 短连接的优缺点

优点管理起来比较简单存在的连接都是有用的连接不需要额外的控制手段。

缺点由于TCP的建立和关闭操作需要一定的系统开销如果客户端连接请求频繁会降低服务器的处理速度、浪费系统资源和带宽。

4.2 长连接的优缺点

优点长连接可以省去较多的TCP连接的建立和关闭的操作减少浪费节约时间。

缺点client 与 server 之间的连接如果一直不关闭的话会存在一个问题随着客户端的连接越来越多服务器的负载压力会增大降低服务器的整体性能更严重者可能导致服务器崩溃其次如果大量处于连接状态的TCP通信双方长时间没有进行数据传输这也会浪费系统和网络资源。

相关视频推荐

Tcp/ip协议栈技术专题训练营(1)

Tcp/ip协议栈技术专题训练营(2)

100行代码实现tcp/ip协议栈自行准备好Linux系统

五 长连接/短连接的应用场景

长连接一般多用于需要频繁进行读写操作点对点通讯而且连接数不太多的情况。

例如数据库的连接通常使用长连接如果用短连接的话频繁的TCP socket创建和关闭会造成socket错误也是对资源的一种浪费。

短连接一般用于不需要频繁进行读写操作并且连接数很大的情况下。

例如web网站的http服务一般都用短连接。因为长连接对于服务器来说是要耗费一定的系统资源的像web网站服务通常会有大量的客户端连接请求并发连接量大使用短连接会更节省系统资源能够及时响应客户请求。

总结长连接和短连接的选择要具体需求、实际情况而定。

六 长连接的保活机制

对于TCP长连接当通信双方在没有数据传输的时候如何保持TCP连接一直处于“保活(KeepAlive)”状态这是一个必须要解决的问题。

在Linux系统中我们可以使用 netstat、lsof等命令可以查看TCP连接是否处于“ESTABLISHED”状态。

6.1 TCP保活的必要性

1很多防火墙会主动关闭空闲的socket。

2可能出现的非正常断连服务器并不能检测到为了回收已断连的socket资源必须提供一种检测机制。

导致TCP非正常断连的可能原因
1网络故障
2客户端/服务端一侧突然断电或者进程崩溃

6.2 保活机制的方式

6.2.1 应用层的心跳机制

在应用层中使用心跳(heartbeat)机制来主动检测。具体做法当TCP连接建立成功后客户端开启一个定时任务定时对已经建立连接的对端发送一个心跳请求消息服务器收到该心跳消息后返回一个心跳应答消息。如果在超时时间内没有收到服务器的应答消息则重发心跳请求消息如果客户端持续多次没有响应客户端则可以认为该TCP连接不可用主动断开连接。当然也可以是服务器端主动发送心跳请求消息给客户端。

6.2.2 TCP协议自带的保活机制

Linux内核自带的保活机制keep-alive。使用的时候只需要打开keep-alive功能即可。

TCP的Keepalive机制的作用是在于探测连接的对端是否存活。

工作原理TCP keep-alive是通过在空闲时发送TCP Keep-Alive数据包然后对方回应TCP Keep-Alive ACK来实现的。

在socket网络编程中需要设置一个socket选项 SO_KEEPALIVE才能开启keepalive机制。代码描述如下

keepAlive = 1;
 
setsockopt(listen_fd, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive));

在Linux的keepalive机制中有3个重要的内核参数tcp_keepalive_time、tcp_keepalive_probes 和 tcp_keepalive_intvl。

tcp_keepalive_time表示TCP连接闲置多长时间后开始发送探测报文。单位秒

tcp_keepalive_probes表示一次探测过程中最多可以重发探测报文的次数。没有收到确认时重发次数

tcp_keepalive_intvl表示前一个探测报文和后一个探测报文之间的时间间隔。即超时重传的时间间隔单位秒

这些内核参数可以在/proc/sys/net/ipv4/目录下可以看到也可以使用Linux命令查看其默认值

# sysctl -a |grep keepalivenet.ipv4.tcp_keepalive_intvl = 75net.ipv4.tcp_keepalive_probes = 9net.ipv4.tcp_keepalive_time = 7200

可以看到这3个内核参数的默认值分别为

tcp_keepalive_time = 7200秒即2小时。也就是说从最后一次数据传输结束开始计时起到发送第一个保活探测报文的时间间隔为2小时。

tcp_keepalive_probes = 9。当没有收到对方的确认时继续发送保活探测报文的默认次数为9次。

tcp_keepalive_intvl = 75秒。当没有收到对方的确认时继续发送保活探测报文的间隔时间为75秒。

TCP连接探活的过程

开启 keepalive后如果2小时内在此TCP连接的通信双方没有发生数据交换TCPT就自动给对方发一个保活探测报文段(keepalive probe)。这是一个对方必须响应的TCP报文段。

它会导致以下三种情况

对方成功接收连接正常以期望的ACK报文段响应。2小时后TCP将发出另一个探测报文。

对方已崩溃且已重新启动已RST报文段响应。socket的待处理错误被置为ECONNRESETsocket本身则被关闭断开TCP连接。

对方无任何响应发送保活探测报文的一方相隔75秒后再次重发保活探测报文重发8次一共尝试9次。若仍无响应就放弃。socket的待处理错误被置为ETIMEOUTsocket本身则被关闭断开TCP连接。

设置TCP keepalive

上面提到的 TCP keepalive使用的是其默认值。如果我们不想使用这么长的等待时间可以修改Linux内核关于网络方面的配置参数。我们可以自定义那3个内核参数的值有两种修改方式

1全局设置操作系统层面

2针对单个TCP连接设置应用程序层面

1、全局设置

在Linux系统中我们可以通过修改 /etc/sysctl.conf 配置文件的全局配置

net.ipv4.tcp_keepalive_time=300net.ipv4.tcp_keepalive_intvl=30net.ipv4.tcp_keepalive_probes=5

添加上面的配置后输入sysctl -p 使其生效。

这种方法设置的全局内核参数针对整个操作系统生效对单个socket的设置不够友好。

2、针对单个TCP连接的设置

我们可以在socket网络编程中设置TCP的 TCP_KEEPCNT、TCP_KEEPIDLE、TCP_KEEPINTVL 这3个socket选项。

这三个选项的定义可以通过man 命令查看。

man 7 tcp

TCP_KEEPCNT (since Linux 2.4)
The maximum number of keepalive probes TCP should send before dropping the connection. This option should not be
used in code intended to be portable.
关闭一个非活跃连接之前的最大重试次数。 该选项不具备可移植性。
TCP_KEEPIDLE (since Linux 2.4)
The time (in seconds) the connection needs to remain idle before TCP starts sending keepalive probes, if the
socket option SO_KEEPALIVE has been set on this socket. This option should not be used in code intended to be
portable.
设置连接上如果没有数据发送的话多久后发送keepalive探测报文单位是秒。该选项不具备可移植性。
TCP_KEEPINTVL (since Linux 2.4)
The time (in seconds) between individual keepalive probes. This option should not be used in code intended to be
portable.
前后两次探测报文之间的时间间隔单位是秒。该选项不具备可移植性。

代码层面的设置步骤如下

int keepAlive = 1;    // 非0值开启keepalive属性int keepIdle = 60;    // 如该连接在60秒内没有任何数据往来,则进行此TCP层的探测int keepInterval = 5; // 探测发包间隔为5秒int keepCount = 3;    // 尝试探测的最多次数//开启tcp-keepAlive探活机制
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &keepAlive, sizeof(keepAlive));
 
setsockopt(sockfd, SOL_TCP, TCP_KEEPIDLE, &keepIdle, sizeof(keepIdle));
 
setsockopt(sockfd, SOL_TCP, TCP_KEEPINTVL, &keepInterval, sizeof(keepInterval));
 
setsockopt(sockfd, SOL_TCP, TCP_KEEPCNT, &keepCount, sizeof(keepCount);

6.2.3 TCP Keepalive 常见异常

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

ETIMEOUT 超时错误

在发送一个探测报文段后经过(tcpkeepaliveTime + tcpkeepaliveIntvl * tcpkeepaliveProbes)时间后仍然没有接收到ACK确认报文段的情况下触发的异常套接字被关闭Connection timedout。

EHOSTUNREACH 主机不可达错误

这个是网络层的ICMP汇报给上层应用的异常错误No route to host。

6.2.4 TCP Keepalive 和 应用层 heartbeat 优缺点

1、TCP协议的 Keepalive 机制

优点TCP协议的Keepalive机制由系统内核实现上层应用程序只需要处理数据的收发连接异常通知即可这就减少了应用层代码的复杂度内核层面的计时器相比应用层更为高效。

缺点第一TCP keepalive机制位于传输层由操作系统负责只能检测到连接是否存活但不能检测检测连接是否可用。例如服务器因为某种原因导致负载超高CPU使用率达到了100%无法继续响应任何业务请求但是TCP探针却仍能确定连接状态这就是典型的连接活着但是服务已死的状态。对于客户端而言这时最好的选择就是断开连接重新连接到其他服务器上而不是一直认为当前服务器仍处于可用状态一直向当前服务器发送那些必然会失败的请求。

第二TCP keepalive机制 对于连接异常断开的情况不能及时有效地监测到。如果TCP连接的某一方突然异常断开连接这个时候发送方并不知道对端已经掉线。而此时如果有数据发送失败tcp会自动进行超时重传而重传报文段的优先级是要高于keepalive的探测报文段的导致探测报文段总是不能发送出去直到经过较长时间的重传之后我们才会知道。

2、应用层的HeartBeat 机制

优点第一具有更好的灵活可控性。可以控制心跳的监测时机、间隔和流程甚至可以在心跳包上附带额外信息最重要的是不光可以检测连接是否存在还可以检测到连接是否可用而TCP的keepalive机制只能提供简单的检活功能。

第二具有通用性。应用层的心跳不依赖传输层协议如果有一天不用TCP要改用UDP了传输层不提供心跳机制了但是你应用层的心跳机制依然可以使用只需做少许改动就可以继续使用。

缺点第一需要开发人员自己实现增加软件开发的工作量由于应用特定的网络框架还可能增加代码结构的复杂度。

第二应用层心跳的流量消耗会更大毕竟这本质上还是一个普通的数据包。