3.传输层协议

一、外部视图

1. 传输层的职能

  • 根本目的:在网络层提供的数据通信服务基础上,实现主机的进程间逻辑通信的可靠服务(网络层提供的是主机间的逻辑通信

  • 三大要点:

    • 为位于两个主机内部的两个应用进程之间提供通信服务

    • 传输层协议软件属于OS内核软件而非用户软件

    • 提供可靠的通信服务

      注:可靠的意义在不同协议之间不完全相同,UDP的可靠性就弱于TCP

  • 主要协议:TCP和UDP

2. 传输层的应用编程接口(Socket)

本质上Socket就是应用层和传输层的桥梁,通过Socket API,应用程序(进程)就可以使用传输层协议进行网络间的通信。

3. 端口:标识应用进程

  • 为了使不同操作系统中的应用进程能够互相通信,就必须用统一的方法对 TCP/IP 体系的应用进程进行标识。标识的手段就是端口号

  • 端口号的分类:

    1. 熟知端口(Well-known Ports):范围从0到1023。这些端口号通常被一些广泛使用的标准服务和应用程序所占用,如HTTP(端口号80)、FTP(端口号21)、SSH(端口号22)、SMTP(端口号25)等。熟知端口是由IANA分配和管理的。

    2. 注册端口(Registered Ports):范围从1024到49151。这些端口号用于用户或应用程序自定义的服务和应用程序。它们在需要使用特定端口的应用程序之间进行协商,并在IANA的注册中心进行登记。常见的一些应用程序和服务可能使用注册端口,但不是强制性的。

    3. 动态或私有端口(Dynamic or Private Ports):范围从49152到65535。这些端口号用于临时分配给客户端应用程序,用于与服务器进行通信。通常,客户端应用程序会随机选择一个可用的动态端口进行通信。

  • 传输层通信连接的标识方法

    • 由以下五元组标识:协议、本地地址、本地端口远程地址、远程端口
  • 传输层的多路复用和多路分解

    • 运行TCP/IP协议主机中,可以同时运行不同应用层协议和不同的应用程序

二、UDP协议

1. UDP协议主要特点

  • 只在IP的数据报服务上增加了很少的一点功能

    • (多路)复用和分用

    • 差错检测(一般通过checksum函数)

  • 无连接

  • 面向报文:UDP 对应用层传递下来的报文,既不合并,也不拆分,而是保留这些报文的边界。UDP 层一次向对方交付一个完整的报文。

  • 没有拥塞控制

  • 支持多对多的交互通信

  • 首部开销小:只有 8 个字节,比 TCP 的 20 个字节的首部要短

2. UDP的适用场景

  • 对性能的要求高于对数据完整性的要求(视频播放、P2P、DNS等)

  • 需要“简短快捷”的数据交换(简单的请求与应答报文交互,如在线游戏)

  • 需要多播和广播的应用(本地广播、隧道VPN)

3. UDP的数据报格式

  1. UDP总长度(单位为bytes) = 8 (UDP报头长度) + 数据字段的字节长度 (长度必须为2字节的倍数,即为偶数)

  2. 数据字段的字节长度必须为2字节的倍数原因是:校验和的计算是以2字节为单位的(校验和是16个bits的)
  • 校验和的计算,以两个16bits整数相加为例:

一定要记得把超过16位后的数字回卷再加到结果上

当 校验范围的和 + 校验和 = 1111111111111111 通过校验

三、TCP协议

1. TCP的主要特点

  • 面向连接的传输服务(打电话式、会话式通信)

  • 字节流传输服务(字节按序传输)

  • 全双工通信

  • 可以建立多个并发的TCP连接

  • 可靠传输服务

    • 不丢失数据、保持数据有序、向上层不重复提交数据(通过确认机制、拥塞控制等方式实现)

2. TCP传输的数据单元

  • TCP是以报文段(Segment)作为传输单元

  • 报文结构

  1. 源端口号(Source Port):16位字段,表示发送方应用程序的端口号。

  2. 目标端口号(Destination Port):16位字段,表示接收方应用程序的端口号。

  3. 序列号(Sequence Number):32位字段,用于对报文段进行排序和重组。每个TCP报文段都带有一个序列号,用于指示报文段中第一个数据字节的序列号。

  4. 确认号(Acknowledgment Number):32位字段,用于确认已成功接收到的数据。指示期望接收的下一个字节的序列号。

  5. 数据偏移(Data Offset):4位字段,表示报文段头部的长度,以4字节为单位。TCP报文段头部中有一些控制字段和选项,数据偏移字段用于指示报文段头部的长度。

  6. 控制标志位(Control Flags):TCP报文段头部中有多个控制标志位,用于控制TCP连接的建立、维护和关闭等操作。常见的控制标志位包括SYN(建立连接)、ACK(确认)、FIN(关闭连接)等。

  7. 窗口大小(Window Size):16位字段,用于流量控制。表示发送方希望接收方分配的接收缓冲区大小。

  8. 校验和(Checksum):16位字段,用于检测报文段是否在传输过程中发生了错误。

  9. 紧急指针(Urgent Pointer):16位字段,用于指示报文段中紧急数据的边界。

  10. 选项(Options):可选字段,用于传输一些额外的信息或协商特定的功能和参数。

3. TCP的通信过程

TCP通信分为三个阶段:

  1. 连接建立阶段

    • 三次握手
  2. 数据双向传输阶段

    • 以滑动窗口中的多个报文段为单位的双向传输
  3. 释放连接阶段

    • 每个方向的连接,可以间隔开来释放

    • 每个方向的连接释放,需要2个报文段
  • 建立连接的三次握手如下图所示:

  • 释放连接的过程如下图所示:

注意,建立连接期间报文长度len一般为0,但SYN报文仍需要消耗一个序列号(+1);但释放连接过程中len可能不为0,所以计算ACK的公式为:

ACK = 前一个Seq + 前一个报文段len + 1

4. 滑动窗口

1 ARQ(Automatic repeat request)协议

  • 是一种使用确认、超时机制在不可靠的通信信道上实现可靠数据传输的方法

    • 若发送方在超时之前未能收到对先前发出的数据包P的确认,则发送方重传P,直到收到确认或重传次数超限

    • 用于链路层和传输层的数据传输设计

    • TCP采用的是Go-Back-N ARQ这种变体

2 TCP滑动窗口

  • TCP连接的每一端都必须设有两个窗口

    • 一个发送窗口、一个接收窗口

    • TCP 两端的四个窗口经常处于动态变化之中

    • 往返时间 RTT 也是随机的=>对超时重发提出了挑战

  • TCP 的可靠传输机制用字节的序号进行控制

    • TCP 所有的确认都是基于序号而不是基于报文段号

    • 为描述方便,我们假设所有确认号正好等于报文段的序号字段的值

  • 发送缓冲区是发送窗口的子集:表示已经发送但未经确认的数据包集合。

    接收窗口类似发送窗口。

关于GBN和SR(Selective Repeat)

  • 简单来说就是GBN的接收窗口尺寸为1;SR的接收窗口尺寸>1

适用范围:

  • 出错率低:比较适合GBN,出错非常罕见,没有必要用复杂的SR,为罕见的事件做日常的准备和复杂处理

  • 链路容量大(延迟大、带宽大):比较适合SR二不是GBN,因为一点出错的代价太大

5. 超时重传

当发送方发送数据段后,在一定时间内没有收到接收方的确认(ACK)时,发送方会认为数据丢失,并进行超时重传。由此引出往返时间RTT(Round Trip TIme的概念:

  • 如果把超时重传时间设置得太短,就会引起很多报文段不必要的重传,使网络负荷增大;但若把超时重传时间设置得过长,则又使网络的空闲时间增大,降低了传输效率。

要有效处理这个问题,需要定义一个关键的随机变量:

  • 往返时间RTT:为一个报文段自发出到收到ACK的时间间隔

对RTT、Timeout的估计

其中,

Rtt:估计的往返时间

Rts:往返时间样本(可以理解为测试值)

α:常数权重因子,设定旧的Rtt和新的Rts对新的Rtt‘的影响能力

  • RFC 2988 推荐的α值为1/8

β:超时常数加权因子,推荐值为2

Karn算法

  • Karn算法在原先的RTT估计算法的基础上,对往返时间样本Rts的采样进行了改进

其中,γ的推荐值也为2。

由于Karn不能适应时延变化很大的情况,引出了Kalman算法,主要就是套公式计算。

Kalman算法(基于RTT方差估计)

6. 流量控制

流量控制是用于控制发送方向接收方发送数据的速率,以避免接收方被过多的数据淹没而无法处理。

零窗口

  • 当TCP接收方的缓冲区满(如应用层未能及时提取数据),则接收方往发送方发送ACK报文段(数据长度=0,窗口字段=0),称之为零窗口通告

  • 窗口更新:当接收方缓冲区从满状态变到有可用空间时,接收方向发送方发送ACK报文段(数据长度=0,窗口字段>0),称之为窗口更新

    注意变的只有窗口字段,实际数据长度一直为0

  • 窗口检测:

    • 因为ACK报文段(数据长度=0, ACK=1的报文段)不被TCP可靠递送,则第2步的窗口更新有可能在网络中丢失,导致收发双方都处于等待的死锁状态。

    • 为避免活锁,发送方使用一种叫坚持定时器(persist timer)来定期触发:发送方往接收方-发送窗口探测报文段(数据长度>0, 保证被TCP递送)。

    • 作为响应,接收方自己的缓冲区可用空间大小放入ACK报文段的窗口字段,由此,发送方获知接收方是否能继续接收数据。

糊涂窗口综合征(Silly Window Syndrome)

  • SWS:小的报文段在TCP连接上传输,导致有效数据的通信效率低下

    • 小报文段的数据字段长度远小于报文段首部长度20 + IP首部长度20

    • SWS可由TCP的任何一段引起:

      接收方通过纯ACK报文段发送小的窗口通告导致SWS;

      发送方过于积极传输缓冲区中的剩余数据导致SWS。

  • 解决方案:

    • 在接收方:不发送小的窗口通告。如接收算法[RFC1122]要求,只有当接收缓冲区空闲空间:足够容纳一个MSS的报文段或者达到总缓冲空间的一半时,才发送窗口通告   ( Clark算法)

    • 在发送方:由Nagle算法控制何时发送数据,一般不发送小报文段,但在下述情况,发送方立即发送数据:

      • 当发送缓冲区的数据大到可以组装成一个MSS

      • 当发送缓冲区的数据大到接收方所有通知窗口中最大窗口尺寸的一半

      • 发送方不在等待ACK、或者Nagle算法被禁止

    • Nagle算法:

7. 拥塞控制

拥塞控制是一种网络流量管理机制,用于在网络拥塞发生时控制数据的发送速率,以保证网络的稳定性和可靠性。

当多个主机端点通过TCP向整个网络注入数据时,TCP如果不对注入数据的速率进行控制,将导致整个网络出现拥堵:

  • 往返时延增大导致TCP重传,进一步增加拥堵

  • 中间路由器的缓冲容量有限. 当IP数据报的到达率持续超过发出率时,中间路由器的缓冲变满, 只好丢弃新进的数据包,导致TCP重传

有三种方法能让TCP感知网络拥塞,从而达到拥塞控制的效果:

  • 丢包计数

  • 度量往返时延

  • ECN(Explicit Congestion Notification)

1. 拥塞控制和流量控制是同时进行的

发送窗口 = min(通知窗口rwnd, 拥塞窗口cwnd)

发送方发送数据是取接收方的接受能力(流量控制)和网络传输能力(拥塞控制)的最小值,这样同时满足了流量和拥塞控制。

  • 通知窗口rwnd,拥塞窗口cwnd都是动态变化的

    • rwnd由接收方显式控制(其实就是接收方可用缓冲区大小),通过ACK报文段通知发送方

    • cwnd是对网络拥塞的一种度量,是个随机量

2. 拥塞时间的判断方法

  • 重传定时器超时

  • 收到三个相同的ACK(严谨来说是3+1)

3. TCP的拥塞控制算法

  • 慢开始

  • 拥塞避免

  • 快重传

  • 快恢复

  1. 慢开始)在没有发送拥塞的时候,此时 拥塞窗口 < SST(Slow Start Threshold)拥塞窗口大小按照指数级别增大

  2. (拥塞避免)此时 拥塞窗口 >= SST。拥塞窗口大小线性增大(每收到一个ACK, cwnd += 1*最大报文长度MSS)

  3. 拥塞事件发生后,有两种情况,分别是三次冗余ACK、出现超时(丢包):

    • 出现三次冗余ACK后,SST = cwnd/2 、cwnd = cwnd/2,然后进入下一个拥塞避免阶段

    • 当出现超时(丢包)后,SST = cwnd/2 、cwnd = 1,然后进入下一个慢开始阶段

注:开始时,SST有默认值。


3.传输层协议
https://steve-1936550490.github.io/posts/40612/
Author
Hidden Blue
Posted on
June 24, 2023
Licensed under