计算机网络笔记--4 传 输 层（下）

计算机网络笔记–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的速率——>应用互相不公平