个人博客：http://blog.kunpw.cn/

1.应用层协议原理

• 研发网络应用程序的核心是写出能够运行在不同端系统和通过网络彼此通信的程序：
  • Web应用程序中，有两个互相通信的不同的程序：运行在用户主机上的浏览器程序和运行在Web服务器主机上的Web服务器程序；
  • P2P文件共享系统，在参与文件共享的社区中的每台主机中都有一个程序；

1.1 网络应用程序体系结构

应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序

1.11 客户-服务器体系结构

• 服务器：一个总是打开的主机，服务于来自客户（一般不止一个）的主机请求：
  • 由于一台单独的服务器主机无法处理所有的客户请求，因此常通过连接多台甚至数十万台主机主机服务器而形成的数据中心作为服务器集群来处理客户请求；
  • 如Web服务器服务于来自浏览器（运行在客户主机上）的请求，当Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应；
• 在该体系结构中，客户之间不能直接通信，客户只能与服务器直接通信；
• 服务器具有固定的、周知的IP地址，客户就可以通过该服务器的IP地址向其发送分组进而与其联系（因此服务器必须总是打开）；
• 应用程序：
  • Web；
  • 电子邮件；
  • Telnet；
  • FTP（文件传输协议，由FTP服务器和FTP客户端组成）；

1.12 对等（P2P）体系结构

• 该体系结构中对于数据中心的专用服务器依赖性很小，客户可以直接和客户通信而没有必要经过服务器的第三方进行间接通信；
• 对等方：应用程序在间断连接的主机对之间使用直接通信，这些主机被称为对等方，这些对等方并不为服务提供商所有；
• 应用程序（流量密集型应用）：
  • 文件共享（BitTorrent）；
  • 对等方协助下载加速器（迅雷，[百度网盘有中间服务器]）；
  • 因特网电话和视频会议（Skype）；
• P2P应用于高度非集中式结构，面临安全性、性能、和可靠性等挑战，但它也不需要庞大的服务器基础设施和服务器带宽，成本相对较低；
• P2P自扩展性高，例如：在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其它对等方分发文件，也为系统增加了服务功能；

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

1.2 进程通信

运行在多个端系统中的程序是如何进行通信的呢？进行通信的实际上是进程而不是程序。同一台计算机主机上的多个进程通过操作系统制定的通信规则在进程间相互通信，而不同端系统上的两个进程，则需要通过跨越计算机网络交换报文而相互通信

1.21 客户和服务器进程

• 客户：在一对进程通信会话场景中，发起通信的进程被标识为客户；

• 服务器：在一对进程通信会话场景中，在会话开始时等待联系的进程被标识为服务器；

• 而在P2P中，一个进程既能下载文件又能上传文件，即每一个对等方既是客户又是服务器，但是在单次通信会话过程中，服务器和客户都是唯一的；

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

发送端的应用程序将报文推进套接字，运输层协议负责从接收进程的套接字中获取该报文

• 套接字：

  • 进程通过一个称为**套接字（socket）**的软件接口向网络发送报文和接收报文；
  • 套接字是同一台主机内应用层和运输层之间的接口；
  • 套接字是建立网络应用程序的可编程接口，也被称为应用程序和网络之间的应用程序编程接口（API）；
  • 应用程序开发者可以控制套接字在应用层的一切，而对运输层的控制仅限于：
    • 选择运输层协议；
    • 也许能设定几个运输层参数，如最大缓存和最大报文段长度；

  

1.23 进程寻址

• 为了标识接收进程，需要定义两种信息：
  • 主机的地址：
    • 由IP地址标识；
  • 在目的主机中指定接收进程的标识符：
    • 由目的地端口号标识；
    • 流行的应用已经分配好了固定的端口号；
    • 例如：Web服务器端口号为80，邮件服务器进程（使用SMTP协议）用端口号25来标识；
    • 标准端口号在该网址查看：http://www.iana.org

1.3 运输层协议提供的运输服务

运输层协议能够为调用它的程序提供四类通用运输服务：可靠数据传输、吞吐量、定时和安全性

