应用层是计算机网络从上往下的第一层，这一层的主要内容是网络应用的原理和实现，通过学习几种常见的网络应用程序，并且开发运行在TCP和UTP(运输层)上的网络应用程序，这些应用程序包含Web、电子邮件、DNS、P2P等等。

应用层协议

开发网络应用程序是要开发运行在不同端系统上并且通过网络(下层协议)彼此通信的程序，这过程中不需要为下层的网络核心设备写程序，因为它们不在应用层上起作用。

网络应用程序体系结构

客户——服务器体系结构：

• 客户：发送主机请求
• 服务器：总是打开的主机，接收来自客户的请求

举例：Web应用程序

P2P体系结构

• 对于数据中心服务器几乎没有依赖。
• 应用程序在对等方之间直接通信
• 具有自扩展性，报文在主机之间直接发送，服务器用来追踪IP，有安全隐患。

举例：BitTorrent、Skype

进程通信

端系统之间的通信实际上是进程，进程通过跨越网络发送报文来进行通信。进程是运行在端系统上的程序，同一个端系统和不同端系统之间的进程都可以进行通信，这里主要讨论不同端系统之间跨越网络的通信。

客户与服务器之间的进程：

• 客户-服务器体系中，比如Web服务器，一个进程被标识为客户(Client)，另一个进程被标识为服务器(Server)。
• P2P体系中，一个进程既可以是客户又可以是服务器。

进程与网络之间的接口——套接字：

套接字(端口号)是应用程序和运输层之间的接口，也成为应用程序编程接口。

进程寻址：

为了向特定的目的地发送报文，需要有目的地主机的相关信息，这些信息为：

• IP地址：用来标识目的地主机。
• 端口号：用来指定接受进程(即接受套接字)，例如Web服务器用端口号80标识，邮件服务器进程用25标识。

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

开发应用程序时，需要选择一种适合的运输层协议，运输层协议能够提供的服务主要有以下：

• 可靠数据传输：进程与进程之间的可靠数据传输，有不提供可靠数据传输的应用层协议，使用这种应用层协议的应用被称为容忍丢失的应用。

• 吞吐量：发送进程向接收进程交付比特的速率，所以运输层协议可以提供以特定速率确保的可用吞吐量的服务，对此有需求的应用称为带宽敏感应用，如一些多媒体语音和视频应用。

• 定时（延迟）：例子：发送方注入比特至套接字到接收方烧到比特的时间不多于100ms，这对于实时交互应用很重要，例如多方射击游戏。

因特网提供和未提供的运输服务

因特网为应用程序提供两个运输层协议，TCP和UDP，开发者必须做出选择。

TCP服务：

• 面向连接服务：报文数据流动前，TCP让客户和服务器交换运输层控制信息(即握手)，之后一个TCP连接就建立了，这条连接是全双工的，应用程序运行结束后要拆除该连接。
• 可靠数据传输服务：无差错、按顺序交付报文。
• 拥塞控制机制

安全套接字层(Secure Sockets Layer, SSL)，是加强版的TCP协议，提供了进程之间的安全加密服务，这种强化是在应用层上实现的。

UDP服务：

是一种轻量运输协议，进程通信时无握手过程，不保证到达，同时无拥塞控制机制。

注，这里只是简要的内容，更多详细内容将在第三章运输层中提到。

未提供的服务：

以上两个协议提供了可靠数据传输、安全性相关的服务，但并未提供2.3中所述的吞吐量和定时的服务，所以因特网并不提供这两项服务。虽然未提供具体的服务，但因特网已经运行很多年，对于时间敏感的应用已经被设计得尽可能应对这种保证的缺乏。

应用层协议总结

应用层协议定义了以下内容：

• 交换的报文类型，如请求和响应报文
• 报文语法
• 字段语义
• 确定进程何时发送报文

Web和HTTP

HTTP概况

**超文本传输协议（HyperText Transfer Protocol，HTTP）**是Web的应用层协议，它由客户程序和服务器程序实现，客户和服务器运行在不同端系统中，通过HTTP报文进行会话。

