传输层

传输层

Tue Oct 01 2024
zzcoe
14 分钟
计网
未分配标签
3714 字

UDP 协议#

用户数据报协议,UDP 是一种面向 无连接的,高效率,低可靠性 传输层通信协议

特点

  1. 发送数据之前不需要建立链接,直接传,为了快!
  2. 不对数据包的顺序进行检查,不安全,为了快!!
  3. 没有错误检测和重传机制,为了快!!!

服务对象

主要用于 查询一应答 的服务,如: NFS、NTP、DNS 等

应用

一些对速度有高要求,而不关心数据包是否接收到的场景,也就是一些实时性高的场景 ,例如:语音或视频通话,直播等

UDP 首部#

Pasted image 20240922181039

  1. 源端口号:发送方所使用的端口号
  2. 目的端口号:接受放的端口号
  3. UDP 数据报长度:以字节为单位,最小为 8,即仅首部
  4. 校验和:检测数据报是否有错误,计算时需增加伪首部

UDP 单播,广播,组播#

单播#

用于两个主机之间端对端的通信。即一对一(客户端与服务器端点到点连接)。

广播#

用于一个主机对整个局域网上所有主机通信。即一对所有。广播禁止在 Internet 宽带网上传输(广播风暴)。需要指定目的 IP 地址 255.255.255.255 和接受者的端口号

组播 (多播)#

对一组特定的主机进行通信,而不是整个局域网上的所有主机。即一对一组

将网络中同一业务类型主机进行了逻辑上的分组,进行数据收发的时候其数据仅仅在同一分组中进行,其他的主机没有加入此分组不能收发对应的数据。

在多播系统中,有一个源点一组终点。这是一对多的关系。在这种类型的通信中,源地址是一个单播地址,而目的地址则是一个组地址。

IP 多播通信必须依赖于 IP 多播地址,在 IPv 4 中它是一个 D 类 IP 地址,范围从224.0.0.0 到 239.255.255.255,并被划分为局部连接多播地址、预留多播地址和管理权限多播地址三类。

局部多播地址224.0.0.0~224.0.0.244之间,是为路由协议和其他用途保留的地址,路由器并不转发属于此范围的 IP 包。
预留多播地址224.0.1.0~238.255.255.255之间,可用于全球范围(如 Internet)或网络协议。
本地管理组播地址239.0.0.0~239.255.255.255之间,可供组织内部使用,类似于私有 IP 地址,不能用于 Internet,可限制多播范围。

TCP 协议#

又称传输控制协议,TCP 是一种面向 连接的, 可靠的,基于字节流 传输层的 全双工 通信协议

特点:

  1. 建立链接->使用链接->释放链接 (虚电路)
  2. TCP 数据包中 包含序号和确认序号
  3. 对包进行排序并检错,而损坏的包可以被重传

应用

需要高度可靠性且面向连接的服务,如 HTTP(网页)、FTP(文件)、SMTP(邮件) 等

TCP 首部#

