DNS域名系统 (Domain Name System)
在许多名称服务器的层次结构中实现的分布式数据库 (distributed database)。应用层协议:主机,名称服务器进行通信以解析名称 (地址/名称转换 address/name translation)。
DNS服务
主机名到IP地址的转换(主机别名 host aliasing)。复制的Web服务器,许多IP地址对应一个名称。内容分发网络 (Content Distribution Networks),使用请求主机的IP地址查找最合适的服务器 (如最接近或负载最小的等)。
不中心化DNS (centralize DNS) 的原因:
- 单点故障 (single point of failure)
- 流量 (traffic volume)
- 远程集中式数据库 (distant centralized database)
- 维护 (maintenance)
DNS的实现目标:
- 没有命名冲突 name conflicts (具有唯一性 uniqueness)
- 可扩展 scalable (域名有很多,且是频繁更新的)
- 分布式自治管理 (distributed, autonomous administration): 能够更新其自己的域名。不必跟踪每个站点的更新。
- 高度可用 (highly available)。
- 查找 (look-up) 应该要很快。
关键思想:层次结构 (Hierarchy)
三个相互交织的层次结构
- 分层命名空间 (Hirerachical namespace): 与原始平面名称相反。
- 分层管理 (Hierachically administered): 与中心化相反。
- 服务器的 (分布式) 层次结构 (distributed hierarchy of servers)。与集中存储相反。
分层命名空间
“顶级域名” (Top Level Domain) 位于顶部。每个域是子树 (如 edu,berkeley.edu,eecs.berkeley.edu 等)。名称是从叶子到根路径。(如 instr.eecs.berkeley.edu)。树的深度是任意的(限制128)。
命名冲突能够被避免 (每个域都有责任)。
分层管理
一个区域对应了由管理机构 (administrative authority) 管理的DNS命名空间的不同连续部分。
如,USB控制命名:*.berkeley.edu 和 *.sims.berkeley.edu
服务器层次 (Server Hierarchy)
- 层次结构顶部: root 服务器 (连接到其他服务器位置)。
- 下一级别是顶级域 (Top-level Domain - TLD) 服务器 (如 .com, .edu等)。
- 专业管理,底层是 权威DNS服务器 (Authoritative DNS servers)。其存储了 名称到地址 的映射。并由相应的行政机关所维护。
- 每个服务器存储整个DNS数据库的一个(小的)子集。
- 权威DNS服务器为它有权访问的域中的所有DNS名称存储 “资源记录”(resource records)。
- 每个服务器都可以负责层次结构其他部分的服务器。每个服务器都知道根服务器。根服务器知道所有顶级域。
TLD, 权威服务器 (Authoritative servers)
- 顶级域 (TLD) 服务器: 负责 .com, .org, .net, .edu, .aero, .jobs, .museums, 以及所有顶级国家地区域,如 .uk, .fr, .ca, .jp。
- 权威DNS服务器: 组织自己的DNS服务器,为组织的命名主机提供IP映射的权威主机名。其可以由组织或服务提供商 (service provider) 进行维护。
- 本地DNS名称服务器 (Local DNS name server): 不严格属于层次结构。每个ISP都有一个。也被称作为“默认名称服务器”或“DNS解析器 resolver”。使用本地DNS服务器地址配置的主机 (如,/etc/resolv.conf) 或通过主机配置协议(host configuration protocol, 如DNCP)来了解服务器。
当主机进行DNS查询时,查询将发送至本地DNS服务器。具有最新的 name-to-address 转换对的本地缓存 (可能会过期)。服务器还会充当代理,将查询转发到层次结构中。
DNS域名解析
例:域名为 wagner.cse.unsw.edu.au 想要 gaia.cs.umass.edu
的IP地址。可以使用以下方法:
- 重复查询 (Iterated Query): 服务器 回复 要连接的服务器名称。如果不知道该域名,则进行询问。
- 递归查询 (Recursive Query): 给连接的服务器增加 名称解析 的任务。
DNS缓存,更新记录
- 一旦任何名称服务器学习到新的映射时,它将缓存映射。一段时间 (TTL) 之后,缓存条目 (cache entries) 会消失。TLD服务器通常缓存在本地名称服务器中 (因此,不需要经常访问根名称服务器) 。
- 后续请求无需增加DNS负担。
- 缓存条目可能已经过期 (这是尽力而为的name-to-address的转换)。如果名称主机更换了IP地址,则在所有TTL到期之前,互联网范围内可能无法知道。
- 负缓存 (Negative Caching): 记住不起作用的东西。如,拼错的网址。
DNS记录
DNS是存储资源记录 (Resource Record) 的分布式数据库。
资源记录格式: (name, value, type, ttl)
- type = A: name 是 主机名,value 是 IP 地址。
- type = NS: name 是 域名 (如 foo.com),value是该域的权威名称服务器的主机名。
- type = CNAME: name 是 规范名称 (canonial name) 的别名。value 是 规范名称。
- type = MX:value 是与 name 关联的邮件服务器的名称。
DNS 协议,消息
查询和回复消息,都具有相同的消息格式。
消息报头:
- 标识 (identification): 16位数字用于查询,并且对于该查询的回复使用相同的数字。
- 标志 (flags): 查询 / 回复。可用递归(recursion available)。
DNS插入新记录
举个例子:
一个新的创业公司 “Network Utopia” 想要添加新域名。首先,其在DNS注册商处注册名称 networkutopia.com。提供 名称,权威名称服务器的IP地址 (primary and secondary)。注册商将两个 RR 插入到 .com TLD服务器 (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1,A)
为 www.networkutopia.com 创建权威的服务器类型 A 记录。为 networkutopia.com 创建 MX 记录。
DNS更新记录
旧纪录可能会缓存在其他的DNS服务器中 (TTL)。
- 一般准则:记录当前记录的TTL值,将记录的TTL值降低到一个较低的值 (如30秒)。等待上一个TTL的长度。接着更新记录,并等待一段时间(如一个小时)。将TTL改回以前的时间。
可靠性
- DNS服务器已复制 (primary/ secondary)。如果至少有一个副本可用,则可以使用名称服务。查询可以在副本之间进行负载均衡。
- 通常,UDP用于查询。在UDP之上,我们必须实现可靠性。Spec也支持TCP,但并非始终都是被实现的。
- DNS使用端口53。
- 在超时的时候,尝试使用备用服务器。
- 所有查询的标识符相同(不在乎是哪个服务器响应了)。
间接性
- 地址可以被修改。
- 名称可以映射到多个IP地址。
- 这可以实现 负载均衡 以及 通过选择附近的服务器来减少延迟。
- 同一个地址的多个名称。(如同一台机器的许多服务,以及 别名如 www.cnn.com <-> cnn.com)
反向DNS (Reverse DNS)
IP地址->域名。
特殊的PTR记录类型,用于存储反向DNS条目。
在哪里使用反向DNS?
- 故障排查工具 (troubleshooting tools),例如traceroute和ping。
- SMTP 电子邮件中的 “已接收” 跟踪报头字段。
- SMTP 服务器,用于验证原始服务器的IP地址。
- 互联网论坛跟踪用户。
- 系统记录或监视工具。
- 用于负载均衡服务器/内容分发 (content distribution) 中以确定请求者的位置。
DNS攻击
- DDoS攻击。具有流量的Bombard根服务器。流量过滤,本地DNS服务器缓存TLD服务器的IP,从而可以绕过根服务器。
- Bombard TLD根服务器。可能更危险的重定向攻击。
- Man-in-middle。拦截查询。
- DNS中毒。将伪造的答复发送到缓存的DNS服务器。解决方案:不允许DNS服务器缓存IP地址映射,除非它们来自权威名称服务器。
- 利用DDoS的DNS。发送带有欺骗性源地址的查询:目标IP。
P2P架构
在P2P架构中,不存在永远在线的服务器。任意终端系统直接进行通讯。对等点间歇连接并更改IP地址。
当客户端上传速率为u,F/u = 1 小时 (F是一个文件大小), u_s = 10u。N是机器的数量。
比特洪流 (BitTorrent)
文件被分成多个 256KB 的块 (chunk)。洪流 (torrent) 中的 对等点 发送/接收文件块。
- tracker:跟踪在洪流中参与的对等点。
- torrent:交换文件块的 对等点 组。
对等点 加入 洪流。一开始其没有任何文件块,但随着时间的推移会从其他的 对等点 中累积 文件块。向 tracker 注册以获取 对等点 列表,连接到对等点子集 (邻点)。
当下载时,对等点 向 其他对等点 上传文件块。
对等点 会改变 与之交换文件块的邻点 (修剪:对等点可能会新增或者被删减)
一旦 对等点 拥有整个文件,它可能会(自私地)离开 或者 (以利他的方式)留在洪流中。
.torrent files
- 文件包含了tracker的地址,它可以帮我们找到其他的对等点。
- 文件包含了文件块的列表及其加密哈希 (cryptographic hashes)。这可以确保 文件块 不会被修改。
请求和发送文件块
- 请求文件块 (requesting chunks)。在任意给定时间,不同的对等点拥有不同的文件块的子集。定期地,对等点 向其他 对等点 询问它们拥有的块的列表,且向 其他对等点 请求丢失的数据块,其中最稀有的优先。
- 发送文件块 (sending chunks: tit-for-tat)。对等点 将 文件块 发送给以最高速率发送数据块的 四个对等点 (为了找到更好的交易伙伴,以便更好地获取文件)。其他的 对等点 被 当前对等点 封住 (不被从它那里获得 文件块)。每十秒重新评估前四名。每三十秒随机选择一个 对等点,并开始发送 文件块 (乐观地解封该对等点,这个新加入点可能会被加入前四名)。
分布式哈希表 (Distributed Hash Table - DHT)
DHT是一个查找数据结构,其表现像一个哈希表。DHT能用来实现一个分布式的P2P数据库。数据库拥有 (key, value) 键值对 (如,键: TFN,值: 名字。键: 文件名,值: BT trackers)。将 键值对 分布到多个对等点中。
一个对等点通过键向DHT发起查询 (DHT返回符合该键的值)。对等点也可以插入键值对。
如何将键分配到 对等点 中?
- 将每个键转化为整数。
- 将整数分配给每个 对等点。
- 将键值对放入最接近该键的 对等点 中。
使用某些n位哈希函数将整数标识符 (integer identifier) 分配给 [0, 2n-1] 范围内的每个 对等点 (如,节点ID是其IP地址的哈希)。这要求每个键必须是相同范围内的整数。
为了获得整数的键,我们可以对原先的键进行哈希运算。如: key = hash(“The boys season 2”);
规则: 将键分配给拥有 最接近ID 的 对等点。
通用约定: 最接近 指的是 键的直接后继(immediate successor)。比如,n=4,所有对等点和键标识符在 [1-15] 的范围内,对等点的ID有: 1, 3, 4, 5, 8, 10, 12, 14。则当键为 13,其直接后继对等点 是14。当键为15,则其后继对等点 是 1。
循环DHT (Circular DHT)
第一种情况:
每个对等点只知道其后继点和前继点。
每一个 对等点 维持两个邻点。在以上情况中,一共发送了六次问询信息。最坏情况下,需要发送N条消息才能找到目标,平均情况,N/2 条信息。
第二种情况(有捷径):
每一个对等点 保持追踪 前点,后点和捷径点的 IP 地址。这会让寻找目标从六条消息缩减到两条消息。合理设计捷径,会减少到 O(logN) 问询消息。
对等点流失 (peer churn)
处理对等点流失:
- 对等点可能会新增或者被删除(流失)。
- 每一个对等点 知道其 两个后继点 (successors) 的地址。
- 每一个对等点 定时地 ping 并检查其两个后继点的存活。
- 如果直接后继点离开了,选择其下一个后继点作为新的直接后继点。
如图,当 对等点4 发现 对等点5 离开了。则4会让8成为其直接后继点。同时,询问8的后继点是哪个点,之后,将8的直接后继点设置为4的第二个后继点。
视频流和CDNs
现代视频流量是互联网带宽的主要消耗。
挑战:
- 扩展性,如何到达20亿用户量。
- 异构性(heterogeneity)。不同的用户有不同的情况(如有线或者移动,高带宽或者低带宽)。
解决方案: 分布式,应用级的基础设施。
多媒体:视频
视频由一系列图片由恒定速率展示产生。图片则是由像素数组组成。
编码(coding)是使用了图片内和之间的冗余来减少用于编码图片的字节数量。
- 空间 (spatial)。图像内部。相比起发送N个相同颜色的值 (全紫色),不如仅发送两个值: 颜色值 (紫色) 和重复值的数量 (N)
- 时间 (temporal)。多图像之间。与其发送完整的 i+1 帧,不如只发送与第i帧的差异。
DASH
DASH: Dynamic, Adaptive Streaming over HTTP (通过HTTP的动态适应流)
服务器:
- 将视频文件分为多个块。
- 存储的每个块以不同的速率编码。
- 清单文件 (manifest file): 提供不同块的URL。
客户端:
- 定期测量服务器到客户端的带宽。
- 咨询清单文件 (consulting manifest),一次请求一个块。在给定当前带宽的情况下选择最大编码率。可以在不同的时间选择不同的编码率 (取决于当时的可用带宽)。
客户端可以确定:
- 什么时候请求 文件块 (这样就不会发生缓冲区不足或溢出)。
- 要求什么编码率 (在可用带宽更多时质量更高)
- 从何处请求块 (可以从 接近 客户端或者具有高可用带宽的URL服务器请求)
CDNs (Content Distribution Networks)
为了解决将流数据 (来自成千上万的视频) 传输到成千上万的同时用户 (simultaneous users)。我们不能简单地使用单个大型服务器 (meta server),因为这个解决方案扩展性不强。
我们可以将视频的多个副本存储到多个地理分布位置 (geographically distributed sites)。
- enter deep: 将CDN服务器推入许多接入网络。(距离用户近)
- bring home: 靠近接入网络 (但不在接入网络内) 的 POP 中数量较少 (10个) 的较大集群。
CDN: 将内容的副本存储到CDN节点上。
订阅者 (subscriber) 从 CDN 中请求内容。定向到附近的副本并检索内容。如果网络路径拥塞,可以选择其他的副本。
如下图,用户想要请求一个视频。视频存储在CDN上由 KingCDN.com 管理。
Netflix 案例