TCP实现的一些特点介绍

TCP协议传输特点可以说是可靠性高于一切，其他的一切优化升级都是在保证其传输数据可靠的前提下进行。基于此，TCP会通过校验、序列号、确认应答、重发控制、连接管理以及窗口控制等机制解决数据破坏、丢包、重复和分片顺序混乱等问题。

首先，来看下TCP最基本的传输机制。

TCP在IP这种无连接的网络上也能实现高可靠性链路，就在主机之间进行数据交换时建立虚拟连接，建立连接的方式就是我们经常说的“三次握手建立连接，四次挥手断开连接”。说“三次握手”似乎给人感觉就是握手三次似的，其中只是需要三个数据包建立连接。一般建立连接两包就够了，即请求与响应，但网络是错综复杂的，在这错综复杂的环境下要考虑诸多因素，例如防止旧的重复连接造成初始化混乱、完成双方初始序列号同步，也避免资源浪费。另外，服务端反馈的数据包含SYN和ACK两个内容，用于确认应答和序列号同步。四次挥手也是，都要求对双方给予请求切断连接的确认应答。

TCP发送数据是以段的形式进行的，这在前面也有过相关描述。在建立连接的同时就要确定发送数据包的单位，也称之为最大消息长度——MSS（Maximum Segment Size）。之后的通讯数据长度就以双方约定好的长度进行发送，每发送一包数据都会有与之相适应的响应来保证传输的可靠性，当然，也在改基础之上做了优化。

基本的通讯机制建立了，前辈大佬们又在保证可靠性的前提下进行了优化。

1是窗口控制

如下图，我们原本想着是如左图所示的传输方式，但大佬们想到了图右的做法，就是“利用窗口控制提高速度”。发一包等一个确认太慢了，所以就想到了以更大的单位进行确认，只要不大于这个单位就一包接着一包的发。例如下图右，这个更大的单元就是窗口，窗口大小就是指无需等待确认应答而可以继续发送数据的最大值，类似于FPGA的FIFO，下图窗口大小就是4个段。

具体来看，如下图，白色区域为窗口，窗口内的数据即使没有收到确认应答也可以继续发送，当收到确认应答等候，窗口就会滑动到确认应答的序列号位置。这种机制叫做滑动窗口控制。另外，如果我们连续发了4包，没有收到1001到2001段的确认应答，但收到了3001到4001的确认应答，那么久无需等待1001到2001段的确认应答了。这就涉及到了接下来要说的重发控制。

丢段有两种可能，一是其实数据收到了，但确认应答丢了，二是确实没收到数据。

对第一种，如下图，通过上述机制可在一定程度上避免，即使部分确认应答丢失也不会触发重发机制。

对于第二章，确实数据丢失了，如下图，如果没有收到1001~2000字段的数据，主机B就会不断的发送已接收1~1000的确认应答，以请求1001~2000字段内容，如果连续收到三包同样的确认应答就进行重发，这种机制叫做高速重发控制。

最后，本书还提到了流控制和拥塞控制两种机制，这也是在其它通信方面会用到的。

首先来说流控制，其实上文说的窗口控制是由接收端决定的，而且还是一个弹性缓冲区，可大可小。接收端会时不时的给发送端发送一个叫做“窗口探测的数据段”，该数据段仅含有一个字节以获取最新的窗口大小信息。

那为什么要做流控制，因为接收端接收的数据来源可能很多，如果主机A、B再沟通之时来个第三者插入，而且这个第三者还挺吸引人，那么主机B就会减少与A的沟通时间，转而与第三者进行互动，如果这时A还是可劲的给数据，可能会被B忽视，从而触发A的重发机制，B还是丢弃，这样操作网络流量的浪费，所以B会好心的告诉A我在忙，你发慢点，调节下窗口大小。A就明白了，慢慢的发送，如下图所示。

什么是拥塞控制？

计算机网络都处于一个共享环境，你发的数据多点，别人就得收敛点，如果现在网络繁忙，你发的多可能就丢失的多。基于此，大佬们设计了一个拥塞控制机制，其实就是慢启动，或者说试探性发送数据，一开始我少发点，看看行情，觉得行情不错我再多发点，然后发现依旧不错，那就再多发点，这样一个逐步调节吞噬网络带宽的过程。大致知道就好，反正FPGA也很少去做TCP协议。

快来扫描下方二维码关注公众号，领取站内所有相关资料，所有哦~

有建议、有需求、有疑问、联系我