简单了解TCP中设计的短连接和长连接
1 前言
可能很多 java 程序员对 tcp 的理解只有一个三次握手，四次挥手的认识，我觉得这样的原因主要在于 tcp 协议本身稍微有点抽象（相比较于应用层的 http 协议）;其次，非框架开发者不太需要接触到 tcp 的一些细节。其实我个人对 tcp 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳的问题，做一个统一的整理。
在 java 中，使用 tcp 通信，大概率会涉及到 socket、netty，本文会借用它们的一些 api 和设置参数来辅助介绍。
2 长连接与短连接
tcp 本身并没有长短连接的区别，长短与否，完全取决于我们怎么用它。
短连接：每次通信时，创建 socket;一次通信结束，调用 socket.close（）。这就是一般意义上的短连接，短连接的好处是管理起来比较简单，存在的连接都是可用的连接，不需要额外的控制手段。
长连接：每次通信完毕后，不会关闭连接，这样就可以做到连接的复用。长连接的好处便是省去了创建连接的耗时。
短连接和长连接的优势，分别是对方的劣势。想要图简单，不追求高性能，使用短连接合适，这样我们就不需要操心连接状态的管理;想要追求性能，使用长连接，我们就需要担心各种问题：比如端对端连接的维护，连接的保活。
长连接还常常被用来做数据的推送，我们大多数时候对通信的认知还是 request/response 模型，但 tcp 双工通信的性质决定了它还可以被用来做双向通信。在长连接之下，可以很方便的实现 push 模型。
短连接没有太多东西可以讲，所以下文我们将目光聚焦在长连接的一些问题上。纯讲理论未免有些过于单调，所以下文我借助 dubbo 这个 rpc 框架的一些实践来展开 tcp 的相关讨论。
3 服务治理框架中的长连接
前面已经提到过，追求性能的时候，必然会选择使用长连接，所以借助 dubbo 可以很好的来理解 tcp。我们开启两个 dubbo 应用，一个 server 负责监听本地 20880（众所周知，这是 dubbo 协议默认的端口），一个 client 负责循环发送请求。执行 lsof-i:20880 命令可以查看端口的相关使用情况：
*：20880（listen） 说明了 dubbo 正在监听本地的 20880 端口，处理发送到本地 20880 端口的请求。
后两条信息说明请求的发送情况，验证了 tcp 是一个双向的通信过程，由于我是在同一个机器开启了两个 dubbo 应用，所以你能够看到是本地的 53078 端口与 20880 端口在通信。我们并没有手动设置 53078 这个客户端端口，他是随机的，但也阐释了一个道理：即使是发送请求的一方，也需要占用一个端口。
稍微说一下 fd 这个参数，他代表了文件句柄，每新增一条连接都会占用新的文件句柄，如果你在使用 tcp 通信的过程中出现了 open too many files 的异常，那就应该检查一下，你是不是创建了太多的连接，而没有关闭。细心的读者也会联想到长连接的另一个好处，那就是会占用较少的文件句柄。
4 长连接的维护
因为客户端请求的服务可能分布在多个服务器上，客户端端自然需要跟对端创建多条长连接，使用长连接，我们遇到的第一个问题就是要如何维护长连接。
//客户端 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》
}
在 dubbo 中，客户端和服务端都使用 ip:port 维护了端对端的长连接，channel 便是对连接的抽象。我们主要关注 nettyhandler 中的长连接，服务端同时维护一个长连接的集合是 dubbo 的设计，我们将在后面提到。
5 连接的保活
这个话题就有的聊了，会牵扯到比较多的知识点。首先需要明确一点，为什么需要连接的报活？当双方已经建立了连接，但因为网络问题，链路不通，这样长连接就不能使用了。需要明确的一点是，通过 netstat，lsof 等指令查看到连接的状态处于 established 状态并不是一件非常靠谱的事，因为连接可能已死，但没有被系统感知到，更不用提假死这种疑难杂症了。如果保证长连接可用是一件技术活。
6 连接的保活：keepalive
首先想到的是 tcp 中的 keepalive 机制。keepalive 并不是 tcp 协议的一部分，但是大多数操作系统都实现了这个机制。keepalive 机制开启后，在一定时间内（一般时间为 7200s，参数 tcp_keepalive_time）在链路上没有数据传送的情况下，tcp 层将发送相应的keepalive探针以确定连接可用性，探测失败后重试 10（参数 tcp_keepalive_probes）次，每次间隔时间 75s（参数 tcp_keepalive_intvl），所有探测失败后，才认为当前连接已经不可用。
在 netty 中开启 keepalive：
bootstrap.option（channeloption.tcp_nodelay，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 高等情况，但网络仍然是通的，此时，应用已经失去了活性，所以连接自然应该认为是不可用的。
看来，应用层面的连接保活还是必须要做的。
7 连接的保活：应用层心跳
终于点题了，文题中提到的心跳便是一个本文想要重点强调的另一个 tcp 相关的知识点。上一节我们已经解释过了，网络层面的 keepalive 不足以支撑应用级别的连接可用性，本节就来聊聊应用层的心跳机制是实现连接保活的。
如何理解应用层的心跳？简单来说，就是客户端会开启一个定时任务，定时对已经建立连接的对端应用发送请求（这里的请求是特殊的心跳请求），服务端则需要特殊处理该请求，返回响应。如果心跳持续多次没有收到响应，客户端会认为连接不可用，主动断开连接。不同的服务治理框架对心跳，建连，断连，拉黑的机制有不同的策略，但大多数的服务治理框架都会在应用层做心跳，dubbo 也不例外。
8 应用层心跳的设计细节
以 dubbo 为例，支持应用层的心跳，客户端和服务端都会开启一个 heartbeattask，客户端在 headerexchangeclient 中开启，服务端将在 headerexchangeserver 开启。文章开头埋了一个坑：dubbo 为什么在服务端同时维护 map
// heartbeattask if （channel instanceof client） {
（（client） channel）.reconnect（）;
} else { channel.close（）;
}
熟悉其他 rpc 框架的同学会发现，不同框架的心跳机制真的是差距非常大。心跳设计还跟连接创建，重连机制，黑名单连接相关，还需要具体框架具体分析。
除了定时任务的设计，还需要在协议层面支持心跳。最简单的例子可以参考 nginx 的健康检查，而针对 dubbo 协议，自然也需要做心跳的支持，如果将心跳请求识别为正常流量，会造成服务端的压力问题，干扰限流等诸多问题。
其中 flag 代表了 dubbo 协议的标志位，一共 8 个地址位。低四位用来表示消息体数据用的序列化工具的类型（默认 hessian），高四位中，第一位为1表示是 request 请求，第二位为 1 表示双向传输（即有返回response），第三位为 1 表示是心跳事件。
心跳请求应当和普通请求区别对待。
9 注意和 http 的 keepalive 区别对待
http 协议的 keepalive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
tcp 的 keepalive 机制意图在于保活、心跳，检测连接错误。
这压根是两个概念。
10 keepalive 常见异常
启用 tcp keepalive 的应用程序，一般可以捕获到下面几种类型错误
etimeout 超时错误，在发送一个探测保护包经过 （tcpkeepalivetime + tcpkeepaliveintvl * tcpkeepaliveprobes）时间后仍然没有接收到 ack 确认情况下触发的异常，套接字被关闭 java java.io.ioexception:connectiontimedout
ehostunreach host unreachable（主机不可达）错误，这个应该是 icmp 汇报给上层应用的。 java java.io.ioexception:noroute to host
链接被重置，终端可能崩溃死机重启之后，接收到来自服务器的报文，然物是人非，前朝往事，只能报以无奈重置宣告之。 java java.io.ioexception:connectionresetbypeer
11 总结
有三种使用 keepalive 的实践方案：
1.默认情况下使用 keepalive 周期为 2 个小时，如不选择更改，属于误用范畴，造成资源浪费：内核会为每一个连接都打开一个保活计时器，n 个连接会打开 n 个保活计时器。 优势很明显：
tcp 协议层面保活探测机制，系统内核完全替上层应用自动给做好了
内核层面计时器相比上层应用，更为高效
上层应用只需要处理数据收发、连接异常通知即可
数据包将更为紧凑
2.关闭 tcp 的 keepalive，完全使用应用层心跳保活机制。由应用掌管心跳，更灵活可控，比如可以在应用级别设置心跳周期，适配私有协议。
3.业务心跳 + tcp keepalive 一起使用，互相作为补充，但 tcp 保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。
各个框架的设计都有所不同，例如 dubbo 使用的是方案三，但阿里内部的 hsf 框架则没有设置 tcp 的 keepalive，仅仅由应用心跳保活。和心跳策略一样，这和框架整体的设计相关。
VoWLAN设计面临的挑战及解决方案分析
中软国际鸿蒙生态实践成果闪耀程序员节，以智联创新码动程序世界
三菱PLC N：N网络通讯案例
汽车电子系统产品企业东风科技发布2022第一季度报告
艾法斯7100数字无线测试系统新增对4x2 MIMO的支持
简单了解TCP中设计的短连接和长连接
小米平板3或将今日亮相新品发布会：配置价格全曝光，你值得购买！
iQOO 7电竞旗舰黑镜、传奇版正式开售
Pixel Qi：比新iPad视网膜屏更好更省电的显示屏
突发，全球汽车传感器龙头博世宣布：放弃激光雷达研发！
随着智能家居的蓬勃发展，智能门锁市场或迎新一轮爆发
通过动态功率控制实现模拟输出高效的散热设计
Micrium RTOS内核支持Xilinx的可编程器件 Zynq UltraScale+ MPSoc
【佳金源】德国客户应邀到我公司进行实地考察
工业互联网第一城会是在哪里
检测热敏电阻的注意事项
什么是滤波天线？滤波天线设计优缺点分析
桥式整流电路中输出电容容值的计算讲解
801系列双头短截线ACME螺纹配合连接器Glenair
简单的LED电源项目电路 A power source fo
可能很多 java 程序员对 tcp 的理解只有一个三次握手，四次挥手的认识，我觉得这样的原因主要在于 tcp 协议本身稍微有点抽象（相比较于应用层的 http 协议）;其次，非框架开发者不太需要接触到 tcp 的一些细节。其实我个人对 tcp 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳的问题，做一个统一的整理。
在 java 中，使用 tcp 通信，大概率会涉及到 socket、netty，本文会借用它们的一些 api 和设置参数来辅助介绍。
2 长连接与短连接
tcp 本身并没有长短连接的区别，长短与否，完全取决于我们怎么用它。
短连接：每次通信时，创建 socket;一次通信结束，调用 socket.close（）。这就是一般意义上的短连接，短连接的好处是管理起来比较简单，存在的连接都是可用的连接，不需要额外的控制手段。
长连接：每次通信完毕后，不会关闭连接，这样就可以做到连接的复用。长连接的好处便是省去了创建连接的耗时。
短连接和长连接的优势，分别是对方的劣势。想要图简单，不追求高性能，使用短连接合适，这样我们就不需要操心连接状态的管理;想要追求性能，使用长连接，我们就需要担心各种问题：比如端对端连接的维护，连接的保活。
长连接还常常被用来做数据的推送，我们大多数时候对通信的认知还是 request/response 模型，但 tcp 双工通信的性质决定了它还可以被用来做双向通信。在长连接之下，可以很方便的实现 push 模型。
短连接没有太多东西可以讲，所以下文我们将目光聚焦在长连接的一些问题上。纯讲理论未免有些过于单调，所以下文我借助 dubbo 这个 rpc 框架的一些实践来展开 tcp 的相关讨论。
3 服务治理框架中的长连接
前面已经提到过，追求性能的时候，必然会选择使用长连接，所以借助 dubbo 可以很好的来理解 tcp。我们开启两个 dubbo 应用，一个 server 负责监听本地 20880（众所周知，这是 dubbo 协议默认的端口），一个 client 负责循环发送请求。执行 lsof-i:20880 命令可以查看端口的相关使用情况：
*：20880（listen） 说明了 dubbo 正在监听本地的 20880 端口，处理发送到本地 20880 端口的请求。
后两条信息说明请求的发送情况，验证了 tcp 是一个双向的通信过程，由于我是在同一个机器开启了两个 dubbo 应用，所以你能够看到是本地的 53078 端口与 20880 端口在通信。我们并没有手动设置 53078 这个客户端端口，他是随机的，但也阐释了一个道理：即使是发送请求的一方，也需要占用一个端口。
稍微说一下 fd 这个参数，他代表了文件句柄，每新增一条连接都会占用新的文件句柄，如果你在使用 tcp 通信的过程中出现了 open too many files 的异常，那就应该检查一下，你是不是创建了太多的连接，而没有关闭。细心的读者也会联想到长连接的另一个好处，那就是会占用较少的文件句柄。
4 长连接的维护
因为客户端请求的服务可能分布在多个服务器上，客户端端自然需要跟对端创建多条长连接，使用长连接，我们遇到的第一个问题就是要如何维护长连接。
//客户端 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》
}
在 dubbo 中，客户端和服务端都使用 ip:port 维护了端对端的长连接，channel 便是对连接的抽象。我们主要关注 nettyhandler 中的长连接，服务端同时维护一个长连接的集合是 dubbo 的设计，我们将在后面提到。
5 连接的保活
这个话题就有的聊了，会牵扯到比较多的知识点。首先需要明确一点，为什么需要连接的报活？当双方已经建立了连接，但因为网络问题，链路不通，这样长连接就不能使用了。需要明确的一点是，通过 netstat，lsof 等指令查看到连接的状态处于 established 状态并不是一件非常靠谱的事，因为连接可能已死，但没有被系统感知到，更不用提假死这种疑难杂症了。如果保证长连接可用是一件技术活。
6 连接的保活：keepalive
首先想到的是 tcp 中的 keepalive 机制。keepalive 并不是 tcp 协议的一部分，但是大多数操作系统都实现了这个机制。keepalive 机制开启后，在一定时间内（一般时间为 7200s，参数 tcp_keepalive_time）在链路上没有数据传送的情况下，tcp 层将发送相应的keepalive探针以确定连接可用性，探测失败后重试 10（参数 tcp_keepalive_probes）次，每次间隔时间 75s（参数 tcp_keepalive_intvl），所有探测失败后，才认为当前连接已经不可用。
在 netty 中开启 keepalive：
bootstrap.option（channeloption.tcp_nodelay，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 高等情况，但网络仍然是通的，此时，应用已经失去了活性，所以连接自然应该认为是不可用的。
看来，应用层面的连接保活还是必须要做的。
7 连接的保活：应用层心跳
终于点题了，文题中提到的心跳便是一个本文想要重点强调的另一个 tcp 相关的知识点。上一节我们已经解释过了，网络层面的 keepalive 不足以支撑应用级别的连接可用性，本节就来聊聊应用层的心跳机制是实现连接保活的。
如何理解应用层的心跳？简单来说，就是客户端会开启一个定时任务，定时对已经建立连接的对端应用发送请求（这里的请求是特殊的心跳请求），服务端则需要特殊处理该请求，返回响应。如果心跳持续多次没有收到响应，客户端会认为连接不可用，主动断开连接。不同的服务治理框架对心跳，建连，断连，拉黑的机制有不同的策略，但大多数的服务治理框架都会在应用层做心跳，dubbo 也不例外。
8 应用层心跳的设计细节
以 dubbo 为例，支持应用层的心跳，客户端和服务端都会开启一个 heartbeattask，客户端在 headerexchangeclient 中开启，服务端将在 headerexchangeserver 开启。文章开头埋了一个坑：dubbo 为什么在服务端同时维护 map
// heartbeattask if （channel instanceof client） {
（（client） channel）.reconnect（）;
} else { channel.close（）;
}
熟悉其他 rpc 框架的同学会发现，不同框架的心跳机制真的是差距非常大。心跳设计还跟连接创建，重连机制，黑名单连接相关，还需要具体框架具体分析。
除了定时任务的设计，还需要在协议层面支持心跳。最简单的例子可以参考 nginx 的健康检查，而针对 dubbo 协议，自然也需要做心跳的支持，如果将心跳请求识别为正常流量，会造成服务端的压力问题，干扰限流等诸多问题。
其中 flag 代表了 dubbo 协议的标志位，一共 8 个地址位。低四位用来表示消息体数据用的序列化工具的类型（默认 hessian），高四位中，第一位为1表示是 request 请求，第二位为 1 表示双向传输（即有返回response），第三位为 1 表示是心跳事件。
心跳请求应当和普通请求区别对待。
9 注意和 http 的 keepalive 区别对待
http 协议的 keepalive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
tcp 的 keepalive 机制意图在于保活、心跳，检测连接错误。
这压根是两个概念。
10 keepalive 常见异常
启用 tcp keepalive 的应用程序，一般可以捕获到下面几种类型错误
etimeout 超时错误，在发送一个探测保护包经过 （tcpkeepalivetime + tcpkeepaliveintvl * tcpkeepaliveprobes）时间后仍然没有接收到 ack 确认情况下触发的异常，套接字被关闭 java java.io.ioexception:connectiontimedout
ehostunreach host unreachable（主机不可达）错误，这个应该是 icmp 汇报给上层应用的。 java java.io.ioexception:noroute to host
链接被重置，终端可能崩溃死机重启之后，接收到来自服务器的报文，然物是人非，前朝往事，只能报以无奈重置宣告之。 java java.io.ioexception:connectionresetbypeer
11 总结
有三种使用 keepalive 的实践方案：
1.默认情况下使用 keepalive 周期为 2 个小时，如不选择更改，属于误用范畴，造成资源浪费：内核会为每一个连接都打开一个保活计时器，n 个连接会打开 n 个保活计时器。 优势很明显：
tcp 协议层面保活探测机制，系统内核完全替上层应用自动给做好了
内核层面计时器相比上层应用，更为高效
上层应用只需要处理数据收发、连接异常通知即可
数据包将更为紧凑
2.关闭 tcp 的 keepalive，完全使用应用层心跳保活机制。由应用掌管心跳，更灵活可控，比如可以在应用级别设置心跳周期，适配私有协议。
3.业务心跳 + tcp keepalive 一起使用，互相作为补充，但 tcp 保活探测周期和应用的心跳周期要协调，以互补方可，不能够差距过大，否则将达不到设想的效果。
各个框架的设计都有所不同，例如 dubbo 使用的是方案三，但阿里内部的 hsf 框架则没有设置 tcp 的 keepalive，仅仅由应用心跳保活。和心跳策略一样，这和框架整体的设计相关。
VoWLAN设计面临的挑战及解决方案分析
中软国际鸿蒙生态实践成果闪耀程序员节，以智联创新码动程序世界
三菱PLC N：N网络通讯案例
汽车电子系统产品企业东风科技发布2022第一季度报告
艾法斯7100数字无线测试系统新增对4x2 MIMO的支持
简单了解TCP中设计的短连接和长连接
小米平板3或将今日亮相新品发布会：配置价格全曝光，你值得购买！
iQOO 7电竞旗舰黑镜、传奇版正式开售
Pixel Qi：比新iPad视网膜屏更好更省电的显示屏
突发，全球汽车传感器龙头博世宣布：放弃激光雷达研发！
随着智能家居的蓬勃发展，智能门锁市场或迎新一轮爆发
通过动态功率控制实现模拟输出高效的散热设计
Micrium RTOS内核支持Xilinx的可编程器件 Zynq UltraScale+ MPSoc
【佳金源】德国客户应邀到我公司进行实地考察
工业互联网第一城会是在哪里
检测热敏电阻的注意事项
什么是滤波天线？滤波天线设计优缺点分析
桥式整流电路中输出电容容值的计算讲解
801系列双头短截线ACME螺纹配合连接器Glenair
简单的LED电源项目电路 A power source fo