1.31 可靠数据传输

• 确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端的服务；
• 电子邮件、文件传输、远程主机访问、金融应用等应用需要可靠数据传输，而另一些应用如多媒体应用则容忍丢失部分数据；

1.32 吞吐量

• 可用吞吐量就是发送进程能够向接收进程交付比特的速率，由于带宽共享，可用吞吐量将随时间产生波动；
• 运输层协议能够以某种特定的速率提供确保的可用吞吐量的服务：
  • 应用程序请求 r 比特/秒的吞吐量，则该运输层协议能够确保可用吞吐量总是为至少 r 比特/秒；
• 具有吞吐量要求的应用被称为带宽敏感的应用，许多多媒体应用是带宽敏感的；

1.33 定时

• 运输层协议提供定时保证服务，比特传输具有最低时延；

1.34 安全性

• 运输层协议为应用程序提供安全性服务，如加密解密数据、数据完整性和端点鉴别；

1.4 因特网提供的运输服务

具体考察由因特网提供的运输服务类型

• 因特网（TCP/IP网络）为应用程序提供两个运输层协议：TCP、UDP；

1.41 TCP服务

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

• 面向连接服务：

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

• 可靠数据传输服务：

  • 通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据；

• TCP还具有拥塞控制机制：

  • 能为因特网带来整体好处，而不一定给通信进程带来直接好处；
  • 当发送方和接收方之间的网络出现拥塞现象时，TCP的拥塞控制机制会抑制发送进程；
  • TCP拥塞控制也试图限制每个TCP连接，使它们达到公平共享网络带宽的目的；

• TCP的加强版本SSL在应用层提供了安全性服务；

1.42 UDP服务

• UDP是一种不提供不必要服务的轻量级运输协议，仅提供最小服务；
• UDP无连接、不可靠、且没有拥塞机制；

1.43 因特网运输协议不提供的服务

• 因特网TCP协议和UDP协议都不提供定时或带宽保证，但当下的因特网能够为时间敏感应用提供满意的服务；

1.5 应用层协议

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

• 定义：
  • 交换的报文类型，例如请求报文和响应报文；
  • 各种报文类型的语法，如报文中的各个字段和这些字段是如何描述的；
  • 字段的语义，即这些字段中的信息的含义；
  • 确定一个进程何时以及如何发送报文，对报文进行响应的规则；
• 有些应用层协议是由RFC文档定义的，位于公共域中，例如HTTP协议就作为一个RFC可供使用：
  • 如果浏览器开发者遵从HTTP RFC规则，则该浏览器就能访问任何遵从该文档标准的Web服务器并获取相应的Web页面；
• 网络应用组成：
  • Web应用：
    • 文档格式标准（HTML）;
    • Web浏览器（Chrome等）；
    • Web服务器（Apache、Microsoft等）；
    • Web应用层协议（HTTP）；
  • 电子邮件应用：
    • 邮件服务器；
    • 邮件客户程序；
    • 定义电子邮件报文结构的标准；
    • 邮件应用层协议（不止一个，主要是SMTP）；

2.Web和HTTP

2.1 HTTP概况

• HTTP全称为超文本传输协议，是Web的唯一应用层协议，也是Web的核心所在；

• HTTP由两个程序实现：

  • 客户程序；
  • 服务器程序；

• Web页面由对象组成，一个对象只是一个文件，例如一个HTML文件、一个JPEG图形、一个JAVA小程序等，其中除HTML基本文件外，其余对象都是引用对象，通过URL地址寻址的方式引用显示其它对象；

• URL地址组成（以 http://jwglnew.hunnu.edu.cn/eams/home.action 为例）：

  • 存放对象的服务器主机名，即 http://jwglnew.hunnu.edu.cn ；
  • 对象的路径名，即 /eams/home.action ；

• HTTP使用TCP作为它的支撑运输协议；

• HTTP协议不担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节，这也是分层体系结构最大的优点；

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

2.2 非持续连接和持续连接

