传输层
任务:提供可靠高效的数据传输;提供不同主机应用进程间的逻辑通信;
运行在端系统(端到端)——路由器不含传输层
(端点point = IP + port)
发送方:
把messages分割为segments,递给网络层;
接收方:
把segments还原为messages,递给应用层;
💡 网络层与传输层对比:网络层只负责主机到主机的交付,传输层更进一步交付到进程;
网络层datagram包含两IP地址,传输层segment包含两端口号;
网络层与传输层服务的区别:
- 网络层通过IP协议作用域把数据从源机送到目的机;(主机到主机 host to host)
- 传输层通过TCP与UDP协议作用域把数据送到具体的应用进程;(进程到进程)
多路复用与多路分解
多路复用(发送方)
从多个sockets中整合数据,分别添加头部以便分解;
多路分解(接收方)
根据头部分发segments到正确的sockets;
(使用IP地址+端口号)
无连接的解复用:
UDP sockets由(目的IP地址,目的端口号)全面标识;
源不同,到达的套接字相同;
面向连接的解复用:
TCP sockets由(源IP地址,源端口号,目的IP地址,目的端口号)标识;
源不同,到达的套接字不同;
TCP:
- 可靠传输(握手过程)
- 流量控制
- 拥塞控制
- 面向连接
- 不提供:时延保证、最低吞吐量保证、安全性
UDP:
- 不可靠传输
- 不提供:流量控制、拥塞控制、时延保证、最低吞吐量保证、安全性
- 可以有更快的速度
选择 TCP or UDP ?
TCP
- 可靠传输方式
- 可让应用程序简单化,程序员可以不必进行错误检查、修正等工作
UDP
- 为了降低对计算机资源的需求(DNS)
- 应用程序本身已提供数据完整性的检查机制,毋须依赖传输层的协议来保证
- 应用程序传输的并非关键性的数据(路由器周期性的路由信息交换)
- 一对多方式,必须使用UDP(TCP限于一对一的传送)
用户数据报协议 UDP(无连接传输)
UDP:传输层上的一个轻量级协议,提供高效的端到端的数据段传输;
- 不可靠:segments可能丢失,可能乱序;
- 无连接:不“握手”;
优点:简单、快速
- 无连接——低时延、简单
- 头部小
- 无拥塞控制
报文段:
长度:首部+数据的字节数
检验和:检查差错
(头部8字节)
UDP检验和(checksum):
发送方:UDP对报文段中所有16bit字的和(溢出回卷)求反码,结果放在检验和字段;
接收方:将全部的16bit字(包括检验和)加和,结果为全1,则无差错;
校验和:
IP伪头部+UPD头部+数据,16位一行,按列相加求和,得出结果取反码,得到校验和;
❗当求和溢出时,需要进行回卷——将溢出位的“1”放到最低位与其相加;
校验方法:接收方重新求和,再与发送的校验和相加,若结果全位为1,则无bit error。
传输控制协议 TCP(面向连接传输)
通信5元组:源端点+TCP+目的端点
特点:
-
点对点(无法“多播”);
-
全双工;
-
拥塞控制、流量控制;
-
采用累积确认
-
可靠,有序;
-
面向连接:握手(交换控制msgs),在数据交换前初始化发送者、接收者状态;
-
全双工数据(full duplex data):双向数据流在同一连接中;
MSS: 最大报文段长度;
TCP数据段(TPDU)格式:
(固定头部20字节)
| Sequence number(序号) | 32bit | 用于实现可靠数据传输 | data首字节序号; ◦ 第一段序号(初始序号)为随机数 ◦ 后续段序号为【之前段序号】+【之前段携带字节数】 | 每个数据字节都有独有的32位序列号 | | --- | --- | --- | --- | --- | | Ack number(确认号) | 32bit | 用于实现可靠数据传输 | • 接受最后一个字节的序号+1; | 正在等待的下一段的序号 | | Window size | 16bit | 用于流量控制 | 指示接收方愿意接受的字节数 | - | | header length | 4bit | - | 以32bit(4字节)为单位的TCP首部长度; | 即行数 |
- URG:紧急数据
- ACK:确认号有效
- PSH:立即推送数据
- R|S|F:用于建立/释放连接
- Data:最大长度为MSS的应用数据
对比:UDP数据段头
-
确认号与序号的示例
超时与重传:
-
估计往返时间:仅在某个时刻做一次样本RTT测量(忽略重传);对样本RTT取平均;
EstimatedRTT = (1- a)EstimatedRTT + aSampleRTT
推荐值:a=0.25
-
超时时间:大于RTT
Timeoutlnterval = EstimatedRTT + 4 ·DevRTT
- 太大:不能即使重传,时延大;
- 太短:造成不必要的重传;
TCP定时器:
- 肯定确认定时器,用来保证数据段的可靠传输
- 持续定时器用来解除因更新窗口丢失引发的死锁
TCP可靠数据传输
PPT3-63/课本P159
TCP 的可靠数据传输服务确保一个进程从其接收缓存中读出的数据流是无损坏、无间隙、非冗余和按序的数据流;即该字节流与连接的另一方端系统发送出的字节流是完全相同。
TCP使用累计确认;
触发重传的两种情况:
- 超时
- 冗余ACK
接收方ACK丢失——重传
接收方ACK返回超时——重传(但100不需重传,因为在第二个时限内累计确认了100和120)
接收方前面的ACK丢失,但后面的ACK在时限内被接收——从收到的最后的ACK继续(累计确认)
| 接收端事件 | TCP接收方动作 |
|---|---|
| 具有所期望序号的按序报文段到达。所有在期望序号及以前的数据都已经被确认 | 延迟的ACK。对另一个按序报文段的到达最多等待500ms。如果下一个按序报文段在这个时间间隔内没有到达,则发送一个ACK |
| 具有所期望序号的按序报文段到达。另一个按序报文段等待ACK传输 | 立即发送单个累积ACK,以确认两个按序报文段 |
| 比期望序号大的失序报文段到达。检测出间隔 | 立即发送冗余ACK,指示下一个期待字节的序号(其为间隔的低端的序号) |
| 能部分或完全填充接收数据间隔的报文段到达 | 倘若该报文段起始于间隔的低端,则立即发送ACK |
TCP快速重传:
- 超时时间通常比较长: •重发丢失包之前的长延迟
- 通过重复的ack检测丢失的段: •发送者经常连续发送许多片段 •如果段丢失,可能会有许多重复的ack。
如果发送方收到3个相同数据的ack(“三次重复的ack”),用最小的seq #重新发送未打包的段(无需等待至超时)
TCP流量控制
使发送方发送速率与接收方应用程序读取速率相匹配;
- 发送方维护”接收窗口“,表示接收方剩余可用缓存空间;
TCP拥塞控制
- 每个RTT内cwnd(拥塞窗口)线性增加1MSS;
- 每出现3个冗余ACK事件时减半;
TCP发送速率≈cwnd/RTT (bytes/sec)
慢启动:
拥塞检测(Congestion detection)
- 所有的互联网TCP算法都假定超时是由拥塞引起的,并且通过监视超时的情况来判断是否出现问题
拥塞控制(Congestion control)
- 当一个连接建立的时候,双方选择一个合适的窗口大小,接收方根据自己的缓冲区大小来指定窗口的大小
- 如果发送者遵守这个窗口大小的限制,则接收端不会出现缓冲区溢出的问题,但可能由于网络内部的拥塞而发生问题
每个发送者维护两个窗口:
- 接收窗口:反映了目前接收者的处理能力(容易获取)
- 拥塞窗口:大小反映了网络目前的容量(难于获取)
只要发送者发送的数据字节数是两个窗口中小的那个窗口数;
确定拥塞窗口大小:慢启动算法
- 当连接建立的时候,发送者用当前使用的最大数据段长度初始化拥塞窗口,然后发送一个最大的数据段
- 如果在定时器超期之前收到确认,则将拥塞窗口翻倍,然后发送两个数据段,直到超时(或达到接收方窗口的大小)
- 阈值前指数增长,阈值后线性增长直到超时(阈值为上一次拥塞窗口的一半);
- 若收到3个冗余ACK,cwnd减半,并加上3个MSS(即3个冗余ACK);
- 若超时,cwnd降至1MSS;
阈值:ssthresh
早期版本Tahoe,始终将拥塞窗口减至1MSS,进入慢启动阶段,无快速恢复; 较新版本Reno,有快速恢复;
小结:
-
TCP拥塞控制遵循分组守恒定律
-
两种因素引发拥塞
- 接收方处理不过来,用窗口尺寸来量度
- 通信子网中出现拥塞,用拥塞窗口来量度
-
处理拥塞的具体方法是使用窗口尺寸和拥塞窗口中小的那个来发送
-
CWND通过慢起动方法尝试而来(通过阈值调节CWND尝试的粒度)
-
TCP还需要效率
- 发方优化:Nagle 's algorithm
- 尽量不发送数据含量小的数据段
- 缓存应用层的数据,达到一定量再发送
- 收方优化:Clark 's solution
- 不请求对方发送短数据段(window size)
- 延迟窗口变更信息,使接收缓冲区足够大
- 发方优化:Nagle 's algorithm
TCP连接管理
- 一方(server)被动地等待一个进来的连接请求
- 另一方(client)通过发送连接请求,设置一些参数
- 服务器方回发确认应答
- 应答到达请求方,请求方最后确认,连接建立
通过三次握手建立TCP连接
- 一次:SYN=1,ACK=0,SYN包含随机初始序号x;
- 二次:SYN=1,ACK=1,SYN包含服务器初始序号y,确认号=x+1;
- 三次:SYN=0,ACK=1,确认号=y+1;
三次握手建立连接是一个同步的过程,交换初始序列号,保证后续的每一个字节的可靠传输
可靠数据传输(rdt)原理
PPT 3.4节暂时跳过
可靠数据传输(rdt)协议:(停等协议)
传输层【可靠数据传输】协议:(PPT3-24~3-40/课本P135)
-
rdt1.0:经完全可靠信道的可靠数据传输
-
rdt2.0:经具有比特差错信道的可靠数据传输
错误检测;
错误反馈:
- ACKs:告诉发送方pkt接收OK
- NAKs:告诉发送方pkt有错误(发送方重传)
缺陷:ACK、NAK也可能受损;
停等协议:每发一个分组需要等待响应再继续发下一个分组;(低效)
-
rdt2.1:
增加了“序列号”(避免重复递交)
sender:
receiver:
-
rdt2.2:
移除NAK,以两次ACK代替;
-
rdt3.0:经具有比特差错的丢包信道的可靠数据传输
信道有errors与loss(底层信道可能丢失包)
发送方在合理时间内等待ACK;(计时器)
sender:
示例:
超时时间的设定很关键!
流水线型(pipelined)协议:
一次连续发送多个分组;
- 滑动窗口:
发送窗口:已发送但未被确认的分组,在0~N之间变化(N为缓冲区大小)
-
Go-back-N (GBN)协议:(
累积确认)P145一次可以发送多个分组,但只能确定接受一个分组,即只能顺序接收;
异常情况:
- 乱序:接收方丢弃该分组;
- 丢失:
示例:(接受方窗口大小为1)
-
选择重传(Selective Repeat)协议:(
独立确认)P148接收窗口>1,如果收到乱序分组,不必抛弃,可以把它缓存起来。
示例:
三种滑动窗口协议的比较:
-
交替位:
0 <= 发送窗口大小 <= 1 接收窗口大小=1
-
Go-back-N :
0 <= 发送窗口大小<=MAX_SEQ 接收窗口大小=1
-
Selective Repeat:
0 = 发送窗口大小 <= (MAX_SEQ+1)/2 接收窗口大小= (MAX_SEQ+1)/2
| 发送窗口 | 接收窗口 | 协议 |
|---|---|---|
| =1 | =1 | rdt |
| >1 | =1 | GBN |
| >1 | >1 | SR |
注意:TCP接收方返回的ACK是下一个包的序号,而GBN与SR返回的ACK是当前确认包的序号;