Computer Network Notes 2：Applications

把老师的 PPT 变成 md 文件之计算机网络第二章应用层自学笔记

本章基本内容

网络应用的原理：网络应用协议的概念和实现方面

• 传输层的服务模型
• 客户-服务器模式
• 对等模式 (peer-to-peer)
• 内容分发网络

网络应用的实例：互联网流行的应用层协议

• HTTP
• FTP
• SMTP / POP3 / IMAP
• DNS

编程：网络应用程序

• Socket API

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

创建一个新的网络应用

编程

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

网络核心中没有应用层软件

• 网络核心没有应用层
• 网络应用只在端系统上存在：快速网络应用开发和部署

网络应用的体系结构

客户-服务器模式 (C/S: client/server)

服务器

• 一直运行
• 固定的 IP 地址和周知的端口号 (约定)
• 扩展性：服务器场
  • 数据中心进行扩展
  • 扩展性差
  • 可靠性差：服务非常依赖于服务器的状态

客户端

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

对等模式 (P2P: Peer to Peer)

(几乎) 没有一直运行的服务器
任意端系统之间可以进行通信
每一个节点既是客户端又是服务器

• 自扩展性：新 peer 节点带来新的服务能力，也带来新的服务请求

参与的主机间歇性连接且可以改变 IP 地址

• 难以管理

eg. Gnutella，迅雷

混合体：客户-服务器和对等体系结构

Napster

• 文件搜索：集中
  • 主机在中心服务器上注册其资源
  • 主机向中心服务器查询资源位置
• 文件传输：P2P
  • 任意 Peer 节点之间

即时通信

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

应用层原理-进程通信

概述

进程：在主机上运行的应用程序

• 客户端进程：发起通信的进程 (主动)
• 服务器进程：等待连接的进程 (被动)

P2P 架构的应用也有客户端进程和服务器进程之分

在同一个主机内，使用进程间通信机制通信 (操作系统定义)
不同主机，通过交换报文 (Message) 来通信

• 使用 OS 提供的通信服务
• 按照应用协议交换报文：借助传输层提供的服务

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

1. 进程标示和寻址问题 (服务用户)
2. 传输层-应用层如何提供服务 (服务)
   • 位置：层间界面的 SAP (TCP/IP: socket)
   • 形式：应用程序接口 API (TCP/IP: socket API)
3. 如何使用传输层提供的服务，实现应用进程之间的报文交换，即实现应用 (用户使用服务)
   • 定义应用层协议：报文格式、解释、时序等
   • 编制程序，使用 OS 提供的 API，调用网络基础设施提供通信服务传报文，实现应用时序等

对进程进行编址 (addressing)

进程为了接收报文，必须有一个标识，即 SAP (发送也需要标示)

• 主机：唯一的 32 位 IP 地址
  • 仅仅有 IP 地址不能唯一标示一个进程，在一台端系统上有很多应用进程在运行
• 所采用的传输层协议：TCP or UDP
• 端口号 (Port Numbers)
  • 一些知名端口号例子：HTTP TCP 80；Mail TCP 25；ftp TCP 2
• 一个进程：用 IP + port 标示，端节点
• 本质上，一对主机进程之间的通信由 2 个端节点 (end point) 构成

传输层提供的服务-需要穿过层间的信息

层间接口必须要携带的信息

• 要传输的报文 (对于本层来说：SDU)
• 谁传的：对方应用进程的标示 IP + TCP (UDP) 端口号
• 传给谁：对方的应用进程标示 对方的 IP + TCP (UDP) 端口号

传输层实体 (TCP 或 UDP 实体)根据这些信息进行 TCP 报文段 (UDP 数据报)的封装

• 源端口号，目标端口号，数据等
• 将 IP 地址往下交 IP 实体，用于封装 IP 数据报：源 IP，目标 IP

传输层提供的服务-层间信息的代表

如果 Socket API 每次传输报文都携带如此多的信息，太繁琐易错，不便于管理
用代号标示通信双方或单方：socket (代表本地 IP、本地端口和对方 IP、对方端口的一个本地标识)
类似 OS 打开文件返回句柄一样，对句柄的操作就是对文件的操作

TCP socket

• TCP 服务，两个进程之间的通信之前需要建立连接
  • 两个进程通信会持续一段时间，通信关系稳定