• 非持续连接：每个请求/响应对是经一个单独的TCP连接发送的；

• 持续连接：所有的请求/响应经过相同的一次TCP连接发送；

• HTTP默认使用TCP持续连接，一段时间间隔未使用则自动关闭该TCP连接，该方式下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务，使用并行连接可以缩短响应时间；

• 往返时间（RTT）：一个短分组经客户-服务器-客户所花费的时间，包括分组传播时延、排队时延、分组处理时延；

• 请求并接收响应对象过程：

  • 客户想服务器发送一个小TCP报文段；
  • 服务器用一个小TCP报文段做出确认和响应；
  • 客户向服务器返回确认；
  • 服务器在该TCP连接上发送HTML文件（响应对象）；
  • 所以总响应时间就是两个RTT加上服务器传输HTML文件的时间；
  • 非持续连接每次重新连接TCP需要多花费前面一次握手RTT时间；

2.3 HTTP报文格式

2.31 HTTP请求报文

• 如图所示：
  • 每一行结尾都以“/r/n”回车和换行符结束，图中未标明，但实际操作中有显示；
  • 请求行：请求报文的第一行，有三个字段：
    • 方法字段：取值包括GET、POST、HEAD、PUT、DELETE，一般为GET，功能为请求获取；
    • URL字段：请求对象的路径；
    • HTTP版本字段：浏览器实现的HTTP版本；
  • 首部行：请求报文的后续行，图例内容：
    • Host：主机名；
    • Connection：是否持续连接，close的含义是要求服务器发送完请求之后就关闭连接；
    • User-agent：指名用户代理，即向服务器发送请求的浏览器的类型，此处浏览器类型为Mozilla/5.0，即Firefox浏览器；
    • Accept-language：用户想要接收的语言格式；

• 请求报文的通用格式：

  • 实体体：使用GET方法时为空，使用POST方法时才使用，POST方法常在表单中使用，此时实体体中包含的就是用户在表单字段中的输入值；
  • 表单使用GET方法时，假设两个字段填写值为“monkeys”和“bananas”，则提交时URL结构为：

  

  • HEAD方法类似于GET方法，但响应报文并不返回请求结果，开发者用HEAD方法调试跟踪；

  • PUT方法常与Web发型工具联合使用，允许用户上传对象到指定的Web服务器上指定的路径；

  • DELETE方法允许用户或者应用程序删除Web服务器上的对象；

2.32 HTTP响应报文

• 如图所示：
  • 状态行：响应报文的第一行，有三个部分：
    • 协议版本字段：HTTP/1.1说明服务器使用的HTTP1.1版本；
    • 状态码：200；
    • 相应状态信息：OK；
  • 首部行：
    • Connection：close，发送完报文即关闭TCP连接；
    • Date：服务器从文件系统中检索到该对象，将该对象插入到响应报文，并发送到响应报文的时间；
    • Server：对应于User-agent，Apache/2.2.3表示该报文由ApacheWeb服务器产生；
    • Last-Modified：对象创建或者最后一次修改时间；
    • Content-Length：被发送对象的字节数；
    • Content-Type：指示实体体中的对象格式是HTML文本；
  • 实体体：响应对象数据内容；

• 响应报文的通用格式：

  • 状态码：

2.4 cookie

• 弥补HTTP无状态的缺点，允许站点对用户进行跟踪，即cookie可以标识一个用户；
• cookie技术有四个组件：
  • 在HTTP响应报文中有一个cookie首部行；
  • 在HTTP请求报文中有一个cookie首部行；
  • 在用户端系统中有一个cookie文件，由用户的浏览器进行管理；
  • 位于Web站点的一个后端数据库；

2.5 Web缓存

• Web缓存器也叫做代理服务器，能够代表初始Web服务器来满足HTTP请求的网络实体，它具有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本；
• Web缓存器既是服务器又是客户，它可以接收浏览器的请求并发送响应，也可以向初始服务器发送请求；
• Web缓存器通常由ISP购买并安装，例如，一所大学可能在它的校园网上安装一台缓存器，并且将所有校园网上的用户浏览器配置为指向它；
• 部署Web缓存器有两个原因：
  • Web缓存器可以大量减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时；
  • Web缓存器能够大量减少一个机构的接入链路到因特网的通信量，减少通信量就可以不急于增加带宽，降低费用；

