计算机网络之应用层

二.应用层

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

现代网络应用程序有二种主流体系结构，分别是：

1.客户-服务器（C/S）体系结构

有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。典型的例子就是web应用程序，其中总是打开的Web服务器服务于来自浏览器的请求，浏览器运行在客户主机上。

2.P2P体系结构

P2P体系结构对位于数据中心的专用服务器有最小的 （或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信 ，这些主机对被称为对等方，这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。许多目前流行的、流量密集型应用都是 P2P 体系结构的，这些应用包括文件共享（例如 BitTorren） 、对等方协助下载加速器（例如迅雷）、因特网电话和视频会议（例如 Skype）。

3.C/S体系结构和P2P体系结构的混合

某些应用具有混合的体系结构，它结合了客户－服务器和 P2 元素。例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的 IP 地址，但用户到用户的报文在用户主机之间 （无须通过中间服务器）直接发送。

2.1.2 进程通信

用操作系统的术语来说，进行通信的实际上是进程， 而不是程序，一个进程可以被认为是运行在端系统中的一个程序，当多个进程运行在相同的端系统上时 ，它们使用进程间通信机制相互通信， 进程间通信的规则由端系统上的操作系统确定。在这里并不特别关注同一台主机上的进程间的通信，而关注运行在不同端系统（可能具有不同的操作系统）上的进程间的通信。

1.客户和服务器进程

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

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

大多数应用程序是由通信进程对组成， 每对中的两个进程互相发送报文，从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文。

套接字：

下图显示了两个经过因特网通信的进程之间的套接字通信（假定由该进程使用的下面运输层协议是因特网的 TCP 协议。如该图所示，套接字是同一台主机内应用层与运输层之间的接口由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口 (Applicaion Programming Interface, API ) 。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权 应用程序开发者对千运输层的控制仅限千： 选择运输层协议； 也许能设定几个运输层参数，如最大缓存和最大报文段长度等（将在后面涉及） 。一旦应用程序开发者选择了一个运输层协议 ，则应用程序就建立在由该协议提供的运输层服务之上 

3.进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程， 需要定义两种信息：接收进程所在主机的地址、在目的主机中指定接收进程的标识符。

在因特网中，主机由IP地址来标识，接受进程由端口号来标识

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

1.可靠数据传输

分组在计算机网络中可能丢失，像电子邮件、文件传输、远程主机访问、Web 文档传输以及金融应用等这样的应用，数据丢失可能会造成灾难性的后果。因此，为了支持这些应用，必须做一些工作以确保由应用程序的发送端发送的数据正确完全地交付给该应用程序的另一端，如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输，当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。

当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程,这可能能被容忍丢失的应用所接受，最值得注意的是多媒体应用，如交谈式音频／视频，它们能够承受一定量的数据丢失，在这些多媒体应用中，丢失的数据引起播放的音频／视频出现小干扰，而不是致命的损伤。

2.吞吐量

即运输层协议能够以某种特定的速率提供确保的可用吞吐量，使用这种服务，该应用程序能够请求 r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少r比特/秒 。

3.定时

运输层协议也能保证定时服务，一个保证的例子如： 发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。

4.安全性

运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由 发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。

2.1.4 因特务提供的运输服务

1. TCP 服务

TCP 服务模型包括面向连接的服务和可靠数据传输服务，当某个应用程序调用TCP作为其运输协议时，该应用程序就能获得来自 TCP 的这两种服务

面向连接的服务：

在应用层数据报文开始流动之前， TCP 让客户和服务器互相交 换运输层控制信息，这个所谓的握手过程提醒客户和服务器，让它们为大 分组 的到来做好准备 在握手阶段后，一个 TCP 连接就在两个进 程的套接字之间建立了，这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。

可靠数据传输服务：

通信进程能够依靠 TCP, 无差错、按适当顺序交付所有发送的数据，当应用程序的一端将字节流传进套接字时，它能够依靠TCP 将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。

