计算机网络:自顶向下方法-第8版-Chapter2-Reviews

R1

列出 5 种非专用的因特网应用及它们所使用的应用层协议。

电子邮件: SMTP

远程终端访问: Telnet

Web: HTTP

文件传输: FTP

P2P 文件共享：BitTorrent

流式多媒体: HTTP, DASH

因特网电话: SIP, RTP

R2

网络体系结构与应用程序体系结构之间有什么区别？

网络体系结构(Network architecture)是指将通信过程分层组织, 如五层Internet体系结构。通过将端系统间的数据交换过程按照层次划分，每层提供相应的服务，层次之间各司其职不耦合，这样每层都可以进行扩展而不会影响其他层提供的服务；

应用程序体系结构(Application architecture)是由应用程序开发人员设计的，它规定了应用程序的总体结构(例如，客户机-服务器或P2P)。是设计来让应用程序提供更好的服务而衍生出来的不同方案，比如浏览器和 Web 服务器这样的 B/S 结构；App 和数据服务器这样的 C/S 结构，以及迅雷下载这样的 P2P 结构。其中一台端系统负责运行客户端程序，一台负责全天候 24 小时运行着提供数据服务的程序。

R3

对两进程之间的通信会话而言，哪个进程是客户，哪个进程是服务器？

发起通信的进程的是客户

在会话开始时等待联系的进程是服务器

R4

对一个 P2P 文件共享应用，你同意 “一个通信会话不存在客户端和服务器端的概念” 的说法吗？为什么？

不同意。在 P2P 文件共享应用中，一个进程既可以作为服务器上载文件, 也可以作为客户下载文件。

R5

运行在一台主机上的一个进程，使用什么信息来标识运行在另一台主机上的进程？

目的主机的IP地址和目的进程的socket在目的主机上的端口号

R6

假定你想尽快处理从远程客户到服务器的事物，你将使用 UDP 还是 TCP？为什么？

使用UDP。

Transmission Control Protocol (TCP)

User Datagram Protocol (UDP)

如果使用UDP，事务可以在一个RTT内完成从客户端将事务请求发送到UDP套接字，服务器将回复发送回客户端的UDP套接字。

如果使用TCP，至少需要两个RTT, 一个用于建立TCP连接，另一个用于客户端发送请求和服务器发送应答

TCP的3次握手过程:

1. 客户向服务器发送一个小的TCP报文段SYN
2. 服务器用一个小的TCP报文段: SYN+ACK 进行确认
3. 客户发送ACK确认报文段和要发送的HTTP请求报文

SYN是Synchronize地缩写, ACK是Acknowledge的缩写

R7

参见图 2-4，

我们看到在该图中所列出的应用程序没有一个同时既要求无数据丢失又要求定时的。你能设想一个既要求无数据丢失又高度时间敏感的应用吗？

远程文字处理，既要求远程处理的实时性, 又要求文字处理的正确性

例如，用谷歌文档。但是，由于Google docs在Internet上运行(使用TCP)，因此不提供时间保证。

R8

列出一个运输协议能够提供的 4 种宽泛类型的服务。对于每种服务，指出是 UDP 还是 TCP (或这两种协议) 提供这样的服务。

运输层协议提供地应用程序服务	TCP支持	UDP支持
可靠数据传输	✔	❌
吞吐量	❌	❌
定时	❌	❌
安全性	❌	❌

R9

前面讲过 TCP 能用 TLS 来强化，以提供进程到进程的安全性服务，包括加密。TLS 运行在运输层还是应用层？如果某应用程序研制者想用 TLS 来强化 UDP，该研制者应当做些什么工作？

TLS在应用层运行。TLS套接字从应用层获取未加密的数据，对其进行加密，然后将其传递给TCP套接字。如果应用程序开发人员希望使用TLS增强UDP，则必须在应用程序中包含TLS代码

R10

握手协议的作用是什么?

