计算机网络笔记--3 传 输 层(上)

计算机网络笔记–3 传 输 层(上)


前言

这是学习计算机网络课程时记录的笔记,里面大部分内容来源于哈尔滨工业大学李全龙老师的《计算机网络》mooc,加上我个人的理解整理出的内容。


在这里插入图片描述

任务:
理解传输层服务的基本理论和基本机制:
多路复用/分用
可靠数据传输机制
流量控制机制
拥塞控制机制

掌握Internet的传输层协议:
UDP无连接
TCP面向连接
TCP拥塞控制

3.1传输层服务概述

传输层协议为运行在不同主机上的进程之间提供了一种逻辑通信机制
端系统运行传输层协议
发送方:将应用递交的消息分成一个或者多个的Segment(报文段),并向下交给网络层
接收方:将接收到的segment组装成消息,并向上交给应用层
传输层为应用提供多种协议
Internet上的UDP,TCP

传输层与网络层的比较
网络层:提供主机之间的逻辑通信机制
传输层:提供应用进程间的逻辑通信机制——>位于网络层之上,依赖于网络层服务,为网络层服务进行(可能的)增强在这里插入图片描述
Internet传输层协议
可靠的、按序的交付服务(TCP):拥塞控制,流量控制,建立连接
不可靠的交付服务(UDP):基于尽力而为的网络层,没有做(可靠性)方面的扩展
两种服务均不保证:延迟、带宽

3.2多路复用和多路分用(传输层)

在这里插入图片描述
接收端:多路分用
发送端:多路复用

多路分用工作原理:
1.主机接收到IP数据报:
每个数据报携带源IP地址、目的IP地址
每个数据报携带一个传输层的段(Segment)
每个段携带源端口号和目的端口号
2.主机收到Segment后,传输层协议提取IP地址和端口号信息,将Segment导向相应的SocketTCP做更多处理
一:无连接分用
1.利用端口号创建Socket
2.UDP的Socket是用二元组标识的(目的IP地址,目的端口号)
3.主机收到UDP段后
检查段中的目的端口号
将UDP段导向绑定在该端口号的Socket
4.来自不同源IP地址(和/或)源端口号的IP数据包被导向同一个Socket
在这里插入图片描述
二:面向连接的分用
1.TCP的Socket用四元组标识
源IP地址
源端口号
目的IP地址
目的端口号
2.接收端利用所有的四个值,将Segment导向合适的Socket
3.服务器可能同时支持多个TCPSocket——>都有自己的四元组
4.Web服务器为每个用户开不同的Socket在这里插入图片描述
UDP就解决不了如上图,区分P2——>P6和P3——>P5两条链路的问题,即目的端口和目的IP地址无法将两个使用同一进程的请求分开

多线程WEB服务器
进程是耗费时间多的机制——>利用线程维持多个TCP连接——>提高效率在这里插入图片描述

3.3 UDP协议详解(User Datagram Protocol)

一:基于Internet IP协议:复用/分用
简单的错误校验——>在端到端原则下,因为网络层可能也会出错,所以传输层也要有相应的错误检测和控制
二:“Best effort”(尽力而为)服务,UDP段可能:丢失,非按序到达(因为IP就是这样,UDP未改进)

三:无连接:UDP发送方和接收方之间不需要握手
UDP每个报文段的处理独立于其他段

四:UDP存在的价值:
1.无需建立连接(显著减少延迟)
2.实现简单,无需维护连接状态
3.头部开销少
4.没有拥塞控制:应用可更好地控制发送时间和速率(限制少)在这里插入图片描述
五:UDP的使用
常用于流媒体应用:容忍丢失,对速率敏感(对速率要求高)
用于:DNS,SNMP
在UDP上如何实现可靠数据传输:在应用层增加可靠性机制
(应用开发难度增大) 应用特定的错误恢复机制

