当前位置：首页 > article >正文

网络：TCP协议-报头字段

article 2024/11/19 12:30:41

在这里插入图片描述

个人主页：个人主页
个人专栏：《数据结构》《C语言》《C++》《Linux》《网络》

文章目录

前言
一、TCP协议格式
- 16位源端口号和 16位目的端口号
- 4位首部长度
- 16位窗口大小
- 32位序号和 32位确认序号
- 6种标记位和 16位紧急指针
总结

前言

本文是我对于TCP协议-报头字段的知识总结

一、TCP协议格式

在这里插入图片描述

16位源端口号和 16位目的端口号

16位源端口号：标识发送方应用程序的端口号，是一个16位的字段。通过源端口和目的端口，可以唯一确定一个TCP连接。
16位目的端口号：标识接收方应用程序的端口号，同样是一个16位的字段。与源端口一起，用于确定数据应被哪个应用程序接收。

4位首部长度

TCP协议如何解决 报头和有效载荷分离的问题？ 其中报头为 TCP标准报头长度(20字节) + 选项。
TCP标准报头长度是固定长度好分离，但选项的长度不确定，该怎么办？
4位首部长度表示 TCP标准报头 + 选项的大小。
4位首部长度的取值范围为[ 0000, 1111 ]转化为10进制也就是[ 0, 15 ]，那这不还没有TCP标准报头长度大吗？我们还规定首部长度的基本单位是4字节，也就说4位首部长度的取值范围是[ 0, 60 ]，选项最多40个字节。
现在我们算一下TCP标准报头的4位首部长度，TCP标准报头是20字节，那4位首部长度是5，转化为2进制就是0101 。
注意：TCP的报头长度必须是4的整数倍，因为基本单位是4字节。

16位窗口大小

16位窗口大小：表示接收方愿意并能够接收多少数据。用于实现TCP的流量控制机制。

那我们如何理解16位窗口大小？我们先看下图。
在这里插入图片描述
我们都知道，TCP具有发送和接受缓冲区，即TCP是全双工通信。发送数据就是把数据拷贝到操作系统内的发送缓冲区，再从发送缓冲区到接收方的接受缓冲区。

那如果发送方一直疯狂的向接收方发送数据，此时发送方不清楚接收方的接受能力(接受缓冲区的剩余空间大小为接受能力)，发送方发送数据太快，导致接收方来不及接受数据，接收方的接受缓冲区满了。发送方还是发送数据，那接收方接受到数据，就会直接丢弃。虽然TCP有重传机制，可以重新发送数据，保证可靠性。但这不合理且不高效，数据千辛万苦从网络到接收方，接收方却直接丢弃了。

那要如何使这样的情况合理？如果接收方来不及接受数据了，发送方就慢点发，甚至等会再发。我们把这种如果对方来不及接受，就要求发送方发送变慢，甚至停止发送的策略，叫做流量控制。
对于流量控制的前提是：发送方可以知道接收方的接受能力。那发送方有如何知道接收方的接受能力呢？

这就要先简单的看看确认应答机制了。如 client给server发送一条消息，TCP为了保证可靠性，要求接收方对发送方发过来的消息进行确认，即只要client收到server发送的确认，client就会认为server收到 “hello” 这条消息，保证client 到 server 的可靠性。
在这里插入图片描述
要注意其中"hello"这条消息是TCP报文。

现在发送方每发送一条消息，都会收到接收方的应答消息。那么发送方就可以从应答消息中的16位窗口大小来判断，接收方的接受能力，从而避免发送方发送的数据因为接收方缓冲区满了，而直接丢弃的问题。
注意：16位窗口大小，是指自身的接受缓冲区中剩余空间的大小。

32位序号和 32位确认序号

我们先来看两种TCP发送数据的方式：
在这里插入图片描述
先看串行发送，client每发送一条数据后，必须得到server发送的ACK，才能继续发送数据。这样client可以清晰的知道每个ACK对应的是那条数据。这样虽然保证了可靠性，但效率低。

再看并行发送，client可以一次发送多条数据，那么server也要发送对应数量的应答给client(原则上要求server对每一条消息做出应答)。这样client发送时间，进行了重叠，效率得到提升。但这也引来了几个问题。

client怎么知道那个ACK是哪个发送数据的应答？如果client接受到的ACK与发送数据数量相同，那至少表明client发送的数据，server都收到了。但如果client收到的ACK数量少于发送数据的数量呢？此时client就不清楚那个发送数据没有被server接受到。
因为网络环境复杂，server接受到数据的顺序不一定是按照client发送数据的顺序。此时，如果client把报文分两次发送，server就有可能先收到数据，再收到报头；这就不可靠了。

对于上面两个问题，我们可以对发送的数据和 ACK 进行编号。
在这里插入图片描述

此时client就可以根据每个ACK的编号，来确定哪个发送数据被server接受到了。而server也可以根据发送数据的序号，进行排序，从而保证数据的按序到达。

上面的序号就是 32位序号和 32位确认序号。

32位序号：用于对TCP报文段进行编号和排序。每个TCP报文段都有一个唯一的序列号，确保数据的唯一性和可识别性。
32位确认序号：用于标识接收端确认收到的数据段。它是成功收到的数据序列号加1，表示接收端已经成功接收了序列号小于该确认序号的所有数据。

