【网络】TCP协议理论（1）

一、TCP协议简介

TCP全称为“传输控制协议（Transmission Control Protocol）”，TCP 是面向连接的、可靠的、基于字节流的传输层通信协议，同时TCP协议是当今互联网当中使用最为广泛的传输层协议，没有之一。

• 面向连接：使用TCP进行数据传输，不能像 UDP 协议一样直接发送数据，必须先进行建立连接才能够进行数据传输。
  
• 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端。
  
• 字节流：用户消息通过TCP协议传输时，消息可能会被操作系统「分组」形成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法准确的读出一个有效的用户消息的。
  
• 有序性：TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。
  

TCP协议被广泛应用，其根本原因就是提供了详尽的可靠性保证，基于TCP的上层应用非常多，比如HTTP、HTTPS、FTP、SSH等，甚至MySQL底层使用的也是TCP。

1、浅谈可靠性

为什么网络中会存在不可靠呢？

现代的计算机大部分都是基于冯诺依曼体系结构的，输入设备、输出设备、内存、CPU都在一台机器上，但这几个硬件设备是彼此独立的，如果它们之间要进行数据交互，就必须要想办法进行通信。

因此这些设备实际是用“线”连接起来的，其中连接内存和外设之间的“线”叫做IO总线，而连接内存和CPU之间的“线”叫做系统总线。由于这几个硬件设备都是在一台机器上的，因此这里传输数据的“线”是很短的，传输数据时出现错误的概率也非常低。

但如果要进行通信的各个设备相隔千里，那么连接各个设备的“线”就会变得非常长，传输数据时出现错误的概率也会大大增高，此时要保证传输到对端的数据无误，就必须保证可靠性。

所以网络中存在不可靠的根本原因就是：因为通信双方距离变长了

数据在长距离传输过程中就可能会出现各种各样的问题，而TCP就是在此背景下诞生的，TCP就是一种保证可靠性的协议。

2、UDP协议存在的意义

按照道理来说TCP协议是一种可靠的传输协议，而UDP协议是一种不可靠的传输协议，那UDP协议这种不可靠的协议存在有什么意义呢？

在网络中不可靠和可靠是两个中性词，它们描述的都是协议的特点。

• TCP协议是可靠的协议，也就意味着TCP协议需要做更多的工作来保证传输数据的可靠性，因此TCP使用起来一定比UDP复杂，并且维护成本特别高。
• UDP协议是不可靠的协议，也就意味着UDP协议无论是使用还是维护都足够简单。

TCP和UDP各有各的适用场景，网络通信时具体采用TCP还是UDP完全取决于上层的应用场景。如果应用场景严格要求数据在传输过程中的可靠性，那么就必须采用TCP协议，如果应用场景允许数据传输出现少量丢包，那么肯定优先选择UDP协议，因为UDP协议足够简单而且维护成本极低。

UDP用于对高速传输和实时性要求较高的通信领域：

• 包总量较少的通信如： DNS 、SNMP 等；
• 视频、音频等多媒体通信；
• 广播通信；

而TCP用于可靠传输的情况，

• 应用于文件传输。
• 重要状态更新等场景。

二、TCP的协议格式

TCP报头当中各个字段的含义如下(此处只需要简单理解，后面会有详细解释)：

• 源/目的端口号：表示数据是从哪个进程来，到发送到对端主机上的哪个进程。
  
• 32位序号：分别代表TCP报文当中每个字节数据的编号。
  
• 32位确认序号：接收端对发送方发送的报文的确认序号，是TCP保证可靠性的重要字段。
  
• 4位TCP报头长度：表示该TCP报头的长度，它的单位是4字节。
  
• 6位保留字段：TCP报头中暂时未使用的6个比特位，后续TCP的更新可能会对这些比特位赋予新的含义。
  
• 6位标志位：一些特殊标记，我们后续进行讲解。
  
• 16位窗口大小：描述当前主机的TCP接收缓冲区剩余空间的大小，这是保证TCP可靠性机制和效率提升机制的重要字段。
  
