当我们在学校学习网络和网络传输层时，我们可能总是感到枯草乏味、枯燥难懂。但事实上，在生产环境中，这是一个非常常见的问题，如果你不明白，可能会更困惑。
生产环境遇到的问题
谈谈我今年遇到的TCP层的几个问题。
- 问题1：长短连接的选择？
- 问题2：连接超时了，为什么超时的时间是128s左右
- 问题3：系统不可达，80端口连不通了，可是本地查看80端口是正常的，这是为什么？
- 问题4：客户端连接池很多处于CLOSE-WAIT？
传输层
要充分解释这些问题，我们需要对传输层的协议有非常深入的了解。网络层可能离软件开发人员有点远，但传输层，特别是广泛使用的TCP，与我们的工作密切相关。
传输层的目的
- 从上到下依次包括 应用层、传输层、网络层、链路层、物理层。
- 应用层就是对应不同的数据
- 通过网络层，包已经能够正确的被路由到对应的主机
我们需要有机制将不同的应用程序映射到同一主机的网络层，并确保数据的准确到达。
区别不同的应用-UDP
- 每个应用程序对应一个端口，端口信息也封装在包中，以确定数据包属于哪个应用的。
- UDP的报文格式为传输层的简单协议，也很简单。
保证传输的质量-TCP
UDP不保证数据的准确传输和质量保证。如果包丢失，网络层不会重新传输。因此，传输层还设计了一种新的协议TCP。除了端口映射外，还在应用层和网络层之间增加了一些处理机制，以确保传输质量。
传输的质量对应用而言实际上就2个方面：
- 收到了对端发出的所有数据。
- 对端发出的所有数据都按顺序收到。
- C1.C2表示两个客户端与app1有数据交互。
- 假设app1向C2发送数据，app1的传输层应确保所有数据都发送到C2，以确保没有丢包事件。
- 不丢包不是真的不丢包，而是如果丢包还能重传，保证数据最终收到。
- 假设C1向app1发送数据，则需要按顺序正确接收发送的数据。
核心：Tcp的具体运行机制
TCP要干什么
依据以上的描叙，TCP主要的要做2件事：
- 防止丢包
a.丢包重传
一般情况下，收到包后会向发送者发送ack信号。
超时未收到会使用重传机制。
b. 减少丢包
告诉我你的窗口:感受对端的处理能力。
丢包原因及优化：感受网络拥塞，控制传输速率。
- 保证包到达的顺序。
使用序列号：确保数据包按正确顺序交付。
基本试探-建立连接
正如上面提到的，TCP首先要试探两个对端的收发能力，试探过程如下：
主要是试探并确认了：
- 确认A发送数据的能力
- 确认B接收数据的能力
- 确认B发送数据的能力
- 确认A接收数据的能力
这个试探过程也叫做三次握手，通过三次握手两个应用程序之间建立了一条TCP连接。
具体的过程和状态
TCP连接是内核抽象给应用程序使用的。
我们可以更具体地看看这个过程，包括建立连接之前、中间和之后。
三次握手的状态随时间变迁图如下：
三次握手就是三次发包的过程：
- 1、发起端发送SYNC包：SYN，seq=x，自己进入Sync-Sent状态
注意：seq=x，下面还会有详细描述 - 2、监听端收到SYNC包，发送SYN,ACK,seq=y,ack=x+1，进入Sync-RCVD状态
- 3、发起端收到SYNC，ACK包,发送 ACK,seq=x+1,ack=y+1，进入Established状态
a、RTT表示发送数据到收到ACK的时间 - 4、监听端收到ACK包，进入Established状态
accept和LISTEN
服务器的内核使用accept系统调用来帮助建立连接。服务器调用accep函数后，处于LISTEN状态。可以等待客户端建立连接，并使用netstat查看LISTEN状态的连接。
# netstat -alpnt Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:11110 0.0.0.0:*
- *0.0.0.0:**表示接受网络上所有端口的连接。
- 内核使用socket作为真正的tcp连接对象，但accept的socket是特殊的，没有建立tcp连接。
ESTABLISHED
三次握手成功后，这个连接将保存在内存中。
# netstat -alpnt Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 9.13.73.14:38604 9.13.39.104:3306 ESTABLISHED 26100/java tcp 0 0 9.13.73.14:32926 9.21.210.17:8080 ESTABLISHED 26100/java
- ESTABLISHED:已建立连接。
- 连接的信息包括本地IP端口地址和远程IP端口。
a.本地9.13.73.14:38604与远程9.13.39.104:3306建立连接。
b.本地9.13.73.14:32926与远程9.21.210.17:8080建立连接。
对于问题3的回答
有一次，我们的服务无法到达，即80端口无法连接，但登录机器并发送80端口仍然是正常的列表状态，但我们发现许多连接处于Sync-RCVD状态。查看日志，我们发现系统已经运行，完全有理由怀疑服务建立连接的过程是由内存引起的。
因此，尽管80端口的LISTEN状态正常，但外部无法正常连接。
TCP报文格式和信息交换
三次握手中发的数据报都是TCP报文，TCP报文格式如下：
从这个报文格式和上面三次握手的过程可以看出：
- SYN标记位为1说明这个报文是一个SYN类型的包，用于握手
- 发起端发送SYNC包：SYN，seq=x
- 监听端收到SYNC包后，也发送自己的SYN包：SYN，seq=y
- 发起端和监听端的起始序号x和y是32位序号，它们是系统随机生成的
- 在SYN报文中交换了初始序列号之后，这个序列号就一直单调递增
- 初始序列号ISN还用于关闭连接的吗？
- ACK标记位为1说明这个报文是一个ACK类型的包
- 32位确认号
- 监听端收到SYNC包，还发送ACK,ack=x+1，小于x+1的全部字节已经收到，**期待下一次收到seq=x+1的包
- 发起端收到SYNC，发送ACK,ack=y+1，小于y+1的全部字节已经收到,期待下一次收到seq=y+1的包**
- 用于SYN和ACK连接的包的数据为空
另外报文格式中还包含下面信息：
- 接收到的SYN包的窗口大小代表对方的接收窗口的大小
- RST标记位为1: 可以用于强制断开连接
- PSH标记位为1：告知对方这些数据包收到后应该马上交给上层的应用
- 选项中的MSS:TCP允许的从对方接收的最大报文段。
连接建立后，传输数据
连接建立后，数据可以传输。
回顾上述TCP主要保证的两件事和基本思路：
- 使用序列号seq确保数据包按正确的顺序交付。
- ack信号和超时重传机制防止丢包。
- 用窗户减少丢包。
建立连接的过程为这件事情做好了铺垫。让我们来看看具体的运行机制。
超时重传和ACK深层含义
- 发送出去的数据如果一直没收到ack就重传，需要确定多久时间没收到就重传
- 接收端如果多次收到同一个seq的数据就丢弃
- 需要大于RTT,又不能太大
- RTT是在动态变化的，内核采样，使用RTO来计算
每当遇到一次超时重传时，都会将下一次超时间隔将设置为以前值的两倍。多次超时，表明网络环境差，不宜频繁重复发送，就会每次将成为原来的两倍，可设置最大重传次数。
现在就可以回答问题2了
问题2：连接超时了，为什么超时的时间是128s左右
初始1S超时，然后因为系统设置的重传次数是6，重传了6次，1+2+4+8++16+32+64加起来大约是128s左右。
可以批量提交ack
seq=4的ack没有正确的收到， 但如果在超时时间内收到了ack=6 则表示6之前的seq都已经正确接收到了 seq=4的数据也不会重传
滑动的窗口和右移的指针
发送端的socket缓冲区，示意图如下：
- 已发送并收到ACK确认的数据
- 已发送但未收到ACK确认的数据
- 未发送但总大小在接收方处理范围内
- 未发送但总大小超过接收方处理范围
窗口右移
- 图示的发送窗口和收到ack报文中的window大小相关
- ack指针右移则可用窗口变大
- 发送seq指针右移则可用窗口变小
接收端的socket缓冲区，示意图如下：
- ACK包，ack=16,且（window=16）
- 已成功接收并确认的数据
- ack指针右移则可用窗口还是右移
- 接收窗口是未收到数据但可以接收的数据
- 可用窗口和应用程序获取数据的能力有关，如果应用程序一直不从socket缓冲区获取数据，则接收窗口也会变得越来越小
- 滑动窗口并不是一成不变的。当接收方的应用读取数据的速度非常快的话，接收窗口可以很快的空缺出来。
- 通过使用窗口可以起到流控的作用，可以减少不必要的丢包，并减少网络拥塞。
顺序的保证
如下图：
假设接收端未收到16，17的报文， 儿后面18-27的数据都收到了， 则并不会发ack给发送方 当发送端超时重传16，17之后，且接收端收到之后 则接收端返回ack=28的报文给发送端。
- ack指针只能右移，不能往回走
- 这样可以保证顺序交付
传输的总结
TCP的主要功能是防止包丢失，保证包到达的顺序。本节通过描述TCP的具体工作机制证明了TCP确实达到了这一目的。
高并发系统和关闭连接的设计
最后，我完成了TCP连接建立和传输的基本原理和过程，认为我可以松一口气。
关闭连接是TCP的一部分，但与TCP相比，这并不重要。
但最近发现，在生产活动中，大家也非常关注TCP四次挥手的过程。主要原因是系统并发量大。
TCP连接是衡量系统并发量的重要因素，如果关闭连接异常，必然会影响系统的运行。
对于连接对并发量的影响，首先可以分析开头提出的问题。
长连接 VS 短链接
- 短连接一般只会在 client/server间传递一次请求操作
- 这时候双方任意都可以发起close操作
- 短连接管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
- 通常浏览器访问服务器的时候一般就是短连接。
- 长连接
- Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
- 所以一条连接保持几天、几个月、几年或者更长时间都有可能，只要不出现异常情况或由用户（应用层）主动关闭。
- 长连接可以省去较多的TCP建立和关闭的操作，减少网络阻塞的影响，
- 减少CPU及内存的使用，因为不需要经常的建立及关闭连接。
- 连接数过多时，影响服务端的性能和并发数量。
所以，长短连接怎么选择呢？
- 所以对于并发量大，请求频率低的，建议使用短连接。
- 对于服务端来说，长连接会耗费服务端的资源
- 如果有几十万，上百万的连接，服务端的压力会非常大，甚至会崩溃
- 对于并发量小，性能要求高的，建议选择长连接
- 比如mysql连接池
TCP关闭连接
长短连接的选择如此重要，如果连接不能正确关闭，就会造成很大的麻烦。TCP设计了完善的关闭机制，关闭连接过程如下：
- 关闭连接发起方 发起第一个FIN,处于FIN-WAIT1
- 关闭连接被动方的内核代码回复ACK，此时还可以发送数据，处于Close-WAIT状态
- 关闭连接被动方等待应用程序发送FIN，如果上层应用一直不发FIN，就还可以继续发送数据
- 关闭连接发起方收到ACK后处于FIN-WAIT2状态，还可以接收数据自己不再发送数据
- 关闭连接被动方直到应用程序发出FIN，处于LAST-ACK状态
- 关闭连接发起方收到FIN，会发送ACK，自己会处于TIME-WAIT状态，此时
- 若是关闭连接被动方收到ack,就close连接
- 若是是关闭连接被动方没收到ack,则会重传FIN
TIME-WAIT等多长时间
MSL是报文最大的生存时间。它是任何报文在网络上存在的最长时间。超过这个时间，报文将被丢弃，即MSL的两倍。TCP的TIME_WAIT状态也称为2MSL等待状态。
等待2MSL时间的主要目的是害怕对方没有收到最后一个ACK包，所以对方会在超时后重发第三次握手的FIN包。
若之前交互异常，收到重传的FIN最多使用2MSL，因此结论是等待2MSL的时间。
最后一个问题
有一次，同步数据的应用从一个服务器并发同步大量数据，这个过程比较缓慢，所以考虑如何加快同步。
- 首先查看网络连接，发现20个连接的连接池中有很多处于close_wait状态的连接。
通过以上分析，我们知道Close-WAIT是对方可能认为连接空闲时间太长而关闭的连接，但我在这里使用的连接池还没有发送FIN释放包。
可见看出，连接的数量并没有成为系统的瓶颈，我们可以继续增加并发线程的数量，以增加并发量。
