文章目录
前言
阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。
本文是关于《计算机网络：自顶向下方法（第七版）》的学习分享，内容书写顺序也是按照书中的顺序。本文并不会提及书中的所有内容，主要写重点的知识，以及自己感兴趣的内容。会对原文中的内容进行一定的精简，或者加上个人的理解。
多媒体网络
实时应用式会话的协议
SIP
定义在 [ RFC 3261; RFC 5411 ] 中的会话发起协议 (Session Initiation Protocol , SIP) 是一个开放和轻型的协议，其功能如下：
• 提供了在主叫者和被叫者之间经 IP 网络创建呼叫的机制。 它允许主叫者通知被叫者它要开始一个呼叫。 它允许参与者约定媒体编码，也允许参与者结束呼叫。
• 提供了主叫者确定被叫者的当前IP地址的机制。 因为用户可能动态地分配到地址（使用 DHCP), 而且因为它们可能有多个IP设备，每个都有一个不同的 lP地址，所以用户不具有单一的、固定的IP地址。
• 提供了用于呼叫管理的机制，这些机制包括在呼叫期间增加新媒体流、在呼叫期间改变编码、在呼叫期间邀请新的参与者、呼叫转移和呼叫保持等。
- 向已知 IP 地址建立一个呼叫
为了理解SIP 的要素，最好看一个具体的例子。 在这个例子中， Alice在使用 PC, 并且她要呼叫 Bob, Bob 也在使用 PC 工作。 Alice 和 Bob 的 PC 都配有基于SIP 的软件来产生和接收电话呼叫。 在这个初始的例子中，我们将假设Alice知道Bob PC 的 IP地址。 图9-9描述了这个SIP呼叫建立的过程。
在图9-9 中，我们看到当 Alice 给 Bob 发送一个 INVITE 报文（这类似于 HTTP 请求报文）时， 一个SIP会话开始了。 该INVITE报文通过UDP发送给SIP 的周知端口 5060。 (SIP报文也可以经TCP 发送) 该 INVITE 报文包括了对 Bob 的标识 (bob@ 193. 64. 210. 89) 、Alice 当前 lP 地址的指示、 Alice 希望接收的音频的指示（该音频以格式 AVP0 编码，即 µ律PCM 编码， 并在 RTP 中封装），以及她希望在端口 38060 接收RTP分组的指示。 在收到了 Alice 的 INVITE 报文之后， Bob 发送一个 SIP 响应报文（该报文类似 HTTP 的响应报文） 。 该响应SIP报文也被发送到SIP端口 5060。 Bob 的响应包括一个200 OK和他的 IP地址的指示、 他希望接收的编码和分组化，以及音频数据应该发送到达的端口号。 注意到在这个例子中， Alice 和 Bob 准备使用不同的音频编码机制：要求 Alice 使用 GSM 来对她的音频编码，而要求 Bob使用 µ律PCM 对他的音频编码。 在接收到 Bob 的响应后， Alice 向Bob 发送 SIP 确认报文。 在这个 SIP 事务之后， Bob 和 Alice 可以交谈了。 （为了看起来清晰，图9-9 显示 Alice 在 Bob 之后说话，但是事实上他们通常可以同时进行交谈。） Bob会根据要求对音频进行编码和分组化，并将音频分组发送给IP地址 167. 180. 112. 24 的端口号38060。Alice也会根据要求对音频进行编码和分组化，并将音频分组发送给 IP地址193.64.210. 89 的端口号48753
从这个简单的例子我们学到了一些SIP 的关键特性。 第一， SIP是一个带外协议，即发送和接收STP报文使用了一个不同于发送和接收媒体数据的套接字。 第二， SIP报文本身是可读的 ASCII. 这与 HTTP报文类似。 第三， SIP要求所有的报文都要确认，因此它能够在UDP或者TCP上运行。
在这个例子中，我们考虑一下如果Bob没有µ律PCM 编解码器用于音频编码将会发生什么情况， 在这种情况下， Bob 不用200 OK 来响应，而可能用一个606 Not Acceptable （不可接受）来响应，并在报文中列出他能够使用的所有编解码。 然后Alice从中选择一个编解码，并发送另一个INVITE 报文．以此通告了已选择的编解码器。 Bob也能够直接通过发送某个拒绝应答代码来直接拒绝该呼叫。 （有很多这种代码，包括 "busy (忙）""gone (离开）'' payment (付费）"和 'forbidden (禁止）" 。) - SIP 地址
在前面的例子中， Bob 的 STP地址是sip: bob@ 193. 64. 210. 89。 然而，我们希望许多（即使不是大多数） SIP地址类似于电子邮件地址。 例如， Bob 的地址可以是 sip: bob@ domain. com。 当 Alice 的 SIP 设备发送 INVITE 报文，该报文包括这种类似于电子邮件地址
的地址；然后SIP 的基本设施将该报文转发给 Bob 正在使用的 IP设备（如我们下面要讨论的那样）。 其他可能的SIP地址形式可以是Bob过去的电话号码或者只是Bob 的名字／中间名／姓氏（假设它是唯一的）。
SIP 地址的一个有趣特点是它们能够被包括在Web 页面中，就像人们的电子邮件地址用 mailot URL 形式包含在 Web 页面中那样。 例如，假设 Bob 有个人主页，并且他要为这个主页的访问者提供一个呼叫他的方法。 于是他可能只是在主页中包括该URL sip: bob@ domain. com (当访问者点击该 URL, 访问者设备中的 SIP 应用将启动，并向 Bob 发送 INVITE 报文。 - SIP 报文
在这个SIP简短的介绍中，我们无法包括所有 SIP 报文类型和首部，而只是简要地浏览一下SIP INVITE 报文，以及少数通用的首部行。 我们再假设Alice要对Bob 发起VoIP呼叫，此时Alice 只知道 Bob 的 SIP地址 bob@domain. com, 并不知道 Bob 正在使用的设备的lP 地址。 那么她的报文可能看起来有些像下面这个：
bash
INVITE sip:bob@domain.com SIP/2.0
Via : SIP/2.0/UDP 167.180.112.24
From: sip:alice@hereway. com
To : sip:bob@domain.com
Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0这个INVITE 行包括SIP 的版本，这与 HTTP请求报文一样。 任何时候SIP报文通过一个SIP 设备（包括产生该报文的设备）时，它附加上一个Via首部来指示该设备的 IP地址。 （我们不久将看到通常INVITE 报文在到达被叫者的 SIP 应用之前会通过很多 SIP 设备。）与电子邮件报文类似， SIP报文包括一个From首部行和一个To 首部行。 该报文包括一个Call-ID ( 呼叫标识符），它唯一地标识该呼叫（类似电子邮件中的报文 ID); 包括一个Content-Type ( 内容类型）首部行，定义用于描述包含在 SIP 报文中的内容的格式； 还包括Content-Length (内容长度）首部行，提供报文中内容的字节长度。 最后， 在一个回车和换行之后，该报文包含内容部分。 在这个例子中，内容提供了有关Alice 的 IP地址和Alice 要如何接收该音频的信息。
- 名字翻译和用户定位
在图9-9 的例子中，我们假设Alice 的 SIP设备知道能够联系到 Bob 的 IP地址。 但是这种假设是很不真实的， 不仅因为IP地址通常是通过 DHCP动态分配的，而且 Bob可能有多个IP设备 （例如，在家里、工作中和汽车里有不同的设备）。 因此现在我们假设Alice 只知道 Bob 的电子邮件地址 bob@domain. com, 而且对基于 SIP 的呼叫使用同样的地址。 在这种情况下， Alice需要获得用户 bob@domain. com 正在使用的设备的 IP 地址。 为了获得它， Alice 创建一个 INVITE 报文，它以 INVITE bob@ domain. com SIP/2. 0 开始， 并将该报文发送给一个SIP 代理 (SIP proxy)。 该代理将以一个 SIP 回答来响应，该回答中也可能包含bob@domain. com 正在使用的设备的 IP地址。 该回答也可以选择包括Bob 的语音信箱的IP地址，或者可能包括一个Web页面的 URL (上面写着 "Bob在睡觉，请不要打扰!) 。 代理返回的结果也可能取决于呼叫者：如果呼叫是 Bob 的妻子发出的，它可能接受该呼叫，并提供IP地址；如果呼叫是Bob 的岳母发出的，它可能用指向 "我正在睡
觉＂的Web页面的URL来响应。
现在，你可能想知道这个代理服务器是怎样确定 bob@domain. com 现在的 IP 地址的？为了回答该问题，我们需要讲一下另一个SIP设备，即 SIP 注册器 (SIP registrar)。 每个SIP 用户都有一个相关联的注册器。 任何时候用户在设备上发起SIP应用时，该应用给注册器发送一个SIP注册报文，通知注册器它现在的IP地址。 例如，当 Bob在他的 PDA上发起SIP 应用时，该应用将发送一个类似于下述内容的报文：
bash
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
From: sip:bob@domain.com
To: sip:bob@domain.com
Expires : 3600Bob 的注册器跟踪 Bob 现在的 IP地址。 无论何时 Bob切换到一个新的 SIP设备时，该新设备将发送一个新的注册报文，指示该新的IP地址。 如果 Bob长时间使用同样的设备，该设备将发送刷新注册报文，指示最近发送的IP地址仍然有效。 （在上面的例子中，需要每隔3600 秒发送刷新报文来维护在注册器中的地址。）值得注意的是注册器和 DNS权威名字服务器类似： DNS服务器将固定的域名翻译到固定的IP地址； SIP注册器把固定的人识别标志（例如bob@domain. com) 翻译为一个动态的 IP 地址。 SIP 注册器和 SIP代理通常运行在同一台主机上。
现在我们检查一下Alice 的 SIP 代理服务器是如何获得 Bob 当前的 lP地址的。 从上面的讨论我们看到，代理服务器只需要转发Alice 的INVITE 报文给 Bob 的注册器／代理即可。然后注册器／代理将该报文转发给Bob现在的SIP 设备。 最后，在已收到了 Alice 的INVITE报文之后， Bob 可以向 Alice 发送一个 SIP应答。
举例来说，考虑图9-10, 其中正在217. 123.56. 89 上工作的 jim@umass. edu 要对正在197.87.54.21 上工作的 keith@upenn. edu 发起 IP 语音 ( VoIP) 会话。 采用下面的步骤：1.Jim 向 umass 的 SIP 代理发送 INV1TE 报文。 2.该代理在 SIP 注册器 upenn. edu 上进行DNS 查询 （在图中没有显示），并将该报文转发给注册服务器。 3.因为 keith@upenn. edu 没有在注册器 upenn 上注册， upenn 注册器发送一个重定向应答，指示它应该试一试keith@ nyu. edu 。 4.umass 的代理向 NYU 的 SIP 注册器发送 INVITE 报文。 5.NYU 注册器知道 keith @upenn. edu 的 IP 地址，并将INVITE 报文转发给正运行 Keith 的 SIP 客户的主机 197. 87.54.21 、 6- 8通过注册器／代理把 SIP 响应返回给217. 123.56. 89上的SIP客户。 9.媒体直接在两个客户之间发送。 （还有一个SIP确认报文，图中没有画出来。）
我们有关SIP 的讨论集中在语音呼叫的呼叫发起方面。SIP 通常是一个发起和结束呼叫的信令协议、它能够用于视频会议呼叫和基于文本的会话。 事实上， SIP巳经成为许多即时讯息应用的基本组件。
支持多媒体的网络
我们学习了诸如客户缓存、预取、对可用带宽的适应性媒体质量、适应性播放和丢包缓解技术等应用级机制如何用于多媒体应用，以改善多媒体应用的性能。 我们也学习了内容分发网和P2P覆盖网络如何用于提供系统级的交付多媒体内容的方法。 这些技术和方法都被设计用于今天的尽力而为因特网。 的确，现在因特网得到应用就是因为它只提供单一的、 尽力而为类型的服务。 但是作为计算机网络的设计者，我们禁不住要问： 网络（而不是应用程序或者仅应用级的基础设施）是否可以提供支持多媒体内容交付的机制。 如我们很快将看到的那样，答案当然是肯定的！但是我们也将看到，许多这样的新网络级机制还没有得到广泛部署。 这可能是由千它们的复杂性和下列事实所致： 应
用级基础设施以及尽力而为服务和适当定制的网络资源 （例如带宽）的确能够提供"足够好的＂ （即使不总是尽善尽美的）端到端多媒体交付服务
表9-4 总结了能够对多媒体应用提供网络层支持的三种宽泛的方法)
• 尽可能利用尽力而为服务。 我们学习的应用级机制和基础设施能够成功地用于定制良好的网络，即使该网络偶然出现丢包和过大的端到端时延。 当预见到需求增加， ISP部署额外的带宽和交换能力以持续确保满意的性能 。 我们将进一步讨论网络定制 (network dimensio
ning) 。
• 区分服务。 自因特网的早期，就已经设想不同类型的流量（例如，在IPv4 分组首部中服务类型字段所指示的类型）能够由不同类型的服务所提供，而不是单一的"以不变应万变"的尽力而为服务。 使用区分服务 (differentiated service) , 当两类流量在一台路由器中排队时， 一种类型的流量可以给定严格的优于另一种类型的流量的优先权。 例如，属于实时会话式应用的分组由于其严格的时延限制，可能会给定优于其他分组的优先权。 在网络中引入区分服务将要求一些用于分组标记（指示一个分组的服务类型）、分组调度和其他方面的新机制。
• 每连接服务质量 (QoS) 保证。 使用每连接QoS保证，每个应用的实例显式地预约端到端带宽，并因此具有确保的端到端性能。 硬保证 (hard guarantee) 意味着应用将必定接收到它所请求的服务质量。 软保证 (soft guarantee) 意味着应用将以高概率接收到它所请求的服务质量。 例如，如果某用户要从主机A 向主机B进行VoIP 呼叫，该用户的 VoIP应用在两台主机之间沿着路径在每条链路上显式地预留带宽。 但是，允许应用做预约和请求网络同意该预约，这需要一些大的变化。 首先，我们需要一个协议来代表应用程序，从发送方到其接收方沿路径预约链路带宽。 第二，在路由器队列中将需要新的调度策略，使每连接带宽预约能够兑现。最后，为了进行预约，应用程序必须向网络给出描述来说明它们希望发送进网络的流量，并且网络将需要监管每个应用程序的流量以确保它遵守这个描述。 当这些机制结合时，在主机和路由器中要求新的和复杂的软件。 因为每连接QoS保证服务尚未见到大规模部署，我们将仅简要地涉及这些机制。
定制尽力而为网络
从根本上说，支持多媒体应用的困难是由其严格的性能要求引起的，即低的端到端分组时延、时延抖动和丢包，而事实是，无论何时网络变得拥塞，都将出现较大的分组时延、时延抖动和丢包。改善多媒体应用质量的第一种方法就是"在问题上砸钱"，因此直接避免资源竞争即可。 这种方法常用于解决有关资源受限的任何问题。 在网络多媒体的场合，这意味着在整个网络中提供充足的链路带宽，使网络拥塞及其导致的分组时延和丢失决不会（或仅非常少地）出现。 具有充足的链路带宽，分组将很快地通过今天的因特网而没有排队时延或丢失。从许多方面看，这是一种理想的情况： 完美地执行多媒体应用，用户是幸运的，所有要求都能够满足而不改变因特网尽力而为的体系结构。
当然，问题是为实现这种极乐世界提供多大容量才是"充足的＂，以及提供"充足的＂带宽的成本从ISP的商业角度来说是否实际。 在一个给定拓扑中为网络链路提供多大容量以取得给定水平的性能的问题常被称为带宽供给 (bandwidth provisioning)。 如何设计一个网络拓扑（其中放置一些路由器，如何用链路互联这些路由器，并为链路分配容量）以取得给定水平的端到端性能这个更为复杂的问题常被称为网络定制 (network dimensioning) 。 带宽供给和网络定制都是复杂的专题，它们远超过了本书的范围。 然而，我们这里注意到，为了预测两个网络端点之间的应用级性能，必须处理下列问题，并因此提供充足的容量来满足应用的性能要求。
• 网络端点之间的流量需求模型。 这些模型可能需要定义在呼叫层次（例如，用户"到达"网络并启动端到端应用）和分组层次（例如，由进行中的应用所产生的分组）。 注意负载可能随着时间而变化。
• 定义良好的性能要求。 例如，为支持诸如会话式多媒体应用等时延敏感的流量，其性能要求可能是：分组的端到端时延大于最大可容忍时延的概率要小于某个很小的值 。
• 对给定的负载模型预测端到端性能的模型，以及求出最小成本带宽分配（该带宽分配将导致满足所有用户的需求）的技术。 这里，研究人员正忙于研发能够量化给定负载下的性能模型，以及能求出满足性能要求的最小成本带宽分配的优化技术。
假定今天尽力而为的因特网能够（从技术角度讲）以适当的性能水平支待多媒体流量（ 如果它被定制成这样的话），自然的问题是为什么今天的因特网满足不了这样的要求。 答案基本上是经济上和组织上的原因。从经济角度看，用户将愿意向其ISP支付足够多的费用，使ISP安装充足的带宽经尽力而为的因特网来支持多媒体应用吗？组织问题也许更为令人气绥。 注意到在两个多媒体端点之间的端到端路径将通过多个ISP 的网络。 从组织角度看，这些ISP将愿意合作（也许以收入共享方式）以确保端到端路径被适当地定制来支持多媒体应用吗？
提供多种类型的服务
也许对今天因特网中的以不变应万变的尽力而为服务而言， 一种最简单的强化是将流量划分为多种类型，并为这些不同类型的流量提供不同等级的服务。 例如，某ISP可能要为时延敏感的VoIP 或电信会议流量比为电子邮件或 HTTP等弹性流量提供更高的服务类型（并对该服务收取更高的费用）。 另一种做法是， ISP可能直接向愿意对这种改进服务支付更多费用的顾客提供更高质量的服务。一些住宅有线接入ISP和蜂窝无线接入ISP 已经采用了这样的梯次等级服务，即铂金卡服务用户比金卡服务用户或银卡服务用户享有更好的服务性能。
我们都从日常生活中熟悉了不同类型的服务，如航班头等舱乘客比经济舱乘客得到更好的服务，； VIP在活动中能够立即进入，而所有其他人都必须排队等待。 重要的是注意到在聚合流量中（即在多种流量类型中而不是单个连接中）提供了这种有差别的服务。 例如，所有头等舱乘客被一视同仁（没有哪个头等舱乘客得到了比其他头等舱乘客更好的服务），就像所有的VoIP分组在网络中得到了相同的对待，与它们所属的特定的端到端连接无关。
早期因特网设计者的心中清晰地具有这种多种类型服务的概念。 IPv4首部中的服务类型 (ToS) 字段。 IEN123 [ ISI 1979] 描述也呈现在 IPv4 数据报的原型中的ToS 字段时说："服务类型［字段］ 提供了所希望的服务质量的抽象参数的指示。 当传输一个数据报通过某特定网络时，这些参数被用于引导实际服务参数的选择。 几种网络提供了服务优先权，该优先权以某种方式把高优先权流量看得比其他流量更为重要。
- 促进思考的场景
下面用几种促进思考的场景来开始我们的提供多种类型服务的网络机制的讨论。图 9-11 表示了一种简单的网络场景，两个应用分组流产生于位于一个局域网的主机H1 和 H2, 它们的目的地是另一个局域网的主机H3 和 H4。 在这两个局域网上的两台路由器通过一条 1.5Mbps 的链路连接起来。 我们假设局域网的速度远远高于1. 5Mbps, 并且关注路由器R1 的输出队列；注意到如果H1 和H2 的总计发送速率超过了 1.5Mbps, 分组时延和丢包将会出现。我们进一步假设1Mbps 的音频应用（例如一个 CD 质量的音频呼叫）共享 R1 和 R2 之间1.5Mbps 的链路，同时从 H2 到 H4 有一个HTTP Web浏览应用正在下载一个Web 网页。
在尽力而为服务的因特网中，该音频和 HTTP分组在 R1 的输出队列中混合，并且（通常）以先进先出 (FIFO) 的次序传输。 在这种情况下，来自 Web服务器的分组可能潜在地填充满这个队列，引起IP音频分组过度延迟或者由于R1 的缓存溢出而丢失。 我们应该如何解决这个潜在的问题呢？假定该HTTP Web浏览应用没有时间限制，我们的直觉也许是在R1 为音频分组分配严格的优先级。 在一个严格的优先级调度规则下，在 R1输出缓存的音频分组总是在R1 输出缓存中的任何HTTP分组之前传输。 对音频流量而言，从R1 到R2 的链路看起来像一条1.5Mbps 专用链路，而对于HTTP流量仅当没有音频流量排队时，才使用 R1 到R2 的链路。 为了让 R1 在它的队列中区分音频和FTP分组，每个分组必须被标记为属于这两类流量中的哪一类。 这是IPv4 中服务类型 (ToS) 字段的最初目的。 显而易见，这则是我们对需要提供多种类型流量机制的第 1 个见解。
见解1 : 标记分组 (packet mrking) 使得路由器区分属于不同类型流量的分组。
现在假设路由器被配置为给标记称1Mbps音频应用的分组赋予高优先级。 因为输出链路速度是 1.5Mbps, 即使HTTP分组得到较低的优先级， 它们仍然可以收到平均0. 5Mbps 的传输服务.但是如果音频应用开始以 1. 5Mbps 或者更高的速率 （或者恶意的，或者由于应用的差错）发送分组，那会出现什么样的情况呢？在这种情况下， HTTP分组将挨饿，也就是在R1 到R2 的链路上得不到任何服务。 如果多个应用（例如，多个音频呼叫）都具有同等的服务类型，共享一段链路带宽，那么也会出现类似问题， 即它们也可能共同饿死该HTTP会话。 理想情况下， 一种服务要与各类流量有隔离度，以保护一种流量类型免受其他流量类型干扰。 这种保护能够在网络中的不同地方实现，在每台路由器中，在进人网络的首个入口，或在网络边界域间。 这则是我们的第2个见解。
见解2: 希望在流量类型之间提供流量隔离 (traffic isolation) 的度，以便一类流量不会受到另一类异常流量的负面影响。
我们将考察在流量类型之间提供这种隔离的特定机制。 这里我们注意到，有两大类方法可以使用。 首先，可以执行如上图9-12 所示的流量监管 (traffic policing) 方法。 如果流量类型或流必须满足一定的准则（例如，音频流不超过 1Mbps 的峰值速率），那么可以设置一个监管机制来确保这些准则的确被遵守。 如果被监管的应用行为异常，这个监管机制将采取某种行动（例如， 丢弃或者延时那些违反这些准则的分组），以便实际进入网络的流量符合这些准则。 在图中，分组分类和标记机制（见解 I) 以及监管机制（见解2) 都一起在网络的边缘实现，或在端系统中实现，或在边界路由器中实现。
为流量类型之间提供隔离的一种互补的方法是，链路级的分组调度机制为每种类型明确地分配固定量的链路带宽。 例如，在R1能够给音频类型分配1Mbps, 能够给HTTP 流分配0. 5Mhps。 在这种情况下，音频和HTTP 流分别看到了容量为1Mbps 和0. 5Mbps 的逻辑链路。 通过严格执行链路级的带宽分配， 一种类型仅能够使用已经分配的带宽量；特别是， 它不能利用其他应用现在未使用的带宽。 例如，如果音频流静默了 （例如，如果谈话者停顿，不产生音频分组）， HTTP流在R1 到 R2 的链路上的传输带宽仍然不能够超过0.5Mbps, 即使音频流分配的 1Mbps带宽在那个瞬间没有使用。 由于带宽是一种资源，没有理由妨碍HTTP 流量使用没有由音频流使用的带宽。 我们将希望尽可能高效地使用带宽，当能够以别的方法使用它时决不浪费带宽。 这引发我们的第3个见解。
见解3: 当为流量类型或流之间提供隔离时，希望尽可能有效地使用资源（例如链路带宽和缓存）。 - 调度机制
属于各种网络流的分组混合在一起，并且在与链路关联的输出缓存排队等待传输。 选择在链路上传输的排队分组的方式称为链路调度规
则 (link-scheduling discipline) ,。 回想讨论过三种链路调度规则，即FIFO、 优先权排队和加权公平队列 (WFQ)。 - 监管： 漏桶（不作介绍）
- 漏桶＋加权公平排队＝队列中可证明的最大时延（不作介绍）
区分服务（不作介绍）
每连接服务质量保证：资源预约和呼叫准入（不作介绍）
参考目录
书籍：《计算机网络：自顶向下方法（第七版）》