拥塞控制机制：

这种服务不一定能为通信进程带来直接好处 ，但能为因特网带来整体好处，当发送方和接收方之间的网络出现网络拥塞时，TCP 的拥塞控制机制会抑制发送进程（客户或服务器）。

2.UDP服务

UDP 是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务，UDP 是无连接的，因此在两个进程通信前没有握手过程，UDP 协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进 UDP 套接字时， UDP 协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达。

UDP也没有拥塞控制机制，所以 UDP 的发送端可以用它选定的任何速率向其下层 （网络层）注入数据。

3.因特网运输层协议所不提供的服务

TCP 在应用层可以很容易地用 SSL 来加强以提供安全服务，但目前的因特网运输层协议还没有提供吞吐量或定时保证的服务。

2.1.5 应用层协议

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

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

公有域和私有域协议：

有些应用层协议是由 RFC 文档定义的，因此它们位于公共域中。例如， Web 的应用层协议HTTP 就作为一个 RFC 可供使用。如果浏览器开发者遵从 HTTP RFC 规则，所开发出的浏览器就能访问任何遵从该文档标准的 Web 服务器，并获取相应 Web 页面。但还有很多别的应用层协议是专用的，有意不为公共域使用。例如微信、支付宝、淘宝等。

网络应用和应用层协议的区别：

应用层协议只是网络应用的一部分。我们来看个例子，Web 是一种客户-服务器应用，它允许客户按照需求从 Web 服务器获得文档 ，Web 应用有很多组成部分， 包括文档格式的标准（即 HTML) ，Web 浏览器（Firefox）， Web 服务器（如 Apache），以及一个应用层协议（HTTP）。

2.2 Web和HTTP

20 世纪 90 年代初期， 一个主要的新型应用，即万维网 （World Wide Web) 登上了舞台，Web是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。

2.2.1 HTTP概况

1.Web 的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP) , 它是 Web 的核心。

2.HTTP 由两个程序实现： 一个客户程序和一个服务器程序，客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话，HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式。

3.HTTP 使用 TCP 作为它的支撑运输协议。

4.HTTP 是一个无状态的协议，服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。

2.2.2 非持续连接和持续连接

每个请求 / 响应对是经一个单独的 TCP 连接发送，还是所有的请求及其响应经相同的 TCP 连接发 送呢？采用前一种方法， 该应用程序被称为使用非持续连接; 采用后一种方法，该应用程序被称为使用持续连接。

1.采用非持续连接的HTTP：

每个HTTP的请求响应对如果是经一个单独的TCP连接发送，那么该应用程序使用非持续连接。

2.采用持续连接的HTTP：

如果HTTP的所有的请求及其响应经相同的TCP连接，那么该应用程序被称为使用持续连接。

2.2.3 HTTP报文格式

1.HTTP请求报文

请求报文格式：整个请求报文分为请求行、首部行、实体体。请求行有三个字段，方法字段、URL字段、HTTP版本字段。

方法字段
方法字段可以取GET、POST、HEAD、PUT、DELETE。

• GET：使用GET方式时，实体体为空。
• POST：使用POST方式时，才使用实体体。
• HEAD：HEAD类似于GET方法，当服务器收到使用HEAD方法请求时，将会用一个HTTP响应报文进行响应，但是并不返回请求对象。
• PUT：PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上的路径。
• DELETE：DELETE方法允许用户或者应用程序删除Web服务器上的对象。

首部行
常用的一些首部行如下所示

• Host：www.someschool.edu        指明了对象所在的主机。
• Connection：close        代表浏览器告诉服务器不要使用持续连接，要求服务器发送完被请求的对象后就关闭这条连接。
• User-agent：Mozilla/5.0        代表向服务器发送请求的浏览器的类型。
• Accpet-language：fr        表示用户想得到该对象的法语版本(如果有该版本的话)。

