思维导图:
5.4 可靠传输的工作原理
前言概述
- TCP与IP层的关系:TCP负责发送报文段,而IP层负责传送这些报文段。IP层仅提供“尽最大努力服务”,本质上是不可靠的传输。
- TCP的责任:为了弥补IP层的不可靠性,TCP需要采取一系列措施确保两个运输层之间通信的可靠性。
理想与现实
- 理想条件:
- 传输信道完美无差错。
- 接收方处理能力与发送方发送速度匹配,总是能及时处理所有数据。
- 在这种情况下,可靠传输自然而然发生,无需额外机制。
- 现实挑战:
- 现实中,网络条件远非理想,传输信道可能出现差错,接收方可能处理不及时。
实现可靠传输
- 差错时的处理:通过可靠传输协议,出现差错时,可以让发送方重传出错的数据。
- 流量控制:接收方通过反馈控制信息,告知发送方其处理能力,使发送方调整发送速率以匹配接收方处理速度。
探讨基础
- 停止等待协议:从最简单的可靠传输协议开始讨论,停止等待协议是构建可靠传输机制的起点。
笔记要点
- 可靠传输核心:TCP通过补充措施确保通信可靠性,包括重传机制和流量控制。
- 重传机制:它是对差错控制的直接回应,确保信息正确传达。
- 流量控制:它是对接收能力的一种保障,防止接收方被过快的发送速度淹没。
5.4.1 停止等待协议笔记
基本概念
- 全双工通信: 通信双方可以同时作为发送方和接收方。
- 分组: 为了讨论可靠传输的原理,这里指传送的数据单元。
- 停止等待协议: 发送一个分组后暂停,等待对方确认后再发送下一个。
无差错情况
- 发送方A发送分组M₁并等待接收方B的确认。
- 接收方B在收到分组M₁后,发送确认给A。
- A在收到确认后,继续发送下一个分组M₂。
出现差错情况
- B在接收到有差错的分组时,选择丢弃不进行任何通知。
- A超时未收到确认时,执行超时重传。
- 每个分组发送后都设有超时计时器,超时则触发重传。
- A需要保留已发送分组的副本,以便于超时重传。
- 分组和确认都必须编号,以识别哪些分组已确认。
超时重传
- 设置的超时时间应长于平均往返时间RTT。
- 如果重传时间设置不当,将影响通信效率或造成资源浪费。
确认丢失与迟到
- 如果B发送的确认丢失,A会重传分组。
- 如果收到重复分组,B应丢弃并再次发送确认。
- A在收到重复确认时应该直接丢弃。
信道利用率问题
- 停止等待协议信道利用率低。
ARQ协议
- 自动重传请求(Automatic Repeat reQuest),即无需接收方请求,发送方在未收到确认时自动重传。
- 在不可靠的传输网络上实现可靠通信。
-
时间扣除细节:
- 分子中的时间可以扣除传输控制信息,例如首部所需的时间,对于细致计算很重要。
- 粗略估计时,可使用简化公式(5-3)。
-
往返时间RTT:
- RTT依赖于使用的信道。
- 例子:1200 km信道的RTT=20ms。
-
信道利用率U计算:
- 给出的例子中,分组长度1200 bit,发送速率1 Mbit/s,忽略处理时间和T₄(T₄通常很小)。
- 计算结果:U=5.66%。
- 如果发送速率提高到10 Mbit/s,U=5.96×10^-2,大部分时间信道空闲。
-
信道利用率和RTT关系:
- 当RTT远大于分组发送时间Tp时,信道利用率非常低。
- 重传分组会进一步降低利用率。
-
提高传输效率:
- 流水线传输提高效率,连续发送多个分组,无需每发一个就停下来等待确认。
- 流水线传输示例图5-12说明了如何提高信道利用率。
-
高级协议:
- 流水线传输需要连续ARQ协议和滑动窗口协议。
- 这些协议使数据连续传输成为可能,并提高了信道利用率。
结论:
- 提高信道利用率需要考虑控制信息的传输时间,RTT的大小,发送速率,以及传输协议的选择。
- 流水线传输与滑动窗口协议相结合,可以有效地提升信道的数据传输效率,尤其在高RTT情况下更为显著。
总结
- 停止等待协议是实现可靠传输的基本方法之一,它通过确认和重传机制确保信息正确传递。
- 由于每次只发送一个分组,等待确认后才发送下一个,因此其信道利用率较低。
- 在传输层的实际应用中,使用更复杂的协议以提高效率和可靠性。
我的理解:
停止等待协议是一种基本的数据传输协议,用于在不可靠的传输媒介上实现可靠通信。这种协议非常简单,其基本工作原理如下:
- 发送方(A)发送一个数据分组(M₁)给接收方(B),然后停止发送更多的数据,即“停止”;
- 发送方(A)开始等待接收方(B)的确认(ACK)信号。如果接收方成功收到了数据分组并检验无误,它就会发送这个确认信号;
- 发送方在设定的超时时间内如果没有接收到确认信号,它会重新发送同一数据分组,即“等待”期间发生了“超时重传”;
- 一旦发送方收到了确认信号,它就会发送下一个数据分组(M₂),然后再次等待确认;
- 如果在传输过程中出现了数据分组的丢失、错误或者确认信号的丢失,发送方会在超时后重传该分组;
- 接收方每次收到新的或重传的分组,都需要发送一个确认信号。
通过这种方式,停止等待协议确保了即使在网络不可靠的情况下,数据分组也能够被可靠地从发送方传输到接收方。但由于发送方在每次发送一个分组后都要等待确认,这显著地限制了通信的吞吐量,使得信道利用率较低。即通信效率受到限制,因为信道在等待确认信号期间未被使用。尽管如此,停止等待协议仍然在一些需要高可靠性而不那么关注吞吐量的场合中得到应用。
更形象的说:
可以把停止等待协议比喻成餐厅里的点菜和服务流程:
想象一下你去了一家非常特别的餐厅吃饭。在这家餐厅里,规定顾客每次只能点一样菜,服务员拿到订单后会去厨房准备,直到这道菜做好并且你确认收到后,服务员才会接受你下一次的点菜。
-
发送方和接收方:你是“发送方”,负责发送订单;服务员是“接收方”,负责确认订单并传递你点的菜。
-
发送和等待:当你点了一道菜(相当于发送了一个数据包)之后,你会暂时停止点菜(停止发送),开始等待服务员确认这个订单并把菜送到你的桌上(等待确认信号)。
-
确认信号:服务员把菜送到你的桌上后,你会对服务员说“确认收到”(发送ACK),服务员听到后就知道你已经收到了这道菜。
-
超时重传:如果服务员在规定的时间内没听到你的确认(比如餐厅里太吵了),他会认为你没收到菜,会再次准备同样的菜给你(重传机制)。
-
顺序点菜:一旦你确认收到了菜,你才能点下一样(发送下一个数据包),这个过程一直重复,直到你吃完整顿饭。
在这个比喻中,由于你每次只能点一样菜,而服务员也要等你确认收到之后才能接受下一个订单,所以整个吃饭的过程会比较慢。这就像停止等待协议,它确保了每个“菜肴”(数据包)都能被准确传递和确认,但同时整个“用餐”(传输)效率并不高。
5.4.2 连续ARQ协议笔记
基本概念:
- 连续ARQ协议是滑动窗口机制的基础,它允许在没有收到确认(ACK)的情况下发送多个分组。
发送窗口:
- 发送窗口大小为5,意味着可连续发送五个分组而不等待ACK。
- 发送窗口提高了信道的利用率,因为可以持续发送数据。
时间和方向:
- 时间坐标表明分组发送的先后顺序。
- “向前”意味着随时间增加,“向后”则相反。
窗口滑动:
- 收到一个分组的ACK后,发送窗口向前滑动一个分组的位置。
- 允许发送新的分组进入窗口。
累积确认:
- 接收方采用累积确认,减少了ACK的数量。
- 只有收到的最后一个分组被确认,这意味着所有之前的分组均已正确接收。
优缺点:
- 累积确认简单高效,减少了必需的确认消息。
- 不能提供对每个分组独立确认的详细信息。
Go-back-N策略:
- 如果发生分组丢失,接收方只确认最后按序收到的分组。
- 发送方必须重传丢失分组及其后所有分组。
- 在线路质量差的情况下效率低。
前提知识:
- 在讨论TCP的可靠传输之前,需先理解TCP报文段首部的格式。
结论:
- 连续ARQ和累积确认简化了确认过程,但在分组丢失时可能导致效率问题。
- 此协议是理解复杂的TCP协议一个重要步骤,特别是在高级滑动窗口机制中。
额外注记:
- 详细的滑动窗口协议将在5.6节讨论,为了完全理解连续ARQ,需要预先掌握5.6节的内容。
- 理解这一节内容是理解TCP协议的关键,特别是对于其如何在不可靠的网络中提供可靠传输的能力。
我的理解:
想象一下,你在一家餐厅里点餐。这家餐厅有一个特别的服务流程,类似于连续ARQ协议:
-
分批服务(分组发送):假设你点了五道菜。这些菜就像数据分组,每一道菜都有一个顺序号。
-
多盘同时上(发送窗口):服务员不是一道菜上完才去拿下一道,而是根据餐盘大小(发送窗口大小),一次性端出几道菜(分组),比如三道。
-
确认收菜(确认和窗口滑动):你确认收到每一道菜后,服务员会记下来,并准备将下一批菜端出来。这就像是在数据传输中收到ACK后,发送窗口滑动,准备发送新的数据分组。
-
集中反馈(累积确认):服务员不需要你每吃完一道菜就确认,只需要当你吃完三道菜后,确认一次即可。这样,服务员就知道你至少吃完了前三道菜。
-
菜品遗失(错误处理):如果第二道菜没能成功送达(比如摔在地上了),你不会继续确认新的菜品。服务员注意到你停止确认后,会重新准备并端出这道菜。
-
从遗失的地方重新端(Go-back-N):服务员不仅重新端出第二道菜,而且还会连同后面所有已经端出但你未确认的菜一并重新端出,确保没有遗漏。
通过这样的方式,餐厅确保了每一位客人都能按顺序收到他们点的所有菜品,并且服务员在处理多个桌子时,能够高效且无误地服务。
总结:
重点:
- 可靠性的定义:了解可靠性意味着数据无差错、不丢失、不重复,并且按序到达。
- 错误检测:理解如何通过校验和或CRC等方法检测出在传输过程中发生的错误。
- 确认和超时:掌握发送方如何通过接收方的确认(ACK)知晓数据是否成功到达,以及如何使用超时重传来对付丢失的数据包或确认。
- 停止等待协议:知道这是最简单的可靠传输协议,要求发送方在收到前一个数据包的确认前不发送下一个数据包。
- 连续ARQ协议:明白这种协议允许在等待确认的同时发送多个数据包,提高了通道利用率。
难点:
- 流量控制:理解发送方和接收方如何通过滑动窗口机制来调整发送速率,防止接收方被过多数据淹没。
- 滑动窗口协议:这个协议较为复杂,因为它涉及到发送窗口和接收窗口的动态调整,以及对乱序到达的数据包的处理。
- 连续ARQ的窗口滑动:深入理解窗口是如何滑动的,以及这种滑动对于数据流动的影响。
- 累积确认的工作机制:理解累积确认如何减少必须发送的ACK数量,但也可能导致不必要的重传。
易错点:
- 混淆协议:不要将停止等待协议和连续ARQ协议混淆,每个协议有其特定的使用场景和效率。
- 错误处理方式:理解当错误发生时,不同协议是如何处理的,特别是区分Go-Back-N和选择重传策略。
- 超时设置:确定合适的超时时间对于防止不必要的重传或过长的延迟至关重要。
- 状态信息的更新:每次接收到确认时,发送方和接收方的窗口如何更新是个易错点。
- 确认丢失与数据丢失:理解当确认丢失而非数据丢失时协议的行为,尤其是累积确认可能导致的不必要重传。
在学习这一节时,要尤其注意协议操作的具体细节,理解各个操作为何而设计,并通过实例来加强记忆。此外,画出图解,模拟协议流程,尤其是滑动窗口的变化,可以帮助更好地理解协议机制和避免混淆。