计算机网络：应用层
目录
2.1 应用层原理
一、网络应用的体系结构
二、客户—服务器（C/S）体系结构
三、对等体（P2P）体系结构
四、C/S和P2P体系结构的混合体
五、进程通信
六、分布式进程通信需要解决的问题
七、问题1：对进程进行编址（ addressing ）
八、问题2：传输层提供的服务 - 需要穿过层间的信息
九、套接字（ socket ）
十、应用层协议
十一、应用需要传输层提供的服务
十二、Internet 传输层提供的服务
十三、UDP存在的必要性
十四、安全TCP
2.2 Web and HTTP
一、Web 与 HTTP
二、HTTP 概况
三、HTTP 连接
四、响应时间模型
五、 HTTP 请求报文
六、提交表单输入
七、方法类型
八、 HTTP 响应报文
九、 HTTP 响应状态码
十一、Web 缓存 ( 代理服务器 )
十二、条件 GET 方法
2.3 FTP
一、FTP: 文件传输协议
二、FTP: 控制连接与数据连接分开
三、FTP 命令、响应
2.4 EMail
一、电子邮件（ EMail ）
二、 EMail: 邮件服务器
三、EMail: SMTP
四、举例：Alice 给 Bob 发送报文
五、 简单的 SMTP 交互
六、SMTP ：总结
七、邮件报文格式
八、 报文格式：多媒体扩展
九、邮件访问协议
十、POP3 协议
2.5 DNS
一、DNS 系统需要解决的问题
二、DNS(Domain Name System) 的历史
三、DNS(Domain Name System) 总体思路和目标
四、问题 1 ： DNS 名字空间 (The DNS Name Space)
五、 问题 2 ：解析问题 - 名字服务器 (Name Server)
六、名字空间划分为若干区域： Zone
七、TLD 服务器
八、区域名字服务器维护资源记录
九、DNS 记录
十、DNS 大致工作过程
十一、本地名字服务器（ Local Name Server ）
十二、名字服务器 (Name Server)
十三、DNS 协议、报文
十四、提高性能：缓存
十五、问题 3 ：维护问题：新增一个域
2.6 P2P应用
一、纯P2P架构
二、文件分发: C/S vs P2P
三、Client-server vs. P2P: 例子
四、P2P文件分发： BitTorrent
五、BitTorrent: 请求，发送文件块
六、BitTorrent: tit-for-tat
七、P2P 文件共享
八、P2P ：集中式目录
九、查询洪泛： Gnutella
十、利用不匀称性： KaZaA
十一、Distributed Hash Table (DHT)
2.7 CDN
一、视频流化服务和CDN：上下文
二、存储视频的流化服务
三、多媒体流化服务：DASH
四、Content Distribution Networks (CDNs)
目标
网络应用的原理：网络应用协议的概念和实现方面
- 传输层的服务模型
- 客户—服务器模式
- 对等模式（peer-to-peer）
- 内容分发网络
网络应用的实例：互联网流行的应用层协议
- HTTP
- FTP
- SMTP / POP3 / IMAP
- DNS
编程：网络应用程序
- Socket API（原语，传输层向应用层提供的服务）
2.1 应用层原理
一、网络应用的体系结构
可能的应用架构：
- 客户-服务器模式（C/S：client/server）
- 对等模式（P2P：Peer To Peer）
- 混合体：客户—服务器和对等体系结构
二、客户—服务器（C/S）体系结构
1、服务器：
- 一直运行
- 固定的IP地址和周知的端口号（约定）
- 扩展性：服务器场
- 数据中心进行扩展
- 扩展性差
2、客户端：
- 主动与服务器通信
- 与互联网有间歇性的连接
- 可能是动态IP地址
- 不直接与其它客户端通信
三、对等体（P2P）体系结构
1、（几乎）没有一直运行的服务器
2、任意端系统之间可以进行通信
3、每一个节点既是客户端又是服务器
- 自扩展性—新peer节点带来新的服务能力，当然也带来新的服务请求
4、参与主机间歇性连接且可以改变IP地址
- 难以管理
5、例子：Gnutella ，迅雷（例：你想下载一个photoshop，它存在于远程服务器上，但是访问服务器的人很多，导致速度很慢，从而影响你的下载速度。可是刚好我前两天下载过这个资源，采用P2P加速后，你就不但可以从服务器上下载，还可以从我这里下载，如果有很多人都下载过这个资源，那么速度就会越快。）
四、C/S和P2P体系结构的混合体
1、Napster
- 文件搜索：集中CS
- 主机在中心服务器上注册其资源
- 主机向中心服务器查询资源位置
- 文件传输：P2P
- 任意Peer节点之间
2、即时通信
- 在线检测：集中CS
- 当用户上线时，向中心服务器注册其IP地址
- 用户与中心服务器联系，以找到其在线好友的位置
- 两个用户之间聊天：P2P
五、进程通信
1、进程：在主机运行的应用程序
- 客户端进程：发起通信的进程
- 服务器进程：等待连接的进程
2、在同一主机内，使用进程间通信机制通信（操作系统定义）
3、不同主机，通过交换报文（Message）来通信
- 使用OS提供的通信服务
- 按照应用协议交换报文
- 借助传输层提供的服务
- 注意：P2P架构的应用也有客户端和服务器进程之分
六、分布式进程通信需要解决的问题
1、问题1：进程表示和寻址问题（服务用户）
2、问题2：传输层 - 应用层提供服务是如何（服务）
- 位置：层间界面的 SAP （ TCP/IP ： socket ）
- 形式：应用程序接口 API （ TCP/IP ： socket API ）
3、问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
- 定义应用层协议：报文格式，解释，时序等
- 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等；
七、问题1：对进程进行编址（ addressing ）
1、进程为了接收报文，必须有一个标识，即：SAP（发送也需要标示）
- 主机：唯一的32位IP地址
- 仅仅有IP地址不能够唯一标示一个进程；一台端系统上有很多应用进程在运行
- 所采用的传输层协议：TCP or UDP
- 端口号（Port）
2、一些知名端口号的例子：
- HTTP: TCP 80 Mail: TCP 25 ftp:TCP 2
3、一个进程：用IP+port标示 端节点
4、本质上，一对主机进程之间的通信由两个端节点构成
八、问题2：传输层提供的服务 - 需要穿过层间的信息
1、层间接口必须要携带的信息
- 要传输的报文（对于本层来说： SDU ）
- 谁传的：对方的应用进程的标示： IP+TCP(UDP) 端口
- 传给谁：对方的应用进程的标示：对方的 IP+TCP(UDP) 端口号
2、传输层实体（ tcp 或者 udp 实体）根据这些信息进行 TCP报文段（ UDP 数据报）的封装
- 源端口号，目标端口号，数据等
- 将 IP 地址往下交 IP 实体，用于封装 IP 数据报：源 IP, 目标 IP
3、如果 Socket API 每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理
4、用个代号标示通信的双方或者单方： socket
5、就像 OS 打开文件返回的句柄一样
- 对句柄的操作，就是对文件的操作
6、TCP socket ：
- TCP 服务，两个进程之间的通信需要之前要建立连接
- 两个进程通信会持续一段时间，通信关系稳定
- 可以用一个整数表示两个应用实体之间的通信关系，本地标示
- 穿过层间接口的信息量最小
- TCP socket ：源 IP， 源端口，目标 IP ， 目标端口
7、UDP socket ：
- UDP 服务，两个进程之间的通信需要之前无需建立连接
- 每个报文都是独立传输的
- 前后报文可能给不同的分布式进程
- 因此，只能用一个整数表示本应用实体的标示
- 因为这个报文可能传给另外一个分布式进程
- 穿过层间接口的信息大小最小
- UDP socket ：本 IP, 本端口
- 但是传输 报文时：必须要提供对方 IP ， port
- 接收报文时： 传输层需要上传对方的 IP ， port
8、总结：
套接字在传输的时候
TCP交两样：socket和数据本身
UDP交三样：socket、数据本身、目的地（因为UDP的socket里没有目的IP和端口号）
九、套接字（ socket ）
1、TCP 之上的套接字（ socket ）
对于使用面向连接服务（ TCP ）的应用而言，套接字是 4 元组的一个具有本地意义的标示
- 4 元组： ( 源 IP ，源 port ，目标 IP ，目标 port)
- 唯一的指定了一个会话（ 2 个进程之间的会话关系）
- 应用使用这个标示，与远程的应用进程通信
- 不必在每一个报文的发送都要指定这 4 元组（发socket这个整数，类似于指针）
- 就像使用操作系统打开一个文件， OS 返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名（指针）
- 简单，便于管理
2、UDP 之上的套接字（ socket ）
对于使用无连接服务（ UDP ）的应用而言，套接字是 2 元组的一个具有本地意义的标示
- 2 元组： IP ，port （源端指定）
- UDP 套接字指定了应用所在的一个端节点（ end point ）
- 在发送数据报时，采用创建好的本地套接字（标示ID），就不必在发送每个报文中指明自己所采用的ip和 port（每一个包的目标可以不同，所以socket不包括目的地）
- 但是在发送报文时，必须要指定对方的 ip 和 udp port(另外一个段节点）
3、进程向套接字发送报文或从套接字接收报文
4、套接字 <-> 门户
- 发送进程将报文 推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
- 接收进程从另外一端的门户收到报文（依赖于传输层设施）
十、应用层协议
1、定义了：运行在不同端系统上的应用进程如何相互交换报文
- 交换的报文类型：请求和应答报文
- 各种报文类型的语法：报文中的各个字段及其描述
- 字段的语义：即字段取值的含义
- 进程何时、如何发送报文及对报文进行响应的规则
2、应用协议仅仅是应用的一个组成部分
- Web 应用： HTTP 协议， web 客户端， web 服务器， HTML
3、公开协议
- 由 RFC 文档定义
- 允许互操作
- 如 HTTP, SMTP
4、专用（私有）协议
- 协议不公开
- 如：Skype
十一、应用需要传输层提供的服务
1、数据丢失率
- 有些应用则要求 100% 的可靠数据传输（如文件）
- 有些应用（如音频）能容忍一定比例以下的数据丢失
2、延迟
- 一些应用出于有效性考虑，对数据传输有严格的时间限制
- Internet 电话、交互式游戏
- 延迟、延迟差
3、吞吐
- 一些应用（如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转
- 一些应用能充分利用可供使用的吞吐 ( 弹性应用 ）
4、安全性
- 机密性
- 完整性
- 可认证性（鉴别）
十二、Internet 传输层提供的服务
1、TCP服务
- 可靠的传输服务
- 流量控制：发送方不会淹没接受方
- 拥塞控制：当网络出现拥塞时，能抑制发送方
- 不能提供的服务：时间保证、最小吞吐保证和安全
- 面向连接：要求在客户端进程和服务器进程之间建立连接
2、UDP服务
- 不可靠数据传输
- 不提供的服务：可靠，流量控制、拥塞控制、时间、带宽保证、建立连接
十三、UDP存在的必要性
- 能够区分不同的进程，而 IP 服务不能
- 在 IP 提供的主机到主机端到端功能的基础上，区分了主机的应用进程
- 无需建立连接，省去了建立连接时间，适合事务性的应用
- 不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用
- 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发）
- 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
- 而在 TCP 上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制
十四、安全TCP
1、 TCP & UDP
- 都没有加密
- 明文通过互联网传输，甚至密码
2、SSL
- 在 TCP 上面实现，提供加密的 TCP 连接
- 私密性
- 数据完整性
- 端到端的鉴别
3、SSL 在应用层
- 应用采用 SSL 库， SSL库使用 TCP 通信
4、SSL socket API
- 应用通过 API 将明文交给 socket ， SSL 将其加密在互联网上传输
- 详见第 8 章
2.2 Web and HTTP
一、Web 与 HTTP
一些术语
- Web 页：由一些对象组成
- 对象可以是 HTML 文件、 JPEG 图像、 Java 小程序、声音剪辑文件等
- Web 页含有一个基本的 HTML 文件，该基本 HTML 文件又包含若干对象的引用（链接）
- 通过 URL 对每个对象进行引用
- 访问协议，用户名，口令字，端口等；
- URL 格式
- Prot://user:[email protected]/someDept/pic.gif:port
- 协议名 用户:口令 主机名 路径名 端口
二、HTTP 概况
1、HTTP: 超文本传输协议
- Web 的应用层协议
- 客户 / 服务器模式
- 客户 : 请求、接收和显示Web 对象的浏览器
- 服务器 : 对请求进行响应，发送对象的 Web 服务器
- HTTP 1.0: RFC 1945
- HTTP 1.1: RFC 2068
2、使用 TCP:
- 客户发起一个与服务器的TCP 连接 ( 建立套接字 ) ，端口号为 80
- 服务器接受客户的 TCP 连接
- 在浏览器 (HTTP 客户端 )与 Web 服务器 (HTTP 服务器 server) 交换 HTTP报文 ( 应用层协议报文 )
- TCP 连接关闭
3、HTTP 是无状态的
- 服务器并不维护关于客户的任何信息
三、HTTP 连接
1、非持久 HTTP
- 最多只有一个对象在TCP 连接上发送
- 下载多个对象需要多个 TCP 连接
- HTTP/1.0 使用非持久连接
①假设用户输入 URL（包含文本和 10 个jpeg图像的引用）
www.someSchool.edu/someDept/home.index
②非持久 HTTP 的缺点：
- 每个对象要 2 个 RTT
- 操作系统必须为每个 TCP 连接分配资源
- 但浏览器通常打开并行 TCP 连接，以获取引用对象
2、持久 HTTP
- 多个对象可以在一个（在客户端和服务器之间的） TCP 连接上传输
- HTTP/1.1 默认使用持久连接
- 服务器在发送响应后，仍保持TCP 连接
- 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
- 客户端在遇到一个引用对象的时候，就可以尽快发送该对象的请求
① 非流水方式的持久 HTTP ：
- 客户端只能在收到前一个响应后才能发出新的请求
- 每个引用对象花费一个 RTT
②流水方式的持久 HTTP ：
- HTTP/1.1 的默认模式
- 客户端遇到一个引用对象就立即产生一个请求
- 所有引用（小）对象只花费一个RTT 是可能的
四、响应时间模型
1、往返时间 RTT （ round-triptime ）：一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略）
2、响应时间：
- 一个 RTT 用来发起 TCP 连接
- 一个 RTT 用来 HTTP 请求并等待 HTTP 响应
- 文件传输时间
共：2RTT+ 传输时间
五、 HTTP 请求报文
- 两种类型的 HTTP 报文：请求、响应
- HTTP 请求报文 :
- ASCII (人能阅读）
1、 通用格式
六、提交表单输入
1、Post 方式：
- 网页通常包括表单输入
- 包含在实体主体(entity body ) 中的输入被提交到服务器
2、URL 方式：
- 方法： GET
- 输入通过请求行的URL 字段上载
- http://www.baidu.com/s?wd=xx+yy+zzz&cl=3
参数： wd ， cl
参数值： XX+YY+zzz ， 3
七、方法类型
1、HTTP/1.0
- GET
- POST
- HEAD
- 要求服务器在响应报文中不包含请求对象—>故障跟踪
2、HTTP/1.1
- GET, POST, HEAD
- PUT
- 将实体主体中的文件上载到 URL 字段规定的路径
- DELETE
- 删除 URL 字段规定的文件
八、 HTTP 响应报文
两个15k从http->tcp->tcp->http一个30k，所有tcp应用进程自己维护报文之间的界限
九、 HTTP 响应状态码
位于服务器 —> 客户端的响应报文中的首行
一些状态码的例子：
200 OK
- 请求成功，请求对象包含在响应报文的后续部分
301 Moved Permanently
- 请求的对象已经被永久转移了；新的 URL 在响应报文的 Location:
首部行中指定
- 客户端软件自动用新的 URL 去获取对象
400 Bad Request
- 一个通用的差错代码，表示该请求不能被服务器解读
404 Not Found
- 请求的文档在该服务上没有找到
505 HTTP Version Not Supported
十、用户 - 服务器状态： cookies
大多数主要的门户网站使用 cookies
1、4 个组成部分：
1) 在 HTTP 响应报文中有一个 cookie 的首部行
2) 在 HTTP 请求报文含有一个 cookie 的首部行
3) 在用户端系统中保留有一个 cookie 文件，由用户的浏览器管理
4) 在 Web 站点有一个后端数据库
2、例子：
- Susan 总是用同一个 PC 使用 Internet Explore 上网
- 她第一次访问了一个使用了 Cookie 的电子商务网站
- 当最初的 HTTP 请求到达服务器时，该 Web 站点产生一个唯一的 ID ，并以此作为索引在它的后端数据库中产生一个项
3、如何维持状态：
- 协议端节点：在多个事务上，发送端和接收端维持状态
- cookies: http报文携带状态信息
十一、Web 缓存 ( 代理服务器 )
1、目标： 不访问 原始服务器，就满足客户的请求
- 用户设置浏览器： 通过缓存访问 Web
- 浏览器将所有的 HTTP请求发给缓存
- 在缓存中的对象：缓存直接返回对象
- 如对象不在缓存，缓存请求原始服务器，然后再将对象返回给客户端
2、为什么要使用 Web 缓存？
- 降低客户端的请求响应时间
- 可以大大减少一个机构内部网络与 Internent 接入链路上的流量
- 互联网大量采用了缓存：可以使较弱的 ICP 也能够有效提供内容
①缓存示例1
假设
- 平均对象大小 = 100kb
- 机构内浏览器对原始服务器的平均请求率为 = 15 个 /s
- 平均到浏览器的速率： 1.5Mbps
- 机构内部路由器到原始服务器再返回到路由器的的延时 （Internet 延时） = 2s
- 接入链路带宽： 1.54Mbps
结果
- LAN 的流量强度 = 15%
- 接入链路上的流量强度 = 99%（排队延时过大）
- 总延时 = LAN 延时 + 接入延时 +Internet 延时= ms + 分 + 2s
②缓存示例2：更快的接入链路
假设如上
- 接入链路带宽： 154Mbps
结果
- 接入链路上的流量强度 = 9.9%
- 总延时 = LAN 延时 + 接入延时 +Internet 延时= ms +ms + 2s
代价: 增加了接入链路带宽（非常昂贵）
③缓存例子3：安装本地缓存
计算链路利用率，有缓存的延迟：
- 假设缓存命中率0.4
- 40%请求在缓存中被满足，其他60%的请求需要被原始服务器满足
- 接入链路利用率:
- 60%的请求采用接入链路
- 进过接入链路到达浏览器的数据速率 = 0.6*1.50 Mbps = 0.9 Mbps
- 利用率= 0.9/1.54 = 0.58
- 总体延迟：
- = 0.6 * (从原始服务器获取对象的延迟) +0.4 * (从缓存获取对象的延迟)
- = 0.6 (2s) + 0.4 (~msecs)= ~ 1.2 secs
- 比安装154Mbps链路还来得小 (而且比较便宜!)
十二、条件 GET 方法
- 目标：如果缓存器中的对象拷贝是最新的，就不要发送对象
- 缓存器 : 在 HTTP 请求中指定缓存拷贝的日期If-modified-since:
- 服务器 : 如果缓存拷贝陈旧，则响应报文没包含对象 :HTTP/1.0 304 Not Modified
2.3 FTP
一、FTP: 文件传输协议
- 向远程主机上传输文件或从远程主机接收文件
- 客户 / 服务器模式
- 客户端：发起传输的一方
- 服务器：远程主机
- ftp: RFC 959
- ftp 服务器：端口号为 21
二、FTP: 控制连接与数据连接分开
- FTP 客户端与 FTP 服务器通过端口 21 联系，并使用 TCP 为传输协议
- 客户端通过控制连接获得身份确认
- 客户端通过控制连接发送命令，浏览远程目录
- 收到一个文件传输命令时，服务器打开一个到客户端的数据连接
- 一个文件传输完成后，服务器关闭连接
- 服务器打开第二个 TCP 数据连接用来传输另一个文件
- 控制连接： 带外（ “out of band”）传送，整个会话期间一直保持打开
- FTP 服务器维护用户的状态信息：当前路径、用户帐户与控制连接对应
- 有状态
三、FTP 命令、响应
1、命令样例：
- 在控制连接上以 ASCII 文本方式传送
- USER username
- PASS password
- LIST ：请服务器返回远程主机当前目录的文件列表
- RETR filename ：从远程主机的当前目录检索文件(gets)
- STOR filename ：向远程主机的当前目录存放文件(puts)
2、返回码样例：
- 状态码和状态信息 ( 同 HTTP)
- 331 Username OK,password required
- 125 data connection already open;transfer starting
- 425 Can ’ t open data connection
- 452 Error writing file
2.4 EMail
一、电子邮件（ EMail ）
1、3 个主要组成部分：
- 用户代理
- 邮件服务器
- 简单邮件传输协议： SMTP
2、用户代理
- 又名 “邮件阅读器”
- 撰写、编辑和阅读邮件
- 如 Outlook 、 Foxmail、QQ邮箱
- 输出和输入邮件保存在服务器上
二、 EMail: 邮件服务器
1、邮件服务器
- 邮箱中管理和维护发送给用户的邮件
- 输出报文队列保持待发送邮件报文
- 邮件服务器之间的 SMTP 协议：发送 email 报文
- 客户：发送方邮件服务器
- 服务器：接收端邮件服务器
三、EMail: SMTP
- 使用 TCP 在客户端和服务器之间传送报文，端口号为 25
- 直接传输：从发送方服务器到接收方服务器
- 传输的 3 个阶段
- 握手
- 传输报文
- 关闭
- 命令 / 响应交互
- 命令： ASCII 文本
- 响应：状态码和状态信息
- 报文必须为 7 位 ASCII 码
四、举例：Alice 给 Bob 发送报文
1) Alice 使用用户代理撰写邮件并发送给[email protected]
2) Alice 的用户代理将邮件发送到她的邮件服务器；邮件放在报文队列中
3) SMTP 的客户端打开到 Bob 邮件服务器的 TCP 连接
4) SMTP 客户端通过 TCP 连接发送 Alice 的邮件
5) Bob 的邮件服务器将邮件放到Bob 的邮箱
6) Bob 调用他的用户代理阅读邮件
五、 简单的 SMTP 交互
六、SMTP ：总结
- SMTP 使用持久连接
- SMTP 要求报文（首部和主体）为 7 位 ASCII 编码
- SMTP 服务器使用CRLF.CRLF 决定报文的尾部
1、HTTP 比较：
- HTTP ：拉（ pull ）
- SMTP ：推（ push ）
- 二者都是 ASCII 形式的命令 /响应交互、状态码
- HTTP ：每个对象封装在各自的响应报文中
- SMTP ：多个对象包含在一个报文中（一个邮件里包含多个图片和文本）
七、邮件报文格式
SMTP ：交换 email 报文的协议
RFC 822: 文本报文的标准：
- 首部行：如 ,
- To:
- From:
- Subject:与 SMTP 命令不同 ！
- 主体
- 报文，只能是 ASCII 码字符
八、 报文格式：多媒体扩展
- MIME ：多媒体邮件扩展（ multimedia mail extension ）,RFC 2045, 2056
- 在报文首部用额外的行申明 MIME 内容类型
九、邮件访问协议
- SMTP: 传送到接收方的邮件服务器
- 邮件访问协议：从服务器访问邮件
- POP3 ：邮局访问协议（ Post Office Protocol ）(本地管理文件夹)
- 用户身份确认 ( 代理 <--> 服务器 ) 并下载
- 先前的例子使用 “下载并删除”模式。
- 如果改变客户机， Bob 不能阅读邮件
- “下载并保留”：不同客户机上为报文的拷贝
- POP3 在会话中是无状态的
- IMAP ： Internet 邮件访问协议（ Internet Mail Access Protocol ）(远程管理文件夹)
- 更多特性 ( 更复杂 )
- 在服务器上处理存储的报文
- 有状态，远程目录文件夹维护
- 客户端与邮箱同步更新
- IMAP 服务器将每个报文与一个文件夹联系起来
- 允许用户用目录来组织报文
- 允许用户读取报文组件
- IMAP 在会话过程中保留用户状态：
- 目录名、报文 ID 与目录名之间映射
- HTTP ： Hotmail , Yahoo! Mail 等
- 方便
- POP3 ：邮局访问协议（ Post Office Protocol ）(本地管理文件夹)
十、POP3 协议
1、用户确认阶段
- 客户端命令：
- user: 申明用户名
- pass: 口令
- 服务器响应
- +OK
- -ERR
2、事物处理阶段 , 客户端：
- list: 报文号列表
- retr: 根据报文号检索报文
- dele: 删除
- quit
2.5 DNS
- DNS 的必要性
- IP 地址标识主机、路由器
- 但 IP 地址不好记忆，不便人类使用 ( 没有意义 )
- 人类一般倾向于使用一些有意义的字符串来标识Internet 上的设备 例如[email protected] 所在的邮件服务器www.ustc.edu.cn 所在的 web 服务器
- 存在着“字符串” —IP 地址的转换的必要性
- 人类用户提供要访问机器的“字符串”名称
- 由 DNS 负责转换成为二进制的网络地址
一、DNS 系统需要解决的问题
- 问题 1 ：如何命名设备
- 用有意义的字符串：好记，便于人类用使用
- 解决一个平面命名的重名问题：层次化命名
- 问题 2 ：如何完成名字到 IP 地址的转换
- 分布式的数据库维护和响应名字查询
- 问题 3 ：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作
二、DNS(Domain Name System) 的历史
- ARPANET 的名字解析解决方案
- 主机名：没有层次的一个字符串（一个平面）
- 存在着 一个（集中）维护站：维护着一张 主机名 -IP 地址的映射文件： Hosts.txt
- 每台主机定时从维护站取文件
- ARPANET 解决方案的问题
- 当网络中主机数量很大时
- 没有层次的主机名称很难分配
- 文件的管理、发布、查找都很麻烦
- 当网络中主机数量很大时
三、DNS(Domain Name System) 总体思路和目标
- DNS 的主要思路
- 分层的、基于域的命名机制
- 若干分布式的数据库完成名字到 IP 地址的转换
- 运行在 UDP 之上端口号为 53 的应用服务
- 核心的 Internet 功能，但以应用层协议实现
- 在网络边缘处理复杂性
- DNS 主要目的：
- 实现主机名 -IP 地址的转换 (name/IP translate)
- 其它目的
- 主机别名到规范名字的转换： Host aliasing
- 邮件服务器别名到邮件服务器的正规名字的转换： Mail server aliasing
- 负载均衡： Load Distribution
四、问题 1 ： DNS 名字空间 (The DNS Name Space)
- DNS 域名结构
- 一个层面命名设备会有很多重名
- NDS 采用层次树状结构的 命名方法
- Internet 根被划为几百个顶级域 (top lever domains)
- 通用的 (generic) .com; .edu ; .gov ; .int ; .mil ; .net ; .org; .firm ; .hsop ; .web ; .arts ; .rec ;
- 国家的 (countries) .cn ; .us ; .nl ; .jp
- 每个 ( 子 ) 域下面可划分为若干子域 (subdomains)
- 树叶是主机
- DNS：根名字服务器
- 域名 (Domain Name)
- 从本域往上，直到树根
- 中间使用“ . ”间隔不同的级别
- 例如： ustc.edu.cn
- auto.ustc.edu.cn
- www.auto. ustc.edu.cn
- 域的域名：可以用于表示一个域
- 主机的域名：一个域上的一个主机
- 域名的管理
- 一个域管理其下的子域 .jp 被划分为 ac.jp co.jp .cn 被划分为 edu.cn com.cn
- 创建一个新的域，必须征得它所属域的同意
- 域与物理网络无关
- 域遵从组织界限，而不是物理网络
- 一个域的主机可以不在一个网络
- 一个网络的主机不一定在一个域
- 域的划分是逻辑的，而不是物理的
- 域遵从组织界限，而不是物理网络
五、 问题 2 ：解析问题 - 名字服务器 (Name Server)
- 一个名字服务器的问题
- 可靠性问题：单点故障
- 扩展性问题：通信容量
- 维护问题：远距离的集中式数据库
- 区域 (zone)
- 区域的划分有区域管理者自己决定
- 将 DNS 名字空间划分为互不相交的区域，每个区域都是树的一部分
- 名字服务器：
- 每个区域都有一个名字服务器：维护着它所管辖区域的权威信息(authoritative record)
- 名字服务器允许被放置在区域之外，以保障可靠性
六、名字空间划分为若干区域： Zone
权威 DNS 服务器：组织机构的 DNS 服务器， 提供组织机构服务器（如
Web 和 mail ）可访问的主机和 IP 之间的映射
组织机构可以选择实现自己维护或由某个服务提供商来维护
七、TLD 服务器
- 顶级域 (TLD) 服务器：负责顶级域名（如 com, org, net,edu 和 gov ）和所有国家级的顶级域名（如 cn, uk, fr, ca,jp ）
- Network solutions 公司维护 com TLD 服务器
- Educause 公司维护 edu TLD 服务器
八、区域名字服务器维护资源记录
- 资源记录 (resource records)
- 作用：维护 域名 -IP 地址 ( 其它 ) 的映射关系
- 位置： Name Server 的分布式数据库中
- RR 格式 : ( domain_name, ttl, type,class,Value)
- Domain_name: 域名
- Ttl: time to live : 生存时间 ( 权威，缓冲记录 )
- Class 类别 ：对于 Internet ，值为 IN
- Value 值：可以是数字，域名或 ASCII 串
- Type 类别：资源记录的类型 — 见如下
九、DNS 记录
DNS ：保存资源记录 (RR) 的分布式数据库
RR 格式： (name, value, type, ttl)
- Type=A
- Name 为主机
- Value 为 IP 地址
- Type=CNAME
- Name 为规范名字的别名 www.ibm.com 的规范名字为 servereast.backup2.ibm.com
- value 为规范名字
- Type=MX
- Value 为 name 对应的邮件服务器的名字
- Type=NS
- Name 域名 ( 如 foo.com)
- Value 为该域名的权威服务器的域名
TTL ：生存时间，决定了资源记录应当从缓存中删除的时间
例子：
十、DNS 大致工作过程
- 应用调用 解析器 (resolver)
- 解析器作为客户 向 Name Server 发出查询报文（封装在 UDP 段中）
- Name Server 返回响应报文 (name/ip)
十一、本地名字服务器（ Local Name Server ）
- 并不严格属于层次结构
- 每个 ISP ( 居民区的 ISP 、公司、大学）都有一个本地 DNS 服务器
- 也称为“默认名字服务器”
- 当一个主机发起一个 DNS 查询时，查询被送到其本地 DNS 服务器
- 起着代理的作用，将查询转发到层次结构中
十二、名字服务器 (Name Server)
- 名字解析过程
- 目标名字在 Local Name Server 中
- 情况 1 ：查询的名字在该区域内部
- 情况 2 ：缓存 (cashing)
当与本地名字服务器不能解析名字时，联系根名字服务器，顺着根 -TLD 一直找到权威名
字服务器。
1、递归查询
- 名字解析负担都放在当前联络的名字服务器上
- 问题：根服务器的负担太重
- 解决： 迭代查询(iterated queries)
2、迭代查询
主机 cis.poly.edu 想知道主机 gaia.cs.umass.edu的 IP 地址
- 根（及各级域名）服务器返回的不是查询结果，而是下一个 NS 的地址（类似指针）
- 最后由权威名字服务器给出解析结果
- 当前联络的服务器给出可以联系的服务器的名字
- “我不知道这个名字，但可以向这个服务器请求”（我办不了，但是我可以甩锅hh）
十三、DNS 协议、报文
DNS 协议：查询和响应报文的报文格式相同
报文首部
- 标识符（ ID ）：16 位
- flags:
- 查询 / 应答
- 希望递归
- 递归可用
- 应答为权威
十四、提高性能：缓存
- 一旦名字服务器学到了一个映射，就将该映射缓存起来
- 根服务器通常都在本地服务器中缓存着
- 使得根服务器不用经常被访问
- 目的：提高效率
- 可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致
- 解决方案： TTL （默认 2 天）
十五、问题 3 ：维护问题：新增一个域
- 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
- 在新增子域 的名字服务器上运行名字服务器，负责本域的名字解析： 名字 ->IP 地址 例子：在 com 域中建立一个“ Network Utopia ”
- 到注册登记机构注册域名 networkutopia.com
- 需要向该机构提供权威 DNS 服务器（基本的、和辅助的）的名字和 IP 地址
- 登记机构在 com TLD 服务器中插入两条 RR 记录 : (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A)
- 在 networkutopia.com 的权威服务器中确保有
- 用于 Web 服务器的 www.networkuptopia.com 的类型为 A 的记录
- 用于邮件服务器 mail.networkutopia.com 的类型为 MX 的记录
2.6 P2P应用
一、纯P2P架构
- 没有（或极少）一直运行的服务器
- 任意端系统都可以直接通信
- 利用peer的服务能力
- Peer节点间歇上网，每次IP地址都有可能变化
例子:
- 文件分发 (BitTorrent)
- 流媒体(KanKan)
- VoIP (Skype)
二、文件分发: C/S vs P2P
问题: 从一台服务器分发文件（大小F）到N个peer需要多少时间？
- Peer节点上下载能力是有限的资源
1、文件分发时间: C/S模式
- 服务器传输： 都是由服务器发送给peer，服务器必须顺序传输（上载）N个文件拷贝 :
- 发送一个copy: F/us
- 发送N个copy： NF/us（服务器很少，客户端很多）
- 客户端: 每个客户端必须下载一个文件拷贝
- dmin = 客户端最小的下载速率
- 下载带宽最小的客户端下载的时间：F/dmin（服务器足够多）
2、文件分发时间: P2P模式
- 服务器传输： 最少需要上载一份拷贝
- 发送一个拷贝的时间： F/us
- 客户端: 每个客户端必须下载一个拷贝
- 最小下载带宽客户单耗时：F/d min
- 客户端: 所有客户端总体下载量NF
- 最大上载带宽是：us + ui（服务器上载带宽+所有客户端上载带宽）
- 除了服务器可以上载，其他所有的peer节点都可以上载
三、Client-server vs. P2P: 例子
客户端上载速率 = u , F/u = 1 小时, us = 10u, dmin ≥ us
四、P2P文件分发： BitTorrent
- 文件被分为一个个块256KB
- 网络中的这些peers发送接收文件块，相互服务
- Peer加入torrent:
- 一开始没有块，但是将会通过其他节点处累积文件块
- 向跟踪服务器注册，获得peer节点列表，和部分peer节点构成邻居关系 (“连接”)
- 当peer下载时，该peer可以同时向其他节点提供上载服务
- Peer可能会变换用于交换块的peer节点
- 扰动churn: peer节点可能会上线或者下线
- 一旦一个peer拥有整个文件，它会（自私的）离开或者保留（利他主义）在torrent中
五、BitTorrent: 请求，发送文件块
1、请求块：
- 在任何给定时间，不同peer节点拥有一个文件块的子集
- 周期性的，Alice节点向邻居询问他们拥有哪些块的信息
- Alice向peer节点请求它希望的块，稀缺的块
2、发送块：一报还一报tit-for-tat
- Alice向4个peer发送块，这些块向它自己提供最大带宽的服务
- 其他peer被Alice阻塞 (将不会从Alice处获得服务)
- 每10秒重新评估一次：前4位
- 每个30秒：随机选择其他peer节点，向这个节点发送块
- “优化疏通” 这个节点
- 新选择的节点可以加入这个top4
六、BitTorrent: tit-for-tat
(1) Alice “优化疏通” Bob
(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice
(3) Bob 变成了Alice的前4提供者
七、P2P 文件共享
例子
- Alice 在其笔记本电脑上运行 P2P 客户端程序
- 间歇性地连接到Internet ，每次从其ISP 得到新的 IP 地址
- 请求“双截棍 .MP3 ”
- 应用程序显示其他有“双截棍 .MP3 ” 拷贝的对等方
- Alice 选择其中一个对等方，如 Bob.
- 文件从 Bob ’ s PC 传送到Alice 的笔记本上： HTTP
- 当 Alice 下载时，其他用户也可以从 Alice 处下载
- Alice 的对等方既是一个 Web客户端，也是一个瞬时 Web服务器
所有的对等方都是服务器= 可扩展性好！
- 两大问题：
- 如何定位所需资源
- 如何处理对等方的加入与离开
- 可能的方案
- 集中
- 分散
- 半分散
八、P2P ：集中式目录
最初的“ Napster ”设计
1) 当对等方连接时，它告知中心服务器：
- IP 地址
- 内容
2) Alice 查询 “双截棍.MP3 ”
3) Alice 从 Bob 处请求文件
存在的问题：
- 单点故障
- 性能瓶颈
- 侵犯版权
文件传输是分散的，而定位内容则是高度集中的
九、查询洪泛： Gnutella
- 全分布式
- 没有中心服务器
- 开放文件共享协议
- 许多 Gnutella 客户端实现了 Gnutella 协议
- 类似 HTTP 有许多的浏览器
覆盖网络：图
- 如果 X 和 Y 之间有一个TCP 连接，则二者之间存在一条边
- 所有活动的对等方和边就是覆盖网络
- 边并不是物理链路
- 给定一个对等方，通常所连接的节点少于 10 个
1、Gnutella ：协议
- 在已有的 TCP 连接上发送查询报文
- 对等方转发查询报文
- 以反方向返回查询命中报文
2、Gnutella ：对等方加入
1. 对等方 X 必须首先发现某些已经在覆盖网络中的其他对等方：使用可用对等方列表
- 自己维持一张对等方列表（经常开机的对等方的 IP ）联系维持列表的 Gnutella 站点
2. X 接着试图与该列表上的对等方建立 TCP 连接，直到与某个对等方 Y 建立连接
3. X 向 Y 发送一个 Ping 报文， Y 转发该 Ping 报文
4. 所有收到 Ping 报文的对等方以 Pong 报文响应
- IP 地址、共享文件的数量及总字节数
5. X 收到许多 Pong 报文，然后它能建立其他 TCP 连接
十、利用不匀称性： KaZaA
- 每个对等方要么是一个组长，要么隶属于一个组长
- 对等方与其组长之间有TCP 连接
- 组长对之间有 TCP 连接
- 组长跟踪其所有的孩子的内容
- 组长与其他组长联系
- 转发查询到其他组长
- 获得其他组长的数据拷贝
组内集中，组外泛洪
1、KaZaA ：查询
- 每个文件有一个散列标识码和一个描述符
- 客户端向其组长发送关键字查询
- 组长用匹配进行响应：
- 对每个匹配：元数据、散列标识码（hash）和 IP 地址
- 如果组长将查询转发给其他组长，其他组长也以匹配进行响应
- 客户端选择要下载的文件
- 向拥有文件的对等方发送一个带散列标识码的HTTP 请求
2、KaZaA 小技巧
- 请求排队
- 限制并行上载的数量
- 确保每个被传输的文件从上载节点接收一定量的带宽
- 激励优先权
- 鼓励用户上载文件
- 加强系统的扩展性
- 并行下载
- 从多个对等方下载同一个文件的不同部分
- HTTP 的字节范围首部
- 更快地检索一个文件
- 从多个对等方下载同一个文件的不同部分
十一、Distributed Hash Table (DHT)
- 哈希表
- DHT方案
- 环形DHT 以及覆盖网络
- Peer波动
2.7 CDN
一、视频流化服务和CDN：上下文
- 视频流量：占据着互联网大部分的带宽
- Netflix, YouTube: 占据37%, 16% 的ISP下行流量
- ~1B YouTube 用户, ~75M Netflix用户
- 挑战：规模性-如何服务者 ~1B 用户?
- 单个超级服务器无法提供服务
- 挑战：异构性
- 不同用户拥有不同的能力（例如：有线接入和移动用户；带宽丰富和受限用户）
- 解决方案: 分布式的，应用层面的基础设施
二、存储视频的流化服务
简单场景：先下载视频再播放
三、多媒体流化服务：DASH
- DASH: Dynamic, Adaptive Streaming over HTTP
- 服务器:
- 将视频文件分割成多个块
- 每个块独立存储，编码于不同码率（8-10种）
- 告示文件（manifest file）: 提供不同块的URL
- 客户端:
- 先获取告示文件
- 周期性地测量服务器到客户端的带宽
- 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
- 如果带宽足够，选择最大码率的视频块
- 会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)
- “智能”客户端: 客户端自适应决定
- 什么时候去请求块 (不至于缓存挨饿，或者溢出)
- 请求什么编码速率的视频块 (当带宽够用时，请求高质量的视频块)
- 哪里去请求块 (可以向离自己近的服务器发送URL，或者向高可用带宽的服务器请求)
- 挑战: 服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)?
- 选择1: 单个的、大的超级服务中心“mega-server”
- 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
- “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
- 单点故障点，性能瓶颈
- 周边网络的拥塞
评述：相当简单，但是这个方法不可扩展
- 选项2: 通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
- enter deep: 将CDN服务器深入到许多接入网
- 更接近用户，数量多，离用户近，管理困难
- Akamai, 1700个位置
- bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近（离若干1 st ISP POP较近）
- 采用租用线路将服务器簇连接起来
- Limelight
四、Content Distribution Networks (CDNs)
- CDN: 在CDN节点中存储内容的多个拷贝
- e.g. Netflix stores copies of MadMen
- 用户从CDN中请求内容
- 重定向到最近的拷贝，请求内容
- 如果网络路径拥塞，可能选择不同的拷贝
案例学习：Netflix
