计算机网络自顶向下方法 | 第2章 应用层

第2章 应用层

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

现代网络应用程序中所使用的两种主流的应用程序体系结构：客户-服务器体系结构(C-S)和对等体系结构(P2P)

客户-服务器体系结构：有一个总是打开的主机称为服务器，他服务于来自许多其他称为客户的主机的请求。

对等体系结构：应用程序在间断连接的主机对之间使用直接通信，这些主机对称为对等方。

2.1.2 进程通信

用操作系统的术语来说，进行通信的实际上是进程(process)而不是程序。

0. 客户和服务器进程

   在一对进程之间的通信会话场景中，发起通信的进程被标识为客户，在会话开始时等待联系的进程是服务器。

1. 进程与计算机网络之间的接口

   进程通过一个称为套接字(socket)软件接口向网络发送报文和从网络接受报文。套接字是同一台主机内应用层和运输层的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也被称为应用程序和网络之间的应用程序编程接口 (Application Programming Interface, API)

2. 进程寻址

   在因特网中，主机由其IP地址标识。除了知道这个报文发送目的地主机地址之外，发送进程还必须指定运行在接受主机上的接收进程（接收套接字），目的地端口号用于这个目的。

2.1.3 可供应用程序使用的运输服务

一个运输层协议能够为调用它的应用程序提供什么样的服务呢？

0. 可靠数据传输

1. 吞吐量

   具有吞吐量要求的应用程序被称为带宽敏感的应用(bandwidth-sensitive application)，如许多当前的多媒体应用。弹性应用(elastic application)能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。

2. 定时

   运输层协议也能提供定时保证。

3. 安全性

   运输层协议的能够对发送进程传输的数据加密和解密。

2.1.4 因特网提供的运输服务

0. TCP服务

   TCP服务模型包括面向连接服务和可靠数据传输服务。

   面向连接的服务：在握手阶段，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。

   可靠的数据传送服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。

1. UDP服务

   UDP服务是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，且没有拥塞控制机制。

PS：无论TCP还是UDP都没有提供任何加密机制，而隐私和其他安全问题对许多应用而言是至关重要的问题，故因特网界已经研制了TCP的加强版本，称为安全套接字层(Secure Sockets Layer, SSL)。(这种强化是在应用层上实现的)用SSL加强后的TCP不仅能够做传统TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。

PS 2：今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

2.1.5 应用层协议

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。

• 交换的报文类型（如请求报文和响应报文）
• 各种报文类型的语法（如报文中各个字段及这些字段是如何描述的）
• 字段的语义，及其中信息的含义
• 确定一个进程何时以及如何发送报文，对报文进行响应的规则

应用层协议只是网络应用的一部分（尽管是重要部分）

2.1.6 本书涉及的网络应用

Web、文件传输、电子邮件、目录服务、流式视频和P2P

2.2 Web和HTTP

2.2.1 HTTP概况

Web的应用层协议是超文本传输协议(HyperText Transfer Prototol, HTTP)，它是Web的核心。

Web页面（也叫文档）是由对象组成的。一个对象(object)只是一个文件，如一个HTML文件、一个JPEG图形、一个Java小程序，且它们可以通过一个URL地址寻址。多数Web页面含有一个HTML基本文件以及几个引用对象(如一个HTML基本文件加5个图形)，HTML基本文件通过对象的URL地址引用页面中的其他对象。

每个URL地址由两部分组成：存放服务器的主机名和对象的路径名

www.someSchool.edu/someDepartm…

主机名www.someSchool.edu 路径名：someDepartment/picture.gif

更详细的关于URL的说明：

Web浏览器实现了HTTP的客户端；Web服务器实现了HTTP的服务器端，用于存储Web对象，每个对象其由URL寻址。Web使用了客户-服务器应用程序体系结构。

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。

因为HTTP服务器并不保存关于客户的任何信息，所以我们说HTTP是一个无状态协议(stateless protocol)。

2.2.2 非持续连接和持续连接

非持续连接：每个请求/响应是经一个单独的TCP连接发送，下载多个对象需要多个TCP连接

持续连接：所有请求/响应经相同的TCP连接发送

非持续连接有一些缺点：

• 必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。
• 每一个对象经受两倍RRT(Round-Trip Time)的交付时延，即一个RRT用于创建TCP，另一个RRT用于请求和接收一个对象。

HTTP/0.9	HTTP/1.0	HTTP/1.1	HTTP/2	HTTP/3
非持续连接，只有GET请求方法	默认用非持续连接	默认使用持续连接	在HTTP/1.1基础上构建的，它允(yun)许在相同连接中多个请求和回答交错。可以在同一个tcp连接上同时跑多个http。真正意义上的tcp复用。	弃用TCP协议，改为使用基于UDP协议的QUIC协议实现

