2.0 应用层提纲

• 目标：
• 网络应用的原理：网络应用协议的概念和实现方面
• 传输层的服务模型
• 客户-服务器模式
• 对等模式(peer-to-peer)
• 内容分发网络

• 网络应用的实例：互联网流行的应用层协议
• HTTP
• FTP
• SMTP / POP3 / IMAP
• DNS

• 编程：网络应用程序
• Socket API

• 一些网络应用的例子
• E-mail、Web、文本消息、远程登录、P2P文件共享、即时通信、多用户网络游戏、流媒体(YouTube, Hulu, Netflix)、Internet电话、实时电视会议、社交网络、搜索

2.1 应用层原理

• 编程
• 在不同的端系统上运行
• 通过网络基础设施提供的服务，应用进程彼此通信
• 如Web：Web服务器软件与浏览器软件通信

• 网络核心中没有应用层软件
• 网络核心没有应用层功能
• 网络应用只在端系统上存在，快速网络应用开发和部署

2.2 网络应用的体系结构

• 可能的应用架构：(从应用进程和应用进程的沟通方式来看)
• 客户-服务器模式（C/S:client/server）
• 对等模式(P2P:Peer To Peer)
• 混合体：客户-服务器和对等体系结构

2.2.1 客户-服务器（C/S）体系结构

• 服务器：
• 一直运行（守候在知名端口上，固定IP）
• 因为是先运行的客户端需要通过域名找服务器，所以需要服务器运行在约定好（知名）端口上。所以服务器在固定的端口上一直跑，首先跑。客户端后跑，主动请求服务器资源，服务器响应这个请求，再把资源返回回来，然后客户端得到这样的资源，整个过程就结束了。客户端不一定要运行在固定IP上，可以在动态IP上。
• 资源在服务器上，包括软件资源、硬件资源、数据资源都在服务器上。客户端向服务器请求资源。
• 固定的IP地址和周知的端口号（约定）
• 扩展性：服务器场
• 数据中心进行扩展
• 扩展性差
• eg：一个服务器服务几百台客户端，并发请求，没问题。上千台、上万台无法同时满足高并发请求，所以扩容，硬盘扩容、内存扩…或者换更高级的服务器。同时网络也得扩容（网络瓶颈）。随着用户的增加，性能是断崖式下降。
• 可靠性差
• 都依赖服务器提供的资源，如果服务器出现故障，那么造成很大损失。

• 客户端：
• 主动与服务器通信
• 与互联网有间歇性的连接
• 可能是动态IP地址
• 不直接与其他客户端通信

2.2.2 对等体（P2P）体系结构

• （几乎）没有一直运行的服务器

• 任意端系统之间可以进行通信

• 每一个节点既是客户端又是服务器
• 自扩展性：新peer节点带来新的服务能力，当然也会来新的服务请求

• 参与的主机间歌性连接且可以改变IP地址
• 难以管理。
• 因为每个节点会上线下线，而提供的服务只有在上线时候才会有，所以需要实时知道哪个节点上线了哪个节点下线了。但CS模式里面，服务一直都是服务器提供，服务器一直运行。

• 例子：Gnutella, 迅雷

2.2.3 C/S和P2P体系结构的混合体

• Napster
• 文件搜索：集中
• 主机（客户端）在中心服务器上注册其资源（告诉服务器客户端的所拥有的资源）
• 主机向中心服务器查询资源位置（告诉服务器客户端的IP地址）
• 文件传输：P2P
• 任意Peer节点之间

• 即时通信
• 在线检测：集中
• 当用户上线时，向中心服务器注册其IP地址
• 用户与中心服务器联系，以找到其在线好友的位置
• 两个用户之间聊天：P2P

2.3 进程通信

• 进程：在主机上运行的应用程序
• 客户端进程：发起通信的进程(主动发起)
• 服务器进程：等待连接的进程（被动响应）

• 在同一个主机内，使用进程间通信机制通信（操作系统定义）
• 如果两个应用进程在同一台机器上，通信可以不用网络标准，使用OS进行通信。管道、消息队列、共享缓冲区…

• 不同主机，进程间通过交换报文（Message）来通信
• 使用OS提供的通信服务
• 按照应用协议交换报文
• 借助传输层提供的服务

• 注意:P2P架构的应用也有客户端进程和服务器进程之分(每个节点虽然对等，但是在每个会话上也有客户端（主动请求）和服务器（被动响应）之分)

2.3.1 分布式进程通信需要解决的问题

• 问题1：进程标示和寻址问题（服务用户）
• 需要标示进程唯一，且标示具有寻址作用

• 问题2：传输层-应用层提供服务是如何使用（服务：服务形式和服务地点）
• 位置：层间界面的SAP（TCP/IP：socket）
• 形式：应用层接口API（TCP/IP：socket API）

• 问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用（用户使用服务）
• 定义应用层协议：报文格式，解释，时序等
• 编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用时序等

2.3.2 问题1：对进程进行编址（addressing）

• 进程为了接收报文，必须有一个标识即：SAP（发送也需要标示）
• 主机：唯一的32位IP地址
• 仅仅有IP地址不能够唯一标示一个进程：在一台端系统上有很多应用进程在运行
• 所采用的传输层协议：TCP or UDP
• 端口号（Port Numbers）
• 所以标识一个进程（区分进程）需要包括：主机IP,TCP或者UDP（传输层协议），端口号

