1、传输层
协议栈层次：application transport network link physical
理解传输层服务的基本理论和基本机制
多路复用/分用
可靠数据传输机制
流量控制机制
拥塞控制机制
掌握Internet的传输层协议
UDP：无连接传输服务
TCP：面向连接的传输服务
TCP拥塞控制
==================================================================
2、传输层概述
传输层协议是为运行在不同Host上的进程提供了一种逻辑通信机制。
逻辑通信机制：两个通信进程之间仿佛是直接连接的，不需要关心之间多远的物理距离，到底经过多少路由器，到底经过多少物理层。
端系统运行传输层协议：
发送方：将应用递交的消息分成一个或多个的Segment，并向下传给网络层。
接收方：将接受到的segment组装成消息，并向上交给应用层。
传输层可以为应用提供多种协议
Internet上的TCP
Internet上的UDP
网络层：提供主机之间的逻辑通信机制
传输层：提供应用进程之间的逻辑通信机制
位于网络层之上
依赖于网络层服务
对网络层服务进行（可能性）增强
可靠、按序的交付服务（TCP）
拥塞控制
流量控制
连接建立
不可靠的交付服务（UDP）
基于“尽力而为”的网络层，没有做（可靠性方面的）扩展
两种服务都不保证
延迟
带宽
==================================================================
3、多路复用/分用
如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用。
接收端进行多路分用：
传输层依据头部信息将收到的Segment交给正确的Socket即不同的进程。
发送端进行多路复用：
从多个Socket接收数据，为每块数据封装上头部信息，生产Segment，交给网络层。
分用如何工作？
主机接收到IP数据报（datagram）
每个数据报携带源IP地址、目的IP地址。
每个数据报携带一个传输层的段（Segment）。
每个段携带源端口号和目的端口号。
主机收到Segment后，传输层协议提取IP地址和端口号信息，将Segment导向相应的Socket。
TCP做更多处理
网络层不关心报文中的端口号信息
无连接分用：
利用端口号创建Socket
UDP的Socket用二元组标识
（目的IP地址，目的端口号）
主机收到UDP段后
检查段中的目的端口号
将UDP段导向绑定在该端口号的Socket
来自不同源IP地址和或源端口号的IP数据包被导向同一个Socket
面向连接的分用
TCP的Socket用四元组标识
源IP地址
源端口号
目的IP地址
目的端口号
接收端利用所有的四个值将Segment导向合适的Socket
服务器可能同时支持多个TCP Socket
每个Socket用自己的四元组标识
Web服务器为每个客户端开不同的Socket
==================================================================
4、UDP协议 User Datagram Protocol
基于Internet IP协议
复用/分用
简单的错误校验
“Best Effort” 服务，UDP段可能
丢失
非按序到达
无连接
UDP发送方和接收方之间不需要握手
每个UDP段的处理独立于其他段
UDP为什么存在？
无需建立连接（减少延迟）
实现简单：无需维护连接状态
头部开销少
没有拥塞控制：应用可更好地控制发送时间和速率
常用于流媒体应用
容忍丢失
速率敏感
UDP还用于
DNS
SNMP
在UDP上实现可靠数据传输？
在应用层增加可靠性机制
应用特定的错误恢复机制
UDP校验和（checksum）
目的：检查UDP段在传输中是否发生错误（如位翻转）
==================================================================
5 、可靠数据传输原理
什么是可靠？
不错、不丢、不乱
可靠数据传输协议
可靠数据传输对应用层、传输层、链路层都很重要
网络Top-10问题
信道的不可靠特性决定了可靠数据传输协议（rdt）的复杂性
可靠数据传输协议基本结构：接口
渐进地设计可靠数据传输协议的发送方和接收方
只考虑单向数据传输
但控制信息双向流动
利用状态机刻画传输协议
Rdt 1.0：可靠信道上的可靠数据传输
底层信道完全可靠
不会发生错误
不会丢弃分组
发送方和接收方的FSM独立
有限状态机 刻画网络协议
Rdt 2.0 产生位错误的信道
底层信道可能翻转分组中的位（bit）
利用校验和检测位错误
如何从错误中恢复？
确认机制：接收方显式地告知发送方分组已正确接收
NAK：接收方显式地告知发送方分组有错误
发送方收到NAK后，重传分组
基于这种重传机制的rdt协议称为ARQ（Automatic Repeat reQuest）协议
Rdt 2.0 中引入的新机制
差错检测
接收方反馈控制消息：ACK/NAK
重传
Rdt 2.1 和 2.2
如果ACK/NAK消息发生错误/被破坏会怎么样？
为ACK/NAK增加校验和，检错并纠错
添加额外的控制消息
如果ACK/NAK坏掉，发送方重传
不能简单的重传：产生重复分组
如何解决重复分组问题
序列号：发送方给每个分组增加序列号
接收方丢弃重复分组
Rdt 2.2 无NAK消息协议
Rdt 3.0
信道既可能发生错误，也可能丢失分组，怎么办？
校验和+序列号+ACK+重传 够用吗？
方法：发送方等待“合理”时间
如果没收到ACK，重传
如果分组或ACK只是延迟而不是丢了
重传会产生重复，序列号机制能够处理
接收方需在ACK中显式地告知所确认的分组
需要定时器
性能分析：
能够正确工作，但性能很差
网络协议限制了物理资源的利用
软硬件协同设计
停等操作是主要原因
==================================================================
6 、流水线机制与滑动窗口协议
流水线协议
允许发送方在收到ACK之前连续发送多个分组
更大的序列号范围
发送方和或接收方需要更大的存储空间以缓存分组
滑动窗口协议
窗口：允许使用的序列号范围，窗口尺寸为N，最多有N个等待确认的消息
滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动
滑动窗口协议：GBN SR
GO-Back-N协议
分组头部包含k-bit序列号
窗口尺寸为N，最多允许N个分组未确认
ACK（n）：确认到序列号n（包含n）的分组均已被正确接收，累计确认
可能收到重复ACK
为空中的分组设置计时器（timer）
超时Timer（n）事件：重传序列号大于等于n，还未收到ACK的所有分组（潜在的资源浪费）
接收方：乱序到达的分组直接丢弃，接收方只接受序列号最大的，按序到达的分组。
ACK机制，发送拥有最高序列号的，已被正确接收的分组的ACK。
可能产生重复ACK,只需要记住唯一的expectedseqnum。
Selective Repeat (SR)协议
GBN的缺陷：
会重传很多分组，导致网络中充斥着很多重传的分组。
接收方对每个分组单独进行确认
设置缓存机制，缓存乱序到达的分组
发送方只重传那些没收到ACK的分组
为每个分组设置定时器
发送方窗口
N个连续的序列号
限制已发送且未确认的分组
SR存在的问题：
序列号空间大小与窗口尺寸关系
分组分为：窗口发送方 窗口结构
已经确认的分组
已经发送了但未确认的分组
可用的序列号，可以用来发送的
不能使用的序列号，窗口还未滑动到
可靠数据传输原理与协议回顾
信道的（不可靠）特性
可靠数据传输的需求
Rdt 1.0
Rdt 2.0 rdt 2.1 rdt 2.2
Rdt 3.0
流水线与滑动窗口协议
GBN
SR
==================================================================
7、TCP概述
点对点：一个发送方，一个接收方
可靠的、按序的字节流
流水线机制
TCP拥塞控制和流量控制机制动态调整窗口尺寸。
设置窗口尺寸
发送方/接收方缓存
全双工
同一连接中能够传输双向数据流
面向连接
通信双方在发送数据之前必须建立连接
连接状态只在连接的两端中维护，在沿途节点中并不维护状态
TCP连接包括：两台主机上的缓存、连接状态变量、socket等
流量控制机制
7.1TCP段结构
序列号
序列号指的是segment中的第一个字节的编号
而不是segment的编号
建立TCP连接时，双方随机选择序列号
ACKs
希望接收到的下一个字节的序列号
累计确认：该序列号之前的所有字节均已被正确接收到
7.2TCP可靠数据传输
TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
流水线机制：
累积确认：像GBN
TCP使用单一重传定时器
触发重传的事件
超时
收到重复ACK
渐进式
暂不考虑重复ACK
暂不考虑流量控制
暂不考虑拥塞控制
TCP RTT和超时
如何设置定时器的超时时间？
大于RTT:但是RTT是变化的
过短：不必要的重传
过长：对段丢失时间反应慢
TCP发送方事件：
从应用层收到数据
创建Segment
序列号是Segment的第一个字节的编号
开启计时器
设置超时时间：TimeOutInterval
超时
重传引起超时的Segment
重启定时器
收到ACK
如果确认此前未确认的Segment
更新SendBase
如果窗口中还有未被确认的分组，重新启动定时器
TCP重传示例：
快速重传机制：
TCP的实现中，如果发生超时，超时时间间隔将重新设置，即将超时时间间隔加倍，导致其很大
通过重复ACK检测分组丢失
Sender会背靠背地发送多个分组
如果某个分组丢失，可能会引发多个重复的ACK
如果Sender收到对同一数据的3个ACK，则假定该数据之后的段已经丢失
快速重传：在定时器超时之前即进行重传。
为什么是3次？
3.7.3TCP流量控制
接收方为TCP连接分配buffer
上层应用可能处理buffer中数据的速度较慢
流量控制就是：发送方不会传输的太多、太快以至于淹没接收方（buffer溢出）
速度匹配机制
（假定TCP Receiver 丢弃乱序的 segments）
Buffer中的可用空间
Receiver通过在Segment的头部字段将RcvWindow告诉Sender
Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow尺寸
Receiver告知Sender Rcvwindow=0, 会出现什么情况？
7.4TCP连接管理
TCP sender和receiver 在传输数据前需要建立连接
初始化TCP变量
Seq.#
Buffer和流量控制信息
Client：连接发起者
Server：等待客户连接请求
3次握手：
Step 1: client host sends TCP SYN segment to server
Specifies initial seq.#
No data
Step 2: server host receives SYN, replies with SYNACK segment
Server allocates buffers 分配缓存
Specifies server initial seq.# 选择自己初始序列号，告知客户端
Step 3: client receivers SYNACK, replies with ACK segment, which may contain data
为什么要3次握手？
TCP是双向传递的，必须保证双方都能收发，且保证互相知道对方都能收发
7.5拥塞控制 更像是社会问题
太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理
表现：
分组丢失（路由器缓存溢出）
分组延迟过大（在路由器缓存中排队）排队延迟
拥塞控制 vs 流量控制
流量控制是发送方不要发送得太快，让接收方承受不了
拥塞控制室让网络承受不了
拥塞的另一个代价
当分组被drop时，任何用于该分组的“上游”传输能力全都被浪费掉。
如何进行拥塞控制：在传输层在做，为什么，要思考一下
控制网络负载：管制发送方的发送速率
端到端拥塞控制
网络层不需要显式的提供支持
端系统通过观察loss，delay等网络行为判断是否发生拥塞
TCP采用这种方法
网络辅助的拥塞控制
路由器向发送方显式地反馈网络拥塞信息
简单的拥塞指示
指示发送方应该采取何种速率
ABR：available bit rate
弹性服务
如果发送方路径
Underloaded
使用可用带宽
如果发送方路径拥塞
将发送速率降到最低保障速率
RM (resource management) cells
发送方发送
交换机设置 RM cell 位 （网络辅助）
NI bit : rate不许增长
CI bit : 拥塞指示
RM cell 由接收方返回给发送方
在RM cell中有显式的速率（ER）字段：两个字节
拥塞的交换机可以将ER置为更低的值
发送方获知路径所能支持的最小速率
数据cell中的EFCI位：拥塞的交换机将其设为1
如果RM cell前面的data cell的EFCI位被设为1，那么发送方在返回的RM cell中置CI位。
7.6 TCP拥塞控制机制
TCP拥塞控制面临3个问题：
如何控制发送速率？
Sender限制发送速率:
CongWin: 拥塞窗口 是一个变量 LastByteSent-LastByteAcked<=CongWin
Rate=CongWin/RTT
动态调整以改变发送速率
反映所感知到的网络拥塞
如何感知网络拥塞？
Loss事件=timeout或3个重复ACK
发生loss时间后，发送方降低速率
如何合理地调整发送速率？
加性增-乘性减：AMID
慢启动：SS
AMID
原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生loss
方法：AIMD
Additive Increase: 每个RTT将CongWin增大一个MSS，拥塞避免
Multiplicative Decrease: 发生loss后将CongWin 减半
TCP慢启动：SS
TCP连接建立时，CongWin=1
可用带宽可能远远高于初始速率
希望快速增长
原理：
当连接开始时，指数性增长
指数性增长：
每个RTT将CongWin翻倍
收到每个ACK进行操作
初始速率很慢，但是快速攀升
Threshold变量：
如何从指数性增长变成线性增长（拥塞避免）？
当CongWin达到Loss事件前值的1/2时
实现方法：
变量Threshold
Loss事件发生时，Threshold被设为Loss事件前CongWin值得1/2.
Loss事件的处理：
3个重复ACKs
CongWin切到一半
然后线性增长
Timeout事件
CongWin直接设为1个MSS（Maximum Segment Size）
然后指数增长
达到threshold后，再线性增长
3个重复ACKs表示网络还能够传输一些segment
Timeout事件表明拥塞更为严重
TCP拥塞控制算法
7.7 TCP性能
TCP throughput 吞吐率
给定拥塞窗口大小和RTT，TCP的平均吞吐率是多少？
忽略掉Slow start
假定发生超时时CongWin的大小为W，吞吐率W/RTT
超时后，CongWin=W/2，吞吐率是W/2RTT
平均吞吐率为：0.75W/RTT
吞吐率和丢包率的关系
高速网络下，需要重新设计TCP
TCP的公平性
如果K个TCP Session 共享相同的瓶颈带宽R，那么每个Session的平均速率为R/K。
多媒体应用通常不适用TCP，以免被拥塞控制机制限制速率，使用UDP：以恒定速率发送，能够容忍丢失
产生了不公平
公平性与并发TCP连接
某些应用会打开多个并发连接
Web浏览器
产生公平性问题
UDP的分组称为 用户数据报
TCP的分组称为报文段 segment
Packet 分组
一个数据包切割成很多段segment
确认机制 Acknowledgement ACK
ACK NAK
利用校验和检测底层信道可能产生的位错误
可靠数据传输 RDT：不错、不丢、不乱
可靠数据传输协议基本结构：接口
Rdt_send()
Udt_send()
Rdt_rcv()
Deliver_data()
状态机 (Finite State Machine FSM) 刻画传输协议
状态表明当前发送方的分组序列号
接收方的所处状态提供了期望收到的分组序列号
Rdt1.0:
Rdt2.0: 增加了ACK/NAK机制
Rdt2.1: 序列号（Sequence number）解决重复分组的问题
Rdt2.2 无NAK消息协议
（以上是信道可能发生错误的假设，ACK出错）
Rdt3.0：（丢失分组可能，或者分组或ACK只是延迟而不是丢了），发送方要设置等待合理时间，这个时间不好设置，需要定时器
流水线机制：停-等协议效率太低，允许发送方在收到ACK之前连续发送多个分组
滑动窗口协议：允许使用序列号的范围，窗口在序列号空间内向前滑动。