目标:

  1. 网络应用的原理：网络应用协议的概念和实现

传输层的服务模型
客户服务器模式(CS)&对等模式(P2P)
内容分发网络

  1. 网络应用的实例：HTTP, FTP, DHCP, SMTP/POP3/IMAP, DNS

2.1 应用层协议原理

2.1.1 网络应用程序的体系结构

（1）客户-服务器体系结构（client-server architecture）CS模式
利用客户-服务器体系结构， 客户相互之间不直接通信，服务器具有固定的、 周知的地址。具有客户-服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。
服务器：一直运行；固定的IP地址和周知的端口号；
客户端：主动与服务器通信，与互联网有间歇性的连接，可能是动态IP地址，不与其他客户端通信。
有什么问题？可扩展性较差（网络和服务器性能的扩展困难，随着用户增加性能急剧下降）

（2）对等（P2P）体系结构
在一个 P2P 体系结构（P2P architecture） 中， 对位于数据中心的专用服务器有最小的（或者没有） 依赖。 相反， 应用程序在间断连接的主机对之间使用直接通信， 这些主机对被称为对等方。
该体系结构被称为对等方到对等方的。 许多目前流行的、 流量密集型应用都是P2P体系结构的。 这些应用包括文件共享（例如BitTorrent） x对等方协助下载加速器（例如迅雷） 、 因特网电话和视频会议（例如Skype）。Gnutella，迅雷。
P2P体系结构特点：

  1. 低成本，不需要庞大的服务器基础设施和服务器带宽；
  2. 高度非集中式结构，存在安全性、可靠性、性能风险。
  3. 几乎没有一直运行的服务器；
  4. 任意端系统之间可以进行通信；
  5. 每一个节点既是客户端又是服务器（自扩展性-新peer节点带来新的服务能力，当然也带来新的服务请求）；
  6. 参与的主机间歇性连接且可以改变IP地址（难以管理）；

（3）C/S和P2P体系结构的混合体
Napster

  • 文件搜索：集中
    • 主机在中心服务器上注册其资源
    • 主机箱中心服务器查询资源位置
  • 文件传输：P2P
    • 任意PEER节点之间

即时通信

  • 在线检测：集中
    • 当用户上线时，向中心服务器注册其IP地址
    • 用户与中心服务器联系，以找到其在线好友的位置
  • 两个用户之间聊天：P2P

2.1.2 进程通信

用操作系统的术语来说， 进行通信的实际上是进程（process）而不是程序。
进程：在主机上运行的应用程序。
当多个进程运行在相同的端系统上时， 它们使用进程间通信机制相互通信。 进程间通信的规则由端系统上的操作系统确定。
在两个不同端系统上的进程， 通过跨越计算机网络交换报文（message）而相互通信。发送进程生成并向网络中发送报文； 接收进程接收这些报文并可能通过回送报文进行响应。

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

（2）进程与计算机网络之间的接口
从一个进程向另一个进程发送的报文必须通过下面的网络。 进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。
套接字可以理解为“门”
套接字是同一台主机内应用层与运输层之间的接口。 由于该套接字是建立网络应用程序的可编程接口， 因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface, API）。
应用程序开发者可以控制套接字在应用层端的一切， 但是对该套接字的运输层端几乎没有控制权。 应用程序开发者对于运输层的控制仅限于： ①选择运输层协议； ②也许能设定几个运输层参数， 如最大缓存和最大报文段长度等。 一旦应用程序开发者选择了一个运输层协议（如果可供选择的话） ， 则应用程序就建立在由该协议提供的运输层服务之上。

（3）进程寻址
在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组， 接收进程需要有一个地址。 为了标识该接收进程， 需要定义两种信息： ①主机的地址； ②在目的主机中指定接收进程的标识符
在因特网中， 主机由其IP地址(IP address)标识。 指定运行在接收主机上的接收进程(更具体地说， 接收套接字)：目的地端口号(port number)