• 可用一个征数标示两个应用实体之间的通信关系，本地标示 (便于本地管理引入的一个标识)
• 穿过层间接口的信息量最小
• TCP socket：源 IP，源端口，目标IP，目标端口；用于指明应用进程会话的本地标示
• TCP之上的套接字 (socket)：对于使用面向连接的服务 (TCP) 的应用而言，套接字时 4 元组的一个具有本地意义的标示
  • 4 元组：源 IP、源 port、目标 IP、目标 port
  • 唯一的制定了一个会话 (2 个进程之间的会话关系)
  • 应用使用这个标示，与远程的应用进程通信
  • 不必在每一个报文的发送都要指定这个 4 元组
  • 类似文件句柄，每次使用文件句柄，而不是使用文件的目录名、文件名等
  • 简单，便于管理，层间传输的信息较少

UDP socket

• UDP 服务：两个进程之间的通信之前不需要建立连接
  • 每个报文都是独立传输的
  • 前后报文可能给不同的分布式进程
• 只能用一个征数标示本应用实体的标示，因为这个报文可能传给另外一个分布式进程
• 穿过层间接口的信息量最小
• UDP socket：本IP，本端口；2 元组，本地标示
• 传输报文时，必须提供对方 IP、port；接收报文时，传输层需要上传对方的 IP、port
• UDP 之上的套接字 (socket)：对于使用无连接服务 (UDP) 的应用而言，套接字是 2 元组的一个具有本地意义的标示
  • 2 元组：IP，port (源端指定)
  • UDP 套接字指定了应用所在的一个端节点 (end point)
  • 在发送数据报时，采用创建好的本地套接字 (标示 ID)，就不必在发送每个报文中指明自己所采用的 IP 和 port
  • 在发送报文时，必须置顶对方的 IP 和 UDP port (另外一个段节点)

套接字 (Socket)

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

如何使用传输层提供的服务实现应用

应用层协议

• 定义了运行在不同端系统上的应用进程如何相互交换报文
  • 交换的报文类型：请求和应答报文
  • 各种报文类型的语法：报文中的各个字段及其描述
  • 字段的语义：即字段取值的含义
  • 进程何时、如何发送报文及对报文进行响应的规则
• 应用协议仅仅是应用的一个组成部分，仅规范通信交互规则
  • Web 应用：HTTP 协议、web 客户端、web 服务器、HTML
• 公开协议
  • 由 RFC 文档定义
  • 允许互操作
  • eg. HTTP、SMTP
• 专用 (私有) 协议
  • 协议不公开
  • eg. Skype

应用需要传输层提供什么服务

• 数据丢失率
  • 有些应用要求 100 % 的可靠数据传输，如文件
  • 有些应用能容忍一定比例一下的数据丢失，如音频
• 延迟
  • 一些应用出于有效性考虑，对数据传输有严格的时间限制，如 Internet 电话、交互式游戏
• 吞吐
  • 一些应用必须需要最小限度的吞吐，从而使得应用能够有效运转，如多媒体
  • 一些应用能充分利用可供使用的吞吐，如弹性应用
• 安全性
  • 机密性
  • 完整性
  • 可认证性 (鉴别)

Internet 传输层提供的服务

• TCP 服务
  • 可靠的传输服务
  • 流量控制：发送方不会淹没接收方
  • 拥塞控制：当网络出现拥塞时，能抑制发送方
  • 不能提供的服务：时间保证、最小吞吐量保证和安全
  • 面向连接：要求在客户端进程和服务器进程之间建立连接
• UDP 服务
  • 不考考的数据传输
  • 不提供的服务：可靠、流量控制、拥塞控制、时间、带宽保证、建立连接

UDP 存在的必要性

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

安全 TCP

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

Web and HTTP

Web 页

由一些对象组成，对象可以是 HTML 文件、JPEG 图像、Java 小程序、声音剪辑文件等
Web 页含有一个基本的 HTML 文件，该基本 HTML 文件又包含若干对象的引用 (链接)
通过 URL (通用资源调用符)对每个对象进行引用：访问协议、用户名、口令字、端口等，支持匿名访问，默认端口为 80
URL 格式：

HTTP 概况

HTTP

超文本传输协议 (Hyper Text Transform Protocol)，Web 的应用层协议
客户/服务器模式

• 客户：请求、接收和显示 Web 对象的浏览器
• 服务器：对请求进行响应，发送对象的 Web 服务器

HTTP 1.0：RFC 1945
HTTP 1.1：RFC 2068

使用 TCP

• 客户发起一个与服务器的 TCP 连接 (建立套接字)，端口号为 80
• 服务器接受客户的 TCP 连接
• 在浏览器 (HTTP 客户端) 与 Web 服务器 (HTTP 服务器 server) 交换 HTTP 报文 (应用层协议报文)
• TCP 连接关闭

