Linux：详解TCP报头类型

本文主要是介绍Linux：详解TCP报头类型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章目录

温习
- 序号的意义
- 序号和确认序号
- 报文的类型
TCP报头类型详解
- ACK: 确认号是否有效
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- FIN: 通知对方, 本端要关闭了
- PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
- URG: 紧急指针是否有效

本篇继续对于TCP协议的字段进行解析

在这里插入图片描述

温习

序号的意义

TCP为了传输的效率，必然会遇到批量化传输这样的场景，那也就意味着会涉及到批量化的应答

这里随之而来会遇到一个问题，那就是在传输的过程中，由于传输的速度不同，所以曾经发送的数据不一定是对方接收的顺序，所以一定要在传输之后的内容带一个对应的序号，那么这个序号实际上就是客户端给服务端发送时候报文的序号，也正是因为有这个序号，所以才能对收到的报文进行排序，保证数据的按序到达

序号和确认序号

那序号和确认序号就是伴随着上面的概念而引出的，当传输过去了之后，对应着传输回来的ACK序号往往是收到的报文序号加一，采用这样的方式就能对于对应的报文当中的内容进行确认了

报文的类型

在上篇的最后我们讲到，对于一个服务器来说，它必然会产生很多的请求，有些请求是要建立链接的，有些是要断开连接的，有些是要进行正常通信的，所以我们说报文是有类型的，所以我们才知道对于TCP中的报头部分，其当中会有很多的标记位，其中有几个标记位就是来区分不同的报文类型的，这也是说明了在上面的场景中可以突出他们需要标记位的原因，所以本节要总结的核心点就是对于报文的类型进行解析

对于TCP的三次握手和四次挥手，在后面的文章中也会进行详细的总结和解析

TCP报头类型详解

ACK: 确认号是否有效

首先第一个标记位是ACK标记位，这个标记位的作用是确认序号是否有效，实际上在进行数据通信的时候，在三次握手建立成功之后，在大部分情况下，所有报文的ACK标记位默认都是被置一的，它的意思就是说这个标记位是有效的，ACK原则上代表的是报文是具有应答属性的，而在进行报文通信的时候很多是有捎带应答的概念，所以在一个报文给对方进行应答的同时，可能携带了我的数据，那么如何判断这是一个简单的应答还是有其他的数据，一个是要看这个ACK标记位是否有内容，一个就是要看有效载荷当中是否有数据

SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段

SYN的全称是synchronous，翻译过来的意思是同步，那它代表的是什么意思呢？给出下面的这个场景：

假设现在通信双方要进行一个简单的通信，那么此时第一步要做的就是先建立链接，可是服务器是如何知道我当前要和它做的事是建立链接呢？所以说在一个报文中，凡是设置了SYN标记位的报文，实际上都是代表了自己想要和服务器进行三次握手建立链接，这个也叫做是建立链接的请求，所以它用来标识发过来的TCP整体的报文是一个链接的请求

FIN: 通知对方, 本端要关闭了

第三个要说的标记位是FIN，其全称是finish，这个其实很好理解，它表示的意思就是说通信双方要使用的这个TCP，将要关闭了，所以要进行断开链接了

所以由此可以看出，标记位当中不仅有要进行数据通信的标记位，也有对应的控制标记位，表示我当前要建立链接或者是当前要退出链接

PSH: 提示接收端应用程序立刻从TCP缓冲区把数据读走

首先说明，TCP报头和配套的协议都是操作系统自主决定的，通常来说它不会允许用户直接从外部去修改对应的比特位信息，通常最多是提供一些系统调用来进行修改，实际上在进行套接字的设置过程中，当进行发起connect的请求的时候，实际上就是TCP报文要在底层把SYN设置为一，然后发送给服务器要进行三次握手的链接过程，而这个FIN表示的就是在进套接字关闭的时候要进行的close的操作，实际上也是在底层把这个FIN标记位设置为一

那回到PSH标记位，在进行TCP通信的时候，在客户端向服务端发消息，服务端向客户端发消息，由于存在流量控制的原因，所以对应的应用层可能会出现迟迟不把数据取走的情况出现，那么就会导致缓冲区的数据越来越多，最终导致空间越来越小，不过以我们前面的代码来看，出现这样事件的情况并不多见，而如果真的出现这样的情况会怎么样呢？如果此时现在已经陷入了循环，客户端要给服务端发消息，服务端缓冲区已经满了，而客户端不知道什么时候缓冲区有内容，那这样的情况该如何解决呢？

对应的策略提供两种：

发送方会定期的询问对方，看对方的缓冲区中还有没有空间，只要有就能发送报文，但是前提是对方肯定要做出应答
当接收方的缓冲区数据被上层更新了之后，它就会给对方发送一个报文，说自己的缓冲区已经更新了，可以在缓冲区中继续写入数据了

这两种协商方式在实际的TCP协议中是会同时存在的，具体哪一种协议方式生效就使用哪一种，但不管怎么说，假设现在对方缓冲区的数据就是不拿走，就在对应的缓冲区中卡着，那么此时对应的TCP该如何处理呢？所以就用到了这个PSH标记位，这个标记位表示的是push的意思，表示的是如果对方的操作系统中收到了代表着PSH标记位的数据时，就表示这个操作系统必须要赶快把缓冲区当中的信息交付到上层空间中，尽快的腾出空间，当有这样的需求的时候，发送放就会把信息读走，如果迟迟不读，可能会直接把建立的链接关闭等等，所以换句话说，其实PSH的作用就是催促对方赶快读走信息

RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段

下一个要说的是RST标记位，正常情况下TCP的三次握手和四次挥手是应该成功的，但是这样的动作有没有可能出现意外呢？答案也是可能的

在TCP的内部，可能会和很多个客户端建立链接，那么在TCP的内部必然会存在对应的数据结构，用来描述这样的链接情况，所以从本质上来说就可以把对于TCP链接的管理转换为对于链表的增删查改，所以说对于客户端和服务端来说，一定要在内核中维护对应的结构和对象，上面讲的什么缓冲区超时重传，序号问题，这些属性的字段都会在对应的结构体当中进行标识

可是问题是，对于链接的维护是有成本的，维护的成本主要体现在三次握手成功之后，此时就会建立链接，创建对应的结构体数据结构，然后进行维护对应的链接情况，但是不管怎么说，如果出现链接异常的情况呢？客户端认为链接成功了，而实服务端没有成功，那么在进行报文传输的时候就会携带有对应的RST标记位，表示现在应该要建立链接了

那对于客户端来说，它在发送了最后一个信息的时候就认为链接已经建立好了，而实际上可能在最后发送出去的消息中出现了问题，链接没有建立完成

在这里插入图片描述
那么在这样的情况下，客户端在认为自己成功之后，下一步就会直接向服务端发送给消息，那服务端在看到明明还没有建立好链接，客户端就要给我发消息，那么服务端就认为客户端以为建立好链接了，实际上没有，那么就会赶快把RST的标记位传入到报头中，然后发给客户端，然后客户端就会对于服务端进行链接重新建立