下面是网课里面的相关内容：
问题1：进程标示和寻址问题（服务用户）
至少包含三部分：①主机ip ②指明是TCP还是UDP ③端口号（web应用默认80，telnet默认23，ftp默认21）

问题2：传输层-应用层服务如何实现（服务）
应用采用传输提供的服务，使用层间的接口来传输报文。

  • 位置：层间界面的SAP（TCP/IP:socket）
  • 形式：应用程序接口API（TCP/IP:socket API）

传输层提供的服务-层间信息的代表
TCP socket
如果socket api每次都需要传输发送方和接收方的ip+端口，携带如此多的信息，太繁琐易错，不便于管理。用一个代号（一个整数）来标示通信的双方或者单方，用socket来标示这个四元组。
对于使用面向连接服务（TCP）的应用而言，套接字是四元组的一个具有本地意义的标示：

  • 4元组：（源IP，源port，目标ip，目标port）
  • 唯一指定了一个会话（2个进程之间的会话关系，还包含连接状态）
  • 应用使用这个标示，与远程的应用进程通信
  • 不必在每个报文的发送都指定这个4元组
  • 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名
  • 简单、便于管理

UDP socket
UDP socket：用于指明应用进程所在端节点的本地标示

  • UDP服务：两个进程之间的通信需要之前无需建立连接
    • 每个报文都是独立传输的
    • 前后报文可能给不同的分布式进程
  • 因此，只能用一个整数表示本应用实体的标示
    • 因为这个报文可能传给另外一个分布式进程
  • 穿过层间接口的信息大小最小
  • UDP socket：本IP+本端口。对于使用UDP的应用而言，套接字是2元组的一个具有本地意义的标示；
  • 发送报文的时候，采用创建好的本地套接字，就不必在发送每个报文中指明自己的ip和port
  • 但是传输报文时，必须要额外提供对方的IP+port，因为socket不包含目标IP和Port

套接字

  • 应用进程向套接字发送报文，从套接字接收报文
  • 套接字<->门户

问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用？（用户使用服务）

  • 定义应用层协议：报文格式，解释，时序等
  • 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等。

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

应用需要传输层提供什么样的服务？
（1）可靠数据传输
数据丢失率方面，有些应用要求100%的可靠数据传输（如文件），有些应用（如音视频）能容忍一定比例以下的数据丢失
（2）延迟
一些应用出于有效性考虑，对数据传输有严格的时间限制（网络电话，交互式游戏）
（3）吞吐
一些应用（比如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
（4）安全性
机密性；完整性；可认证性（鉴别）

2.1.4 因特网提供的运输服务

因特网（更一般的是TCP/IP网络） 为应用程序提供两个运输层协议， 即UDP和TCP。当你（作为一个软件开发者） 为因特网创建一个新的应用时， 首先要做出的决定是， 选择UDP还是选择TCP。

（1）TCP服务
TCP服务模型包括面向连接服务和可靠数据传输服务。
面向连接的服务：TCP让客户和服务器互相交换运输层控制信息。在握手阶段后， 一个TCP连接（TCP connection） 就在两个进程的套接字之间建立了。 这条连接是全双工的， 即连接双方的进程可以在此连接上同时进行报文收发。 当应用程序结束报文发送时， 必须拆除该连接。
可靠的数据传输服务：通信进程能够依靠TCP,无差错、 按适当顺序交付所有发送的数据。
拥塞控制机制， 这种服务不一定能为通信进程带来直接好处， 但能为因特网带来整体好处，当网络出现拥塞时，能抑制发送方。
流量控制：发送方不会淹没接收方。
不能提供的服务：时间保证、最小吞吐保证和安全。

（2）UDP服务
UDP是一种不提供不必要服务的轻量级运输协议， 它仅提供最小服务。
UDP是无连接的， 因此在两个进程通信前没有握手过程；UDP协议提供一种不可靠数据传送服务，可能丢失、乱序 。
不提供：可靠、流量控制、拥塞控制、时间、带宽保证、建立连接。