• 一些知名端口号的例子：
• HTTP: TCP 80 Mail: TCP 25 ftp: TCP 21

• 本质上，一对主机进程之间的通信由2个端节点构成
• 一个进程：用IP+对应协议+port（端节点end point）标识

2.3.2 问题2：传输层提供的服务-需要穿过层间的信息

• 层间接口必须要携带的信息（发的什么，谁发的，发给谁）
• 要传输的报文（对于本层来说，SDU）
• 谁传的：自己的应用进程的标示：IP+TCP(UDP)+端口
• 传给谁：对方的IP+TCP(UDP)+端口号

• 传输层实体（tcp或者udp实体）根据这些信息进行TCP报文段（UDP数据报）的封装
• 源端口号，目标端口号，数据等
• 将IP地址往下交IP实体，用于封装IP数据报：源IP, 目标IP

2.3.3 问题2：传输层提供的服务-层间信息的代表

• 如果Socket API（原语/形式）每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理
• 用个代号标示通信的双方或者单方：socket（实际上是一个整数）
• 这个整数代表一个四元组：我的IP和端口号、对方的IP和端口号
• 本地标识，便于管理
• 就像打开文件OS通过api返回的描述符/句柄一样
• 对句柄的操作，就是对文件的操作

• TCP socket：
• TCP服务，两个进程之间的通信需要之前要建立连接
• 两个进程通信会持续一段时间，通信关系稳定
• 可以用一个整数表示两个应用实体之间的通信关系，本地标示（自身的OS知道就可以，也只有应用层和传输层知道，应用层和传输层的约定）
• 穿过层间接口的信息量最少
• TCP socket：源IP,源端口，目标IP,目标端口

2.3.3.1 TCP之上的套接字（socket）

• 对于使用面向连接服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的标示
• 4元组：（源IP, 源port, 目标IP, 目标port）
• 唯一的指定了一个会话（2个进程之间的会话关系）
• 应用使用这个标示，与远程的应用进程通信
• 不必在每一个报文的发送都要指定这4元组
• 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名。操作这个句柄即操作文件。那么操作这个socket值，相当于操作这个会话关系。
• 简单，便于管理

2.3.3.2 UDP socket

• UDP服务，两个进程之间的通信需要之前无需建立连接
• 每个报文都是独立传输的
• 前后报文可能给不同的分布式进程

• 因此，只能用一个整数表示本应用实体的标示（代表一个端节点，但是不代表会话关系，因为UDP无连接）
• 因为这个报文可能传给另外一个分布式进程
• 只是代表本地的IP和端口（即一个端节点）

• 穿过层间接口的信息大小最小

• UDP socket: 本IP, 本端口

• 但是传输报文时：必须要提供对方IP, port
• 接收报文时：传输层需要上传对方的IP, port
• 所以传输时需要三件东西：报文本身，UDP socket，对方IP和Port

• 对于使用无连接服务（UDP）的应用而言，套接字是2元组的一个具有本地意义的标示
• 2元组：IP, port（源端指定）
• UDP套接字指定了应用所在的一个端节点（end point）
• 在发送数据报时，采用创建好的本地套接字（标示 ID），就不必在发送每个报文中指明自己所采用的ip和port
• 但是在发送报文时，必须要指定对方的ip和udp port(另外一个端节点)

• UDP socket: 用于指明应用进程所在端节点的本地标示
• 发的时候需要指明目标IP和Port
• 收的时候根据目标IP和Port值找到响应的socket，交给socket应用进程寻找

我们在应用层，可以借助传输层所提供的服务建立socket，通过socket发送和接收。怎么在传输层提供的服务上进行应用层协议的制定？（传输层的服务是什么怎么实现，是传输层的知识）。目前只关心本层的事情。（在后续每层的学习中也是这样。）

2.3.3.3 套接字（Socket）

• 进程向套接字发送报文或从套接字接收报文

• 套接字 <-> 门户
• 发送进程将报文推出门户，发送进程依赖于传输层设施在另外一侧的门将报文交付给接受进程
• 接收进程从另外一端的门户收到报文（依赖于传输层设施）

2.3.4 问题3：如何使用传输层提供的服务实现应用

• 定义应用层协议：报文格式，解释，时序等

• 编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

2.4 应用层协议

协议：对等层的实体在通信过程中所遵守的规则集合

• 定义了：运行在不同端系统上的应用进程（分布式的应用进程）如何相互交换报文（遵守的规则集合）
• 交换的报文类型：请求和应答报文
• 各种报文类型的语法：报文中的各个字段及其描述
• 字段的语义：即字段取值的含义
• 进程何时、如何发送报文及对报文进行响应的规则

• 应用协议仅仅是应用的一个组成部分
• Web应用：HTTP协议，web客户端，web服务器，HTML（用户界面，IO等等与网络无关的东西）
• 实体的进一步理解：和协议相关，遵守协议的内容

• 公开协议
• 由RFC文档定义
• 允许互操作口
• 如HTTP, SMTP

• 专用（私有）协议
• 协议不公开如:Skype