实体体
请求报文的实体体是客户端请求服务端时服务端所需要的数据。

2.HTTP响应报文

HTTP响应报文格式：响应报文分为状态行、首部行、实体体。

状态行

版本字段代表HTTP协议的版本。状态行中的状态码和短语指示了请求的结果。如：

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

首部行

常见的首部行如下所示

• Connection：close        首部行告诉客户，发送完该报文将关闭该TCP连接。
• Date：Tue , 18 Aug 2015 15 : 44 : 04 GMT        首部行指示服务器产生并发送该响应报文的日期和时间。
• Service：Apache/2 . 2 . 3 (CentOS )        首部行指示该报文是由一台Apache Web服务器产生的。
• Last—Modified：Tue , 18 Aug 2015 15 : 11 : 0J GMT        首部行指示了对象创建或者最后修改的日期和时间。
• Content-Length：6821        首部行指示了被发送对象中的字节数。
• Content-Type：text/html        首部行指示了实体体中的对象时Html文本。

实体体
实体体部分包含了所请求的对象本身。

2.2.4 Cookie

作用：

HTTP是一个无状态协议，这简化了服务器的设计，但我们希望一个Web服务器能够识别
用户，此时就需要cookie技术，因为它允许服务器对用户进行跟踪。

cookie技术的组件：
1.在HTTP响应报文中的一个cookie首部行。
2.在HTTP请求报文中的一个cookie首部行。
3.在用户端系统保留有一个cookie文件，并由用户的浏览器进行管理。
4.位于Web站点的一个后端数据库。

cookie的工作过程：

下图中多出来的ebay：8734代表客户机曾经访问过另一个ebay站点，ebay站点为客户机返回了一个cookie。图中现在访问的是一个新的站点。

2.2.5 Web缓存

1.什么是Web缓存

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

2.Web缓存器安装位置

Web缓存器通常由ISP购买并安装。一所大学可能在他的校园网上安装一台缓存器，并且将校园网上的用户浏览器配置为指向他。一个主要的住宅ISP可能在它的网络上安装一台或多台Web缓存器。

3.Web缓存器工作流程
第一步：首先对浏览器进行配置。配置完成后，浏览器对每个对象的请求首先会被定位到该Web缓存器。
第二步：然后，浏览器开始访问某资源，会先创建一个到Web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求。
第三步：Web缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户浏览器用HTTP响应报文返回该对象。
第四步：如果Web缓存器没有该对象，他就打开一个与该对象的初始服务器的TCP连接。Web缓存器在同初始服务器的TCP连接上发送一个对该对象的HTTP请求。
收到该请求后，初始服务器向Web缓存器发送具有该对象的HTTP响应。
第五步：当Web缓存器接收到该对象时，它在本地存储一份副本，并向客户浏览器用HTTP响应报文发送该副本。

2.2.6 条件Get方法

1.什么是条件GET方法

存放在Web缓存器中的对象可能是陈旧的。HTTP协议有一种机制，允许缓存器隔一段时间向服务器证实它的对象是最新的。这种机制就是条件GET方法。

2.条件GET请求报文
如果：

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

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

2.3 因特网中的电子邮件

用到再更新

2.4 DNS：因特网的目录服务

        我们首先要了解域名和IP地址的区别。IP地址是互联网上计算机唯一的逻辑地址，通过IP地址实现不同计算机之间的相互通信，每台联网计算机都需要通过IP地址来互相联系和分别。

        但由于IP地址是由一串容易混淆的数字串构成，人们很难记忆所有计算机的IP地址，这样对于我们日常工作生活访问不同网站是很困难的。基于这种背景，人们在IP地址的基础上又发展出了一种更易识别的符号化标识，这种标识由人们自行选择的字母和数字构成，相比IP地址更易被识别和记忆，逐渐代替IP地址成为互联网用户进行访问互联的主要入口。这种符号化标识就是域名。

        域名虽然更易被用户所接受和使用，但计算机只能识别纯数字构成的IP地址，不能直接读取域名。因此要想达到访问效果，就需要将域名翻译成IP地址。而DNS域名解析承担的就是这种翻译效果。