问题：为什么要有UDP？

  1. 能够区分不同的进程，而IP不能（在IP提供的主机到主机端到端功能的基础上，区分了主机的应用进程）
  2. 无需建立连接，省去了建立连接时间，适合事务性的应用（比如实时语音通话？）
  3. 不做可靠性的工作，例如检错重发，适合对实时性要求比较高而对正确性要求不高的应用（实时视频音频，比如直播这一类的，还有交互式游戏）
  4. 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

2 应用层 - 图1
TCP&UDP

  • 都没有加密
  • 明文通过互联网传输，甚至密码

安全TCP：SSL加密、 数据完整性和端到端鉴别。 我们强调SSL不是与TCP和UDP在相同层次上的第三种因特网运输协议， 而是一种对TCP的加强， 这种强化是在应用层上实现的。

2.1.5 应用层协议

应用层协议（application-layer protocol）定义了运行在不同端系统上的应用程序进程如何相互传递报文。
应用层协议定义了：
1、交换的报文类型， 例如请求报文和响应报文。
2、各种报文类型的语法， 如报文中的各个字段及这些字段是如何描述的。
3、字段的语义， 即这些字段中的信息的含义。
4、确定一个进程何时以及如何发送报文， 对报文进行响应的规则。

应用层协议只是网络应用的一部分

  • web应用：HTTP协议，web客户端，web服务器，HTML

在各层次中，应用层协议最多，因为应用层直接与用户交互，用户可以自己创新。

2.2 Web和HTTP

2.2.1 HTTP概况

Web的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP）,它是Web的核心 。HTTP由两个程序实现： 一个客户程序和一个服务器程序。 客户程序和服务器程序运行在不同的端系统中， 通过交换HTTP报文进行会话。 HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。
Web页面（Webpage）（也叫文档） 是由对象组成的。多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。
HTTP定义了 Web客户向Web服务器请求Web页面的方式， 以及服务器向客户传送Web页面的方式。 当用户请求一个Web页面时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文， 服务器接收到请求并用包含这些对象的HTTP响应报文进行响应。
HTTP使用TCP作为它的支撑运输协议 。
一旦客户向它的套接字接口发送了一个请求报文， 该报文就脱离了客户控制并进入TCP的控制。HTTP协议不用担心数据丢失， 也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。
HTTP是一个无状态协议 ，不存储客户的状态。（某个特定的客户在短短的几秒内两次请求同一个对象， 服务器并不会因为刚刚为该客户提供了该对象就不再做出反应， 而是重新发送该对象）
使用无状态协议同样的资源可以支持更多的用户连接。

2.2.2 非持续连接和持续连接

HTTP在其默认方式下使用持续连接。
RTT round time trip 往返时延
采用非连续连接的HTTP的缺点：

  • 必须为每一个请求的对象建立和维护一个全新的连接。 对于每个这样的连接， 在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担。
  • 每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP,另一个RTT用于请求和接收一个对象。

采用HTTP 1.1持续连接的情况下， 服务器在发送响应后保持该TCP连接打开。如果一条连接经过一定时间间隔（一个可配置的超时间隔） 仍未被使用， HTTP服务器就关闭该连接。
HTTP/2 ［RFC 7540］是在HTTP 1. 1基础上构建的， 它允许在相同连接中多个请求和回答交错， 并增加了在该连接中优化HTTP报文请求和回答的机制。

流水方式和非流水方式的持久HTTP

2.2.3 HTTP报文格式

HTTP报文有两种： 请求报文和响应报文。
（1）请求报文

  1. GET /somedir/page.html HTTP/1.1
  2. Host: www.someschool.edu
  3. Connection: close
  4. User-agent: Mozilla/5.0
  5. Accept-language: fr