PS:

HTTP/3是即将到来的第三个主要版本的HTTP协议。与其前任HTTP/1.1和HTTP/2不同，在HTTP/3中，将弃用TCP协议，改为使用基于UDP协议的QUIC协议实现。

此变化主要为了解决HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用，受到TCP拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。

QUIC（快速UDP网络连接）是一种实验性的网络传输协议，由Google开发，该协议旨在使网页传输更快。在2018年10月28日的邮件列表讨论中，互联网工程任务组（IETF） HTTP和QUIC工作组主席Mark Nottingham提出了将HTTP-over-QUIC更名为HTTP/3的正式请求，并在最终确定并发布草案后，将QUIC工作组继承到HTTP工作组。在随后的几天讨论中，Mark Nottingham的提议得到了IETF成员的接受，他们在2018年11月给出了官方批准，认可HTTP-over-QUIC成为HTTP/3。

截至2022年2月，HTTP/3仍然是草案状态。

QUIC / HTTP 3.0 ：

• TCP or UDP ? (基于UDP)
• Kernel or Userspace ? (做在了Userspace里面)
• 0 RTT (天然支持https协议。传输层 0 RTT 就能建立连接，加密层 0 RTT 就能建立加密连接。)
• 弱网优势 (弱网环境下很容易丢包，那么HTTP 2.0就有队头阻塞，2.0所有的优化都付诸东流了)

2.2.3 HTTP报文格式

2.2.3.1 HTTP请求报文

补充： 方法字段：put是更改全部，patch是部分更改 。PUT是全局，PATCH是局部

2.2.3.2 HTTP响应报文

PS：一些常见的状态码和状态消息组合：

• 200 OK：请求成功，信息在返回的响应报文中
• 301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报文的Location:首部行中。客户软件将自动获取新的URL。
• 400 Bad Request：一个通用差错代码，指示该请求不能被服务器理解。
• 404 Not Found：被请求的文档不在服务器上。
• 505 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本。

2.2.4 用户与服务器的交互：cookie

一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来，为此，HTTP使用了cookie。

cookie技术有4个组件：

• 在HTTP响应报文中的一个cookie首部行
• 在HTTP请求报文中的一个cookie首部行
• 在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理
• 位于Web站点的一个后端数据库

2.2.5 Web缓存

Web缓存器(Web cache)也叫代理服务器(proxy server)，它是能够代表初始Web服务器来满足HTTP请求的网络实体。

Web缓存器既是服务器又是客户。当它接收浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接收响应时，它是一个客户。

部署Web缓存器的原因：

0. Web缓存器可以大大减少对客户请求的响应时间
1. Web缓存器能够大大减少一个机构的接入链路到因特网的通信量，故该机构不必急于增加带宽，因此降低了费用
2. Web缓存器能从整体上大大减低因特网上的Web流量，从而改善所有应用的性能

通过使用内容分发网络(Content Distribution Network, CDN)，Web缓存器正在因特网中发挥着越来越重要的作用。CDN公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。

2.2.6 条件GET方法

条件GET方法：HTTP协议允许缓存器证实它的对象是最新的这样一种机制。

若

• 请求报文使用GET方法
• 请求报文中包含一个"If-Modified-Slice:"首部行

那么这个HTTP请求报文就是一个条件GET请求报文。

2.3 因特网中的电子邮件

电子邮件三个主要组成部分：

• 用户代理(user agent)
• 邮件服务器(mail server)
• 简单邮件传输协议(Simple Mail Transfer Protocol, SMTP)

2.3.1 SMTP

像大多数应用层协议一样，SMTP也有两个部分：运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端。每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。

SMTP一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。

SMTP能依赖TCP提供的可靠数据传输无差错地将邮件邮递到接收服务器。该客户若有另外的报文要发送到该服务器，就在相同的TCP连接上重复这种处理；否则，它指示TCP关闭连接。

SMTP命令：握手协议的一部分，如HELO(HELLO缩写)、MAIL FROM、RCPT TO、DATA、QUIT。

SMTP使用25端口。

2.3.2 与HTTP的对比

SMTP	HTTP
邮件服务器-->邮件服务器	Web服务器-->Web客户
使用持续连接	使用持续连接
推协议(push protocol)	拉协议(pull protocol)
要求每个报文采用7比特ASCII码格式	不受这种限制
把所有报文对象放在一个报文之中	把每个对象封装到它自己的HTTP响应报文中

推协议：TCP连接是由要发送文件的机器发起的

拉协议：TCP连接是由想接收文件的机器发起的

2.3.3 邮件报文格式

