网络:TCP协议-报头字段

水月梦镜花 2024-09-30 08:07:06 阅读 75

在这里插入图片描述

个人主页 : 个人主页

个人专栏 : 《数据结构》 《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丢包了,会重新建立链接。

还有很多其它例子。

在这里插入图片描述


下图就是linux-2.6.11.10中tcp的报头字段

在这里插入图片描述


总结

TCP保证可靠性,但又不仅仅保证可靠性,还会进行各种提高效率的设定。

以上就是我对于TCP协议的知识总结

在这里插入图片描述



声明

本文内容仅代表作者观点,或转载于其他网站,本站不以此文作为商业用途
如有涉及侵权,请联系本站进行删除
转载本站原创文章,请注明来源及作者。