计算机网络笔记（五）：传输层

Jeff_

已于 2022-01-18 19:59:59 修改

阅读量1.2k

点赞数 1

文章标签：计算机网络 mesh 网络

于 2021-11-24 20:42:46 首次发布

本文链接：https://blog.csdn.net/weixin_40539125/article/details/121524293

版权

文章目录

前言
多路复用和多路分用
UDP（User Datagram Protocol [RFC 768]）
可靠数据传输原理
流水线机制与滑动窗口协议
- Go - Back - N （GBN）协议
- Selective Repeat （SR）协议
TCP 协议 (RFCs-793, 1122, 1323, 2018, 2581)

前言

理解传输层服务的基本理论和基本机制

多路复用/分用
可靠数据传输机制
流量控制机制
拥塞控制机制

在这里插入图片描述
传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制。

端系统运行传输层协议

发送方：将应用递交的消息分成一个或多个的Segment，并向下传给网络层。
接受方：将接收到的Segment组装成消息，并向上交给应用层。

传输层与网络层

网络层：提供主机之间的逻辑通信机制
传输层：提供应用进程之间的逻辑通信机制

可靠的、按序的交付服务（TCP）

拥塞控制
流量控制
连接建立

不可靠的交付服务（UDP）

基于“尽力而为（Best-effort）”的网络层，没有做（可靠性方面的）扩展

两种服务均不保证延迟、带宽。

多路复用和多路分用

如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用。

在这里插入图片描述
主机接收到IP数据报（datagram）

每个数据报携带源IP地址、目的IP地址
每个数据报携带一个传输层的端（segment）
每个段携带源端口号和目的端口号

主机收到Segment之后，传输层协议提供IP地址和端口号信息，讲Segment导向相应的Socket

TCP做很多处理

无连接分用

利用端口号创建Socket
UDP的Socket用二元组标识（目的IP地址，目的端口号）
主机收到UDP段后
- 检查段中的目的端口号
- 将UDP段导向绑定在该端口号的Socket
来自不同源IP地址和/或源端口号IP数据包被导向同一个Socket

在这里插入图片描述

面向连接的分用

TCP的Socket用四元组标识：源IP地址、源端口号、目的IP地址、目的端口号
接收端利用所有的四个值将Segement导向合适的Socket
服务器可能同时支持多个TCP Socket
- 每个Socket用中间的四元组标识
Web服务器为每个客户端开不同的Socket

在这里插入图片描述

UDP（User Datagram Protocol [RFC 768]）

基于Internet IP协议，增加了：

复用 / 分用
简单的错误校验

“Best effort” 服务，UDP段可能：

丢失
非按序到达

无连接

UDP发送发和接收方之间不需要握手
每个UDP段的处理独立于其他段

UDP为什么存在？

无需建立连接（减少延迟）
实现简单：无需维护连接状态
头部开销少
没有拥塞控制：应用可更好地控制发送时间和速率

应用

常用于流媒体应用：容忍丢失、速率敏感
UDP还用于：DNS、SNMP

在UDP上实现可靠数据传输？

在应用层增加可靠性机制
应用特定的错误恢复机制

UDP校验和（checksum）

目的：检测UDP段在传输中是否发生错误（如，位翻转）

发送方：

将段的内容视为16-bit整数
校验和计算：计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和
发送方将校验和放入检验和字段

在这里插入图片描述

接收方：

计算所收到段的检验和
将其与校验和字段进行对比：不相等则检测出错误，相等则没有检测出错误（但可能有错误）

可靠数据传输原理

什么是可靠：不错、不丢、不乱

可靠数据传输协议：

可靠数据传输对应用层、传输层、链路层都很重要
网络Top-10问题
信道的不可靠特性决定了可靠数据传输协议（rdt）的复杂性

在这里插入图片描述

可靠性数据传输协议

渐进地设计可靠数据传输协议的发送方和接收方
只考虑单项数据传输，但控制信息双向流动
利用状态机（Finite State Machine，FSM）刻画传输协议

Rdt 1.0 : 可靠信道上的可靠数据传输

底层信道完全可靠：不会发生错误（bit error），不会丢弃分组
发送方和接收方的FSM独立

Rdt 2.0：不可靠（例如，产生位错误，但是没有丢包）信道的可靠数据传输