• 举例：假设对象的平均长度为1Mb，从机构内的浏览器对这些初始服务器的平均访问速率为每秒15个请求，且HTTP请求报文足够小而不会在网络中即接入链路产生通信量（无排队等时延），且从接入链路一侧转发HTTP请求报文到接收响应的平均因特网时延为2s：
  • 总响应时间 = 局域网时延 + 接入时延 + 因特网时延；
  • 局域网流量强度：
    • （15个请求/s）×（1Mb/请求）/（100Mbps）= 0.15；
    • 0.15的通信量时延一般为几十毫秒，可以忽略；
  • 接入链路流量强度：
    • （15个请求/s）×（1Mb/请求）/（15Mbps）= 1；
    • 1的通信量时延非常大且会无限增长；
  • 解决方法：
    • 将接入链路速率由15Mbps升级到100Mbps，代价很高；
    • 在机构网络中安装一个Web缓存器：
      • 一个缓存器所满足的请求的比率通常在0.2~0.7之间，假设平均命中率为0.4；
      • 客户和缓存连接在同一个高速局域网上，这样40%的请求几乎立即完成响应，时延约在10ms以内；
      • 剩下的60%请求由初始服务器来完成响应，而且流量强度从1减少为0.6，时延较小，可忽略；
      • 一般而言，在15Mbps链路中，流量强度小于0.8时，时延较小，一般为几十毫秒；
      • 此时平均时延为：0.4 ×（0.010秒）+ 0.6 ×（2.01秒）= 1.2秒

2.6 条件GET方法

• 上述Web缓存中存在问题：存放在缓存器中的对象副本可能是陈旧的，而条件GET方法则是用来解决这个问题的；
• 条件GET方法：
  • 请求报文使用GET方法；
  • 请求报文中包含一个“If-Modified-Since：”首部行
• 过程：
  • 代理缓存器代表一个请求浏览器向Web服务器发送一个请求报文；
  • Web服务器向缓存器发送具有被请求对象的响应报文；
  • 一段时间后用户再次访问，但对象可能已经改变，缓存器通过发送一个条件GET执行最新检查，其中If-Modified-Since：首部行的值正好等于上一次发送过来的Last-Modified：首部行的值；
  • 如果两个时间相同，没有修改时，Web服务器向该缓存器发送一个响应报文回来，但并不发送所请求的对象，并且状态行为304 Not Modified；

3.因特网中的电子邮件

• 组成部分：
  • 用户代理：
    • 允许用户阅读、回复、转发、保存和撰写报文；
  • 邮件服务器：
    • 形成电子邮件体系结构的核心；
  • 简单邮件传输协议（SMTP）；
• 一个典型的邮件发送过程：
  • 从发送方的用户代理开始，传输到发送方的邮件服务器；
  • 再传输到接收方的邮件服务器；
  • 在接收方的邮件服务器被分发到接收方的邮箱中；

3.1 SMTP

• 是因特网电子邮件中主要的应用层协议，也是因特网电子邮件的核心，使用TCP可靠数据传输服务；

• 每台邮件服务器上既运行SMTP客户端，也运行SMTP服务器端，SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器；

• 缺陷：

  • 限制所有邮件报文的体部分只能采用简单的7比特ASCII码表示，在用SMTP传送邮件之前，需要将二进制多媒体数据编码为ASCII码，并且在使用SMTP传输后要求将相应的ASCII码邮件解码还原为多媒体数据，而使用HTTP传送前不需要编码为ASCII码；

• SMTP一般不使用中间邮件服务器发送邮件，而是通过TCP直接连接，如果接收方邮件服务器没有开机，则该报文邮件会保存在发送方邮件客户端并等待进行新的连接请求尝试；

