【传输层协议】UDP/TCP结构特点与原理(详解)

文章目录

  • 1. UDP
    • 1.1 UDP结构
    • 1.2 UDP特点
      • 1. 无连接
      • 2. 不可靠
      • 3. 面向数据报
      • 4. 缓冲区
      • 5. 大小受限
      • 6. 无序性
  • 2. TCP
    • 2.1 TCP结构
    • 2.2 TCP特点
      • 1. 有连接
      • 2. 可靠性
      • 3. 面向字节流
      • 4. 拥塞控制
      • 5. 头部开销
    • 2.3 TCP原理
      • 1. 确认应答(安全机制)
      • 2. 超时重传(安全机制)
      • 3. 连接管理(安全机制)
      • 4. 滑动窗口(效率机制)
      • 5. 流量控制(安全机制)
      • 6. 拥塞控制(安全机制)
      • 7. 延迟应答(效率机制)
      • 8. 捎带应答(效率机制)
    • 2.4 粘包问题

1. UDP

1.1 UDP结构

【传输层协议】UDP/TCP结构特点与原理(详解)_第1张图片

  • 2字节的长度表示整个数据报的最大长度(UDP首部+UDP数据)。
  • 校验和用来验证数据是否出错,出错就摒弃。
  • 首部8个字节。
  • 源/目的端口号:表示数据是从哪个进程来,到哪个进程去;
  • 校验和:发送端填充,CRC校验。接收端校验不通过,则认为数据有问题。

1.2 UDP特点

1. 无连接

知道对方的端口和IP就可以直接传输不用建立连接。
这使UDP更加的轻量级,适用于一些实时性高的应用。

2. 不可靠

UDP没有任何安全机制,发送端发送数据报以后,如果因为网络错误发生错误,UDP协议层也不会给应用层返回任何错误信息。

3. 面向数据报

应用层给UDP多长的报文,就会发送多长的报文,并不会拆分合并。

4. 缓冲区

UDP并没有真正的发送缓冲区,具有接受缓冲区。
UDP的scoket既能读,又能写,所以是全双工

5. 大小受限

UDP协议首部有个16位的最大长度,所以一次最多传输64Kb,包括UDP首部。

6. 无序性

UDP不保证数据包的传输顺序,这对某些应用来说可能是一个缺点,但对其他应用来说,这样的特性可以提高性能。

2. TCP

2.1 TCP结构

【传输层协议】UDP/TCP结构特点与原理(详解)_第2张图片

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

2.2 TCP特点

1. 有连接

通信双方通信前需要建立连接,知道对方的端口号和IP。

2. 可靠性

TCP提供可靠的数据传输,确保数据的完整性和顺序。主要通过确认应答。

3. 面向字节流

TCP是面向字节流的协议,而不是面向消息的。这意味着应用程序需要负责将数据分割为适当的消息或数据块,以便进行传输。

4. 拥塞控制

TCP拥有拥塞控制机制,它可以调整发送速率以避免网络拥塞。通过监控网络的延迟和丢包情况,TCP可以自动适应不同的网络条件。

5. 头部开销

TCP头部较大,包含序号、确认号、窗口大小等字段,因此在某些情况下可能引入较高的开销。

2.3 TCP原理

TCP相对UDP安全性提高,但是效率却降低了,所以TCP中引入了很多在保证安全的情况下提高传输效率。

1. 确认应答(安全机制)

TCP将每个字节的数据都进行了编号,即为序列号。每一个ACK都带有对应的确认序列号,意思是告诉发送者,我已经收到了哪些数据;下一次你从哪里开始发。
确认应答就是对方收到消息后,给出回应,让对方知道你收到了。
每当一方收到数据包时,它会发送一个确认应答,通常包含了已经成功接收的数据的序号。这确保了数据的可靠传输,因为发送方会等待确认应答,以确定数据已经到达并且没有丢失。【传输层协议】UDP/TCP结构特点与原理(详解)_第3张图片

2. 超时重传(安全机制)

当对方的回应你迟迟没有收到,当到达一定时间,可以重新发送一次。
当一方的数据包或者对方的确认应答在传输途中丢失,一定时间后会重新发送相同的数据包,直到收到确认应答。累计到一定的重传次数,TCP认为网络或者对端主机出现异常,强制关闭连接。
【传输层协议】UDP/TCP结构特点与原理(详解)_第4张图片

3. 连接管理(安全机制)

正常情况下TCP要经过三次握手建立连接,四次挥手断开连接。

三次握手

【传输层协议】UDP/TCP结构特点与原理(详解)_第5张图片
第一次握手:客户端向服务器发送一个特殊的TCP报文,这个报文中的SYN标志位被置为1,这个报文表示客户端希望建立连接。
第二次握手:服务器收到客户端的SYN报文后,需要确认建立连接。服务器会响应一个包含SYN和ACK标志位的报文。这个报文表示服务器同意建立连接。
第三次握手:客户端收到服务器的确认后,也要发送一个确认报文ACK。这个报文告诉服务器它已经收到了服务器的确认,连接建立完成。

四次挥手

【传输层协议】UDP/TCP结构特点与原理(详解)_第6张图片
第一次挥手:关闭方(通常是客户端)向另一方发送一个TCP报文,带有FIN标志位,表示它已经没有数据要发送,但仍愿意接收数据。这个报文开始了连接的关闭过程。
第二次挥手:接收方收到第一次挥手的报文后,它会发送一个ACK确认报文作为响应。表示接收方已经收到并确认了关闭方的FIN报文。
第三次挥手:接收方(通常是服务器)在确定没有更多数据要发送后,也会发送一个FIN标志的报文,通知对方它准备关闭连接。
第四次挥手:关闭方收到第三次挥手的报文后,也要发送一个ACK确认报文作为响应,以确认接收方的关闭请求。

