计算机网络笔记–4 传 输 层(下)
前言
这是学习计算机网络课程时记录的笔记,里面大部分内容来源于哈尔滨工业大学李全龙老师的《计算机网络》mooc,加上我个人的理解整理出的内容。
3.6 TCP协议
点对点:一个发送方,一个接收方
提供可靠的、按序的字节流
流水线机制:TCP拥塞控制和流量控制,设置窗口尺寸
发送方/接收方缓存
全双工:同一连接中能够双向传输
面向连接:通信双方在发送数据之前必须建立连接
连接状态只在连接的两端中维护,在沿途节点中并不维护状态
TCP连接包括:两台主机上的缓存、连接状态变量、socket等
流量控制机制
TCP段结构:(具体中文内容还是要听MOOC)
序列号:是segment中第一个字节的编号
不是segment本身的编号(思考为什么这么做)
建立TCP连接时,双方随机选择序列号
ACKs:希望接收到的下一个序列号
累计确认:该序列号之前的字节均已被正确接收到
接收方如何处理乱序到达的segment
——>TCP规范中没有规定,由TCP实现者规定
TCP可靠数据传输如何实现
1.TCP在IP层提供的不可靠服务基础上实现可靠数据传输服务
2.流水线机制
3.累计确认
4.TCP使用单一重传计时器
5.触发重传的事件:超时,收到重复ACK
6.渐进式:目前这一讲不考虑重复ACK,流量控制,拥塞控制
TCP RTT和 超时
如何设置定时器的超时时间?
1.大于RTT:但是RTT是变化的
2.不应过短:会导致不必要的重传
3.不应过长:对段丢失反应慢
RTT是重要的参考值,所以如何估算RTT
SampleRTT:测量从段发出去到接受到段的时间(忽略重传)
SampleRTT是变化的:测量多个SampleRTT,取平均值,形成估计值EstimatedRTT
定时间超时时间的设置
Estimated RTT+“安全边界”
Estimated 变化大小——>边界大小
测量Estimated的变化值:SampleRTT与EstimatedRTT的差值,得到DevRTT定时器超时时间的设置
TCP发送方事件
1.从应用层收到数据:
收到Segment
序列号是Segment第一个字节的编号
开始计时器
设置超时时间:TimeOutInterval
2.超时:
重传引起超时的Segment
重启定时器
3.收到ACK:如果收到此前未确认的Segment——>更新SendBase,如果窗口中还有未被确认的分组,重新启动定时器
上图的解释:
1.收到有序分组——>延迟ACK的发送,等待500ms是否有分组继续到达
2.有序分组到达,且前面有一个在等它——>发送累计确认ACK,确认多个段
3.乱序段到达——>发送重复ACK,寻求希望发送的段的序列号
快速重传机制:
TCP的实现中,如果发生超时,计时器的超时时间间隔将重新设置,即将超时时间间隔加倍,时间间隔会变得很大——>重发丢失分组之前要等很久
所以通过重复ACK检测分组丢失:sender会“背靠背”的发送多个分组,如果某个分组丢失,可能会引发多个重复的ACK
所以有这样的假设:如果sender收到对同一个数据的三个ACK,则假定该数据之后的段已经丢失——>快速重传:在定时器超时之前即进行重传
问题:为什么是三个
——>两个ACK可能是前后两个数据乱序,不一定是丢失,三个ACK代表起码多收了两个非WaitSeq的包,所以原因是丢失数据的可能更大,当然更多相同的ACK更能代表丢失,但是为了不影响数据传输和重发效率,以及考虑到实际的丢失概率,三个相同的ACK就被定义为数据丢失。
快速重传算法:
TCP流量控制:
接收方为TCP连接分配buffer
上层应用可能处理buffer中的数据速度较慢
所以要有流量控制:发送方不会传输太多太快,以至于淹没接收方——>速度匹配机制
假定TCP receiver丢弃乱序的segments
Receiver通过在Segment的头部字段将RevWindow告诉Sender
Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RevWindow 尺寸
Receiver告诉Sender RecWindow=0时:允许发送方发送一个很小的段,避免发生死锁的情况
TCP连接管理
1.TCP双方传输前要建立连接
2.初始化TCP变量:确定Seq(序列号),Buffer和流量控制信息
3.Client:连接发起者
4.Server:等待客户连接请求
握手的三个步骤:
1.client发出TCP SYN报文段给server:SYN标志位置1(表示建立连接),选择初始序列号(有大量的方式),不携带任何数据
2.server接收到SYN,如果同意建立连接会回复SYNACK报文段:为这个连接分配缓存,选择初始序列号并告知客户端,
3.client收到SYNACK,答复一个ACK报文段,SYN的标志位不再置1,这个报文段可以包含data
建立连接的过程(对应三个过程):
假如第三次握手没达成,资源会保留一段时间之后才释放
关闭连接的过程:
clientSocket.close()
1.client向server发送FIN报文段控制segment
2.server收到FIN,回复ACK,关闭连接发送FIN
3.client收到FIN,回复ACK
进入等待—如果收到FIN,会重新发送ACK
(为了确保服务器那端正确释放资源)
4.server收到ACK,连接关闭
3.7拥塞控制原理
拥塞
非正式定义:太多发送主机发送太多数据或者发送速率太快,以至于网络无法处理
表现:分组丢失(路由器缓存溢出)
分组延迟过大(在路由器缓存中排队)
拥塞控制 和 流量控制不一样:一个是对于网络,一个是对于接收方
A top-10 problem
场景1:
两个sender两个receiver
一个路由器没有缓存
也就是没有丢包
没有重传
场景2:
一个路由器,有限缓存
Sender 重传丢失分组
三种情况:
情况a:
Sender能通过某种机制获知路由器buffer信息,有空闲才发λin=λout(goodput)
情况b:
丢失后才重发
λ’in>λout
情况c:
分组丢失和计时器超时都重发,λ’in变得更大场景3:
四个发送方
多跳
重传
随着λin和λ’in不断增加
会产生拥塞的另一个代价:
当某一分组被丢掉的时候,任何用于该分组的“上游”传输能力全都被浪费掉(之前的路由都是无用功)
端到端拥塞控制:
网络层不需要显式的提供支持
端系统通过观察loss,delay等网络行为判断是否发生拥塞
TCP采用这种方法
网络辅助的拥塞控制:
路由器向发送方显式地反馈网络拥塞信息
简单的拥塞指示(1bit):SNA,ATM
指示发送方应该采取什么速率
案例:ATM ABR拥塞控制
ABR:(available bit rate)
“弹性服务”
如果发送方路径“underloaded”(使用率低)——>使用可用带宽
如果发送方路径拥塞——>将发送速率降到最低保障速率
RM(Resourse management)cells
发送方发送
交换机设置RM cell位(网络辅助)
NI bit:速率不许增长
CI bit:拥塞指示(已经拥塞)
两个值由路径上的路由器不断改变
RM cell由接收方返回给发送方
在RM cell中有显式的速率(ER)字段:两个字节
拥塞的交换机可以把ER设为更低的值
发送方获知路径所能支持的最小速率
数据cell中的EFCI位:拥塞交换机将其设为1
如果RMcell前面的data cell的EFCI位被设为1,那么发送方在返回的RM cell中置CI位
TCP拥塞控制:
基本原理
1.Sender如何限制发送速率
CongWin动态调整以改变发送速率
反应所感知到的网络拥塞
2.如何感知发送速率?
Loss事件=timeout或三个重复的ACK
发生loss事件后,发送方降低速率
3.如何合理的调整发送速率?
加性增——乘性减:AIMD(Additive Increase Multiplicative Decrease)
慢启动:SS(slow start)
加性增——乘性减:AIMD
原理:逐渐增加发送速率,谨慎探测可用带宽,直到发生loss
方法:AIMD
Additive Increase:每个RTT将CongWin增大一个MSS——>拥塞避免(避免增加太大,也避免时加时减的震荡)
Multiplicative Decrease:发生loss后将CongWin减半
锯齿行为:探测可用带宽
TCP慢启动:SS
TCP建立连接时CongWin=1
例:MSS=500byte RTT=200msec——>初始速率=20kbps
可用带宽可能远远高于初始速率,希望快速增长
所以当连接开始时,我们选择了指数型增长
指数型增长
每个RTT将CongWin翻倍
收到每个ACK进行操作
初始速率很慢但是快速攀升
何时应该指数型增长切换到线性增长?
答:当Congwin达到Loss事件前值的1/2时
实现方法:Threshold变量
Loss事件发生时,Threshold被设为Loss事件前Congwin值的1/2
Loss事件的处理:
3个重复的ACKs:CongWin切到一半,然后线性增长
Timeout事件:CongWin直接设为一个MSS,然后指数增长,达到threshold后再线性增长
为什么要做不同的处理?——>3个重复的ACK表示网络还能够传输一些Segments,而timeoout表明拥塞更为严重
总结:
1.拥塞窗口在Threshold以下:处于慢启动状态,指数型增长
2.达到Threshold:线性增长
3.3个重复的ACKs:CongWin切到一半,然后线性增长
4.Timeout事件:CongWin直接设为一个MSS,然后指数增长,达到threshold后再线性增长
TCP拥塞控制算法
TCP性能分析
给定拥塞窗口大小和RTT,TCP的平均吞吐量是多少(忽略慢启动过程)
假定发生超时时的Congwin大小为W,吞吐率为W/RTT
超时后Congwin为W/2,吞吐率为W/2RTT
平均吞吐率为0.75W/RTT
TCP的公平性:
如果K个TCP连接共享相同的瓶颈带宽R,那么每个Session的平均速率为R/K
TCP是具有公平性的:
TCP与UDP共存时
因为TCP有拥塞控制会降速,而UDP不会考虑速度,所以多媒体应用一般不用TCP去避免受拥塞控制影响
使用UDP:以恒定速率发送,能够容忍丢失
产生了不公平
并发TCP连接中
某些应用会打开多个并发连接:WEB浏览器——>会产生公平性问题
比如:链路速率是R,之前有9个连接已经存在
新来一个应用请求一个TCP,获得R/10的速率
又新来一个应用请求11个TCP,获得了R/2的速率——>应用互相不公平