计算机网络传输层

第三章 传输层

目标：
理解传输层服务以后的原则:
复用/分解复用
可靠数据传输
流量控制
拥塞控制
学习因特网的传输层协议:
UDP: 无连接传输
TCP: 面向连接传输
TCP 拥塞控制




3.1 传输层服务
传输层服务和协议：
在两个不同的主机上运行的应用程序之间提供 逻辑通信 
传输层协议运行在端系统 
发送方: 将应用程序报文分成数据段传递给网络层, 
接受方: 将数据段重新组装成报文传递到应用层
不只一个传输层协议可以用于应用程序
因特网: TCP 和 UDP


传输层和网络层：
网络层：两个主机之间的逻辑通信

传输层：两个进程之间的逻辑通信
可靠，增强的网络层服务

Internet 传输层协议：
可靠按序递交 (TCP)
拥塞控制 
流量控制
连接建立
不可靠的无序传递: UDP
“尽力传递” IP的直接扩展
不提供的服务: 
延迟保证
带宽保证



3.2 多路复用和多路分解
在接受主机多路分解：将接受到的数据段传递到正确的套接字（多路分解）
在发送方主机多路复用：从多个套接字收集数据，用首部封装数据，然后将报文段传递到网络层（多路复用）


多路分解工作步骤：
主机收到IP数据报（每个数据报有源IP地址，目的IP地址）
每个数据报搬运一个数据段
每个数据段有源和目的端口号  （对于特定应用程序有特定端口号）
主机用IP地址和端口号致命数据段属于哪个合适的套接字

无连接多路分解
1) 用端口号创建套接字
2) UDP套接字由两个因素指定（目的IP地址，目的端口号）
3) 当主机收到UDP数据段：
检查数据段中的目的端口号
用端口号指示UDP数据段属于哪个套接字
4) 具有不同的源IP地址且/或源端口号，但具有相同的目的IP地址和目的端口号的IP数据报指向同样的套接字

面向连接的多路分解
1) TCP套接字由4部分指定：
源IP地址
源端口号
目的IP地址
目的端口号
2) 接受主机使用所有四个值将数据段定位到合适的套接字
3) 服务器主机支持很多同时TCP套接字：
每个套接字用4部分来表示
4) Web服务器对每个连接的客户都有不同的套接字
非持久HTTP将对每个请求有一个不同的套接字


3.3无连接传输：UDP
使用UDP的原因：
1 不需要建立连接 (减少延迟)
2 简单: 在发送者接受者之间不需要连接状态
3 很小的数据段首部
4 没有拥塞控制: UDP 能够用尽可能快的速度传递
缺点：
丢失
会传递失序的报文到应用程序
特点：
无连接：
在UDP接收者发送者之间没有握手
每个UDP 数据段的处理独立于其他数据段


总结：
UDP 的首部开销小，只有 8 个字节。
UDP 是面向报文的。发送方 UDP 对应用程序交下来的报文，在添加首部后就向下交付 IP 层。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。
接收方 UDP 对 IP 层交上来的 UDP 用户数据报，在去除首部后就原封不动地交付上层的应用进程，一次交付一个完整的报文。
应用程序必须选择合适大小的报文。


UDP的首部格式：（半期不考）
详情在PPT 第三章21-25

UDP校验和：
目标: 对传输的数据进行差错检测
发送方:
将数据段看成16bit的整数序列
校验和: 数据段内容相加 (1的补码和)
发送者将校验和值放入UDP的校验和域

接收方：
计算接受到数据段的校验和
检查计算的校验和是否等于校验和域中的值
NO -检查到错误
YES -没有检查到错误

求检验和时需要注意的地方：
求和时产生的进位必须回卷加到结果上
最后的累加和必须按位变反才是校验和

3.4 可靠数据传输原理

逐步开发发送方和接收方的可靠数据传输协议(rdt)
仅考虑单向数据传输
但控制信息将双向流动
用有限状态机(FSM)来标示发送方和接收方

