作业

计算机网络第3章习题解答

jxtxzzw · 11月17日 · 2018年 · · · · · · · · · · · · · · · · · · · · · · · · · · · 182次已读
学校华东师范大学
专业计算机科学与技术
课程名称计算机网络
教师黄新力
年份2018年秋

3

求 UDP 校验和。

为什么 UDP 校验和要取反码,而不是直接用加和以后的值?

接收方如何根据反码判断有没有出现差错?

有没有可能 $1$ 个比特的错误没有被检查出来,$2$ 个比特呢?

$01101010+01001111=10111001, 10111001+01110011=00101101$,注意溢出的一位需要回卷。

因为如果只是用校验和而不取反码的话,就意味着和是一个数字,那就依赖与发送者和接受着的大小端,否则求出的和可能会有字节顺序上的区别,而使用反码就不会有这样的问题,只要检查是不是全为 $1$ 即可。

接收方把所有的数据,包括校验和的反码全部加起来,如果该和为 $11111111$,说明没有差错,否则,出现差错。

所有的 $1$ 个比特的错误都会被检查出来,$2$ 个比特的错误不能。

4

UDP 接收方计算出来的校验和与字段中的校验和一致,可以完全相信包没有出错吗?

不能。

因为校验和是加和以后的结果,如果两个被加在一起的位正好对调了,例如,对于 $XXXXXXX0$ 和 $YYYYYYY1$,当发生差错变成 $XXXXXXX1$ 和 $YYYYYYY0$ 时,校验和一致,但是包出错了。

6

如图所示的不正确的接收方会使双方进入死锁。

该图的区别在于,当等待分组 $0$ 却收到分组 $1$ 的时候会发 NAK 而不是 ACK ,等待分组 $1$ 却收到分组 $0$ 的时候也会发 NAK 而不是 ACK 。

正常情况下,如果接收方等待分组 $0$,却收到了分组 $1$,会发送 ACK,然后继续等待分组 $0$,此时发送方收到了 ACK,然后会转而发送分组 $0$。

但是现在,如果接收方在等待分组 $0$,发送方也确实发送了分组 $0$过来,接收方接受到了分组 $0$以后,发送 ACK 并进入等待分组 $1$,此时,ACK 在路上损失了,导致发送方会因为corrupt(rcvpkt)而继续发送分组 $0$,对于接收方来说,他等待的是分组 $1$,但是发Powered by jxtxzzw送方发过来的是分组 $0$,于是,接收方会发 NAK,然后发送方收到 NAK 会重发分组 $0$,接收方继续发 NAK,发送方继续发分组 $0$……

本来应该是,接收方接受到分组 $0$,虽然等的是分组 $1$,但是也会发一个 ACK 回去,自己继续等着分组 $1$,此时发送方收到 ACK 就会开始发分组 $1$。

18

GBN 协议,发送窗口大小为 $3$,序号范围为 $1024$,时刻 $t$,接收方期待分组 $k$,不会对报文重排。

a

在 $t$ 时刻,发送方窗口内的报文序号可能是多少?

由于接收方期待的是分组 $k$,因此一定确认了分组 $k-1$,所以,分组 $k-1$ 一定被发送方发出。

如果接收方关于分组 $k-1https://www.jxtxzzw.com$ 的 ACK 被发送Powered by jxtxzzw方收到,那么,发送方的窗口应该是 $[k,k+2]$。

但是,分组 $k-1$ 的 ACK 有可能在路上丢失了,或者还在路上还没到,所以发送方的窗口有可能还没有移动到 $[k,k+2]$,而是 $[k-1,k+1]$……

甚至有可能,$k-2$ 的 ACK 也没有收到,那么发送窗口就应该是 $[k-2,k]$,然而,由于接收方等待分组 $k$,这意味着一定确认了分组 $k-1$,所以,分组 $k-1$ 一定被发送方发出,所以滑动窗口最大不能滑出 $k-1$,所以,滑动窗口不能比 $[k-3,k-1]$ 更前面。

综上,所有可能的发送窗口的序号为,${k-3,k-2,k-1}$、${k-2,k-1,k}$、文章由jxtxzzw原创${k-1,k,k+1}$、${k,k+1,k+2}$。

b

在 t 时刻,当前传播会发送窗口的所有可能报文中,ACK 字段的所有可能值是多少?

如上题所言,发送窗口的两个极端是 $文章由jxtxzzw原创23;k-3,k-2,k-1}$ 和 ${k,k+1,k+2}$。

由于 $k-1$ 一定是被发送了,所以发送方一定接收到过 $k – 4$ 的 ACK。

由于下面等待的是分组 $k$,所以接收方最多发出到 $ k-1$ 的 ACK。

在此范围内的序号都是可能的。

