-
让品牌有温度、有情感
专注品牌策划15年
tcp长连接（tcp长连接保持多久）
发布时间：2023-03-19 11:20:22
稿源：
创意岭 阅读：
59
问大家
大家好！今天让创意岭的小编来大家介绍下关于tcp长连接的问题，以下是小编对此问题的归纳整理，让我们一起来看看吧。
开始之前先推荐一个非常厉害的Ai人工智能工具，一键生成原创文章、方案、文案、工作计划、工作报告、论文、代码、作文、做题和对话答疑等等
只需要输入关键词，就能返回你想要的内容，越精准，写出的就越详细，有微信小程序端、在线网页版、PC客户端
本文目录:
一、tcp长连接如何实现
关于面向 tcp/ip 协议的可靠连接的网络 socket 编程，必须要按照 tcp/ip协议的 server/client 模型进行编程和调试。
二、TCP keepalive 和 http keep-alive 以及心跳保活
HTTP的长连接和短连接本质上是TCP长连接和短连接。
短连接
短连接，顾名思义，与长连接的区别就是，客户端收到服务端的响应后，立刻发送FIN消息，主动释放连接。也有服务端主动断连的情况，凡是在一次消息交互（发请求-收响应）之后立刻断开连接的情况都称为短连接。
长连接/http keep-alive
也叫持久连接，即一个TCP连接服务多次请求，在TCP层握手成功后，不立即断开连接，并在此连接的基础上进行多次消息（包括心跳）交互，直至连接的任意一方（客户端OR服务端）主动断开连接，此过程称为一次完整的长连接。
在HTTP/1.0中得到了初步的支持，客户端在请求header中携带Connection:Keep-Alive，即是在向服务端请求持久连接。如果服务端接受持久连接，则会在响应header中同样携带Connection: Keep-Alive，这样客户端便会继续使用同一个TCP连接发送接下来的若干请求。（Keep-Alive的默认参数是[timout=5, max=100]，即一个TCP连接可以服务至多5秒内的100次请求）
HTTP/1.1开始，即使请求header中没有携带Connection: Keep-Alive，传输也会默认以持久连接的方式进行，只有加入"Connection: close "后，才关闭。
http keepalive是客户端浏览器与服务端httpd守护进程协作的结果。
TCP中的KeepAlive
TCP协议的实现中，提供了KeepAlive报文，用来探测连接的对端是否存活。在应用交互的过程中，可能存在以下几种情况：
客户端或服务器意外断电，死机，崩溃，重启；
中间网络已经中断，而客户端与服务器并不知道；
利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。TCP保活报文交互过程如下：
因此，KeepAlive并不适用于检测双方存活的场景，这种场景还得依赖于应用层的心跳。 应用层心跳也具备着更大的灵活性，可以控制检测时机，间隔和处理流程，甚至可以在心跳包上附带额外信息。
应用层心跳是检测连接有效性以及判断双方是否存活的有效方式 。但是心跳过于频繁会带来 耗电和耗流量 的弊病，心跳频率过低则会影响连接检测的实时性。业内关于心跳时间的设置和优化，主要基于如下几个因素：
理想的情况下,客户端应当以略小于NAT超时时间的间隔来发送心跳包。 根据微信团队测试的一些数据，一些常用网络的NAT超时时间如下表所示：
TCP的KeepAlive机制意图在于保活、心跳，检测连接错误
如何快速区分当前连接使用的是长连接还是短连接
1、凡是在一次完整的消息交互（发请求-收响应）之后，立刻断开连接（有一方发送FIN消息）的情况都称为短连接；
2、长连接的一个明显特征是会有心跳消息（也有没有心跳的情况），且一般心跳间隔都在30S或者1MIN左右，用wireshark抓包可以看到有规律的心跳消息交互（可能会存在毫秒级别的误差）。
什么时候用长连接，短连接？
1、需要频繁交互的场景使用长连接，如即时通信工具（微信/QQ，QQ也有UDP），相反则使用短连接，比如普通的web网站，只有当浏览器发起请求时才会建立连接，服务器返回相应后，连接立即断开。
2、维持长连接会有一定的系统开销，用户量少不容易看出系统瓶颈，一旦用户量上去了，就很有可能把服务器资源（内存/CPU/网卡）耗尽，所以使用需谨慎。
keep-alive与TIME_WAIT
使用http keep-alvie，可以减少服务端TIME_WAIT数量(因为由服务端httpd守护进程主动关闭连接)。道理很简单，相较而言，启用keep-alive，建立的tcp连接更少了，自然要被关闭的tcp连接也相应更少了。
短连接和长链接 图：
参考： https://caofengbin.github.io/2018/03/16/dhcp-and-nat/#4-%E5%BD%B1%E5%93%8D%E5%BF%83%E8%B7%B3%E9%A2%91%E7%8E%87%E7%9A%84%E5%85%B3%E9%94%AE%E5%9B%A0%E7%B4%A0
https://blog.csdn.net/hengyunabc/article/details/44310193
http://wingjay.com/2018/12/05/android-arch-long-link/
https://www.levicc.com/2018/06/30/yi-dong-duan-wang-luo-you-hua/
能被我参考的都很优秀，哈哈
三、TCP/IP, UDP, HTTP, WebSocket, RPC及协议包结构
WebSocket对客户端和服务端的要求
参考资料
http://www.websocket.org/index.html
https://segmentfault.com/a/1190000012709475
https://www.liaoxuefeng.com/wiki/1022910821149312/1103303693824096
https://www.cnblogs.com/nnngu/p/9347635.html
https://www.cnblogs.com/bianzy/p/5822426.html
https://www.cnblogs.com/jingmoxukong/p/7755643.html (nginx代理WebSocket)
https://segmentfault.com/a/1190000012948613
https://www.jianshu.com/p/42260a2575f8
https://www.jianshu.com/p/45cbc2252c11 (参考资源)
https://www.jianshu.com/p/9e63767c04e1
https://www.jianshu.com/p/e41a329ef353 (握手等过程参考这里)
TCP 标志位
TCP状态
建立连接协议（三次握手）
连接终止协议（四次握手）
https://blog.csdn.net/yangyangye/article/details/38851271 (详解)
https://blog.csdn.net/zzhongcy/article/details/21992471
1.为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
2. 为什么不能用两次握手进行连接？
3.为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
TCP短连接
TCP长连接
TCP长/短连接的优点和缺点
TCP长/短连接的应用场景
wireshark
https://www.jianshu.com/p/e41a329ef353 (参考这里)
https://www.jianshu.com/p/7c01759c28dd (https加密传输参考这里)
使用集线器组成一个网络
使用交换机组成一个网络
使用路由器连接多个网络(组包, 拆包过程)
通信过程
https://www.jianshu.com/p/209576915459
参考资源
https://www.jianshu.com/p/9e63767c04e1 (各种协议包结构)
https://www.jianshu.com/p/29868fb82890 (TCP三次握手四次挥手)
四、TCP长连接出现Too many open files，该怎么处理
这是因为网络请求过多，也就导致了系统打开的文件过多。每一个连接都会当成“文件”看待的。
于是用命令
ulimit -a
（效果：查看每个用户允许打开的最大文件数）
看到最大文件数是1024，将其更改大点，如
ulimit -n 4096
然后必须重启下网络服务，我用的是WebLogic，重启之后便没有出现异常。
导致 Too many open files ，网络请求过多是一种可能，但也有可能是程序上的缺陷，如没有释放一些文件句柄，程序open了文件却忘记了在最后close。但我确信工程中没有用到打开文件这一环节，因此这个可能是排除掉了。
用lsof -p [进程ID] 可以看到某ID的打开文件状况。进程ID可能用 ps -ef|grep java列出weblogic的进程ID，然后用此ID套入lsof -p ID号，咳，一大堆的请求哟，这显然是网络请求过多造成了 Too many open files。适当调整后便已消除这种现象。
以上就是关于tcp长连接相关问题的回答。希望能帮到你，如有更多相关问题，您也可以联系我们的客服进行咨询，客服也会为您讲解更多精彩的知识和内容。
推荐阅读：
赣公网安备 50019002502384号