握手协议的主要作用是在通信的两个实体（通常是客户端和服务器）建立连接或会话之前进行必要的协商和验证，以确保通信的安全性、可靠性和完整性。握手协议是计算机通信中的重要步骤，它提供了以下几个关键功能：

1. 身份验证：

   握手协议允许通信双方在建立连接之前验证对方的身份。这是防止未经授权的访问和中间人攻击的关键步骤。通常，身份验证是通过数字证书或其他证据来实现的。

2. 加密参数协商：

   握手协议还允许通信双方协商加密算法和密钥，以确保后续的数据传输在安全通道上进行。通过在握手过程中交换加密参数，通信双方能够建立一个安全的通信环境，保护数据免受窃听和篡改。

3. 建立通信参数

   握手协议中还可以协商其他通信参数，例如通信的协议版本、通信的时间限制等。这有助于确保通信双方在数据传输过程中理解彼此的期望和要求。

4. 错误处理和状态同步：

   在握手过程中，通信双方可以交换状态信息，并确保双方都知道连接的建立过程中是否出现了错误。这样有助于在连接建立之前解决问题，并保持通信状态的同步。

R11

为什么 HTTP，SMTP 及 IMAP 都运行在 TCP，而不是 UDP 上？

HTTP、SMTP和IMAP与这些协议相关联的应用程序要求以正确的顺序接收所有应用程序数据，并且没有间隙。TCP提供此服务，而UDP不提供。

1. 可靠性：

   HTTP、SMTP和IMAP这些应用层协议通常涉及传输的数据较为重要，要求数据传输的可靠性。TCP是一种面向连接的协议，它确保数据的可靠传输，即数据不会丢失，不会损坏，而且按照发送顺序正确地到达目的地。对于网页浏览（HTTP）、电子邮件传输（SMTP）和邮件收取（IMAP）等应用场景，确保数据的完整性和可靠性是至关重要的。

2. 有序性：

   TCP协议保证数据按照发送顺序进行传输。这对于像Web页面中的图像、样式表和脚本等需要按特定顺序加载的资源是非常重要的。类似地，电子邮件传输和收取需要按照发送顺序处理消息的各个部分，确保邮件的正确组装。

3. 流量控制和拥塞控制：

   TCP具有流量控制和拥塞控制机制，可以根据网络条件调整数据传输速率，防止网络拥塞和数据丢失。这对于保持网络的稳定和可靠运行至关重要。

相比之下，UDP是一种无连接的协议，它不提供上述的可靠性和有序性保证。UDP更适合那些对数据传输延迟要求较高，而对数据可靠性要求相对较低的应用场景，比如实时音视频传输和游戏数据传输。由于UDP没有建立连接的握手过程，数据传输速度更快，但也容易丢失数据和无序传输。

R12

考虑一个电子商务网站需要保留每一个客户的购买记录。描述如何使用 cookie 来完成该功能？

当用户第一次访问站点时，服务器创建一个唯一的标识号作为cookie值，并其后端数据库中的cookie表中插入，并通过响应报文将该标识号作为cookie号返回。这个cookie号存储在用户的主机上，由浏览器管理。在随后的每次访问(和购买)期间，浏览器将cookie号码放在请求报文的首部行发送回站点, 若用户有购买记录, 则以cookie作为主键插入一条购买记录到后端的购买记录表中。因此，站点知道该用户(更准确地说，是该浏览器)何时访问该站点。

R13

描述 Web 缓存器时如何减少接收被请求的对象的时延的。Web 缓存器将减少一个用户请求的所有对象或只是其中的某些对象的时延吗？为什么？

Web缓存器在自己的存储空间中存储最近请求的对象副本,客户每次先对代理服务器发送HTTP请求, 如果在代理服务器命中对象, 则直接对客户端进行响应, 否则才在代理服务器处对初始服务器进行HTTP请求, 当代理服务器接收到初始服务器的HTTP响应后会在本地存储该对象, 这样提高在代理服务器处的命中率, 才减少请求对象的时延, 并且客户端通常与代理服务器在一个高带宽局域网中