HTTP 是无状态的：服务器并不维护关于客户的任何信息，不维护客户端的状态
维护状态的协议很复杂：

• 必须维护历史信息 (状态)
• 如果服务器/客户端死机，它们的状态信息可能不一致，二者的信息必须是一致的
• 无状态的服务器能够支持更多的客户端

HTTP 连接

响应时间模型

往返时间 RTT (round-trip time)：一个小的分组从客户端到服务器，在回到客户端的时间 (传输时间忽略)
响应时间：

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

共 2 RTT + 传输时间

非持久 HTTP

最多只有一个对象在 TCP 连接上发送
下载多个对象需要多个 TCP 连接
HTTP 1.0 使用非持久连接
过程：TCP 连接请求 -> TCP 连接确认 -> HTTP 请求 -> 对象回传 -> 连接关闭请求 -> 连接关闭确认

非持久 HTTP 的缺点

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

持久 HTTP

多个对象可以在一个 (在客户端和服务器之间的) TCP 连接上传输
HTTP 1.1 默认使用持久连接
过程：TCP 连接请求 -> TCP 连接确认 -> HTTP 请求对象 -> 对象回传；连接不关闭，之后再有请求可直接使用此路径

• 服务器在发送响应后，仍保持 TCP 连接
• 在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送
• 客户端在遇到一个引用对象时，可以尽快发送该对象的请求

非流水方式的持久 HTTP

• 客户端只能在收到前一个响应后才能发出新的请求
• 每个引用对象花费一个 RTT

流水方式的持久 HTTP

• HTTP 1.1 的默认模式
• 客户端遇到一个引用对象就立即产生一个请求
• 所有引用 (小) 对象只花费一个 RTT 是可能的

HTTP 请求报文

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

HTTP 请求报文：

ASCII (人能阅读，readable)

通用格式

提交表单输入

Post 方式

• 网页通常包括表单输入
• 包含在实体主体 (entity body) 中的输入被提交到服务器

URL 方式

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

方法类型

HTTP 1.0

• GET
• POST
• HEAD：要求服务器在响应报文中不包含请求对象 -> 故障跟踪

HTTP 1.1

• GET, POST, HEAD
• PUT：将实体主体中的文件上载到 URL 字段规定的路径，通常用于网页内容的维护
• DELETE：删除 URL 字段规定的文件，用于维护网页

HTTP 响应报文

基本信息

状态行：协议版本、状态码 (如404、504等)和相应状态信息
首部行：服务器、内容等的相关信息，如服务器系统信息、内容的字节长度等
数据：如请求的 HTML 文件

HTTP 响应状态码

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

• 200 OK：请求成功，请求对象包含在响应报文的后续部分
• 301 Moved Permanently：请求的对象已经被永久转移，新的 URL 在响应报文的 Location：首部行中指定；客户端软件自动用新的 URL 去获取对象
• 400 Bad Request：一个通用的差错代码，表示该请求不能被服务器解读
• 404 Not Found：请求的文档在服务器上没有找到
• 505 HTTP Version Not Supported

用户-服务器状态 cookies

大多数主要的门户网站使用cookies，用于维护状态

4 个组成部分

在 HTTP 响应报文中有一个 cookie 的首部行
在 HTTP 请求报文含有一个 cookie 的首部行
在用户段系统中保留有一个 cookie 文件，由用户的浏览器管理
在 Web 站点有一个后端数据库
通过维护 cookie 使得 HTTP 这一无状态服务能够维护状态

Cookies 的作用

用户验证
购物车
推荐
用户状态 (Web Email)

如何维持状态

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

Cookies 与隐私

Cookies 允许站点知道许多关于用户的信息
可能将这些信息卖给第三方
使用重定向和 cookie 的搜索引擎还能知道用户更多信息

• 如通过某个用户在大量站点上的行为，了解其个人浏览方式的大致模式 (互联网画像)

广告公司从站点获得信息

Web 缓存(代理服务器)

目标：不访问原始服务器，就满足客户的请求
用户设置浏览器：通过缓存访问 Web
缓存既是客户端又是服务器
通常缓存由 ISP 安装：大学、公司、居民区 ISP

缓存实现的方式

浏览器将所有的 HTTP 请求发给缓存

• 在缓存中的对象：缓存直接返回对象 (本地访问)
• 如对象不在缓存，缓存请求原始服务器，然后再将对象返回客户端 (远程访问)