Web页面是由对象组成的，一个对象只是一个文件，如一个HTML文件、一张JEPG图片、一段视频，它们可以由URL寻址(URL地址由两部分组成，主机名和路径)。多数Web页面由一个HTML基本文件和一些对象组成。

HTTP使用TCP作为支撑运输协议，客户首先发起一个与服务器的TCP连接，建立连接后浏览器和服务器就可以通过套接字进行交互。

HTTP是一个无状态协议，服务器不会储存客户的状态信息，无论用户进行多少次的重复请求，服务器都会做出反应。

非持续性连接和持续性连接

非持续性连接：客户服务器之间的请求和响应都是经一个单独的TCP连接发送。

持续性连接：二者之间的请求和响应经过相同的TCP连接发送。

采取非持续性连接的HTTP：

• 往返时间（Round-Trip Time，RTT）：该时间指一个短分组从客户到服务器再返回服务器所花的时间。
• 必须为每一个请求的对象建立一个全新的TCP连接，每个连接都需要在客户和服务器中分为TCP缓冲区和保持TCP变量，这会给服务器带来巨大负担；并且每个对象要经历两倍RTT交付时延，一个RTT用于创建TCP连接，另一个RTT用于请求和接受一个对象。

采取持续性连接的HTTP：

• HTTP 1.1 连接下，服务器发送响应后保持该TCP连接打开，相同客户和服务器之间，后续的请求和响应报文能够通过相同的连接传送。如果一条连接经过一段时间间隔未使用，则HTTP服务器就会关闭它。
• HTTP/2 允许相同连接中的多个请求和回答相互交错。

HTTP报文格式

请求报文：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu	#指明了对象所在主机
Connection: close	#让服务器在发送完被请求对象后就关闭这条连接
User-agent: Mozilla/5.0		#浏览器类型
Accept-language: fr		#语言

• 第一行为请求行，共有三个字段：

  • 方法字段：可取：GET、POST、HEAD、PUT、DELETE，绝大部分请求使用GET。
  • URL字段：带有请求对象的标识
  • HTTP版本字段

• 第一行后的后继行都叫首部行，具体意义见程序。

• 首部行后有一个实体体(entity body)，使用GET请求时实体体为空，而当使用POST方法时才使用该实实体。

  • 用户提交表单时，HTTP客户常常使用POST方法，例如用户向搜索引擎提供搜索关键字时。
  • 使用POST报文时仍然可以请求Web页面，但Web内容依赖于用户在表单中字段中输入的内容。

  用表单生成的请求报文不是必须使用POST方法，相反也经常使用GET方法，并在所请求的URL中包括输入的数据

• HEAD方法类似于GET方法，服务器收到一个HEAD方法的请求时，会用一个HTTP报文进行响应但并不会返回请求的对象，该方法常用在调试跟踪中.

• PUT方法被那些需要向Web服务器上传对象的应用程序使用，DELETE方法允许应用程序删除服务器上的对象。

响应报文：

HTTP/1.1 200 OK
Connection: close	#发送完报文后关闭该TCP连接
Date: Tue, 18 Aug 2015 15:44:04 GMT		#指示服务器产生并发送该响应报文的日期和时间
Server: Apache/2.2.3 (CentOS)	#服务器类型及系统，对应于请求报文中的User-agent字段
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT	#对象创建或最后修改的日期和时间
Content-Length: 6821	#被发送对象的字节数
Content-Type: text/html		#对象类型

(data data data ...)

• 一个初始状态行(第一行)：三个字段，协议版本字段、状态码和相应状态信息
• 6个首部行(2至7行)
• 实体体：报文的部分，即包含了所请求的对象本身。

状态码和它们对应的短语：

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

cookie

HTTP服务器是无状态的，但一个Web站点希望能够识别用户身份，所以HTTP使用cookie允许站点对用户进行追踪。

cookie技术组件：

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

一般工作流程：