2.5 传输层提供的服务

• 数据丢失率
• 有些应用则要求100%的可靠数据传输（如文件，必须跑在TCP上）
• 有些应用（如音频）能容忍一定比例以下的数据丢失（跑在UDP上，视频小噪点/声音小毛刺可以靠前后信息弥补）

• 延迟
• 一些应用出于有效性考虑，对数据传输有严格的时间限制
• Internet电话、交互式游戏
• 延迟、延迟差

• 吞吐
• 一些应用(如多媒体)必须需要最小限度的吞吐，从而使得应用能够有效运转（实时传输对吞吐量是有要求的，音频和视频）
• 一些应用能充分利用可供使用的吞吐(弹性应用，传得慢也行)
• 取决于瓶颈链路

• 安全性
• 机密性
• 完整性
• 可认证性（鉴别）

2.5.1 TCP服务

• TCP服务：
• 可靠的传输服务（这边发送什么对方就可以收到什么）
• 流量控制：发送方不会淹没接受方
• 拥塞控制：当网络出现拥塞时，TCP实体能抑制发送方，能感知到路径上拥塞程度，扩大或者减少发送速率
• 不能提供的服务：时间保证、最小吞吐量保证和安全
• 面向连接：要求在客户端进程和服务器进程之间建立连接

• 安全TCP
• TCP & UDP
• 都没有加密（所以都不提供安全）
• 明文通过互联网传输，甚至密码
• SSL（安全套接字层）
• 在TCP上面实现，提供加密的TCP连接
• 私密性
• 数据完整性
• 端到端的鉴别
• SSL在应用层
• 应用采用SSL库，SSL库使用TCP通信
• SSL socket API
• 应用通过API将明文交给socket，SSL将其加密在互联网上传输
• 详见第8章

2.5.2 UDP服务

• UDP服务：
• 不可靠数据传输
• 不提供的服务：可靠，流量控制、拥塞控制、时间、带宽保证、建立连接
• 为什么要有UDP？

• UDP存在的必要性
• 能够区分不同的进程，而IP服务不能（增加端口号的识别机制）
• 在IP提供的主机到主机端到端功能的基础设施上，区分了主机的应用进程
• 无需建立连接，省去了建立连接时间，适合事务性的应用
• 不做可靠性的工作，例如错误重发，适合那些对实时性要求比较高而对正确性要求不高的应用（网络实时多媒体）
• 因为为了实现可靠性（准确性、保存等），必须付出时间代价（检错重发）
• 没有拥塞控制和流量控制，应用能够按照设定的速度发送数据
• 而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制

2.5.3 应用、应用层协议和传输协议

2.6 具体网络应用和协议：Web and Http

• 一些术语
• Web页：由一些对象组成
• 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等
• Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接）
• 通过URL对每个对象进行引用
• 访问协议，用户名，口令字，端口等；
• URL格式: Prot://user:psw@www.someSchool.edu/someDept/pic.gif:port

2.6.1 HTTP协议

2.6.1.1 HTTP概况

• HTTP: 超文本传输协议
• （即不是线性关系，网状结构） (hypertext transport protocol)
• Web的应用层协议
• 客户/服务器模式
• 客户: 请求、接收和显示Web对象的浏览器
• 服务器: 对请求进行响应，发送对象的Web服务器
• 客户端（浏览器）首先需要和服务器建立起TCP的连接，在这个连接之上发送http请求。对方web服务器收到这个请求后，再把客户端请求的对象封装成http响应报文，回转回客户端。PC端和移动终端都是如此。
• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068

2.6.1.2 HTTP如何工作？

• 使用TCP:
• 客户发起一个与服务器的TCP连接（建立连接字socket，指向客户（浏览器）和服务器的会话关系），端口号为80
• 服务器接受客户的TCP连接
• 在浏览器（HTTP客户端）与Web服务器（HTTP服务器server）交换HTTP报文（应用层协议报文）
• TCP连接关闭

• HTTP是无状态的
• 服务器并不维护关于客户的任何信息
• 维护状态的协议很复杂！
• 必须维护历史信息（状态）
• 如果服务器/客户端死机，它的状态信息可能不一致，二者的信息必须一致
• 无状态的服务器能支持更多的客户端（无记忆轻载，所以可以维护的客户端数量更多）

2.6.1.3 HTTP连接

• TCP连接请求过去，TCP连接建立确认回来（socket api）。发送HTTP请求（HTTP请求报文）过去，HTTP响应报文（找到的对象封装在里面）回来。这里有一个HTTP响应报文的传输时间。

• TCP连接请求相对于一个对象的报文来说，字节数少，传输时间可以忽略。一个对象的传输时间不可以忽略不计

• 后面还有C→S:连接拆除请求和S→C:连接拆除请求的确认。

• 这是HTTP 1.0（非持久HTTP）
• 非持久HTTP
• 最多只有一个对象在TCP连接上发送
• 下载多个对象需要多个TCP连接
• HTTP/1.0使用非持久连接

• 持久HTTP
• 多个对象可以在一个TCP连接上（在客户端和服务器之间的）传输
• HTTP/1.1 默认使用持久连接
• 连接不关，在这个连接上如果还有别的对象发送请求，那么还可以在这个连接上发送请求。