注意：32位确认序号还表示，确认序号之前的所有的报文已经被对方全部收到了。为什么要这样规定？允许少量报文的丢失，提高了效率。
如上图，如果server发送的3个ACK，只有序号为301的ACK被client接受到了，那client就会认为发送的3条数据都被server接受到了，效率提升了。

那这里，我们可能会有一个问题？32位序号和 32位确认序号可以同一个字段吗？答案是不能。
在这里插入图片描述

向上图，client 和 server互相发送信息。在情况1 server对client的回应是发送两条信息，那server可不可以将这两条信息作为一条信息发送？要知道发送的消息都是完整的TCP报文，而ACK只是一个ACK标志位置1的报头，那将报头和 “hello” 数据合并不也是一个完整报文吗？这样不仅对client发送的"hello"进行了应答，而且还对client的信息进行了回复。这些效率进行了提升。像这样报文大都既是数据(需要32位序号，保证按序到达)，又是对历史报文的确认(需要32位确认序号)，32位序号和 32位确认序号同事使用，不能是同一个字段。

6种标记位和 16位紧急指针

我们知道一个server会被多个client连接，这么多连接，总会有不同的链接请求。
在这里插入图片描述
即server一定会同时收到各种各样不同类型的TCP报文，也就表示报文要有类型，如何表示报文的类型？TCP中是6种标记位来表示报文类型。

URG：紧急指针是否有效
ACK：确认序号是否有效
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
RST：对方要求重新建立连接，我们把携带RST标识的称为复位报文段
SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段

这里我们介绍URG，PSH，RST。

URG 和 16位紧急指针
在这里插入图片描述
在client 和 server 双方通讯时，TCP报文要按照32位序号排序，按序处理，也就是排队。如果此时服务器通讯双方有一些紧急数据时，因为TCP报文是有序号的，那该紧急数据也要按序处理吗？这就不好了，我们应该尽快处理紧急数据，即该报文要提前处理，也就是要插队。
此时，我们就需要 URG 和 16位紧急指针。

URG标记位被置 1 ，表示该报文是紧急报文
16位紧急指针表示，在当前报文中，紧急数据在有效载荷中的偏移量

注意：只有URG无效，16位紧急指针也就无效；只有URG被置1,16位紧急指针也要被查看

这就有一个问题。紧急数据的大小是多少？毕竟16位紧急指针只是给了一个地址，并没有给紧急数据有多少个字节。答案是 1个字节。
紧急任务都有哪些？
在这里插入图片描述

PSH

在这里插入图片描述
当client 给 server 发送 “hello” 时，server要给 client 发送 ACK；但不仅仅只发送 ACK 还会同步窗口大小。比较发送的是一个完整报文。
如果server因为上层http 处理一个比较耗时的任务，导致进程卡主了。client 给 server 发送 “hello”， server 给 client 发送 ACK ，同时更新窗口大小为 0；
在这里插入图片描述
此时表示，server的接受缓冲区满了，client知道不能发送消息了，只能等待。那以后client 如何知道 server 缓冲区的情况，这会不会出现双方互相等待的情况？
并不会，此时client会定期向server发送询问报文(只有报头)，根据TCP的确认应答机制，server要给client发送ACK(携带了server的窗口大小)。同时当上层将接受缓冲区的数据取走，也就是server接受缓冲区的剩余空间从 0 变为非0。server 会主动给client发送窗口大小更新报文。

在这里插入图片描述

上面两种策略同时使用，那种方式先被client收到，client就会继续发送信息。

其中，client发送的询问报文，就是一个PSH标记位被置1的报头。

注意：PSH不仅仅使用在上述场景中，在所有数据需要尽快交付的场景下，都可以使用。如Linux的指令输入

RST
在这里插入图片描述
我们知道TCP通讯的前提，必须进行三次握手。这里有个问题，TCP是保证可靠性的，那是不是三次握手必须成功？不是，三次握手可能失败。那TCP保证可考性是怎么回事，该可靠性不是保证数据100%发送到，而是数据被接收方收到，发送方要知道；数据发送出现问题，发送方也要知道。

现在我们以三次握手出现问题为例，介绍RST出现场景。

我们先要知道对于client 和 server 来说，什么时候，连接建立好了。

对于client，是发出ACK就认为连接建立好了
对于server，是要收到client发送的ACK，才认为连接建立好了

注意：这里client 和 server 认为建立好链接有一定的时间差

了解上面这点，我们再往下看。其中SYN 和 SYN + ACK 如果丢包，我们不担心。因为SYN 和 SYN + ACK都有对应的应答，但 ACK 如果丢失，就不好办了。如果client发送的ACK丢包了，但client认为TCP连接已经建立好了，而server因为还没有收到client的ACK，认为还没有建立TCP链接。这就存在了连接建立认知不一致。此时client给server发送数据，server会给client发送一个重新建立链接的报文(RST标记位被置1 的报文)，此时client会知道发送的ACK丢包了，会重新建立链接。

还有很多其它例子。
在这里插入图片描述