Web缓存可以减少所有对象的延迟, 对于在代理服务器处命中的对象, 由于距离短, 带宽高, 所以时延会降低, 对于没有在代理服务器处命中的对象，因为缓存减少了接入链路到因特网的通信量, 整体上减少了因特网上Web的流量, 因此请求和响应报文在中间某个路由器被排队的可能性就减小，因此时延得到减少。

R14 (Unsolved)

Telnet 到一台 Web 服务器并发送一个多行的请求报文。在该请求报文中包含 If-Modified-Since: 首部行，迫使响应报文中出现 “304 Not Modified” 状态代码。

telnet设置与使用

遇到问题

因为每次请求都是独立的, 没有对之前的响应做缓存, 所以出现不了304

R15

列出几种流行的即时通信应用。它们使用相同的协议作为SMS吗?

Answer

一些流行的即时通讯应用:WhatsApp, Facebook Messenger，微信，
和Snapchat。这些应用程序使用与SMS不同的协议。

SMS

短信（Short Message Service，简称 SMS）是一种用于发送文本消息的通信服务，最初设计用于在移动电话之间传递短文本消息。它是一种基于电信网络的服务，允许用户通过移动设备发送和接收短文本消息，每条消息长度通常限制在 160 个字符以内。

SMS 最早是在 1992 年由欧洲电信标准协会（ETSI）引入的，并很快成为全球范围内手机用户之间交流的标准方式之一。SMS 的使用非常简单，用户只需在手机上输入文本消息，选择接收者的电话号码，然后点击发送即可。

尽管 SMS 最初是一种简单的文本消息传递方式，但随着移动技术的发展，它逐渐演变出多媒体消息（MMS）等变种，允许发送更多类型的内容，如图片、音频、视频等。然而，由于互联网连接的普及，许多新型即时通信应用（如上文所列）已经取代了传统的 SMS，提供更丰富的功能和更高效的通信方式。

R16

假定Alice使用一个基于Web的电子邮件账户（例如Hotmail或Gmail)向Bob发报文，而Bob使用IMAP从他的邮件服务器访问自己的邮件。讨论该报文是如何从Alice主机到Bob主机的。要列出在两台主机间移动该报文时所使用的各种应用层协议。

Answer

首先, Alice将报文通过HTTP协议从浏览器发送到她的邮件服务器。然后, 在Alice的邮件服务器中通过SMTP将报文传输到Bob的邮件服务器。 然后 Bob 通过 IMAP 将消息从他的邮件服务器传输到他的主机

IMAP

IMAP（Internet Message Access Protocol）是一种用于电子邮件客户端与电子邮件服务器之间进行通信的协议。它允许用户通过邮件客户端（如Outlook、Thunderbird、Apple Mail等）访问和管理存储在远程邮件服务器上的电子邮件。

IMAP 与另一种常见的电子邮件协议 POP3（Post Office Protocol 3）相比，具有许多优势。以下是 IMAP 的一些特点：

1. 保留邮件在服务器上： IMAP 允许电子邮件保留在邮件服务器上，而不仅仅是下载到本地设备。这意味着您可以在不同的设备上（例如台式机、笔记本电脑、手机）之间同步邮件状态。

2. 文件夹同步： IMAP 支持文件夹同步，因此您在一个设备上创建的文件夹、标签、邮件状态等更改都会在其他设备上反映出来。

3. 在线访问： 由于邮件保留在服务器上，您可以随时通过网络访问邮件，而无需仅仅依赖于本地设备上存储的副本。

4. 批量下载： IMAP 可以选择性地下载邮件，而不是像 POP3 那样一次性下载所有邮件。这可以节省带宽和存储空间。

5. 服务器端搜索和筛选： 使用 IMAP，您可以在邮件服务器上执行高级搜索、过滤和分类操作，而不必下载所有邮件。

虽然 IMAP 提供了更灵活和方便的电子邮件管理方式，但由于涉及与服务器的实时通信和同步，它可能需要更多的网络带宽和服务器资源。总体而言，IMAP 是一种适用于需要在多个设备上访问和管理邮件的情况下的有用协议。