底层信道可能翻转分组中的位（bit）
- 利用 校验和 检测位错误
如何从错误中恢复？
- 确认机制（Acknowledgments，ACK）：接收方显示地告知发送方分组已正确接收
- NAK：接收方显示地告知发送方分组有错误
- 发送方收到NAK后，重传分组
基于这种重传机制的rdt协议称为 ARQ（Automatic Repeat reQuest）协议
Rdt 2.0中引入的新机制
- 差错检测
- 接收方反馈控制消息：ACK / NAK
- 重传

在这里插入图片描述
Rdt 2.0 缺陷：

如果 ACK/NAK 消息发生错误/被破坏（corrupted）会怎么样？ 我们思考下面几种方案：

为ACK / NAK 增加校验和，检错并纠错
发送方收到被破坏ACK / NAK 时不知道接收方发生了什么，添加额外的控制消息
如果ACK / NAK 坏掉，发送方重传
重传，但不能简单的重传：产生重复分组

我们一般选择重传，但如何解决重复分组问题？

序列号（Sequence number）：发送方给每个分组增加序列号
接收方丢弃重复分组

Rdt 2.1 ：针对ACK / NAK 破坏

发送方：

为每个分组增加序列号（0，1）
需校验ACK / NAK 消息是否发生错误
状态数量翻倍
- 状态必须”记住“”当前“的分组序列号
  
  接收方
需判断分组是否重复
- 当前所处状态提供了期望收到分组的序列号
注意：接收方无法知道ACK / NAK 是否被发送方正确收到

我们真的需要两种确认消息（ACK+NAK）吗？

Rdt 2.2：无NAK消息协议

接收方通过ACK告知最后一个被正确接收的分组
在ACK消息中显式的加入被确认分组的序列号
发送方收到重复ACK之后，采取与收到NAK消息相同的动作，重传当前分组

在这里插入图片描述
如果信道既可能发生错误，也可能丢失分组，怎么办？

“校验和 + 序列号 + ACK + 重传” 够用吗？

方法：发送方等待“合理”时间

如果没有收到ACK，重传
如果分组或者ACK只是延时而不是丢了
- 重传会产生重复，序列号机制能够处理
- 接收方需要在ACK中显示告知所确认的分组
需要定时器

Rdt 3.0：添加超时机制

在这里插入图片描述

计时器过短 / timeout 早熟将造成大量出现重复包，如何合理设置计时器时间？

Rdt3.0 能够正确工作，但性能很差，因为其是停等协议，需要等待回复。
在这里插入图片描述

Rdt 3.0 虽然功能正确，但是其性能太过于糟糕，因为停等的操作，1G的链路上1秒钟才只能传输33KB的数据，于是流水线机制应运而生（在等待的情况下发送其他分组的数据）。

在这里插入图片描述

流水线机制与滑动窗口协议

允许发送方在收到ACK之前连续发送多个分组

更大的序列号范围
发送方和/或接收方需要更大的存储空间以缓存分组

滑动窗口协议 : Sliding - Window Protocol

窗口

允许使用的序列号范围
窗口尺寸为N：最多有N个等待确认的消息

滑动窗口：随着协议的允许，窗口在序列号空间内向前滑动

滑动窗口协议：GBN，SR

在这里插入图片描述

绿色：发送完已确认的数据
黄色：发送完待确认的数据
蓝色：还可以使用的序列号空间

Go - Back - N （GBN）协议

发送方

分组头部包含k-bit 序列号
窗口尺寸为N，最多允许N个分组未确认
ACK(n) ：确认到序列号n（包含n）的分组均已被正确接收（可能收到重复ACK）
为空中的分组设置计时器
超时Timeout（n）事件：重传序列号大于等于n，还未收到ACK的所有分组

在这里插入图片描述

接收方

ACK机制：发送拥有最高序列号的、已被正确接收的分组的ACK
- 可能参产生重复ACK
- 只需要记住唯一的expectedseqnum
乱序到达的分组
- 直接丢弃 -> 接收方没有缓存
- 重新确认序列号最大的、按序到达的分组
  
  GBN有什么缺陷？
GBN在重传时会重传多个分组（例如：序列号N丢失之后，会重传N及以后没确认的分组）
网络中充斥着这些重传的分组，影响性能