• 16位检验和：由发送端填充，采用CRC校验。接收端校验不通过，则认为接收到的数据有问题。（检验和包含TCP首部+TCP数据部分）
  
• 16位紧急指针：标识紧急数据在报文中的偏移量，需要配合标志字段当中的URG字段统一使用。
  
• 选项字段：TCP报头当中允许携带额外的选项字段，最多40字节，即TCP的报头长度为20~60。
  

TCP的解包和分用

TCP的解包：

当TCP从底层获取到一个报文后，虽然TCP不知道报头的具体长度，但报文的前20个字节是TCP的基本报头，并且这20字节当中涵盖了4位的首部长度。

因此TCP是「根据4位的首部长度」分离报头与有效载荷的：

1. 当TCP获取到一个报文后，首先读取报文的前20个字节，并从中提取出4位的首部长度：l e n lenlen，此时便获得了TCP报头的大小s i z e = l e n ∗ 4 b y t e size = len * 4 bytesize=len∗4byte。
   
2. 如果s i z e sizesize的值大于20字节，则需要继续从报文当中读取s i z e − 20 size − 20size−20字节的数据，这部分数据就是TCP报头当中的选项字段，读取完TCP的基本报头和选项字段后，剩下的就是有效载荷了。
   

4为首部长度的取值范围是 0000 ~ 1111，因此TCP报头最大长度为：15 × 4 = 60 b y t e 15 × 4 = 60byte15×4=60byte ，因为基本报头的长度是20字节，所以报头中选项字段的长度最多是40字节。

如果TCP报头当中不携带选项字段，那么TCP报头的长度就是20字节，此时报头当中的4位首部长度的值就为20 ÷ 4 = 5 = 0101 20 ÷ 4 = 5 = 010120÷4=5=0101

TCP的分用：

TCP的报头中含有了目的端口号，因此TCP可以提取出报头中的目的端口号，找到对应的应用层进程，进而将有效载荷交给对应的应用层进程进行处理。

三、确认应答机制

TCP 实现可靠传输的方式之一，是通过「序列号与确认应答」。

确认应答的简单理解

在进行网络通信时，发送端发出的数据后，它不能保证该数据能够成功被接收端收到，因为数据在传输过程中可能会出现各种各样的错误，只有当发送端收到接收端主机发来的确认消息后，发送端主机才能保证上一次发送的数据被接收端真正的收到了。

所以在TCP中，当的数据到达接收主机时，接收端主机会返回一个确认应答消息，表示已收到消息。

接收端发送的确认应答消息一般情况下是一个TCP报头，这个TCP报头中标志位ACK被置为1，表示这是一个确认应答消息。

当然，发送端为了确保数据没有丢包，发送端是需要等待一定的时间来接收确认应答（ACK)的，当发送端收到了ACK以后，才能够进行下一次的传输，如果超时了还没有收到ACK(此时有两种情况，一种是数据丢了，一种是ACK丢了)，那么发送端就会判定此次通信出现了丢包，于是触发TCP的「超时重传机制」，进行数据的重新发送，然后继续等待ACK。

当发送端收到了ACK以后，不用对收到的ACK再做应答，因为双方通信时总有最新的一条消息得不到响应，我们只要保证双方通信时发送的每一个核心数据都有对应的ACK响应就可以了。

序列号

上面双方在进行数据通信时，只有收到了上一次发送数据的ACK才能发下一个数据，那么此时双方的通信过程就是串行的，效率比较低下。

因此双方在进行网络通信时，允许一方向另一方连续发送多个报文数据，只要保证发送的每个报文都有对应的响应消息就行了，此时也就能对确认应答的等待时间进行了并发的利用。

但在连续发送多个报文时，由于各个报文在进行网络传输时选择的路径可能是不一样的，那么其各个路径的转发能力也是不一样的，因此这些报文到达对端主机的先后顺序也就可能和发送报文的顺序是不同的。但报文有序也是可靠性的一种，因此TCP报头中的32位序号的作用之一就是用来保证报文的有序性的。