Web 缓存的优势

降低客户端的请求响应时间
可以大大减少一个机构内部网络与 Internet 接入链路上的流量
互联网大量采用缓存：可以使较弱的 ICP 也能有效提供内容

条件 GET 方法

目标：如果缓存器中的对象拷贝是最新的，就不要发送对象
缓存器：在 HTTP 请求中指定缓存拷贝的日期：If-modified-since: <date>
服务器：如果缓存拷贝不陈旧，则响应报文没包含对象：HTTP/1.0 304 Not Modified

FTP

FTP：文件传输协议

向远程主机上传输文件或从远程主机接收文件
客户/服务器模式

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

FTP：RFC 959
FTP 服务器：端口号为 21

控制连接与数据连接分开

FTP 客户端与 FTP 服务器通过端口 21 联系，并使用 TCP 为传输协议
客户端通过控制连接获得身份确认
客户端通过控制连接非让送命令浏览远程目录
收到一个文件传输命令时，服务器打开一个到客户端的数据连接
一个文件传输完成后，服务器关闭连接

服务器打开第二个 TCP 数据连接用来传输另一个文件
控制连接：带外 (out of band) 传送
FTP 服务器维护用户的状态信息：当前路径、用户账户与控制连接对应 (有状态)

FTP 命令、响应

命令样例：

• 在控制连接上以 ASCII 文本方式传送
• USER username
• PASS password
• LIST：请服务器返回远程主机当前目录的文件列表
• RETR filename：从远程主机的当年目录检索文件 (gets)，下载
• STOR filename：向远程主机的当前目录存放文件 (puts)，上载

上和下的概念以客户端为准

返回码样例：

• 状态码和状态信息 (同 HTTP)
• 331 username OK, password required
• 125 data connection already open; transfer starting
• 425 Can’t open data connection
• 452 Error writing file

Email

电子邮件

三个主要组成部分：

• 用户代理
• 邮件服务器
• 简单邮件传输协议：SMTP

用户代理

又名邮件阅读器
撰写、编辑和阅读邮件
如 outlook、foxmail
输出和输入邮件保存在服务器上

邮件服务器

邮箱中管理和维护发送给用户的邮件
输出报文队列保持待发送邮件报文
邮件服务器之间的 SMTP 协议：发送 email 报文

• 客户：发送方邮件服务器
• 服务器：接收方邮件服务器

SMTP [RFC 2821]

使用 TCP 在客户端和服务器之间传送报文，端口号为 25
直接传输：从发送方服务器到接收方服务器
传输的三个阶段

• 握手
• 传输报文
• 关闭

命令/响应交互

• 命令：ASCII 文本
• 响应：状态码和状态信息

报文必须为 7 位 ASCII 码：所有内容要在 ASCII 码范围之内

SMTP 小结

• 使用持久连接
• 要求报文 (首部和主题) 为 7 位 ASCII 编码
• SMTP 服务器使用 CRLF.CRLF 决定报文的尾部

与 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：传送放到接收方的邮件服务器
邮件访问协议：从服务器访问邮件

• POP
  • 邮局访问协议 (Post Office Protocol) [RFC 1939]
  • 用户身份确认 (代理<–>服务器) 并下载
• IMAP
  • Internet 邮件访问协议 (Internet Mail Access Protocol) [RFC 1730]
  • 更多特性 (更复杂)
  • 在服务器上处理存储的报文
• HTTP
  • Hotmail，Yahoo！Mail 等
  • 方便

前两跳是推，最后一跳是拉

POP3

用户确认阶段

• 客户端命令：
  • user：申明用户名
  • pass：口令
  明文
• 服务器响应：
  • +OK
  • -ERR

事务处理阶段(客户端)：

• list：报文号列表
• retr：根据报文号检索报文
• dele：删除
• quit

“下载并删除” 模式：如果改变客户机，不能阅读邮件
“下载并保留” 模式：不同客户机上为报文的拷贝
POP3 在会话中是无状态的，不支持远程维护，本地管理文件夹

IMAP

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

DNS (Domain Name System)

必要性

IP 地址主要用于标识主机、路由器，但不便于人类记忆和使用
人类用户提供要访问机器的“字符串”名称，由 DNS 负责转换成二进制的网络地址
DNS 主要提供域名和 IP 地址之间的转换
分层的命名，分布式的解析

DNS 总体思路