• 首部行：每个首部必须含有一个From:首部行和一个To:首部行；可能包括一个Subject:首部行以及其他可选的首部行
• 空白行
• 报文体：以ACSII格式表示的报文体

2.3.4 邮件访问协议

0. POP3(Post Office Protocol-Version 3, 第三版的邮局协议)

   POP3 的特点是只要用户从服务器上读取了邮件，就把该邮件删除。但最新版本的 POP3 可以不删除邮件。

   POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。(IMAP解决了)

   POP3使用110端口。

1. IMAP(Internet Mail Access Protocol, 因特网邮件访问协议)

   IMAP 协议中客户端和服务器上的邮件保持同步，如果不手动删除邮件，那么服务器上的邮件也不会被删除。IMAP 这种做法可以让用户随时随地去访问服务器上的邮件。

   IMAP协议具有允许用户代理获取报文某些部分的命令。当用户和其邮件服务器间使用低宽带连接时，这个特性很有用，用户可以避免取回包含如音频或视频的大邮件。

2. 基于Web的电子邮件

   使用这种服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。

2.4 DNS：因特网的目录服务

因特网上的主机和人类一样，可以使用多种方式进行标识。主机的一种标识方法是用它的主机名。主机也可以使用所谓的IP地址进行标识。

2.4.1 DNS提供的服务

人们喜欢便于记忆的的主机名标识方式，而路由器喜欢定长的、有着层次结构的IP地址。为了折中这些不同的偏好，我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统(Domain Name System, DNS)的主要任务。

因特网体系结构的复杂性大多数位于网站的”边缘“。DNS通过采用了位于网络边缘的客户和服务器，实现了关键的名字到地址转换功能。

DNS是：

• 一个由分层的DNS服务器(DNS server)实现的分布式数据库
• 一个使得主机能够查询分布式数据库的应用层协议

DNS服务器通常是运行BIND软件的UNIX机器。DNS 并非只使用 UDP 协议，它同时占用了 UDP 和 TCP 的 53 端口。

---

虽然 UDP 速度更快，DNS 协议也确实大面积使用了 UDP，但是由于 UDP 面向报文、只能传输小于 512 字节的特性，DNS 并非只使用了 UDP，具体的 TCP 和 UDP 使用场景如下：

• DNS 在域名解析的过程中，会根据 DNS 响应报文的大小选择使用 TCP 还是 UDP。但是一般情况下，返回的 DNS 响应报文都不会超过 512 字节，所以事实上，很多 DNS 服务器进行配置的时候，也仅支持 UDP 查询包。
• DNS 在进行区域传输的时候使用 TCP 协议。

这方面具体说明详见network.51cto.com/article/658…

---

DNS还提供了一些重要的服务：

• 主机别名（为了好记）
• 邮件服务器别名（为了好记）
• 负载分配（DNS也用于在冗余的服务器之间进行负载分配）

2.4.2 DNS工作机理概述

DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映射。这种集中式设计的问题是：

• 单点故障：若该DNS服务器崩溃，整个因特网随之瘫痪
• 通信容量：单个DNS服务器不得不处理所有的DNS查询
• 远距离的集中式数据库：导致严重时延
• 维护：中央数据库异常庞大且需要频繁更新

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。

• 根DNS服务器
• 顶级域(DNS)服务器，即TLD服务器(Top-Level Domain)
• 权威DNS服务器

还有另一类重要的DNS服务器，称为本地DNS服务器（亦称默认名字服务器）：

• 并不严格属于层次结构
• 每个ISP(居民区的ISP、公司、大学)都有一个本地DNS服务器
• 当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器(起着代理的作用，将查询转发到层次结构中)

递归查询(recursive query)和迭代查询(iterative query)：

实践中，查询通常遵守上图中的模式：从请求主机到本地DNS服务器的查询是递归的，其余的查询是迭代的

为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术。

• DNS服务器在一段时间后（通常两天）将丢弃缓存的信息
• 因为缓存，除了少数DNS查询以外，根服务器被绕过了

2.4.3 DNS记录和报文

2.4.3.1 资源记录RR

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record, RR)，RR提供了主机名到IP地址的映射。

资源记录是一个包含了下列字段的4元组：

(Name, Value, Type, TTL)

TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间（默认两天）。

Name和Value的值取决于Type。

2.4.3.2 DNS报文

• 首部区域：前12个字节（三种类型的RR）
• 问题区域：包含着正在进行的查询信息，包括名字字段和类型字段
• 回答区域：包含了对最初请求的名字的资源记录
• 权威区域：包含了其他权威服务器的记录
• 附加区域：包含了其他有帮助的记录

2.4.3.3 WHOIS（域名数据库查询）