HTTP请求报文的第一行叫作请求行（request line） ,其后继的行叫作首部行（header line）。
请求行有3个字段： 方法字段、 URL字段和HTTP版本字段。 方法字段的值包括：GET、POST、 HEAD、PUT和DELETE。
HEAD向服务器请求相应html对象的头部。用于维护、索引。
首部行Host指明了对象所在的主机；通过Connection: close首部行， 该浏览器要求服务器在发送完被请求的对象后就关闭这条连接（Connection: keep-alive）。 User-agent:首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。 Accept-language：首部行表示用户想得到该对象的法语版本。

  1. Content-type: application/json

（2）响应报文

  1. HTTP/1.1 200 OK
  2. Connection: close
  3. Date: Tue, 18 Aug 2015 15:44:04 GMT
  4. Server: Apache/2.2.3 (CentOS)
  5. Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
  6. Content-Length: 6821
  7. Content-Type: text/html
  8. (data data data data data ...)

有三个部分： 一个初始状态行（status line） , 6个首部行（headerline）,然后是实体体（entity body）。实体体是报文的主要部分。
状态行有3个字段： 协议版本字段、 状态码和相应状态信息。
常见的状态码和对应信息

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

书-p70
cookie允许站点对用户进行跟踪。比如购物网站，就需要服务器维护客户端的状态
cookie技术有4个组件：

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

2.2.5 Web缓存

Web缓存器（Web cache）也叫代理服务器（proxy server） ,它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本。

  1. 浏览器创建一个到Web缓存器的TCP连接， 并向Web缓存器中的对象发送一个HTTP请求。
  2. Web缓存器进行检查， 看看本地是否存储了该对象副本。 如果有， Web缓存器就向客户浏览器用HTTP响应报文返回该对象。
  3. 如果Web缓存器中没有该对象， 它就打开一个与该对象的初始服务器的TCP连接。
  4. 当Web缓存器接收到该对象时， 它在本地存储空间存储一份副本， 并向客户的浏览器用HTTP响应报文发送该副本。

Web缓存器既是服务器又是客户。
通常缓存是由ISP安装（大学，公司，居民区ISP）

是什么要使用Web缓存？

  • Web缓存器可以大大减少对客户请求的响应时间；
  • Web缓存器能够大大减少一个机构的接入链路到因特网的通信量，降低费用；
  • 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容

如果服务器端的内容更新了，但是缓存未更新，是不是会无法访问到更新后的内容？
使用下面介绍的条件GET

2.2.6 条件GET方法

请求报文使用GET方法且请求报文中包含一个“If-Modified-Since:”首部行
一个代理缓存器（proxy cache） 代表一个请求浏览器， 向某Web服务器发送一个请求报文

  1. GET /fruit/kiwi.gif HTTP/1.1
  2. Host: www.exotiquecuisine.com

该Web服务器向缓存器发送具有被请求的对象的响应报文:

HTTP/1.1 200 OK
Date: Sat. 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)

一个星期后， 另一个用户经过该缓存器请求同一个对象， 该对象仍在这个缓存器中。 由于在过去的一个星期中位于Web服务器上的该对象可能已经被修改了， 该缓存器通过发送一个条件GET执行最新检查。
If-Modified-Since：首部行的值正好等于一星期前服务器发送的响应报文中的Last-Modified:首部行的值。

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

假设没有被修改，Web服务器向该缓存器发送一个响应报文：
状态行中为304 Not Modified,它告诉缓存器可以使用该对象， 能向请求的浏览器转发它（该代理缓存器） 缓存的该对象副本：

HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)

可以避免重复传数据浪费带宽的同时有效更新缓存。

2.3 补充 FTP

向远程主机上传输文件或从远程主机接收文件
客户/服务器模式：客户端是发起传输的一方，服务器是远程主机
FTP服务器：端口号为21，使用TCP为传输协议
控制连接与数据连接分开，传送一个文件需要建立两个连接：控制连接&数据连接
客户端通过控制连接：（1）获得身份确认（2）发送命令浏览远程目录
收到一个文件传输命令时，服务器打开一个到客户端的数据连接，一个文件传输完成后，服务器关闭连接，服务器打开第二个TCP数据连接用来传输另一个文件
FTP服务器维护用户的状态信息：当前路径、用户账户与控制连接对应
是有状态的连接