• 使用Telnet与一个SMTP服务器进行一次直接对话，使用命令：

• telnet SeverName 25
  //25 是端口号
  

3.2 与HTTP的对比

• HTTP：
  • 从Web服务器向Web客户（通常是一个浏览器）传送文件；
  • 主要是一个拉协议，在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息；
  • 不受7比特ASCII编码协议限制；
  • 处理既包含文本又包含图形的文档时，HTTP把每个对象封装到它自己的HTTP响应报文中；
• SMTP：
  • 从一个邮件服务器向另一个邮件服务器传送文件；
  • 基本上是一个推协议，发送邮件服务器把文件推向接收邮件服务器，这个TCP连接由要发送该文件的机器发起的；
  • 采用7比特ASCII字符编码发送；
  • 处理既包含文本又包含图形的文档时，SMTP把所有报文对象放在一个报文之中；

3.3 邮件报文格式

• 必须包含的首部行：
  • From：首部行；
  • To：首部行；
  • 可能包含一个Subject：首部行；
  • 首部之后接一个空白行；
  • 再后面是一个以ASCII格式表示的报文体；

3.4 邮件访问协议

• 典型的用户通常在本地PC上运行一个用户代理程序，而它访问存储在总是保持开机的共享邮件服务器上的邮箱，该邮件服务器与其它用户共享，通常由用户的ISP进行维护（大学或公司）；

• 如图所示：

  • 问题一：发送方代理不能直接通过SMTP发送到接收方的邮件服务器，必须要考虑到目的地不可达时（是接收方服务器关机）情形，所以通过发送方邮件服务器进行中继，这样一来就可以一直重复发送，知道发送完毕为止；
  • 问题二：SMTP是一个推协议，而从接收方代理主动获取邮件是一个拉操作，只能通过第三方的特殊邮件访问协议进行；

3.41 POP3

• 是一个极为简单的邮件访问协议，功能有限；
• 将邮件下载到本地主机；
• 工作的三个阶段：
  • 特许：用户代理鉴别用户；
  • 事务处理：用户代理取回报文，对报文做或取消删除标记；
  • 更新：客户发送quit命令之后，结束POP3会话，删除标记删除的报文；

3.42 IMAP

• IMAP协议服务器把每个报文与一个文件夹关联，可删除可移动可读取；
• 为用户提供了在远程文件夹中查询邮件的命令；
• 允许用户代理只获取报文某些部分；
• 维护了IMAP会话的用户状态信息；

3.43 基于Web的电子邮件（HTTP）

• 使用Web浏览器收发电子邮件；
• 使用这种服务时：
  • 用户代理就是普通的浏览器；
  • 用户和他自己远程邮箱之间的通信则通过HTTP进行；

4.DNS：因特网的目录服务（重点）

• 因特网上的主机可以使用多种方式进行标注：
  • 主机名（服务器域名）：很少或几乎不提供主机在因特网中改的位置，适合人类标识；
  • IP地址：从左到右扫描时能够获得越来越具体的关于主机在因特网中的位置，适合路由器标识；

4.1 DNS提供的服务

• DNS全称为域名系统，能够进行主机名到IP地址转换的目录服务；

• DNS协议是应用层协议，但通常由其它协议使用，将用户提供的主机名解析为IP地址；

• DNS：

  • 一个由分层的DNS服务器实现的分布式数据库；
  • 一个使得主机能够查询分布式数据库的应用层协议；
  • DNS协议运行在UDP上，使用53号端口；

• 浏览器调用DNS解析过程：

  • DNS给使用它的因特网额外的时延；

  

• 其它服务：

  • 主机别名：应用程序可以调用DNS来获取主机别名对应的规范主机名以及主机的IP地址；
  • 邮件服务器别名；
  • 负载分配：用于在冗余的服务器之间进行负载分配；

4.2 DNS工作机理（IP地址转换）

• 集中式设计模型：整个因特网使用一个DNS服务器，该服务器包含所有映射，但是具有一定缺陷：
  • 单点故障；
  • 通信容量；
  • 远距离的集中式数据库；
  • 维护；
