应用层续

DNS（域名解析系统）

前面说的都是应用层的协议 和相关案例

应用层协议 和 例子都是所有案例中最多的。 域名解析系统是给其他应用应用的应用通过其他应用来为应用提供服务。

dns提供的是： 域名到 ip地址的转换

DNS的重要性（必要性）

• IP地址标识主机、路由器
• 但IP地址不好记忆，不便人类使用(没有意义)
• 人类一般倾向于使用一些有意义的字符串来标识 Internet上的设备(大实话)

例如：qzheng@ustc.edu.cn 所在的邮件服务器 www.ustc.edu.cn 所在的web服务器

• 存在着“字符串”—– IP地址的转换的必要性
• 人类用户提供要访问机器的“字符串”名称
• 由DNS负责转换成为二进制的网络地址

DNS系统需要解决的问题

主要解决的问题就是域名到ip地址的转换

1. 问题1： 如何命名设备

需要通过一些有意义的字符串来标识设备。便于记忆

解决一个平面命名的重名问题：层次化命名

1. 问题2：如何完成(域名)名字到IP地址的转换

分布式的数据库维护和响应名字查询

1. 问题3：如何维护：增加或者删除一个域，需 要在域名系统中做哪些工作

DNS (Domain Name System) 的发展历史

ARPANET 的名字解析 解决方案：

1. 主机名：没有层次的一个字符串（一个平面）
2. 存在着一个（集中）维护站：维护着一张 主机名-IP地址 的映射文件：****Hosts.txt
3. 每台主机定时从维护站取文件

上述ARPANET 的名字解析 解决方法所遇到的问题：

当网络中主机数量很大时

没有层次的主机名称很难分配

文件的管理、发布、查找都很麻烦

DNS的总体设计思路和目标

设计思路：

• 分层的、基于域的命名机制 （分层命名）
• 若干分布式的数据库完成名字到IP地址的转换

通过上面的方式来解决名字到ip地址的转换关系。

• 运行在UDP之上端口号为53的 应用服务

• 核心的Internet功能，但以应用层协议实现

• • 在网络边缘处理复杂性

互联网的很多核心功能都是在网络的边缘，通过端系统之上的应用进程来实现的。（复杂性体现在边上， 传输层及以上)

DNS的主要目的：

1. 实现主机名-IP地址的转换(name/IP translate)
2. 其它目的

• 主机别名到规范名字的转换：Host aliasing
• 邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing
• 负载均衡：Load Distribution

解决的三个问题 ：

问题一 ： DNS名字空间(The DNS Name Space)

DNS域名结构 ：

1. 一个层面命名设备会有很多重名
2. NDS采用层次树状结构的 命名方法
3. Internet 根被划为几百个顶级域(top lever domains)

通用的

.com; .edu ; .gov ; .int ; .mil ; .net ; .org .firm ; .hsop ; .web ; .arts ; .rec ;

国家级别的:

.cn ; .us ; .nl ; .jp

1. 每个(子)域下面可划分为若干子域(subdomains)
2. 树叶是主机

DNS: 根名字服务器

全球只有这13个。中国这边没有。

10个在美国、1个在英国、1个在瑞典、1个在荷兰

这是存在一些安全隐患的，我国只有相关的镜像

创建一个新的域，必须征得它所属域的同意 。

DNS名字空间(The DNS Name Space)

域名（Domain Name）

1. 从本域往上，直到树根 所有的都属于这个域名
2. 中间使用“.”间隔不同的级别

例如： ustc.edu.cn 、 auto.ustc.edu.cn …

1. 域的域名：可以用于表示一个域
2. 主机的域名：一个域上的一个主机

域名的管理

一个域管理其下的子域 （前缀树)

.jp 被划分为 ac.jp co.jp ；

.cn 被划分为 edu.cn com.cn ；

创建一个新的域，必须征得它所属域的同意 （）

域与物理网络无关

• 域的划分是逻辑的，而不是物理的
• 域遵从组织界限，而不是物理网络

一个域的主机可以不在一个网络 。但是， 一个网络的主机不一定在一个域

问题二： 解析问题-名字服务器(Name Server)

一个名字服务器存在的相关问题

可靠性问题：单点故障

扩展性问题：通信容量

维护问题：远距离的集中式数据库

分布式解决一个名字服务器的问题： ‘划分’ 区域(zone)