分层的、基于域的命名机制
若干分布式的数据库完成名字到 IP 地址的转换
运行在 UDP 之上端口号为 53 的应用服务
核心的 Internet 功能，但以应用层协议实现：在网络边缘处理复杂性

DNS 主要目的

实现主机名 - IP 地址的转换 (name/IP translate)
主机别名 (便于用户访问) 到规范名字 (便于管理) 的转换：Host aliasing
邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing
负载均衡：Load Distribution

DNS 域名结构

一个层次命名设备会有很多重名
DNS 采用层次树状结构的命名方法
Internet 被划分为几百个顶级域 (top level domains)

• 通用的 (generic)
  .com, .edu, .gov, .int, .mil, .net, .org, .firm, .hsop, .web, .arts, .rec
• 国家的 (countries)
  .cn, .us, .nl, .jp

每个(子)域下面可划分为若干子域 (subdomains)
树叶是主机

DNS 名字空间 (The DNS Name Space)

域名

• 从本域往上，直到树根
• 中间使用 “.” 间隔不同级别
• 域的域名：可以用于表示一个域
• 主机的域名：一个域上的一个主机

域名的管理

• 一个域管理其下的子域
• 创建一个新的域，必须征得它所属的域的同意

域域物理网络无关

• 域遵从组织界限，而不是物理网络
  • 一个域的主机可以不在一个网络
  • 一个网络的主机不一定在一个域
• 域的划分是逻辑的，而不是物理的

名字服务器 (Name Server)

一个名字服务器的问题

• 可靠性：单点故障
• 扩展性：通信容量
• 维护：远距离的集中式数据库

区域 (zone)

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

权威 DNS 服务器

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

TLD 服务器

顶级域 (TLD) 服务器
负责顶级域名 (如com, org, net,edu 和 gov) 和所有国家级的顶级域名 (如 cn, uk, fr, ca, jp, de 等)

• Network solutions 公司维护 com 服务器
• 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

• Type = A
  • Name 为主机
  • Value 为 IP 地址
• Type = CNAME
  • Name 为规范名字的别名
  • Value 为规范名字
• Type = NS
  • Name 为子域名 (如 foo.com)
  • Value 为该子域名的权威服务器的域名
• Type = MX
  • Value 为 name 对应的邮件服务器的名字

TTL：生存时间，决定了资源记录应当从缓存中删除的时间

DNS 大致工作过程

应用调用：解析器 (resolver)
解析器作为客户，向 Name Server 发出查询报文 (封装在 UDP 段中)
Name Server 返回响应报文 (name/ip)

本地名字服务器 (Local Name Server)

并不严格属于层次结构
每个 ISP (居民区的 ISP、公司、大学) 都有一个本地 DNS 服务器，也称为默认名字服务器
当一个主机发起一个 DNS 查询时，查询被送到其本地 DNS 服务器：起着代理的作用，将查询转发到层次结构中

名字解析过程

目标名字在 Local Name Server 中

• 查询名字在该区域内部
• 缓存 (cashing)

缓存为了性能，删除为了一致性

当本地名字服务器不能解析名字时，联系根名字服务器，顺着根 - TLD 一直找到权威名字服务器

• 递归查询
  • 名字解析负担都放在当前联络的名字服务器上
  • 问题：根服务器的负担太重
  • 解决：迭代查询 (iterated queries)

• 迭代查询
  • 根 (及各级域名) 服务器返回的不是查询结果，而是下一个 NS 的地址
  • 最后由权威名字服务器给出解析结果
  • 当前联络的服务器给出可以联系的服务器的名字
  • “我不知道这个名字，但可以向这个服务器请求”

DNS 协议、报文

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

报文首部

• 标识符 (ID)：16 位；实现流水线查询
• flags
  • 查询/应答
  • 希望递归
  • 递归可用
  • 应答为权威

提高性能：缓存

一旦名字服务器学到一个映射，就将该映射缓存起来
跟服务器通常都在本地服务器中缓存着，使得根服务器不用经常被访问
目的：提高效率
可能存在的问题：如果情况变化，缓存结果和权威资源记录不一致
解决方案：TTL，默认 2 天

维护问题：新增一个域

在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字 -> 地址

攻击 DNS

总体而言，DNS 比较健壮

DDoS 攻击

对根服务器进行流量轰炸攻击：发送大量 ping

• 没有成功
• 原因 1：根目录服务器配置了流量过滤器，防火墙
• 原因 2：Local DNS 服务器缓存了 TLD 服务器的 IP 地址，因此无需查询根服务器

向 TLD 服务器流量轰炸攻击：发送大量查询