Rdt1.0：完全可靠信道上的可靠数据传输
在完美可靠的信道上：
没有bit错误
没有分组丢失
发送方，接收方分离的FSMs：
发送方发送数据到下层信道
接收方从下层信道接受数据

Rdt2.0：具有bit错误的信道
下层信道可能让传输分组中的bit受损
校验和将检测到bit错误

问题：如何从错误中恢复
确认(ACKs):接收方明确告诉发送方 分组接受正确
否认(NAKs):接收方明确告诉发送方 分组接受出错
发送方收到NAK后重发这个分组
在rdt2.0的新机制：
差错检测
接收方反馈：控制信息(ACK,NCK)rcvr->sender


停一等协议：
发送方发送一个报文，然后等待接收方的响应
rdt2.0的缺陷：
发送方不知道接收方发生了什么！不能正确重发：可能重发。
处理重复：
发送方给每个分组加一个序号
在ACK/NAK混淆时发送方重发当前分组
接收方丢弃重复的分组(并不向上传递)

rdt2.1:发送方处理混乱的ACK/NAKs
发送方：
序号加到分组上
两个序号（0，1)就可以满足
必须检查是否收到混淆的ACK/NAK
状态加倍：
状态必须记住当前的报文是1号还是0号
接收方：
必须检查是否收到重复的报文：
状态指示0或者1：是否希望的报文序号
注意：接收方并不知道它的上一个ACK/NAK是否被发送方正确接受

rdt2.2：一个不要NAK的协议
同rdt2.1一样的功能，如果上个报文接受正确接收方发送ACK
接收方必须明确包含被确认的报文的序号
发送方收到重复ACK将导致和NAK一样的处理：重发当前报文


rdt3.0: 具有出错和丢失的信道
新假设：下层信道还要丢失报文（数据或者ACKs）
检验和，序号，确认，重发将会有帮助，但是不够
方法：
发送者等待“合理的”确认时间
如果在这个时间内没有收到确认就重发
如果报文（或者确认）只是延迟（没有丢失）
重发将导致重复，但是使用序号已经处理了这个问题
接收方必须指定被确认的报文序号
要求倒计时定时器
只有在定时器超时时才出发重发

性能：
网络利用率很低，能工作但是性能很差


流水线：发送方允许发送多个"在路上的",还没有确认的报文
序号数目的范围必须增加
在发送方/接收方必须有缓冲区
流水线计数的两个通用形式:go-Back-N,选择重传

增加利用率

Go-Back-N
发送方：
在分组头中规定一个K位的序号
"窗口"，允许的连续未确认的报文
接收方：
ACK-only: 总是为正确接收的最高序号的分组发送ACK。
可能生成重复的ACKs
只需要记住被期待接收的序号expectedseqnum
接收到失序分组: 
丢弃(不缓冲) -> 没有接收缓冲区!
重发最高序号分组的ACK



选择性重传：
接收方分别确认已经收到的分组
必要时，缓冲报文，最后按序提交给上层
发送者只重发没有收到确认的分组
对每个没有确认的报文发送者都要启动一个定时器(每个未被确认的报文都有一个定时器)
发送窗口：
N个连续序号
限制被发送的未确认的分组数量

发送方：
从上层收到数据 :
如果下一个可用的序号在发送方窗口内，则将数据打包并发送,启动定时器
超时(n):
重发分组n, 重启定时器
收到ACK(n)在[sendbase,sendbase+N-1]内:
标记分组n被接收
如果n是最小的未确认分组，则增加窗口基序号到下一个未被确认的序号
接收方：
分组n的序号在[rcvbase,rcvbase+N-1]内，发送ACK(n)
失序分组：缓冲
有序分组：交付上层（包括已经缓冲的有序分组），提高窗口到下一个没有接受的分组not-yet-received pkt
分组n在[rcvbase-N,rcvnase-1]内发送ACK(n)
其他：忽略

*****注意：序号大小和窗口大小的关系：小于或等于序号空间大小的一半

3.5 面向连接传输：TCP