2.6.1.4 响应时间模型

• 往返时间RTT（round-trip time）：
• 一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略，因为是小分组）

• 响应时间
• 一个RTT用来发起TCP连接
• 一个RTT用来HTTP请求并等待HTTP响应
• 文件传输时间
• 共：2RTT+传输时间

2.6.1.5 持久HTTP

• 非持久HTTP的缺点：
• 每个对象要2个RTT
• 操作系统必须为每个TCP连接分配资源
• 但浏览器通常打开并行TCP连接，以获取引用对象

• 持久HTTP模式：
• 服务器在发送响应后，仍保持TCP连接
• 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
• 客户端在遇到一个引用对象的时候，就可以尽快发送对象的请求
• 非流水方式的持久HTTP
• 通用的请求连接，连接确认。请求对象，对象回来。
• 客户端只能在收到前一个响应后才能发出新的请求（前面一个请求对象回来后，才能发送新的请求）
• 每个引用对象花费一个RTT
• 流水方式的持久HTTP
• HTTP/1.1的默认模式
• 客户端遇到一个引用对象就立即产生一个请求（这个请求的对象还没有回来，就已经发出下一个请求）
• 所有引用(小)对象只花费一个RTT是可能的

2.6.2 HTTP请求报文

• 两种类型的HTTP报文：请求、响应

• HTTP请求报文：
• ASCII(人能够阅读，不是二进制的01)



请求行：命令字：GET（头和body都有）,POST(上载)，HEAD(拿头建索引) +空格/
URL
host主机名，用户代理，连接



 

2.6.3 提交表单输入

• Post方式：
• 网页通常包括表单输入
• 包含在实体主体（entity body）中的输入被提交到服务器

• URL方式
• 方法:GET
• 输入通过请求行的URL字段上载

• HTTP/1.0
• GET
• POST
• HEAD
• 要求服务器在响应报文中不包含请求对象→故障跟踪

• HTTP/1.1
• GET, POST, HEAD
• PUT
• 将实体主体中的文件上传到URL字段指定的路径
• DELETE
• 删除URL字段指定的文件

2.6.4 HTTP响应报文

• 位于服务器->客户端的响应报文中的首行

• 一些状态码的例子：
• 200 OK
• 请求成功，请求对象包含在响应报文的后续部分
• 301 Moved Permanently
• 请求的对象已经被永久转移了；新的URL在响应报文的Location首部中指定
• 400 Bad Request
• 一个通用的错误代码，表示该请求不能被服务器解读
• 404 Not Found
• 请求的文档在该服务上没有找到
• 505 HTTP Version Not Supported
• 版本号不支持

2.6.5 用户-服务器状态：cookies

• 大多数主要的门户网站使用cookies
• 4个组成部分：
（0.第一次发送对象请求的时候无cookie）
1. 在HTTP响应报文中有一个cookie的首部行
1. 服务器数据库保留这个cookie
2. HTTP请求报文含有一个cookie的首部行
3. 在用户端系统中保留有一个cookie文件，由用户的浏览器管理(在os本地文件系统相应目录下)
4. 在Web站点有一个后端数据库
(下次用户再次访问相同网站的时候，可以带上对应cookie，和服务器端的数据库中cookie建立联系，得到信息)

• 例子
• Susan总是用同一个PC使用Internet Explore上网
• 她第一次访问了一个使用了Cookie的电子商务网站
• 当最初的HTTP请求到达服务器时，该Web站点产生一个唯一的ID，并以此作为索引在它的后端数据库中产生一个项

2.6.5.2 Cookies：维护状态

• Cookies能带来什么：
• 用户验证
• 购物车
• 推荐
• 用户状态（Web e-mail）

• 如何维持状态：
• 协议端节点：在多个事务上，发送端和接收端维持状态
• cookies：http报文携带状态信息

2.6.5.2 Cookies与隐私

• Cookies允许站点知道许多关于用户的信息

• 可能将它知道的东西卖给第三方

• 使用重定向和cookie的搜索引擎还能知道用户更多的信息
• 如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式

• 广告公司从站点获得信息

2.6.6 Web缓存

• 目标：不访问原始服务器，就满足客户的请求

• 用户设置浏览器：通过缓存访问Web

• 浏览器将所有的HTTP请求发给缓存
• 在缓存中的对象：缓存直接返回对象（本地被命中）
• 如对象不在缓存，缓存请求原始服务器，然后将对象返回给客户端

2.6.6.1 Web缓存特点

• 缓存既是客户端又是服务器

• 通常缓存是由ISP安装（大学、公司、居民区ISP）

• 为什么要使用Web缓存？
• 降低客户端的请求响应时间
• 可以大大减少一个机构内部网络与Internet接入链路上的流量（服务器负载减轻，很多都被proxy命中）
• 互联网大量采用了缓存：可以使较弱的TCP也能够有效提供内容（访问的趋同性）

2.6.6.2 缓存示例

• 平均对象大小 = 100kb

• 机构内浏览器对原始服务器的平均请求率为15请求/s

• 平均请求速率为1.5Mbps（每个请求会返回100kb的对象，返回的带宽是1.5Mbps）

• 平均浏览器的速率：1.5Mbps