TCP将发送出去的每个字节数据都进行了编号，这个编号叫做序列号。

比如现在发送端要发送3000字节的数据，如果发送端每次发送1000字节，那么就需要用三个TCP报文来发送这3000字节的数据。此时这三个TCP报文当中的32位序号填的就是发送数据中首个字节的序列号，因此分别填的是1、1001和2001。

此时接收端收到了这三个TCP报文后，就可以根据TCP报头当中的32位序列号对这三个报文进行顺序重排（该动作在传输层进行），重排后将其放到TCP的接收缓冲区当中，此时接收端这里报文的顺序就和发送端发送报文的顺序是一样的了。

确认应答号

TCP报头当中的32位确认应答号是告诉对端，我当前已经收到了哪些数据，你的数据下一次应该从哪里开始发。

以刚才的例子为例，当主机B收到主机A发送过来的32位序号为1的报文时，由于该报文当中包含1000字节的数据，因此主机B已经收到序列号为1-1000的字节数据，于是主机B发给主机A的响应数据的报头当中的32位确认序号的值就会填成1001。

确认应答号的含义：

1. 一方面是告诉主机A，序列号在1001之前的字节数据我已经收到了。
2. 另一方面是告诉主机A，下次向我发送数据时应该从序列号为1001的字节数据开始进行发送。

接收端可以根据：当前报文的32位序号与其报文的字节数，进而确定下一个报文对应的序号。

在TCP连续发送多个报文时，中间可能有某个报文出现了数据丢包，以上面的例子为例，主机A发送了三个报文给主机B，其中每个报文的有效载荷都是1000字节，这三个报文的32位序号分别是1、1001、2001。

如果这三个报文在网络传输过程中出现了丢包，最终只有序号为1和2001的报文被主机B收到了，那么当主机B在对报文进行顺序重排的时候，就会发现只收到了1-1000和2001-3000的字节数据。此时主机B在对主机A进行响应时，其响应报头当中的32位确认序号填的就是1001，告诉主机A下次向我发送数据时应该从序列号为1001的字节数据开始进行发送。

因此发送端可以根据对端发来的确认序号，来判断是否某个报文可能在传输过程中丢失了。

序列号与确认序列号的意义 ：

• 序列号可以保证数据的「有序性」，同时根据序列号也能够对发送端发送的重复报文（可能由于超时重传机制而导致的重复报文）进行识别并丢弃。
• 确认序列号可以保证数据的「可靠性」。

一种应答方式——捎带应答

捎带应答是TCP通信时最常规的一种方式，例如客户端给服务端发送了一条消息，当服务端收到这条消息后需要对其进行ACK应答，但如果服务端此时正好也要给客户端发生消息，此时这个ACK就可以搭顺风车，而不用单独发送一个ACK应答，此时服务端发送的这个报文既发送了数据，又完成了对收到数据的进行响应，这就叫做捎带应答。

捎带应答的方式提高了发送数据的效率，将两次网络发送合并成了一次。

此外，由于捎带应答的报文携带了有效数据，因此对方收到该报文后会对其进行响应，当收到这个响应报文时不仅能够确保发送的数据被对方可靠的收到了，同时也能确保捎带的ACK应答也被对方可靠的收到了。

为什么要用两套序号机制？

我们可以对TCP报头中的字段进行进一步的思考，为什么要用两套序号机制呢？

1. 如果发送端在发送数据时，将该序号看作是32位序号。
2. 接收端在对发送端发来的数据进行响应时，将该序号看作是32位确认序号。

这样的话TCP的报头还能够减少一些字节的数据，提高一定的效率，但实际TCP却没有这么做，根本原因就是因为TCP是全双工的，双方可能同时想给对方发送消息。

1. 双方发出的报文当中，不仅需要填充32位序号来表明自己当前发送数据的序号。
2. 还需要填充32位确认序号，对对方上一次发送的数据进行确认，告诉对方下一次应该从哪一字节序号开始进行发送。（这种发送方式其实就是捎带应答）