第一次访问某个Web服务器时，服务器会为用户创建一个ID，这个ID会通过响应报文中的一个首部行传给端系统，记录在cookie文件中，同时这个ID被记录在服务器的后端数据库中；当再次访问这个网站时，浏览器会查询cookie文件并抽取对于该网站的识别码，并放到HTTP请求报文的cookie首部中，此时服务器可以跟踪该用户在站点的活动，显示一些内容，比如浏览购物网站会提供上次加入购物车的内容。

Web缓存

即使用代理服务器，proxy server；代理服务器是能代表初始Web服务器来满足HTTP请求的网络实体。

部署Web缓存器的原因：

• 能大大减少对客户请求的响应时间
• 减低因特网上的Web流量，改善应用性能

条件GET方法

虽然高速缓存能减少响应时间，但也有一个问题，存放在缓存器中的对象副本可能是陈旧的，而HTTP有一种机制，允许缓存器证实它的对象是最新的，即条件GET方法。

条件GET：

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

代理服务器代表请求浏览器向Web服务器发送一个请求报文，Web服务器向缓存器发送具有请求对象的响应报文，缓存器将对象转发到浏览器的同时也在本地缓存了该对象，重要的是也同时储存占了最后修改日期；一段时间后，另一个用户通过该缓存器请求同一个对象，该对象可能已经被修改了，所以缓存器发送一个条件GET执行最新检查，该条件GET包含If-Modified-Since:首部行，该报文告诉服务器，只有当自指定日期后该对象被修改过，才发送该对象。

DNS:因特网目录服务

主机可以使用主机名(hostname)或是IP地址来进行标识，显然主机名更容易被人们记住，但路由器更喜欢定长的、有层次地IP地址，所以需要一个能进行主机名到IP地址的转换目录服务。这即是域名系统(Domain Name System, DNS)

DNS提供的服务

DNS组成：

• 由分层的DNS服务器实现的分布式数据库
• 使主机能查询分布式数据库的应用层协议，DNS服务器通常是运行BIND软件的UNIX机器
• DNS协议运行在UDP上，使用53号端口

主机名到IP地址的转换：

• 同一台主机上运行着DNS应用的客户端
• 浏览器从一条URL中抽取出主机名，将主机名传给DNS应用的客户端
• DNS客户端向服务器发出包含主机名的请求
• DNS客户收到回答报文，其中包含对应主机名的IP
• 浏览器收到来自DNS的IP地址，向位于该IP地址80端口的HTTP服务器发起一个TCP连接

DNS提供的其他服务：

• 主机别名：主机名可以拥有一个或多个别名，最初的主机名称为规范主机名，浏览器可以通过调用DNS来获得一个主机别名对应的规范主机名以及主机IP地址
• 负载分配：
  • 一个繁忙的站点会被冗余在多台服务器上，每台服务器都有着不同的IP地址；所以由于这些冗余服务器的存在，一个IP地址集合于同一个规范主机名相联系
  • 当用户对映射到某地址集合的主机名发出DNS请求时，该DNS服务器用IP地址的整个集合进行响应，但在每个回答中循环这些地址的次序；客户总是向IP地址排在最前面的服务器发送HTTP请求，所有DNS就在有冗余的Web服务器之间循环分配了负载。

DNS工作机理

DNS由分布于全球的大量DNS服务器以及定义了DNS服务器于查询主机之间通信方式的应用层协议组成。集中式DNS设计(全球公用一台DNS服务器)的问题：单点故障、通信容量、远距离延时、维护。

分布式、层次数据库：

如图，有三个类型的服务器：根DNS服务器、顶级域DNS服务器、权威DNS服务器

• 根DNS服务器：由400多个根名字服务器，由不同组织管理，提供顶级域服务器的IP地址。
• 顶级域(Top-Level Domain, TLD)DNS服务器：每个顶级域(包括国家顶级域)都有TLD服务器，提供权威DNS服务器的IP地址。
• 权威DNS服务器：具有公共可访问主机的组织机构必须提供公共可访问的DNS记录；一个组织机构可通过：
  • 构建自己的权威DNS服务器
  • 租用服务商提供的权威DNS服务器

