TCP/IP网络协议
IP协议
> 参考TCP/IP详解卷一
(1) TCP 使用不可靠的IP服务,并且提供一个可靠的运输层服务
(2) UDP为应用层发送和接受数据报并且为不可靠
(3) IP是网络层上的主要协议同时被TCP和UDP使用
(5)ICMP是IP协议的附属协议
端口号:源端口号随机的目的端口号是固定的
服务器一般都是通过知名的端口号来识别的
客户端口号又称为随机端口号
以太网头部组成
IP介绍
(1)IP是TCP/IP协议中最为核心的协议所有的TCP/UDP/ICMP/IGMP数据都已IP数据报格式传输
(2)IP提供不可靠,无连接的数据报传送服务
(3) ifconfig netstat
(1) 无状态: IP通信双方的数据状态信息不同步,即所有的IP数据报的发送、传输、接收都是相互独立
的,没有上下文关系。优点是简单高效,不占用内核结构来保存通信状态,
每次传输数据时不用携带状态信息
(2) 无连接: IP通信双方不能长久地维持对方的任何信息。上层协议每次发送数据时都需要指明通信对方的地址
(3) 不可靠: 不能保证IP数据报准确地到达接收端,它只是承诺尽最大的努力
在网络协议中无状态无连接是很常见的,如UDP协议和HTTP协议。HTTP协议中,一个浏览器的连续两次网页请求之间并没有关联,它们被WEB服务器独立处理。使用IP服务的上层协议若要实现数据确认、
超时重传等机制,就需要在上层协议中实现,如TCP协议。
IP头部(60byte)
(1) 版本号:IP协议的版本,ipv4 值为4
(2) 头部长度:4位最多1111,
(3) 服务类型(Type Of Service,TOS):3位优先权字段(现已被忽略) + 4位TOS字段 + 1位保留字段(须为0)。4位TOS字段分别表示最小延时、最大吞吐量、最高可靠性、最小费用,其中最多有一个能置为1。
应用程序根据实际需要来设置 TOS值,如ssh和telnet这样的登录程序需要的是最小延时的服务,文件传输ftp需要的是最大吞吐量的服务
(4) 总长度: 指整个IP数据报的长度,单位为字节,即IP数据报的最大长度为65535字节(2的16次方)。由于MTU的限制,长度超过MTU的数据报都将被分片传输,
所以实际传输的IP分片数据报的长度远远没有达到最大值
如何分片
(5)标识 : 同一个数据报的所有分片都具有相同的标识值
(6)标志位: 位1 保留,位2 禁止分片(DF)若设置了此位,IP模块将不对数据报进行分片,
在此情况下若IP数据报超过MTU,IP模块将丢弃数据报并返回一个ICMP差错报文
位3更多分片(MF)除了最后一个分片,其他分片都为1
(7)位偏移:分片相对原始IP数据报数据部分的偏移。实际的偏移值为该值左移3位后得到的,
所以除了最后一个IP数据报分片外,每个IP分片的数据部分的长度都必须是8的整数倍
(8)生存时间:数据报到达目的地之前允许经过的路由器跳数,每过一个路由减一,防止数据报陷入路由环路
(9)协议:区别上层协议
1 : ICMP
6 : TCP
17 : UDP
(10) 头部校验和: 由发送端填充接收端对其使用CRC算法校验,
检查IP数据报头部在传输过程中是否损坏
(12) 选项:可变长的可选信息,最多包含40字节。选项字段很少被使用。可用的IP可选项有:
a. 记录路由: 记录数据包途径的所有路由的IP,这样可以追踪数据包的传递路径
b. 时间戳: 记录每个路由器数据报被转发的时间或者时间与IP地址对,这样就可以测量途径路由之间数据报的传输的时间
c. 松散路由选择: 指定路由器的IP地址列表数据发送过程中必须经过所有的路由器
d. 严格路由选择: 数据包只能经过被指定的IP地址列表的路由器
e. 上层协议(如TCP/UDP)的头部信息
————————————————
特殊的IP地址
源IP:0.0.0.0 目的IP:255.255.255.255 DHCP UDP包
127...* 环回口
ARP协议
ARP 出现的原因:设备驱动程序从不检查IP数据包中的目的IP地址
ARP协议是“Address Resolution Protocol”(地址解析协议)的缩写。其作用是在以太网环境中,
数据的传输所依懒的是MAC地址而非IP地址,而将已知IP地址转换为MAC地址的工作是由ARP协议来完成的。
工作过程: 输入域名 --> DNS解析域名得到IP–> TCP 连接 -->IP 映射查询是否位直联网络 —> ARP发生一个二层广播 —>目的主机接受广播 响应一个单播给源IP,
并且附上MAC地址–> 通过MAC 建立连接
ARP报头
硬件类型:16位字段,用来定义运行ARP的网络类型。每个局域网基于其类型被指派一个整数。例如:以太网的类型为1。ARP可用在任何物理网络上。
协议类型:16位字段,用来定义使用的协议。例如:对IPv4协议这个字段是0800。ARP可用于任何高层协议
硬件长度:8位字段,用来定义物理地址的长度,以字节为单位。例如:对于以太网的值为6。
协议长度:8位字段,用来定义逻辑地址的长度,以字节为单位。例如:对于IPv4协议的值为4。
操作码:16位字段,用来定义报文的类型。已定义的分组类型有两种:ARP请求(1),ARP响应(2)。
源硬件地址:这是一个可变长度字段,用来定义发送方的物理地址。例如:对于以太网这个字段的长度是6字节。
源逻辑地址:这是一个可变长度字段,用来定义发送方的逻辑(IP)地址。例如:对于IP协议这个字段的长度是4字节。
目的硬件地址:这是一个可变长度字段,用来定义目标的物理地址,例如,对以太网来说这个字段位6字节。对于ARP请求报文,这个字段为全0,因为发送方并不知道目标的硬件地址。
TCP协议
TCP : 传输控制报协议 ,是一种面向字节流可靠的传输协议
TCP会管理四个定时器:
(1)2MSL定时器
(2)重传定时器
(3)坚持定时器
(4)保活定时器
后续的章节会详细讲解这4个定时器
TCP通过以下方式提供可靠性:
(1)应用数据会被分割成TCP认为和合适的数据块
(2)TCP发送后会使用一个定时器,超时重传
(3)TCP连接的对端收到数据报会产生确认应答有个延迟delayed-ACK(200ms)
(4)TCP首部和数据的校验和
(5)能够处理IP协议的丢包,失序,重复数据的能力
(6)流量控制,防止较快主机致使较慢主机的缓冲区溢出
首部详解
五元组:协议,源端口 IP 目的端口 IP
首部字段详解:
(1)源端口和目的端口号:寻找发端和收端的应用进程
(2)序号:TCP发端向TCP收端发送的数据字节流,标识这个报文段中的第一个
数据字节的序号(32bit unsigned SYN/FIN要消耗一个序号)
(3)确认序号是上次成功收到的数据字节+1,ACK为1确认序号字段有效
(4)发送ACK无需占用如何序号
(5)TCP为应用层提供全双工服务
首部长度:20~60
标识位
标识 | 作用 |
---|---|
CWR | 减少拥塞窗口(发送方降低发送速率)//保留位增加的 |
ECE | ECN回显(发送方收到一个更早的拥塞通告)//保留位增加的 |
URG | 紧急指针 |
ACK | 确认序号有效 |
PSH | 接收方应该尽快将这个报文段交给应用层指针 |
RST | 重建连接 |
SYN | 同步序列号用来发起一个连接请求 |
FIN | 终止连接 |
窗口大小:16bit 最多65535
紧急指针:当URG位置1有效是一个偏移量,和序号字段中的值相加标识紧急数据最后一个字节的序号
可选字段:
最大报文段长度(Maxium Segment Size):指明数据字段的最大长度,数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS值指示自己期望对方发送TCP报文段时那个数据字段的长度。通信双方可以有不同的MSS值。如果未填写,默认采用536字节。MSS只出现在SYN报文中。即:MSS出现在SYN=1的报文段中。
窗口扩大选项(Windows Scaling):由于TCP首部的窗口大小字段长度是16位,所以其表示的最大数是65535。但是随着时延和带宽比较大的通信产生(如卫星通信),需要更大的窗口来满足性能和吞吐率,所以产生了这个窗口扩大选项。
SACK选择确认项(Selective Acknowledgements):用来确保只重传缺少的报文段,而不是重传所有报文段。比如主机A发送报文段1、2、3,而主机B仅收到报文段1、3。那么此时就需要使用SACK选项来告诉发送方只发送丢失的数据。那么又如何指明丢失了哪些报文段呢?使用SACK需要两个功能字节。一个表示要使用ACK选项,另一个指明这个选项占用多少字节。描述丢失的报文段2,是通过描述它的左右边界报文段1、3来完成的。而这个1、3实际上是表示序列号,所以描述一个丢失的报文段需要64位即8个字节的空间。那么可以推算整个选项字段最多描述(40-2)/8=4个丢失的报文段。
时间戳选项(Timestamps):可以用来计算RTT(往返时间),发送方发送TCP报文时,把当前的时间值放入时间戳字段,接收方收到后发送确认报文时,把这个时间戳字段的值复制到确认报文中,当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS,也可以说可以用来区分相同序列号的不同报文。因为序列号用32为表示,每2^32个序列号就会产生回绕,那么使用时间戳字段就很容易区分相同序列号的不同报文。
NOP(NO-Operation):它要求选项部分中的每种选项长度必须是4字节的倍数,不足的则用NOP填充。同时也可以用来分割不同的选项字段。如窗口扩大选项和SACK之间用NOP隔开。
TCP连接管理
TCP是一种面向连接的单播协议,发送数据之前通信双方必须建立一条连接。相比与UDP来说,TCP在妥善处理多种TCP状态时需要面对大量的细节问题,比如一个连接何时建立,终止以及无警告的情况下重新启动
TCP连接的建立与终止
三次握手:由发送方发送一个(SYN ,seq = ISN(c))报文给接收方
接收方接受报文发送一个(ACK + SYN,ACK = ISN( c ) + 1 seq = ISN( s))给发送方
发送方接受接受方的报文在重新发送一个(ACK,ACK = ISN( s) + 1 seq = ISN( c) + 1)给接受方
为什么要三次握手而不是两次,为什么需要ISN?
为了实现可靠数据传输, TCP 协议的通信双方, 都必须维护一个序列号, 以标识发送出去的数据包中, 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手,至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认
防止同一连接的不同实例出现序列号重叠的情况,防止攻击者利用序列号发生攻击
四次挥手:
(1)主动关闭方发送(FIN + ACK, seq = K, ACK = L)报文,其中ACK字段是用于确认最后一次发来的数据(进入FIN_WAIT1状态)
(2)被动关闭方接受报文然后发送(ACK, ACK = k + 1, seq = L)此时告诉上层应用有请求关闭的请求,因此此时被动关闭方变为主动关闭方发送(ACK + FIN, seq = L, ACK = K + 1)
(3)为完成连接的关闭,最后发送一个ACK用于确认一个FIN(ACK, ACK = L + 1, seq = K)
TCP的半关闭:一端发送FIN请求关闭一端的连接,而另外一端的连接保持。BSD API定义shutdow()
为什么TIME_WAIT = 2MSL(报文段最大生存时间)?
(1)保证建立新连接的时候,老连接的数据报全部处理完了
(2)可靠的实现TCP全双工的终止
对于某一端出现大量的 TIME_WAIT如何解决?
主要出现在短连接比较多的情况,TIME_WAIT来说可以通过修改系统内核参数来实现
/etc/sysctl.conf文件的修改:
#对于一个新建连接,内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255,默认值是5,对应于180秒左右时间
net.ipv4.tcp_syn_retries=2
#net.ipv4.tcp_synack_retries=2
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3
#表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout=30
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_syn_backlog = 4096
#表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭
net.ipv4.tcp_syncookies = 1
#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭
net.ipv4.tcp_tw_recycle = 1
##减少超时前的探测次数
net.ipv4.tcp_keepalive_probes=5
##优化网络设备接收队列
net.core.netdev_max_backlog=3000
修改完之后执行/sbin/sysctl -p让参数生效。
这里头主要注意到的是
net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_fin_timeout
net.ipv4.tcp_keepalive_*
这几个参数。
net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。
net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。
net.ipv4.tcp_keepalive_*一系列参数,是用来设置服务器检测连接存活的相关配置。
对于某一端出现大量的 CLOSE_WAIT如何解决?
TIME_WAIT 可以通过优化服务器来解决,因为发生TIME_WAIT的情况是服务器自己可控的,要么就是对方连接的异常,要么就是自己没有迅速回收资源,总之不是由于自己程序错误导致的。
CLOSE_WAIT : 对方关闭连接之后服务器程序自己没有进一步发出ack信号,出现程序异常
主要原因是某种情况下对方关闭了socket链接,但是我方忙与读或者写,没有关闭连接。
解决方法如下:
1.代码需要判断socket,一旦read返回0,断开连接,read返回负,检查一下errno,如果不是AGAIN,也断开连接。(注:在UNP 7.5节的图7.6中,可以看到使用select能够检测出对方发送了FIN,再根据这条规则就可以处理CLOSE_WAIT的连接)
2.给每一个socket设置一个时间戳last_update,每接收或者是发送成功数据,就用当前时间更新这个时间戳。定期检查所有的时间戳,如果时间戳与当前时间差值超过一定的阈值,就关闭这个socket。
3.使用一个Heart-Beat线程,定期向socket发送指定格式的心跳数据包,如果接收到对方的RST报文,说明对方已经关闭了socket,那么我们也关闭这个socket。
4.设置SO_KEEPALIVE选项,并修改内核参数
系统查看TCP状态常用命令
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TCP的超时重传
由于下层网络协议IP协议是不可靠的协议,因此会出现丢报,重包以及乱序等等的问题。而TCP需要提供可靠数据传输服务。因此TCP有两套独立机制来实现重传
(1)重传计时器:发送一个数据报文,在规定时间内发送方需要收到另一端的ACK响应,Tcp_ip_abort_interval(超时时间)
(2)快速重传:TCP累积确认无法返回新的ACK或者说当ACK包含的选择确认信息SACK表明出现失序报文段时
TCP的数据流与窗口管理
TCP流量控制机制:通过动态调节窗口大小来控制发送端的操作,确保接收端不会溢出
延迟ACK(delay_ACK)
(1)避免窗口综合征
(2)发送数据时将ACK捎带发送,不必单独发送ACK
(3)如果延迟时间内有多个数据段到达,运行协议栈发送一个ACK确认多个报文段
Nagle 算法
:TCP连接中有在传数据(即已经发送但是没有ACK确认),小于MSS的报文段就不能发送,直到在传数据收到ACK。并且在收到ACK确认后,TCP需要收集小数据整合到一个数据包在发送。RTT控制这发包速率
是为了减少广域网的小分组数目,从而减小网络拥塞的出现;
优点:是自适应的,确认到达的越快,数据也就发哦送的越快;而在希望减少微小分组数目的低速广域网上,则会发送更少的分组;
关闭Nagle算法
使用TCP套接字选项TCP_NODELAY可以关闭套接字选项;
流量控制和窗口管理
TCP报文首部字段:win用于表示接收端可用缓存空间的大小,以字节为单位
滑动窗口
每个TCP/IP主机支持全双工数据传输,因此TCP有两个滑动窗口:一个用于接收数据,另一个用于发送数据。
1)关闭:即窗口左边界右移,当发送数据得到ACK确认时,窗口会减少
2)打开:即窗口右边界右移,发送数据量增加,当以确认数据被处理接收端可用缓存加大,窗口变大
3)收缩:窗口右边界左移
零窗口与TCP的持续定时器
零窗口:TCP是通过TCP接收方的窗口实现流量控制的。而零窗口是接收方发送的窗口大小为0,此时阻止数据发送直到窗口更新为止
持续定时器:专门为了零窗口而设计,(如果更新窗口报文丢失,会产生死锁的情况)当发送端收到零窗口的确认时,就启动坚持计时器,当坚持计时器截止期到时,发送端TCP就发送一个特殊的报文段,叫探测报文段,这个报文段只有一个字节的数据。探测报文段有序号,但序号永远不需要确认,甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP,确认已丢失,必须重传。
糊涂窗口综合症
基于窗口控制机制,尤其是不使用大小固定的报文段的情况;交换数据段大小不是全长而是一些较小的数据段
TCP的拥塞控制
防止网络因为大规模的通信负载而造成瘫痪,基本方法是认为网络即将进入拥塞状态(或者由于拥塞而出现路由器丢包的情况)时减少TCP的传输
拥塞窗口(cwnd):反应网络传输能力的变量 发送端实际可用的窗口大小
W = min(cwnd, awnd(接收窗口大小))
最佳窗口大小:接近带宽大小
慢开始和拥塞避免
发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。但只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数
慢开始:当一个新的TCP连接建立或者检测到由于重传超时(RTO)而导致的丢包,启动慢开始算法
慢开始
通常在刚刚开始发送报文段时,先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ,可以使分组注入到网络的速率更加合理。
拥塞避免
让拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的cwnd 拥塞窗口cwnd加1cwnd ,而不是加倍cwnd 。这样拥塞窗口cwnd按线性规律缓慢增长,比慢开始算法的拥塞窗口增长速率缓慢得多。
不论是慢开始还是拥塞避免只要网络出现拥塞(没有按时到达)时,就把ssthresh的值置为出现拥塞时的拥塞窗口的一半(但不能小于2),以及cwnd置为1,进行慢开始。 目的是迅速减少主机发送到网络中的分组数,使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。
快重传和快恢复
拥塞控制算法需要判断当收到重复的确认报文端时,网络是否真的发生了阻塞,或者说TCP报文端是否真的丢失了。具体的做法是:发送端如果连续收到3个重复的确认报文端,就认为是拥塞发生了。然后它启用快速重传和快速恢复算法来处理拥塞。
快速重传(Fast retransmit):要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方),而不要等到自己发送数据时捎带确认。
如果在超时重传定时器溢出之前,接收到连续的三个重复冗余ACK(其实是收到4个同样的ACK,第一个是正常的,后三个才是冗余的),发送端便知晓哪个报文段在传输过程中丢失了,于是重发该报文段,不需要等待超时重传定时器溢出,大大提高了效率。这便是快速重传机制。
快恢复算法:
(1)当发送方连续收到三个重复确认,就执行“乘法减小”算法,把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。然后立即重传丢失的报文段,并将CWND设置为新的ssthresh(减半后的ssthresh)
(2)由于发送方现在认为网络很可能没有发生拥塞,因此与慢开始不同之处是现在不执行慢开始算法(即拥塞窗口cwnd现在不设置为1),而是把cwnd值设置为慢开始门限ssthresh减半后的数值,然后开始执行拥塞避免算法(“加法增大”),使拥塞窗口缓慢地线性增大。
(3)每次收到一个重复的确认时,设置CWND=CWND+SMSS(拥塞窗口加1).此时发送端可以发送新的TCP报文段
(4)当收到新数据的确认时,设置CWND=ssthresh(ssthresh是新的慢启动门限值,由第一步计算得到)
原因是因为该ACK确认了新的数据,说明从重复ACK时的数据都已收到,该恢复过程已经结束,可以回到恢复之前的状态了,也即再次进入拥塞避免状态。
总结:
当出现超时重传和冗余ack的时候慢启动门限都要设置为当前发送窗口的一半
不同的就是超时重传还得将拥塞窗口大小设为1,重新进入慢启动,而冗余ack则是将拥塞窗口设为慢启动门限大小并且进入拥塞避免
TCP的保活机制
保活计时器:当计时器被激发时,连接端发送一个保活探测报文,另外一端接收报文会回应一个ACK响应
报活机制:一般为服务器应用提供,这样服务端就可以知道客户端释放崩溃或者离开,从而决定是否绑定资源给客户端
如果一个给定的连接在两小时内没有任何的动作,则服务器就向客户发一个探测报文段,客户主机必须处于以下4个状态之一:
1. 客户主机依然正常运行,并从服务器可达。客户的TCP响应正常,而服务器也知道对方是正常的,服务器在两小时后将保活定时器复位。
2. 客户主机已经崩溃,并且关闭或者正在重新启动。在任何一种情况下,客户的TCP都没有响应。服务端将不能收到对探测的响应,并在75秒后超时。服务器总共发送10个这样的探测 ,每个间隔75秒。如果服务器没有收到一个响应,它就认为客户主机已经关闭并终止连接。
3. 客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应,这个响应是一个复位,使得服务器终止这个连接。
4. 客户机正常运行,但是服务器不可达,这种情况与2类似,TCP能发现的就是没有收到探查的响应。
Linux系统设置的系统变量参数:net.ipv4.tcp_keepalive_time , net.ipv4.tcp_keepalive_intvl 和 net.ipv4.tcp_keepalive_probrs分别7200s(2H), 75s, 9
长连接与短连接
短连接
过程 :client向server发起连接请求,server接到请求,然后双方建立连接。client向server 发送消息,server回应client,然后一次读写就完成了,这时候双方任何一个都可以发起close操作,不过一般都是client先发起 close操作
优点:管理比较简单,存在的连接都是有用的连接,无需额外的控制手段
缺点:占用大量资源,产生大量的TIME_WAIT状态,如果短时间内产生大量的短连接
客户端的操作系统的socket端口和句柄被用尽,系统无法再发起新的连接
长连接
使用了TCP的保活机制,可参考上方的解释
过程:
client向server发起连接请求
server收到请求,双方建立连接
收发数据
。。。。。。。。。。。。。。。(利用TCP的保活定时器)
收发数据
断开连接
区别
长连接多用于操作频繁,点对点的通讯,而且连接数不能太多情况,。每个TCP连接都需要三步握手,这需要时间,如果每个操作都是先连接,再操作的话那么处理速度会降低很多,所以每个操作完后都不断开,次处理时直接发送数据包就OK了,不用建立TCP连接。例如:数据库的连接用长连接, 如果用短连接频繁的通信会造成socket错误,而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接,因为长连接对于服务端来说会耗费一定的资源,而像WEB网站这么频繁的成千上万甚至上亿客户端的 连接用短连接会更省一些资源,如果用长连接,而且同时有成千上万的用户,如果每个用户都占用一个连接的话,那可想而知吧。所以并发量大,但每个用户无需频 繁操作情况下需用短连好。
TCP KeepLive机制详解(英)http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
TCP 为什么三次握手而不是两次握手https://blog.csdn.net/lengxiao1993/article/details/82771768
Linux网络tcp连接大量CLOSE_WAIT和TIME_WAIT状态的出现和解决方法https://blog.csdn.net/lqglqglqg/article/details/54616380