计算机网络自顶向下方法-第8版-Chapter2-Problems_计算机网络自顶向下方法第八版答案

前端node资料大全

2089人浏览 · 2024-04-12 20:40:42

前端node资料大全 · 2024-04-12 20:40:42 发布

−

0.0567

−

0.0567

0.0928

0.611

\frac{\Delta}{1 - \Delta \beta} \ = \frac{0.0567}{1 - 16 \times 0.0567} \ = \frac{0.0567}{0.0928} \ = 0.611s

1−ΔβΔ=1−16×0.05670.0567=0.09280.0567=0.611s
因特网时延为3s, 所以总的平均响应时间为:

3.611

3.611s

b

60%的对象在web缓存被命中, 所以直接考虑从web缓存发送对象到客户主机的时延, 即一个对象大小 / 局域网带宽, 这个时延小到可以忽略。

40%的对象要经过因特网到web缓存, 在从web缓存中发送到客户主机

所以, 总的响应时间:

0.6

8.5

100

0.4

(

3.611

8.5

100

)

0.6

8.5

−

0.4

(

3.611

0.0085

)

0.6

0.4

(

3.611

)

1.44

0.6 \times \frac{8.5\times 10^{5}{100\times10}6} + 0.4 \times (3.611+\frac{8.5\times 10^{5}{100\times10}6}) \ = 0.6\times 8.5\times10^{-3} + 0.4 \times (3.611 + 0.0085) \ = 0.6\times 0 + 0.4\times (3.611 + 0) \ = 1.44s

0.6×100×1068.5×105+0.4×(3.611+100×1068.5×105)=0.6×8.5×10−3+0.4×(3.611+0.0085)=0.6×0+0.4×(3.611+0)=1.44s

P10

考虑一条 10 米短链路，某发送方经过它能够以 150 bps 速率双向传输。假定包含数据的分组是 100 000 比特长，仅包含控制（比如 ACK 和握手）的分组是 200 比特长。假定 N 个并行连接每个都获得 1/N 的链路带宽。现在考虑 HTTP 协议，并且假定每个下载对象是 100 kb 长，这些初始下载对象包含 10 个来自相同发送方的引用对象。在这种情况下，经非持续 HTTP 的并行实例的并行下载有意义吗？现在考虑持续 HTTP。你期待这比非持续的情况有很大增益吗？评价并解释你的答案。

令

T_p

Tp表示客户端与服务器之间的单向传播时延, 假设光的传播速率为

3\times10^8 m/s

3×108m/s, 一直链路长度为10m

0.03

T_p = \frac{10}{3\times10^8} = 0.03\mu s

Tp=3×10810=0.03μs
考虑使用非持续 HTTP 请求1个对象后, 然后并行请求10个引用对象的时延, 每个并行连接分到的带宽为15 bps

第一次, 建立一个TCP连接, 获取初始对象

(

200

150

)

(

200

150

)

(

200

150

)

(

100

000

150

)