4. 滑动窗口(效率机制)

上述传输数据时,每次发送一个数据,都需要等待ACK才能发送下一段数据,这样的效率并不高,性能较差,所以引入了滑动窗口。
如图:【传输层协议】UDP/TCP结构特点与原理(详解)_第7张图片
我们可以一次发送多条数据,这样就能才等待时间重叠在一起,提高性能。
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000个字节(四个段)。
发送前四个段的时候,不需要等待任何ACK,直接发送;
收到第一个ACK后,滑动窗口向后移动,继续发送第五个段的数据;依次类推;
操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
窗口越大,则网络的吞吐率就越高;
丢包处理

  1. 丢了ACK
    这种情况下,如果前面的部分ACK丢失,只要接受到后面的ACK,依然可以确认应答。
    【传输层协议】UDP/TCP结构特点与原理(详解)_第8张图片
  2. 丢了数据包
    当某一段报文段丢失之后,发送端会一直收到 1001 这样的ACK,就像是在提醒发送端 “我想要的是 1001” 一样;
    如果发送端主机连续三次收到了同样一个 “1001” 这样的应答,就会将对应的数据 1001 - 2000 重新发送;
    这个时候接收端收到了 1001 之后,再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中;
    这种机制被称为 “高速重发控制”(也叫 “快重传”)。
    【传输层协议】UDP/TCP结构特点与原理(详解)_第9张图片

5. 流量控制(安全机制)

接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制
TCP通过流量控制机制来管理数据传输,以确保发送方不会发送过多的数据,从而导致接收方无法处理或网络拥塞。流量控制的主要目标是防止数据包的丢失和网络拥塞。以下是TCP流量控制的关键概念和工作原理:

  1. 窗口机制:TCP使用窗口机制来进行流量控制。接收方会告诉发送方它可以接收多少数据,这个信息被称为"接收窗口大小"(Receiver
    Window Size)。

  2. 滑动窗口:发送方维护一个发送窗口,它表示当前可以发送的数据量。这个窗口的大小受到接收方的接收窗口大小和网络条件的影响。

  3. 通告窗口大小:接收方会在TCP报文中通告当前的接收窗口大小,发送给发送方。这告诉发送方可以发送多少数据,以避免过载接收方。

  4. 动态调整窗口大小:接收方可以根据自身处理能力和可用内存动态调整接收窗口大小。如果接收方无法及时处理数据,它可以减小窗口大小,通知发送方降低发送速率。

  5. 流量控制的目的:流量控制的主要目的是防止发送方发送过多数据,从而导致接收方缓冲区溢出,数据丢失,或网络拥塞。通过维护适当的接收窗口大小,TCP可以确保发送和接收之间的数据传输协调顺畅。

  6. 自适应机制:TCP的流量控制是自适应的,它可以根据网络状况进行调整。如果网络拥塞,接收方可以减小窗口大小,发送方会相应降低发送速率,从而减轻网络负担。

6. 拥塞控制(安全机制)

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。
因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。
TCP引入慢启动机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据;

【传输层协议】UDP/TCP结构特点与原理(详解)_第10张图片

7. 延迟应答(效率机制)

如果接收数据的主机立刻返回ACK应答,这时候返回的窗口可能比较小。一定要记得,窗口越大,网络吞吐量就越大,传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;
规则
数量限制:每隔N个包就应答一次;
时间限制:超过最大延迟时间就应答一次
具体的数量和超时时间,依操作系统不同也有差异;一般N取2,超时时间取200ms;

8. 捎带应答(效率机制)

在延迟应答的基础上,我们发现,很多情况下,客户端服务器在应用层也是 “一发一收” 的。意味着客户端给服务器说了 “How are you”,服务器也会给客户端回一个 “Fine, thank you”;
那么这个时候ACK就可以搭顺风车,和服务器回应的 “Fine,thank you” 一起回给客户端

2.4 粘包问题

首先要明确,粘包问题中的 “包” ,是指的应用层的数据包。
在TCP的协议头中,没有如同UDP一样的 “报文长度” 这样的字段,但是有一个序号这样的字段。
站在传输层的角度,TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。
站在应用层的角度,看到的只是一串连续的字节数据。
那么应用程序看到了这么一连串的字节数据,就不知道从哪个部分开始到哪个部分,是一个完整的应用层数据包。
那么如何避免粘包问题呢?归根结底就是一句话,明确两个包之间的边界。

  1. 对于定长的包,保证每次都按固定大小读取即可;例如上面的Request结构,是固定大小的,那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
  2. 对于变长的包,可以在包头的位置,约定一个包总长度的字段,从而就知道了包的结束位置;
  3. 对于变长的包,还可以在包和包之间使用明确的分隔符(应用层协议,是程序猿自己来定的,只要保证分隔符不和正文冲突即可);

对于UDP协议来说,是否也存在 “粘包问题” 呢?
对于UDP,如果还没有上层交付数据,UDP的报文长度仍然在。同时,UDP是一个一个把数据交付给应用层。就有很明确的数据边界。
站在应用层的站在应用层的角度,使用UDP的时候,要么收到完整的UDP报文,要么不收。不会出现"半个"的情况。

你可能感兴趣的:(计算机网络,udp,tcp/ip,网络)