计算机网络OSI传输层

传输层服务概述

传输层服务和协议

传输层协议==>为运行在不同Host上的进程提供一种逻辑通信
- 是一种端到端的连接,两个进程间
- 逻辑通信==>两个进程之间仿佛是直接连接的,不需要管中间的物理距离.传输链路使用了多少路由器,实现了什么网络层媒介(双绞线/光纤)
端系统运行传输层协议
- 发送方 : 将应用递交的消息/报文分成一个或多个Segment(报文段),并向下传给网络层,网络层进行传输
- 接收方 : 从网络层收到的segment(报文段)组装成消息,并向上交给应用层
传输层可以为应用层提供多种协议
- Internet上的TCP
- Internet上的UDP
传输层与网络层的对比
- 网络层 : 提供主机间的逻辑通信(IP协议)
- 传输层 : 提供应用进程之间的逻辑通信
  - 位于网络层之上
  - 依赖于网络层的服务
  - 对网络层服务进行(可能的)增强

Internet传输层协议

可靠、按序的交付服务(TCP)

拥塞控制
流量控制
连接建立

不可靠的交付服务(UDP)

基于"(Best-effort)尽力而为"的网络层协议
没有做(可靠性方面的)扩展

多路复用和多路分用

应用场景
- 某层的协议对应直接上层的多个协议/实体,就需要用到多路复用

工作原理

主机接收到IP数据报(datagram)

每个数据报携带源IP地址和目的主机IP地址
每个数据报携带一个传输层的报文段(Segment)
每个段携带源端口号和目的主机端口号

主机收到报文段(Segment)之后,将传输层协议提取IP地址和端口号信息,将Segment导向相应的Socket

TCP做更多处理

面向UDP的无连接分用

利用端口号创建Socket

代码语言：javascript复制

DatagramSocket mySocket1 = new DatagramSocket(99111);
DatagramSocket mySocket2 = new DatagramSocket(99222);

UDP的Socket使用二元组标识==>(目的IP地址,目的端口号)
主机收到UDP报文段后
- 检查报文段中的目的端口号
- 将UDP报文段导向绑定在该端口号上的Socket
来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket

面向TCP的有连接分用

TCP的Socket用四元组标识
- 源IP地址
- 源端口号
- 目的IP地址
- 目的端口号
接收端利用所有的四个值将Segment导向合适的Socket
服务器可能同时支持多个TCPSocket
- 每个Socket用自己的四元组标识
Web服务器为每个客户端开不同的Socket

多线程服务器Web

UDP

User Datagram Protocol [RFC 768]

基于Internet IP协议
- 复用/分用(传输层协议都需要做)
- 简单的错误校验==>校验和
  - 发送方计算校验和(checksum)
  - 接收方,获取数据后重新计算校验和,并与接收端进行比对
    - 判断报文段在传输过程是否发生错误
  - 为什么传输层需要做错误检测
    - UDP与TCP提供的是端到端的连接通信,在传输过程需要经过多个路由器
    - 在传输过程,不能保证所有链路层协议均有错误检测和恢复机制
    - 经由路由器时也存在存储转发过程发生错误
  - UDP的特点==>将IP层服务暴露给应用层
IP层就是一个Best effort协议 ; UDP继承其特点也是一个"Best effort"协议
- UDP段可能会丢失,乱序
无连接
- UDP发送方和接收方之间不需要进行握手
- 每个UDP段的处理独立于其他段
UDP的优点
- 无需建立连接(减少延迟)
- 实现简单,无需维护链接
- 头部开销少
  - UDP头部8个Byte
  - TCP头部20个Byte
- 没有拥塞控制 : 上层应用可以更好地控制发送时间和速率
UDP的应用
- 流媒体==>容忍丢失,速率敏感
- DNS,SNMP
在UDP上如何实现可靠数据传输
- 在应用层增加可靠性机制
- 应用特定的错误恢复机制

UDP校验之checksum校验和