Pasted image 20240922182006|669

  1. 源端口号: 发送方端口号
  2. 目的端口号: 接收方端口号
  3. 序号(seq): 该数据报的第一个字节的序号,例如:一个报文段的序号字段值是 200,携带的数据总共有 100 字节,表明这个报文段的数据的最后一个字节的序号是 299,所以下一个报文段的数据序号应从 300 开始。防止乱序问题出现
  4. 确认序号(ACK): 期望收到对方下一个报文段的第一个数据字节的序号,防止丢包,如果确认序号不对,就让对面重新发送
  5. 数据偏移: TCP 报文段的数据起始处距 TCP 报文段的 起始处 有多远,即首部长度。单位: 4 字节注意和 IP 分片的数据偏移做区分
  6. 保留: 占 6 位,保留为今后使用,目前应置为 0
  7. 紧急 URG: 此位置 1,表明紧急指针字段有效,告知系统此报文段中有紧急数据,应尽快传送,配合紧急指针使用,从第一个字节到紧急指针所指字节就是紧急数据。
  8. 确认 ACK: 仅当 ACK=1 时确认号字段才有效,TCP 规定,在连接建立后所有传达的报文段都必须把 ACK 置 1
  9. 推送 PSH: 当两个应用进程进行交互式的通信时,有时在一端的应用进程希望在键入一个命令后立即就能够收到对方的响应。在这种情况下,TCP 就可以使用推送 (push) 操作,这时,发送方 TCP 把 PSH 置 1,并立即创建一个报文段发送出去,接收方收到 PSH=1 的报文段,就尽快地 (即“推送”向前) 交付给接收应用进程,而不再等到整个缓存都填满后再向上交付
  10. 复位 RST: 原连接出现错误,用于复位相应的 TCP 连接
  11. 同步 SYN: 仅在三次握手建立 TCP 连接时有效。当 SYN=1 而 ACK=0 时,表明这是一个连接请求报文段,对方若同意建立连接,则应在相应的报文段中使用 SYN=1 和 ACK=1. 因此,SIN 置 1 就表示这是一个连接请求或连接接受报文
  12. 终止 FIN: 用来释放一个连接。当 FIN 1 时,表明此报文段的发送方的数据已经发送完毕,并要求释放运输连接。
  13. 窗口: 因为缓存空间有限,使用窗口表示自己目前可用的缓存空间。同时用于 TCP 的流量控制,表明自己的处理能力
  14. 校验和: 校验和字段检验的范围包括首部和数据两部分,在计算校验和时需要加上 12 字节的伪首部
  15. 紧急指针: 仅在 URG=1 时才有意义,它指出本报文段中的紧急数据的字节数 (紧急数据结束后就是普通数据),即指出了紧急数据的末尾在报文中的位置,注意: 即使窗口为零时也可发送紧急数据
  16. 填充:使得首部长度是 4 字节的整数倍

TCP 链接控制#

三次握手#

Pasted image 20240922183528 接下来就可以传送应用层数据了。TCP 提供的是全双工通信,因此通信双方的应用进程在任何时候都能发送数据。注意:服务器端的资源是在完成第二次握手时分配的,而客户端的资源是在完成第三次握手时分配的。所以服务器易于受到 SYN 洪泛攻击。

四次挥手#

Pasted image 20240922184356 因为 TCP 是全双工通信,前两次挥手表示客户端不会再向服务器发送数据,此时服务器依然可以向客户端发送数据报(半关闭状态),后两次挥手后两者完全断开。

为什么是三次和四次#

TCP 同时打开同时关闭#

同时打开#

双方同时申请连接 Pasted image 20240922190909

同时关闭#

双方同时申请断开连接 Pasted image 20240922190943

TCP 可靠性的保证#

  1. 序列号顺序控制:针对数据报到达接受端的乱序问题
  2. 校验和:针对数据报再传输过程种发生变化的问题
  3. 确认应答信号:针对发送端发出的数据包的确认应答信号 ACK
  4. 重发机制:针对数据报丢失或者定时器超时
  5. 连接管理:
  6. 窗口控制:针对数据缓冲区不够用的问题
  7. 流量控制:针对网络拥挤的情况,减少发送的速度

滑动窗口#

TCP 使用滑动窗口来实现流量控制

滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。

当滑动窗口为 0 时,发送方一般不能再发送数据报,但有 两种情况除外 ,一种情况是可以 发送紧急数据,例如,允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。 探测报文

慢启动算法#

防止一开始就发送大量数据导致网络瘫痪的问题。在 TCP 刚刚连接好,开始发送 TCP 报文段时,先让拥塞窗口 cwnd=1,即一个最大报文段长度 MSS。而在每收到一个对新的报文段的确认后,将 cwnd 加倍,即刚开始会增大一个 MSS。用这样的方法逐步增大发送方的拥塞窗口 cwnd,可以使分组注入到网络的速率更加合理。