UDP校验和(checksum)
目的:检测UDP在传输过程中是否发生错误(如位翻转)
对于发送方:
1.将段的内容视为16-bit整数
2.校验和计算:计算所有整数的和,进位加在和的后面,将得到的值按位取反,得到校验和
3.然后发送方将校验和放在checksum字段
对于接收方:
1.计算所收到段的校验和
2.将其与校验和字段进行对比:不相等——>有错误,相等——>没检测到错误但是可能有错误,因为不同数据可能算出相同结果

校验和计算示例:(最高位进位要加到结果的最低位)在这里插入图片描述
Wraparound的第一个1,加到了wrapaound的最低位,得到了sum

3.4可靠数据传输(rdt)的基本原理

可靠:不错,不丢,不乱
可靠数据传输协议:
对应用层、传输层、链路层都很重要
网络Top-10问题
信道的不可靠特性决定了可靠数据传输协议的复杂性在这里插入图片描述
Rdt_send():被上层应用调用,将数据交给rdt以发送给对方
Udt_send():被rdt调用,在不可靠信道上向接收方传输数据
Rdt_recv():当数据包到达接收方信道时被调用
注意图中的双向箭头,因为在不可靠信道上的数据传输,需要双向的控制消息流动

渐进地设计可靠数据传输协议的发送方和接收方
只考虑单向传输数据:但控制信息单向流动
利用状态机(FSM)刻画传输协议在这里插入图片描述
RDT 1.0:可靠信道上的可靠数据传输
底层信道完全可靠:不会发生错误,不会丢弃分组
发送方和接受方的FSM独立在这里插入图片描述
RDT 2.0:产生位错误的信道(1变0,0变1)
底层信道可以反转分组中的位(bit)——>利用校验和检测位错误
如何从错误中恢复:
确认机制(ACK)接收方显式的告诉发送方分组已正确接受acknowledge
NAK:接收方显式的告知发送方分组有错误negative acknowledge。发送方收到NAK后,重传分组
基于这种重传机制的RDT协议称为ARQ(Automatic Repeat reQuest)协议

Rdt2.0引入的新机制:
差错检测(校验和等)
接收方反馈控制信息:ACK/NAK
重传

Rdt 2.0的FSM归约(发送方变为两个状态)
在这里插入图片描述
‘^’的意思是不需要进行操作,有接受信号不需要响应就可以进行状态转移
注:停止等待就是之前学过的:每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。

Rdt 2.0的缺陷

1.如果ACK/NAK消息发生错误/被破坏会怎么样
为ACK/NAK增加校验和,检错并纠错
发送方收到被破坏ACK/NAK时不知道接收方发生了什么:添加额外的控制消息
如果ACK/NAK坏掉:发送方重传
不能简单地重传:产生重复分组
2.如何解决重复分组问题
序列号:发送方给每个分组增加序列号
接收方丢弃重复分组
仍然使用停止等待机制

Rdt 2.1按照上述方法得到了:发送方应对ACK/NAK破坏在这里插入图片描述
在这里插入图片描述
Rdt 2.1对2.0的改进/区别
对于发送方:
对每个分组增加了序列号
两个序列号就够用(0,1)——>我的理解:分组的序列号为0101交替,就可以足够区别相邻两个文件,这样当我重复收到1或者0就说明分组重复接受或者缺失,因为是采用停止等待机制,所以只需要判断每两个相邻文件之间序列号就可以判断整个报文的传输成功与失败
需校验ACK/NAK消息是否发生错误
状态数量翻倍:状态必须“记住”“当前”分组的序列号
对于接收方:
需判断分组是否重复:当前所处状态提供了期望收到分组的序列号
注意:接收方无法知道ACK/NAK是否被发送方正确收到

在接收方等待0却得到1要调用ACK——>我的理解:为什么不用NAK?用ACK接收方不改变状态,但是可以让发送方进入到发送下一个分组即0分组的状态,就可以收到想要的0序列号报文。为什么不能不响应?是发送方在等待接受方的响应,如果接受方没有ACK或者NAK,发送方得不到回复不能继续发送,接受方也无法响应,所以整个传输陷入停滞

