《计算机网络 自顶向下方法》 第3章 运输层 Part1

 

由于个人精力和智商有限,又喜欢想太多、钻牛角尖,导致学习系统性知识很痛苦,尝试改变学习方式,慢慢摸索
现在看到 rdt2.0,又有点看不下去
现在的想法:
要有个目标,且有截止时间(作业模式、考试模式),在过程中,如果遇到对整体没有致命影响的难点,可以暂时跳过,在特定时间内把目标内的其他地方解决即可(即先解决简单的其他部分,在考虑进攻难点,这样的话,前期心态不会太焦灼,而且等回过头进攻难点的时候,有一种从四面八方将难点包围的感觉)
 
写博客也换个思路:
边写博客,边摸索写博客的方式,而且可以把摸索过程也记在博客里
 
 
记录一下本章的说明问题的思路,值得学习
大思路:
由于一个能提供可靠数据传输和拥塞控制的协议必定是复杂的,采用基本原理与 TCP 交替介绍方式(从一般走向具体)
在一般环境下讨论可靠数据传输,然后讨论 TCP 是怎样具体提供可靠数据传输的
在一般环境下讨论拥塞控制,然后讨论 TCP 是怎样实现拥塞控制的
小思路:
在讨论可靠数据传输原理的时候,将底层信道从理想状况逐步向现实情况靠拢,进而逐步引出相关概念
从简单模型到复杂模型,一点点把复杂的事情说清楚
 
 
本章整体情况
 
理想情况到现实情况分别是:
理想:底层信道完全可靠(比特不受损,分组不丢失,比特不会被重排序)
现实一:底层信道会让比特受损(比特受损,分组不丢失,比特不会被重排序)
现实二:底层信道会丢包(比特受损,分组丢失,比特不会被重排序)
注意,本章贯穿始终的一个假设是分组将以它们发送的次序进行交付,某些分组可能会丢失,即底层信道不会对分组重排序
 
理想情况:发送发和接收方只需做简单的发送和接收操作就行了(对应协议:rdt1.0)
现实一需要的技术:检验和、肯定和否定确定、重传、序号、ACK 分组(对应协议:rdt2.0)
现实二需要的技术:检验和、肯定和否定确定、重传、序号、ACK 分组、定时器(对应协议:rdt3.0)
 
由 rdt3.0 的缺点(停等协议,链路利用率低),引入流水线可靠数据传输协议
为了保证是流水线可靠数据传输协议的有效性(主要是为实现其差错回复功能),引入回退 N 步的的方法
而回退 N 步的方法,可能会导致一些性能问题(一个出错,之前的全部需要重传,如果失败率较高,则可能导致信道中充斥着冗余的分组),于是引入了选择重传的方法
 
 
有一点值得注意的是
我们一般写程序都不用考虑这么多,是因为我们选择了 TCP 协议,虽然 IP 层(即网络层)及以下是不可靠的,但是运输层的 TCP 帮助我们解决了这些不可靠,使我们可以专注于开发应用程序,而不用担心数据是否会按照预想、没有误差到达目的地
 
 
以下是对我来说有用的零散知识点:
 
最简运输层功能:
进程到进程的数据交付、差错检查
附加功能:
可靠数据传输、拥塞控制
 
运输层协议只运行在端系统,而不是路由器中,运输层协议将报文在应用进程和网络边缘(即网络层)之间移动(在发送方,移动方向是 应用进程→网络边缘;在接收方,则反过来)
 
网络层为主机之间提供通信,运输层为不同主机上的进程之间提供通信
 
多路复用与多路分解
 
看微信“文件传输助手”中的聊天记录
 
IP 层是不可靠的

 

 把这次看不懂的地方记录一下:

 

对于协议 rdt2.1,有个问题想不明白:

接收方成功接受了分组 0,向发送方反馈了一个 ACK,而由于比特受损,发送方收到了一个含糊不清的回复,于是发送方重传了分组 0,而此时接收方已经在等待分组 1 到的了,这样的话,当接收方在此接收到分组 0 的时候(与预期的分组 1 不符),会给发送发返回一个 NAK,发送发以为重传分组 0 失败,继续重传分组 0,而接收方此时预期接收的还是分组 1,于是造成了一个死循环

这种情况会发生吗?是不是我没有完全看懂协议 rdt2.1?

 

posted @ 2019-06-05 20:31  stoneBlog  阅读(213)  评论(0编辑  收藏  举报