怎么避免这些缺陷？

不适用累计确认机制，单个确认
不丢弃乱序的分组，缓存起来

Selective Repeat （SR）协议

接收方对每个分组单独确认

设置缓存机制，缓存乱序达到的分组

发送方只重传那些没收到ACK的分组

为每个分组设置单独定时器，该分组超时没有收到ACK时，进行重传

发送方窗口

N个连续的序列号
限制已发送且未确认的分组

TCP 协议 (RFCs-793, 1122, 1323, 2018, 2581)

特点：

点对点：一个发送方，一个接收方
可靠的、按序的字节流
流水线机制：TCP拥塞控制和流量控制机制、设置窗口尺寸
发送方 / 接收方缓存
全双工（full-duplex）：同一连接中能够传输双向数据流
面向连接：1. 通信双方在发送数据之前必须建立连接。2. 连接状态只在连接的两端中维护，在沿途节点中并不维护状态。 3. TCP连接包括：两台主机上的缓存、连接状态变量、Socket等。
流量控制机制

在这里插入图片描述
序列号（sequence number）：

序列号指的是Segment中第一个字节的编号，而不是Segment的编号，该序列号被用来跟踪该端发送的数据量。
建立TCP连接时，双方随机选择序列号（不完全随机，而是随着时间流逝而线性增长，到了2^32尽头再回滚），为的就是让攻击者更难以猜测sequence number，因为伪造的sequence number不在合法范围内，而被接收方丢弃，增加安全性。

举例，随机序列号从0开始，有1K个字节的数据拆成两个segment，则第二的segment的编号是501。

Acks：

希望接收到的下一个字节的序列号，即上一个字节的序列号Seq加1
累计确认：该序列号之前的所有字节均已被正确接收到

问：接受方如何处理乱序到达的Segment?（GBN协议乱序到达直接丢弃，SR协议使用缓存机制）

答： TCP规范中没有规定，由TCP的实现者做出决策

在这里插入图片描述

TCP可靠数据传输

特点：

IP层提供不可靠的数据传输，TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
流水线机制
累计确认
TCP使用单一重传定时器
触发重传的事件：1. 超时 2. 收到重复ACK
渐进式：1. 暂不考虑重复ACK 2. 暂不考虑流量控制 3. 暂不考虑拥塞控制

问题：如何设置定时器的超时时间？

大于RTT：但是RTT是变化的
过短：不必要的重传
过长：对段丢失时间反应慢

问题：如何评估RTT（Round-trip delay：来回通讯延时）？

SampleRTT：测量从段发出去到收到ACK的时间（忽略重传）
SampleRTT变化：测量多个SampleRTT，求平均值，形成RTT的估计值EstimatedRTT

定时器超时时间的设置：
EstimatedRTT + “安全边界”
EstimatedRTT变化大 -》较大的边界

测量RTT的变化值：SampleRTT与EstimatedRTT的差值

TCP发送方事件：

从应用层收到数据：创建Segment、序列号是Segment第一个字节的编号、开启定时器、设置超时事件TimeOutInterval
超时：重传引起超时的Segment、重启定时器
收到ACK：如果确认此前未确认的Segment，更新SendBase。如果窗口中还有未确认的分组，重新启动定时器。

在这里插入图片描述

TCP 接收方：ACK生成（RFC 1122，RFC 2581）
在这里插入图片描述

快速重传机制

TCP的实现中，如果发生超时，超时事件间隔将重新设置，即将超时事件间隔加倍，导致其很大，重发丢失的分组之前要等待很长事件。

通过重复ACK检测分组丢失：Sender会背靠背地发送多个分组，如果某个分组丢失，可能引发多个重复的ACK
如果Sender收到同一数据的3个ACK，则假定该数据之后的段已经丢失。
快速重传：在定时器超时之前即进行重传，而不必等待TimeOut。

TCP流量控制

接受方为TCP 连接分配 Buffer：
在这里插入图片描述

Flow Control 流量控制：发送方不会传输的太多、太快以至于淹没接收方（Buffer溢出）

速度匹配机制

在这里插入图片描述

TCP连接管理

TCP 发送方和接收方在传输数据前需要建立连接

