每日总结-计网作业

所花时间:2小时

代码量:如下

博客量:本学期截至目前65篇

了解到的知识点:对计网的学习

5-01 试说明运输层在协议栈中的地位和作用,运输层的通信和网络层的通信有什么重要区别?为什么运输层是必不可少的?

地位:属于面向通信部分的最高层,同时也是用户功能中的最底层。
功能:向应用层提供通信服务。
区别:网络层为主机之间提供提供通信,可以使分组到达目的主机的网络层。但主机间的通信实际上是进程之间的通信,网络层无法给进程之间提供通信,但运输层可以,运输层通过其自身的功能,依靠网络层提供的服务,就可以实现两主机间进程与进程的通信。
运输层是要实现应用进程通信的,所以必不可少。

5-02 网络层提供数据报或虚电路服务对上面的运输层有何影响?

虚电路提供可靠服务,保证了数据报在主机之间的无差错传输,但不能保证运输层的无差错传输。数据报服务是不可靠的。总之,网络层提供数据报服务或虚电路服务对运输层是否可靠没有影响。

5-03 当应用程序使用面向连接的TCP和无连接的IP时,这种连接是面向连接的还是面向无连接的?

这要在不同层次来看,在运输层是面向连接的,在网络层则是无连接的。

5-04 试用画图解释运输层的复用。画图说明许多个运输用户复用到一条运输连接上,而这条运输连接又复用到IP数据报上。


H3和H1、H2同时进行通信。H3和H1中的两个进程HTTP和SMTP通信,H3和H2中的HTTP进程通信,共三个TCP连接。三个tcp连接传输的报文段都需要通过下面的网络层利用IP数据报作为载体进行传输。

5-05 试举例说明有些应用程序愿意采用不可靠的UDP,而不用采用可靠TCP。

对实时性要求高的应用程序愿意采用UDP获得低时延的效果,尽管会丢失部分数据报。

5-06 接收方收到有差错的UDP用户数据报时应如何处理?

简单丢弃即可。

5-07 如果应用程序愿意使用UDP来完成可靠的传输,这可能吗?请说明理由。

可能,但应用程序中必须额外提供与TCP相同的功能。

5-08 为什么说UDP是面向报文的,而TCP是面向字节流的?

UDP发送报文时将应用层传下来的报文添加首部后直接交给IP层,接收UDP报文时去掉首部直接交给应用层。
TCP发送报文时先将报文缓存起来,将其看做字节流,对每个字节都要编号,TCP根据网络拥塞情况与对方接收缓存大小决定一次发送多少字节的数据报。

5-09 端口的作用是什么?为什么端口号要划分为三种类型?

端口是应用层中的应用进程与运输层实体进行层间交互的接口,只具有本地意义。
服务器端使用两类端口号,熟知端口号和登记端口号,熟知端口号是给重要的应用程序使用的,登记端口号给没有熟知端口号的应用程序使用。这两类给服务器端使用,为了让所有用户都知道,便于通信。
客户端使用短暂端口号,这种端口号仅在客户端运行时才动态随机选择,留给客户临时使用。

5-10 试说明运输层中伪首部的作用。

用来计算报文的检验和。

5-11 某个应用进程使用运输层的用户数据报UDP,然而继续向下交给IP层后,又封装成IP数据报。既然都是数据报,可否跳过UDP而直接交给IP层?哪些功能UDP提供了但IP没提提供?

不能,UDP数据报中仅指明了通信进程双方的端口号,应用层的数据报直接交付给IP层后,虽然IP层能将数据报运送至目的主机,但不能确定通信进程双方的端口号,无法将数据交付给目的进程,不能完成通信。
没有复用和分用功能,不能实现进程间通信,没有数据部分的差错检验。

5-12 一个应用程序用UDP,到IP层把数据报在划分为4个数据报片发送出去,结果前两个数据报片丢失,后两个到达目的站。过了一段时间应用程序重传UDP,而IP层仍然划分为4个数据报片来传送。结果这次前两个到达目的站而后两个丢失。试问:在目的站能否将这两次传输的4个数据报片组装成完整的数据报?假定目的站第一次收到的后两个数据报片仍然保存在目的站的缓存中。

不行。重传的IP数据报的标识字段会有不同的标识符。仅当标识符相同的IP数据报片才能组装成一个IP数据报。前两个IP数据报片的标识符与后两个IP数据报片的标识符不同,因此不能组装成一个IP数据报。

5-13 一个UDP用户数据的数据字段为8192字节。在数据链路层要使用以太网来传送。试问应当划分为几个IP数据报片?说明每一个IP数据报片的数据字段长度和片偏移字段的值。

UDP用户数据报的长度:8192+8 = 8200字节
以太网数据字段最大长度1500字节,假设IP数据报首部长度20字节,则数据部分长度为1480字节。
8200 = 1480x5 + 800 所以需划分为6个数据报片。
前五个数据报片数据字段长度1480字节,最后一个800字节。
片偏移字节依次为:0,1480,2960,4440,5920,7400字节。
片偏移字段依次为:0,185,370,555,740,925

5-14 UDP用户数据报的首部十六进制表示是:06 32 00 45 00 1C E2 17.试求源端口、目的端口、用户数据报的总长度、数据部分长度。这个用户数据报是从客户发送给服务器还是服务器发送给客户?使用UDP的这个服务器程序是什么?

源端口:0000 0110 0011 0010,十进制为1586。
目的端口:0000 0000 0100 0101,十进制为69。
长度:0000 0000 0001 1100,十进制为28。
数据部分长度:28-8=20。
目的端口小于1023,是服务器端口,程序时TFTP。

5-15 使用TCP对实时话音数据的传输会有什么问题?使用UDP在传送数据文件时会有什么问题?

TCP虽然保证可靠传输,但它的延迟大,因为一旦有分组丢失就要重传,增加时延。
UDP是不可靠的传输协议,UDP传输数据文件如果出现差错,UDP就会丢弃这个数据报,不会重传,所以数据文件有可能是错误的。

5-16 在停止等待协议中如果不使用编号是否可行?为什么?

不行,如果报文段M1的确认报文在网络中延迟了,发送主机重新发送M1后收到延迟的M1确认报文,然后发送M2,收到重传M1的确认报文,就开始发送M3,此时M2有可能在传输过程丢失,而目的主机收到了两个M1。所以不使用编号是不行的。

5-17 在停止等待协议中,如果收到重复的报文段时不予理睬(即悄悄地丢弃它而其他什么也没做)是否可行?试举出具体的例子说明理由。

放发送方没有收到确认报文就会重传,接收方就会收到重复报文,停止等待协议对于重复报文要重传确认。让发送方知道自己接收到了报文,让其继续发送下一个。
如果不予理睬,发送发就以为对方没有收到报文,就会继续发送,进而陷入死循环。

5-18 假定在运输层使用停止等待协议。发送发在发送报文段M0后在设定的时间内未收到确认,于是重传M0,但M0又迟迟不能到达接收方。不久,发送方收到了迟到的对M0的确认,于是发送下一个报文段M1,不久就收到了对M1的确认。接着发送方发送新的报文段M0,但这个新的M0在传送过程中丢失了。正巧,一开始就滞留在网络中的M0现在到达接收方。接收方无法分辨M0是旧的。于是收下M0,并发送确认。显然,接收方后来收到的M0是重复的,协议失败了。试画出类似于图5-9所示的双方交换报文段的过程。

posted @   南北啊  阅读(162)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 【杭电多校比赛记录】2025“钉耙编程”中国大学生算法设计春季联赛(1)
1 2 3
4
点击右上角即可分享
微信分享提示