1. 区域的划分有区域管理者自己决定
2. 将DNS名字空间划分为互不相交的区域，每个区域都是 树的一部分
3. 名字服务器：

每个区域都有一个名字服务器：维护着它所管辖区域的权威信息 (authoritative record)

权威名字服务器允许被放置在区域之外，以保障可靠性

将互联网名字空间划分为若干区域（Zone）

权威DNS服务器：组织机构的DNS服务器， 提供组织机构服务器（如 Web和mail）可访问的主机和IP之间的映射

组织机构可以选择实现自己维护或由某个服务提供商来维护

TLD服务器：

1. 顶级域(TLD)服务器：

负责顶级域名（如com, org, net, edu和gov）和所有国家级的顶级域名（如cn, uk, fr, ca, jp ）

比如： Network solutions 公司维护com TLD服务器

Educause公司维护edu TLD服务器

1. 顶级域名字服务器需要 维护资源的记录

DNS ：保存资源记录(RR)的分布式数据库

资源记录(resource records)

• 作用：维护 域名-IP地址(其它)的映射关系
• 位置：Name Server的分布式数据库中

RR格式: (domain_name, ttl, type,class,Value)

• • Domain_name: 域名
  • ttl: time to live : 生存时间(权威，缓冲记录)
  • Class 类别 ：对于Internet，值为IN
  • Value 值：可以是数字，域名或ASCII串(服务器的别名)
  • Type 类别：资源记录的类型—见下页

key：子域, value：该子域的子域服务器

key：子域服务器, value：该子域服务器IP地址

举例：

DNS大致工作过程

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

一个机器上线之后必须具备以下的几个信息 :

IP，掩码，网关，DNS

1. ip地址是什么
2. 子网掩码是什么 （）
3. localname server本地服务器() 是什么（名字的问题去解析 需要问哪个ip名字服务器.）
4. default getway默认网关（就是在一个局域网内部， 我的ip是这个，如果我想要出去这个局域网该走哪个路由器。 ）

本地名字服务器（Local Name Server）

获取名字到ip的对应关系。

• 并不严格属于层次结构
• 每个ISP (居民区的ISP、公司、大学）都有一 个本地DNS服务器

也称为“默认名字服务器”

• 当一个主机发起一个DNS查询时，查询被送到 其本地DNS服务器

起着代理的作用，将查询转发到层次结构中

名字服务器（Name Server）

名字解析的过程：

目标名字在本地服务器中(有缓存)

1. 查询的名字在该区域内部
2. 缓存（cashing）

没有缓存的话：

当与本地名字服务器不能解析 名字时，联系根名字服务器 顺着根-TLD 一直找到 权威名字服务器

也就是向上查询

www.ustc.edu.cn :

假设一个他国的公司的一台设备需要解析上述的域名所对应的ip地址

1. 首先查询本地name server 有没有缓存（不在一个局域网八成是没有的。）
2. 如果没有那么就向上递归查找， 看 .cn
3. .cn知道 .edu.cn的域名服务器。
4. .edu.cn 又知道 ustc.edu.cn 的域名服务器。
5. 到最后一直找打最终的域名对应的ip地址。

上述的查询方式是递归查询方式

还有一种查询方式是****迭代查询

假设 ： 主机cis.poly.edu 想知道 主机 gaia.cs.umass.edu 的IP地址

1. 根（及各级域名）服务器 返回的不是查询结果，而 是下一个NS的地址
2. 最后由权威名字服务器给 出解析结果
3. 当前联络的服务器给出可 以联系的服务器的名字
4. “我不知道这个名字，但 可以向这个服务器请求”

DNS协议、 报文

DNS协议：查询和响应报文的报文格式相同

提高性能 ： 缓存

一旦名字服务器学到了一个映射，就将该映射 缓存起来

根服务器通常都在本地服务器中缓存着

使得根服务器不用经常被访问

目的：提高效率

可能存在的问题：如果情况变化，缓存结果和 权威资源记录不一致

解决方案：TTL（默认2天）

问题三：维护问题：新增一个域

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

例子：在com域中建立一个“Network Utopia”

1. 到注册登记机构注册域名networkutopia.com

1.1. 需要向该机构提供权威DNS服务器（基本的、和辅助的）的名字 和IP地址

1.2. 登记机构在com TLD服务器中插入两条RR记录: (networkutopia.com, dns1.networkutopia.com, NS)(dns1.networkutopia.com, 212.212.212.1, A)

1. 在networkutopia.com的权威服务器中确保有

• 用于Web服务器的www.networkuptopia.com的类型为A的记录
• 用于邮件服务器mail.networkutopia.com的类型为MX的记录

攻击DNS

P2P应用

之前介绍的例子都是CS模型的， 但是CS模型存在很多问题 。

比如： 可扩展性、可靠性等。 随着用户数量的不断增多， 用户都从服务器去获取服务（文件、视频检波等）， 一旦服务挂了。 所有应用都无法服务

什么是P2P？

大概就是一个节点既是服务器又是客户端。

纯P2P架构

• 没有（或极少）一直运行的 服务器
• 任意端系统都可以直接通信
• 利用peer的服务能力
• Peer节点间歇上网，每次IP 地址都有可能变化

例子：

1. 文件分发（BitTorrent）
2. 流媒体（KanKan）【从其他的节点获取流量，不需要从其他的服务器去获取信息】
3. VoIP（Skype）【互联网打电话】

文件分发（BitTorrent)