还有一类称为本地DNS服务器，这类服务器不属于上图所示的层次结构；每个ISP都有一台本地DNS服务器，本地DNS服务器于主机之间距离很近，甚至可能在同一个局域网中，它起代理作用，并将DNS请求转发到DNS服务器层次结构中。

DNS查询：

DNS查询一般分为两类：递归查询、迭代查询

• 递归查询：DNS服务器收到客户机请求时，必须使用一个准确的查询结构回复客户机，如果DNS服务器本地没有储存DNS信息，该服务器会向其他服务器询问，并将返回的查询结果提交给客户机。
• 迭代查询：DNS服务器会向客户机提供其他能够解析查询请求的DNS服务器地址，当客户机发送请求时，DNS服务器不直接返回结果，而是告诉客户机另一台DNS服务器地址，客户机再想这台服务器体提交请求，一次循环到返回查询结果为止。

所以图中请求主机和本地DNS服务器之间为递归查询，本地DNS服务器和其他DNS服务器之间为迭代查询。

DNS缓存：

DNS缓存用来改善延时性能并减少在因特网上传输的DNS报文数，例如上图所示，当本地服务器从某个DNS服务器接收到一个回答，他能缓存包含在该回答内的任何信息，当一个主机向本地DNS服务器查询已经缓存的地址时就能够直接将IP地址返回给主机。而主机名与IP地址间的映射不是永久的，DNS服务器一般在一段时间(通常设置为两天)后丢弃缓存信息。

DNS记录和报文：

DNS服务器存储了资源记录(Resource Record, RR)，RR提供了主机名到IP地址的映射。

资源记录元组：

(Name, Value, Type, TTL)

• TTL是该记录的生存时间，决定了资源记录应当从缓存中删除的时间。
• Name和Value的值取决于Type：
  • Type = A，则Name是主机名，Value是主机名对应的IP地址
  • Type = NS，则Name是一个域(如foo.com)，而Value知道如何获得该域中主机IP地址的权威DNS服务器的主机名。
  • Type = CNAME，则Value是别名为Name的主机对应的规范主机名，如(foo.com, relay1.bar.foo.com, CNAME)。
  • Type = MX，则Value是个别名为Name的邮件服务器对应的规范主机名。

DNS报文：

DNS报文有查询和回答两种，且两种报文的格式相同。

• 首部区域：前12字节为首部区域，有6个字段
  • 标识符：16比特的数，用于标识该查询。该标识符会被复制到回答报文中，以便匹配。
  • 标志字段：有若干标志
    • 1比特的“查询/回答”标志位
    • 1比特的“权威的”标志位
    • 1比特的“希望递归”标志位，用户在该DNS服务器没有某记录时希望它执行递归查询
    • 1比特的“递归可用”标志位
  • 4个有关数量的字段，指出了4类数据区域出现的数量
• 问题区域：包含正在进行的查询信息
  • 名字字段：包含正在查询的主机名字
  • 类型字段：包含Type的值
• 回答区域：来自DNS服务器的回答报文，包含了对最初请求名字的资源记录，即(Name, Value, Type, TTL)；回答区域可以包含多条RR，所以一个主机名能有多个IP地址。
• 权威区域：包含了其他权威服务器的记录。
• 附加区域：其他有帮助的信息

DNS脆弱性，一种针对DNS的攻击时分布式拒绝服务（DDos）。

P2P文件分发

P2P体系结构对基础设施服务器几乎没有依赖，成对间歇连接的主机(对等放)彼此直接通信。

P2P体系结构的扩展性

客户——服务器体系和P2P体系的比较，结论为在相同的网络速率环境下，随着分发文件数量的增加，P2P的最小分发时间与客户——服务器体系相比差距越来越大，优势越来越明显。

BitTorrent

BT是一种用于文件分发的流行P2P协议，参与一个特定分发文件的所有对等方的集合被称为一个洪流(torrent)，一个洪流中的对等方彼此下载等长度的文件块，典型长度为256KB.