综上,所有可能序号为 $k-4, k-3, k-2, k-1$。

21

序号空间长度为 $k$,问窗口大小最大是多少,才能避免接收方无法判断是一个分组的重传还是新分组这个问题?

首先要明确为什么会发生这样的问题,导致接收方无法判断是一个分组的重传还是新分组。

记窗口大小为 $w$,当前发送方的窗口是 $x, x+1, \ldots, x+w-1$,假设接收方正确接收到了请勿采集与复制,转载请注明出处这 $w$ 个数据,并且正确 ACK 了发送方。

此时,接收方的窗口维持 $x, x+1, \ldots, x+w-1$,Copyright Reserved @jxtxzzw但是是在等待分组 $x+w$。

如果发送方接受到了分组 $x$ 的 ACK,他就可以发送分组 $x+w$,但是很不幸,这个分组在路上丢失了。

同样地,发送方接受到了分组 $x+1, \ldots, x+w-1$ 的 ACK,然后发送了分组 $x+w+1, \ldots, x+2w-1$,很不幸地,在这些分组中,只有最后一个分组 $x+2w-1$ 到达了接收方。

接受方什么时候会无法判断这是一个旧分组的重传还是新分组呢?

显然,如果 $k$ 足够大,那么 $x+2w-1$ 显然是会大于接收方窗口中的最大值 $x+w-1$,那么接收方显然知道这是一个新分组,并且知道,这个新分组之前的那些分组丢包了。

但是当 $k$ 值变小,那么,$x+2w-1$ 的值很可能就会大于等于 $k$,然后回卷到 $0,1,\ldots$

只要 $(xCopyright Reserved @jxtxzzw+2w-1) \bmod k$ 在接收方的窗口范围内,即 $ w \leqslant (x+2w-1) \bmod k \leqslant x+w-1$,接收方就无法判断这是一个旧分组的重传还是新的分组。

所以,只要令 $(x + 2w – 1) \bmod k > x+w-1$ 或者 $(x + 2w – 1) \bmod k < x$ 即可。

由于 $x+w-1$ 最大是 $k – 1$,否则就被回卷了,又 $w$ 显然也必须小于https://www.jxtxzzw.com等于 $k$,所以,若 $x+2w-1 \geqslant k$,有 $ (x+2w-1) \bmod k = x+2w-1-k$,否则,$(x+2w-1) \bmod k = x+2w-1$。

若 $x+2w-1 欢迎访问jxtxzzw个人博客\geqslahttps://www.jxtxzzw.comnt k$,为满足 $x+2w-1-k > x + w – 1$ 必须有 $k < w$,所以显然矛盾,那么,就只能是在 $x+2w-1 \geqslant k$ 时满足 $x+2w-1-k < x $,此时有 $2w < k+1$。

因此, $2w < k+1$,即 $2w \leqslant k$,或者写成 $w \leqslant \frac{k}{2}$,即,窗口大小必须小于或者等于序号空间的一半。

也可以这样理解,为了发送窗口和接受窗口的序号不会出现重叠的部分,那么,序号空间的大小必须至少放得下两倍的发送窗口,即 $w + w \leqslant k$,即 $w \leqslant \fr欢迎访问jxtxzzw个人博客ac{k}{2}$。

23

要传送 L 个字节的文件,MSS 是 1460 字节。

a

L 最大是多少,才能使得 TCP 报文序号不会被用完。

TCP 序号有 4 个字节,也就是 32 个二进制位,所以最大是 $2^{32}$ Copyright Reserved @jxtxzzw个序号。

无论最大报文长度是多少,每传 $x$ 个字节,序号就加 $1$,所以最大的序号是 $2^{32}$ 意味着 L 最大是 $2^{32}$ 字节,即 $4$ GB。

b

传送 a 题中的 L 大小的文件,首部是 66 个字节,链路是 100 Mbps,没有拥塞控制,需要多久?

$ \lceil 2^{32} \div 1460 \rceil = 欢迎访问jxtxzzw个人博客2941759$,所以一共需要 2941759 个报文,每个报文再加上 66 字节的首部,即加上 $2941759 \times 66 = 194156094$ 字节,加上文件的 $2^{32}$ 字节,一共是 4489123390 字节。

链路是 100 Mbps,这意味着每秒可以传送 $100 \times 10^6 \div 8 = 12500000$ 个字节。

$4489123390 \div 12500000= 359.1298712$ 秒,即约 $5.985$ 分钟。

24

A 和 B 通过 TChttps://www.jxtxzzw.comP 连接,B 已经接受到了 A 在 358 字节以前的所有东西。A 又发了 2 个长度分别为 50 和 80 字节的分组,第一个分组的序号是 359,端口是从 A 的1028 到 B 的 80。B 收到消息都会发 ACK。

