【网络安全】TCP和UDP

一、TCP/UDP对比

1.共同点：

都是工作在TCP/IP体系结构的传输层的协议

工作主要都是把端口号往原始数据封装

在 TCP 协议中，原始数据指的是应用程序产生的需要通过网络进行传输的数据。这些数据可以是各种类型的信息，例如文本、图像、音频、视频等。
 
原始数据通常在应用程序中生成，并被传递给 TCP 协议进行封装和传输。TCP 协议会将原始数据与其他相关信息（如端口号、序列号、校验和等）一起组成 TCP 数据包。

2.区别：

• TCP是面向连接的协议，而UDP是无连接的协议；
• TCP协议的传输是可靠的，而UDP协议的传输 “尽力而为”；
• TCP协议可以实现流控，而UDP不行；

流控：流量控制

我们在发送数据的时候，有的时候发送的太快，有的时候发送的太慢，我们要想办法控制一下这个速度，这点TCP可以做到，而UDP做不到。

流控（3）应该算是传输可靠性（2）中的一环，流量发的快一点或者慢一点，主要目的是保证对方能够正常收到这些信息，能够正常地处理这些信息，并且保证传输效率。所以有流控这个机制在里面，传输也会更可靠一点。

• TCP可以分段，而UDP不行；

分段：拆分大的数据包

我们发数据的时候，这个数据包有可能很大，因为里面的数据内容有可能很多，TCP可以分段就是可以把这些很大的数据包拆分开，拆成一个一个的小段，然后再去分别发送过去，而UDP不行，多大就多大发。

• TCP消耗资源较大，传输效率较低。UDP耗费资源较小，速度快；

3.TCP/UDP使用场景

• TCP协议更适用于对传输可靠性要求较高，但是对传输效率和资源占用要求较低；（网页浏览、电子邮件传输和文件传输等）；
• UDP更适用于对传输效率要求较高，可靠性要求较低的场景；（即时通实现类：语音、视频、聊天、游戏、直播等）；

什么是面向连接？

我们可以通过一个小游戏来理解一下：

在正式传输数据之前，先使用预先的协议（TCP协议），建立点到点的链接。 

A跟B说：你准备好了吗？我要开始扔球了，然后B说：我准备好了。

有了这一来一回，A就可以给B扔球了。A给B的连接就相当于建立好了。这种情况下，A就可以给B扔球了。

如果B也想给A扔球，那B也要A给B说：你准备好了吗？我也要开始扔球了，然后A说：我准备好了。 有了这一来一回，B也可以给A扔球了。

所以数据传输其实是双向的，TCP协议建立好的通信通道其实是双向的，就是A可以给B扔球，小B也可以给A仍球，这个通道就是 “会话”。

什么是会话？

A可以给B发信息，那A就生成一条指向B的会话，B可以给A发信息，那B就生成一条指向A的会话。可以发送信息的这个通道，就可以把他理解为是一个会话。

TCP协议是面向连接的协议，在发送数据之前要先建立连接，而他建立的连接就是建立的一条双向会话。

TCP建立的连接实际建立了一个双向的会话连接，即通讯双方都可以向对方发送数据。

一张很刺激的图片：

这张图可以在一定程度上可以反应出来TCP和UDP这两种协议的风格。

• TCP比较沉稳，面向连接、速度慢、可靠传输；
• UDP比较奔放，无连接、速度快、不可靠传输；

二、TCP

1.TCP协议头部

 来看一下TCP和UDP这两个协议的包头，上面的图片中写着TCP-20字节头，UDP-8字节头。

往原始数据前面加的数据称之为头部，往后面加的称之为尾部。

TCP和UDP都是只给前面加，所以他们只有头部信息。

我们看一下他们头部都要封装哪些参数，哪些内容。

TCP协议头部：

数据：从应用诞生传到传输层再加工的数据

其他：都是要TCP再往原数据上再加的数据

• 源端口号和目的端口号

源端口号和目的端口号用于标识发送方和接收方的应用程序。端口号是一个 16 位的数字，取值范围为 0 到 65535。

 

源端口号是发送方应用程序所使用的端口号，它告诉接收方数据来自哪个应用程序。目的端口号则是接收方应用程序所监听的端口号，用于确定数据应该被传递给哪个应用程序。

 