(\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p + (\frac{100,000}{150}) + T_p

(150200)+Tp+(150200)+Tp+(150200)+Tp+(150100,000)+Tp
然后, 并行建立10个TCP连接, 获取引用对象

(

200

)

(

200

)

(

200

)

(

100

000

)

(\frac{200}{15}) + T_p + (\frac{200}{15}) + T_p + (\frac{200}{15}) + T_p + (\frac{100,000}{15}) + T_p

(15200)+Tp+(15200)+Tp+(15200)+Tp+(15100,000)+Tp
综上, 总的时延为二者相加:

(

200

150

)

(

200

150

)

(

200

150

)

(

100

000

150

)

(

200

)

(

200

)

(

200

)

(

100

000

)

7377

(

)

(\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p + (\frac{100,000}{150}) + T_p \+ (\frac{200}{15}) + T_p + (\frac{200}{15}) + T_p + (\frac{200}{15}) + T_p + (\frac{100,000}{15}) + T_p \ = 7377 + 8T_p \ (s)

(150200)+Tp+(150200)+Tp+(150200)+Tp+(150100,000)+Tp+(15200)+Tp+(15200)+Tp+(15200)+Tp+(15100,000)+Tp=7377+8Tp (s)
如果使用持续 HTTP 进行下载, 先建立一个TCP连接, 再获取初始对象, 再进行10次请求对象操作

(

200

150

)

(

200

150

)

(

200

150

)

(

100

000

150

)

(

200

150

100

000

150

)

7351

(\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p + (\frac{200}{150}) + T_p \+ (\frac{100,000}{150}) + T_p \ + 10 \times (\frac{200}{150} +T_p +\frac{100,000}{150} + T_p) \ = 7351 + 24T_p

(150200)+Tp+(150200)+Tp+(150200)+Tp+(150100,000)+Tp+10×(150200+Tp+150100,000+Tp)=7351+24Tp
对比持续连接与非持续连接, 发现持续连接再短距离的链路中, 并没有比非持续连接响应的快很多。

P11

考虑在前一个习题中引出的情况。现在假定该链路由 Bob 和 4 个其他用户共享。 Bob 使用并行非持续 HTTP ，而其他 4 个用户使用无并行非持续 HTTP。

a. Bob 的并行连接能够帮助他更快地得到 Web 页面吗？

b. 如果所有 5 个用户打开 5 个非持续 HTTP 并行实例，那么 Bob 的并行连接仍将是有益的吗？为什么？

a

Bob拥有比其他人跟多的连接, 所以会获得比其他人更多的带宽

b

当所有人都使用持续的并行下载时, 如果Bob不使用, 他将会获得比其他用户更少的带宽。

P12

写一个简单的 TCP 程序，使服务器接收来自客户的行为并将其打印在服务器的标准输出上，（可以通过修改本书中的 TCPServer.py 程序来实现上述任务。）编译并运行你的程序。在另一台有浏览器的机器上，设置浏览器的代理服务器为你正在运行服务器程序的机器，同时适当地配置端口号。这时你的浏览器向服务器发送 GET 请求报文，你的服务器应当在其标准输出上显示该报文。使用这个平台来确定你的浏览器是否对本地缓存的对象产生了条件 GET 报文。

python文件

from socket import \*

serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)
serverSocket.bind(('', serverPort))
# 开始聆听请求, 最大为1
serverSocket.listen(1)
print("The server is ready to recive")
# 当客户端请求连接时, 接收并分配一个专用的新的socket
connectionSocket, addr = serverSocket.accept()
while True:
    # 此后都是新的socket与用户相互发送数据
    sentenct = connectionSocket.recv(10240)
    print('From Server:', sentenct, '\n')
    connectionSocket.close()

在windows本地查询ip

ipconfig

得到ipv4的ip

192.168.118.1

在Linux主机上设置http和https代理服务器

在Linux端打开浏览器, 获取到GET报文

From Server: b'GET http://detectportal.firefox.com/canonical.html HTTP/1.1\r\n
Host: detectportal.firefox.com\r\n
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0\r\n
Accept: */*\r\n
Accept-Language: en-US,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Cache-Control: no-cache\r\n
Pragma: no-cache\r\n
Connection: keep-alive\r\n\r\n'

没有发现If-Modified-Since:首部, 判断浏览器对对象没有使用条件GET

P13

考虑经HTTP/2发送一个Web页面，该页面由1个视频片段和5幅图像组成。假定该视频片段要传输2000帧,而每幅图像有3帧。

a.如果所有视频片段首先发送而没有交错，所有5幅图像发送完需要多少“帧时间"?

b.如果帧是交错的,所有5幅图像发送完需要多少帧时间?

a

2000

2015

2000 + 3 \times 5 = 2015

2000+3×5=2015

把帧时间看作发送一个帧所需要的时间, 因为是先发送视频,再发生5个图像, 所以当图像发生完毕后, 所需帧时间有2015个

b

如果帧是交错发送的, 并且先发送视频的帧, 则依次在每一个帧时间内发送视频, 图像1, 图像2, 图像3, 图像4, 图像5的一个帧, 所以每6个帧时间将所有对象的一帧发出, 因为每个对象有3个帧, 所以经过18个帧时间将所有5个图像的所有帧发出

P14

考虑习题P13中的Web页面。此时应用HTTP/2优先权。假定为所有图像赋予高于视频片段的优先权，并且为第一幅图像赋予高于第二幅图像的优先权，为第二幅图像赋予高于第三幅图像的优先权,等等。第二幅图像发完需要多少帧时间?

服务器发送响应报文帧的优先权情况

picture1 > picture2 > picture3 > picture4 > picture5 > video

当picture1的3帧没有被发送完之前, 它的优先权一直是最高的, 所以picture1发送完后才会发送picture2, 所以发送完picture2需要

2\times3=6

2×3=6个帧时间

P15

SMTP 中的 MAIL FROM 与该邮件报文自身的 From: 之间有什么不同？

SMTP中的MAIL FROM:是来自SMTP客户端的消息，用于标识向SMTP服务器发送邮件消息的发件人。邮件消息本身的 From:不是SMTP消息，而只是邮件消息正文中的一行

在电子邮件中，有两个不同的 “From” 地址，一个是SMTP中的 “MAIL FROM”，是与邮件服务器通信的语法格式, 指定了发送方的邮件地址, 但不一定是实际的邮件地址, 另一个是邮件报文头部中的 “From:”, 它指定了邮件的实际发件人的地址。

SMTP中的 MAIL FROM：
当你通过SMTP（Simple Mail Transfer Protocol）发送电子邮件时，邮件传输始于客户端（发送方）将邮件发送到邮件服务器。在这个过程中，客户端会使用类似以下命令的语法与服务器进行通信：

MAIL FROM: <sender@example.com>

这个命令指定了电子邮件的发件人地址，也就是邮件从哪里发送出去。注意，这个地址可能与邮件报文头部中的 “From:” 地址不一致，因为邮件服务器可以允许你发送电子邮件，但可能并不是你实际的邮件地址。
2. 邮件报文头部中的 From:：
在电子邮件的报文结构中，有一组头部字段用于描述邮件的各个方面，包括发件人、收件人、主题等等。其中一个字段就是 “From:”，它指定了邮件的实际发件人的地址。这个地址通常是邮件的真实发件人，接收者可以看到这个地址，并且可以通过它回复邮件。

总结来说，SMTP中的 “MAIL FROM” 地址是在电子邮件传输过程中指定的发件人地址，而邮件报文头部中的 “From:” 地址则是显示在邮件中，表示邮件的实际发件人。这两个地址可能相同，但在某些情况下（例如，代理服务器、转发），它们可能会有所不同。

P16

SMTP 是怎样标识一个报文体结束的？HTTP 是怎样做的呢？HTTP 能够使用与 SMTP 标识一个报文体结束相同的方法吗？试解释。

SMTP 使用一个只包含 . 的行来标示邮件报文体的结束。

HTTP 使用响应报文中的 Content-Length:首部行来决定报文体在什么地方结束。

HTTP 不能够使用与 SMTP 同样的方法标识一个报文体结束，因为 SMTP 的报文体只允许是 7-bit 的 ASCII，而 HTTP 的报文体可以包含二进制数据。

P17

阅读用于 SMTP 的 RFC 5321。MTA 代表什么？

考虑下面收到的垃圾邮件（从一份真实垃圾邮件修改得到）。

From - Fri Nov 07 13:41:30 2008

Return-Path: <tennis5@pp33head.com>

Received: from barmail.cs.umass.edu (barmail.cs.umass.edu [128.119.240.3]) by cs.umass.edu (8.13.1/8.12.6) for <hg@cs.umass.edu>; Fri, 7 Nov 2008 13:27:10 -0500
PROBLEMS 175

Received: from asusus-4b96 (localhost [127.0.0.1]) by barmail.cs.umass.edu (Spam Firewall) for <hg@cs.umass.edu>; Fri, 7 Nov 2008 13:27:07 -0500 (EST)
Received: from asusus-4b96 ([58.88.21.177]) by barmail.cs.umass.edu for <hg@cs.umass.edu>; Fri,
07 Nov 2008 13:27:07 -0500 (EST)
❗❗
Received: from [58.88.21.177] by inbnd55.exchangeddd.com; Sat, 8 Nov 2008 01:27:07 +0700 From: "Jonny" <tennis5@pp33head.com>

To: <hg@cs.umass.edu>

Subject: How to secure your savings

假定这封垃圾邮件的唯一始作俑者是恶意的，而其他主机是诚实的，指出产生了这封垃圾邮件的恶意主机。

RFC 5321 2.3.3 Mail Agents and Message Stores

Additional mail system terminology became common after RFC 821 was published and, where convenient, is used in this specification.  
❗❗
In particular, SMTP servers and clients provide a mail transport service and therefore act as "Mail Transfer Agents" (MTAs).  
"Mail User Agents" (MUAs or UAs) are normally thought of as the sources and targets of mail.  At the source, an MUA might collect mail to be transmitted from a user and hand it off to an MTA; the final ("delivery") MTA would be thought of as handing the mail off to an MUA (or at least transferring responsibility to it, e.g., by depositing the message in a "message store").  However, while these terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs often do not accurately match common, and conforming, practices with Internet mail.  Hence, the reader should be cautious about inferring the strong relationships and responsibilities that might be implied if these terms were used elsewhere.

MTA(Mail Transfer Agents)表示邮件传输代理, 主机将报文发送到MTA, 然后经过一系列MTA到达收件人的邮件阅读器。

我们看到该垃圾邮件遵循MTA链。诚实的MTA应报告其在何处接收邮件。请注意，在此报文中, asusus-4b96 ([58.88.21.177])不会报告其收到电子邮件的位置。由于我们假设只有发起者是不诚实的，因此asusus-4b96([58.88.21.177])一定是发起者

P18

如题:

a. 什么是whois数据库?

b. 使用因特网上的各种 whois 数据库，获得两台DNS服务器的名字。指出你使用的是哪个whois 数据库。

c. 你本地机器上使用nslookup向3台DNS服务器发送DNS查询:你的本地DNS服务器和两台你在(b)中发现的 DNS服务器。尝试对类型A、NS和MX报告进行查询。总结你的发现。

d. 使用nslookup找出一台具有多个IP地址的Web服务器。你所在的机构（学校或公司)的Web服务器具有多个IP地址吗?

e. 使用ARIN whois数据库,确定你所在大学使用的IP地址范围。

f. 描述一个攻击者在发动攻击前，能够怎样利用whois 数据库和nslookup 工具来执行对一个机构的侦察。

g. 讨论为什么 whois 数据库应当为公众所用。

a

对于给定输入的域名（例如ccn.com) 、IP地址或网络管理员名称，可以使用whois数据库来定位相应的注册商、whois服务器、DNS服务器等

WHOIS（发音为"who is"）数据库是一个用于查询和检索互联网域名和IP地址相关信息的公共数据库。它存储了关于域名所有者、域名注册商、域名注册日期、到期日期、域名服务器信息等的数据。通过查询WHOIS数据库，你可以获取有关特定域名或IP地址的详细信息。

主要的用途包括：

域名注册信息查询：你可以使用WHOIS来查找某个域名的所有者信息，注册商信息，注册日期，以及域名到期日期等。这对于了解域名的归属权和状态非常有用。
网络安全和欺诈检测：WHOIS数据库使得网络管理员和安全专家能够追踪到不良行为，如网络攻击、垃圾邮件传播等。通过查看域名的注册信息，可以识别不法行为背后的责任人。
联系域名所有者：如果你想与一个域名的所有者取得联系，你可以使用WHOIS数据库中提供的联系信息。
了解域名服务器信息：WHOIS还提供了域名的DNS服务器信息，这对于网络管理员来说非常有用，因为他们可以使用这些信息来调试域名解析问题。
商业用途：一些公司和个人可能会使用WHOIS数据来开展业务活动，比如市场调研、销售、广告等。

需要注意的是，尽管WHOIS数据库是公开的，但出于隐私和安全考虑，一些域名注册商和所有者可能会选择隐藏或保护部分或全部的注册信息。这使得查询到的信息可能不是完全准确或详尽的。

b

whois 数据库查询网址: https://who.is

Domain Name: BAIDU.COM 
Registrar WHOIS Server: whois.markmonitor.com
Creation Date: 1999-10-11T11:05:17Z
Name Server: NS1.BAIDU.COM
Name Server: NS2.BAIDU.COM
Name Server: NS3.BAIDU.COM
Name Server: NS4.BAIDU.COM
Name Server: NS7.BAIDU.COM

c

在Ubuntu安装nslookup: sudo apt-get install dnsutils

没有指定域名的dns服务器就会使用本地的dns服务器, 发现本地的DNS服务器地址为127.0.0.53#53

wxc@wxc-virtual-machine:~$ nslookup www.baidu.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
www.baidu.com	canonical name = www.a.shifen.com.
Name:	www.a.shifen.com
Address: 36.155.132.31
Name:	www.a.shifen.com
Address: 36.155.132.55

查询a记录

wxc@wxc-virtual-machine:~$ nslookup -type=a baidu.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	baidu.com
Address: 39.156.66.10
Name:	baidu.com
Address: 110.242.68.66

查询ns记录

wxc@wxc-virtual-machine:~$ nslookup -type=ns baidu.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
baidu.com	nameserver = ns2.baidu.com.
baidu.com	nameserver = ns7.baidu.com.
baidu.com	nameserver = ns4.baidu.com.
baidu.com	nameserver = dns.baidu.com.
baidu.com	nameserver = ns3.baidu.com.

Authoritative answers can be found from:

查询mx记录

wxc@wxc-virtual-machine:~$ nslookup -type=mx baidu.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
baidu.com	mail exchanger = 10 mx.maillb.baidu.com.
baidu.com	mail exchanger = 20 mx1.baidu.com.
baidu.com	mail exchanger = 15 mx.n.shifen.com.
baidu.com	mail exchanger = 20 mx50.baidu.com.
baidu.com	mail exchanger = 20 usmx01.baidu.com.
baidu.com	mail exchanger = 20 jpmx.baidu.com.

Authoritative answers can be found from:

查询指定为NS1.BAIDU.COM的DNS服务器, 发现DNS服务器地址为110.242.68.134#53, 并且查询A记录

wxc@wxc-virtual-machine:~$ nslookup -type=a baidu.com NS1.BAIDU.COM
Server:		NS1.BAIDU.COM
Address:	110.242.68.134#53

Name:	baidu.com
Address: 39.156.66.10
Name:	baidu.com
Address: 110.242.68.66

查询NS记录

wxc@wxc-virtual-machine:~$ nslookup -type=ns baidu.com NS1.BAIDU.COM
Server:		NS1.BAIDU.COM
Address:	110.242.68.134#53

baidu.com	nameserver = dns.baidu.com.
baidu.com	nameserver = ns4.baidu.com.
baidu.com	nameserver = ns2.baidu.com.
baidu.com	nameserver = ns3.baidu.com.
baidu.com	nameserver = ns7.baidu.com.

查询MX记录

wxc@wxc-virtual-machine:~$ nslookup -type=mx baidu.com NS1.BAIDU.COM
Server:		NS1.BAIDU.COM
Address:	110.242.68.134#53

baidu.com	mail exchanger = 20 usmx01.baidu.com.
baidu.com	mail exchanger = 10 mx.maillb.baidu.com.
baidu.com	mail exchanger = 20 jpmx.baidu.com.
baidu.com	mail exchanger = 15 mx.n.shifen.com.
baidu.com	mail exchanger = 20 mx1.baidu.com.
baidu.com	mail exchanger = 20 mx50.baidu.com.

d

$ nslookup -type=a baidu.com NS3.BAIDU.COM
Server:		NS3.BAIDU.COM
Address:	36.152.45.193#53

Name:	baidu.com
Address: 110.242.68.66
Name:	baidu.com
Address: 39.156.66.10

可以得知baidu.com的IP地址至少有110.242.68.66, 39.156.66.10

e

ARIN whois

f

whois数据库可以让我们知道一个域名的DNS主机名, 和IP范围

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D2xfDwBI-1693138873977)(Practice.assets/image-20230825082845550.png)]

通过nslookup可以通过主机名获取对应的IP地址, 让我们可以进行攻击

$ nslookup -type=any baidu.com NS1.BAIDU.COM

Server:		NS1.BAIDU.COM
Address:	110.242.68.134#53

baidu.com
	origin = dns.baidu.com
	mail addr = sa.baidu.com
	serial = 2012147132
	refresh = 300
	retry = 300
	expire = 2592000
	minimum = 7200
baidu.com	text = "v=spf1 include:spf1.baidu.com include:spf2.baidu.com include:spf3.baidu.com include:spf4.baidu.com mx ptr -all"
baidu.com	text = "9279nznttl321bxp1j464rd9vpps246v"
baidu.com	text = "google-site-verification=GHb98-6msqyx_qqjGl5eRatD3QTHyVB6-xQ3gJB5UwM"
baidu.com	text = "_globalsign-domain-verification=qjb28W2jJSrWj04NHpB0CvgK9tle5JkOq-EcyWBgnE"
baidu.com	mail exchanger = 20 usmx01.baidu.com.
baidu.com	mail exchanger = 15 mx.n.shifen.com.
baidu.com	mail exchanger = 10 mx.maillb.baidu.com.
baidu.com	mail exchanger = 20 mx1.baidu.com.
baidu.com	mail exchanger = 20 jpmx.baidu.com.
baidu.com	mail exchanger = 20 mx50.baidu.com.
Name:	baidu.com
Address: 39.156.66.10
Name:	baidu.com
Address: 110.242.68.66
baidu.com	nameserver = ns4.baidu.com.
baidu.com	nameserver = ns3.baidu.com.
baidu.com	nameserver = ns2.baidu.com.
baidu.com	nameserver = ns7.baidu.com.
baidu.com	nameserver = dns.baidu.com.

g

通过分析攻击数据包的源地址，受害者可以使用whois来获取有关攻击来自的域的信息，并可能告知源域的管理员

P19

在本习题中，我们使用在 Unix 和 Linux 主机上可用的 dig 工具来探索 DNS 服务器的等级结构。图 2-21 讲过，在 DNS 等级结构中较高的 DNS 服务器授权对该等级结构中较低的 DNS 服务器的 DNS 请求，这是通过向 DNS 客户发送回那台较低层次的 DNS 服务器的名字来实现的。先阅读 dig 的帮助页，再回答下列问题。

a. 从一台根 DNS 服务器（从根服务器 [a-m].root-server.net 之一）开始，通过使用 dig 得到你所在系的 Web 服务器的 IP 地址，发起一系列查询。显示回答你的查询的授权链中的 DNS 服务器的名字列表。

b. 对几个流行 Web 站点如 google.com、yahoo.com 或 amazon.com，重复上一小题。

dig -h显示dig的帮助页

Usage:  dig [@global-server] [domain] [q-type] [q-class] {q-opt}
            {global-d-opt} host [@local-server] {local-d-opt}
            [ host [@local-server] {local-d-opt} [...]]
Where:  domain	  is in the Domain Name System
        q-class  is one of (in,hs,ch,...) [default: in]
        q-type   is one of (a,any,mx,ns,soa,hinfo,axfr,txt,...) [default:a]
                 (Use ixfr=version for type ixfr)
        q-opt    is one of:
                 -4                  (use IPv4 query transport only)
                 -6                  (use IPv6 query transport only)
                 -b address[#port]   (bind to source address/port)
                 -c class            (specify query class)
                 -f filename         (batch mode)
                 -k keyfile          (specify tsig key file)
                 -m                  (enable memory usage debugging)
                 -p port             (specify port number)
                 -q name             (specify query name)
                 -r                  (do not read ~/.digrc)
                 -t type             (specify query type)
                 -u                  (display times in usec instead of msec)
                 -x dot-notation     (shortcut for reverse lookups)
                 -y [hmac:]name:key  (specify named base64 tsig key)
        d-opt    is of the form +keyword[=value], where keyword is:
                 +[no]aaflag         (Set AA flag in query (+[no]aaflag))
                 +[no]aaonly         (Set AA flag in query (+[no]aaflag))
                 +[no]additional     (Control display of additional section)
                 +[no]adflag         (Set AD flag in query (default on))
                 +[no]all            (Set or clear all display flags)
                 +[no]answer         (Control display of answer section)
                 +[no]authority      (Control display of authority section)
                 +[no]recurse        (Recursive mode (+[no]rdflag))

基本用法

dig [@global-server] [domain]

a

非递归从根DNS服务器a.root-servers.net查询it.chd.edu.cn的IP

如果递归dig @a.root-servers.net it.chd.edu.cn就直接查到了

查询根DNS服务器

$ dig @a.root-servers.net it.chd.edu.cn  +norec

结果, 获得cn顶级域的列表

;; AUTHORITY SECTION:
cn.			172800	IN	NS	c.dns.cn.
cn.			172800	IN	NS	b.dns.cn.
cn.			172800	IN	NS	ns.cernet.net.
cn.			172800	IN	NS	e.dns.cn.
cn.			172800	IN	NS	a.dns.cn.
cn.			172800	IN	NS	d.dns.cn.

继续查询其中一个cn顶级域DNS服务器

$ dig @c.dns.cn. it.chd.edu.cn  +norec

得到edu.cn的DNS列表

;; AUTHORITY SECTION:
edu.cn.			172800	IN	NS	deneb.dfn.de.
edu.cn.			172800	IN	NS	dns2.edu.cn.
edu.cn.			172800	IN	NS	ns2.cernet.net.
edu.cn.			172800	IN	NS	ns2.cuhk.hk.
edu.cn.			172800	IN	NS	dns.edu.cn.

继续查询edu.cn域的DNS服务器

$ dig @dns2.edu.cn. it.chd.edu.cn  +norec

得到chde.edu.cn的权威DNS服务器的列表

;; AUTHORITY SECTION:
chd.edu.cn.		172800	IN	NS	dns2.chd.edu.cn.
chd.edu.cn.		172800	IN	NS	dns1.chd.edu.cn.

最后查询权威DNS服务器

$ dig @dns2.chd.edu.cn. it.chd.edu.cn  +norec

结果发现it.chd.edu.cn.是lxsy.chd.edu.cn.的别名

该别名有A记录, 所以it.chd.edu.cn.的IP地址为202.117.64.155

;; ANSWER SECTION:
it.chd.edu.cn.		600	IN	CNAME	lxsy.chd.edu.cn.
lxsy.chd.edu.cn.	600	IN	A	202.117.64.155

b

$ dig @a.root-servers.net baidu.com  +norec

结果得到com顶级域的DNS服务器名称

...
; AUTHORITY SECTION:
com.			172800	IN	NS	e.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
com.			172800	IN	NS	j.gtld-servers.net.
com.			172800	IN	NS	m.gtld-servers.net.
com.			172800	IN	NS	i.gtld-servers.net.
com.			172800	IN	NS	f.gtld-servers.net.
com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	g.gtld-servers.net.
com.			172800	IN	NS	h.gtld-servers.net.
com.			172800	IN	NS	l.gtld-servers.net.
com.			172800	IN	NS	k.gtld-servers.net.
com.			172800	IN	NS	c.gtld-servers.net.
com.			172800	IN	NS	d.gtld-servers.net.
...

在随便选一个comDNS服务器继续查询

$ dig @e.gtld-servers.net. baidu.com  +norec

结果为baidu.com的权威域名服务器

;; AUTHORITY SECTION:
baidu.com.		172800	IN	NS	ns2.baidu.com.
baidu.com.		172800	IN	NS	ns3.baidu.com.
baidu.com.		172800	IN	NS	ns4.baidu.com.
baidu.com.		172800	IN	NS	ns1.baidu.com.
baidu.com.		172800	IN	NS	ns7.baidu.com.

在随便选一个baidu的权威DNS服务器继续查询

得到最终结果

;; ANSWER SECTION:
baidu.com.		600	IN	A	110.242.68.66
baidu.com.		600	IN	A	39.156.66.10

发现与直接使用dig baidu.com结果一致

P20

假定你能够访问所在系的本地 DNS 服务器中的缓存。你能够提出一种方法来粗略地确定在你所在系的用户中最为流行的 Web 服务器（你所在系以外）吗？解释原因。

我们可以对 DNS 缓存进行周期性的快照，在缓存中出现的最频繁的站点就是最为流行的 Web 服务器。因为大部分用户都对此站点感兴趣，所以对它的 DNS 查询就更为频繁，所以在缓存中出现得更频繁。

对某个站点的缓存频率越高, 说明站点的DNS查询越频繁, 说明可会访问该站点频繁, 说明该站点在用户中受欢迎

P21

假设你所在系具有一台用于系里所有计算机的本地 DNS 服务器。你是普通用户（即你不是网络/系统管理员）。你能够确定是否在几秒钟前从你系里的一台计算机可能访问过一台外部 Web 站点吗？解释原因。

可以确定。可以使用dig在本地DNS服务器查询那个外部站点, 如果query time 为 0ms 表示该站点的A记录已经缓存到了本地DNS服务器, 否则如果query time很大, 则说明在我之前没有人访问过那个外部站点

$ dig cnn.com

;; Query time: 11 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 25 10:14:16 CST 2023
;; MSG SIZE  rcvd: 100

几秒后再次访问

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Fri Aug 25 10:15:25 CST 2023
;; MSG SIZE  rcvd: 100

P22

考虑向 N 个对等方分发 F = 20 Gb 的一个文件。该服务器具有

u

s

u_s

us = 30 Mbps 的上载速率，每个对等方具有

d

i

d_i

di = 2 Mbps 的下载速率和上载速率 u。对于 N = 10、100 和 1000 并且 u = 300 kbps、700 kbps 和 2 Mbps，对于 N 和 u 的每种组合会指出确定最小分发时间的图表。需要分别针对客户-服务器分发和 P2P 分发两种情况制作。

C-S

最小分发事件

{

}

{

102

}

{

1024

}

1024

}

D_{cs} = max{\frac{NF}{u_s}, \frac{F}{d_{min}}} \ = max{N\frac{20\times1024^{3}{30\times1024}2}, \frac{20\times1024^3}{2\times 1024^2}} \ = max{N \frac{2\times1024}{3}}, 10\times1024} \

Dcs=max{usNF,dminF}=max{N30×1024220×10243,2×1024220×10243}=max{N32×1024},10×1024}
因为在C-S体系结构下, 对等方不用上传, 所以

D_{cs}

Dcs与u无关

N\u	300kbps	700kbps	2Mbps
10	10240	10240	10240
100	68266.67	68266.67	68266.67
100	682666.67	682666.67	682666.67

P2P

最小分发时间

{

∑

}

{

102

∑

}

{

1024

10240

102

∑

}

D_{P2P} = max{\frac{F}{u_s}, \frac{F}{d_i}, \frac{NF}{u_s + \sum\limits_{i = 1}^{N}u_i}} \ = max{\frac{20\times1024^{3}{30\times1024}2}, \frac{20\times1024^3}{2\times 1024^2}, N\frac{20\times1024^{3}{30\times1024}2 + \sum\limits_{i = 1}^{N}u_i}} \ = max{\frac{2\times1024}{3}, 10240, N\frac{20\times1024^{3}{30\times1024}2 + \sum\limits_{i = 1}^{N}u_i}} \

DP2P=max{usF,diF,us+i=1∑NuiNF}=max{30×1024220×10243,2×1024220×10243,N30×10242+i=1∑Nui20×10243}=max{32×1024,10240,N30×10242+i=1∑Nui20×10243}

300

1024

N = 10, u_i = 300kbps, D_{P2P} = 1024

N=10,ui=300kbps,DP2P=1024

100

700

100

102

100

(

300

1024

)

102

}

102

100

(

300

1024

)

102

}

N = 100, u_i = 700kbps\ D_{P2P} = 100\frac{20\times1024^{3}{30\times1024}2 + 100 \times(300/1024)\times1024^2}} \ D_{P2P} = \frac{2\times10^3\times10243}{30\times1024^2 + 100 \times(300/1024)\times1024^2}} \

N=100,ui=700kbpsDP2P=10030×10242+100×(300/1024)×1024220×10243}DP2P=30×10242+100×(300/1024)×102422×103×10243}

N\u	300kbps	700kbps	2Mbps
10	10240	10240	10240
100	34538.67	20821.33	10240
100	63412	28700	10240

P23

考虑使用一种客户-服务器体系结构向 N 个对等方分发一个 F 比特的文件。假定一种流体模型，即某服务器能够同时向多个对等方传输，只要组合速率不超过

u

s

u_s

us，则以不同的速率向每个对等方传输。

a. 假定$ u_s/N \le d_{min}$。定义一个具有

N

F

/

u

s

NF/u_s

NF/us 分发时间的分发方案。

b. 假定

u

s

/

N

≥

d

m

i

n

u_s/N \ge d_{min}

us/N≥dmin。定义一个具有

F

/

d

m

i

n

F/d_{min}

F/dmin 分发时间的分发方案。

c. 得出最小分发时间通常是由

max

⁡

{

N

F

/

u

s

,

F

/

d

m

i

n

}

\max{ NF/us, F/d_{min} }

max{NF/us,F/dmin} 所决定的讨论。

≥

{

}

D_{cs} \ge max{\frac{NF}{u_s}, \frac{F}{d_{min}}} \

Dcs≥max{usNF,dminF}

a

分发方案:

服务器并行地以速率

u_s/N

us/N发送文件, 因为

≤

u_s/N \le d_{min}

us/N≤dmin, 所以客户端可以以速率

u_s/N

us/N接受文件, 接受整个文件的时间是

(

)

F/(u_s/ N) = NF / u_s

F/(us/N)=NF/us, 因为是并行的, 所以总的时间也是

NF / u_s

NF/us

随着

u_s/ N

us/N越来越小于

d_{min}

dmin,

D_{CS}

DCS越来越大于

NF/u_s

NF/us

所以

≥

D_{CS} \ge NF/ u_S

DCS≥NF/uS

b

服务器并行地以速率

u_s/N

us/N发送文件, 因为服务器传输速率大于客户端接收速率:

≥

u_s/N \ge d_{min}

us/N≥dmin, 所以最后一个客户端只能以速率

d_{min}

dmin接受文件, 所以总的花费时间等于N个并行传输链路中最慢的费时:

{

}

F / min{d_i} = F / d_{min}

F/min{di}=F/dmin

c

我们已知

≥

{

}

D_{cs} \ge max{\frac{NF}{u_s}, \frac{F}{d_{min}}} \

Dcs≥max{usNF,dminF}
可以得到

≥

D_{CS} \ge NF / u_s

DCS≥NF/us

又由(a)可知

≤

D_{CS} \le NF/u_s

DCS≤NF/us, 所以, 当

≤

u_s/ N \le d_{min}

us/N≤dmin, 有

D_{CS} = NF / u_s

DCS=NF/us

由(b)可知

≥

D_{CS} \ge F / d_{min}

DCS≥F/dmin, 所以, 当

≥

u_s/ N \ge d_{min}

us/N≥dmin, 有

D_{CS} = F / d_{min}

DCS=F/dmin

综上, 在N个并行发送情况下, 总的最小分发时延可以取到

{

}

D_{cs} = max{\frac{NF}{u_s}, \frac{F}{d_{min}}} \

Dcs=max{usNF,dminF}

P24

考虑虑使用 P2P 体系结构向 N 个用户分发 F 比特的一个文件。假定一种流体模型。为了简化起见，假定

d

m

i

n

d_{min}

dmin 很大，因此对等方下载带宽不会成为瓶颈。

a. 假定

u

s

≤

(

u

s

u

1

.

.

.

u

n

)

/

N

u_s \le (u_s + u_1 + … + u_n)/N

us≤(us+u1+…+un)/N。定义一个具有

F

/

u

s

F/u_s

F/us 分发时间的分发方案。

b. 假定

u

s

≥

(

u

s

u

1

.

.

.

u

n

)

/

N

u_s \ge (u_s + u_1 + … + u_n)/N

us≥(us+u1+…+un)/N。定义一个具有

N

F

/

(

u

s

u

1

.

.

.

u

n

)

NF/(u_s + u_1 + … + u_n)

NF/(us+u1+…+un) 分发时间的分发方案。

c. 得出最小分发时间通常是由

max

⁡

{

F

/

u

s

,

N

F

/

(

u

s

u

1

.

.

.

u

n

)

}

\max{F/u_s, NF/(u_s + u_1 + … + u_n)}

max{F/us,NF/(us+u1+…+un)} 所决定的结论。

由于假定

d_{min}

dmin 很大, 所以

≥

{

∑

}

D_{P2P} \ge max{\frac{NF}{u_s + \sum\limits_{i = 1}^{N}u_i}, \frac{F}{u_s}} \

DP2P≥max{us+i=1∑NuiNF,usF}
令

∑

u = \sum\limits_{i = 1}^{N}u_i

u=i=1∑Nui

a

分发方案:

由假设:

≤

(

)

≤

(

−

)

≤

(

−

)

≤

(

−

)

u_s \le (u + u_s) / N \ u_s \le u / N + u_s/ N \ u_s(1-1/N) \le u /N \ u_s(N -1) \le u \ u_s \le u / (N - 1)

us≤(u+us)/Nus≤u/N+us/Nus(1−1/N)≤u/Nus(N−1)≤uus≤u/(N−1)

分发方案:

将文件分为N块, 每块大小为

(

)

(u_i/u)F

(ui/u)F, (容易看出

∑

\sum\limits_{i = 1}^{N} \frac{u_i}{u}F = F/u\sum\limits_{i=1}^{N}u_i = F

i=1∑NuuiF=F/ui=1∑Nui=F)服务器并行地以速率

r_i = \frac{u_i}{u}u_s

ri=uuius将第i块分发给第i个对等方, 第i个对等方要并行地给其它N-1个对等方以速率

r_i

ri发送块。所以第i个对等方的总发送速率为

(

−

)

(N -1)r_i

(N−1)ri

(

−

)

(

−

)

(

)

≤

(N - 1)r_i = (N - 1)(u_su_i)/u \le u_i

(N−1)ri=(N−1)(usui)/u≤ui
上式满足假设, 所以每个对等方的发送速率可取

(

−

)

(N -1)r_i

(N−1)ri

第i个对等方总接收速率(接收服务器的加接收其它N-1个对等方的比特速率)

∑

≠

r_i + \sum\limits_{j \ne i}r_j = u_s

ri+j=i∑rj=us
所以每个对等方在

F/u_s

F/us时刻接收到该文件的所有块

b

由假设

≥

(

)

u_s \ge (u + u_s) / N \

us≥(u+us)/N
令

(

−

)

−

(

−

)

r_i = u_i/(N - 1), r_{N + 1} = \frac{u_s - u/(N-1)}{N}

ri=ui/(N−1),rN+1=Nus−u/(N−1)

分发方案:

将文件分成N+1块, 服务器先并行地将N块中的第i块分发给第i个对等方, 然后每个对等方以速率

r_i

ri将所持有的块分发给其余N-1个对等方, 同时服务器将第N+1块以速率

r_{N+1}

rN+1并行分发给N个对等方, 此时这些对等方不用分发块

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Linux运维工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Linux运维知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加VX：vip1024b （备注Linux运维获取）

,

N

F

/

(

u

s

u

1

.

.

.

u

n

)

}

\max{F/u_s, NF/(u_s + u_1 + … + u_n)}

max{F/us,NF/(us+u1+…+un)} 所决定的结论。

由于假定

d_{min}

dmin 很大, 所以

≥

{

∑

}

D_{P2P} \ge max{\frac{NF}{u_s + \sum\limits_{i = 1}^{N}u_i}, \frac{F}{u_s}} \

DP2P≥max{us+i=1∑NuiNF,usF}
令

∑

u = \sum\limits_{i = 1}^{N}u_i

u=i=1∑Nui

a

分发方案:

由假设:

≤

(

)

≤

(

−

)

≤

(

−

)

≤

(

−

)

u_s \le (u + u_s) / N \ u_s \le u / N + u_s/ N \ u_s(1-1/N) \le u /N \ u_s(N -1) \le u \ u_s \le u / (N - 1)

us≤(u+us)/Nus≤u/N+us/Nus(1−1/N)≤u/Nus(N−1)≤uus≤u/(N−1)

分发方案:

将文件分为N块, 每块大小为

(

)

(u_i/u)F

(ui/u)F, (容易看出

∑

\sum\limits_{i = 1}^{N} \frac{u_i}{u}F = F/u\sum\limits_{i=1}^{N}u_i = F

i=1∑NuuiF=F/ui=1∑Nui=F)服务器并行地以速率

r_i = \frac{u_i}{u}u_s

ri=uuius将第i块分发给第i个对等方, 第i个对等方要并行地给其它N-1个对等方以速率

r_i

ri发送块。所以第i个对等方的总发送速率为

(

−

)

(N -1)r_i

(N−1)ri

(

−

)

(

−

)

(

)

≤

(N - 1)r_i = (N - 1)(u_su_i)/u \le u_i

(N−1)ri=(N−1)(usui)/u≤ui
上式满足假设, 所以每个对等方的发送速率可取

(

−

)

(N -1)r_i

(N−1)ri

第i个对等方总接收速率(接收服务器的加接收其它N-1个对等方的比特速率)

∑

≠

r_i + \sum\limits_{j \ne i}r_j = u_s

ri+j=i∑rj=us
所以每个对等方在

F/u_s

F/us时刻接收到该文件的所有块

b

由假设

≥

(

)

u_s \ge (u + u_s) / N \

us≥(u+us)/N
令

(

−

)

−

(

−

)

r_i = u_i/(N - 1), r_{N + 1} = \frac{u_s - u/(N-1)}{N}

ri=ui/(N−1),rN+1=Nus−u/(N−1)

分发方案:

将文件分成N+1块, 服务器先并行地将N块中的第i块分发给第i个对等方, 然后每个对等方以速率

r_i

ri将所持有的块分发给其余N-1个对等方, 同时服务器将第N+1块以速率

r_{N+1}

rN+1并行分发给N个对等方, 此时这些对等方不用分发块

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

因此收集整理了一份《2024年Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-VZ9yVJQd-1712925627368)]
[外链图片转存中…(img-vDXWq87Z-1712925627369)]
[外链图片转存中…(img-RW2MTijP-1712925627369)]
[外链图片转存中…(img-VqY3emvF-1712925627369)]
[外链图片转存中…(img-cBAWGCMJ-1712925627370)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Linux运维知识点，真正体系化！

如果你觉得这些内容对你有帮助，可以添加VX：vip1024b （备注Linux运维获取）
[外链图片转存中…(img-hBioMWJw-1712925627370)]

腾讯云开发者社区

腾讯云面向开发者汇聚海量精品云计算使用和开发经验，营造开放的云计算技术生态圈。

更多推荐

Elasticsearch复杂数据类型终极指南：从入门到精通

Elasticsearch作为功能强大的搜索引擎，支持多种复杂数据类型，让开发者能够灵活处理各种结构化和非结构化数据。本文将带你全面了解Elasticsearch中的复杂数据类型，从基础概念到实际应用，助你轻松掌握数据建模的核心技巧。## 内部对象：构建层级化数据结构在Elasticsearch中，对象类型（Object）是最基础的复杂数据类型之一，用于表示具有嵌套关系的数据。例如，我们可

腾讯云开发者社区

终极指南：Flink SQL连接器版本管理从混乱到有序的升级之路

Apache Flink作为流处理领域的佼佼者，其SQL连接器的版本管理一直是开发者面临的核心挑战。本文将系统讲解Flink SQL连接器版本管理的最佳实践，帮助你轻松应对版本兼容性问题，实现从混乱到有序的升级之旅。## 连接器版本管理的常见痛点 😫在Flink应用开发中，连接器版本管理常常让开发者头疼不已。不同版本的连接器可能导致各种兼容性问题，例如API变更、功能差异甚至运行时错误。

腾讯云开发者社区

如何快速搭建Neon无服务器PostgreSQL：面向初学者的完整指南

Neon是一款革命性的无服务器PostgreSQL解决方案，它通过分离存储和计算层，实现了自动扩缩容、类代码式数据库分支以及零级扩展能力。本指南将帮助你从零开始搭建Neon开发环境，体验这款创新数据库的强大功能。## 准备工作：环境要求与依赖项在开始搭建Neon环境前，请确保你的系统满足以下要求：- Linux操作系统（推荐Ubuntu 20.04+或Debian 11+）- Git

腾讯云开发者社区

所有评论(0)

查看更多评论

前端node资料大全

@m0_60144796

已为社区贡献1条内容

计算机网络 自顶向下方法-第8版-Chapter2-Problems_计算机网络自顶向下方法第八版答案

前端node资料大全

b

P10

P11

a

b

P12

P13

a

b

P14

P15

P16

P17

P18

a

b

c

d

e

f

g

P19

a

b

P20

P21

P22

C-S

P2P

P23

a

b

c

P24

a

b

a

b

所有评论(0)

温馨提示：您尚未绑定手机号

前端node资料大全

计算机网络自顶向下方法-第8版-Chapter2-Problems_计算机网络自顶向下方法第八版答案