一个域名的所有者可以通过查询WHOIS数据库而被找到；对于大多数根域名服务器，基本的WHOIS由ICANN维护，而WHOIS的细节则由控制那个域的域注册机构维护。

对于240多个国家代码顶级域名（ccTLDs），通常由该域名权威注册机构负责维护WHOIS。例如中国互联网络信息中心（China Internet Network Information Center）负责.CN域名的WHOIS维护。

2.4.3.4 安全性

总的来说，DNS比较健壮。至今为止，还没有一个攻击已经成功妨碍了DNS服务。

2.5 P2P文件分发

0. 具有P2P体系结构的应用程序能够是自扩展的。这种扩展性的直接成因是：对等方除了是bit的消费者外还是它们的重新分发者。
1. BitTorrent是一种用于文件分发的流行P2P协议。其术语：洪流、追踪器、临近对等方、最稀缺优先、疏通。
2. 另一种P2P应用----分布式散列表(DHT)。其是一种简单的数据库，数据库记录分布在一个P2P系统的多个对等方上。DHT得到了广泛实现(如在BitTorrent中)。
3. 磁力链接是对等网络中进行信息检索和下载文档的电脑程序，以magnet:?开头，其后的参数无顺序规则

2.6 视频流和内容分发网

2.6.1 因特网视频

视频是一系列的图像，通常以一种恒定的速率（每秒24、30、60张图像）来展现。

2.6.2 HTTP流和DASH

HTTP流中，所有客户接收到相同编码速率的视频。

HTTP动态适应流(Dynamic Adaptive Streaming over HTTP, DASH)。在DASH中，视频编码为几个不同的版本，其中每个版本有不同的比特率。对应于不同的质量水平。DASH允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频，且客户可以自由地在不同的质量等级之间切换。

2.6.3 内容分发网

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网(Content Distribution Network, CDN)。有专用CDN，如谷歌的CDN分发YouTube视频和其他类型的内容；也有第三方CDN，它代表多个内容提供商分发内容。

为什么？ ：通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验。

CDN通常采用两种不同的服务器安置原则：

• 深入(部署服务器深入到ISP接入网中；较高的维护和管理开销；较低的时延)
• 邀请做客(在少量关键位置建造大集群来邀请到ISP做客；较低的维护和管理开销；较高的时延)

讨论过这两种部署CDN的重要方法后，现在深入看看CDN操作的细节。当用户主机中的一个浏览器指令检索一个特定的视频(由URL标识)时，CDN必须截获该请求，以便于：1.确定此时适合于该客户的CDN服务器集群；2.将客户的请求重定向到该集群的某台服务器。

大多数CDN利用DNS来截获和重定向请求：

任何CDN部署，其核心是集群选择策略，即动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。每种策略都有其优点和缺点(eg:地理上最为为邻近，实时测量)

2.7 套接字编程：生成网络应用

典型的网络应用是由一对程序（即客户程序和服务器程序)组成的，它们位于两个不同的端系统中。开发者创建一个网络应用时，其主要任务就是编写客户程序和服务器程序的代码。

每个进程好比是一座房子，该进程的套接字则好比是一扇门。应用程序位于房子中门的一侧；运输层位于该门朝外的另一侧。

2.7.1 UDP套接字编程

当生成一个套接字时，就为它分配一个称为端口号的标识符。

2.7.2 TCP套接字编程

与UDP不同，TCP是一个面向连接的协议。这意味着在客户和服务器能够开始互相发送数据之前，它们先要握手和创建一个TCP连接。TCP连接的一端与客户端套接字相联系，另一端与服务器套接字相联系。当创建该TCP连接时，我们将其与客户套接字地址(IP地址和端口号)和服务器套接字地址(IP地址和端口号)关联起来。使用创建的TCP连接，当一侧要向另一侧发送数据时，它只需经过其套接字将数据丢进TCP连接，这与UDP不同，UDP服务器在将分组丢进套接字之前必须为其附上一个目的地地址。

在三次握手期间，客户进程敲服务器进程的欢迎之门。当该服务器“听”到敲门声时，它将生成一扇新门(更精确地讲是一个新套接字)。它是专门对客户进行连接的新生成的套接字，称为连接套接字(connectionSocket)。

欢迎套接字：这是所有要与服务器通信的客户的起始接触点

连接套接字：这是随后为与每个客户通信而生成的套接字

下图中，serverSocket是欢迎套接字，循环中的connectionSocket是连接套接字。

1、一个端口只能被绑定一次，多个服务器进程不能绑定同一个端口

2、被绑定的端口可以被多个进程共用

3、多个进程可以使用同一个端口进行发送和接收，这就是共用

4、绑定≠共用