R17 (Unsolved)

将你最近收到的报文首部打印出来。其中有多少 Recieved: 首部行？分析该报文的首部行中的每一行。

尝试

因为Recieved: 首部行只在SMTP中有, 所以要抓取到SMTP的包

https://www.jianshu.com/p/37f46ca1176a

Base64编码

注册了163邮箱, 并设置telnet到telnet smtp.163.com 25

建议使用Linux的shell

helo m18143664811@163.com
250 OK
auth login
334 dXNlcm5hbWU6
MTgxNDM2NjQ4MTFAMTYzLmNvbQ==
334 UGFzc3dvcmQ6
TFRMWUxaUldUTk1TRlRCUA==
235 Authentication successful
mail from: <18143664811@163.com>
250 Mail OK
rcpt to: <2415571314@qq.com>
250 Mail OK
data
354 End data with <CR><LF>.<CR><LF>
from: <18143664811@163.com>
to: <2415571314@qq.com>
subject: test

i am wxc, who are you?

.
250 Mail OK queued as zwqz-smtp-mta-g1-2,_____wCHJmMer9Vkb8roCg--.54441S2 1691725717

很遗憾, 没有在抓到的SMTP包中找到Received首部行相关信息

SMTP首部行

SMTP（Simple Mail Transfer Protocol）是用于发送电子邮件的协议，它定义了一组命令和规则，以便在邮件服务器之间传递电子邮件。在SMTP中，邮件的头部信息由一系列字段组成，这些字段描述了邮件的不同方面。以下是一些常见的SMTP邮件头部字段：

1. Date: 指定邮件的发送日期和时间。

2. From: 指定邮件的发件人地址。

3. To: 指定邮件的收件人地址。可以有多个收件人，以逗号分隔。

4. Cc (Carbon Copy): 指定邮件的抄送（副本）收件人地址。和 “To” 字段一样，可以有多个收件人。

5. Bcc (Blind Carbon Copy): 指定邮件的密送（暗抄送）收件人地址。Bcc 收件人不会在邮件的其他收件人中显示。

6. Subject: 指定邮件的主题或标题。

7. Reply-To: 指定回复邮件时要使用的邮件地址。

8. Message-ID: 指定邮件的唯一标识符。

9. In-Reply-To: 指定被回复邮件的 Message-ID，用于建立邮件之间的关联。

10. References: 列出与当前邮件相关的邮件的 Message-ID 列表。

11. MIME-Version: 指定邮件使用的 MIME 版本，以支持多媒体内容。

12. Content-Type: 指定邮件的内容类型，如文本、HTML 或附件。

13. Content-Disposition: 指定附件的显示方式，如 inline（嵌入式）或 attachment（作为附件）。

14. Content-Transfer-Encoding: 指定邮件内容的编码方式，如 base64 或 quoted-printable。

15. Received: 在邮件的传递过程中，不同的邮件服务器会在头部中添加 “Received” 行，用于跟踪邮件的路径。

16. X-Headers: 用户自定义的扩展头部字段，通常以 “X-” 开头。

这只是一些常见的SMTP邮件头部字段，实际上还有很多其他的字段可以用于指定邮件的各个方面。在创建邮件时，可以根据需要添加这些字段以及其他自定义字段，以确保邮件被正确地传递和解释。不同的邮件客户端和服务器可能会支持不同的头部字段，因此在使用特定字段之前最好了解其在目标系统上的兼容性。

Received首部行

SMTP（Simple Mail Transfer Protocol）是用于电子邮件传输的一种协议。在邮件传输过程中，每个邮件服务器都会在其收到、处理和传递邮件的过程中添加一个名为 “Received” 的首部行。这些首部行记录了邮件的传输路径，包括每个中间邮件服务器的名称、IP地址和时间戳。

每个邮件服务器在处理邮件时都会添加一个新的 “Received” 首部行，并将其添加到邮件的首部部分。以下是一个示例邮件的 “Received” 首部行链条：

