第三章
第三章 传输层
3.1 概述和传输层服务
传输服务和协议
- 为运行在不同主机上的应用进程提供逻辑通信
- 传输协议运行在端系统
- 发送方:将应用层的报文分成报文段,然后传递给网络层
- 接受方:将报文段重组成报文,然后传递给应用层
- 有多个传输层协议可供应用选择
- Internet:TCP和UDP
传输层 VS 网络层
- 网络层服务:主机之间的逻辑通信
- 传输层服务:进程间的逻辑通信
- 依赖于网络层的服务—延时,带宽(这些服务无法优化)
- 并对网络层的服务进行增强—数据丢失,顺序混乱,加密
Internet传输层协议
- 可靠的,保序的传输:TCP
- 多路复用,解复用
- 拥塞控制
- 流量控制
- 建立连接
- 不可靠,不保序的传输:UDP
- 多路复用,解复用
- 没有为尽力而为的IP服务添加更多的其他额外服务
- 都不提供:
- 延时保证
- 带宽保证
3.2 多路复用和解复用
工作原理
无连接(UDP)多路解复用
面向连接的解复用
3.3 无连接传输 UDP
UDP:用户数据报协议
User Datagram Protocol [RFC 768]
- “no frills”,”bare bones” Internet传输协议
- “尽力而为的服务”,报文段可能丢失,送到应用进程的报文段乱序
- 无连接:
- UDP发送端和接收端之间没有握手
- 每个UDP报文段都被独立地处理
UDP被用于:
- 流媒体(丢失不敏感,速率敏感,应用可控制传输速率)
- DNS
- SNMP
在UDP上实现可靠传输:
- 在应用层增加可靠性
- 应用特定的差错恢复
校验和:EDC,差错检验码
UDP校验和
目标:检测在被传输报文段中的差错(如比特反转)
发送方:
- 将报文段的内容视为一个个16比特的整数,不足的补0
- 校验和:报文段的加法和(1的补运输)
- 发送方将校验和放在UDP的校验和字段
接受方:
- 计算接受到的报文段的校验和
- 检查计算出的校验和与校验和字段的内容是否相等
- 不相等—检测到差错
- 相等—没检测到差错,但也许有差错—残存错误
即最高位进位要进到最低位去,最后结果取反码即为校验和
在接收方,将包括EDC在内的报文相加起来,为2^(16)-1,则通过校验
3.4 可靠数据传输(rdt)的原理
rdt_rcv大概是打错了,应该都是udt_rcv
即双向传输化rdt简化成单向传输rdt,而实现单向传输中,控制信息是双向的(需要给出反馈信息)
Rdt1.0: 在可靠信道上的可靠数据传输
同理,rdt_rcv应该是udt_rcv,此处应该是打错了
Rdt2.0: 具有比特差错的信道
Rdt2.1: ACK/NAK出错
即只要发送方没有接受到正确的ACK,都会重传当前分组,如果发送方已经成功收到该分组(通过分组内的序号识别?),则将其丢弃,再次发送ACK
packet通过校验后,通过序号是0还是1判断是否将数据传递给上层
Rdt2.2: 无NAK的协议
若ack出现错误,则sender重新发送packet,此时receiver根据packet中的序号判断是否重复
Rdt3.0 :具有比特差错和分组丢失的信道
要注意等待ACK状态中,接收到错误ACK后,不执行操作,直至超时后才重新发送packet
流水线协议:提高链路利用率
超时时间不合理仍能正常工作,但会导致packet都被发送多次
延迟时间:一个bit从发送方发出,到接受方接受所需要的时间—可以理解成车的行驶时间
带宽:每秒能发出多少个bit—可以理解为马路宽度,即每秒能发出多少辆车
由于每次发送需要等待接收方返回控制信息(ACK),就算链路的容量较大,由于每次发送的PDU较小,也无法有效利用其容量,如例子中吞吐量仅为270kbps
即一次发送多个PDU
通用:滑动窗口(slide window)协议
发送窗口:
- 发送窗口SW=1,接受窗口RW=1: S-W(stop and wait)协议—rdt3.0
- 发送窗口SW>1,接受窗口RW=1: GBN(回退N步)协议—流水线协议
- 发送窗口SW>1,接受窗口RW>1: SR(选择重传)协议—流水线协议
接受窗口:
接受窗口=1,比如罩住1时,若收到非1数据,都返回ACK0,收到1时,则返回ACK1,即GBN协议,只能顺序接受(其ACK包含累计确认的含义,即前X个都成功接收了)
若接受窗口>1,比如罩住1234,若收到2,则返回ACK2(但只有收到1时,尾沿才能移动),即SR协议
窗口互动:
比如发送方一次发送1~5,一共5个PDU,2~5都成功发送,由于GBN其接受窗口大小为1,2~5都被抛弃,然后产生了4个累计确认,然后超时重发机制又使得发送窗口内PDU全被发送一遍
假设发送了2,3,4,一共3个PDU,其中3,4都被接受到,返回ACK3和ACK4,而2超时,则超时重发机制会将2重新发送(而3,4不需要)
GBN协议和SR协议的异同
注意返回ACK1后不会立即发送2,而是等2的计时器超时,ACK决定的是窗口的后沿位置
注意上图中黑框为发送缓冲区的范围(发送后才加入发送窗口开始计时)
3.5 面向连接的传输: TCP
TCP:概述
- 全双工:二者可以同时向对方发送数据
- 物理链路中载荷大小有限,通过划定最大报文段大小,使数据分块分块后传输
TCP:报文段结构
- 注意序号是字节的序号,而不是前文中PDU的序号,如MSS大小为1024B,第一个MSS序号为0,则第二个MSS序号为1024,第n个MSS序号为1024*n(真实情况中,初始序号在握手时决定),而窗口大小也是以字节为单位
- 注意接受方若向发送方发送ACK555,则表示554及之前的字节都被成功接受,需要第555个字节(注意与前文差1)
- 乱序到达的段既可以丢弃也可以缓存
TCP:往返延时(RTT)和超时
前i个采样贡献权值为a*(1-a)^i,即呈指数下降
TCP:可靠数据传递
由重复确认引起的重传称为快速重传(因为还没超时)
接受方的ACK行为
TCP:流量控制
- 通过反馈接受窗口的大小(即缓冲区的空白大小)来控制流量
- 通过对报文段结构的学习,我们可以知道,反馈信息(窗口大小,ACK等等)是附带在数据中的(TCP的双向传输特性也支持这一点)
TCP:连接管理
两次握手是否可行?
即双方正常创建连接,关闭连接后,该连接中由于超时导致的重复发送(可能是连接请求,可能是传输的数据)才到达服务器,第一张图中服务器”建立”了一个不存在的连接,而第二张图中服务器不仅”建立”了一个不存在的连接,甚至接受了前一个连接中的老数据作为当前连接的新数据
三次握手
- 可以发现,第二次握手表示服务器是活跃的,第三次握手表示客户端是活跃的,因此延迟到达的连接请求会被服务器拒绝,无法建立
- 而延迟到达的数据,若socket已经关闭,则服务器不接受该数据;若相同端口,IP地址的socket再次打开,由于初始序号不一致,老数据仍被拒绝
- 有没有可能老数据的序号与此时的序号恰好一致—有,概率极小
- 可以将初始序号同时间周期绑定在一起—仍有可能重复,概率非常非常小,几乎不可能
连接拆除
- 为什么最后客户端仍有个等待时间—为了确保ack发送到服务器(ack可能发生丢失),服务器接收到ack后就关闭连接,客户端在发送ack一段时间后,才关闭连接
3.6 拥塞控制原理
与流量控制的差别:流量控制是”我”到”你”的问题,即单对单,而拥塞控制是整个网络的问题(多到多)
拥塞场景/代价1
拥塞场景/代价2
- 传输层输出大于应用层输出
- 因为拥塞,即使数据没有丢失也发生了超时,此时链路中存在多个相同的分组—浪费,同时加剧拥塞
拥塞场景/代价3
- 蓝色的流量经过第一个路由器过滤,当发生拥塞时,蓝色经过的第二个路由器,其吞吐量被红色占据,蓝色吞吐量几乎为0,而红色在其经过的第二个路由器,该路由器吞吐量又几乎被绿色的流量占据,故红色的吞吐量也几乎为0
- 出现”死锁”
拥塞控制方法
网络辅助的拥塞控制
信元: 53个字节,其中5个字节是头部(非常小,所以传输得很快,比bit大,比分组小)
3.7 TCP拥塞控制
因为网络辅助的拥塞控制,给网络带来的压力较大(附加了控制信息),所以TCP采用端到端的拥塞控制
TCP拥塞控制:机制
端到端的拥塞控制机制
- 路由器不向主机提供有关拥塞的反馈信息
- 路由器的负担较轻
- 符合网络核心简单的TCP/IP架构原则(将问题放在端系统解决)
- 端系统根据自身得到的信息,判断是否发生拥塞,从而采取动作
几个问题
- 如何检测拥塞
- 轻微拥塞
- 拥塞
- 控制策略
- 在拥塞发生时如何动作,降低速率
- 轻微拥塞时,如何降低
- 拥塞时,如何降低
- 在拥塞缓解时如何动作,增加速率
- 在拥塞发生时如何动作,降低速率
TCP拥塞控制:拥塞感知
TCP拥塞控制:速率控制方法
(MSS:最大报文段长度)
即发生超时时,先降为1,然后倍增到原来CongWin的1/2(每个RTT增加1倍),然后开始线性增长
若出现轻微拥塞,则直接降为CongWin的1/2,然后线性增长
TCP拥塞控制和流量控制的联合动作
TCP拥塞控制:策略概述
- 慢启动
- AIMD:线性增,乘性减少
- 超时事件后的保守策略
TCP慢启动
AIMD
TCP吞吐量
TCP公平性
每次发送拥塞,窗口大小要除2,则TCP会话之间的窗口大小之差也除2,指数级趋向于0,故每一个会话的有效带宽相同
UDP不受拥塞控制节制—对TCP不友好