因此在进行TCP通信时，双方都需要有确认应答机制，此时一套序号就无法满足需求了，因此需要TCP报头当中出现了两套序号。

四、超时重传机制

在进行网络通信时，发送方发出去的数据在一个特定的事件间隔内如果得不到对方的应答（ACK），此时发送方就会进行数据重发，这就是TCP的超时重传机制。

TCP保证双方通信的可靠性，一部分是通过「TCP的协议报头」体现出来的，还有一部分是通过实现「TCP的代码逻辑」体现出来的。

超时重传机制实际就是发送方在发送数据后开启了一个定时器，若是在这个时间内没有收到刚才发送数据的确认应答报文，则会对该报文进行重传，这就是通过TCP的代码逻辑实现的，而在TCP报头当中是体现不出来的。

TCP 会在以下两种情况发生超时重传：

1. 数据包丢失
2. 确认应答丢失

• 当出现数据包丢失时，发送方是无法辨别是发送的数据报文丢失了，还是对方发来的响应报文丢失了，因为这两种情况下发送方都收不到对方发来的响应报文，此时发送方就只能进行超时重传。
• 如果是对方的响应报文丢失而导致发送方进行超时重传，此时接收方就会再次收到一个重复的报文数据，但此时也不用担心，接收方可以根据报头当中的32位序号来判断曾经是否收到过这个报文，从而达到报文去重的目的。
• 需要注意的一个细节是：当发送缓冲区当中的数据被发送出去后，操作系统不会立即将该数据从发送缓冲区当中删除或覆盖，而会让其保留在发送缓冲区当中，以免需要进行超时重传，直到收到该数据的响应报文后，发送缓冲区中的这部分数据才可以被删除或覆盖。

超时等待时间

超时重传的时间是很有讲究的。

• 超时重传的时间设置的太长，会导致丢包后对方长时间收不到对应的数据，进而影响整体传输的效率。
• 超时重传的时间设置的太短，会导致对方收到大量的重复报文，可能对方发送的响应报文还在网络中传输而并没有丢包，但此时发送方就开始进行数据重传了，并且发送大量重复报文会也是对网络资源的浪费。

因此超时重传的时间一定要是合理的，最理想的情况就是找到一个最小的时间，保证“确认应答一定能在这个时间内返回”。但这个时间的长短，是与网络环境有关的。网好的时候重传的时间可以设置的短一点，网卡的时候重传的时间可以设置的长一点，也就是说超时重传设置的等待时间一定是上下浮动的，因此这个时间不可能是固定的某个值。

TCP为了保证无论在任何环境下都能有比较高性能的通信，因此会动态计算这个最大超时时间。

• Linux中（BSD Unix和Windows也是如此），超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。
  
• 如果重发一次之后，仍然得不到应答，下一次重传的等待时间就是 2 × 500 2 × 5002×500 ms。如果仍然得不到应答，那么下一次重传的等待时间就是4 × 500 4 × 5004×500 ms ，以此类推，以指数的形式递增。
  

• 即如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。
• 也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。

• 当累计到一定的重传次数后，TCP就会认为是网络或对端主机出现了异常，进而强转关闭连接。

五、流量控制

1、TCP的缓冲区

TCP本身是具有接收缓冲区和发送缓冲区的：

• 接收缓冲区用来暂时保存接收到的数据。
• 发送缓冲区用来暂时保存还未发送的数据。

这两个缓冲区都是在TCP传输层内部实现的。

• TCP发送缓冲区当中的数据由上层应用层进行写入。当上层调用write/send这样的系统调用接口时，实际不是将数据直接发送到了网络当中，而是将数据从应用层拷贝到了TCP的发送缓冲区当中。
• TCP接收缓冲区当中的数据最终也是由应用层来读取的。当上层调用read/recv这样的系统调用接口时，实际也不是直接从网络当中读取数据，而是将数据从TCP的接收缓冲区拷贝到了应用层而已。

TCP的发送缓冲区和接收缓冲区存在的意义