2.3 补充 DHCP

动态主机配置协议
DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的连网方式，用户不再需要手动配置 IP 地址等信息。
DHCP 配置的内容不仅是 IP 地址，还包括子网掩码、网关 IP 地址。
DHCP 工作过程如下：

  1. 客户端发送 Discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，被放入 UDP 中，该报文被广播到同一个子网的所有主机上。如果客户端和 DHCP 服务器不在同一个子网，就需要使用中继代理。
  2. DHCP 服务器收到 Discover 报文之后，发送 Offer 报文给客户端，该报文包含了客户端所需要的信息。因为客户端可能收到多个 DHCP 服务器提供的信息，因此客户端需要进行选择。
  3. 如果客户端选择了某个 DHCP 服务器提供的信息，那么就发送 Request 报文给该 DHCP 服务器。
  4. DHCP 服务器发送 Ack 报文，表示客户端此时可以使用提供给它的信息。

image.png

2.3 因特网中的电子邮件

3个主要组成部分： 用户代理（user agent） 、 邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）。
用户代理允许用户阅读、 回复、 转发、 保存和撰写报文。
（1）当Alice完成邮件撰写时， 她的邮件代理向其邮件服务器发送邮件， 此时邮件放在邮件服务器的外出报文队列中。
（2）当Bob要阅读报文时， 他的用户代理在其邮件服务器的邮箱中取得该报文。

邮件服务器形成了电子邮件体系结构的核心。 每个接收方（如Bob）在其中的某个邮件服务器上有一个邮箱（mailbox）。Bob的邮箱管理和维护着发送给他的报文。
一个典型的邮件发送过程是： 从发送方的用户代理开始， 传输到发送方的邮件服务器， 再传输到接收方的邮件服务器， 然后在这里被分发到接收方的邮箱中。
Alice的邮箱也必须能处理Bob的邮件服务器的故障。 如果Alice的服务器不能将邮件交付给Bob的服务器, Alice的邮件服务器在一个报文队列（message queue）中保持该报文并在以后尝试再次发送。 通常每30分钟左右进行一次尝试； 如果几天后仍不能成功， 服务器就删除该报文并以电子邮件的形式通知发送方（Alice）
SMTP是因特网电子邮件中主要的应用层协议。 它使用TCP可靠数据传输服务， 从发送方的邮件服务器向接收方的邮件服务器发送邮件。

2.3.1 SMTP

SMTP是因特网电子邮件的核心。
一些特点：

  1. 它限制所有邮件报文的体部分（不只是其首部） 只能采用简单的7比特ASCII表示。（因为以前的传输能力不足，且一般不通过电子邮件发送大的附件或是大的图片）在用SMTP传送邮件之前，需要将二进制多媒体数据编码为ASCII码， 并且在使用SMTP传输后要求将相应的ASCII码邮件解码还原为多媒体数据。
  2. 全是明文

使用HTTP传送前不需要将多媒体数据编码为ASCII码。
2 应用层 - 图3

SMTP 一般不使用中间邮件服务器发送邮件， 即使这两个邮件服务器位于地球的两端也是这样。
如果Bob的邮件服务器没有开机， 该报文会保留在Alice的邮件服务器上并等待进行新的尝试， 这意味着邮件并不在中间的某个邮件服务器存留。

S: 220 hamburger・edu
C: HELO crepes.fr
S: 250 Hello crepes.frf pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles? 
c: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP用的是持续连接 持久连接

2.3.2 与HTTP对比