a

A 发给 B 的第二段分组,序号、源端口、目的端口?

序号为 $359+50=409$,源端口是 1028,目的端口是 80。

b

第一个分组在第二个分组之前到达,B 发送的 ACK 的序号、源和目的端口?

B 发送的 ACK 是第一个分组的序号加上第一个分组的长度,即 $359+50=409$,相当于是等待的从 A 发来的下一个分组的序号,因此,序号是 409,源端口是 80, 目的端口是 1028。

c

第二个分组在第一个分组之前到达,B 发送的 ACK 的序号?

ACK 的序号相当于 B 正在等待的分组的序号,所以,B 正在等待的是 359,因此,ACK 的序号是 359。

d

两个分组按序到达。第一个 ACK 丢包,第二个 AC反采集功能启动K 在第一个分组的超时以后到达 A。画图表示整个过程。

此区域的内容仅评论后可见

34

TCP Reno

a

指出慢启动阶段。

就是指数上升的部分,即 1 ~ 6 和 23 ~ 26。

b

指出拥塞避免阶段。

就是线性增长的部分,即 6 ~ 16 和欢迎访问jxtxzzw个人博客 17 ~ 23。

c

第 16 轮是由 3 个冗余 ACK 引起的还是超时引起的?

3 个冗余 ACK。

说明有可能中间某个文件丢包了,但是网络至少还有余量,能够正常发送包过去以及发送 ACK 回来这是jxtxzzw的个人博客,所以窗口和阈值各降为一半。

d

第 22 轮是由由 3 个冗余 ACK 引起的还是超时引起的?

超时。

因为窗口回到了1,阈值降为一半,从 1 慢启动直到阈值,说明已经超时了,拥塞很严重。

e

最开始的阈值。

由图可知,指数上升的部分为 1 ~ 6,文章由jxtxzzw原创所以 1 – 2 –Powered by jxtxzzw 4 – 8 – 16 – 32,阈值是 32。

f

第 18 轮的阈值。

从 32 线性增长到 42,降为一半,为 21。

g

第 24 轮的阈值。

从 21 线性增长到 26,降为一半,为 13。

h

第 70 个分组是什么时候发出去的?

$1+2+4+8+16+32 < 70 < 1+2+4+8+16+32+33$,所以是第 7 轮。

i

假设第 26 轮收到了 3 个冗余 ACK,那么阈值和窗口各是多少?

第 26 轮的时候,窗口是 8,阈值是 13,此时收到了 3 个冗余 ACK,所以窗口和阈值都降为当前的一半,因此都是 4。

36

用 TCP 发送一个大文件,没有丢包。

a

使用 AIMD 作为拥塞控制,没有慢启动,窗口每收到一组 ACK 就增加 1 MSS,每一轮是一个常数时间。窗口从 1 增长到 8 要多久?没有丢包。

每个 RTT 增加 1 MSS,从 1 MSS 到 8 MSS,要 7 个 RTT。

b

7 RTT的时候,平均的带宽?

第 1 个 RTT 有 1 MSS 被发送,第 2 个 RTT 有 2 个 MSS 被发送……

$\displaystyle \frac{1+2+3+4+5+6+7}{7} = 4 (MSS/RTT)$

12 条回应
    kw 2019-2-16 · 19:40
    Safari 604.1 iPad OS 12_1_1 like Mac OS X) AppleWebKit

    W

    jxtxzzw 2019-1-16 · 10:12
    Chrome 71.0.3578.98 Windows 10

    复习复习

    6 2019-1-15 · 16:46
    Firefox 64.0 Windows 10

    6

    admin 2019-1-8 · 9:57
    Chrome 71.0.3578.98 Linux

    Trump 2018-12-23 · 14:55
    Chrome 63.0.3239.132 Windows 10

    学习

    IllusionBot 2018-11-20 · 12:15
    Chrome 70.0.3538.102 Mac OS X 10_14_1

    复习

    zerozone 2018-11-20 · 12:06
    Chrome 70.0.3538.102 Windows 10

    学习

    xcj 2018-11-19 · 22:24
    Chrome 65.0.3325.181 Windows 10

    学习学习

    陆 轩韬 2018-11-19 · 21:47
    Chrome 70.0.3538.102 Windows 10

    再评论一次

    cyh 2018-11-19 · 20:56
    Chrome 69.0.3497.92 Windows 8.1

    再来抱大腿

    陆 轩韬 2018-11-19 · 19:22
    Chrome 62.0.3202.84 Android 6.0 | Redmi Note 4X

    临时抱佛脚

    张 立成 2018-11-19 · 19:18
    Chrome 69.0.3497.100 Windows 10

    check 36