• 数据在网络中传输时可能会出现某些错误，此时就可能要求发送端进行数据重传，因此TCP必须提供一个发送缓冲区来暂时保存要发送出去的数据，只有当发出去的数据被对端可靠的收到后，发送缓冲区中的这部分数据才可以被覆盖掉。
• 接收端处理数据的速度是有限的，为了保证没来得及处理的数据不会被迫丢弃，因此TCP必须提供一个接收缓冲区来暂时保存未被处理的数据，因为数据传输是需要耗费资源的，我们不能随意丢弃正确的报文。此外，TCP的数据重排也是在接收缓冲区当中进行的。

经典的生产者消费者模型：

• 对于发送缓冲区来说，上层应用不断往发送缓冲区当中放入数据，下层网络层不断从发送缓冲区当中拿出数据准备进一步封装。此时上层应用扮演的就是生产者的角色，下层网络层扮演的就是消费者的角色，而发送缓冲区对应的就是“交易场所”。
• 对于接收缓冲区来说，上层应用不断从接收缓冲区当中拿出数据进行处理，下层网络层不断往接收缓冲区当中放入数据。此时上层应用扮演的就是消费者的角色，下层网络层扮演的就是生产者的角色，而接收缓冲区对应的就是“交易场所”。
• 因此引入发送缓冲区和接收缓冲区相当于引入了两个生产者消费者模型，该生产者消费者模型将上层应用与底层通信细节进行了解耦，此外，生产者消费者模型的引入同时也支持了并发和忙闲不均。

理解一些现象：

• 在编写TCP套接字时，我们调用read/recv函数从套接字当中读取数据时，可能会因为套接字当中没有数据而被阻塞住，本质是因为TCP的接收缓冲区当中没有数据了，我们实际是阻塞在接收缓冲区当中了。
• 而我们调用write/send函数往套接字中写入数据时，可能会因为套接字已经写满而被阻塞住，本质是因为TCP的发送缓冲区已经被写满了，我们实际是阻塞在发送缓冲区当中了。

2、TCP的窗口大小

当发送端要将数据发送给对端时，本质是把自己发送缓冲区当中的数据发送到对端的接收缓冲区当中。但缓冲区是有大小的，如果接收端处理数据的速度小于发送端发送数据的速度，那么总有一个时刻接收端的接收缓冲区会被填满，这时发送端再发送数据过来就会造成数据丢包，进而引起超时重传等一系列的连锁反应。

因此TCP报头当中就有了16位的窗口大小，这个16位窗口大小当中填的是自身接收缓冲区中剩余空间的大小，也就是当前主机接收数据的能力，2 16 ÷ 1024 b y t e = 64 K B 2^{16}÷1024 byte = 64 KB216÷1024byte=64KB。

实际上TCP报头当中40字节的选项字段中包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位得到的。

接收端在对发送端发来的数据进行响应(ACK)时，就可以通过16位窗口大小告知发送端自己当前接收缓冲区剩余空间的大小，此时发送端就可以根据这个窗口大小字段来调整自己发送数据的速度。

问：在接收方接受能力为0的条件下，发送方怎么知道什么时候可以重新向接收方发送数据了呢？

当发送端得知接收端接收数据的能力为0时会停止发送数据，此时发送端会通过以下两种方式来得知何时可以继续发送数据。

• 等待告知。接收端上层将接收缓冲区当中的数据读走后，接收端向发送端发送一个TCP报文，主动将自己的窗口大小告知发送端，发送端得知接收端的接收缓冲区有空间后就可以继续发送数据了。
• 主动询问。发送端每隔一段时间向接收端发送报文，该报文不携带有效数据，只是为了询问发送端的窗口大小，直到接收端的接收缓冲区有空间后发送端就可以继续发送数据了。

问：第一次发送方发送数据时怎么保证数据量不会超过对方的窗口大小呢？

在进行TCP通信之前需要先进行三次握手建立连接，而双方在握手时除了验证双方通信信道是否通畅以外，还进行了其他信息的交互，其中就包括告知对方自己的接收能力，因此在双方还没有正式开始发送报文数据之前就已经知道了对方接收数据能力，所以双方在第一次发送数据时是不会出现缓冲区溢出的问题的。

