整理了期末复习资料
This commit is contained in:
147
Review/第3章.md
Normal file
147
Review/第3章.md
Normal file
@@ -0,0 +1,147 @@
|
||||
# 1. 运输层服务
|
||||
|
||||
|
||||
|
||||
# 2. 多路复用与多路分解
|
||||
|
||||
一个端口号可以支持多个TCP连接（分配不同的套接字）或接收多个UDP包
|
||||
|
||||
# 3. 无连接运输：UDP
|
||||
|
||||
- 检验和
|
||||
1. 求和（101 + 110 = 1011）
|
||||
2. 如果溢出，回卷，即把溢出位加到最低位（1 + 011 = 100）
|
||||
3. 取反（011）
|
||||
|
||||
# 4. 可靠数据传输原理
|
||||
|
||||
- 可靠数据传输协议
|
||||
|
||||
- rdt 1.0：没有误差和丢失
|
||||
|
||||
<img src="images\rdt1.0FSM.png" alt="rdt1.0FSM" style="zoom: 25%;" />
|
||||
|
||||
- rdt 2.0：有误差，无丢失
|
||||
|
||||
- 使用ACK/NAK，此ACK/NAK不会有差错
|
||||
|
||||
<img src="images\rdt2.0FSM.png" alt="rdt2.0FSM" style="zoom:25%;" />
|
||||
|
||||
- rdt 2.1：数据包和ACK都会出现误差，但不会丢失
|
||||
|
||||
- ACK/NAK和数据包都加上序号，用两个序号0和1轮流即可
|
||||
|
||||
<img src="images\rdt2.1FSM Sender.png" alt="rdt2.1FSM Sender" style="zoom:25%;" />
|
||||
|
||||
<img src="images\rdt2.1FSM Receiver.png" alt="rdt2.1FSM Receiver" style="zoom:25%;" />
|
||||
|
||||
- rdt 2.2：
|
||||
|
||||
- 只使用ACK，ACK序号告知最后一个正确的包（重复收到ACK则说明上一个包损坏，要重传）
|
||||
|
||||
<img src="images\rdt2.2FSM Sender.png" alt="rdt2.2FSM Sender" style="zoom:25%;" />
|
||||
|
||||
<img src="images\rdt2.2FSM Receiver.png" alt="rdt2.2FSM Receiver" style="zoom:25%;" />
|
||||
|
||||
- rdt 3.0：数据包和ACK都会出现误差或丢失
|
||||
|
||||
- 加定时器
|
||||
- 利用率：$U_{sender} = \frac{L/R}{RTT+L/R}$，$RTT$占比过高
|
||||
|
||||
<img src="images\rdt3.0FSM Sender.png" alt="rdt3.0FSM Sender" style="zoom:25%;" />
|
||||
|
||||
- 流水线可靠数据传输协议
|
||||
|
||||
- N个流水线并行，利用率：$U_{sender} = \frac{N\times L/R}{RTT+N\times L/R}$
|
||||
- GBN（回退N步）和SR（选择重传）
|
||||
|
||||
- 回退N步
|
||||
|
||||
- 序号为i的ACK表示i及之前的分组都收到了。窗口N要小于序列长度L（N<=L-1）
|
||||
- sender：
|
||||
- 定时器记录窗口中最早的已发送但未确认的包，一旦确认（收到序号为i的ACK）窗口就要向后滑动（到i+1处）并重置定时器
|
||||
- 定时器超时，就要重发窗口内所有的包，并重置定时器
|
||||
- receiver：
|
||||
- 只需要维护期望收到的包序号i：无论收到什么序号的包，都只发序号为i-1的ACK。收到正确序号就i+=1
|
||||
|
||||
<img src="images\GBN Sender.png" alt="GBN Sender" style="zoom:25%;" />
|
||||
|
||||
<img src="images\GBN Receiver.png" alt="GBN Receiver" style="zoom:25%;" />
|
||||
|
||||
<img src="images\GBN例子.png" alt="GBN例子" style="zoom:25%;" />
|
||||
|
||||
- 选择重传
|
||||
|
||||
- 窗口N要小于等于序列长度L的一半（N<=L/2）
|
||||
- sender：
|
||||
- 发送窗口内的所有包，并对所有包记录定时器。接收到第i个包及其前面的所有包的ACK时，将窗口移动到i+1位置
|
||||
- 如果窗口内某一包没收到ACK，定时器超时，则只重发该包
|
||||
- receiver：
|
||||
- 对每一接收到的包发送ACK并缓存，当第i个包及其前面的包都收到时，有序地交付第i个包及其前面还未交付的包
|
||||
|
||||
<img src="images\SR例子.png" alt="SR例子" style="zoom:25%;" />
|
||||
|
||||
# 5. 面向连接的运输：TCP
|
||||
|
||||
- TCP报文结构
|
||||
|
||||
以太网的标准：MTU最大传输单元（1500B） = TCP包头（20B）+ IP包头（20B） + 最大报文段长度MSS （1460B）
|
||||
|
||||
- 序号：报文段首字节的字节流编号（注意是字节编号，一个报文中含有多个字节）（初始字节流编号随机初始化）
|
||||
- ACK：期望从对方收到的下一个字节的序号（累积确认，即：回复ACK表示前面的包都收到了）
|
||||
- TCP没有规定如何处理无序报文段，实现者可以选择缓存或丢弃（一般选择缓存）
|
||||
|
||||
<img src="images\TCP报文结构.png" alt="TCP报文结构" style="zoom: 33%;" />
|
||||
|
||||
<img src="images\TCP传输过程.png" alt="TCP传输过程" style="zoom: 50%;" />
|
||||
|
||||
- TCP连接：三次握手
|
||||
|
||||
1. 第1次握手：建立连接时，客户端发送SYN包（其中定义了随机起始序列号seg=j）到服务器，并进入SYN SENT状态，等待服务确认；
|
||||
2. 第二次握手：服务器收到syn包，必须确认客户端的SYN（ack=j+1），同时自己也发送一个SYN包（定义服务端的随机起始序列号seg=k），即
|
||||
SYN+ACK包，此时服务器进入SYN RECV状态；
|
||||
3. 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED (TCP连接成功)状态，完成三次握手
|
||||
|
||||
- TCP断开连接：四次挥手
|
||||
|
||||
1. 第1次挥手：客户端发送一个FIN包（FIN标志位设为1，序列号为当前序列号j）给服务器，并将状态变为FIN_WAIT_1，表明它已发送连接终止请求。
|
||||
2. 第2次挥手：服务端收到FIN包，回复ACK（确认号为j+1），服务器此时进入CLOSE_WAIT状态。客户端收到该ACK后进入FIN_WAIT_2状态，等待服务器端的FIN包。
|
||||
3. 第3次挥手：服务器发送FIN包（FIN标志位设为1，序列号为当前序列号k）给客户端，状态变为LAST_ACK。
|
||||
4. 第4次挥手：客户端收到FIN包，回复ACK（确认号为k+1），并进入TIME_WAIT状态持续2个TTL（考虑到服务器可能没收到ACK，再次发FIN）。服务器收到ACK后，正式关闭连接。
|
||||
|
||||
- 往返时延和超时重传
|
||||
|
||||
- 估算RTT：指数加权移动平均（过去样本的影响以指数级速度递减）：$EstimatedRTT = (1-\alpha)\times EstimatedRTT + \alpha \times SampleRTT$，其中$\alpha=0.125$为典型值
|
||||
- 估算SampleRTT与EstimatedRTT之间的差值有多大：$DevRTT = (1-\beta)\times DevRTT + \beta \times |SampleRTT-EstimatedRTT|$，通常$\beta=0.25$
|
||||
- 超时阈值计算：$TimeoutInterval = EstimatedRTT + 4\times DevRTT$
|
||||
|
||||
- TCP可靠数据传输
|
||||
|
||||
- 流水线发送报文段；累积确认；单个重传计时器（在最早的未确认报文段处计时）
|
||||
- 重传触发条件：超时；快速重传：对于相同数据，发送方收到3个ACK，则立即重传未确认的最小序号的报文段
|
||||
|
||||
- TCP流量控制：防止接收方的缓存溢出
|
||||
|
||||
- 接收方把rwnd放在报文首部，发送方限制未确认的报文段数量不超过该rwnd
|
||||
|
||||
# 6. 拥塞控制原理
|
||||
|
||||
- 原因：路由器缓冲区是有限的。导致：发送方超时重传，拥塞加重（且重传的包实际上有可能还在缓存里，是不必要的重传）
|
||||
- 解决方法：TCP拥塞控制（控制TTL）；网络辅助拥塞控制（直接向目的主机发送拥塞情况）
|
||||
|
||||
# 7. TCP拥塞控制
|
||||
|
||||
- 加性增 乘性减 AIMD：如果没丢包，每个RTT，拥塞窗口+=MSS（最大报文段长度）；如果丢包了，拥塞窗口*=0.5
|
||||
|
||||
- 慢启动：设置sstresh
|
||||
|
||||
1. 初始cwnd =1 MSS；每经过一个传输回合，cwnd*=2（指数增加）；cwnd到达sstresh后，每经过一个传输回合cwnd+=1初始MSS（线性增加）
|
||||
2. 超时或3个冗余ACK：
|
||||
- Tahoe：$ssthresh=0.5 \times cwnd$，$cwnd=1\times MSS$，并重新开始慢启动过程
|
||||
- Reno快速恢复算法：收到3个冗余ACK后，$ssthresh=0.5\times cwnd$，$cwnd=ssthresh+3\times MSS=0.5\times cwnd+3\times MSS$
|
||||
|
||||
<img src="images\Tahoe和Reno.png" alt="Tahoe和Reno" style="zoom:50%;" />
|
||||
|
||||
- 吞吐量：$=cwnd/RTT$，假设丢包时窗长为W，则平均窗长为3/4W，则吞吐量为$\frac{3}{4}\frac{W}{RTT}$
|
||||
|
||||
- 网络层协助的拥塞控制：在IP数据报设置CE位通知目的主机，目的主机回复ACK时会在TCP数据报设置ECE位告知发送方
|
||||
Reference in New Issue
Block a user