目的==>检测UDP段在传输中是否发生错误(如位翻转)
发送方
- 将段的内容视为16-bit
- 校验和计算==>计算所有整数的和,进位加在和的后面,将得到的值按位取反,得到校验和
- 发送方将校验和放入校验和字段
接收方
- 计算所得到的校验和
- 将其校验和字段进行对比
  - 不相等==>检测出错误
  - 相等==>没检测出错误(但可能有错误)
校验和计算案例
- tips : 最高位必须加进去

可靠数据传输原理==>RDT

什么是可靠?
- 不出差错,不丢包,不乱序
可靠数据传输协议的作用
- 可靠数据传输对应用层,传输层,链路层都很重要
- 是网络发展的Top-10问题
- 信道的不可靠特性决定了可靠数据传输协议(RDT-reliable data transfer )的复杂性
提供的服务&服务的实现

RDT基本结构==>接口

RDT特点
- 渐进式地设计可靠数据传输协议的发送方和接收方
- 只考虑单向数据传递
  - 控制信息双向流动
- 利用有限状态机(Finite State Machine,FSM)刻画传输协议

RDT 1.0 (理想化): 可靠信道上的可靠数据传输

底层信道完全可靠
- 不会发生错误(bit error)
- 不会丢弃分组
发送方和接收方的FSM独立

RDT 2.0 仅产生位错误的信道

研究的信道==>传输过程仅会产生位错误
- 不丢报,不乱序
解决的问题
- 接收方==>核验是否有误

底层信道可能翻转分组中的位(bit)

利用校验和校验位错误

发送方无法得知接收方是否正确接收==>ACK/NAK

如何从错误中恢复?

确认机制(Acknowledgement,ACK) : 接收方式显示地告知发送方分组已正确接收
NAK (Native Acknowledgement): 接收方显示地告知发送方分组有错误
- 发送方收到NAK后,重发分组
基于上述的重传机制的rdt协议称为ARQ(Automatic Repeat reQuest)协议

Rdt2.0中引入的新机制

差错检测
接收方反馈控制消息:ACK/NAK
- 该机制不是数据本身,是一种保证网络可靠传输的控制消息
重传

FSM规约

无错误场景

有错误场景

Rdt 2.1和2.2

Rdt 2.0有什么缺陷==>如果ACK/NAK消息发生错误/被破坏(corrupted)会怎样?
- 为ACK/NAK增加校验和,检错并纠错(难度太大)
- 发送方收到ACK/NAK时不知道接收方发生了什么?
  - 增加额外的控制消息
- 若ACK/NAK坏掉,发送方重传(计网中普遍使用的方法)
  - 不能简单的重传==>会产生重复分组
- 解决分组重复问题?
  - 序列号(Sequence number) : 发送方给每个分组增加序列号
  - 接收方丢弃重复分组

Rdt 2.1 解决ACK/NAK破坏

发送方,解决ACK/NAK破坏

采用0/1序列号
发送消息制作分组时,加入序列号0
遇到NAK时或确认消息坏掉,重传,序列号仍为0
遇到ACK时并且没有坏掉时,序列号置1

接收方,解决ACK/NAK破坏

收到分组数据,数据没有坏掉,收到的分组序列号与期望序列号一致
- 提取数据,交付数据,制作和发送ACK
收到数据分组,数据没有坏掉,分组序列号与期望序列号不一致
- 制作和发送ACK
收到数据分组,数据被破坏
- 制作和发送NAK

Rdt 2.1 相较于 Rdt 2.0
- 发送方
  - 为每个分组增加了序列号
  - 由于使用停等协议,仅需新增(0,1)两个序列号即可
  - 需要校验ACK/NAK消息是否出错
  - 状态数量翻倍
    - 状态必须"记住""当前"的分组序列号
- 接收方
  - 需要判断分组是否重复
    - 当前所处状态提供了期望收到分组的序列号
  - 接收方无法知道ACK/NAK是否被发送方正确收到

Rdt 2.2 无NAK消息协议