3、TCP的PSH标志位

TCP报头当中的PSH被设置为1，是在告诉对方尽快将你的接收缓冲区当中的数据交付给上层，用来让流量的速度快起来。

我们一般认为：

• 当使用read/recv从缓冲区当中读取数据时，如果缓冲区当中有数据read/recv函数就能够读到数据进行返回，而如果缓冲区当中没有数据，那么此时read/recv函数就会阻塞住，直到当缓冲区当中有数据时才会读取到数据进行返回。

实际这种说法是不太准确的，其实接收缓冲区和发送缓冲区都有一个「水位线」的概念，只有当接收缓冲区当中有大于等于水位线以上字节的数据时才让read/recv函数读取这些数据并进行返回。

这样的设计是为了避免read/recv类似的系统调用频繁的进行读取和返回，进而影响读取数据的效率（在内核态和用户态之间切换也是有成本的）。

当报文当中的PSH被设置为1时，就会告知对方操作系统，尽快将接收缓冲区当中的数据交付给上层，尽管接收缓冲区当中的数据还没到达所指定的水位线。这也就是为什么我们使用read/recv函数读取数据时，期望读取的字节数和实际读取的字节数是不一定吻合的。

六、TCP的六个标志位

为什么会存在标志位？

1. TCP报文的种类多种多样，除了正常通信时发送的普通报文，还有建立连接时发送的请求建立连接的报文，以及断开连接时发送的断开连接的报文等等。
2. 收到不同种类的报文时完美需要执行对应动作，比如正常通信的报文需要放到接收缓冲区当中等待上层应用进行读取，而建立和断开连接的报文本质不是交给用户处理的，而是需要让操作系统在TCP层执行对应的握手和挥手动作。

为了让不同种类的报文对应的是不同的处理逻辑，所以我们要能够区分报文的种类。而TCP就是使用报头当中的六个标志字段来进行区分的，这六个标志位都只占用一个比特位，为0表示假，为1表示真。

URG字段的详细解释

在进行网络通信的时候，由于TCP是保证数据按序到达的，即便发送端将要发送的数据分成了若干个TCP报文进行发送，最终到达接收端时这些数据也都是有序的，因为TCP可以通过序号来对这些TCP报文进行顺序重排，最终就能保证数据到达对端接收缓冲区中时是有序的。

TCP按序到达本身也是我们的目的，此时对端上层在从接收缓冲区读取数据时也必须是按顺序读取的。但是有时候发送端可能发送了一些“紧急数据”，这些数据需要让对方上层提取进行读取，此时就需要用到URG标志位，以及TCP报头当中的16位紧急指针。

• 当URG标志位被设置为１时，需要通过TCP报头当中的「16位紧急指针」来找到紧急数据，否则则不需要关注TCP报头当中的16位紧急指针。
• 16位紧急指针代表的就是紧急数据在发送来的报文中的偏移量。
• 因为紧急指针只有一个，而且没有指示结束位置，所以它只能标识数据段中的一个位置，因此紧急数据只能发送一个字节。

recv/send函数的第四个参数flags有一个叫做MSG_OOB的选项可供设置，其中OOB是带外数据（out-of-band）的简称，带外数据就是一些比较重要的数据，因此上层如果想读取紧急数据，就可以在使用recv函数进行读取，并设置MSG_OOB选项。

上层如果想发送紧急数据，就可以使用send函数进行写入，并设置MSG_OOB选项。

URG的一个应用场景

在网盘服务中，我们正在上传一个文件，但是我们现在突然不想上传这个文件了，于是我们发起取消请求，但是由于TCP的保证有序性，所以我们的取消请求不能够被立即处理，需要在接收缓冲区中排队，网盘继续执行上传任务，直到读取到了取消请求才进行取消上传，显然这种处理方式是不合理的。

为了让服务器能够尽快的响应我们的取消请求，我们可以将取消请求的报文设置为紧急数据，这样对于我们发送的取消请求，服务器就能够尽快处理了。