• 在单一DNS服务器上运行集中式数据库缺少可扩展能力；

4.21 分布式、层次数据库

• 大量DNS以层次结构组织分布于全世界；

• 服务器类型：

  • 根DNS服务器；
  • 顶级域服务器；
  • 权威DNS服务器；

• 举例分析获取 www.amazon.com IP地址：

  • 客户与根服务器之一联系，返回顶级域名 com 的TLD服务器IP地址；
  • 客户与这些返回的TLD服务器之一联系，返回 amazon.com 权威服务器IP地址；
  • 客户与 amazon.com 权威服务器之一联系，返回 www.amazon.com IP地址；

• 除此之外，每个ISP都有一台本地DNS服务器，本地DNS服务器不属于DNS服务器层次结构；

• 举例分析主机 cse.nyu.edu 获取 gaia.cs.umass.edu 的IP地址：

  • cse.nyu.edu 主机向它的本地DNS服务器 dns.nyu.edu 发送一个DNS查询报文；
  • 本地DNS服务器将报文转发给根DNS服务器；
  • 根DNS服务器注意到 edu 前缀并向本地DNS服务器返回负责 edu 的TLD的IP地址列表；
  • 本地DNS服务器再次向这些TLD服务器之一发送查询报文；
  • 该TLD服务器注意到umass.edu前缀，用权威DNS服务器 dns.umass.edu 的IP地址进行响应；
  • 最后，本地DNS服务器直接向 dns.umass.edu 重发查询报文；
  • dns.umass.edu 使用 gaia.cs.umass.edu IP地址进行响应，即查询完毕；

• 注意上述事例中，实际上TLD服务器并不一定知道目的主机的权威DNS服务器，而是知道中间的某个服务器，继续进行转换才能得到。上述例子的报文查询使用了递归查询和迭代查询的方式；

4.22 DNS缓存

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

• DNS缓存原理：在一个请求链中，当某DNS服务器接收一个DNS回答时，它能将映射缓存到本地DNS服务器，一段时间后再丢弃缓存的信息；
• 本地DNS服务器也能缓存TLD服务器的IP地址，因此允许本地DNS绕过查询链中的根DNS服务器；

4.3 DNS记录和报文

• 共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（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的主机对应的规范主机名；
    • Type = MX，Value是个别名为Name的邮件服务器的规范主机名；

4.31 DNS报文

DNS只有查询和回答报文，并且查询报文和回答报文格式相同

• 报文格式图示：

• 前十二个字节是首部区域，有以下字段：

  • 标识符：16比特的数，用于表示该报文，查询报文中的标识符会被复制到回答报文中，以表示相匹配；
  • 标志：1比特指出查询报文（0）或回答报文（1），其余自查
  • 其余四个有关数量的字段，指出了在首部后的四类数据区域出现的数量；

• 问题区域包含正在进行的查询信息：

  • 名字字段：主机名；
  • 类型字段：该主机名正被询问的问题类型；

• 回答区域是回答报文拥有的，包含了对最初请求的名字的资源记录：

  • 回答报文中可以有多条RR，意味着一个主机名能拥有多个IP地址（冗余Web服务器）；

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

• 附加区域包含了其它有帮助的信息；

• 使用nslookup程序能够从正在工作的主机直接向某些DNS服务器发送一个查询报文；

• 除此之外，还可向DNS服务器插入资源记录；

5.P2P文件分发

• 使用P2P体系结构，对总是打开的基础设施服务器具有最小的依赖：
  • 从单一服务器向大量主机（对等方）分发一个大文件，每个对等方能向任何其它对等方重新分发它已经收到的该文件的任何部分；

5.1 P2P体系结构的扩展性

• 图示实例：