2.4.1 DNS提供的服务

主要服务

提供主机名到IP地址的转换，是DNS最重要的服务

次要服务

• 主机别名：有的主机拥有复杂的主机名，所以会为复杂的主机名起一个或多个主机别名，复杂的主机名也称为规范主机名
• 邮件服务器的别名
• 负载分配

2.4.2 DNS的名字空间

1.域名结构

一个层面命名设备会有很多重名，DNS采用层次树状结构的命名方法为主机起域名。

因特网被划分成了几百个顶级域

• 通用的顶级域：.com   .edu   .gov   .int   .mil   .net   .org   .firm   .hsop   .web   .arts   .rec 
• 国家的顶级域：.cn   .us   .nl   .jp

每个顶级域下面可划分为若干子域，子域下面可进一步划分为若干子域，树叶是主机

域名结构：从本域往上，直到树根，中间使用“.”间隔不同的级别。例如：ustc.edu.cn auto.ustc.edu.cn。

注意：

域的域名：可以用于表示一个域

主机的域名：一个域上的一个主机

域名的管理：

• 一个域管理其下的子域。例如，.jp管理 ac.jp  co.jp
• 创建一个新的域，必须征得它所属域的同意

域与物理网络无关：

• 域遵从组织界限，而不是物理网络。一个域的主机可以不在一个网络，一个网络的主机不一定在一个域
• 域的划分是逻辑的，而不是物理的

2.4.2 DNS服务器的类型

        为了避免由于单个信息源带来的各种问题，DNS名字空间被划分为一些不重叠的区域。每个圈起来的区域包含域名树的一部分。区域边界应该放置在区域中的什么位置由该区域的的管理员来决定。（取决于需要在哪里使用多少个名字服务器）

        每个区域都与一个或多个域名服务器关联，这些服务器是持有该区域数据库的主机，通常情况下，一个区域有一个主域名服务器和一个或多个辅域名服务器。主服务器从自己磁盘的一个文件读入有关域名的信息，辅域服务器从主域名获取域名信息。为了提高可靠性，一些域名服务器可以设置在区域外面。

        DNS 使用了大量的 DNS 服务器 ，它们以层次方式组织且分布在全世界范围内，没有 DNS 服务器拥有因特网上所有主机的映射。相反，这些映射分布在所有的 DNS 服务器上。大致说来，有3种类型的 DNS 服务器：根 DNS 服务器、顶级域 (Top-Level Domain, TLD) DNS 服务器、权威 DNS 服务器。这些不同类型的DNS服务器以下图所示的层次结构组织起来。

根DNS服务器：有400 多个根名字服务器遍及全世界，这些根名字服务器由13个不同的组织管理。

顶级域DNS服务器：对于每个顶级域（如 .com .org .net .edu .gov) 和所有国家的顶级域（如 .uk .fr .ca .jp)都有 TLD 服务器 （或服务器集群）与之对应。

权威DNS服务器：在因特网上具有公共可访问主机（如 Web 服务器和邮件服务器）的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。一个组织机构的权威 DNS 服务器收藏了这些 DNS 记录。一个组织机构能够选择实现它自己的权威 DNS 服务器以保存这些记录；另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威 DNS 务器中，多数大学和大公司实现和维护它们自已基本和辅助（备份）的权威 DNS 服务器。

本地DNS服务器

根、 TLD 和权威 DNS 服务器都处在该 DNS 服务器的层次结构中，有另一类重要的 DNS 服务器，称为本地 DNS 服务器，一个本地 DNS 服务器并不属于DNS服务器的层次结构，但它是至关重要的。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用，并将该请求转发 DNS 服务器层次结构中。

