TCP协议-长连接和短连接

我会带着你远行 2023-01-24 02:06 214阅读 0赞

# 一 前言 #

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

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

# 二 TCP短连接 #

模拟一种TCP短连接的情况：

1.  client 向 server 发起连接请求
2.  server 收到连接请求，双方建立TCP连接
3.  client 向 server 发送消息
4.  server 回应 client 消息
5.  一次读写完成，此时双方任何一方都可以发起关闭连接请求，即close操作。

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

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

# 三 TCP长连接 #

模拟一种长连接的情况：

1.  client 向 server 发起连接请求
2.  server 收到连接请求，双方建立TCP连接
3.  client 向 server 发送消息
4.  server 回应 client 消息
5.  一次读写完成，TCP连接不关闭
6.  后续读写操作...
7.  长时间操作之后，client 发起关闭连接请求

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

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

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

## 4.1 短连接的优缺点 ##

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

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

## 4.2 长连接的优缺点 ##

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

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

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

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

> 例如：数据库的连接通常使用长连接，如果用短连接的话，频繁的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 keepalive
    net.ipv4.tcp_keepalive_intvl = 75
    net.ipv4.tcp_keepalive_probes = 9
    net.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的待处理错误被置为ECONNRESET，socket本身则被关闭，断开TCP连接。
 *  对方无任何响应：发送保活探测报文的一方，相隔75秒后，再次重发保活探测报文，重发8次，一共尝试9次。若仍无响应就放弃。socket的待处理错误被置为ETIMEOUT，socket本身则被关闭，断开TCP连接。

**设置TCP keepalive**

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

（1）全局设置（操作系统层面）

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

**1、全局设置**

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

net.ipv4.tcp_keepalive_time=300 
    net.ipv4.tcp_keepalive_intvl=30  
    net.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了，传输层不提供心跳机制了，但是你应用层的心跳机制依然可以使用，只需做少许改动就可以继续使用。

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

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

# 参考 #

[tcp长连接和短连接][tcp]

[TCP Keepalive机制与应用层心跳Heartbeat][TCP Keepalive_Heartbeat]

[TCP连接探测中的Keepalive和心跳包][TCP_Keepalive]

[TCP keepalive的详解(解惑)][TCP keepalive]

[理解TCP长连接（Keepalive）][TCP_Keepalive 1]

[聊聊 TCP 长连接和心跳那些事][TCP]

[tcp]: https://www.cnblogs.com/georgexu/p/10909814.html
[TCP Keepalive_Heartbeat]: https://blog.csdn.net/chrisnotfound/article/details/80112736
[TCP_Keepalive]: https://www.cnblogs.com/lidabo/p/3804108.html
[TCP keepalive]: https://blog.csdn.net/lanyang123456/article/details/90578453
[TCP_Keepalive 1]: https://blog.csdn.net/chrisnotfound/article/details/80111559
[TCP]: https://network.51cto.com/art/201901/590095.htm