Transcript EE 122: Computer Networks

DNS 和 Web
1
DNS
2
命名（Naming）
• Internet有一个全局的地址: IP
– 通过显式设计
• 并且有一个全局的命名系统: DNS
– 几乎是偶然的（accident）
• 有段时间, 唯一值得命名的是主机
– 一个错误导致许多极其痛苦的绕过
• 现在所有的命名都与主机相关
– 内容是最著名的例子 (URL结构)
3
使用Internet的逻辑步骤
• 人有她希望访问的实体名
– 内容, 主机等
• 启动应用来执行相应任务
– 使用该名字
• 应用启动DNS将名字翻译成地址
• 应用启动传输协议来连接应用
– 使用地址作为目标
4
地址与（vs）名字
• 相关范围:
– 应用/用户主要关心名字
– 网络主要关心地址
• 时间维:
– 名字查询一次 (或者从cache中得到)
– 每个包都要查询地址
• 当把主机移动到另一个子网下时:
– 地址改变
– 名字不改变
• 当将内容移动到不同名字的主机时
– 名字和地址都要变化!
5
名字/地址间的关系
• 地址可在下面改变
– 将www.cnn.com移到4.125.91.21
– 人/应用不该受影响
• 名字可能映射多个IP地址
– www.cnn.com到多个重复网站
– 从而实现
o 负载平衡
o 通过找到附近的服务器减少延时
• 同一地址多个名字
– 例, 如 www.cnn.com和cnn.com这样的别名
– 记忆稳定的名字,且动态权威名字
o 权威名字 = 主机实际名字
6
从名字到地址的映射
• 最开始: 每个主机有一个文件 /etc/hosts
– SRI (Menlo Park) 保持有主拷贝
– 周期性的下载
– 平的名字空间
• 单个服务器不具有弹性, 无法扩展
– 采用分布式层次系统
• 两个纠缠在一起的层次:
– 基础设施: DNS服务器的层次
– 名字结构: www.cnn.com
7
域名系统(DNS)
• 层次结构的顶端: 根（Root）
– 位置硬连接到其他服务器
• 下一层: 顶级域名Top-level domain (TLD)服务器
– .com, .edu, etc.
– 专业管理
• 底层: 授权DNS服务器
– 事实上做映射
– 可以本地维护或者由服务提供商来做
8
分布式层次数据库
unnamed root
com
edu
org
generic domains
bar
uk
ac
zw
arpa
country domains
Top-Level Domains (TLDs)
ac
west
east
cam
foo
my
usr
my.east.bar.edu
usr.cam.ac.uk
inaddr
9
DNS根（Root）
• 位于美国的弗吉尼亚（Virginia）
• 如何使根可扩展?
Verisign, Dulles, VA
10
DNS根服务器
• 13个根服务器 (参见 http://www.root-servers.org/)
– 标记为 A 到 M
• 此能扩展吗?
A Verisign, Dulles, VA
C Cogent, Herndon, VA
D U Maryland College Park, MD
G US DoD Vienna, VA
K RIPE London
H ARL Aberdeen, MD
I Autonomica, Stockholm
J Verisign
E NASA Mt View, CA
F Internet Software
Consortium
Palo Alto, CA
M WIDE Tokyo
B USC-ISI Marina del Rey, CA
L ICANN Los Angeles, CA
11
DNS根服务器
• 13个根服务器 (参见http://www.root-servers.org/)
– 标记库A到M
• 通过any-casting复制(对地址用局部路由)
E NASA Mt View, CA
F Internet Software
Consortium,
Palo Alto, CA
(and 37 other locations)
A Verisign, Dulles, VA
C Cogent, Herndon, VA (also Los Angeles, NY, Chicago)
D U Maryland College Park, MD
G US DoD Vienna, VA
K RIPE London (plus 16 other locations)
H ARL Aberdeen, MD
I Autonomica, Stockholm
J Verisign (21 locations)
(plus 29 other locations)
M WIDE Tokyo
plus Seoul, Paris,
San Francisco
B USC-ISI Marina del Rey, CA
L ICANN Los Angeles, CA
12
层次结构有必要吗?
• 类Google的集群可以非常容易地处理 DNS负荷
• 层次的两个方面:
– 名字解析
– 名字分配
• 没有层次时，如何一起处理两者?
– 我们将在下次课，设计一个这样的系统!
13
使用DNS
• 两个组件
– 本地DNS服务器
– 解析软件在本机
• 本地DNS服务器(“缺省名字服务器”)
– 通常与使用它的端主机比较近
– 本地主机用本地服务器配置 (如/etc/resolv.conf)或者
通过DHCP学习服务器
• 客户应用
– 提取服务器名字(如, 从URL中)
– 运行gethostbyname() 来触发解析代码
14
分解是如何进行的?
在 cis.poly.edu 的
主机想要
gaia.cs.umass.edu
root DNS server
2
3
的IP地址
TLD DNS server
4
local DNS server
dns.poly.edu
5
1
8
requesting host
cis.poly.edu
7
6
authoritative DNS server
dns.cs.umass.edu
gaia.cs.umass.edu
15
递归 vs. 迭代查询
root DNS server
• 递归查询
– 问服务器要答案
– 如, 请求1而得到
响应8
• 迭代查询
2
3
4
local DNS server
– 问服务器，下一个
问谁
– 如, 所有其他请求
-响应对
TLD DNS server
dns.poly.edu
5
1
8
requesting host
7
6
authoritative DNS server
dns.cs.umass.edu
cis.poly.edu
16
DNS缓存
• 执行所有这些查询都要耗时
– 而所有这些都在实际通信发生之前
– 如, 在开始WEB下载之前1秒钟
• 缓存可极大减少延时
– 顶层服务器极少改变
– 大众网站(如, www.sina.com.cn) 会经常访问
– 本地DNS服务器通常把信息存在缓存中
• DNS缓存如何工作
– DNS服务器把对查询的响应存储在缓存中
– 响应包括 “存活时间time to live” (TTL)字段
– 服务器会在失效后删除缓存项
19
负面缓存（Caching）
• 记住无法工作的事情
– 拼写错误，如www.cnn.comm和www.cnnn.com
– 第一次，这将花费很长时间
– 记住此无法工作会比较好
– … 从而失败在下次会花费较少时间
• 但: 负面缓存是可选项
– 且未被广泛实现
20
DNS资源记录
DNS: 分布式数据库存储资源记录 (RR)
RR format: (name,
• Type=A
– name 是主机名
– value 是IP地址
• Type=NS
– name 是域名 (e.g. foo.com)
– value 是此域的授权服务器的主机名
• Type=PTR
– name 是反向IP quads
o E.g. 78.56.34.12.in-addr.arpa
– value 是对应的主机名
value, type, ttl)
• Type=CNAME
– name 是某个“正式”名字的别名
如, www.cs.mit.edu 其实是
eecsweb.mit.edu
– value 是正式名字
• Type=MX
– value 是与name相关联的域名服
务器的名字
– 也包括权重/偏好
21
DNS协议
DNS协议: 查询和响应消息,两者用同样的消息格式
消息头:
• 标识: 对于查询用16位号,
回应查询使用同样号
• 标记:
– 查询或回应
– 需要递归
– 可以递归
– 回应是权威的
• 加上表明选项头元素的大小
(0 或更多)
16 bits
16 bits
Identification
Flags
# Questions
# Answer RRs
# Authority RRs
# Additional RRs
Questions
(variable # of resource records)
Answers
(variable # of resource records)
Authority
(variable # of resource records)
Additional information
(variable # of resource records)
22
可靠性
• DNS服务器是备份的 (主/次)
– 如果至少有一个备份服务器是开的，名字服务即可用
– 查询可在备份间负载平衡
• 通常,使用UDP来查询
– 需要可靠性: 必须在UDP的顶层实现
– 规格说明也支持TCP, 但不总是实现
• 超时，试替代服务器
– 当重试同一服务器时，指数回退（backoff）
• 对所有查询具有相同标志
– 不关心哪个服务器响应
23
将资源记录插入到DNS中
• 例: 刚成立了创业公司“FooBar”
• 从ISP中得到地址空间块
– 如 212.44.9.128/25
• 找Network Solution注册如foobar.com
– 服务商用名字和IP地址注册你授权的名字服务器(主和从)
– 注册插入RR对到 com 顶级服务器:
o (foobar.com, dns1.foobar.com, NS)
o (dns1.foobar.com, 212.44.9.129, A)
• 放到你自己(授权)服务器dns1.foobar.com:
– 对www.foobar.com输入A记录
– 对foobar.com输入MX记录
24
DNS测量(MIT从2000年的数据)
• 查找了些什么?
– ~60% 请求用于A记录
– ~25% 用于PTR记录
– ~5% 用于MX记录
– ~6% 用于ANY记录
• 花多长时间?
– 中位线 ~100msec (但 90% ~500msec)
– 80%没有提交; 99.9%提交少于4次
• 每次查找时查询包数: ~2.4
– 但这有些误导….
26
DNS测量(从2000年开始的MIT数据)
• DNS给出答案吗?
– ~23%查找无法给出答案!
– ~13%查找产生NXDOMAIN (或类似的)
o 主要是反向查找
– 仅~64%的查询是成功的!
o Web怎么看起来工作很好呢?
• ~ 63% 的DNS包是未应答查询!
– 失效的查询通常会被重发
– 99.9%成功查询实际上 ≤2次重发
27
DNS测量(从2000年开始的MIT数据)
• 10%的名字被查找了~70%
– Caching确实能有帮助!
• 9%的查询是唯一的
– Cache击中率永远不会超过91%
• Cache击中率 ~ 75%
– 但缓存超过10个主机后，帮助不大
28
共同模式…..
• 各种分布式度量 (文件长度,访问模式等)通常具有
两个特性:
– 总度量的大部分在高10%
– 相当的部分(~10%)在低值区
• 非指数分布
– 大部分在高10%
– 但低值对总值很少
• 教训: 必须关注分布的两端
• 这里: 缓存有帮助,但非灵丹妙药
29
故事的寓意
• 如果设计一个高度弹性的系统,许多事情会在你未注
意到的情形下出错!
30
DNS与安全
• 没有办法验证答案
– 使DNS有多攻击的可能
– DNSSEC解决了它
• 最明显的易受攻击: 递归分解
– 使用递归分解, 主机必须信任DNS服务器
– 当在Starbucks时,服务器在其控制之下
– 并且可以返回任何它想给的值
• 更微妙的攻击: Cache poisoning
– 哪些“附加”记录可以是任何东西!
31
Cache Poisoning
• 假定你是一个Bad Guy，而你控制了foobar.com的名
字服务器.你收到一个要解析www.foobar.com的要求
，并如下回应:
;; QUESTION SECTION:
;www.foobar.com.
;; ANSWER SECTION:
www.foobar.com.
300
IN
Evidence
of the attack
A
disappears 5 seconds
later!
A
212.44.9.144
;; AUTHORITY SECTION:
foobar.com.
foobar.com.
600
600
IN
IN
NS
NS
dns1.foobar.com.
google.com.
5
IN
A
212.44.9.155
;; ADDITIONAL SECTION:
google.com.
IN
A foobar.com machine, not google.com
32
5 Minute Break
35
Entertainment….
• Anagram: What anagram of an acronym of a
coveted trade status conflicts with this
lecture?
• Puzzle: You have two candles, that each take
20 minutes to burn. How can you time 15
minutes?
– Candles do not burn evenly, so can’t mark ¾ point
– Can light either end
– No external tricks (e.g., “look at your watch”).
– Don’t look online…you’ll feel guilty for rest
36
of your life!
Answers
• Anagram: What anagram of an acronym of a
coveted trade status conflicts with this
lecture? MNF
• Puzzle: You have two candles, that each take
20 minutes to burn. How can you time 15
minutes?
– Candles do not burn evenly, so can’t mark ¾ point
– Can light either end
– No external tricks (e.g., “look at your watch”).
– Don’t look online…you’ll feel guilty for rest
of your life!
• Light candle #1 at both ends, light #2 at one37
The Web
38
The Web – 先驱
• 1967, Ted Nelson, Xanadu:
– 世界范围的出版网络的信息存储，
分离文件不可行，文献链接可行
– 文献拥有者能由于虚拟复制其文献
而通过电子方式被自动付款
• 造词“Hypertext”
– 影响了研究社群
Ted Nelson
o 他们后来错过了web…..
39
The Web – 历史
• 物理学家想要解决实际问题
– 分布式访问数据
• 万维网 (WWW): “页面pages”通过超
文本传输协议(HTTP)连接的分布式数
据库
– 首个HTTP实现 - 1990
o Tim Berners-Lee at CERN
Tim Berners-Lee
– HTTP/0.9 – 1991
o 用于WEB的简单GET
– HTTP/1.0 –1992
o 客户机/服务器信息,简单缓存（caching）
– HTTP/1.1 - 1996
40
为何不是CS研究人员发表了Web?
HTML is precisely what we were trying to PREVENT—
ever-breaking links, links going outward only, quotes
you can't follow to their origins, no version
management, no rights management.
– Ted Nelson
Academics get paid for being clever,
not for being right.
–Don Norman
41
为何如此成功?
• Web, youtube, fb 有何共性?
– 自己出版的能力
• 自己出版：容易, 独立, 免费
• 对合作和理想工作没有兴趣
– 人们通常不寻求Nirvana (或者甚至Xanadu)
– 人们通常也不寻求技术上的完美
• 只想做出他们的标记,并发现一些干净的东西
– 同一硬币的两面, 产生协同
– “性能”比交换意见更重要….
42
Web组件
• 体系架构:
– 客户机Clients
– 服务器Servers
– 代理Proxies
• 内容:
– 单个对象 (文件等)
– Web网站(条理分明的一组对象)
• 实现
– HTML: 格式化内容
– URL: 命名内容
– HTTP: 交换内容的协议
43
HTML: 超文本标记(HyperText Markup)语言
• 一个网页具有:
– 基本HTML文件
– 引用对象 (如, 图像)
• HTML 有几个功能:
– 格式化文本
– 引用图像
– 嵌入超级链接 (HREF)
44
URL语法
protocol://hostname[:port]/directorypath/resource
protocol
http, ftp, https, smtp, rtsp, etc.
hostname
域名, IP地址
port
缺省时是协议的标准端口
e.g. http: 80 https: 443
directorypath 层次的, 反应文件系统
resource
确定所需资源
也可扩展到程序执行:
http://us.f413.mail.yahoo.com/ym/ShowLetter?box=%4
0B%40Bulk&MsgId=2604_1744106_29699_1123_1261_0_289
17_3552_1289957100&Search=&Nhead=f&YY=31454&order=
down&sort=date&pos=0&view=a&head=b
45
超文本传输协议(HTTP)
•请求-响应协议
•依赖全局名字空间
•资源宏数据
• 无状态
•ASCII格式
% telnet www.icir.org 80
GET /jdoe/ HTTP/1.0
<blank line, i.e., CRLF>
46
HTTP请求的步骤
• HTTP客户端发起到服务器的TCP连接
– SYN
– SYNACK
– ACK
• 客户端发送HTTP请求到服务器
– 可能会被TCP的ACK重压
• HTTP服务器响应要求
• 客户端接收到响应, 终止连接
• TCP连接终止交换
对单个请求有多少个RTT?
47
客户机到服务器通信
• HTTP请求消息
– 请求线（line）: method, resource, 及协议版本
– 请求头: provide information or modify request
– 体: optional data (如, to “POST”数据到服务器)
request line
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
header User-agent: Mozilla/4.0
lines Connection: close
Accept-language: fr
(blank line)
Not optional
carriage return line feed
indicates end of message
48
客户机到服务器通信
• 请求methods包括:
– GET: 返回资源当前值,运行程序, …
– HEAD: 返回与某资源关联的宏数据meta-data
– POST: 更新资源, 把输入提供给程序, …
• 头包括:
– 对服务器有用的信息
o 如. 需要的语言
49
客户机到服务器通信
• HTTP响应消息
– 状态line:
协议版本, status code, status phrase
– 响应头: 提供信息
– 体: 可选数据
status line
(protocol, status code,
status phrase)
header
lines
HTTP/1.1 200 OK
Connection close
Date: Thu, 06 Aug 2006 12:00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 2006 ...
Content-Length: 6821
Content-Type: text/html
(blank line)
data
e.g., requested HTML file
data data data data data ...
50
客户机到服务器通信
• 响应码分类
– 与其他ASCII应用协议如SMTP类似
Code
Class
Example
1xx
Informational
100 Continue
2xx
Success
200 OK
3xx
Redirection
304 Not Modified
4xx
Client error
404 Not Found
5xx
Server error
503 Service Unavailable
51
服务器响应的不同形式
• 返回文件
– URL匹配一个文件 (如, /www/index.html)
– 服务器返回文件作为响应
– 服务器产生合适的响应头
• 动态产生响应
– URL在服务器端触发一个程序
– 服务器运行程序并发送输出给客户端
• 返回没有体（ body）的宏数据
52
HTTP资源宏数据（Meta-Data）
• 宏数据Meta-data
– 关于资源的信息,以分离的实体来存储
• 例:
– 资源大小, 最后修改时间, 内容类型
• 使用示例:
Conditional GET Request
– 客户端请求对象 “If-modified-since”
– 如果未修改, “HTTP/1.1 304 Not Modified”
– 服务器的响应中只有头，没有体
53
HTTP是无状态的
• 每个请求响应独立地处理
– 服务器不需要保留状态
• 优点: 改进服务器端的可扩展性
– 失效处理更容易
– 可以处理高的请求率
– 请求的顺序无影响
• 缺点: 一些应用需要持久状态
– 需要唯一确定用户或者存储临时状态
– 如, 购物车, 用户profiles, usage tracking, …
54
无状态协议中的状态:
Cookies
• 客户端状态维护
– 客户机替服务器存储少量状态
– 客户机在将来有要求时把状态发给服务器
• 可以提供认证
Request
Response
Set-Cookie: XYZ
Request
Cookie: XYZ
55
性能问题
56
HTTP性能
• 大多数网页都有多个对象
– 如, HTML文件及一堆嵌入图像
• 你怎样获取这些对象 (朴素的)?
– 一次一项
57
获取HTTP项:
Client
Start fetching
page
停止&等待
Server
Time
≥2
Finish; display
page
RTTs
per
object
58
改进HTTP性能:
并发请求和响应
•并行使用多个连接
•不必维护响应的顺序
R1
R2
T2
• Client = 
R3
T3
T1
• Server = 
• Network =  Why?
59
改进HTTP性能:
流水线请求和应答
•批量请求和应答
– 减少连接和延时
– 多个请求在单个批处理中发送
– 维护响应的次序
– 第1项总是在第2项之前到达
Client
Server
•这和并发响应/应答有什么区
别?
– 单个TCP连接
60
改进HTTP性能:
永久连接
• 允许每个连接多个传输
– 对多个请求维护TCP连接
– 包含传输子串到当前页面
– 客户机或服务器可以挂断连接
• 性能优势:
– 避免连接建立和挂断的延时
– 允许TCP学习更精确的RTT估计
– 允许TCP拥塞窗口增加
– 即, 使用之前发现的带宽
• 在HTTP/1.1中缺省的做法
61
记分卡: 请求n个小对象
时间主要受延时影响
•一次一个:
~2n RTT
•持久: ~ (n+1)RTT
•M个并发: ~2[n/m] RTT
•流水线: ~2 RTT
•流水线/持久: 首次时间~2 RTT,其后RTT
62
记分卡: 请求n个大对象
时间主要受带宽影响
•一次一个:
~ nF/B
•M个并发: ~ [n/m] F/B
– 假定和大量用户共享
•流水线 和/或 永久连接: ~ nF/B
– 唯一能帮助的就是增加带宽.
63
改进HTTP性能:
Caching
• 许多客户机发送相同的信息
– 产生多余的服务器和网络负担
– 客户端经历不必要的延时
Server
Backbone ISP
ISP-1
ISP-2
Clients
64
改进HTTP性能:
Caching: 如何实现
• 对GET请求的修改（Modifier）:
– If-modified-since –如果资源自从指定时间以来没
有修改过，返回“not modified”
• 响应头:
– Expires – 缓存资源多久是安全的
– No-cache – 忽略所有caches; 总是从服务器端直接得
到资源
65
改进HTTP性能:
Caching: 为什么
• 动机是把内容放在离客户端较近的地方:
– 用户得到更好的时间响应
– 内容提供商能让用户更高兴
o 时间就是金钱, really!
– 网络获得较少的负载
• 缓存为什么能工作?
– 利用了引用的局部性
• 缓存工作得有多好?
–
–
–
–
非常好,有一个上限
内容上大量重叠
但还有很多单独的请求
听起来有点熟悉?
66
改进HTTP性能:
Caching on the Client
例: 条件GET请求
• 仅当服务器改变时返回资源
– 保存服务器资源!
从客户机到服务器的请求:
GET /~ee122/fa07/ HTTP/1.1
Host: inst.eecs.berkeley.edu
User-Agent: Mozilla/4.03
If-Modified-Since: Sun, 27 Aug 2006 22:25:50 GMT
<CRLF>
• 怎样进行?
–
–
–
–
客户端在请求中指定 “if-modified-since”时间
服务器将此与资源的“上次修改last modified”比较
如果资源没有修改过，服务器返回“304 Not Modified”
…. 或者，否则的话返回一个带有最新版本的“200 OK”
67
改进HTTP性能:
用反向代理缓存
缓存文档离服务器近
 减少服务器负载
• 典型的由内容提供商完成
• 仅对静态内容能工作
Server
Reverse proxies
Backbone ISP
ISP-1
Clients
ISP-2
68
改进HTTP性能:
用前向代理缓存
缓存文件离客户机近
 减少网络流量和延时
• 典型的由ISP或企业局域网完成
Server
Reverse proxies
Backbone ISP
ISP-1
ISP-2
Forward proxies
Clients
69
改进HTTP性能:
用内容分布网络（CDN）缓存
• 集成前向代理和反向代理的功能
– One overlay 网络(通常)由一个实体管理
– e.g., Akamai
• 提供文档缓存
– 拉（Pull）: 引导客户请求的结果
– 推（Push）: 期望得到高可访问率
• 也做一些处理
– 处理动态网页
– 转码Transcoding
70
改进HTTP性能:
使用CDN缓存(续)
Server
CDN
Backbone ISP
ISP-1
ISP-2
Forward proxies
Clients
71
改进HTTP性能:
CDN例 – Akamai
• Akamai对每个客户内容提供商创建一个新的域名
– 如, a128.g.akamai.net
• CDN的DNS服务器对新域名负责授权
• 客户内容提供商修改其内容，以使嵌入的URL引用新
域.
– “Akamaize”内容
– 如: http://www.cnn.com/image-of-the-day.gif 变成
http://a128.g.akamai.net/image-of-the-day.gif
• 现在请求发往CDN组织架构…
72
Hosting: 每台机器多个站点
• 单台机器上有多个网站
– 主机（Hosting）公司为多个站点运行网页服务器 (如,
www.foo.com 和 www.bar.com)
• 问题: GET /index.html
– www.foo.com/index.html 或 www.bar.com/index.html?
• 解决方案:
– 在同一机器上有多个服务器进程
o 对每个服务器有一个独立的IP地址(或端口)
– 在HTTP请求中包含站点名
o 每个网页服务器进程有一个IP地址
o 客户端包含“主机Host”头(如, Host: www.foo.com)
o 对HTTP/1.1所需要的头
73
Hosting: 每个站点多台机器
• 在多台机器上复制流行站点
– 帮助处理负载
– 使内容离客户更近
• 当内容无法缓存时会有帮助
• 问题: 希望把客户导向到一个专门的复制
– 通过服务器复制来实现负载平衡
– 将客户与附近的服务器匹配
74
单个位置Multi-Hosting
• 单个IP地址, 多台主机
– 在单个IP地址后运行多台机器
Load Balancer
64.236.16.20
– 确保从单个TCP连接的所有包到达相同的备份机
75
在几个地方的Multi-Hosting
• 多地址, 多机器
– 对所有的备份机有相同名字但不同的地址
– 配置DNS服务器返回不同的地址
12.1.1.1
64.236.16.20
Internet
173.72.54.131
76