例如，当你在浏览器中访问一个网页时，浏览器会使用一个随机的源端口号与服务器的 80 端口（HTTP 默认端口）进行通信。

• 序号：就是扔球游戏中标记的序号，目的是把传输的数据按照顺序排列起来，还原为正常的顺序

序号就如你所说，在 TCP 传输中类似于扔球游戏中的序号标记。它是一个 32 位的数字，用于对每个发送的数据字节进行编号。

 

发送方在发送数据时，会为每个字节分配一个序号。接收方根据序号可以将接收到的数据按照正确的顺序排列起来，确保数据的完整性和顺序性。

• 确认序号

确认序号是接收方用来告诉发送方已经成功接收到的数据的序号。它是接收方期望收到的下一个数据字节的序号。

 

当接收方成功接收到数据后，会在回复的报文段中设置确认序号，以确认已经收到的数据，并通知发送方可以继续发送后续的数据。

• 首度：因为有（选项）字段的存在，导致头度不固定

首度表示 TCP 报头的长度，以 32 位字（4 字节）为单位。由于 TCP 报头的长度是可变的，这个字段用于确定报头的结束位置和数据的开始位置。

 

首度的取值范围为 5 到 15，分别对应 20 字节到 60 字节的报头长度。

• 保留

保留字段是为了将来的扩展而保留的，目前必须设置为 0。

• 六个控制位：URG、ACK、PSH、RST、SYN、FIN

每个标记位占一位。0表示未被激活，为1表示已被激活

1.URG：（紧急标记位），要是置1，（紧急指针）就会被激活，里面的内容就会生效，如果数据包中携带需要紧急优先处理的数据，就需要把紧急标志位激活。会把需要紧急处理的数据放在最前面

紧急指针会指示哪些是紧急数据，指针之前的是紧急的数据，后面是常规数据

2.ACK（确认标志位）：置1表示确认之前的信息，（确认序号）被激活，小A跟小B扔5号球，小B回复我已经收到5号球了请你扔六号球，小B回复的过程就是确认的过程，所以小B回复的这个数据包里的ACK标志位要置1

3.PSH：数据可以进行分段，然后分别去传输，到对端还有拼回去，所以TCP这个协议建立连接的过程中有一个机制：对端在接受TCP信息的时候，会预留一个缓冲区域。在缓冲区域中把数据段先收集起来，然后按照序号进行排序，把完整在信息提取出来，然后再进行传递。如果置1，则不需要在缓冲区排队了，将被直接推送给进程

4.RST：

5.SYN：（请求标志位）请求建立连接

6.FIN：（结束标记位）想要断开连接

• 窗口大小

窗口大小是一个 16 位的数字，用于流量控制。它表示接收方愿意接收的字节数，即接收窗口的大小。

 

发送方根据接收方的窗口大小来调整自己的发送速度，避免发送过多的数据导致接收方无法处理。

• 校验和：确保数据的完整性，每一层都有校验和，但是四层的校验（传输层）相对于其他层的校验，校验强度稍微高一点
  伪头部校验：头部内容和数据内容都要校验，并且包括下一层（网络层）也进行校验
  封装图：
  

校验和用于检测 TCP 报头和数据在传输过程中是否出现错误。它是对报头、数据和伪首部进行计算得到的一个 16 位的校验值。

 

接收方在接收到报文段后，会重新计算校验和，并与报文中的校验和进行比较。如果两者不相等，则说明数据在传输过程中出现了错误，接收方会丢弃该报文段。

• 紧急指针

当 URG 标志位被设置为 1 时，紧急指针指出紧急数据的最后一个字节的序号。它是一个偏移量，与序号字段中的值相加得到紧急数据的位置。

• 选项

选项字段是可变长度的，用于提供一些额外的功能，如最大报文段长度（MSS）、窗口扩大因子等。选项的长度必须是 4 字节的整数倍，如果不足，则需要填充到 4 字节的整数倍。

所以TCP头部的长度是：20—60字节

2.TCP的三次握手

就是建立连接的过程

简单：

• 建立A指向B的会话

• 建立B指向A的会话

• 2、3两个数据包可以用一个数据包完成

所以这个过程称为三次握手

详细：

TCP 的三次握手：

 

