假设您有一个新的网络应用程序的想法。 也许这个应用程序会对人类有很大的帮助，或者会取悦你的教授，或者会给你带来巨大的财富，或者只是开发起来很有趣。 无论动机是什么，现在让我们来看看您如何将想法转化为现实世界的网络应用程序。<br />网络应用程序开发的核心是编写在不同终端系统上运行并通过网络相互通信的程序。 例如，在 Web 应用程序中有两个相互通信的不同程序：运行在用户主机（台式机、笔记本电脑、平板电脑、智能手机等）中的浏览器程序； 以及运行在 Web 服务器主机上的 Web 服务器程序。 再举一个例子，在诸如 Netflix 之类的视频点播应用程序中（参见第 2.6 节），有一个 Netflix 提供的程序在用户的智能手机、平板电脑或计算机上运行； 以及在 Netflix 服务器主机上运行的 Netflix 服务器程序。 服务器通常（但肯定不总是）位于数据中心内，如图 2.1 所示。<br />![image.png](https://cdn.nlark.com/yuque/0/2021/png/12377925/1635828606554-26179200-3db9-4c41-af76-de879a097dbf.png#clientId=u52a256fb-590e-4&from=paste&height=756&id=u104c5407&margin=%5Bobject%20Object%5D&name=image.png&originHeight=756&originWidth=749&originalType=binary&ratio=1&size=199384&status=done&style=none&taskId=uf657ae86-e374-459c-913a-ab27f809790&width=749)<br />**Figure 2.1 ♦ Communication for a network application takes place  between end systems at the application layer**<br />因此，在开发新应用程序时，您需要编写可在多个终端系统上运行的软件。 例如，该软件可以用 C、Java 或 Python 编写。 重要的是，您无需编写在网络核心设备（例如路由器或链路层交换机）上运行的软件。 即使你想为这些网络核心设备编写应用软件，你也做不到。 正如我们在第 1 章中学到的，以及前面的图 1.24 所示，网络核心设备不在应用层运行，而是在较低层运行——特别是在网络层及以下。 如图 2.1 所示，这种基本设计（即，将应用软件限制在终端系统中）促进了大量网络应用的快速开发和部署。

2.1.1 网络应用程序架构 Network Application Architectures

在深入研究软件编码之前，您应该为您的应用程序制定一个广泛的架构计划。 请记住，应用程序的架构明显不同于网络架构（例如，第 1 章中讨论的五层互联网架构）。 从应用程序开发人员的角度来看，网络架构是固定的，并为应用程序提供一组特定的服务。 另一方面，应用程序架构是由应用程序开发人员设计的，它规定了应用程序在各种终端系统上的结构。 在选择应用程序架构时，应用程序开发人员可能会利用现代网络应用程序中使用的两种主要架构范式之一：客户端-服务器（client-server）架构或点对点技术 (peer-to-peer，P2P) 架构。
在客户端-服务器架构中，有一个永远在线的主机，称为服务器，它为来自许多其他主机的请求提供服务，称为客户端。 一个典型的例子是 Web 应用程序，其中一个永远在线的 Web 服务器为来自客户端主机上运行的浏览器的请求提供服务。 当 Web 服务器收到来自客户端主机的对象请求时，它会通过将请求的对象发送到客户端主机来进行响应。 请注意，在客户端 - 服务器架构中，客户端不直接相互通信； 例如，在Web 应用程序中，两个浏览器不直接通信。客户端-服务器架构的另一个特点是服务器有一个固定的、众所周知的地址，称为 IP 地址（我们将很快讨论）。 因为服务器有一个固定的、众所周知的地址，而且因为服务器一直在运行，所以客户端总是可以通过向服务器的 IP 地址发送数据包来联系服务器。 一些比较知名的具有客户端-服务器架构的应用程序包括 Web、FTP、Telnet 和电子邮件。 客户端-服务器架构如图 2.2(a) 所示。

Figure 2.2 ♦ (a) Client-server architecture; (b) P2P architecture
通常在客户端-服务器应用程序中，单服务器主机无法跟上来自客户端的所有请求。例如，一个流行的社交网站如果只有一台服务器处理其所有请求，它很快就会不堪重负。因此，通常使用容纳大量主机的数据中心来创建功能强大的虚拟服务器。最流行的互联网服务——例如搜索引擎（如谷歌、必应、百度）、互联网商务（如亚马逊、易趣、阿里巴巴）、基于网络的电子邮件（如 Gmail 和雅虎邮件）、社交媒体（例如，Facebook、Instagram、Twitter 和微信）——在一个或多个数据中心运行。如 1.3.3 节所述，Google 在全球拥有 19 个数据中心，共同处理搜索、YouTube、Gmail 和其他服务。一个数据中心可能有数十万台服务器，必须对其进行供电和维护。此外，服务提供商必须为从其数据中心发送数据支付经常性的互连和带宽成本。
在 P2P 架构中，对数据中心专用服务器的依赖程度最低（或不依赖）。 相反，应用程序利用间歇连接的主机对之间的直接通信，称为对等点（peers）。 peers 不归服务提供商所有，而是由用户控制的台式机和笔记本电脑，大多数 peers 位于家庭、大学和办公室。 由于 peers 之间无需通过专用服务器即可进行通信，因此该架构称为点对点（peer-to-peer）。 流行的 P2P 应用程序的一个例子是文件共享应用程序 BitTorrent。
P2P 架构最引人注目的特性之一是它们的自扩展性（self-scalability）。 例如，在 P2P 文件共享应用中，虽然每个对等点通过请求文件产生工作负载，但每个对等点也通过向其他对等点分发文件来增加系统的服务能力。 P2P 架构也具有成本效益，因为它们通常不需要大量的服务器基础设施和服务器带宽（与具有数据中心的客户端-服务器设计相反）。 然而，P2P 应用程序由于其高度分散的结构而面临安全性、性能和可靠性的挑战。

2.1.2 进程通信 Processes Communicating

在构建网络应用程序之前，您还需要基本了解运行在多个终端系统中的程序如何相互通信。 用操作系统的术语来说，进行通信的实际上不是程序，而是进程（processes）。 进程可以被认为是在终端系统中运行的程序。 当进程在同一个终端系统上运行时，它们可以通过进程间通信相互通信，使用由终端系统的操作系统管理的规则。 但是在本书中，我们对同一主机中的进程如何通信并不特别感兴趣，而是对运行在不同主机（可能具有不同操作系统）上的进程如何通信感兴趣。
两个不同端系统上的进程通过跨计算机网络交换报文（messages）来相互通信。 发送进程创建报文并将其发送到网络中； 接收进程接收这些报文并可能通过发回报文进行响应。 图 2.1 说明了相互通信的进程驻留在五层协议栈的应用层。

客户端和服务器进程 Client and Server Processes

网络应用程序由成对的进程组成，这些进程通过网络相互发送消息。 例如，在 Web 应用程序中，客户端浏览器进程与 Web 服务器进程交换消息。 在 P2P 文件共享系统中，文件从一个对等点中的进程传输到另一个对等点中的进程。 对于每对通信进程，我们通常将两个进程中的一个标记为客户端（client），将另一个进程标记为服务器（server）。 对于 Web，浏览器是客户端进程，Web 服务器是服务器进程。 在 P2P 文件共享中，下载文件的点被标记为客户端，上传文件的点被标记为服务器。
您可能已经观察到，在某些应用程序中，例如在 P2P 文件共享中，进程可以既是客户端又是服务器。 事实上，P2P 文件共享系统中的进程可以上传和下载文件。 尽管如此，在一对进程之间的任何给定通信会话的上下文中，我们仍然可以将一个进程标记为客户端，将另一个进程标记为服务器。 我们定义客户端和服务器进程如下：

在一对进程之间的通信会话的上下文中，发起通信的进程（即在会话开始时最初联系另一个进程）被标记为客户端。 等待被联系以开始会话的进程是服务器。

在 Web 中，浏览器进程初始化与 Web 服务器进程的联系； 因此浏览器进程是客户端，Web 服务器进程是服务器。 在 P2P 文件共享中，当 Peer A 要求 Peer B 发送特定文件时，在此特定通信会话的上下文中，Peer A 是客户端，Peer B 是服务器。 如果没有混淆，我们有时也会使用术语“应用程序的客户端和服务器端”。 在本章的最后，我们将逐步介绍网络应用程序客户端和服务器端的简单代码。

进程与计算机网络之间的接口 The Interface Between the Process and the Computer Network

如上所述，大多数应用程序由成对的通信进程组成，每对中的两个进程相互发送消息。 从一个进程发送到另一个进程的任何消息都必须通过底层网络。 进程通过称为套接字（socket）的软件接口向网络发送消息和从网络接收消息。 让我们考虑一个类比来帮助我们理解进程和套接字。 一个进程类似于一所房子，它的套接字类似于它的门。当一个进程想要向另一台主机上的另一个进程发送报文时，它会将报文推出它的门（套接字）。 这个发送进程假设在其门的另一侧有一个传输基础设施，它将报文传输到目标进程的门。 一旦报文到达目标主机，报文就会通过接收进程的门（socket），然后接收进程对报文进行操作。
图 2.3 说明了通过 Internet 进行通信的两个进程之间的套接字通信。 （图 2.3 假设进程使用的底层传输协议是 Internet 的 TCP 协议。）如图所示，套接字是主机内应用层和传输层之间的接口。它也被称为应用程序和网络之间的应用程序编程接口 (Application Programming Interface，API)，因为套接字是构建网络应用程序的编程接口。应用程序开发人员可以控制套接字应用层一侧的所有内容，但几乎无法控制套接字的传输层一侧。应用程序开发人员在传输层方面的唯一控制是 (1) 传输协议的选择和 (2) 可能确定一些传输层参数的能力，例如最大缓冲区和最大段大小（maximum buffer and maximum segment sizes）（将在第 3 章讨论）。一旦应用程序开发人员选择了传输协议（如果有选择），应用程序就使用该协议提供的传输层服务构建。我们将在 2.7 节中更详细地探讨套接字。

Figure 2.3 ♦ Application processes, sockets, and underlying transport protocol

进程寻址 Addressing Processes

为了将邮政邮件发送到特定目的地，目的地需要有一个地址。 同样，为了让运行在一台主机上的进程向运行在另一台主机上的进程发送数据包，接收进程需要有一个地址。要识别接收进程，需要指定两条信息：(1) 主机的地址和 (2) 指定目标主机中接收进程的标识符。
在 Internet 中，主机由其 IP 地址标识。 我们将在第 4 章中详细讨论 IP 地址。现在，我们只需要知道 IP 地址是一个 32 位的数，我们可以将其视为唯一标识主机的数量。 除了知道消息目的地的主机地址之外，发送进程还必须识别在主机中运行的接收进程（更具体地说，接收套接字）。 需要此信息是因为通常主机可能正在运行许多网络应用程序。 目的端口号（destination port number）用于此目的。 常用的应用程序被分配了特定的端口号。 例如，Web 服务器由端口号 80 标识。邮件服务器进程（使用 SMTP 协议）由端口号 25 标识。可以在 www.iana 上找到所有 Internet 标准协议的常用的端口号列表 .org。 我们将在第 3 章详细研究端口号。

2.1.3 应用程序可使用的传输服务 Transport Services Available to Applications

回想一下，套接字是应用程序进程和传输层协议之间的接口。 发送端的应用程序通过套接字推送报文。 在套接字的另一端，传输层协议负责将报文发送到接收进程的套接字。
许多网络，包括 Internet，提供不止一种传输层协议。 开发应用程序时，必须选择可用的传输层协议之一。 你如何做出这个选择？ 最有可能的是，您会研究可用传输层协议提供的服务，然后选择最符合您的应用程序需求的服务的协议。 这种情况类似于在两个城市之间选择火车或飞机运输。您必须选择其中一种，每种运输方式提供不同的服务。 （例如，火车提供市区接送服务，而飞机提供较短的旅行时间。）
传输层协议可以为调用它的应用程序提供哪些服务？ 我们可以从四个维度对可能的服务进行大致分类：可靠的数据传输、吞吐量、时间和安全性。

可靠数据传输 Reliable Data Transfer

正如第 1 章所讨论的，数据包可能会在计算机网络中丢失。例如，数据包可能会溢出路由器中的缓冲区，或者在其某些位损坏后可能会被主机或路由器丢弃。对于许多应用程序——例如电子邮件、文件传输、远程主机访问、Web 文档传输和金融应用程序——数据丢失可能会带来毁灭性的后果（在后一种情况下，对于银行或客户！）。因此，为了支持这些应用程序，必须采取一些措施来保证应用程序一端发送的数据正确且完整地传送到应用程序的另一端。如果一个协议提供了这种有保证的数据传送服务，就说它提供了可靠的数据传输（reliable data transfer）。传输层协议可能为应用程序提供的一项重要服务是进程到进程的可靠数据传输。当传输协议提供此服务时，发送进程只需将其数据传递到套接字中，并完全确信数据将无误地到达接收进程。
当传输层协议不提供可靠的数据传输时，发送进程发送的某些数据可能永远不会到达接收进程。 这对于容错应用程序来说是可以接受的，最显着的是多媒体应用程序，例如可以容忍一定量数据丢失的对话音频/视频。 在这些多媒体应用程序中，丢失的数据可能会导致音频/视频中的小故障，而不是严重的损害。

吞吐量 Throughput

在第 1 章中，我们介绍了可用吞吐量的概念，在沿网络路径的两个进程之间的通信会话的上下文中，它是发送进程可以向接收进程传送比特的速率。因为其他会话将沿网络路径共享带宽，并且因为这些其他会话会来来往往，所以可用吞吐量会随时间而波动。 这些观察导致传输层协议可以提供的另一种自然服务，即以某个指定速率保证可用吞吐量。 使用这样的服务，应用程序可以请求保证的吞吐量为 r 位/秒，然后传输协议将确保可用的吞吐量始终至少为 r 位/秒。 这种有保证的吞吐量服务会吸引许多应用程序。
例如，如果 Internet 电话应用程序以 32 kbps 的速率对语音进行编码，则它需要将数据发送到网络并以该速率将数据传送到接收应用程序。 如果传输协议无法提供此吞吐量，则应用程序将需要以较低的速率进行编码（并接收足够的吞吐量以维持此较低的编码速率）或可能不得不放弃，因为接收所需吞吐量的一半是对这个互联网电话应用程序几乎没有用处或根本没有用处。 具有吞吐量要求的应用程序被称为带宽敏感应用程序（bandwidth-sensitive applications）。 许多当前的多媒体应用对带宽敏感，尽管一些多媒体应用可能使用自适应编码技术（adaptive coding techniques）以匹配当前可用吞吐量的速率对数字化语音或视频进行编码。
虽然带宽敏感的应用程序有特定的吞吐量要求，但弹性应用程序（elastic applications）可以使用尽可能多或尽可能少的吞吐量。 电子邮件、文件传输和 Web 传输都是弹性应用程序。 当然，吞吐量越大越好。 有句格言说，一个人不能太富有，太瘦，也不能有太多的吞吐量！

时间 Timing

传输层协议还可以提供时间保证。与吞吐量保证一样，时间保证可以有多种形式。一个保证示例可能是发送方泵入套接字的每一位都在不超过 100 毫秒后到达接收方的套接字。这种服务对交互式实时应用程序很有吸引力，例如互联网电话、虚拟环境、电话会议和多人游戏，所有这些应用程序都需要对数据传输进行严格的时间限制才能有效，参见 [Gauthier 1999;拉姆吉 1994]。例如，互联网电话的长时间延迟往往会导致对话中出现不自然的停顿；在多人游戏或虚拟交互环境中，执行操作和查看环境响应（例如，端到端连接结束时来自另一个玩家的响应）之间的长时间延迟会使应用程序感觉不太真实。对于非实时应用，低延迟总是优于高延迟，但对端到端延迟没有严格限制。

安全 Security

最后，传输协议可以为应用程序提供一个或多个安全服务。 例如，在发送主机中，传输层协议可以对发送进程传输的所有数据进行加密（encrypt），而在接收主机中，传输层协议可以在将数据传送到接收进程之前对数据进行解密。 这样的服务将在两个进程之间提供机密性，即使在发送和接收进程之间以某种方式观察到数据。 除了机密性之外，传输协议还可以提供其他安全服务，包括数据完整性和端点身份验证（data integrity and end-point authentication），我们将在第 8 章详细介绍这些主题。

2.1.4 互联网提供的传输服务 Transport Services Provided by the Internet

到目前为止，我们一直在考虑计算机网络通常可以提供的传输服务。 现在让我们更具体地研究互联网提供的传输服务类型。 Internet（以及更普遍的 TCP/IP 网络）为应用程序提供了两种传输协议：UDP 和 TCP。 当您（作为应用程序开发人员）为 Internet 创建新的网络应用程序时，您必须做出的第一个决定是使用 UDP 还是 TCP。 这些协议中的每一个都为调用应用程序提供了一组不同的服务。图 2.4 显示了一些选定应用程序的服务要求。

Figure 2.4 ♦ Requirements of selected network applications

TCP服务 TCP Services

TCP服务模型包括面向连接的服务和可靠的数据传输服务。 当应用程序调用 TCP 作为其传输协议时，应用程序会从 TCP 接收这两种服务。

• 面向连接的服务（Connection-oriented service）。TCP让客户端和服务器在应用程序级数据流开始之前互相交换传输层控制信息。 这种所谓的握手过程会向客户端和服务器发出警报，让它们为数据包的猛烈攻击做好准备。 在握手阶段之后，两个进程的套接字之间就存在一个 TCP 连接（TCP connection）。 该连接是全双工连接（full-duplex connection），两个进程可以同时通过该连接相互发送消息。当应用程序发送完消息后，它必须断开连接。 在第 3 章中，我们将详细讨论面向连接的服务并研究它是如何实现的。
• 可靠的数据传输服务（Reliable data transfer service）。 通信进程可以依靠 TCP 以正确的顺序无误地传送所有发送的数据。 当应用程序的一侧将字节流传递到套接字时，它可以依靠 TCP 将相同的字节流传送到接收套接字，而不会丢失或重复字节。

TCP 还包括拥塞控制机制（congestion-control mechanism），这是一种为 Internet 的整体福利服务，而不是为通信进程的直接利益服务。 当发送方和接收方之间的网络拥塞时，TCP 拥塞控制机制会限制发送进程（客户端或服务器）。 正如我们将在第 3 章中看到的，TCP 拥塞控制还试图将每个 TCP 连接限制在其公平的网络带宽份额。

UDP服务 UDP Services

UDP 是一种简洁、轻量级的传输协议，提供最少的服务。 UDP 是无连接的，因此在两个进程开始通信之前没有握手。 UDP 提供不可靠的数据传输服务——也就是说，当一个进程将消息发送到 UDP 套接字时，UDP 不保证该消息将永远到达接收进程。 此外，确实到达接收进程的消息可能会乱序到达。

FOCUS ON SECURITY 关注安全 保护 TCP TCP 和 UDP 都不提供任何加密——发送进程传递到其套接字的数据与通过网络传输到目标进程的数据相同。 因此，例如，如果发送进程以明文（cleartext）（即未加密）的形式将密码发送到其套接字中，则明文密码将通过发送方和接收方之间的所有链路，可能会在任何中间链路处被嗅探和发现。 由于隐私和其他安全问题对许多应用程序来说变得至关重要，因此 Internet 社区开发了 TCP 增强功能，称为传输层安全性 (Transport Layer Security，TLS) [RFC 5246]。 用TLS增强的TCP不仅完成了传统TCP所做的一切，而且还提供了关键的进程对进程的安全服务，包括加密、数据完整性和端点身份验证。我们强调，TLS 不是第三种互联网传输协议，与 TCP 和 UDP 处于同一级别，而是 TCP 的增强，其增强是在应用层实现的。 特别是，如果应用程序想要使用 TLS 的服务，它需要在应用程序的客户端和服务器端都包含 TLS 代码（现有的、高度优化的库和类）。 TLS 有自己的套接字 API，类似于传统的 TCP 套接字 API。 当应用程序使用 TLS 时，发送进程将明文数据传递给 TLS 套接字； 发送主机中的 TLS 然后加密数据并将加密的数据传递到 TCP 套接字。 在接收进程中，加密数据通过 Internet 传输到 TCP 套接字。 接收套接字将加密数据传递给 TLS，后者对数据进行解密。 最后，TLS 通过其 TLS 套接字将明文数据传递给接收进程。 我们将在第 8 章中详细介绍 TLS。

UDP 不包含拥塞控制机制，因此 UDP 的发送端可以随意将数据泵入下层（网络层）。（但请注意，由于中间链路的传输容量有限或由于拥塞，实际端到端吞吐量可能低于此速率）。

互联网传输协议未提供的服务Services Not Provided by Internet Transport Protocols

我们从四个维度组织了传输协议服务：可靠的数据传输、吞吐量、时间保证和安全性（reliable data transfer, throughput, timing, and security）。这些服务中哪些是由 TCP 和 UDP 提供的？我们已经注意到 TCP 提供可靠的端到端数据传输。而且我们也知道，TCP 可以很容易地在应用层用 TLS 进行增强，以提供安全服务。但是在我们对 TCP 和 UDP 的简要描述中，明显没有提到吞吐量或时间保证——当今的 Internet 传输协议没有提供这些服务。这是否意味着互联网电话等对时间敏感的应用程序无法在当今的互联网上运行？答案显然是否定的——互联网多年来一直在托管对时间敏感的应用程序。这些应用程序通常工作得很好，因为它们的设计目的是在最大程度上应对这种缺乏保证的情况。然而，当延迟过大或端到端吞吐量有限时，巧妙的设计有其局限性。综上所述，今天的互联网往往可以为时间敏感的应用程序提供令人满意的服务，但它无法提供任何时间或吞吐量保证。
图 2.5 显示了一些流行的 Internet 应用程序使用的传输协议。 我们看到电子邮件、远程终端访问、Web 和文件传输都使用 TCP。 这些应用程序选择 TCP 主要是因为 TCP 提供可靠的数据传输，保证所有数据最终都会到达其目的地。 由于 Internet 电话应用程序（例如 Skype）通常可以容忍一些丢失，但需要最低速率才能有效，因此 Internet 电话应用程序的开发人员通常更喜欢在 UDP 上运行他们的应用程序，从而绕过 TCP 的拥塞控制机制和数据包开销。 但是由于许多防火墙被配置为阻止（大多数类型的）UDP 流量，如果 UDP 通信失败，Internet 电话应用程序通常被设计为使用 TCP 作为备份。

Figure 2.5 ♦ Popular Internet applications, their application-layer protocols, and their underlying transport protocols

2.1.5 应用层协议 Application-Layer Protocols

我们刚刚了解到网络进程通过向套接字发送报文来相互通信。 但是这些报文是如何结构化的呢？ 报文中各个字段的含义是什么？ 进程何时发送报文？ 这些问题将我们带入了应用层协议的领域。 应用层协议（application-layer protocol）定义了运行在不同终端系统上的应用进程如何相互传递报文。 特别是，应用层协议定义了：

• 交换的报文类型，例如请求报文和响应报文（request messages and response messages）
• 各种报文类型的语法，例如报文中的字段（fields）以及字段的描述方式
• 字段的语义（semantics），即字段中信息的含义
• 用于确定进程何时以及如何发送报文和响应报文的规则

某些应用层协议在 RFC 中指定，因此属于公共领域。 例如，Web 的应用层协议 HTTP（超文本传输协议 [RFC 7230]）可用作 RFC。 如果浏览器开发人员遵循 HTTP RFC 的规则，浏览器将能够从任何也遵循 HTTP RFC 规则的 Web 服务器检索网页。许多其他应用层协议是专有的，有意在公共领域不可用。 例如，Skype 使用专有的应用层协议。
区分网络应用程序和应用层协议很重要。 应用层协议只是网络应用程序的一部分（尽管从我们的角度来看，这是应用程序的一个非常重要的部分！）。 让我们看几个例子。 Web 是一种客户端-服务器应用程序，允许用户按需从 Web 服务器获取文档。 Web 应用程序由许多组件组成，包括文档格式标准（即 HTML）、Web 浏览器（例如 Chrome 和 Microsoft Internet Explorer）、Web 服务器（例如 Apache 和 Microsoft 服务器）以及一个应用层协议。 Web 的应用层协议 HTTP 定义了浏览器和 Web 服务器之间交换的消息的格式和顺序。因此，HTTP 只是 Web 应用程序的一部分（尽管很重要）。 作为另一个例子，我们将在 2.6 节中看到 Netflix 的视频服务也有许多组件，包括存储和传输视频的服务器、管理计费和其他客户端功能的其他服务器、客户端（例如，智能手机、平板电脑或电脑上的Netflix应用程序），应用程序级 DASH 协议定义了 Netflix 服务器和客户端之间交换的消息的格式和顺序。 因此，DASH 只是 Netflix 应用程序的一部分（尽管很重要）。

2.1.6 本书涉及的网络应用程序 Network Applications Covered in This Book

每天都在开发新的应用程序。 我们没有以百科全书的方式涵盖大量的 Internet 应用程序，而是选择关注少数普遍且重要的应用程序。在本章中，我们将讨论五个重要的应用程序：Web、电子邮件、目录服务 、视频流和 P2P 应用程序（the Web, electronic mail, directory service, video streaming, and P2P applications）。 我们首先讨论 Web，不仅因为它是一个非常流行的应用程序，还因为它的应用层协议 HTTP 简单易懂。然后我们讨论电子邮件，互联网的第一个杀手级应用程序。 电子邮件比 Web 更复杂，因为它使用的不是一种而是多种应用层协议。在电子邮件之后，我们将介绍 DNS（Domain Name System），它为 Internet 提供目录服务。 大多数用户不直接与 DNS 交互； 相反，用户通过其他应用程序（包括 Web、文件传输和电子邮件）间接调用 DNS。 DNS 很好地说明了一个核心网络功能（网络名称到网络地址的转换）是如何在互联网的应用层实现的。 然后我们讨论 P2P 文件共享应用程序，并通过讨论按需视频流来完成我们的应用程序研究，包括通过内容分发网络（content distribution networks）分发存储的视频。