Cwnd 以指数形式增长直到达到 ssthresh 阈值,接着启用拥塞控制算法

拥塞避免算法#

发送端的拥塞窗口 cwnd 每经过一个往返时延 RTT 就 增加一个 MSS 的大小 ,而不是加倍,使 cwnd 按线性规律缓慢增长,而当出现一次超时 (网络拥塞) 时,会令慢开始门限 ssthresh 等于当前 cwnd 的一半。

冗余 ACK#

如果收到的报文顺序不对,就再次发送刚才的 ACK,表示我想要的是这个序号的报文,当发送发收到三个相同的 ACK 后就默认想要的数据报丢失。

快速重传#

快重传并非取消重传计时器,而是在某些情况下可更早的重传丢失的报文段。当发送方连续收到三个重复的 ACK 报文时,直接重传对方尚未收到的报文段,而不必等待那个报文段设置的重传计时器超时。

快速恢复#

当检测到丢包(通过收到三个重复的 ACK),发送方会将拥塞窗口(cwnd)减半,而不是重置为 1。这是为了避免过度减少发送速率(即快速恢复)。重新开始发送数据报,当收到确认 ACK 后,进入拥塞避免阶段。

TCP 超时重传机制#

重传计时器(Retransmission Timer)#

也就是确认应答 ACK 的等待时间,超过这个时间就说明数据报丢失,进行重传。一般计时器时间=2\*RTTRTT:表示客户端和服务器的一个往返时间。RTT 并不固定,是动态的。

坚持计时器(persistent timer)#

坚持计时器的主要作用是 避免发送方和接收方在窗口大小为零的情况下进入死锁状态 ,从而确保数据传输的连续性。

针对滑动窗口为 0 的情况,当发送端收到滑动窗口为零时开始计时,计时倒时就发送一个探测报文( #探测报文 [[传输层#滑动窗口]] )。

如果接收方的窗口持续为零,发送方会定期发送探测报文(通常是一个字节),以检查接收方的窗口是否已经打开。这种探测会一直持续,直到接收方的窗口变大或连接被认为超时(认为连接失效,避免无限等待)。

保活计时器(keeplive timer)#

每当服务器收到客户的信息,就将 keeplive timer 复位,超时通常设置 2 小时,若服务器超过 2 小时还没有收到来自客户的信息,就发送探测报文段,若发送了 10 个探测报文段(每 75 秒发送一个)还没收到响应,则终止连接。

时间等待计时器(Time_Wait Timer)#

在连接终止期使用,当 TCP 关闭连接时,并不认为这个连接就真正关闭了,在时间等待期间,连接还处于一种中间过度状态。这样就可以时重复的 fin 报文段在到达终点后被丢弃,这个计时器的值通常设置为一格报文段寿命期望值的两倍。

TCP 分段#

前置知识: [[数据链路层#MTU 概念]] #tcp分段
Pasted image 20240929195327

什么是 MSS?#

MSS:Maximum Segment Size 。TCP 提交给 IP 层最大分段大小,不包含 TCP Header 和  TCP Option,只包含 TCP Payload ,MSS 是 TCP 用来限制应用层最大的发送字节数。

假设 MTU= 1500 byte,那么 MSS = 1500- 20 (IP Header) -20 (TCP Header) = 1460 byte,如果应用层有 2000 byte 发送,那么需要两个切片才可以完成发送,第一个 TCP 切片 = 1460,第二个 TCP 切片 = 540

为什么要 TCP 分段?#

IP 协议不是可靠传输,如果交给 IP 分片,一个分片丢失,TCP 就要重传整个数据报,所以由 TCP 分段,丢失后只重传丢失的就好了。

在发送端如果 TCP 分段了,那 IP 一定不会分片,但可能还会再链路上的其他设备分片

如果链路上还有设备有 更小的 MTU ,那么还会再分片,最后所有的分片都会在 接收端 处进行组装。[[网络层#IP 分片]]