本地DNS服务器所处地理位置

对某机构 ISP而言 ，本地 DNS 服务器可能就与主机在同一个局域网中；对于某居民区 ISP 来说，本地 DNS 服务器通常与主机相隔不超过几台路由器。严格说来，每个ISP(如一个居民区的 ISP 或一个机构的 ISP) 都有一台本地 DNS 服务器。

2.4.3 DNS对域名解析的过程

当我们在浏览器地址栏中输入www.baidu.com时，DNS解析将会有将近10个步骤，这个过程大体大体由一张图可以表示：

整个过程大体描述如下，其中前两个步骤是在本地电脑内完成的，后8个步骤涉及到真正的域名解析服务器：

第一步

      本地电脑会检查浏览器缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就结束。浏览器缓存域名也是有限制的，不仅浏览器缓存大小有限制，而且缓存的时间也有限制，通常情况下为几分钟到几小时不等，域名被缓存的时间限制可以通过TTL属性来设置。这个缓存时间太长和太短都不太好，如果时间太长，一旦域名被解析到的IP有变化，会导致被客户端缓存的域名无法解析到变化后的IP地址，以致该域名不能正常解析，这段时间内有一部分用户无法访问网站。如果设置时间太短，会导致用户每次访问网站都要重新解析一次域名。

第二步

        如果浏览器缓存中没有数据，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。其实操作系统也有一个域名解析的过程，在Linux中可以通过/etc/hosts文件来设置，而在windows中可以通过配置C:\Windows\System32\drivers\etc\hosts文件来设置，用户可以将任何域名解析到任何能够访问的IP地址。例如，我们在测试时可以将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是因为有这种本地DNS解析的规程，所以有黑客就可能通过修改用户的域名来把特定的域名解析到他指定的IP地址上，导致这些域名被劫持。

第三步

        前两个过程无法解析时，就要用到我们网络配置中的"DNS服务器地址"了。操作系统会把这个域名发送给这个本地DNS服务器。每个完整的内网通常都会配置本地DNS服务器，例如用户是在学校或工作单位接入互联网，那么用户的本地DNS服务器肯定在学校或工作单位里面。它们一般都会缓存域名解析结果，当然缓存时间是受到域名的失效时间控制的。大约80%的域名解析到这里就结束了，后续的DNS迭代和递归也是由本地DNS服务器负责

第四步

       如果本地DNS服务器仍然没有命中，就直接到根DNS服务器请求解析

第五步

       根DNS服务器返回给本地DNS域名服务器一个顶级DNS服务器地址，它是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右。

第六步

       本地DNS服务器再向上一步获得的顶级DNS服务器发送解析请求。

第七步

        接受请求的顶级DNS服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server服务器就是我要访问的网站域名提供商的服务器，其实该域名的解析任务就是由域名提供商的服务器来完成。   比如我要访问www.baidu.com，而这个域名是从A公司注册获得的，那么A公司上的服务器就会有www.baidu.com的相关信息。

第八步

       Name Server服务器会查询存储的域名和IP的映射关系表，再把查询出来的域名和IP地址等等信息，连同一个TTL值返回给本地DNS服务器。

第九步

       返回该域名对应的IP和TTL值，本地DNS服务器会缓存这个域名和IP的对应关系，缓存时间由TTL值控制。

第十步

       把解析的结果返回给本地电脑，本地电脑根据TTL值缓存在本地系统缓存中，域名解析过程结束在实际的DNS解析过程中，可能还不止这10步，如Name Server可能有很多级，或者有一个GTM来负载均衡控制，这都有可能会影响域名解析过程。

实践中，查询通常遵循上述模式。也就是从请求主机到本地DNS服务器的查询是递归的，其余的查询是迭代的。但也有查询全部是递归的模式，如下图所示：

DNS缓存