Received: from sender_domain.com (sender_ip_address) by sending_mail_server.com (sending_server_ip) with SMTP id ABC123; Tue, 11 Aug 2023 10:00:00 -0700

Received: from receiving_mail_server.com (receiving_server_ip) by recipient_domain.com (recipient_server_ip) with SMTP id DEF456; Tue, 11 Aug 2023 11:30:00 -0700

Received: from final_destination_server.com (final_destination_ip) by receiving_mail_server.com (receiving_server_ip) with SMTP id GHI789; Tue, 11 Aug 2023 12:45:00 -0700

在这个示例中，每个 “Received” 首部行都显示了邮件传输的路径。邮件从发送方域（sender_domain.com）通过发送邮件服务器（sending_mail_server.com），然后传递到接收邮件服务器（receiving_mail_server.com），最终到达最终目的地服务器（final_destination_server.com）。

每个 “Received” 首部行通常包括以下信息：

• 发送邮件服务器的域名和IP地址
• 接收邮件服务器的域名和IP地址
• 使用的SMTP协议ID（用于标识邮件传输会话）
• 时间戳，表示邮件的接收时间

这些 “Received” 首部行链条可以帮助管理员和邮件收件人跟踪邮件的路径，检查邮件传输是否正常，以及在需要时进行故障排除。请注意，邮件首部行的内容可能因邮件服务器的设置而有所不同，但一般来说，每个邮件服务器都会添加一个或多个 “Received” 首部行。

R18

什么是 HTTP/1.1中的HOL阻塞问题? HTTP/2试图如何解决这个问题?

HOL阻塞问题是网页中的大文件(即视频剪辑)需要很长时间才能通过瓶颈链接，从而阻塞了后面的其他小对象, 导致小对象的完整接收延迟, 从而导致用户的感知时延增加。

HTTP/2通过将每个报文分解成小帧，并在单一持续的TCP连接上交错(根据报文的优先级, 交错的发送每个对象的不同帧)发送请求和响应报文来解决这个问题。并且在接收段实现成帧子层将一个响应报文的帧组装起来。

R19

一个机构的 Web 服务器和邮件服务器可以有完全相同的主机名别名（例如：foo.com） 吗？包含邮件服务器主机名的 RR 有什么样的类型？

可以。Web 服务器可以通过DNS请求CNAME获取别名foo.com对应的规范主机名, 例如: www.oj.foo.com。邮件服务器可以通过DNS请求MX获取别名foo.com对应的规范主机名, 例如: www.mail.foo.com。

MX类型的RR将邮件服务器的别名映射到规范主机名

A类型的RR将邮件服务器的规范主机名映射到其主机的IP地址

R20 (Unsolved)

仔细检查收到的电子邮件，查找由使用 .edu 电子邮件地址的用户发送的报文首部。从其首部，能够确定发送该报文的主机的 IP 地址吗？对于由 gmail 账号发送的报文做相同的事。

您应该能够看到带有.edu电子邮件地址的用户的发件人的IP地址。但如果用户使用gmail帐户，你将无法看到发件人的IP地址

R21

在 BitTorrent 中，假定 Alice 向 Bob 提供一个30秒间隔的文件块吞吐量。Bob将必须进行回报，在相同的间隔中向Alice提供文件块吗?为什么?

Bob没有必要也向Alice提供数据块。除非 Alice 给 Bob 提供块的速率足够快，以至于成为给 Bob 传块速率最高的四位上传者之一, Bob才会在给Alice提供文件块;

另外, 每30sBob才会随机地选一位邻居进行发送块, 如果选择Alice才有可能成为Alice的最高四位上传者

即使Alice以30秒的间隔向Bob提供数据块，也可能不会发生这种情况。

R22

考虑一个新对等方 Alice 加入 BitTorrent 而不拥有任何文件块。没有任何块，因此她没有任何东西可上载，她无法成为任何其他对等方的前 4 位上载者。那么 Alice 将怎样得到她的第一个文件块呢？