[C/S vs P2P]

在cs模式中， 一般都是由服务器提供上载， 客户端提供下载，有些客户端也能够提供上载服务 ，但是速率十分慢， 所以可以忽略不记。

而p2p模式则不是。 它是将一个节点既是客户端又是服务器端

1. 问题: 从一台服务器分发文件（大小F）到N个peer 需要多少时间？

从peer节点上下载能力是有限的

下载下线就是说下载最慢的时间

文件分发时间： C/S模式

服务器传输： 都是由服务器 发送给peer，服务器必须顺序 传输（上载）N个文件拷贝:

• 发送一个copy: F/us
• 发送N个copy： NF/u

客户端: 每个客户端必须下 载一个文件拷贝

• dmin = 客户端最小的下载速率
• 下载带宽最小的客户端下载的 时间：F/dmin

文件分发时间: P2P模式

服务器传输：最少需要上载一份拷贝

• 发送一个拷贝的时间：F/u

客户端： 每个客户端必须下载一 个拷贝

• 最小下载带宽客户单耗时：: F/dmin

所有客户端总体下载量NF （N是要下载n份， 一个文件的大小是F，所以总的下载量是NF****）

• 最大上载带宽是：Us + Σui （Us: 服务器的上载带宽 + 每个peer节点的上载带宽）
• 除了服务器可以上载，其他所有的peer节点都可以上载

举例：

Client-server VS P2P的例子

如果说当服务器充足的时候，想要提高效率的话， 客户端的下载能力是瓶颈， 但是如果当服务器数量不能再增加，但是客户端又要增加的时候， 那么此时服务器的上载能力则是瓶颈。 毕竟客户端的数量是远远大于服务器端的数量的。

客户端上载速率 = u, F/u = 1 小时, Us = 10u, dmin ≥ Us

从上述可以看出。 纯clent-server模式， 一旦客户端的数量达到一定的程度， 他的速率就完全定格了（因为服务器的数量有限， 所以此时决定速率的就是服务器的上载速率。 ）

而我们使用的p2p（peer to peer） 也就是我们常说的人人为我我为人人。每个peer ，它既可以上载也可以作为clent进行下载。 效率会随着机器数量的add 而不断的 add。 效率完全取决于用户数量。 十分适合现在的体系

P2P文件分发： BitTorrent

p2p的管理模式

• 非结构化p2p（分布式散列表）： 每个peer之间构成的关系（上传下载），互通有无，就构成了一个有序的覆盖网（类似于环、树的关系）

• 结构化P2P： peer节点之间构成的覆盖关系是任意的、无序的。

• 文件被分为一个个块256KB

• 网络中的这些peers发送接收文件块，相互服务

Peer加入torrent

• 一开始没有块，但是将会通 过其他节点处累积文件块
• 向跟踪服务器注册，获得 peer节点列表，和部分peer 节点构成邻居关系 (“连接 ”)

• 当peer下载时，该peer可以同时向其他节点提供上载服务
• Peer可能会变换用于交换块的peer节点
• 扰动churn : peer节点可能会上线或者下线
• 一旦一个peer拥有整个文件，它会（自私的）离开或者保 留（利他主义）在torrent中

BitTorrent: 请求，发送文件块

请求块：

• 在任何给定时间，不同 peer节点拥有一个文件块 的子集

• 周期性的，Alice节点向 邻居询问他们拥有哪些块 的信息

