【TCP粘包的处理、三次握手四次挥手、TIMEWAIT状态、滑动窗口】

TCP主要特点

1. TCP是面向连接的运输层协议。
2. 每一条TCP连接只能有两个端点。
3. TCP提供可靠交付的服务。
4. TCP提供全双工通信。
5. 面向字节流。
   
   TCP不需要解释字节流内容。

TCP粘包

1.为什么会产生粘包现象？
多次发送的数据被一次收到的情况。
2.怎么解决粘包问题？
解决a : 每一次send() 都有一个recv()
解决b: 加起始标记和结束标记。
解决c: 报文中加起始标记和数据的长度。

应用数据被分割成T C P认为最适合发送的数据块。这和 U D P完全不同，应用程序产生的 数据报长度将保持不变。由 T C P传递给I P的信息单位称为报文段或段。

超时重传：

当T C P发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

T C P将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， T C P将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
乱序重排：
• 既然T C P报文段作为I P数据报来传输，而I P数据报的到达可能会失序，因此 T C P报文段的到达也可能会失序。如果必要， T C P将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层（因为每个数据包都有序号，可以标识到）

六位标志位含义：

TCP头部最长60字节，而头部中的选项部分的长度最大是40字节（60-20）。

拥塞控制：
**滑动窗口（TCP可靠传输的实现）：**流量控制
通过滑动窗口控制进入网络的流量，在滑动窗口内的数据都可以不用得到确认直接发送，提高了传输的速率。
快重传：
当发送端发送的数据丢失后，每次收端收到数据都回复丢数据那个序号，累计三次就使得丢失的数据重新发送。这样就不用等到超时再发送数据，提高了传输的速度。

---

三次握手：

TCP三次握手发生于connect 时，四次挥手发生在close。

在三次握手开始时A 和B 都要先创建一个传输控制块TCB。

三次握手的简略步骤：
1.A发送SYN位（请求报文段，SYN=1）,选择初始序号x 给B。

2.B收到报文段后同意建立连接，向A发送确认（ACK=1，SYN=1），确认号ack=x+1,为自己选择初始信号seq=y。

3.A收到B确认后，继续发确认给B，ACK置为1，自己的序号seq=x+1,确认号ack=y+1。这时A已经进入ESTABLISHED(已连接状态），B在收到报文后也进入此状态。

思考：为什么A最后还要发送一次确认？

这主要是防止A传的已经失效的连接请求报文段突然又传送到 了B，B误认为是A新发送的请求报文而接收连接，因而产生错误。

四次挥手：

1.A关闭连接，发送报文段(结束标志位）FIN=1，seq=u(u 是上次已传送数据的最后一个字节的序号+1给B。
2.B收到后即发出确认（ACK=1），发送确认号ack=u+1, 发送自己序号v。此时TCP连接处于半关闭状态，B发送消息A扔要接收。
3.B没了要给A发送的数据，就发送结束标志位FIN=1，ACK=1，ack=u+1,seq=w。
4.A收到B的数据后必须对此确认，ACK置为1，ack=w+1,seq=u+1。此时进入到TIME-WAIT状态，此时TCP还没有释放掉。必须经过时间等待计算器设置的时间2MSL后，A才进到CLOSED状态。A的close要比B要晚一些。

思考：为什么A在TIME-WAIT状态必须等待2MSL的时间呢？

1.为了保证被动关闭端发送的最后一个FIN报文段能够到达主动关闭端（◼ 可靠的终止 TCP 连接。如果主动关闭端部等待也许收不到被动关闭端发过来的FIN和ACK，就不是可靠的TCP连接）. B如果因为A传送的数据丢失可以再超时重传，A就 能在2MLS时间内收到这个重传的FIN+ACK报文段。如果不等待2MLS立即释放，将无法收到B的重传。

2.防止已失效的连接请求报文段出现在本连接中。（◼ 保证让迟来的 TCP 报文有足够的时间被识别并被丢弃。）给充足的时间让残存的包消失，防止下一次连接发生误会。（保证下次传输是干净的，没有残存包）

---

附：2.time_wait状态产生的原因
1)为实现TCP全双工连接的可靠释放
由TCP状态变迁图可知，假设发起主动关闭的一方(client)最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方(server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源(client方的local_ip,local_port)不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。
2）为使旧的数据包在网络因过期而消失
为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接:(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。本文前面介绍过，TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是"感知"不到的。这样就可能发生这样的情况:前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层(而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的)，从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。

---

TCP状态转换：