（1）HTTP是一个拉协议（pull protocol），TCP连接是由想接收文件的机器发起的；SMTP基本上是一个推协议（push protocol），TCP连接是由要发送文件的机器发起的。
（2）SMTP要求每个报文（包括它们的体） 采用7比特ASCII码格式。而HTTP协议不受编码限制。
（3）如何处理一个既包含文本又包含图形（也可能是其他媒体类型） 的文档，HTTP把每个对象封装到它自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文之中。
（4）二者都是ASCII形式的命令/响应交互、状态码

2.3.3 邮件报文格式

#首部看起来如下,from和to是必须有的，subject可选
From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life

在报文首部之后， 紧接着一个空白行， 然后是以ACSII格式表示的报文体。

2.3.4 邮件访问协议

典型的用户通常在本地PC上运行一个用户代理程序， 而它访问存储在总是保持开机的共享邮件服务器上的邮箱。 该邮件服务器与其他用户共享， 并且通常由用户的ISP进行维护

2 应用层 - 图4

Bob的用户代理不能使用SMTP得到报文， 因为取报文是一个拉操作， 而SMTP协议是一个推协议。
SMTP用来将邮件从发送方的邮件服务器传输到接收方的邮件服务器； SMTP也用来将邮件从发送方的用户代理传送到发送方的邮件服务器。 如POP3、IMAP、HTTP这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理。

2.4 DNS：因特网的目录服务

DNS是提供给机器使用的服务。DNS系统是一个基础性系统

2.4.1 DNS提供的服务

域名系统（Domain Name System, DNS），提供主机名到IP地址转换的目录服务。
DNS是： ①一个由分层的DNS服务器（DNS server）实现的分布式数据库； ②一个使得主机能够查询分布式数据库的应用层协议。
DNS协议运行在UDP之上， 使用53号端口。
除了进行主机名到IP地址的转换外， DNS还提供了一些重要的服务：

  1. 主机别名
  2. 邮件服务器别名
  3. 负载分配：繁忙的站点可能被冗余地分布在多台服务器上，一个IP地址集和与同一个规范主机名相联系，DNS在冗余的WEB服务器之间循环分配了负载。

2.4.2 DNS工作机理概述

DNS的一种简单设计是在因特网上只使用一个DNS服务器， 该服务器包含所有的映射。在单一DNS服务器上运行集中式数据库完全没有可扩展能力。存在：单点故障、通信容量、远距离的集中式数据库、维护等问题。
（1）分布式层次数据库
大致说来， 有3种类型的DNS服务器： 根DNS服务器、 顶级域(Top Level Domain, TLD) DNS服务器和权威DNS服务器。

2 应用层 - 图5
还有另一类重要的DNS服务器， 称为本地DNS服务器（local DNS server）。严格说来， 一个本地DNS服务器并不属于该服务器的层次结构， 但它对DNS层次结构是至关重要的。 每个ISP （如一个居民区的ISP或一个机构的ISP）都有一台本地DNS服务器（也叫默认名字服务器） 。 当主机与某个ISP连接时， 该ISP提供一台主机的IP地址， 该主机具有一台或多台其本地DNS服务器的IP地址。

查询：迭代查询+递归查询
image.pngimage.png

域的划分和物理网络无关，同一网络可以属于不同的域，同一域可以属于不同的网络。
区域（zone）

  • 区域的划分有区域管理者自己决定
  • 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
  • 名字服务器（Name Server）：
    • 每个区域都有一个名字服务器；维护着它所管辖区域的权威信息；权威名字服务器
    • 名字服务器允许被放置在区域之外，以保障可靠性

DNS大致工作过程：

  • 应用调用解析器（resolver）
  • 解析器作为客户向Name Server发出查询报文（封装在UDP中）
  • Name Server返回响应报文（name/ip）

可以指定任何name server为local name server，一般来说指定比较近的，因为快。local name server一般也称为默认名字服务器。

（2）DNS缓存
本地DNS服务器也能够缓存TLD服务器的IP地址， 因而允许本地DNS绕过查询链中的根DNS服务器。
由于主机和主机名与IP地址间的映射并不是永久的， DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息 。
可能存在情况有变，但是访问的是旧信息。