• Alice向peer节点请求它 希望的块，稀缺的块

发送块：一报还一报titfor-tat

• Alice向4个peer发送块，这些 块向它自己提供最大带宽的服 务

• • 其他peer被Alice阻塞 (将不会 从Alice处获得服务)
  • 每10秒重新评估一次：前4位

• 每个30秒：随机选择其他peer 节点，向这个节点发送块

• • “优化疏通” 这个节点
  • 新选择的节点可以加入这个top 4

BitTorrent: tit-for-tat

(1) Alice “优化疏通” Bob

(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice

(3) Bob 变成了Alice的前4提供者

P2P文件共享

应用例子：

P2P文件共享需要解决的有两个问题：

1. 如何定位所需资源（目录服务的问题）
2. 如何处理对等方的加入与离开（节点的管理问题）

已知的解决方案：

• 集中
• 分散
• 半分散

P2P：集中式目录

最初的“Napster”设计

• \1) 当对等方连接时，它告知 中心服务器：

• • IP地址
  • 内容

• \2) Alice查询 “双截棍.MP3”(资源)

• \3) Alice从Bob处请求文件 （下载or其他）

• Bob响应并处理请求

P2P：集中式目录中存在的问题

• 单点故障（目录服务器挂了怎么办）
• 性能瓶颈 （clent-server问题，很多的clent对应一个serveer）
• 侵犯版权

文件传输是分散的， 而定位内容则是高度 集中的

完全分布式（一个实例 查询洪泛：Gnutella ）

解决的两个问题：

1. 如何定位所需资源（目录服务的问题）
2. 如何处理对等方的加入与离开（节点的管理问题）

• 全分布式

• • 没有中心服务器

• 开放文件共享协议

• 许多Gnutella客户端 实现了Gnutella协议

• • 类似HTTP有许多的 浏览器

覆盖网络：图

1. 如果X和Y之间有一个 TCP连接，则二者之间 存在一条边
2. 所有活动的对等方和边 就是覆盖网络
3. 边并不是物理链路
4. 给定一个对等方，通常 所连接的节点少于10个

Gnutella: 协议

• 在已有的TCP连接上 发送查询报文
• 对等方转发查询报文
• 以反方向返回查询命 中报文
• 文件传输：HTTP

可扩展性： 限制范围的 洪泛查询

Gnutella：对等方加入

1. 对等方X必须首先发现某些已经在覆盖网络中的其他对
   等方：使用可用对等方列表
   自己维持一张对等方列表（经常开机的对等方的IP）
   联系维持列表的Gnutella站点
2. X接着试图与该列表上的对等方建立TCP连接，直到与
   某个对等方Y建立连接
3. X向Y发送一个Ping报文，Y转发该Ping报文
4. 所有收到Ping报文的对等方以Pong报文响应
   IP地址、共享文件的数量及总字节数
5. X收到许多Pong报文，然后它能建立其他TCP连接

Gnutella： 对等方离开

个人理解： 可以通过加TTL

半分散（ 利用不匀称性：KaZaA ）

1. 每个对等方要么是一个 组长，要么隶属于一个 组长

2. 1. 对等方与其组长之间有 TCP连接
   2. 组长对之间有TCP连接

3. 组长跟踪其所有的孩子 的内容

4. 组长与其他组长联系

5. 1. 转发查询到其他组长
   2. 获得其他组长的数据拷贝

KaZaA：查询

1. 每个文件有一个散列标识码和一个描述符

2. 客户端向其组长发送关键字查询

3. 组长用匹配进行响应：

4. 1. 对每个匹配：元数据、散列标识码和IP地址

5. 如果组长将查询转发给其他组长，其他组长也以匹配进行响应

6. 客户端选择要下载的文件

7. 1. 向拥有文件的对等方发送一个带散列标识码的 HTTP请求

Kazaa小技巧

1. 请求排队

• 限制并行上载的数量
• 确保每个被传输的文件从上载节点接收一定量的带宽

1. 激励优先权

• 鼓励用户上载文件
• 加强系统的扩展性

1. 并行下载

• 从多个对等方下载同一个文件的不同部分

CDN

背景：

随着网络得普及， 视频类业务占据着流量市场得大部分带宽， 人数也是占有量最大得。
如何让用户之间能够同步得播放视频等成为了互联网得最大挑战之一。