• 将一个文件分发给固定对等方集合，u表示服务器或对等方接入链路的上载速率，d表示下载速率，被分发的文件长度为F（以比特为单位），N表示对等方数量，考虑所有理想化情形下，求其分发时间：

  • 客户-服务器体系结构：

    • 服务器必须向N个对等方每个传输该文件的一个副本，传输比特为N×F，由于服务器上载速率为u_s，所以分发时间至少为N×F/u_s；
    • 令d_min表示具有最小下载速率的对等方的下载速率，即d_min = min{d₁，d_p，···，d_N}，因此具有最小下载速率的对等方下载时间为F/d_min；
    • 综上，分发时间D_cs >= max{N×F/u_s，F/d_min}，而对于足够大的N，其分发时间由N×F/u_s确定；

  • P2P：

    • 在分发初始，服务器至少发送一次该文件，最小分发时间为F/u_s；
    • 具有最低下载速率的对等方获取文件最短分发时间为F/d_min；
    • 系统整体的总上载能力等于服务器的上载速率加上每个单独的对等方的上载速率，即u_total = u_s + u₁ + ··· +u_N，系统必须向N个对等方总共交付N×F比特，因此最小分发时间为N×F/u_s + u₁ + ··· +u_N；
    • 综上，最小分发时间D_P2P = max{F/u_s，F/d_min，N×F/u_s + u₁ + ··· +u_N}；

  • 效用关系如图：

  

5.2 BitTorrent

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

• 洪流：参与一个特定文件分发的所有对等方的集合，在一个洪流中的对等方彼此下载等长度的文件块，任何对等方能够随时进出该洪流；
• 追踪器：每个洪流具有的一个基础设施节点，在新对等方加入时注册标记，并且周期性地接收对等方的通知以确保对等方依然存在洪流中；
• BitTorrent运行过程：
  • 一个新对等方加入洪流，追踪器随机从对等方集合中选择一个子集并将其IP地址发送给新对等方，使之与其创建TCP连接获取文件，创建TCP连接的对等方被称为新对等方的邻近对等方；
  • 由于对等方随时能离开与加入，因此一个对等方的邻近对等方将随时间而波动；
  • 该对等方能够使用最稀缺优先技术（最稀缺的块就是邻居中副本最少的块）首先请求最稀缺的块；
  • 该对等方使用对换算法根据当前能够以最高速率向它提供数据的邻居给与优先响应权，例如，响应接收传输速率排名前4的对等方的请求，并且每过一段时间重新替换新的对换伴侣，这些对等方被称为疏通；
• 另一种P2P应用——分布式散列表（DHT）：
  • 分布式散列表是一种简单的数据库，其数据库记录分布在一个P2P系统的多个对等方上；
  • DHT得到了广泛实现（如在BitTorrent中），并成为大量研究的主题；

6.视频流和内容分发网

6.1 因特网视频

• 在流式存储视频应用中，基础的媒体是预先录制的视频；
• 视频是由一系列的图像，以一种恒定的速率（如每秒24张图像）来展现，而一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素都是由一些比特编码来表示亮度和颜色；
• 视频的一个重要特征就是能够被压缩，因而可用比特率来权衡视频质量；
• 流式视频最为重要的性能度量是平均端到端吞吐量，为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大；

6.2 HTTP流和DASH

• 在HTTP流中，视频只是存储在HTTP服务器中的一个普通的文件，每个文件具有一个特定的URL，但HTTP流所有客户接受到的视频编码版本相同，也就是比特率相同，显然并没有考虑用户带宽的问题；
• DASH解决了上述问题，DASH流中，将视频编码成几个不同的版本，每个版本具有不同的比特率，每一个版本都拥有属于自己的URL，DASH初始时根据用户带宽自定义选择一个版本的视频，并且允许用户更改版本；

6.3 内容分发网（CDN）

• 建立大型单一的大规模数据中心存储所有视频并且直接传输给用户存在三个问题：
  • 客户原理数据中心时，服务器到客户之间的其中一个通信链路提供的吞吐量如果小于视频消耗速率，则有强大的停滞时延；
  • 流行的视频可能经过相同的链路发送很多次，既浪费宽带，又需向ISP支付更多费用；
  • 单个数据中心可能发生单点故障；