• 机构内部路由器到原始服务器的延时 = 2s

• 接入链路带宽：1.544Mbps

• 结果
• LAN的流量强度 = 15%
• 接入链路上的流量强度 = 99%→排队延时很大（I越接近于1，排队延时陡增）
• 总延时 = LAN延时 + 接入延时 = ms（局域网内访问很快1Gbps LAN） + 分 + 2s

• 平均对象大小 = 100kb

• 机构内浏览器对原始服务器的平均请求率为15请求/s

• 平均到浏览器的速率：1.5Mbps

• 机构内部路由器到原始服务器再返回到路由器的的延时（Internet延时） = 2s

• 接入链路带宽：154Mbps→流量强度1%→排队延时从min级别到ms级

• 代价:增加了接入链路带宽(非常昂贵!）

• 计算链路利用率，有缓存的延迟：
• 假设缓存命中率0.4
• 40%请求在缓存中被满足，其他60%的请求需要被原始服务器满足

• 接入链路利用率：60%
• 60%的请求采用接入链路
• 通过链路到服务器的数据速率：0.6 * 1.5Mbps = 0.9 Mbps
• 流量强度I（利用率）=0.9/1.54Mbps=0.58
• I=0.58也没有到陡增的情况，ms
• 主导仍然是2s

• 总体延迟：





• 0.6 * (2s + 0.4 * (ms)) + 0.4 * (2s + 2s) = 1.2 秒
• 一定比例的满足本地用户的要求，既能减少访问时间，也可以减少投入

2.6.6.3 条件GET方法

• 目标：如果缓存器中的对象拷贝是最新的，就不要发送对象
• 就是如果服务器中的报文没有修改，那么就说明缓存是有用的，告诉我没有改变就可以而不用传一次总的报文。
• 如果改了，那么就回复一个200 OK后面跟着新的报文内容

• 缓存器：在HTTP请求中指定缓存拷贝的日期
• If-modified-since: <date>

• 服务器：如果没有拷贝陈旧，则响应报文没包含对象：
• HTTP/1.0 304 Not Modified

• 解决：缓存和服务器版本一致性的问题

2.7 FTP（文件传输协议）

• 向远程主机上传文件或从远程主机接收文件（upload，download）

• 客户/服务器模式
• 客户端：发起传输的一方
• 服务器：远程主机

• FTP: RFC 959

• FTP服务器：端口号为21
• 服务器首先在21号端口运行起来，等待客户端和其建立连接。（控制性的TCP连接→FTP控制连接），然后在控制连接上进行用户认证。在控制连接上客户端可以向服务器端发送指令（upload download list文件）

2.7.1 FTP：控制连接与数据连接分开

• FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
• 两个FTP的进程/应用调用一些列socket api建立起socket（TCP连接）

• 客户端通过控制连接获得身份确认（身份认证）

• 客户端通过控制连接发送命令调阅远程目录

• 收到一个文件传输命令时，服务器打开一个到客户端的数据连接
• 服务器主动建立起和客户端的20号端口建立一个新连接（数据连接）
• 即数据传输是通过另外一个TCP连接（数据连接）
• 关于文件的上传/下载/list是通过控制连接

• 一个文件传输完成后，服务关闭连接

（FTP协议：有状态协议）

（HTTP:无状态协议，+cookie 有状态）

2.7.2 FTP命令、响应

• 命令样例：在控制连接上以ASCII文本方式传送
• USER username
• PASS password
• LIST:请服务器返回远程主机当前目录的文件列表
• RETR filename:从远程主机的当前目录检索文件(gets)
• STOR filename:向远程主机的当前目录存放文件(puts)
• 上载：客户端向服务器发东西；下载：客户端接收服务器的东西

• 返回码样例：状态码和状态信息(同HTTP)
• 331 Username OK,password required
• 125 data connection already open;
• 425 Can't open data connection.
• 452 Error writing file

2.8 Email

• 3个主要组成部分：
• 用户代理
• 邮件服务器
• 简单邮件传输协议：SMTP

• 用户代理
• 也就是撰写发送和接收的邮件的客户端软件
• 又名“邮件阅读器”
• 撰写、编辑和阅读邮件
• 如Outlook、Foxmail
• 输出和输入邮件保存在服务器上
• Web应用的用户代理：浏览器
• FTP应用的用户代理：FTP应用软件

• 邮件服务器（守候在25号端口）
• 邮箱中管理和维护发送给用户的邮件
• 输出报文队列保持待发送邮件报文
• 邮件服务器之间的SMTP协议发送email报文
• 客户：发送方邮件服务器
• 服务器：接收端邮件服务器

 

用户代理配置好邮件服务器的IP地址端口号，发邮件给邮件服务器，邮件服务器将邮件放在报文队列（绿色）里，排着队发走。通过SMTP协议发给接收端服务器。接收端服务器将收到的邮件放在相应用户邮箱（黄色）里。

目标用户收邮件的时候再运行客户代理，从邮箱里面拉。（拉出邮件的协议：POP3,IMA，HTTP)

为什么放在队列里面再发？

因为队列形式可以控制邮件的收发速率，同时有间隔期可以使得收发平滑。

1. Alice使用用户代理撰写邮件并发送给bob@someschool.edu