单个超级服务器无法提供服务。
解决方案： 分布式应用层可解决， 应用层面的基础设施。

多媒体视频

视频：固定速度显示的图像序列。

网络视频特点：

• 高码率：>10x于音频,高的网络带 宽需求
• 可以被压缩
• 90%以上的网络流量是视频

** 数字化图像：像素的阵列 （ **每个像素被若干bits表示 ）
编码：使用图像内和图像间的 冗余来降低编码的比特数

• 空间冗余(图像内)
• 时间冗余(相邻的图像间)

• **CBR: (constant bit rate): 以固定速率编码 **
• VBR: (variable bit rate): 视频编码速率随 时间的变化而变化
• 例子:
  • MPEG 1 (CD-ROM) 1.5 Mbps
  • MPEG2 (DVD) 3-6 Mbps
  • MPEG4 (often used in Internet, < 1 Mbps)

存储视频得流化服务（Streaming）

多媒体流化服务 ： DASH

DASH: Dynamic, Adaptive Streaming over HTTP

用户在播放视频时边下载边播放， 减少因为网络原因得卡顿。
相当于我们看虎牙直播 ，如果当前得网络不支持4k， 那么就会切换成1080p

**服务器: **

• 将视频文件分割成多个块
• 每个块独立存储，编码于不同码率（8-10种[1080p、4k等等 ] ）
• 告示文件（manifest file）: 提供不同块的URL

**客户端: **

• 先获取告示文件
• 周期性地测量服务器到客户端的带宽
• 查询告示文件,在一个时刻请求一个块，HTTP头部指定字 节范围
  • 如果带宽足够，选择最大码率的视频块
  • 会话中的不同时刻，可以切换请求不同的编码块 (取 决于当时的可用带宽)

“智能”客户端: 客户端自适应决定（动态自适应）

1. 什么时候去请求块 (不至于缓存挨饿，或者溢出)
2. 请求什么编码速率的视频块 (当带宽够用时，请求高质 量的视频块)
3. 哪里去请求块 (可以向离自己近的服务器发送URL，或 者向高可用带宽的服务器请求)

Content Distribution Networks （CDN）

CDN： 内容分发网络

大家都是从一个或者说微缩非常少的服务器上去流化服务的化会带来什么问题？ （也就是高并发情况）

**挑战: **服务器如何通过网络向上百万用户同时 流化视频内容 (上百万视频内容)?
以下的几种方法…

使用单个， 超大的超级服务中心 “megaserver”出现的问题

通过服务器自身的提升来提高效率

• 服务器到客户端路径上跳数较多，瓶颈链路的带宽 小导致停顿
• “二八规律”决定了网络同时充斥着同一个视频的 多个拷贝，效率低（付费高、带宽浪费、效果差）
• 单点故障点，性能瓶颈
• 周边网络的拥塞

** 相当简单，但是这个方法不可扩展 **

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

CDN： 内容分发网络
CDN的运营商将节点部署按照一定的部署策略 将节点部署到世界各地， 然后如果某个商户（假设抖音）， 上传视频给用户去看， 视频就会上传的很多节点上， 然后不同地方的用户设备通过就近原则找到自己附件的节点 ，然后将视频拉去到本地。然后给用户看。

enter deep: 将CDN服务器深入到许多接入网

• 更接近用户，数量多，离用户近，管理困难
• Akamai, 1700个位置

**bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近（离若干1stISP POP较近） **

• 采用租用线路将服务器簇连接起来
• Limelight

**用户如何知道访问的内容是从哪里访问的呢？ **

1. 告示文件（manifest file）: 提供不同块的URL
2. 通过域名解析的重定向

**CDN: 在CDN节点中存储内容的多个拷贝 **
• e.g. Netflix stores copies of MadMen
** 用户从CDN中请求内容 **

• 重定向到最近的拷贝，请求内容
• 如果网络路径拥塞，可能选择不同的拷贝

CDN网络的特点就是： 采用主机-主机之间的服务来加速内容访问。

OTT 挑战: 在拥塞的互联网上复制内容

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

场景：

** Bob(客户端)请求视频http://netcinema.com/6Y7B23V **

• **视频存储在CDN，位于http://KingCDN.com/NetC6y&B23V **

最早的网络视频点播服务（网飞）Netflix

将自己制作的内容发给很多的CDN运营商， 通过这些运营商来传播自己的内容。

TCP套接字（Socket）编程

UDP套接字编程