1. 第一次握手：建立连接时，客户端向服务器发送一个带有 SYN（同步序列编号）标志位的数据包，其中包含一个随机生成的序列号 seq=x。发送完这个包后，客户端进入 SYN_SENT 状态，等待服务器的确认。这一步的作用是客户端告知服务器自己有建立连接的请求。
2. 第二次握手：服务器收到客户端的 SYN 包后，知道客户端请求建立连接。服务器将 SYN 和 ACK 标志位都置为 1，确认号 ack=x+1（表示对客户端序列号的确认），同时随机生成一个自己的序列号 seq=y，然后将这个 SYN+ACK 包发送给客户端，此时服务器进入 SYN_RCV 状态。这一步服务器既对客户端的请求进行了确认，又向客户端发起了自己的连接请求。
3. 第三次握手：客户端收到服务器的 SYN+ACK 包后，检查确认号 ack 是否为自己发送的序列号加 1（即 y+1），以及 ACK 标志位是否为 1，如果正确则将 ACK 标志位置为 1，确认号 ack=y+1，并将该数据包发送给服务器。服务器收到这个包后，检查确认号 ack 是否为自己发送的序列号加 1（即 k+1），以及 ACK 标志位是否为 1，如果正确则连接建立成功，客户端和服务器进入 ESTABLISHED（已建立连接）状态，之后就可以开始传输数据了。三次握手的主要作用是确认双方的接收与发送能力是否正常，以及指定初始化序列号，为后续的可靠传输做准备。

3.四次挥手

TCP 的四次挥手：

1. 第一次挥手：客户端完成数据发送任务后，发送一个带有 FIN（结束）标志位的数据包，用来关闭客户端到服务器的数据传送，此时客户端进入 FIN_WAIT_1 状态。这表示客户端不再向服务器发送数据，但仍可以接收服务器发送的数据。
2. 第二次挥手：服务器收到客户端的 FIN 包后，发送一个 ACK 包给客户端，确认序号为收到的序号加 1，服务器进入 CLOSE_WAIT 状态。这一步是服务器对客户端关闭连接请求的确认，表示服务器已经知道客户端不再发送数据，但此时服务器可能还有数据要发送给客户端。
3. 第三次挥手：当服务器确定自己的数据已发送完成，就向客户端发送一个带有 FIN 标志位的数据包，用来关闭服务器到客户端的数据传送，服务器进入 LAST_ACK 状态。这表示服务器也完成了数据发送，请求关闭连接。
4. 第四次挥手：客户端收到服务器的 FIN 包后，进入 TIME_WAIT 状态，接着发送一个 ACK 包给服务器，确认序号为收到的序号加 1。服务器收到这个 ACK 包后，进入 CLOSED 状态，完成连接的关闭。客户端在 TIME_WAIT 状态等待一段时间（通常为 2 倍的最长报文段寿命）后，如果没有收到服务器的重传请求，也会进入 CLOSED 状态，彻底关闭连接。四次挥手的目的是确保双方都能正确地关闭连接，并且在关闭连接之前处理完所有的数据传输。

在特殊情况下，TCP 挥手有可能是三次，但几乎不可能是两次或一次。以下是具体分析：

 

1. 三次挥手的特殊情况：
   • 正常的 TCP 四次挥手过程中，第二次挥手和第三次挥手之间，服务器可能还有数据要发送给客户端。但如果服务器在收到客户端的 FIN 报文后，已经没有数据要发送了，就可以把第二次挥手的 ACK 报文和第三次挥手的 FIN 报文合并成一个报文发送给客户端，这样就出现了三次挥手的情况。不过这种情况相对较少，因为大多数情况下服务器在收到客户端的关闭请求时，可能还需要一些时间来处理未完成的数据发送等操作。
2. 不可能是两次挥手的原因：
   • TCP 是全双工通信，即通信双方都可以发送和接收数据。在关闭连接时，需要双方都确认对方不再发送数据。客户端发起第一次挥手表示自己不再发送数据，服务器回复 ACK 报文只是确认收到了客户端不再发送数据的请求，但此时服务器还可能有数据要发送，所以不能直接进入关闭状态，还需要再发送一个 FIN 报文表示自己也不再发送数据，客户端再回复 ACK 报文确认，这样才能完成连接的关闭。所以两次挥手无法满足 TCP 全双工通信关闭连接的需求。
3. 不可能是一次挥手的原因：
   • 一次挥手意味着只有一方发送了关闭连接的请求，而另一方没有进行任何确认操作，这完全不符合 TCP 协议的可靠性要求。TCP 协议为了保证数据的可靠传输和连接的正确释放，必须经过双方的确认和交互，所以不可能只通过一次挥手就完成连接的关闭。

