三、传输层
3.1 传输层概述
传输层和网络层的区别：
Internet传输层协议：
3.2 多路复用和多路分用
分用如何工作？
无连接的UDP协议使用二元组 <目的ip，目的端口>标识socket
有连接的TCP协议如何分用？
3.3 UDP协议
UDP实现了传输层必须做的复用/分用，简单的错误检验机制
为什么需要在传输层做错误检测，明明在底层链路层做过错误检测了？
- 基于端到端的原则，底层的链路层可能没有错误检测，同时在路由器存储转发的过程中也可能出错，在最接近应用层做这样一个错误检测机制
常用于流媒体应用，DNS，SNMP
UDP上如何实现可靠数据传输：
- 在应用层增加可靠性机制
- 应用特定的错误恢复机制
UDP端结构：
UDP的校验和checksum
目的：检测UDP端在传输中是否发生错误
3.4 可靠数据传输原理
什么是可靠？
- 不错，不丢，不乱
注意上图中，传输层和网络层的ip协议之间是双向箭头，代表了数据的双向流动，而传输层和应用层是数据的单向流动
有限状态自动机：
Rdt1.0：可靠信道上的可靠数据传输
在一个理想可靠信道上进行传输
Rdt2.0：不可靠信道上的可靠数据传输，信道只有可能产生位错误
产生位错误的信道
作为接收方，先得知道位是否发生错误，然后进行错误恢复
Rdt2.0引入了新的控制消息:ACK/NAK
FSM规约(finite state machine)
Rdt2.1
上面的Rdt2.0有什么缺陷？
于是引入Rdt2.1，下面是Rdt2.1的发送方状态机：
接收方状态机:
上图中，当Wait for 0 from below的状态时，但是收到了1号的包，此时应该发ACK给发送方
Rdt2.1 和 Rdt2.0的区别：
引入Rdt2.2，我们不需要NAK消息来处理未接受到消息，而只使用ACK和序列号来确认接受到的最后一个包
Rdt2.2状态机：
Rdt3.0
信道可能丢失分组，可能传输错误，引入停等机制
发送方状态机：
Rdt3.0工作场景
发送方丢包：
接收方丢包：
timeout重传
Rdt3.0缺点：
性能差！停等协议影响了对数据链路的利用
引入流水线协议：
发送方不停的发分组，接收方不停的发ACK
滑动窗口协议：
GBN协议(go-back-n 回退N步协议)
GBN的发送方FSM：
GBN的接收方：
接收方没有缓存
GBN示例：
SR(Selective Repeat协议)
发送方和接收方都使用窗口：
SR协议的步骤：
SR的缺陷：
接收方无法区分这两个情况。需要对窗口和序列号大小做限制：
发送方+接收方窗长的和小于等于发送的序列号位数
3.5 TCP连接
概述：
一个基本的TCP段结构：
可以理解为图中ACK对应接收窗的序列号，REQ对应发送窗的序列号
TCP可靠数据传输：
关于RTT和超时的问题，如何设置超时时间？
TCP接收方使用累计机制，每次回复发送方的ACK都是对累计接收到的段进行确认
- 比如因为网络原因接收到了重复的过去发送的包，应该ACK(n)的n是到目前为止累计的字节数目
TCP流量控制机制：
即使当Reciiver告知发送方可用空间为0时，发送方也要发送一个很小的段去试探现在的可用空间，然后继续发送
TCP连接管理：
提问：为什么要用三次握手？
一种网络攻击手段：TCP建立连接时，服务器会分配资源给连接，并向客户端发ACK，然后等待客户端的ACK，在这期间，如果客户端没有ACK，则在一段时间后拆除连接，可以通过短时间大量发起TCP请求，然后不回复ACK，达成网络攻击。
TCP连接如何关闭
TCP连接和拆除状态转换：
TCP拥塞控制
拥塞成因和代价：
场景1：
场景2：
场景3：
拥塞控制方法：
TCP拥塞控制方法：
、
AIMD方法：
MSS是最大段长度
SS慢启动方法：
何时应该用线性增长去替换指数增长(拥塞避免)？
用一个变量threshold来进行切换，当小于threshold时指数增长，发生loss以后，减小threshold
对loss事件的处理，我们需要分别处理3个ACK和timeout事件：
总结：
TCP拥塞控制算法：
一道例题：
TCP性能分析：
TCP 吞吐率：
我们计算出能容忍的丢包率loss rate，发现这个值非常小，对网络设计要求太高了，甚至是无法实现的
需要设计新的TCP协议：
TCP的公平性：
TCP是公平的
