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