三、传输层
传输层工作原理：
- 多路复用/解复用
- 可靠数据传输
- 流量控制
- 拥塞控制
传输层协议：
- UDP：无连接传输
- TCP：面向连接的可靠传输
- TCP拥塞控制
传输服务和协议
为运行在不同主机上的应用进程提供逻辑通信
传输协议运行在端系统
- 发送方：将应用层的报文分成报文段，然后传递给网络层
- 接收方：将报文段重组成报文，然后传递给应用层
有多个传输层协议可供应用层选择
- Internet：TCP和UDP
传输层VS网络层
网络层服务
主机之间的逻辑通信
传输层服务
进程间的逻辑通信
- 依赖于网络层的服务（延时、带宽）
- 对网络层的服务进行增强（数据丢失、顺序混乱、加密）
服务的可靠性可以加强，安全性可以加强
但是例如：延迟、带宽等属性不可以被加强的
Internet传输层协议
多路复用/解复用
多路解复用工作原理
解复用作用：TCP或UDP实体采用哪些信息，将报文的数据部分交给正确的socket，从而交给正确的进程
主机收到IP数据报
- 每个数据报有源IP地址和目标地址
- 每个数据报承载一个传输层报文段
- 每个报文段有一个源端口号和目标端口号（特定应用有著名的端口号）
主机联合使用IP地址和端口号将报文段发送给合适的套接字
无连接（UDP）多路解复用
面向连接（TCP）多路复用
无连接传输：UDP
用户数据报协议（User Datagram Protocol）【RFC 768】
“尽力而为”的服务，报文段可能：丢失、乱序
无连接：：
- UDP发送端和接收端之间没有握手
- 每个UDP报文段都被独立地处理
UDP被用于：
- 流媒体
- DNS
- SNMP
在UDP上进行可靠传输：
- 在应用层增加可靠性
- 应用特定的差错恢复
UDP：用户数据报协议
UDP校验和
目标：检测在被传输报文段中的差错
发送方：
- 将报文段的内容视为16比特的整数
- 校验和：报文段的加法和（1的补运算）
- 发送方将校验和放在UDP的校验和字段
接收方：
- 计算接收到的报文段的校验和
- 检查计算出的校验和与校验和字段的内容是否相等（不相等——有差错、相等——可能有残存错误）
例子
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-teNCRC37-1643866898667)(https://img.samuel-luo.space/image-20220121174740327.png)]
可靠数据传输（rdt）的原理
rdt在应用层、传输层、数据链路层都很重要
是网络Top10问题之一
信道的不可靠特点决定了可靠数据传输协议（rdt）的复杂性
问题描述
rdt 1.0：在可靠信道上的可靠数据传输
下层的信道是完全可靠的
- 没有比特出错
- 没有分组丢失
发送方和接收方的FSM
- 发送方将数据发送到下层信道
- 接收方从下层信道接收数据
rdt 2.0：具有比特差错的信道
下层信道可能会出错：将分组中的比特翻转
- 用校验和来检测比特差错
怎样从差错中恢复
- 确定（ACK）：接收方显式地告诉发送方分组已被正确的接收
- 否定确定（NAK）：接收方显式地告诉发送方分组发生了差错（发送方收到NAK后，发送方重传分组）
新机制：采用差错控制编码进行差错检测
- 发送方差错控制编码、缓存
- 接收方使用编码检错
- 接收方的反馈：控制报文（ACK、NAK）：接收方 -> 发送方
- 发送方收到反馈响应的动作
FSM描述
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-er3KF5sq-1643866898669)(https://img.samuel-luo.space/image-20220121204803578.png)]
缺陷
ACK和NCK可能出错！
rdt 2.1
新机制：使用序号
- 发送方在每个分组中加入序号
- 如果ACK/NAK出错，发送方重传当前分组
- 接收方丢弃重复分组
停等协议
发送方发送一个分组，然后等待接收方的应答
发送方处理出错的ACK/NAK
接收方处理出错的ACK/NAK
小结
rdt 2.2：无NAK的协议
功能同rdt2.1，但只是用ACK（ACK要编号）
接收方对最后正确接收的分组发ACK
- 接收方必须显式地包含被正确接收分组的序号
当收到重复的ACK时，发送方与收到NAK采取相同的动作：重传当前分组
为后面的一次发送多个数据单位做一个准备
- 一次能够发送多个
- 使用前一个数据单位的ACK，代替本数据单位NAK
- 确认信息减少一半，协议处理简单
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jtb7GXNt-1643866898674)(https://img.samuel-luo.space/image-20220121214356801.png)]
rdt 3.0：具有比特差错和分组丢失信道
发送方等待ACK一段合理的时间（链路层的timeout时间确定传输层timeout时间，是自适应的）
- 发送端超时重传：如果到时没有收到ACK -> 重传
- 需要一个倒计数定时器
发送方
运行时
性能
rdt 3.0可以工作，但链路容量较大的情况下，性能很差
- 链路容量比较大，一次发一个PDU不能够充分利用链路的传输能力
例子
停 - 等协议
流水线：提高链路利用率
流水线协议
流水线：允许发送方在未得到对方确认的情况下一次发送多个分组
- 必须增加序号的范围：用多个bit表示分组的序号
- 在发送方/接收方要有缓冲区（发送方缓冲：未得到确认，可能要重传；接收方缓存：接收到的数据可能乱序，排序交付）
两种通用流水线协议：回退N步（GBN）和选择重传（SR）
通用：滑动窗口（slide window）协议
发送缓冲区
- 形式：内存中的一个区域，落入缓冲区的分组可以发送
- 功能用于存放已发送，但是没有得到确认的分组
- 必要性：需要重发时可用
发送缓冲区的大小
- 停止等待协议 = 1
- 流水线协议 > 1，合理的值，不能太大，链路利用率不能够超100%
发送缓冲区中的分组
- 未发送的：落入发送缓冲区的分组，可以连续发送出去
- 已经发送出去的、等待对方确认的分组：发送缓冲区的分组只有得到确认才会删除
发送窗口：发送缓冲区内容的一个范围
- 已发送但是未经确认的分组序号构成的空间
发送窗口的最大值 <= 发送缓冲区
发送窗口初始值：后沿 = 前沿，尺寸 = 0
每发送一个分组，前沿移动一个单位，前沿不能超过发送缓冲区
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RN89CIeF-1643866898680)(https://img.samuel-luo.space/image-20220122184833263.png)]
每确认一个后沿分组，后沿移动一个单位，后沿不能超过前沿
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-K6ivxdWb-1643866898681)(https://img.samuel-luo.space/image-20220122185513318.png)]
移动过程
接收窗口 = 接收缓冲区
- 接收窗口用于控制哪些分组可以接收（只有收到分组序号落入接收窗口内才允许接收，若在接收窗口之外则丢弃）
- 接收窗口尺寸 = 1，只能顺序接收
- 接收窗口尺寸 > 1，可以乱序接收（向上层提交时需要排序）
接收窗口的滑动和确认
另一种情况
正常情况下两个窗口互动
异常情况下GBN的两个窗口互动
异常情况下SR的两个窗口互动
GBN和SR协议的异同
总结
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QAxBuOvS-1643866898686)(https://img.samuel-luo.space/image-20220122194051939.png)]
GBN：
发送方的FSM
接收方的FSM
运行时
SR：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6fS41OS6-1643866898689)(https://img.samuel-luo.space/image-20220122200552718.png)]
运行时
对比GBN和SR
窗口最大尺寸
GBN：2 ^ n - 1
SR: 2 ^ (n - 1)
面向连接的传输：TCP
TCP：概述
- 点对点（一个发送方，一个接收方）
- 可靠的、按顺序的字节流（没有报文边界）
- 管道化（流水线）：TCP拥塞控制和流量控制设置窗口大小
- 发送和接受缓存
- 全双工数据（在同一连接中数据流双向流动；MSS：最大报文段大小）
- 面向连接（在数据交换之前，通过握手（交换控制报文）初始化发送方、接收方状态变量）
- 有流量控制（发送方不会淹没接收方）
TCP报文段结构
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-esCtH1q9-1643866898693)(https://img.samuel-luo.space/image-20220123175942365.png)]
TCP序号、确认号
TCP往返延时（RTT）和超时
怎样设置超时
怎样估计RTT
平均RTT
设置超时
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-o6Q0zuuY-1643866898697)(https://img.samuel-luo.space/image-20220124002209927.png)]
可靠数据传输
TCP在IP不可靠服务上建立了rdt
- 管道化的报文段（GBN or SR）
- 累积确认（像GBN）
- 单个重传定时器（像GBN）
- 是否可以接受乱序的，没有规范
通过下列时间触发重传
- 超时（只发送最早的未确认的段：SR）
- 重复的确认
首先考虑简化的TCP发送方
- 忽略重复的确认
- 忽略流量控制和拥塞控制
TCP发送方（简化版）
事件
代码
TCP重传
产生TCP ACK的建议
快速重传
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6wVGRQ1A-1643866898702)(https://img.samuel-luo.space/image-20220125160643877.png)]
算法
流量控制
连接管理
在正式交换数据之前，发送方和接收方握手建立通信关系：
- 同意建立连接
- 同意连接参数
同意建立连接
为什么不是两次握手
- 变化的延迟（连接请求的段没有丢但是可能超时）
- 由于丢失造成的重传
- 报文乱序
- 互相看不到对方
失败场景
三次握手
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hyZw2oq3-1643866898706)(https://img.samuel-luo.space/image-20220125163641317.png)]
解决的半连接和接受老数据问题
FSM
关闭连接
客户端和服务器分别关闭它自己这一侧的连接
- 发送FIN bit = 1的TCP段
一旦接收到FIN，用ACK回应
- 接到FIN段，ACK可以和它自己发出的FIN段一起发送
可以处理同时的FIN交换
拥塞控制原理
拥塞
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B1ezy0aU-1643866898708)(https://img.samuel-luo.space/image-20220125165424664.png)]
拥塞原因/代价
场景1
场景2
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T7Js5dsA-1643866898713)(https://img.samuel-luo.space/image-20220125170519290.png)]
场景3
方法
两种拥塞控制方法
端到端的拥塞控制
网络辅助的拥塞控制
ATM ABR拥塞控制
TCP拥塞控制
机制
端到端的拥塞控制机制
- 路由器不向主机发送有关拥塞的反馈信息（路由器负担较轻、符合网络核心简单的TCP/IP架构原则）
- 端系统根据自身得到的信息，判断是否发生拥塞，从而采取动作
拥塞控制的几个问题
如何检测拥塞
- 轻微拥塞
- 拥塞
控制策略
- 再拥塞发送时如何动作，降低速率（轻微拥塞如何降低；拥塞时如何降低）
- 再拥塞缓解时如何动作，增加速率
拥塞感知
某个段超时了（丢失事件）：拥塞
- 超时时间到，某个段的确认没有来
- 网络拥塞（某个路由器缓冲区没有空间了，被丢弃）大概率
- 出错被丢弃了（各级错误，没有通过校验，被丢弃）概率小
- 一旦超时，就认为拥塞了，有一定的误判，但总体控制方向是对的
某个段的三次重复ACK：轻微拥塞
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dZBNPrhN-1643866898717)(https://img.samuel-luo.space/image-20220125180657508.png)]
速率控制方法
拥塞控制和流量控制联合
策略
慢启动（SS）
AIMD：线性增、乘性减少
超时事件后的保守策略
TCP慢启动
TCP拥塞控制：AIMD
总结：TCP拥塞控制
TCP吞吐量
W：发生丢失事件时的窗口尺寸（单位：字节）
- 平均窗口尺寸：3/4W
- 平均吞吐量：RTT时间吞吐3/4W
TCP公平性
目标：k个TCP会话分享一个链路带宽为R的瓶颈，每个会话的有效带宽为R/k
总结