当一个对等方首次加入一个洪流，它没有块，随着时间的流逝，它累计了越来越多的块，同时也为其他对等放上载了多个块；当对等方获得了整个文件，它也许离开洪流，也许留在洪流中并继续向其他对等方上载块。

• 追踪器：每个洪流都具有一个的基础设施节点；当一个对等方加入洪流时，他向追踪器注册自己，并周期性地通知追踪器它仍在洪流中。一个给定的洪流可能在任何时刻具有数以百计或千计的对等方。

任何给定时间，每个对等方将具有来自该文件的块的子集，并且不同对等方有不同子集。一个对等方经TCP连接周期性地询问每个邻近对等方它们所具有的块列表，然后对当前没有的块发出请求。

那么对等方应该向它的邻居请求哪些块呢？应向哪些向它请求的邻居发送块？

• 最稀缺优先技术：针对自己没有的块，在邻居中寻找这些块的副本最少的，并首先请求这些稀缺的块，这也可以同时均衡每个块在洪流中的副本数量。

• 对换算法：对等方根据当前能够以最高速率向他提供数据的邻居给出优先权；并且确定向流入速率前四的邻居提供数据，且每隔10秒就重新计算速率并重新确定4个对等方，这4个对等方被称为疏通。每过30秒对换方将重新选择一名新的对换伴侣并开始与那位伴侣进行对换，并且如果二者直接都满足对换算法规则，那么互相将对方放入自己的前4人中，这样能使对等方趋于找到彼此的协调速率上载。

视频流和内容分发网

HTTP流和DASH

在HTTP流中，视频是指存储在HTTP服务器中的一个文件，每个文件有特定的URL，用户要看视频时，客户与服务器创建一个TCP连接并对URL发送HTTP GET请求，服务器在HTTP响应报文中发送该视频；在客户一侧，视频字节被收集在客户应用缓存中，当缓存中的字节量超过预先设定的门槛，客户应用程序就开始播放视频。

• 经HTTP的动态适应性流(Dynamic Adaptive Streaming over HTTP, DASH)：DASH中视频被编码为几个不同版本，每个版本有不同的比特率(画质)，当用户的可用带宽较高时，自然选择来自高速率版本的块，同时可用带宽较低时自然选择低速率的块。
• 告示文件：存在于HTTP服务器中，为每个版本提供一个URL及其比特率。

内容分发网

内容分发网(Content Distribution Network, CDN)：是现在主流视频流公司用来向全世界用户分发视频数据的部署在全球多个地理位置的服务器，服务器中存储了视频和其他相关内容的副本。

CDN服务器安置原则：

• 深入：靠近端用户，改善时延和吞吐量。
• 邀请做客：通过在少量关键位置建造大集群来邀请ISP做客，通常将这些集群放置在因特网交换点(IXP).

CDN集群部署就绪后就可以跨集群复制内容，并进行一系列视频管理操作。

CDN操作：

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

• 用户访问位于内容提供商的Web页面
• 用户点击视频链接时，用户发哦是那个了一个对于该视频链接的DNS请求
• 用户的本地DNS服务器（LDNS）将该请求中继到一台权威DNS服务器上，权威服务器并不返回一个IP地址，而是返回自己租用的内容服务器的主机名
• 此时DNS请求进入内容服务器专用DNS基础设施，LDNS发送第二个请求，基础设施DNS服务器最终返回内容服务器的IP地址
• 客户收到内容服务器的IP地址后，创建一条TCP连接，并发送HTTP GET 请求，若使用了DASH，服务器将首先向客户发送具有URL列表的告示文件，对应了不同版本视频，客户动态地选择不同版本

集群选择策略：

如上CDN操作所示，CDN得知该用户LDNS服务器的IP地址后，需要基于IP地址选择一个适当的集群，一般采用专用的集群选择策略。

• 地理上最为邻近的集群：每个LDNS 的IP地址都映射到一个地理位置，CDN选择地理上最为接近的集群。
• 当前流量条件：CDN能对当前集群和客户之间的时延和丢包性能进行周期性实时测量，基于此来选择。

最后修改于 2021-11-20