• 可能更危险
• 效果一般，大部分 DNS 缓存了 TLD

重定向攻击

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

P2P 应用

纯 P2P 架构

没有(或极少)一直运行的服务器
任意端系统都可以直接通信
利用 Peer 的服务能力
Peer 节点间歇上网，每次 IP 地址都有可能变化

例子：

• 文件分发 (BitTorrent)
• 流媒体 (KanKan)
• VoIP (Skype)

文件分发：C/S vs P2P

Peer 节点上下载能力是有限的
C/S 模式

• 服务器传输：都是由服务器发送给 Peer，服务器必须顺序传输 (上载) N 个文件拷贝
  • 发送一个 copy：F/u_s
  • 发送 N 个 copy：NF/u_s
• 客户端：每个客户端必须下载一个文件拷贝
  • d_min：客户端最小的下载速率
  • 下载带宽最小的客户端下载的时间：F/d_min

采用 C-S 方法将一个 F 大小的文件分发给 N 个客户端耗时 D_c-s ≥ max
{NF/u_s, F/d_min}

• 随着客户端的数目 N 越多，时间越长 (线性增加)

P2P 模式

• 服务器传输：最少需要上载一份拷贝
  • 发送一个拷贝的时间：F/u_s
• 客户端：每个客户端必须下载一个拷贝
  • 最小下载带宽客户单耗时：F/d_min
• 客户端：所有客户端总体下载量 NF
  • 最大上载带宽是 u_s + Σu_i
  • 除了服务器可以上载，其它所有的 Peer 节点都可以上载

采用 P2P 方法将一个 F 大小的文件分发给 N 个客户端耗时：D_P2P ≥ max
{F/u_s, F/d_min, NF/(u_s + Σu_i)}

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

P2P 性能更好，可扩展性更强

P2P 的管理模式

P2P 文件共享的问题

问题：

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

可能的方案：

• 集中
• 分散
• 半分散

非结构化 P2P

节点与节点之间是任意构建起来的 overlay

集中式目录

• 当对等方连接时，告诉中心服务器：IP 地址、内容；peer A 可查询资源；peer A 从 peer B 处请求文件；下线时告诉中心服务器
• 存在的问题：文件传输是分散的，而定位内容则是高度集中的；单点故障，如中心服务器出现问题；性能瓶颈；侵犯版权

完全分布式

• 没有中心服务器
• 全开放文件共享协议
• 查询泛洪：Gnutella；许多 Gnutella 客户端实现了 Gnutella 协议，类似 HTTP 有许多的浏览器
• 覆盖网络：图
  • 如果 X 和 Y 之间有一个 TCP 连接，则二者之间存在一条边
  • 所有活动的对等方和边就是覆盖网络
  • 边并不是物理链路
  • 给定一个对等方，通常所连接的节点少于 10 个
• Gnutella 协议
  • 在已有的 TCP 连接上发送查询报文
  • 对等方转发查询报文
  • 以反方向返回查询命中报文
• 可扩展性
  • 限制范围的泛洪查询
  • 设置 ttl
  • 让中转节点记忆查询，下次返回不再发送查询
• 对等方加入(Gnutella)
  • 对等方 X 必须首先发现某些已经在覆盖网络中的其它对等方：使用可用对等方列表；自己维持一张对等方列表(经常开机的对等放的 IP)；联系维持列表的 Gnutella 站点
  • X 接着试图与该列表上的对等方建立 TCP 连接，直到与某个对等方 Y 建立连接
  • X 向 Y 发送一个 Ping 报文，Y 转发该 Ping 报文
  • 所有收到 Ping 报文的对等方以 Pong 报文响应：IP 地址、共享文件的数量及总字节数
  • X 收到许多 Pong 报文，然后它能建立其它 TCP 连接

混合体：利用不匀称性 (KaZaA)

• 每个对等方要么是一个组长，要么隶属于一个组长
  • 对等方与其组长之间有 TCP 连接
  • 组长对之间有 TCP 连接
• 组长跟踪器所有的孩子的内容
• 组长与其他组长联系
  • 转发查询到其他组长
  • 获得其他组长的数据拷贝

• KaZaA：查询
  • 每个文件有一个散列标识码和一个描述符
  • 客户端向其组长发送关键字查询
  • 组长用匹配进行响应：对每个匹配元数据、散列标识码和 IP 地址
  • 如果组长将查询转发给其他组长，其他组长也以匹配进行响应
  • 客户端选择要下载的文件：向拥有文件的对等方发送一个带散列标识码的 HTTP 请求