为了改善时延性能并减少在因特网上到处传输的 DNS 报文数，DNS 广泛使用了缓存技术，DNS 缓存的原理非常简单，在一个请求链中，当某 DNS 服务器接收 DNS 回答（例如，包含某主机名到 IP 地址的映射）时，它能将映射缓存在本地存储器中，当再次收到DNS请求报文时，如果缓存中有此映射，则直接返回回去。由于主机和主机名与 IP 地址间的映射并不是永久的，DNS 服务器在一段时间后（通常设置为两天）将丢弃缓存的信息。

2.4.4 DNS记录和报文

1.DNS记录

共同实现 DNS 分布式数据库的所有 DNS 服务器存储了 资源记录 (Resource Record , RR), 资源记录提供了主机名到 IP 地址的映射，每个 DNS 回答报文包含了一条或多条资源记录。

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

(Name, Value , Type , TTL)

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

如果 Type= A, Name 是主机名， Value 是该主机名对应的 IP 地址。

如果 Type= NS, Name 是个域（如 foo. com) , Value 是个知道如何获得该域中主机 IP 地址的权威 DNS 服务器的主机名。

如果 Type= CNAME,，Value 是别名为 Name 的主机对应的规范主机名。

如果 Type= MX ，则 Value 是个别名为 Name 的邮件服务器的规范主机名。

2.DNS报文

DNS只有查询报文和回答报文。并且，这二种报文具有相同的格式，如下图所示。DNS报文中个字段的含义如下所示：

首部区域 

• 标识符字段：标识符是一个 16 特的数，用于标识该查询，这个标识符会被复制到对查询的回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。
• 标志字段：标志字段中含有若千标志。1比特的“查询／回答“标志位指出报文是查询报文 (O) 还是回答报文 (1) 。当某 DNS 服务器是所请求名权威 DNS 服务器时， 1比特的＂权威的" 标志位被置在回答报文中。如果客户 （主机或者 DNS 服务器）在该 DNS 服务器没有某记录 希望 它执行递归查询，将设置特的“希望递归”标志位，如果该 DNS 服务器支持递归查询 ，在它的回答报文中会比对比特的＂递归可用“标志位置位。
• 4个有关数量的字段：这些字段指出了在首部后的4类数据区域出现的数量。

问题区域

问题区域包含着正在进行的查询信息，该区域包括：①名字字段，包含正在被查询的主机名；②类型字段，指出有关该名字的正被询问的问题类型。

权威区域

权威区域包含了其它权威服务器的记录

附加区域

附加区域包含了其他有帮助的记录。例如，对于一个 MX 请求的回答报文的回答区域包含了一条资源记录，该记录提供了邮件服务器的规范主机名，附加区域包含一个类型A记录，该记录提供了用于该邮件服务器的规范主机名的 IP 地址。

3.在DNS数据库中插入记录

当我们向某些注册登记机构注册域名 networkutopia. com 时，需要向该机构提供我们的基本和辅助权威 DNS 服务器的名字和 IP 地址，假定该名字和 IP 地址是 dnsl. networkutopia com dns2 nehvorkutopia. com 及 212. 212. 212.1 和 212.212.212.1， 对这两个权威 DNS 服务器的每个，该注册登记机构确保将一个类型 NS 个类型和一个类型A的记录输入 TLD com 服务器。特别是对于用于 networkutopia com 的基本权威服务器，该注册登记机构将下列两条资源记录插入该 DNS 系统中

(networkutopia.com，dnsl.netwokutopia.com，NS)

(dnsl.networkutopia.com，212.212.212.1，A)

你还必须确保用于 Web 服务器 www. networkutopia. com 的类型 A 资源记录和用于邮件服务器 mail.networkutopia.com的类型 MX 资源记录被输入到我们自己的权威 DNS 服务器中。直到最近，每台 DNS 服务器中的内容都是静态配置的，例如来自系统管理员创建的配置文件。最近，在 DNS 协议中添加了一个更新选项，允许通过 DNS 报文对数据库中的内容进行动态添加或者删除，[RFC 2136]和[RFC 3007] 定义了 DNS 动态更新.