4.TCP传输可靠性的保障机制

         --- 确认、重传、排序、流控

（1）确认

每发一个信息就要等对方回复一个确认消息，有了这个保障可以确保发送的信息对方都能收到

在 TCP 通信中，确认机制是确保数据可靠传输的重要手段。当发送方发送数据后，接收方会对接收到的数据进行确认。确认的方式是接收方发送一个确认报文（ACK）给发送方，其中包含确认号，该确认号表示接收方期望接收到的下一个字节的序号。

 

例如，发送方发送了一段数据，序号从 1 开始，长度为 1000 字节。接收方成功接收后，会发送一个确认报文，确认号为 1001，表示接收方期望下一个字节的序号为 1001。发送方收到确认报文后，就知道接收方已经成功接收了前面的数据，可以继续发送后续的数据。

 

确认机制确保了发送方和接收方之间的数据传输是有序的，并且发送方可以及时了解数据是否被正确接收。如果发送方在一定时间内没有收到确认报文，就会认为数据可能丢失，从而触发重传机制。

（2）重传

如果收不到对方的确认消息，可能对方没有收到，就要重新发一次，要保证对方收到才行

重传机制是为了解决数据在传输过程中可能丢失的问题。当发送方发送数据后，如果在一定时间内没有收到接收方的确认报文，就会认为数据丢失，并重新发送该数据。

 

TCP 采用了多种重传策略，其中最常见的是超时重传。发送方在发送数据时，会启动一个定时器。如果定时器超时后还没有收到确认报文，发送方就会重新发送数据。定时器的超时时间是根据网络状况动态调整的，以适应不同的网络环境。

 

除了超时重传，TCP 还采用了快速重传机制。当接收方收到失序的数据时，会立即发送重复的确认报文给发送方。如果发送方连续收到三个重复的确认报文，就会认为数据丢失，并立即重传该数据，而不必等待定时器超时。

 

重传机制保证了即使在网络出现故障或数据丢失的情况下，数据也能最终被正确传输。

（3）排序

由于网络中的数据包可能会经过不同的路径传输，到达接收方的顺序可能与发送方发送的顺序不一致。为了确保数据的正确顺序，TCP 采用了排序机制。

 

接收方在接收到数据包后，会根据数据包中的序号对数据进行排序。如果接收到的数据包序号不连续，接收方会将这些数据包缓存起来，等待缺失的数据包到达后再进行排序和组装。

 

例如，发送方发送了三个数据包，序号分别为 1、2、3。如果接收方先收到序号为 2 的数据包，然后收到序号为 3 的数据包，最后收到序号为 1 的数据包。接收方会根据序号将这些数据包进行排序，确保数据的正确顺序。

 

排序机制保证了接收方能够按照发送方的顺序接收和处理数据，避免了数据的混乱和错误。

（4）流控

按照TCP确认机制来说，TCP每发一个数据包，就要求对方回复一个确认才发下一个数据包，这样做的弊端是效率低，每发一个数据包都需要去等，这种流控叫做停等式流控。

TCP采用的方式是加入窗口值，如果窗口值是10，一次发10个数据包，只需要确认一次就可以。

滑动窗口的内在逻辑会更复杂

流控机制是为了防止发送方发送数据过快，导致接收方无法及时处理而出现数据丢失的情况。TCP 采用了滑动窗口机制来实现流控。

发送方和接收方在建立连接时，会协商一个窗口大小。发送方在发送数据时，会根据接收方通告的窗口大小来控制发送的数据量。接收方会在确认报文中通告自己当前可用的接收缓冲区大小，即窗口大小。发送方根据这个窗口大小来调整自己的发送速度，确保不会发送过多的数据导致接收方无法处理。

例如，接收方通告的窗口大小为 1000 字节，表示接收方当前可以接收 1000 字节的数据。发送方在发送数据时，会确保发送的数据量不超过这个窗口大小。当接收方处理完一部分数据后，会通告一个新的窗口大小，发送方根据这个新的窗口大小来调整自己的发送速度。

流控机制保证了数据传输的稳定性和可靠性，避免了因发送方发送速度过快而导致的数据丢失和网络拥塞。

三、UDP

1.UDP协议头部