计算机网络理论笔记 (2-2): 应用层 (Application Layer)，DNS 和 P2P

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 案例