TCP 协议特性总结
TCP协议特点
TCP协议段格式
TCP报文=TCP报头（首部）+TCP载荷
- 源/目的端口号：表示数据是从哪个进程来，到哪个进程去；
- 32位序号/32位确认号：针对多组数据进行详细区分
- 4位首部长度：描述TCP报头具体的长度（TCP报头长度可变，UDP报头长度不可变，固定8个字节）
- 6位保留：为了以后的扩展考虑
- 6位标志位
- URG：紧急指针是否有效
- ACK：确认号是否有效
- PSH：提示接收端应用程序立刻从TCP缓 冲区把数据读走
- RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
- SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
- FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段
- 16位窗口大小：
- 16位检验和：与UDP检验和作用相同：都是验证数据传输是否正确，但是不能保证数据安全性
- 16位紧急指针：标识哪部分数据是紧急数据；
- 选项：选项之前的部分是固定长度（20字节）（公式 ：选项长度=首部长度-20字节）
TCP原理
确认应答（安全机制）
示例图: 
A给B发了个消息，B收到后就会返回一个应答报文（ACK）,此时A收到应答之后，就知道刚才发的数据已经顺利被B接收。
考虑更复杂的情况
示例图: 
由于网络上可能存在“后发先至”，收到消息的顺序是可能存在变数的，变成了“去吃饭不？：不好”，“去学习不？：好”，这就跟原义不符。
为了解决上述后发先至问题，给传输的数据，和应答报文，都进行编号。
示例图: 
这样就可以通过序号来区分当前应答报文是针对那个数据进行的
实际上，由于TCP是面向字节流的，TCP的序号也是按照字节来编号的
确认序号的取值，是收到的数据的最后一个字节的序号+1
小结：TCP可靠传输能力，最主要就是通过确认应答机制来保证，通过应答报文（ACK）,就可以让发送方清楚的知道传输是否成功，进一步的引入了序号和确认序号，针对多组数据进行详细的区分
超时重传（安全机制）
上述讨论确认应答的时候，只是讨论了顺利传输的情况，并未讨论传输出现问题的情况（例如丢包）
以下是丢包的两种情况
第一种情况：数据丢失
第二种情况：ACK丢失
第二种情况重传数据，可能会导致主机B收到很多重复数据。TCP就要对其进行去重以及重新排列。
小结：由于去重和重新排序机制（都依赖于TCP报头的序号）的存在，发送方只要发现ACK没有按时到达，就会重传数据，即使重复了，顺序乱了，接收方都能很好地处理。
连接管理（安全机制）(面试高频题)
在正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接
三次握手
建立连接阶段的几种状态：
1.LISTEN ：
监听对方建立连接请求，表示服务器已经准备就绪，随时可以有客户端来建立连接，相当于手机开机，信号良好，随时可以接听他人的电话。
2.SYN_SEND：属于请求连接，此时发送的报文段，不能携带数据。
3.SYN_RECEIVE：接收到对方的连接建立请求。
4.ESTABLISHED ：
连接建立完成，接下来可以进行正常通信，相当于拨打电话，对方接通。当客户端在此状态下，发送的ACK报文段可以携带数据，
所谓的三次握手，本质上是“四次”交互。
通信双方，各自要向对方发起一个“建立连接”的请求，同时，再各自向对方回应一个ack。中间两次交互是可以合并成一次交互的，因此就构成了“三次握手”。
四次挥手
四次挥手和三次握手非常类似，都是通信双方各自向对方发起一个断开连接的请求，在各自给对方一个回应。
建立连接阶段的几种状态：
1.FIN_WAIT_1:客户端主动调用close时，向服务器发送结束报文段(FIN)，同时进入FIN_WAIT_1；
2.CLOSE_WAIT:（出现在被动发起断开连接的一方）
当客户端主动关闭连接（调用close），服务器会收到结束报文段(FIN)，服务器返回确认报文段(ACK)并进入CLOSE_WAIT；
3. FIN_WAIT_2:客户端收到服务器对结束报文段的确认(ACK)，则进入FIN_WAIT_2，
开始等待服务器的结束报文段(FIN)；
4. LAST_ACK:进入CLOSE_WAIT后说明服务器准备关闭连接（需要处理完之前的数据）；当服务器真正调用close关闭连接时，会向客户端发送FIN，此时服务器进入LAST_ACK状态，等待最后一个ACK到来（这个ACK是客户端确认收到了FIN）
5.TIME_WAIT:（出现在主动发起断开连接的一方）
假设是客户端主动断开连接，当客户端进入TIME_WAIT状态的时候，相当于四次挥手已经挥完了，客户端收到服务器发来的结束报文段(FIN)，进入TIME_WAIT，并发出LAST_ACK；
6.服务器收到了对FIN的ACK，彻底关闭连接,进入CLOSED状态
滑动窗口（效率机制）
上述讨论的确认应答策略，对每一个发送的数据段，都要给一个ACK确认应答。收到ACK后再发送下一个数据段。这样做使得性能较差。
此时就要引用滑动窗口机制来提高性能。
具体操作：批量发送，批量等待，使用一份等待时间来等待一组数据的多个ACK，本质上就是降低确认应答等待ack消耗的时间。
窗口大小:无需等待确认应答而可以继续发送数据的最大值,上图窗口大小就是4000；
- 发送前四个段的时候，不需要等待任何ACK，直接发送；
- 收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
下面是针对丢包的两种情况进行的讨论
情况一：数据包已经抵达，ACK丢了。
这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认；
情况二：数据包就直接丢了。
上述机制也被称为“快速重传机制”。
流量控制（安全机制）
流量控制是一种干预发送窗口大小的机制
流量控制的工作就是根据接收方的处理能力（通过查看接收方接受缓冲区的剩余大小），来协调发送方的发送速率
拥塞控制（安全机制）
流量控制考虑的是接收方的处理能力，接下来讲述的拥塞控制则是考虑传输过程中中间节点的处理能力，二者共同决定发送方的窗口大小（二者较小值）
拥塞控制，本质上就是通过实验的方式，来逐渐找到一个合适的窗口大小。
- 0轮时窗口大小是1单位，已非常慢的速度发送数据，如果传输顺利，就使窗口大小扩大一倍。
- 初始阶段，由于初始窗口比较小，每一轮不丢包就会使窗口大小扩大一倍（指数增长）。
- 当增长速率达到阈值后，此时指数增长，就转化为线性增长（前提是不丢包的情况）。
- 当传输过程中一旦出现丢包，说明此时发送的速率已经接近网络的极限，这时就把窗口大小一下缩成很小的值（重复上述指数增长和线性增长的过程）
拥塞窗口不是固定数值，而是一直动态变化的。
TCP是个非常复杂的协议，不仅仅只有上述提到的特性！！！如果想了解更多TCP特性，可以去翻阅RFC标准文档。