2.4.3 DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(Resource Record,RR), RR提供了主机名到IP地址的映射。
资源记录是一个包含了下列字段的4元组:

(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的邮件服务器的规范主机名。

（1）DNS报文
2 应用层 - 图8

  • 前12个字节是首部区域， 其中有几个字段。
    • 第一个字段（标识符） 是一个16比特的数， 用于标识该查询。 这个标识符会被复制到对查询的回答报文中， 以便让客户用它来匹配发送的请求和接收到的回答。
    • 标志字段中含有若干标志。 1比特的“查询/回答” 标志位指出报文是查询报文 （0）还是回答报文（1）。当某DNS服务器是所请求名字的权威DNS服务器时， 1比特的“权威的” 标志位被置在回答报文中。 如果客户（主机或者DNS服务器） 在该DNS服务器没有某记录时希望它执行递归查询， 将设置1比特的“希望递归” 标志位。 如果该DNS服务器支持递归查询， 在它的回答报文中会对1比特的“递归可用” 标志位置位。
    • 有4个有关数量的字段， 这些字段指出了在首部后的4类数据区域出现的数量。
  • 问题区域包含着正在进行的查询信息。 该区域包括： ①名字字段， 包含正在被查询的主机名字； ②类型字段， 指出有关该名字的正被询问的问题类型。
  • 在来自DNS服务器的回答中， 回答区域包含了对最初请求的名字的资源记录。 前面讲过每个资源记录中有Type （如A、NS、CNAME和MX）字段、 Value字段和TTL字段。 在回答报文的回答区域中可以包含多条RR,因此一个主机名能够有多个IP地址（例如， 就像本节前面讨论的冗余Web服务器） 。
  • 权威区域包含了其他权威服务器的记录
  • 附加区域包含了其他有帮助的记录。

（2）在DNS数据库中插入记录

  • 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
  • 在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字->IP地址

例如：在com域中建立一个networkutopia.com；

  • 到注册登记机构注册域名networkutopia.com
    • 需要向该机构提供权威DNS服务器（基本的、辅助的）的名字和IP地址
    • 登记机构在com TLD服务器中插入两条RR记录

(networkutopia.com, dnsl.networkutopia.com,NS）
(dnsl.networkutopia.com, 212.212.212.1, A)

  • 在networkutopia.com的权威服务器中确保有：
    • 用于web服务器的类型为A的记录
    • 用于邮件服务器mail.networkutopia.com的类型为MX的记录

（3）攻击DNS
总的来说，DNS比较健壮

  • DDoS攻击：全称Distributed Denial of Service，中文意思为“分布式拒绝服务”，就是利用大量合法的分布式服务器对目标发送请求，从而导致正常合法用户无法获得服务。

攻击根服务器，TLD服务器

  • 重定向攻击

截获查询，伪造回答。
发送伪造的应答给DNS服务器，希望他能够缓存这个虚假的结果。

  • 利用DNS基础设施进行DDoS—-不太理解

伪造某个IP进行查询，攻击这个目标IP
查询放大，响应报文比查询报文要大

一个网上的说法：
主域名服务器和辅域名服务器区别为：地址查询不同、数据存放不同、授权不同。
一、地址查询不同
1、主域名服务器：主域名服务器负责本地域名的地址查询。
2、辅域名服务器：辅域名服务器负责非本地域名的地址查询。

二、数据存放不同
1、主域名服务器：主域名服务器是地址数据的初始来源，并具有向任何一个甚至全部需要其数据的服务器发布域的信息的功能。
2、辅域名服务器：辅域名服务器不是区域源数据存放的地方，通常从域的主DNS服务器获得区域数据。

2.5 P2P文件分发

前面描述的应用（包括Web、电子邮件和DNS）都采用了客户-服务器体系结构， 极大地依赖于总是打开的基础设施服务器。
P2P适用于：文件分发，流媒点播，音频视频传输
本节研究从单一服务器向大量主机（称为对等方）分发一个大文件。
在客户-服务器文件分发中， 该服务器必须向每个对等方发送该文件的一个副本， 即服务器承受了极大的负担， 并且消耗了大量的服务器带宽。
在P2P文件分发中， 每个对等方能够向任何其他对等方重新分发它已经收到的该文件的任何部分， 从而在分发过程中协助该服务器。

（1）P2P体系结构的扩展性
自扩展性
当一个对等方接收到某些文件数据， 它能够使用自己的上载能力重新将数据分发给其他对等方。
对等方除了是比特的消费者外还是它们的重新分发者。
（2）BitTorrent

不想看。。非结构化P2P和结构化P2P
视频2.6 20分钟左右开始
（1）非结构化P2P
两大问题：如何定位所需资源？如何处理对等方的加入与离开？
可能的方案：集中；分散；半分散。
（2）结构化P2P
结构化P2P基于Hash值

  • 哈希表
  • DHT方案
  • 环形DHT 以及覆盖网络
  • Peer波动

2.6 视频流和内容分发网

视频流化服务和CDN：上下文
CDN的全称是Content Delivery Network，即内容分发网络。
（杀手级业务）

2.6.2 HTTP 流和 DASH

多媒体流化服务 DASH
Dynamic Adaptive Streaming over HTTP，经HTTP的动态适应性流

  • 服务器
    • 将视频文件分割成多个块
    • 每个块独立存储，编码于不同码率（8-10种）
    • 告示文件（manifest file）：提供不同块的URL
  • 客户端
    • 先获取告示文件
    • 周期性地测量服务器到客户端的带宽
    • 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围

如果带宽足够，选择最大码率的视频块
会话中的不同时刻，可以切换请求不同的编码块（取决于当时的可用带宽）

挑战：服务器如何通过网络向上百万用户同时流化视频内容？
如果使用单个的大的超级服务中心，方法简单但不可扩展。
存在：①服务器到客户端路径上跳数多，瓶颈链路带宽小导致停顿；②“二八规律”，网络中会同时充斥着一个视频的多个拷贝，重复流量多，网络资源浪费；③单点故障，性能瓶颈可靠性差；④周边网络拥塞的问题。
可以使用CDN解决上面问题

2.6.3 内容分发网 CDN

特别之处：在应用层，在网络边缘实现。
通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验。让内容靠近用户。
两种缓存节点的部署策略：

  • enter deep：将CDN服务器深入到许多接入网
    • 更接近用户，数量多，离用户近，节点多（Akami 1700个）所以管理困难
  • bring home：部署在少数（10个左右）关键位置
    • limelight

预先在CDN节点中存储内容的多个拷贝。用户从CDN中请求内容，重定向到最近的拷贝，请求内容。不需要请求原服务器。
互联网络主机-主机之间的通信行为作为一种服务向用户提供。
挑战：

  1. 从哪个CDN节点获取内容？
  2. 用户在网络拥塞时的行为？
  3. 在哪些CDN节点存储什么内容？

第2章小结

应用程序体系结构：

  • 客户-服务器
  • P2P
  • 混合

应用程序需要的服务品质描述

  • 可靠性、带宽、延时、安全

Internet传输层服务模式

  • 可靠的、面向连接的服务：TCP
  • 不可靠的数据报：UDP

流行的应用层协议：

  • HTTP
  • FTP
  • SMTP、POP、IMAP
  • DNS

Socket编程
另外：学习协议的知识
应用层协议报文类型：请求、响应报文

  • 客户端请求信息或服务
  • 服务器以数据，状态码进行响应

报文格式

  • 首部：关于数据信息的字段
  • 数据：被交换的信息

控制报文 VS 数据报文
集中式 VS 分散式
无状态 VS 维护状态
可靠的 VS 不可靠的报文传输
在网络边缘处理复杂性