回想一下，在 BitTorrent 中，一个对等方随机选择一个对等方，并乐观地在短时间内解除对等方的封锁。因此，Alice最终将被她的邻居之一乐观地解除阻塞，在此期间，她将从该邻居那里接收块

对等方每个30s随机地向其前4个对等方之外的邻近对等方发送块, Alice可能会被其邻居选中, Alice接送到块后, 可能会响应别的对等方的请求, 以至于成为对方的前4位邻居, 使得Alice接受到更多的块。

R23

覆盖网络是什么？它包括路由器吗？在覆盖网络中边是什么？

P2P文件共享系统中的覆盖网络由参与文件共享系统的节点(对等方)和节点之间的逻辑链路(上载/下载关系)组成的逻辑网络。覆盖网络不包括路由器。如果A和B之间存在半永久的TCP连接，则从节点A到节点B之间存在逻辑链接(图论术语中的“边”), 即服务的提供/请求关系。

R24

CDN通常采用两种不同的服务器放置方法之一。列举并简单描述它们。

• 深入

  在接入ISP中部署CDN服务器集群, 减少端用户到CDN之间的链路和路由器数量, 以减小端用户的感知时延并增加端用户和CDN服务器之间的吞吐量。由于ISP众多, 所以对于每个ISP内部的CDN服务器集群的管理和维护难度大大加强。

• 邀请做客

  在少量的IXP中放置服务器集群, 并邀请ISP接入到部署了服务器集群的IXP中, 这样服务器集群数量大大减少, 使得管理和维护的成本减低, 但是端用户到CDN集群之间的"距离"变远了, 感知时延增大

R25

除了如时延、丢包和带宽性能等网络相关的考虑外，设计一种CDN服务器选择策略时还有其他重要因素。它们是什么?

除了与网络相关的因素外，还有一些重要的因素需要考虑，例如负载平衡(不应将客户机定向到过载集群)、日影响、网络中DNS服务器之间的变化、很少访问的视频的有限可用性，以及缓解由于流行视频内容而可能出现的热点的需要。另一个要考虑的因素是ISP的交付成本考虑到ISP和集群运营商之间的合同关系中不同的成本结构，可以选择集群，以便使用特定的ISP来承载cdn到客户端的流量。

1. 服务器容量与负载：CDN服务器的负载情况和可用容量是选择策略中的关键因素。选择负载较低的服务器可以确保内容得到更好的服务，而不会因过载而导致性能下降。
2. 内容分布与复制策略：CDN涉及将内容在多个服务器上进行复制，以提供更好的性能和可靠性。设计选择策略时需要考虑哪些内容复制到哪些服务器以及何时更新副本，以最大程度地提供内容的可用性。
3. 成本和效益：CDN服务器的运营和维护成本是一个重要因素。在选择策略时，需要平衡服务器的性能和成本，以确保在提供良好用户体验的同时不会产生过高的成本。

R26

2.7 节中所描述的 UDP 服务器仅需要一个套接字，而 TCP 服务器需要两个套接字。为什么？

如果 TCP 服务器支持 n 个并行连接，每条连接来自不同的客户主机，那么 TCP 服务器将需要多少个套接字？

对于UDP服务器，没有欢迎套接字，来自不同客户端的所有数据都通过这个套接字进入服务器。

对于TCP服务器，有一个欢迎套接字，每次客户机发起到服务器的连接时，都会创建一个新的连接套接字。

因此， TCP 服务器为了支持n个同时连接，服务器将需要n+1个套接字: n个连接套接字和1个欢迎套接字。

R27

对于 2.7 节所描述的运行在 TCP 之上的客户-服务器应用程序，服务器程序为什么必须先于客户程序运行？对于运行在 UDP 之上的客户-服务器应用程序，客户程序为什么可以先于服务器程序运行？

对于TCP应用程序，一旦执行客户机，它就会尝试启动与服务器的TCP连接。如果TCP服务器没有运行，那么客户端将无法建立连接。对于UDP应用程序，客户端在执行时不会立即发起连接(或尝试与UDP服务器通信)