BitTorrent

• 文件被分为一个个块 256 KB；每个节点都有一张 Bit map；节点之间定期交互
• 网络中的这些 peers 发送接收文件块，相互服务
• tracker：跟踪 torrent 中参与节点
• Torrent (洪流)：节点的组，之间交换文件块
• Peer 加入 torrent
  • 一开始没有块，但是将会通过其他节点处累积文件块
  • 向跟踪服务器注册，获得 peer 节点列表，和部分 peer 节点构成邻居关系 (“
    连接”)
• 当 peer 下载时，该 peer 可以同时向其他节点提供上线服务
• peer 可能会变换用于交换的块的 peer 节点
• 扰动 churn：peer 节点可能会上线或者下线，整个洪流具有动态性
• 一旦一个 peer 拥有整个文件，他会 (自私的) 离开或者保留 (利他主义) 在 torrent 中
• 请求块
  • 在任何给定时间，不同 peer 节点拥有一个文件块的子集
  • 周期性的，某节点向邻居询问他们用有哪些块的信息
  • 某节点向 peer 节点请求它希望的块、稀缺的块
• 发送块：一报还一报 tit-for-tat
  • 某节点向 4 个 peer 发送块，这些块向它自己提供最大带宽的服务：其他 peer 被该节点阻塞，将不会从这一节点获得服务；每 10 秒重新评估一次 (前 4 位)
  • 每 30 秒随机选择其它 peer 节点，向这个节点发送块：“优化疏通”这个节点；新选择的节点可以加入这个 top 4

DHT (结构化) P2P

peer 节点之间构成环、树等关系的有序拓扑 overlay
DHT: Distributed Hash Table
节点 IP 和文件都有一个唯一 Hash 值用以标识
内容存在哪个节点是约定好的，副本数量不需要很多就可以很快地找到目标内容

CDN

视频流化服务和 CDN：上下文

视频流量占据互联网大部分带宽
挑战

• 规模性：如何服务着 ~ 1 B 用户；单个超级服务器无法提供服务
• 异构性：不同用户拥有不同的能力；如有线接入和移动用户、带宽丰富和受限用户

解决方案：分布式的、应用层面的基础设施

多媒体：视频

视频：固定速率显示的图像序列
网络视频特点：

• 高码率：> 10 x 于音频，搞得网络带宽需求
• 可以被压缩
• 90 % 以上的网络流量是视频

数字化图像：像素的阵列，每个像素被若干 bits 标识
编码：使用图像内和图像间的荣誉来降低编码的比特数

• 空间冗余 (图像内)
  • 如一张图中某颜色大面积重复，不是发送 N 个相同的颜色值，仅仅发送 2 个值：颜色和重复的个数 N
• 时间冗余 (相邻的图像间)
  • 如不是发送第 i+1 帧的全部编码，而仅发送和第 i 帧差别的地方
• CBR (Constant Bit Rate)：以固定速率编码
• VBR (Variable Bit Rate)：视频编码速率随时间的变化而变化

多媒体流化服务：DASH

DASH: Dynamic, Adaptive Streaming over HTTP
服务器

• 将视频分割成多个块
• 每个块独立存储，编码于不同码率 (8 ~ 10 种)
• *告示文件 (manifest file)*：提供不同块的 URL

客户端

• 先获取告示文件
• 周期性地测量服务器到客户端的带宽
• 查询告示文件，在一个时刻请求一个块，HTTP 头部指定字节范围
  • 如果带宽足够，选择最大码率的视频块
  • 会话中的不同时刻，可以切换请求不同的编码块，取决于当时的可用带宽

智能客户端：客户端自适应决定

• 什么时候去请求块：不至于缓存挨饿或溢出
• 请求什么编码速率的视频块：档带宽够用时，请求高质量的视频块
• 那里去请求块：可以向离自己近的服务器发送 URL，或者向高可用带宽的服务器请求

Content Distribution Networks

挑战：服务器如何通过网络向上百万用户同时流化视频内容(上百万视频内容)？

单个的、大的超级服务中心：mega-server

服务器到客户端路径上跳数过多，瓶颈链路的带宽小导致停顿
“二八定律”决定了网络同时充斥着同一个视频的多个拷贝，效率低、付费高、带宽浪费、效果差
单点故障，性能瓶颈
周边网络的拥塞会造成影响
评述：实现相当简单，但这个方法不可扩展

CDN

通过 CDN，全网部署缓存节点，存储服务内容，就近位用户提供服务，提高用户体验