一旦完成所有这些步骤，人们将能够访问我们的 Web 站点，并向我们公司的雇员发送电子邮件。

2.5 P2P文件分发

1.P2P体系结构的扩展性

如下图所示，对于客户 - 服务器体系结构，随着对等方数量的增加，分发时间呈线性增长并且没有界。 然而，对于  P2P 体系结构，最小分发时间不仅总是小于客户－服务器体系结构的分发时间，并且对于任意的对等方数量 N，总是小于1小时。因此，具有 P2P 体系结构的应用程序能够是自扩展的，这种扩展性的直接成因是： 对等方除了是比特的消费者外还是它们的重新分发者。

2.BitTorrent

BitTorrent是一种用于文件分发的流行P2P协议。

2.6 视频流和内容分发网

事先录制的流式视频现在是北美住宅 ISP 中的流量主体。特别是， Netflix 和 YouTube在2015年分别消耗了住宅 ISP 流量的 37% 和 16%。

2.6.1 因特网视频

在流式存储视频应用中，基础的媒体是预先录制的视频，例如电影、电视节目、录好的体育事件或录制好的用户生成的视频。这些预先录制好的视频放置在服务器上，用户按需向这些服务器发送请求来观看视频，许多因特网公司现在提供流式视频，这些公司包括 Netfljx 、YouTube (谷歌）、亚马逊和优酷等等。

视频的特点

视频是一系列的图像， 通常以一种恒定的速率（如每秒 24 到 30 张图像）来展现。一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素是由一些比特编码来表示亮度和颜色、视频的一个重要特征是它能够被压缩，因而可用比特率来权衡视频质量、今天现成的压缩算法能够将一个视频压缩成所希望的任何比特率。当然，比特率越高，图像质量越好，用户的总体视觉感受越好。我们也能使用压缩生成相同视频的多个版本 ，每个版本有不同的质量等级。例如，我们能够使用压缩生成相同视频的多个版本，比特率分别为 300kbps、1Mbps、3Mbps 。

比特率：比特率，也称为传输速率或数据速率，是指每秒钟传输的比特数，通常用“bps”来表示。它是衡量计算机网络传输效率的重要指标，可以用来衡量网络带宽的大小。

2.6.2 HTTP流和DASH

1.HTTP流

HTTP 流中，视频只是存储在 HTTP 服务器中作为一个普通的文件，每个文件有一个特定的URL， 当用户要看该视频时，客户与服务器创建 TCP 连接并发送对该URL的 HTTP GET 请求，服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个 HTTP 响应报文中发送该视频文件。在客户侧，字节被收集在客户应用缓存中，一旦该缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放，特别是，流式视频应用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩并且在用户屏幕上展现，因此，流式视频应用接收到视频就进行播放，同时缓存该视频后面部分的帧。

缺点：所有客户只能接收到具有相同编码的视频。也就是说，所有客户只能观看的视频质量都是相同的。

2.DASH

DASH 允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频，使用低速 3G 连接的客户能够接收一个低比特率（和低质量）的版本，使用光纤连接的客户能够接收高质量的版本。 如果端到端带宽在会话过程中改变的话， DASH 允许客户适应可用带宽。

使用 DASH 后，每个视频版本存储在 HTTP 务器中，每个版本都有一个不同的 URL。HTTP 服务器也有一个告示文件, 为每个版本提供了一个URL及其比特率。 客户首先请求该告示文件并且得知各种各样的版本。然后客户通过在 HTTP GET 请求报文中对每块指定一个 URL 和一个字节范围， 一次选择一块，在下载块的同时， 客户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。自然地，如果客户缓存的视频很多，并且测量的接收带宽较高，将选一个高速率的版本。同样，如果客户缓存的视频很少，并且测量的接收带宽较低，它将选择一个低速率的版本。DASH允许客户自由地在不同的质量等级之间切换。

2.6.3 内容分发网

1.什么是CDN

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网 (Content Distribution Network, CDN)。 CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的 We 内容，包括文档 、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置。

视频流公司：如Netflix(网飞)、YouTube(油管)、看看等

2.CDN的类型

CDN 可以是专用 CDN (private CDN) , 即它由内容提供商自己所拥有；例如，谷歌的 CDN 分发 YouTube 视频和其他类型的内容。另一种 CDN 可以是第三方 CDN，它代表多个内容提供商分发内容。

3.CDN采用的服务器安置原则

深入

第一个原则由 Akamai 首创，该原则是通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接入网中。

邀请做客

第二个设计原则由 Limelight 和许多其他 CDN 公司所采用，该原则是通过在少量（例如 10 个）关键位置建造大集群来邀请到 ISP 做客，不是将集群放在接入 ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点 (IXP)。

一旦 CDN 的集群准备就绪，它就可以跨集群复制内容。CDN 可能不希望将每个视频的副本放置在每个集群中，因为某些视频很少观看或仅在某些国家中流行。事实上，许多 CDN 没有将视频推入它们的集群，而是使用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向客户流式传输视频时的同时在本地存储一个副本。类似千因特网缓存，当某集群存储器变满时，它删除不经常请求的视频。

4.CDN操作

当用户主机中的一个浏览器指令检索一个特定的视频（由 URL 标识）时，CDN 必须截获该请 求，以便能够：①确定此时适合用于该客户的 CDN 服务器集群； ②将客户的请求重定向到该集群的某台服务器。

大多数CDN利用DNS来截获和重定向请求。下面通过一个例子来说明一下CDN如何用DNS来截获和重定向请求。

第一步：如下图所示，用户访问位于NetCinema.com的Web网页。

第二步：当用户点击链接 http: // video. netcinema. com/6Y7B23 时，该用户主机发送了一个对于 video. netcinema. com 的DNS 请求。

第三步：用户的本地 DNS 服务器 (LDNS) 将该 DNS 请求中继到一台用于 NetCinema 的权威DNS 服务器，该服务器观察到主机名 video. netcinema. com 中的字符串 ''video" 。为了将该 DNS 请求移交给 KingCDN，NetCinema 权威 DNS 服务器并不返回一个 lP 地址，而是向LDNS返回 KingCDN 域的主机名，如 a1105.kingcdn. com。

第四步：从这时起，DNS 请求进入了 KingCON 专用 DNS 基础设施。用户的 LDNS 则发送第二个请求，此时是对 a1105.kingcdn. com 的DNS 请求， KingCDN的 DNS 系统最终向 LDNS 返回 KingCDN 内容服务器的 IP 地址。所以正是在这里，在 KingCDN的 DNS 系统中，指定了CDN 服务器、客户将能够从这台服务器接收到它的内容。

第五步：LONS 向用户主机转发内容服务 CON 节点的 IP 地址。

第六步：一旦客户收到 KingCDN 内容服务器的 lP 地址，它与具有该 IP 地址的服务器创建了一条直接的 TCP 连接，并且发出对该视频的 HTTP GET 请求，如果使用了 DASH，服务器将首先向客户发送具有 URL 列表的告示文件，每个 URL 对应视频的每个版本，并且客户将动态地选择来自不同版本的块。

集群选择策略

如我们刚才所见，经过客户的 DNS 查找，CDN 得知了该客户的 LDNS 服务器的 IP 地址，在得知该 IP 地址之后， CDN 需要基于该 IP 地址选择一个适当的集群，CDN 一般采用专用的集群选择策略。一种简单的策略是指派客户到地理上最为邻近的集群。

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

2.7.1 UDP套接字编程

2.7.2 TCP套接字编程