2. Alice的用户代理将邮件发送到她的邮件服务器；邮件放在报文队列中

3. SMTP的客户端打开到Bob邮件服务器的TCP连接

4. SMTP客户端通过TCP连接发送Alice的邮件

5. Bob的邮件服务器将邮件放到Bob的邮箱

6. Bob调用他的用户代理阅读邮件

2.8.1 SMTP协议

• SMTP [RFC 2821]
• 使用TCP在客户端和服务器之间传送报文，端口号为25
• 直接传输：从发送方服务器到接收方服务器
• 传输的3个阶段
• 握手
• 传输报文
• 关闭
• 命令/响应交互
• 命令：ASCII文本
• 响应：状态码和状态信息（也是ASCII码）
• 报文必须是7为ASCII码

• SMTP使用持久连接

• SMTP要求报文（首部和主体）为7位ASCII编码

• SMTP服务器使用CRLF.CRLF决定报文的尾部

• HTTP比较：
• HTTP：拉（pull）
• SMTP：推（push）
• 二者都是ASCII形式的命令/响应交互、状态码
• HTTP: 每个对象封装在各自的响应报文中
• 其他对象在这个报文中是以URL链接形式，所以HTTP报文最多只有一个对象
• SMTP: 多个对象包含在一个报文中

2.8.2 邮件报文格式

• SMTP：交换email报文的协议

• RFC 822：文本报文的标准：
• 首部行：如，
• To:
• From:
• Subject:(邮件title)
• 与SMTP命令不同！
• 主体
• 报文，只能是ASCII码字符

• MIME：多媒体邮件扩展（multimedia mail extension），RFC 2045, 2066

• 在报文首部用额外的行申明MIME内容类型

• SMTP：传送到接收方的邮件服务器(准确来说是队列里)
• 前两跳都是SMTP

• 邮件访问协议：从服务器访问邮件
• POP3: 邮局访问协议（Post Office Protocol）[RFC 1939]
• 用户身份确认（代理->服务器）并下载
• IMAP: Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]
• 更多特性（更复杂）：例如远程目录维护、远程报文搬运…
• 在服务器上处理存储的报文
• HTTP:Hotmail, Yahoo! Mail等
• 方便

2.8.3 POP3、IMAP协议

• POP3（本地管理文件夹）
• 先前的例子使用“下载并删除”模式。
• 如果改变客户机，Bob不能阅读邮件
• 好处是邮箱不会满
• “下载并保留”:不同客户机上为报文的拷贝
• POP3在会话中是无状态的（因为不支持远程目录维护）

• IMAP（远程管理文件夹）
• IMAP服务器将每个报文与一个文件夹联系起来
• 允许用户用目录来组织报文
• 允许用户读取报文组件口
• IMAP在会话过程中保留用户状态:（有状态）
• 目录名、报文TD与目录名之间映射

2.9 DNS (域名解析系统：Domain Name System)

• DNS的必要性
• IP地址标识主机、路由器（IP地址的作用：标识和寻址）
• 但IP地址不好记忆，不便人类使用(没有意义)
• 人类一般倾向于使用一些有意义的字符串来标识Internet上的设备：例如:gzheng@ustc.edu.cn 所在的邮件服务器www.ustc.edu.cn 所在的web服务器
• 存在着“字符串”→IP地址的转换的必要性
• 人类用户提供访问机器的“字符串”名称
• 由DNS负责转换成为二进制的网络地址

• 问题1：如何命名设备
• 用有意义的字符串：好记，便于人类使用
• 解决一个平面命名的重名问题：层次化命名

• 问题2：如何完成名字到IP地址的转换
• 分布式的数据库维护和响应名字查询

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

• ARPANET的名字解析解决方案
• 主机名：没有层次的一个字符串（一个平面）
• 存在着一个（集中）维护站；维护着一张主机名-IP地址的映射文件：Hosts.txt
• 每台主机定时从维护站取文件

• ARPANET解决方案的问题
• 当网络中主机数量很大时
• 没有层次的主机名称很难分配
• 文件的管理、发布、查找都很麻烦

2.9.2 DNS总体思路和目标

• DNS的主要思路
• 分层的、基于域的命名机制
• 若干分布式的数据库完成名字到IP地址的转换
• 运行在UDP之上端口号为53的应用服务（握手过于繁琐所以选择UDP）
• 核心的Internet功能，但以应用层协议实现
• 在网络边缘处理复杂性

• DNS主要目的：
• 实现主机名-IP地址的转换(name/IP translate)
• 其它目的
• 主机别名到规范名字的转换：Host aliasing（别名便于用户访问，规范名字便于管理）
• 邮件服务器别名到邮件服务器的正规名字的转换：Mail server
• 负载均衡：Load Distribution（同一个别名访问，但是经过DNS之后可以精准提供服务器，所以负载均衡）

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

• DNS域名结构
• 一个层面命名设备会有很多重名
• NDS采用层次树状结构的命名方法
• Internet根被划为几百个顶级域(top level domains)
• 通用的(generic)
• .com ; .edu ; .gov ; .int ; .mil ; .net ; .org; .hsop ; .web ; .arts ; .rec ;
• 国家的(countries)
• .cn ; .us ; .nl ; .jp
• 每个(子)域下面可划分为若干子域(subdomains):二级域，三级域，也可直接挂载在顶级域下
• 树叶是主机（最末端）

