目录

1. 多路复用/分用
2. 可靠数据传输机制
3. 流量控制机制
4. 拥塞控制机制
5. udp ： 无连接传输服务
6. tcp : 面向连接传输服务
7. tcp 拥塞控制

传输层为运行在不同host上的进程提供了一种逻辑通信机制。
发送方将应用递交的消息分成一个或多个segment，并向下传递给网络层。
接收方将接收到的segment组装成消息，并向上交给应用层。

网络层： 提供主机之间的逻辑通信机制
传输层：提供应用进程之间的逻辑通信机制（依赖于网络层，对网络层进行可能的增强）

多路复用和多路分用

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

image.png

HOW？

image.png

无连接的多路分用

image.png

面向连接的多路分用

image.png

image.png

UDP协议

用户数据报协议
复用/分用
简单的错误校验
可能丢失，非按序到达。
无连接，不需要握手，每个UDP段的处理独立于其他段。

UDP的价值：
无需建立连接，延迟低
实现简单，无需维护连接状态
头部开销少
没有拥塞控制：应用可以更好地控制发送时间和速率。
常用于流媒体应用，容忍丢失，速率敏感
DNS,SNMP

image.png

CHECKSUM

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

image.png

可靠数据传输原理

什么是可靠？ 不错，不丢，不乱
依靠可靠数据传输协议，可靠数据传输对应用层，传输层，链路层都很重要。
信道的不可靠特性决定了可靠数据传输协议的复杂性。

image.png

渐进的设计可靠数据传输协议的发送方和接收方
只考虑单向数据传输，但控制信息双向流动
利用有限状态机刻画传输协议。

可靠数据传输协议（RDT） 1.0

下图都是一个状态，横线上面是接受到的EVENT，横线下面是对应的ACTION

image.png

RDT 2.0

信道可能产生位错误。

image.png

image.png

RDT 2.1

rdt 2.0 的缺陷是什么？
ACK/NAK 消息会发生错误怎么办？发送方无法识别这个消息，就没法继续下去。
增加序列号，接收方看到重复的序列号，丢到就好。

发送方的状态机：

image.png

接收方：

image.png

image.png

RDT 2.2

不再需要NAK消息，根据序号来确认最后一个正确的分组。

image.png

RDT 3.0

image.png

image.png

image.png

image.png

到目前为止3.0的版本，已经可以处理丢包，重传，错误等。但是性能不是很理想。
看个例子：1GBPS的链路，15MS 端到端传播延迟， 1KB 分组。
传输时间（T） = 8 Kbit/ 10^9 bit/sec = 8 micro sec
发送方利用率：
0.008/ 30.008 = 0.00027, 在1GBPS的链路上每30MS 才发送一个分组。网络协议限制了物理资源的利用率。
性能问题的瓶颈主要在停等协议引起的。

image.png

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

image.png

允许发送方在收到ACK之前连续发送多个分组。
所以我们需要更大的序列号范围。
发送方和接收方需要更大的存储空间以缓存分组。

image.png

滑动窗口协议

绿色是已经确认，黄色是已经发出但是还没确认，蓝色的代表还可以使用的序列号。白色的是还不能使用的序列号。

image.png

Go-Back-N协议

分组头包含K-BIT序列号，窗口尺寸为n，最多允许N个分组未确认。

image.png

ACK（n） ： 确认到序列号N（包含N）的分组都已被正确接收
为在传输的分组设置TIMER，当发生超时，重传序列号 》= N, 但还未收到ACK的所有分组。

image.png

image.png

Selective Repeat 协议

GBN 的缺点就是要重传很多分组，如果第一个没过去的话。
接收方对每个分组单独进行确认，设置缓存机制，缓存乱序到达的分组。
发送方值重传那些没收到ACK的分组，所以要为每个分组设置定时器。

多了一个接收方的窗口

image.png

image.png

但是SR协议有个困境，就是下面2种情况，对接收端来说是无法区分的。

image.png

要解决这个问题需要满足 NS + NR <= 2^K
K 是序列号的位数。NS 发送方窗口的尺寸，NR 接收方窗口的尺寸。

TCP协议

image.png

TCP可靠数据传输

image.png

image.png

为了让定时器的时限 需要比RTT大，所以要加一个安全边界。

image.png

TCP 重传示例

image.png

image.png

快速重传机制

image.png

TCP流量控制

image.png

需要一个额外的处理，即使是RCV WINDOW = 0， TCP仍然可以发一个很小的段，再收回来新的RCV WINDOW的信息 来避免上面的死锁的情况的发生。

TCP 连接管理

image.png

image.png

image.png

image.png

拥塞控制

拥塞，太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理。
表现，分组丢失（路由器缓存溢出），分组延迟过大（都在路由器缓存中排队）
流量控制是保证接收方能够处理。拥塞控制是保证网络能够处理。

image.png

上图就是网络瘫痪的原因。
那么怎么来进行拥塞控制呢？
有2种拥塞控制的方法。端到端的拥塞控制，还有一种是网络辅助的拥塞控制。

image.png

网络辅助的拥塞控制（ABR）

image.png

TCP的拥塞控制：

窗口大小会随着感知到的网络拥塞而动态调整。那么发送速率就会响应的改变。
感知拥塞的方法是通过LOSS事件。
LOSS事件分为2类，一个是收到3个重复的ACK，一个是TIMEOUT。
调整发送速率的方法是，线性增加，指数减少。 还有就是慢启动。

image.png

慢启动的思想是，因为一开始窗口大小是1，如果线性增加，可能到达有效带宽会花很多时间（可用带宽可能远远高于初始速率），所以在连接开始时，也是指数型增长。

image.png

那么何时做这个切换呢，也就是说从指数增长改回线性增长。 就是当窗口第一次指数减少的时候。

image.png

LOSS事件的处理

image.png