初始化TCP变量
- Seq.#
- Buffer 和流量控制信息
Client：连接发起者
- socket clientSocket = new Socket(“hostname”，“port number”)；
server：等待客户连接请求
- socket connectionSocket = welcomeSocket.accept()；

Three way handshark：

Step1：客户端主机向服务器发送 TCP SYN segment (Synchronize Sequence Numbers，同步序列编号)
- SYN序列号置一，表示需要建立连接
- 特殊的客户端初始序列号 seq # （一般是随机数）
- 不包含数据
Step2：服务端主机接收SYN，答复 SYNACK segment
- 服务器分配缓存
- 特殊的服务端初始序列号 seq #（一般是随机数）
Step3：客户端收到SYNACK，答复 ACK segment
- SYN序列号不在置1，与服务器确认同一建立连接的报文段
- 可以包含数据

在这里插入图片描述
是不是在三次握手的第二步服务器就会分配资源吗？假如说三次握手客户端向服务器的ACK没有发送过来，这时候服务器的资源会保留一段时间，直到超时确认连接不会建立，ACK将不会到来时释放资源。

假如大量客户端向服务器发起建立连接请求，当服务器返回SYNACK之后，客户端不回复ACK，这时候会怎么样？服务器的资源时候会耗尽？

Closing a connection：

Step 1：client向Server发送TCP FIN 控制 segment
Step 2：server收到FIN，回复ACK，关闭连接，发送FIN
Step 3：Client收到FIN，回复ACK：进入“等待”，确保服务器关闭并释放资源。此时如果重复收到FIN，会重复发送ACK
Step 4：server收到ACK，连接关闭

在这里插入图片描述
请添加图片描述

拥塞控制原理

对比：

可靠数据传输针对端到端的，个体的利益传输的角度，采用确认、重传保证数据传输。
流量控制是发送方不要发送太快以至于接收方处理不了。
拥塞控制更像是群体利益考虑，个体之间做出一定的牺牲保证网络的负载，确保网络处理速度。

拥塞（Congestion）

非正式定义：太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理。
表现：分组丢失（路由器缓存溢出）、分组延时过大（在路由器缓存中排队）
拥塞控制 VS 流量控制
A top-10 problem
当分组被drop时，任何用于该分组的“上游路由”传输能力全部被浪费掉

为什么拥塞控制需要在传输层来做？不是所有的传输层协议都需要拥塞控制，比如UDP。

拥塞控制的方法有哪些？

端到端拥塞控制

网络层不需要显示的提供支持
端系统通过观察Loss、delay等网络行为判断是否发送拥塞
TCP采取这种方法

网络辅助的拥塞控制

路由器向发送方显示地反馈网络拥塞信息
简单的拥塞指示（1bit）： SNA，DECbit，TCP/IP ECN，ATM
指示发送方应该采取何种速率

案例：ATM ABR拥塞控制

ABR：available bit rate

“弹性服务”
如果发送方路径“underloaded”，使用可用带宽（降低当前带宽）
如果发送方路径拥塞，将发送速率降低最低保障速率

RM（resource management）cells：穿插在Data cells之间

发送方发送
交换机设置RM cell位（网络辅助）
- NI bit：rate不许增长
- CI bit：拥塞指示
RM cell 由接收方返回给发送方

在这里插入图片描述

TCP 拥塞控制

Sender限制发送速率： $L a s t B y t e S e n t - L a s t B y t e A c k e d < = C o n g w i n$

$\frac{CongWin}{RTT} Bytes/sec$

Congwin ：1. 动态调整以改变发送速率 2. 反映所感知到的网络拥塞

问题：如何感知网络拥塞？

Loss事件 = TimeOut 或者 3个重复ACK
发生Loss事件后，发送方减低速率

如何合理地调整发送速率？

慢启动：SS
- TCP连接建立时，CongWin = 1。例如：MSS = 500 Byte，RTT = 200msec，初始速率 = 20k bps
- 可用带宽可能远远高于初始速率：希望快速增长
- 原理：当连接开始时，指数性增长，每个RTT将CongWin翻倍，收到每个ACK进行操作。
加性增——乘性减： AIMD 拥塞避免
- 原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生Loss Event。
- 方法：AIMD 1. Additive Increase，每个RTT将CongWin增大一个MSS（最大段长度），进行拥塞避免。 2. Multiplicative Decrease，发生Loss后将CongWin减半。