Rdt 2.2:无NAK消息协议
与rdt2.1功能相同,但是只是用ACK
实现过程:接收方通过ACK告知最后一个被正确接受的分组,在ACK消息中显式地加入被确认分组的序列号
发送方收到重复的ACK时,采取与收到NAK消息相同的动作, 重传当前分组
在这里插入图片描述
如果信道既可能发生错误也可能丢失分组怎么办(会导致双方一直等待)
解决:发送方等待“合理”时间:如果没收到ACK——>重传
如果分组或者ACK只是延迟没有丢——>重传会产生重复,但是序列号机制可以解决,接收方需要在ACK中显式地告知所确认的分组
需要定时器
Rdt 3.0因此产生了

Rdt3.0发送方FSM
在这里插入图片描述
Start_timer:启动定时器
Stop_timer:重置定时器
Timeout:超时在这里插入图片描述
在这里插入图片描述
Rdt3.0性能分析
Rdt3.0能够工作但是性能很差
示例:1Gbps链路,15ms端到端传播延迟,1KB分组在这里插入图片描述
在1Gbps链路上每30ms发送一个分组——>33KB/sec
网络协议限制了物理资源的利用(本质上是停等操作限制了速度)在这里插入图片描述

3.5流水线机制和滑动窗口协议

流水线机制:提高资源利用率
流水线协议:允许发送方在收到ACK之前连续发送多个分组
所以就会有更大的序列号范围
发送方/接收方需要更大的储存空间以缓存分组
停-等机制和流水线机制的区别:在这里插入图片描述
滑动窗口协议:Sliding-window protocol
窗口:允许使用的序列号范围
窗口尺寸为N,最多有N个等待确认的消息
滑动窗口:随着协议的运行,窗口在序列号空间内向前滑动
滑动窗口协议:GBN,SR在这里插入图片描述
已经发送且已经确认 已经发送未确认 还可以使用的序列号

Go-Back-N(GBN)协议(累计确认机制)
1.分组头部包含k-bit序列号
2.窗口尺寸为N,最多允许N个未确认分组
3.ACK(n):确认到序列号n的分组均已被正确接受(累积确认机制)
——>可能收到重复ACK
4.为空中的分组设置计时器(timer)
5.超时timeout(n)事件:序列号大于等于n,还未收到ACK的所有分组,都要被重传(n<=N)在这里插入图片描述
发送方扩展FSM在这里插入图片描述
Refuse_data:当前所有序列号已经用完,不能再提供新的序列号就拒绝请求
接收方扩展FSM:在这里插入图片描述
每次期望的序列号都是每次加一的,所以只要接收方发送了ACKn,那么接收方一定已经发送了ACK1到ACKn-1
ACK机制:发送拥有最高序列号的、已被正确接收的分组的ACK——>可能产生重复ACK,只需要机制唯一的expectedseqnum
对于乱序到达的分组:直接丢弃,因为接收方没有缓存
重新确认按序到达的、序列号最大的分组
教材官网有动画演示GBN过程
在这里插入图片描述
GBN的缺陷:只要出现丢失就会重发很多分组影响网络

Selective Repeat协议 (SR)
解决GBN的缺陷:
接受方对每个分组单独进行确认:设置缓存机制,缓存乱序到达的分组
发送方只重传那些没收到ACK的分组:为每个分组设置定时器
发送方窗口:N个连续的序列号,限制已发送而未确认的分组
发送方与接收方窗口示意图(两个窗口不是对应的):在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
SR解决了GBN的重复发送的缺陷,但是SR还有自己的问题

序列号空间大小与窗口尺寸需满足什么关系
Ns+Nr<=2k ——>这样两个窗口永远不会有前后同序列号但是分组文件不一致问题
Ns:发送方窗口大小
Nr:接收方窗口大小
K:二进制序列号的位数在这里插入图片描述

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值