• 共有13个根名字服务器

• 域名(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.9.3 问题2：解析问题-名字服务器(Name Server)

• 一个名字服务器的问题
• 可靠性问题：单点故障
• 扩展性问题：通信容量
• 维护问题：远距离的集中式数据库

• 区域(zone)
• 区域的划分有区域管理者自己决定
• 将DNS名字空间划分为互不相交的区域，每个区域都是树的一部分
• 名字服务器：
• 每个区域都有一个名字服务器：持有它所管辖区域的权威信息( authoritative record)
• 名字服务器允许被放置在区域之外，以保障可靠性

• 权威DNS服务器
• 组织机构的DNS服务器，提供组织机构服务器(如Web和mail)可访问的主机和IP之间的映射组织机构可以选择实现自己维护或由某个服务提供商来维护

• TLD服务器
• 顶级域(TLD)服务器:负责顶 级域名(如com,org,net,edu和gov)和所有国家级的顶级域名(如cn,uk,fr，cajp )
• Network solutions 公司维护com TLD服务器
• Educause公司维护edu TLD服务器

2.9.4 区域名字服务器维护资源记录

• 资源记录(resource records)
• 作用：维护域名-IP地址(其它)的映射关系
• 位置：Name Server域名服务器的分布式数据库中

• RR格式：(domain_name, ttl, type, class, Value)
• domain_name: 域名
• ttl: time to live：生存时间(权威记录ttl无限大，缓冲记录ttl有限，2天)
• 缓冲：性能快 删除：一致性
• Class 类别：对于Internet，值为IN
• Value 值：可以是数字，域名或ASCII串
• Type 类别：资源记录的类型—见下页

• 一个例子

• DNS大致工作过程
• 应用调用 解析器(resolver)
• 解析器作为客户端向Name Server发出查询报文（封装在UDP段中）
• Name Server返回响应报文(name/ip)

• 并不严格属于层次结构

• 每个ISP（居民区的ISP、公司、大学）都有一个本地DNS服务器
• 也称为“默认名字服务器”

• 当一个主机发起一个DNS查询时，查询被送到其本地DNS服务器
• 起着代理的作用，将查询转发到层次结构中
• 一般在同一个子网内，速率快
• Local Name Server的地址一般是动态配/手工配

• 名字解析过程
• 目标名字在Local Name Server中
• 情况1：查询的名字在该区域内部
• 情况2：缓存(cashing)
• 当与本地名字服务器不能解析名字时，联系根名字服务器
• 顺着根-TLD—一直找到权威名字服务器

2.9.5 DNS两种工作方式

• 递归查询：本地问根，根知道TLD,TLD知道权威DNS，权威DNS知道然后返回。
• 名字解析负担都放在当前联络的名字服务器上（顺着根服务器）
• 问题：根服务器的负担太重
• 解决：迭代查询（Iterated queries）
• 发起请求的主机 cis.poly.edu

• 主机cis.poly.edu 想知道主机gaia.cs.umass.edu的IP地址
• 根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址
• 最后由权威名字服务器给出解析结果
• 当前联络的服务器给出可以联系的服务器的名字
• “我不知道这个名字，但可以向这个服务器请求”

 

 

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

• 报文首部
• 标识符（ID）：16位
• 使得一个Name Server可以同时维护非常多的并行查询（查一个ID号返回一个值，和查询ID对应，就可以精准分配）
• flags
• 询问/应答
• 递归查询
• 递归可用
• 应答为权威

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

• 根服务器通常都在本地服务器中缓存着
• 使得根服务器不用经常被访问

• 目的：提高效率

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

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

2.9.5 问题3：维护问题：新增一个域

• 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址

• 在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字->IP地址
• 例子：在com域中建立一个“Network Utopia”

• 到注册登记机构注册域名networkutopia.com
• 需要向该机构提供权威DNS服务器（基本的、和辅助的）的名字和IP地址

• 登记机构在”com”顶级域名服务器中插入两条RR记录：

记录类型	解释
NS记录	说明 networkutopia.com 由 ns1.networkutopia.com 负责解析
A记录	说明 ns1.networkutopia.com 的IP地址是 212.212.212.1

也就是说，com域的DNS服务器现在知道了：如果有人问 networkutopia.com 的IP是多少，就去问 ns1.networkutopia.com。

• 自己的权威DNS服务器里也要写好记录 你运行着 ns1.networkutopia.com，那你得在里面写清楚：

子域名	类型	作用
www.networkutopia.com	A	网站地址，比如指向 212.212.212.2
mail.networkutopia.com	MX	邮件服务器地址

2.9.10 攻击DNS

• DDoS 攻击
• 对根服务器进行流量轰炸攻击：发送大量ping
• 没有成功
• 原因1：根目录服务器配置了流量过滤器，防火墙
• 原因2：Local DNS 服务器缓存了TLD服务器的IP地址，因此无需查询根服务器
• 向TLD服务器流量轰炸攻击：发送大量查询
• 可能更危险
• 效果一般，大部分DNS缓存了TLD

• 总的来说，DNS比较健壮

• 重定向攻击
• 中间人攻击
• 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点
• DNS中毒
• 发送伪造的应答给DNS服务器，希望能够缓存这个虚假的结果
• 技术上较困难：分布式截获和伪造利用DNS基础设施进行DDoS
• 伪造某个IP进行查询，攻击这个目标IP
• 查询放大，响应报文比查询报文大
• 效果有限

2.10 P2P应用（-）

2.10.1 纯P2P架构

• 没有（或极少）一直运行的服务器

• 任意端系统都可以直接通信

• 利用peer的服务能力

• Peer节点间歇上网，每次IP地址都有可能变化

• 文件分发（BitTorrent）

• 流媒体（KanKan）

• VoIP（Skype）

2.10.2 文件分发：C/S vs P2P

• Peer节点上下载能力是有限的资源

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

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

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

• 采用C-S方法将一个F大小的文件分发给N个客户端耗时:



• 随着N线性增长

2.10.2.2 文件分发时间：P2P模式

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

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

• 客户端：所有客户端总体下载量NF

• 采用P2P方法将一个F大小的文件分发给N个客户端耗时



• 分子随着N线性变化，每个节点需要下载，整体下载量随着N增大
• 分母也是如此，随着peer节点的增多每个peer也带了服务能力

2.10.3 P2P文件共享

• 两大问题：
• 如何定位所需资源
• 如何处理对等方的加入与离开

• 可能的方案：
• 集中
• 分散
• 半分散

• 非结构化P2P
• Peer节点和另外的Peer节点有邻居和会话关系，构成边。然后构成网（覆盖网overlay）
• 两个节点构成边是无序的
• 集中式目录
• 完全分布式
• 混合式

• DHT(结构化)P2P
• 节点构成的边是有序的：环/树/嵌入关系

• 最初的“Napster”设计
• ①当对等方连接时，它告知中心服务器（注册和登记）：
• IP地址
• 内容（我这个IP上有什么资源）
• ②Alice查询“双截棍.MP3”（中心服务器知道在哪个客户端上有）
• ③Alice从Bob处请求文件

• P2P：集中式目录中存在的问题
• 单点故障
• 性能瓶颈
• 侵犯版权
文件传输是分散的，而定位内容则是高度集中的

• 全分布式
• 没有中心服务器

• 开放文件共享协议

• 许多Gnutella客户端实现了Gnutella协议
• 类似HTTP有许多的浏览器

• 如果X和Y之间有一个TCP连接，则二者之间存在一条边

• 所有活动的对等方和边就是覆盖网络

• 边并不是物理链路

• 给定一个对等方，通常所连接的节点少于10个

• 在已有的TCP连接上发送查询报文

• 对等方转发查询报文

• 以反方向返回查询命中报文

• 向所有的邻居发起查询（泛洪），所有邻居又发起查询，很快遍及全网。拥有资源的节点向Alice返回命中报文，这个时候目录就有了。选择节点后，再向拥有这些资源的节点发起查询。

• 有限泛洪：ttl=5就不查了/记住中转查询和已查询过会话

1. 对等方X必须首先发现某些已经在覆盖网络中的其他对等方；使用可用对等方列表
1. 自己维持一张对等方列表(经常开机的对等方的IP)联系维持列表的Gnutella站点

2. X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接

3. X向Y发送一个Ping报文，Y转发该Ping报文

4. 所有收到Ping报文的对等方以Pong报文响应IP地址、共享文件的数量及总字节数

5. X收到许多Pong报文，然后它能建立其他TCP连接

• 每个对等方要么是一个组长，要么隶属于一个组长
• 对等方与其组长之间有TCP连接
• 组长对之间有TCP连接

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

• 组长与其他组长联系
• 转发查询到其他组长
• 获得其他组长的数据拷贝

• 组长和组长间的目录查询是分布式的，组内层面是集中式

• 每个文件有一个散列标识码（Hash值）和一个描述符

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

• 组长用匹配进行响应：
• 对每个匹配：元数据、散列标识码和IP地址

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

• 客户端选择要下载的文件
• 向拥有文件的对等方发送一个带散列标识码的HTTP请求

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

• 激励优先权
• 鼓励用户上传文件
• 增强系统的扩展性

• 并行下载
• 从多个对等方下载同一个文件的不同部分
• HTTP的字节范围首部
• 更快地检索一个文件

• 哈希表

• DHT方案

• 环形DHT 以及覆盖网络

• Peer波动

2.11 CDN

• 视频流量:占据着互联网大部分的带宽

• 挑战:
• 规模性：如何服务者~1B 用户?
• 异构性：不同用户拥有不同的能力(例如:有线接入和移动用户;带宽丰富和受限用户)

• 解决方案:分布式的，应用层面的基础设施

• 多媒体:视频
• 视频:固定速度显示的图像序列 e.g.24 images/sec
• 网络视频特点:
• 高码率:>10x于音频,高的网络带宽需求
• 可以被压缩
• 90%以上的网络流量是视频
• 数字化图像:像素的阵列。
• 每个像素被若干bits表示
• 编码:使用图像内和图像间的冗余来降低编码的比特数仅
• 空间冗余(图像内)
• 时间冗余(相邻的图像间)

2.11 TCP、UDP套接字编程