enter deep：将 CDN 服务器深入到许多接入网

• 更接近用户，服务器数量多，离用户近，但管理困难
• Akamai，1700 个位置

bring home：部署在少数 (10 个左右) 关键位置，如将服务器簇安装于 POP 附近 (离若干 1st ISP POP 较近)

• 采用租用线路将服务器簇连接起来
• 跳数稍微多一些，服务器少
• Limelight

Content Distribution Networks (CDNs) 的应用过程：

• 部署：在 CDN 节点中存储内容的多个拷贝
• 用户从 CDN 中请求内容：重定向到最近的拷贝，请求内容；如果网络路径拥塞，可能选择不同的拷贝

减少跳数、增加拷贝，让内容靠近用户，总体相当于加速服务

over the top
CDN 运行在应用层、网络边缘
互联网络主机-主机之间的通信作为一种服务向用户提供

OTT 挑战：在拥塞的互联网上复制内容

？从哪个 CDN 节点中获取内容
？用户在网络拥塞时的行为
？在哪些 CDN 节点中存储什么内容 (内容、节点部署策略的问题)

TCP 套接字编程

Socket 编程

应用进程使用传输层提供的服务才能交换报文，实现应用协议，实现应用
TCP/IP：应用进程使用 Socket API 访问传输服务
地点：界面上的 SAP(socket)
方式：Socket API
socket：分布式应用进程之间的门，传输层协议提供的端到端服务接口

2 种传输层服务的 socket 类型：

• TCP：可靠的、字节流服务 (原原本本，不错不重复不丢失，保证按照流但不保证界限)
• UDP：不可靠 (数据 UDP 数据报) 服务

TCP 套接字编程

套接字：应用进程与端到端传输协议 (TCP 或 UDP) 之间的门户
TCP 服务：从一个进程向另一个进程可靠地传输字节流
类似文件句柄

TCP 连接建立流程

服务器首先运行，等待连接建立：

1. 服务器进程必须先于运行状态

• 创建欢迎 socket
• 和本地端口捆绑
• 在欢迎 socket 上阻塞式等待接收用户的连接

创建、捆绑、等待等都是 socket 函数

客户端主动和服务器建立连接：

1. 创建客户端本地套接字 (隐式捆绑到本地 port)

• 指定服务器进程的 IP 地址和端口号，与服务器进程连接

3. 当与客户端连接请求到来时，服务器接受来自客户端的请求，解除阻塞式等待，返回一个新的 socket (与欢迎 socket 不一样)，与客户端通信

• 允许服务器与多个客户端通信
• 使用源 IP 和源端口来区分不同的客户端

4. 连接 API 调用有效时，客户端 P 与服务器建立了 TCP 连接

从应用进程的角度：TCP 在客户端和服务器进程之间提供了可靠的、字节流 (管道) 服务

TCP socket 编程 C/S 模式应用样例：大小写转换

1. 客户端从标准输入装置读取一行字符，发送给服务器
2. 服务器从 socket 读取字符
3. 服务器将字符转换成大写，然后返回给客户端
4. 客户端从 socket 中读取一行字符，然后打印出来

实际上，这描述了 C-S 之间交互的动作次序

数据结构 sockaddr_in

IP 地址和 port 捆绑关系的数据结构 (标识进程的端节点)

struct sockaddr_in{
  short sin_family; //AF_INET
  u_short sin_port; //port  
  struct in_addr sin_addr; //IP address, unsigned long  
  char sin_zero[8]; //align
}

数据结构 hostent

域名和 IP 地址的数据结构

struct hostent{
  char *h_name;
  char **h_aliases;
  int h_addrtype;
  int h_length; //地址长度  
  char **h_addr_list;  
  #define h_addr h_addr_list[0];
}

作为调用域名解析函数时的参数
返回后，将 IP 地址拷贝到 sockaddr_in 的 IP 地址部分

C/S socket 交互：TCP

例：客户端 TCP

例：服务器 TCP

UDP 套接字编程

UDP Socket 编程

UDP：在客户端和服务器之间没有连接

• 没有握手
• 发送端在每一个报文中明确指定目标的 IP 地址和端口号
• 服务器必须从收到的分组中提取出发送端的 IP 地址和端口号

UDP 传送的数据可能乱序也可能丢失
进程视角看 UDP 服务：UDP 位客户端和服务器提供不可靠的字节组传送服务

Client/server socket 交互：UDP

C 客户端 UDP 代码

C 服务器 UDP 代码