概述：
点到点：
一个发送者，一个接受者
可靠按序的字节流：
没有信息边界
流水线：
TCP拥塞和流量控制
设置窗口大小
收发缓冲区

全双工数据：
同一个连接上的双向数据流
MSS：最大报文段长
面向连接：
在数据交换前握手（交换控制信息）初始化发送方和接受方的状态
流量控制：
发送方不会淹没接受方


TCP往返时延的估计和超时：
样本RTT：测量从报文段发送到收到确认的时间
忽略重传
样本RTT会变化，因此需要一个样本RTT均值
对收到的样本RTT根据以下公式进行均值处理：
EstimatedRTT= (1-α)*EstimatedRTT + αSampleRTT
上述均值计算被称为：指数加权移动平均
典型的α=0.125

设置超时：
EstimatedRTT加上 “安全余量”

SampleRTT 偏离EstimatedRTT多少的估计

DevRTT =(1-β)*DevRTT + β *| SampleRTT -EstimatedRTT|
典型的，β =0.25
然后社会超时时间间隔：
TimeoutInterval =EstimatedRTT + 4 *DevRTT
注意：先计算DevRTT，再计算EstimatedRTT

初始时 TimeoutInterval 设置1秒
第一个样本RTT获得后，
EstimatedRTT =SampleRTT，
DevRTT=SampleRTT/2，
TimeoutInterval =EstimatedRTT+ max(G,K*DevRTT)(K=4,G是用户设置的时间粒度)
2 可靠数据传输
TCP在IP不可靠服务之上创建rdt服务
流水线技术处理报文段
累计确认
TCP使用单个重发定时器
触发重发：
超时时间
重复确认

TCP发送方时间：
从应用程序接受数据：
用序号创造一个数据段
序号是数据段中第一个数据字节在字节流中的位置编号
如果没有启动定时器，则启动定时器（定时器是最早没有被确认的数据段发送时启动的）
设置超时间隔:(TimeoutIntervalOut
Interval)
超时：
重发导致超时的数据段
重新开始定时器
收到确认：
如果确认了还没有确认的数据段
更新该没有确认的状态
还有未完成的数据段，重新开始定时器

快速重传：
超时触发重传存在问题：
超时周期往往太长：
重传丢失报文之前要等待很长时间，因此增加了网络的时延
发送方可以在超时之前通过重发的ACK检测丢失报文段
发送方常常一个接一个地发送很多报文段
如果报文段丢失，则发送方将可能接收到很多重复的ACKs
如果发送方收到3和对同样报文段的确认，则发送方认为该报文段之后的数据已经丢失
启动快速重传：在定时器超时之前重发丢失的报文段

TCP ACK的产生：
接收方事件：
1 期望序号的报文段按序到达们所有在期望序号以前的报文段都被确认
2 期望序号的报文段按序到达。另一个按序报文段等待发送ACK。
3 收到一个失序的报文段，高于期望的序号，检查到缝隙
4 到达的报文段部分地或者完全的填充接受数据间隔

接收方行为：
1 延迟ACK，等到500ms看是否有下一个报文段，如果没有，发送ACK
2 立即发送单个累积ACK，确认两个有序的报文段
3 立即发送重复ACK，指出期望的序号
4 立即发送ACK，证实缝隙低端的报文段已经收到

3、 流量控制
发送方不能发送的太多太快，让接受缓冲区溢出
速度匹配服务：
发送速率和接受应用程序的提取速率匹配

工作原理：（假设TCP接收方丢弃失序的报文段）
流量控制使用接受窗口：
接受缓冲区的剩余空间
接收方在报文段中宣告接受窗口的剩余空间
发送方限制没有确认的数据不超过接受窗口
保证接受缓冲区不溢出
4、连接管理
Step 1: 客户发送TCP SYN报文段到服务器
指定初始的序号
没有数据
Step 2: 服务器接收SYN, 回复 SYNACK 报文段
服务器分配缓冲区
指定服务器的初始序号
Step 3: 客户接收 SYNACK, 回复 ACK 报文段, 可能包含数据