与rdt2.1功能相同,但只使用ACK
实现原理
- 接收方通过ACK告知最后一个被正确接收的分组
- 在ACK消息中显式加入最后一个被确认分组的序列号
  - 发送方发1,而接收方确认0==>发送方就知道1没有被接收方正确收到
  - 发送发==>重传
发送方收到重复ACK之后,采取与收到NAK消息相同的动作
- 重传当前分组

Rdt 3.0

若信道既可能发生错误,也可能丢失,又该如何解决
校验和序列号 ACK 重传够用吗?
假设场景
- 发送发送一个分组,在到达接收方之前丢失了,或者接收方返回的消息丢失了
- 此时发送方一直在等待接收方响应
解决分组丢失的一个方法 : 发送方设置等待时间,当timeout时
- 若无收到ACK==>重传
- 若分组/ACK只是延迟到达而非丢失
  - 重传会产生重复,序列号机制能够处理
  - 接收方需在ACK中显式告知所确认的分组
- 需要定时器

发送方FSM

示例==>数据报丢失

示例==>控制消息ACK丢失

计时器设置时间过短/timeout时间早熟(RDT3.0的技术核心在于timeout时间的确定)

Rdt 性能分析

Rdt3.0能够正确工作,但性能很差
示例==>1Gbps链路,15ms端到端传播延迟,1KB分组

发送方利用率 : 发送方发送时间百分比

在1Gbps链路上每30毫秒才发送一个分组,33KB/sec
网络协议限制了物理资源的利用

Rdt 停等操作

滑动窗口协议

流水线机制

回顾RDT3.0的弊端==>由于停等协议==>导致性能极差

采用流水线机制==>提高资源利用率

流水线协议

允许发送方在收到ACK之前连续发送多个分组
- 更多序列号范围
- 发送方和/或接收方需要更大的存储空间以缓存分组

计算机网络中若想实习流水线机制,需要滑动窗口协议支持

滑动窗口协议

滑动窗口协议 : Sliding-window protocol
窗口 :
- 允许使用的序列号范围
- 窗口尺寸为N : 最多有N个等待确认的消息
- 绿色==>已发送并且已确认
- 黄色==>已发送未确认
- 蓝色==>还可使用的序列号
滑动窗口
- 随着协议的运行,窗口序列号空间内向前滑动
滑动窗口协议 : GBN,SR

Go-Back-N 协议

发送方

分组头部包含k-bit序列号
窗口尺寸为N,最多允许N个分组未确认

最小序列号==>send_base
nextseqnum==>可用的序列号
ACK(n) : 确认收到序列号n(包含n)的分组均已被正确接收
- 可能收到重复ACK
为空中的分组设置计时器(timer)
超时Timeout()事件 : 重传序列号>=n,还未收到ACK的所有分组
- 潜在可能造成资源浪费

扩展有限状态自动机——FSM

rdt_send(data)
- nextseqnum<base N ==> 存在可用的seqnum
  - 执行打包发送,当base == nextseqnum时,启动定时器
  - nextseqnum
- refuse_data(data) ==> 当窗口中的序列号都用完时,上层需要调用时,直接调用该方法
timeout
- start_timer,重启定时器
- 重发未确认分组
收到分组确认消息&&分组消息未被破坏
- 修改 base =提取序列号 1
- base == nextseqnum 时停止定时器否则,重启定时器

接收方扩展有限状态自动机——FSM

ACK机制 : 发送拥有最高序列号的、已被正确接收的分组ACK
- 可能产生重复ACK
- 只需要记住唯一的expectedseqnum期望收到的
- 简单的发送拥有最高序列号的已被正确接收的分组的ACK
乱序到达的分组 :
- 直接丢弃->接收方没有缓存
- 重新确认序列号最大的,按序到达的分组
  - 期望5收到7,确认4
收到分组&&分组没坏&&序列号是所期望的序列号
- 交付数据
- 发送ACK
- exceptedseqnum
流水线协议会存在乱序到达的分组,停等协议不会出现乱序到达