• CDN管理分布在多个地理位置上的服务器，在它的服务器上存储视频（包括其它Web内容）的副本，并且视图将每个用户请求定向到一个能提供最好用户体验的CDN位置；
• CDN两种类型：
  • 专用CDN：由内容提供商拥有；
  • 第三方CDN，为多个内容提供商分发内容；
• CDN两种服务器安置原则：
  • 深入：
    • 由Akamai首创，通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中；
    • 目的是靠近端用户，通过减少端用户和CDN集群之间链路和路由器的数量，从而改善用户感受的时延和吞吐量；
    • 是一种高度分布式设计，维护和管理集群困难；
  • 邀请做客：
    • 由Limelight和其它CDN公司采用，通过在少量关键位置建造大集群来邀请ISP做客；
    • 不是将集群放在接入ISP中，这些CDN通常将它们的集群放置在因特网交换点（IXP）；
    • 产生较低的维护和管理开销，有可能以对端用户的较高时延和较低吞吐量为代价；
• 很多CDN没有将视频推入集群，而是通过一种简单的拉策略：
  • 如果客户向未存储该视频的集群请求视频，该集群从某种新仓库或另一个集群检索该视频，向客户发送的同时存储副本到本地；
  • 存储器满时，删除不经常使用的视频；
  • 这个拉策略和因特网缓存与分页机制很像；

6.31 CDN操作

• 当用户主机中的一个浏览器指令剑索一个特定视频（URL标识）时，CDN必须截获该请求：
  • 确定此时适合用于该用户的CDN服务器集群；
  • 将客户的请求重定向到该集群的某台服务器；
• 截获和重定向机制，步骤：
  • 用户访问视频网站；
  • 用户点击视频链接，发送DNS请求；
  • 用户本地DNS服务器（LDNS）将该请求中继到一台用于域名的权威DNS服务器，该权威CDN服务器返回CDN域的主机名；
  • 用户本地DNS服务器向该主机名发起第二个请求，CDN服务器的DNS返回CDN内容服务器的IP响应；
  • 用户本地DNS服务器向用户主机转发IP地址；
  • 建立TCP连接并发出HTTP GET请求；
  • CDN响应；

6.32 集群选择策略

• CDN部署的核心就是集群选择策略，即动态地将客户定向到CDN中某个服务器集群或数据中心的机制；

• CDN在得到客户的LDNS服务器的IP地址后，需要基于该IP地址选择一个适当的集群，并将其IP响应给LDNS；

• 策略：

  • 指派到地理上最为邻近的集群，但地理邻近未必网络传输路径短；
  • 基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量；

• 存储器满时，删除不经常使用的视频；

  • 这个拉策略和因特网缓存与分页机制很像；

6.31 CDN操作

• 当用户主机中的一个浏览器指令剑索一个特定视频（URL标识）时，CDN必须截获该请求：
  • 确定此时适合用于该用户的CDN服务器集群；
  • 将客户的请求重定向到该集群的某台服务器；
• 截获和重定向机制，步骤：
  • 用户访问视频网站；
  • 用户点击视频链接，发送DNS请求；
  • 用户本地DNS服务器（LDNS）将该请求中继到一台用于域名的权威DNS服务器，该权威CDN服务器返回CDN域的主机名；
  • 用户本地DNS服务器向该主机名发起第二个请求，CDN服务器的DNS返回CDN内容服务器的IP响应；
  • 用户本地DNS服务器向用户主机转发IP地址；
  • 建立TCP连接并发出HTTP GET请求；
  • CDN响应；

[外链图片转存中…(img-uWXranKk-1606619709048)]

6.32 集群选择策略

• CDN部署的核心就是集群选择策略，即动态地将客户定向到CDN中某个服务器集群或数据中心的机制；

• CDN在得到客户的LDNS服务器的IP地址后，需要基于该IP地址选择一个适当的集群，并将其IP响应给LDNS；

• 策略：

  • 指派到地理上最为邻近的集群，但地理邻近未必网络传输路径短；
  • 基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量；