关闭连接：
Step 1: 客户发送 TCP FIN 控制报文段到服务器 
Step 2: 服务器接收 FIN, 回复 ACK. 半关闭连接, 并发送FIN到客户
Step 3: 客户接收 FIN, 回复 ACK. 
进入 “timed wait”
等待结束时释放连接资源
Step 4: 服务器接收 ACK.  连接关闭. 


3.6拥塞控制原理：
拥塞：
从信息的角度看：太多源主机发送太多的数据，速度太快以至于网络来不及处理
和流量控制不同
表现：丢失分组（路由器的缓冲区溢出）
  长延迟（在路由器的缓冲区排队）

拥塞控制的两个主要方法：
端到端拥塞控制：
没有从网络中得到明确的反馈
从端系统观察到的丢失和延迟推断出拥塞
TCP采用的方法
网络辅助的拥塞控制：
路由器给端系统提供反馈
单bit指示拥塞（SNA, DECbit, TCP/IP ECN, ATM）
指明发送者应该发送的速率

3.7 TCP的拥塞控制
问题引述：
TCP拥塞控制使用的是端到端的方式，路由器不需要参与拥塞控制，减轻路由器的负担。为实现端到端的拥塞控制，端系统必须知道是否发生了拥塞，讨论两种拥塞判断的方法，介绍拥塞控制的三种机制。

拥塞控制：
端到端控制 (没有网络辅助)
发送方限制发送:
LastByteSent-LastByteAcked ≤ min( CongWin , RcvWindow )
大体上,
rate=CongWin/RTT/sec
CongWin是动态的。感知的网络拥塞的函数




发送方感知拥塞的方法：
丢失事件=超时或者3个重复的acks
TCP发送方在丢失事件发生后降低发送速率
三个机制：
慢启动、对超时事件作出反应、AIMD

TCP慢启动：
连接开始的时候, CongWin = 1 MSS
Example: MSS = 500 bytes & RTT = 200 msec
初始速率 = 20 kbps
有效带宽将 >> MSS/RTT
希望尽快达到期待的速率
然后将以2的指数方式增加速率
，直到产生丢失事件，或者达到某个阈值ssthresh
对拥塞事件的反应：
三个重复的确认后：
CongWin 减半+3 (Reno版) / 直接为1(Tahoe版)  （选用Reno版）
然后，窗口线性增长
超时事件后，TCP进入慢启动过程：
CongWin立即设置为1个MSS；
窗口开始指数增长
到一个阈值后再线性增长
3个重复的ACKs表明网络具有传输一些数据段的能力
在三个重复的确认之前”超时是更加严重的警告“

从指数增加变为线性增加：
当CongWin到超时前的一半
实现:
变化的阈值 
发送丢失事件后,阈值设置为丢失前的 CongWin 的一半，最小为2.

TCP AIMD：
乘性递减: 发生丢失事件后将拥塞窗口减半
加性递增: 每个RTT内如果没有丢失事件发生，拥塞窗口增加一个MSS : 检测


总结：
当 CongWin 低于阈值, 发送方处于慢启动阶段, 窗口指数增长.
当 CongWin 高于阈值, 发送方处于拥塞避免阶段, 窗口线性增长.
当三个重复的ACK 出现时,阈值置为CongWin/2 并且CongWin 置为阈值+3 or 1(根据不同TCP实现版本).
当超时发生时 ，阈值置为CongWin/2 并且CongWin 置为1 MSS. 


TCP 平均吞吐量
假设忽略慢启动
假设在丢失发生时，设W是窗口大小
如果窗口为 W, 吞吐量是 W/RTT
丢失发生后, 窗口降为 W/2, 吞吐量为 W/2RTT. 
平均吞吐量为0 .75 W/RTT




总结：
传输层提供的服务
进程通信
面向连接和无连接（是否建立连接）
可靠传输实现原理
UDP协议特性
校验和的实现思想
TCP协议特性及其实现
TCP报文，固定报头为20字节
连接管理
可靠传输
流量控制
拥塞控制