中科大郑烇、杨坚《计算机网络》课程 第二章笔记

第2章 应用层

2.1 应用层协议原理

网络应用的体系结构

可能的应用架构:
客户-服务器模式（C/S:client/server)
对等模式(P2P:Peer To Peer)
混合体:客户-服务器和对等体系结构

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

服务器:

• 一直运行
• 固定的IP地址和周知的端口号（约定)
• 扩展性:服务器场数据中心进行扩展扩展性差

客户端:

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

缺点 ：可拓展性差 达到一定能限（阈值），性能暴跌 可靠性差

对等体（P2P）体系结构

• (几乎）没有一直运行的服务器
• 任意端系统之间可以进行通信
• 每一个节点既是客户端又是服务器
  • 自扩展性-新peer节点带来新的
    服务能力，当然也带来新的服务请求
• 参与的主机间歇性连接且可以改变地址
  • 难以管理（缺点）
• 例子:Gnutella，迅雷

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

Napster

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

即时通信

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

进程通信

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

• 在同一个主机内，使用
  进程间通信机制通信（操作系统定义)
• 不同主机，通过**交换报文(Message）**来通信
  • 使用OS提供的通信服
    务
  • 按照应用协议交换报文
    • 借助传输层提供的服务

客户端进程：发起通信 的进程 服务器进程：等待连接 的进程

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

分布式进程通信需要解决的问题（应用进程如何使用传输层提供的服务交换报文）

 问题1：进程标示和寻址问题 (对于进程 谁发/谁收，对等层实体之间)

 问题2：传输层-应用层提供服务是如何 (上下层间)

•  位置：层间界面的SAP （TCP/IP ：socket）
•  形式：应用程序接口API （TCP/IP ：socket API）

 问题3：如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用 （本层间）

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

 编制程序，使用OS提供的API ，调用网络基础设施提 供通信服务传报文，实现应用时序等；

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

• 进程为了接收报文，必须有一个标识
  即: SAP(发送也需要标示)
  • 主机:唯一的32位IP地址
    仅仅有IP地址不能够唯一标示一个进程;在一台端系统上有很多应用进程在运行
  • 所采用的传输层协议:TCP or UDP
  • **端口号(Port Numbers) 用来区分不同的应用进程 **
• 一些知名端口号的例子:
  • HTTP: TCP 80 Mail: TCP 25 ftp: TCP 2
• 一个进程:用IP+port标示端节点
• 本质上，一对主机进程之间的通信由2个端节点构成

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

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

• 要传输的报文(对于本层来说:SDU) (SDU——未经本层封装的) （发的什么）
• 谁传的:对方的应用进程的标示:IP+TCP(UDP)端口 （谁发的）
• 传给谁:对方的应用进程的标示:对方的IP+TCP(UDP)端口号 （发给谁）

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

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

• 如果Socket API（原语）每次传输报文（穿过层间），都携带如此多的信息，太繁琐易错，不便于管理
• 用个代号标示通信的双方或者单方: socket
• 就像OS打开文件返回的句柄一样
  对句柄的操作，就是对文件的操作

TCP socket

TCP socket:

• TCP服务，两个进程之间的通信需要之前要建立连扫
  两个进程通信会持续一段时间，通信关系稳定
• 可以用一个整数表示两个应用实体之间的通信关系
  ，本地标示
• 穿过层间接口的信息量最小
• TCP socket: 源IP,源端口，目标IP，目标IP,目标

TCP socket 是一个整数（类似文件描述符）代表一个四元组（我的IP和端口号 对方的IP和端口号）
便于管理 使得穿过层间的信息量最小
是应用层和传输层的一个约定 本地会话的标识

对于使用面向连接服务(TCP）的应用而言，套接字是4元组的一个具有本地意义的标识

• 4元组: (源IP，源port，目标IP，目标port)
• 唯一的指定了一个会话（2个进程之间的会话关系)
• 应用使用这个标示，与远程的应用进程通信
• 不必在每一个报文的发送都要指定这4元组
• 就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件的目录名、文件名
• 简单，便于管理

穿过层间接口的包括 ICI 和 SDU

UDP socket

UDP socket：

• UDP服务，两个进程之间的通信需要之前无需建立连接
  每个报文都是独立传输的
  前后报文可能给不同的分布式进程
• 因此，只能用一个整数表示本应用实体的标示
  因为这个报文可能传给另外一个分布式进程·1○穿过层间接口的信息大小最小
• UDP socket:本IP,本端口
  • 但是传输报文时:必须要提供对方IP，port
  • 接收报文时:传输层需要上传对方的IP，port

对于使用无连接服务(UDP）的应用而言，套接字是2元组的一个具有本地意义的标识

• 2元组: IP，port(源端指定)
• UDP套接字指定了应用所在的一个端节点(endpoint>
• 在发送数据报时，采用创建好的本地套接字(标示ID），就不必在发送每个报文中指明自己所采用的ip和port
• 但是在发送报文时，必须要指定对方的ip和udpport(另外一个段节点)

套接字（Socket）

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

套接字<->门户

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

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

1. 定义应用层协议：报文格式，解释，时序等
2. 编制程序，通过API调用网络基础设施提供通信服务传报文，解析报文，实现应用时序等

应用层协议

定义了:运行在不同端系统上的应用进程如何相互交换报文

• 交换的报文类型:请求和应答报文
• 各种报文类型的语法:报文中的客个字段及其描述
• 字段的语义:即字段取值的含义进程何时、如何发送报文及对报文进行响应的规则

应用协议仅仅是应用的一个组成部分
Web应用:HTTP协议，web客户端，web服务器，HTML(超文本标记语言)

公开协议：  由RFC文档定义  允许互操作  如HTTP, SMTP
专用（私有）协议：  协议不公开  如：Skype

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

如何描述传输层的服务？

数据丢失率
有些应用则要求100%的可
靠数据传输（如文件)
有些应用(如音频)能容忍
一定比例以下的数据丢失

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

吞吐
一些应用(如多媒体）必须
需要最小限度的吞吐，从而使得应用能够有效运转一些应用能充分利用可供使
用的吞吐(弹性应用)

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

常见应用对传输服务的要求

Internet 传输层提供的服务

实体：实行网络协议的软件模块或硬件模块（运行中的）

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

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

UDP存在的必要性

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

Internet应用及其应用层协议和传输协议

安全TCP

TCP & UDP
 都没有加密  明文通过互联网传输 ，甚至密码

SSL 提供安全性
 在TCP上面实现，提供加密的TCP连接  私密性  数据完整性  端到端的鉴别

SSL在应用层  应用采用SSL库，SSL 库使用TCP通信

SSL socket API  应用通过API将明文交 给socket，SSL将其加 密在互联网上传输  详见第8章

Https 跑在 SSL + TCP 上

2.2 Web and HTTP

一些术语

• Web页:由一些对象组成

• 对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等

• Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接)

• 通过URL对每个对象进行引用
  访问协议，用户名，口令字，端口等；

• URL格式:

  

HTTP概况

HTTP: 超文本传输协议
 Web的应用层协议
 客户/服务器模式
 客户: 请求、接收和显示 Web对象的浏览器
 服务器: 对请求进行响应， 发送对象的Web服务器
 HTTP 1.0: RFC 1945
 HTTP 1.1: RFC 206

使用TCP:

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

HTTP是无状态的  服务器并不维护关于客户的任何信息

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

HTTP连接

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

持久HTTP  多个对象可以在一个 （在客户端和服务器 之间的）TCP连接上 传输  HTTP/1.1 默认使用 持久连接

非持久HTTP

响应时间模型

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

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

持久HTTP

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

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

非流水方式的持久HTTP：  客户端只能在收到前一个响应后 才能发出新的请求  每个引用对象花费一个RTT

流水方式的持久HTTP：  HTTP/1.1的默认模式  客户端遇到一个引用对象就立即 产生一个请求  所有引用（小）对象只花费一个RTT是可能的

HTTP请求报文

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

HTTP请求报文：通用格式

提交表单输入（向服务器提交信息）

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

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

例子
www. somesite.com/animalsearch?monkeys&banana
http: //www. baidu.com/s?wd=xx+yy+zzz&cl=3

参数：wd，cl 参数值：XX+YY+zzz，3

方法类型

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

HTTP/1.1  GET, POST, HEAD
 PUT  将实体主体中的文件上载 到URL字段规定的路径
 DELETE  删除URL字段规定的文件

HTTP响应报文

HTTP响应状态码

位于服务器→客户端的响应报文中的首行一些状态码的例子:

200 OK

• 请求成功，请求对象包含在响应报文的后续部分

301 Moved Permanently

• 请求的对象己经被永久转移了;新的URL在响应报文的Location:首部行中指定
  客户端软件自动用新的URL去获取对象

400 Bad Request

• 一个通用的差错代码，表示该请求不能被服务器解读

404 Not Found

• 请求的文档在该服务上没有找到

505 HTTP version Not supported

Trying out HTTP (client side) for yourself

用户-服务器状态：cookies

大多数主要的门户网站使 用 cookies 4个组成部分：

1) 在HTTP响应报文中有 一个cookie的首部行

2)在HTTP请求报文含有 一个cookie的首部行

3) 在用户端系统中保留有 一个cookie文件，由用户的浏览器管理

4) 在Web站点有一个后 端数据库

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

Cookies: 维护状态

Cookies能带来什么：  用户验证  购物车  推荐  用户状态 (Web e-mail)

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

Cookies与隐私：
 Cookies允许站点知道许多关于 用户的信息
 可能将它知道的东西卖给第三方
 使用重定向和cookie的搜索引 擎还能知道用户更多的信息
 如通过某个用户在大量站点 上的行为，了解其个人浏览方式的大致模式
 广告公司从站点获得信息

Web缓存 (代理服务器)

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

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

 浏览器将所有的HTTP 请求发给缓存
 在缓存中的对象：缓存 直接返回对象
 如对象不在缓存，缓存 请求原始服务器，然后 再将对象返回给客户端

 缓存既是客户端又是服务器  通常缓存是由ISP安 装 (大学、公司、居 民区ISP)

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

缓存示例

假设  平均对象大小 = 100kb  机构内浏览器对原始服务器的 平均请求率为 = 15请求/s  平均到浏览器的速率：1.5Mbps  机构内部路由器到原始服务器 再返回到路由器的的延时 （ Internet 延时）= 2s  接入链路带宽：1.54Mbps 结果  LAN的流量强度 = 15%
 接入链路上的流量强度 = 99%
 总延时 = LAN延时 + 接入延时 + Internet 延时 = ms + 分

t (queue) = I/(1 - I) * L / R
I——流量强度 L/R——一个分组的传输时间 排队延迟非常大

缓存示例：更快的接入链路

假设  平均对象大小 = 100kb  机构内浏览器对原始服务器的 平均请求率为 = 15请求/s  平均到浏览器的速率：1.5Mbps  机构内部路由器到原始服务器 再返回到路由器的的延时 （ Internet 延时）= 2s  接入链路带宽：1.54Mbps——> 154Mbps 结果  LAN的流量强度 = 15%  接入链路上的流量强度 = 99%
 总延时 = LAN延时 + 接入延时 + Internet 延时 = ms + 分 + 2s
代价: 增加了接入链路带宽（非常昂贵！）

排队延迟降低

缓存例子：安装本地缓存

假设  平均对象大小 = 100kb  机构内浏览器对原始服务器的平均 请求率为 = 15请求/s  平均到浏览器的速率：1.5Mbps  机构内部路由器到原始服务器再返回到路由器的的延时 （Internet 延 时）= 2s  接入链路带宽：1.54Mbps 结果 LAN 利用率: 15%  接入网络利用率： ？  总体延迟= ? ? How to compute link utilization, delay? 代价: web缓存(廉价!)

计算链路利用率，有缓存的延迟： 假设缓存命中率0.4  40%请求在缓存中被满足，其他60%的请求 需要被原始服务器满足  接入链路利用率:  60%的请求采用接入链路  进过接入链路到达浏览器的数据速 率 = 0.6*1.50 Mbps = .9 Mbps  利用率= 0.9/1.54 = .58  总体延迟：  = 0.6 * (从原始服务器获取对象的 延迟) +0.4 * (从缓存获取对象的延迟)
 = 0.6 (2.01) + 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命令、响应

命令样例：
 在控制连接上以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

FTP协议与HTTP协议的差别

FTP协议是有状态的，FTP协议的控制命令和数据传输分别在两个TCP上进行

2.4 EMail

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

用户代理 （客户端软件）
 又名 “邮件阅读器”
 撰写、编辑和阅读邮件
 如Outlook、Foxmail
 输出和输入邮件保存在服务器 上

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

EMail: SMTP [RFC 2821] 原理

 使用TCP在客户端和服务器之间传送报文，端口号为25
 直接传输：从发送方服务器到接收方服务器
 传输的3个阶段 握手 传输报文 关闭
 命令/响应交互
命令：ASCII文本
响应：状态码和状态信息
 报文必须为7位ASCII码 （规范传输内容）

举例：Alice给Bob发送报文

1. Alice使用用户代理撰写邮件并发送给 [email protected]
   2) Alice的用户代理将邮件发送到她的邮件服务器；邮件放在报文队列中
2. SMTP的客户端打开到Bob邮件服务器的TCP连接
   4) SMTP客户端通过TCP连接发送Alice的邮件
   5) Bob的邮件服务器将邮件放到Bob的邮箱
3. Bob调用他的用户代理阅读邮件

简单的SMTP交互

SMTP：总结

 SMTP使用持久连接
 SMTP要求报文（首部 和主体）为7位ASCII编 码
 SMTP服务器使用 CRLF.CRLF决定报文的 尾部

HTTP比较：
 HTTP：拉（pull）
 SMTP：推（push）
 二者都是ASCII形式的命令/ 响应交互、状态码
 HTTP：每个对象封装在各自的响应报文中
 SMTP：多个对象包含在一个报文中

邮件报文格式

SMTP：交换email报文的协议 RFC 822: 文本报文的标准：
 首部行：如,
 To:  From:  Subject:
 主体
 报文，只能是ASCII码字符

报文格式：多媒体扩展

 MIME：多媒体邮件扩展（multimedia mail extension）, RFC 2045, 2056
 在报文首部用额外的行申明MIME内容类型

常用Base64 对STMP的ASCII码进行拓展 传输更多内容

Base64 常用于在处理文本数据的场合，表示、传输、存储一些二进制数据，包括 MIME 的电子邮件及 XML 的一些复杂数据。**在 MIME 格式的电子邮件中，base64 可以用来将二进制的字节序列数据编码成 ASCII 字符序列构成的文本。**使用时，在传输编码方式中指定 base64。使用的字符包括大小写拉丁字母各 26 个、数字 10 个、加号 + 和斜杠 /，共 64 个字符，等号 = 用来作为后缀用途。

邮件访问协议

两推一拉

 SMTP: 传送到接收方的邮件服务器
 邮件访问协议：从服务器访问邮件 （3种方式）

1. POP3：邮局访问协议（Post Office Protocol）[RFC 1939]
    用户身份确认 (代理<–>服务器) 并下载

2. IMAP：Internet邮件访问协议（Internet Mail Access Protocol）[RFC 1730]
    更多特性和功能 (更复杂)
    在服务器上处理存储的报文

3. HTTP：Hotmail , Yahoo! Mail等
    方便

POP3协议

用户确认阶段  客户端命令：  user: 申明用户名  pass: 口令  服务器响应  +OK  -ERR
事物处理阶段 客户端：  list: 报文号列表  retr: 根据报文号检索报文  dele: 删除  quit

用户确认阶段

事物处理阶段,

POP3
 先前的例子使用 “下载 并删除”模式。
 如果改变客户机，Bob不 能阅读邮件
 “下载并保留”：不同 客户机上为报文的拷贝
 POP3在会话中是无状态的

IMAP

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

2.5 DNS

DNS(Domain Name System)

从域名到IP地址的转换（主要功能）

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）在边缘系统实现的）

 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: 根名字服务器

DNS名字空间(The DNS Name Space)

域名(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 说明是Internet网
Value 值：可以是数字，域名或ASCII串 对应的IP地址
Type 类别：资源记录的类型—见下页

DNS记录

DNS ：保存资源记录(RR)的分布式数据库
RR 格式：(name, value, type, ttl)

信息1 （叫什么）
TYPE = NS Name放的是子域的名字
Value 子域名字服务器（权威DNS服务器）的名字

信息2 （在哪）
Type = A Name放的是名字（子域的名字）
Value 对应服务器的IP地址

DNS大致工作过程

一台设备上网必备的IP信息
我的IP地址 我的子网掩码 我的local name serve 我的default getway（路由器）

​ 应用调用 解析器(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 一直找到 权威名字服务器

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

迭代查询

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

DNS协议、报文

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

提高性能：缓存

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

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

• 在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名和域名服务器的地址
  （Type = NS、 Type = A 相当于指针）
• 在新增子域的名字服务器上运行名字服务器，负责本域
  的名字解析:名字->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的记录

攻击DNS 总的说来，DNS比较健壮

DDoS 攻击
 对根服务器进行流量轰炸 攻击：发送大量ping
 没有成功
 原因１：根目录服务器配置 了流量过滤器，防火墙
 原因２：Local DNS 服务器 缓存了TLD服务器的IP地址, 因此无需查询根服务器

 向TLD服务器流量轰炸攻击 ：发送大量查询
 可能更危险
 效果一般，大部分DNS缓存 了TLD

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

流量是分布式 查询有几乎都有缓存，基本不需要根 ——> 无根也基本安全

2.6 P2P 应用

 没有（或极少）一直运行的 服务器
 任意端系统都可以直接通信
 利用peer的服务能力
 Peer节点间歇上网，每次IP 地址都有可能变化
例子:
 文件分发 (BitTorrent)
 流媒体(KanKan)
 VoIP (Skype)

文件分发: C/S vs P2P

问题: 从一台服务器分发文件（大小F）到N个peer 需要多少时间？

文件分发时间: C/S模式

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

• 发送一个copy: F/us（上载）
• 发送N个copy： NF/us （上载）

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

• dmin = 客户端最小的下载速率
• 下载带宽最小的客户端下载的 时间：F/dmin （下载）

采用C-S方法 将一个F大小的文件 分发给N个客户端耗时 Dc-s > max{NF/us（随着N线性增长 ）,F/dmin}
(瓶颈却决于服务器的性能和客户端性能的相对强弱)

文件分发时间: P2P模式

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

• 发送一个拷贝的时间：F/us （上载）

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

• 最小下载带宽客户单耗时: F/dmin（下载）

客户端: 所有客户端总体下载量NF

• 最大上载带宽是：us（服务器的） + Sui（所有客户端的） （上载）
• 除了服务器可以上载，其他所有的peer节点都可以上载

采用P2P方法 将一个F大小的文件 分发给N个客户端耗时 Dp2p > max{F/us,F/dmin,NF/(us + Sui)}

C-S 线性
P2P 非线性 性能高 可拓展性强 难管理（动态性强）

非结构化P2P 任意连接
DHT 结构化P2P 如：环形、树 节点哈希 内容哈希 按一定规律存内容

P2P文件共享

例子
 Alice在其笔记本电脑上 运行P2P客户端程序  间歇性地连接到 Internet，每次从其 ISP得到新的IP地址  请求“双截棍.MP3”  应用程序显示其他有“ 双截棍.MP3” 拷贝的对 等方

 Alice选择其中一个对等方， 如Bob.  文件从Bob’s PC传送到 Alice的笔记本上：HTTP  当Alice下载时，其他用户也 可以从Alice处下载  Alice的对等方既是一个Web 客户端，也是一个瞬时Web 服务器

所有的对等方都是服务器 = 可扩展性好！

两大问题

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

可能的方案
集中
分散
半分散

1、集中式目录

最初的“Napster”设计

1. 当对等方连接时，它告知
   中心服务器：  IP地址  内容
2. Alice查询 “双截棍 .MP3”
3. Alice从Bob处请求文件

 单点故障  性能瓶颈  侵犯版权
文件传输是分散的， 而定位内容则是高度集中的

2、查询洪泛：Gnutella（完全分布式）

 全分布式
 没有中心服务器
 开放文件共享协议
 许多Gnutella客户端 实现了Gnutella协议
 类似HTTP有许多的 浏览器

覆盖网络：图
 如果X和Y之间有一个 TCP连接，则二者之间存在一条边
 所有活动的对等方和边就是覆盖网络
 边并不是物理链路
 给定一个对等方，通常 所连接的节点少于10个

 在已有的TCP连接上发送查询报文
 对等方转发查询报文
 以反方向返回查询命中报文

泛洪查询 flooding

我的客户端向所有邻居发出查询 所有邻居的客户端向其邻居发出查询 …
拥有资源的节点通过反向的方法将查询的结果发回来

我的客户端就知道那个节点有资源——解决目录的问题——再向拥有资源的节点发出请求，得到资源

Gnutella：对等方加入（网络的建立）

1. 对等方X必须首先发现某些已经在覆盖网络中的其他对 等方：使用可用对等方列表 自己维持一张对等方列表（经常开机的对等方的IP、死党列表） 联系维持列表的Gnutella站点
2. X接着试图与该列表上的对等方建立TCP连接，直到与某个对等方Y建立连接
3. X向Y发送一个Ping报文，Y转发该Ping报文
4. 所有收到Ping报文的对等方以Pong报文响应 IP地址、共享文件的数量及总字节数
5. X收到许多Pong报文，然后它能建立其他TCP连接

3、利用不匀称性：KaZaA（混合体）

每个对等方要么是一个组长，要么隶属于一个组长

• 对等方与其组长之间有 TCP连接
• 组长对之间有TCP连接

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

组长与其他组长联系

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

KaZaA：查询

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

Kazaa小技巧

请求排队

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

激励优先权

• 鼓励用户上载文件
• 加强系统的扩展性

并行下载

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

Distributed Hash Table (DHT)

 哈希表  DHT方案  环形DHT 以及覆盖网络  Peer波动

（实际的例子）P2P文件分发： BitTorrent

 文件被分为一个个块256KB
每个节点有一个bit map（hash），用map标记是否具备，有则标识为1否则为0
 网络中的这些peers发送接收文件块，相互服务

 Peer加入torrent:
 一开始没有块（吸血鬼），但是将会通 过其他节点处累积文件块
 向跟踪服务器注册，获得 peer节点列表，和部分peer 节点构成邻居关系 (“连接 ”)
 当peer下载时，该peer可以同时向其他节点提供上载服务
 Peer可能会变换用于交换块的peer节点
 扰动churn: peer节点可能会上线或者下线
 一旦一个peer拥有整个文件（种子），它会（自私的）离开或者保留（利他主义）在torrent中

BitTorrent: 请求，发送文件块

请求块：
 在任何给定时间，不同 peer节点拥有一个文件块 的子集
 周期性的，Alice节点向 邻居询问他们拥有哪些块 的信息
 Alice向peer节点请求它 希望的块，稀缺的块（稀缺优先，对集体有利）

1、（集体提出）客户端优先请求稀缺的（稀缺优先，对集体有利）
2、（集体定的规则）优先向提供服务好的客户端服务（个人利益与集体利益绑定）
3、（造成个人遵守）客户端优先请求稀缺的 （利他等于利己）

发送块：一报还一报titfor-tat
 Alice向4个peer发送块，这些块向它自己提供最大带宽的服务
 其他peer被Alice阻塞 (将不会 从Alice处获得服务)
 每10秒重新评估（谁对它好）一次：前4位
 每个30秒：随机选择其他peer 节点，向这个节点发送块
 “优化疏通” 这个节点
 新选择的节点可以加入这个top 4

(1) Alice “优化疏通” Bob
(2) Alice 变成了Bob的前4位提供者; Bob答谢Alice
(3) Bob 变成了Alice的前4提供者

更高的上载速率： 发现更好的交易伙伴，获得更快的文件传输速率!

2.7 CDN

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

• 视频流量：占据着互联网大部分的带宽
  • Netflix, YouTube: 占据37%, 16% 的ISP下行流 量
  • ~1B YouTube 用户, ~75M Netflix用户
• 挑战：规模性-如何服务者 ~1B 用户?
  • 单个超级服务器无法提供服务（为什么）
• 挑战：异构性
  • 不同用户拥有不同的能力（例如：有线接入和移 动用户；带宽丰富和受限用户）
• 解决方案: 分布式的，应用层面的基础设施

多媒体: 视频

视频：固定速度显示的图像序 列

• e.g. 24 images/sec

网络视频特点：

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

数字化图像：像素的阵列

• 每个像素被若干bits表示

编码：使用图像内和图像间的 冗余来降低编码的比特数

• 空间冗余(图像内)
• 时间冗余(相邻的图像间)

CBR: (constant bit rate): 以固定速率编码

VBR: (variable bit rate): 视频编码速率随 时间的变化而变化

多媒体流化服务：DASH

DASH: Dynamic, Adaptive Streaming over HTTP 动态自适应

服务器:
将视频文件分割成多个块 （流化）
每个块独立存储，编码于不同码率（8-10种）
告示文件（manifest file）: 提供不同块的URL （自适应：自己选择）

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

“智能”客户端: 客户端自适应决定

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

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

选择1: 单个的、大的超级服务中心“megaserver”

​  服务器到客户端路径上跳数较多，瓶颈链路的带宽 小导致停顿
​  “二八规律”决定了网络同时充斥着同一个视频的 多个拷贝，效率低（付费高、带宽浪费、效果差）
​  单点故障点，性能瓶颈
​  周边网络的拥塞

相当简单，但是这个方法不可扩展

选项2: 通过CDN（content distribution network），全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验 （内容加速服务）

• enter deep: 将CDN服务器深入到许多接入网
  • 更接近用户，数量多，离用户近，管理困难
  • Akamai, 1700个位置
• bring home: 部署在少数(10个左右)关键位置（到用户的跳数较多），如将服务器簇安装于POP附近（离若干1stISP POP较近）
  • 采用租用线路将服务器簇连接起来
  • Limelight

CDN: 在CDN节点中存储内容的多个拷贝 让内容靠近用户
e.g. Netflix stores copies of MadMen

用户从CDN中请求内容**（先从原服务器获取告知文件manifest file，自适应选择块）**
(域名解析的重定向)重定向到最近的拷贝，请求内容
如果网络路径拥塞，可能选择不同的拷贝

互联网络主机-主机之间的通信作为一种服务向用户提供

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

OTT(互联网公司越过运营商，发展基于开放互联网的各种视频及数据服务业务)，over the top

• 从哪个CDN节点中获取内容？
• 用户在网络拥塞时的行为？
• 在哪些CDN节点中存储什么内容？

案例学习: Netflix

2.8 TCP 套接字编程

Socket编程

应用进程使用传输层提供的服务能够交换报文，实现应用协议，实现应用
TCP/IP：应用进程使用Socket API访问传输服务
地点：界面上的SAP(Socket） 方式：Socket API
目标: 学习如何构建能借助sockets进行通信的C/S应用程序

socket: 分布式应用进程之间的门，传输层协议提供的端到端服务接口

2种传输层服务的socket类型:
 TCP: 可靠的、**字节流**的服务
 UDP: 不可靠（数据UDP数据报）服务

套接字：应用进程与端到端传输协议（TCP或UDP）之间 的门户
TCP服务：从一个进程向另一个进程可靠地传输字节流

过程

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

1：服务器进程必须先处于运行状态
 创建欢迎socket
 和本地端口捆绑
 在欢迎socket上阻塞式等待接收用户的连接

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

2：创建客户端本地套接字（隐式捆绑到本地port）
 指定服务器进程的IP地址和端口号，与服务器进程连接

3 ：当与客户端连接请求到来时
服务器接受来自用户端的请求 ，解除阻塞式等待，返回一个新的socket（与欢迎socket不 一样），与客户端通信
 允许服务器与多个客户端通信
 使用源IP和源端口来区分不同的客户端

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

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

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;	//IP地址
#define h_addr h_addr_list[0];
} 

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

C/S socket 交互: TCP

系统自己默认使用了bind，自动分配

argv[1] 主机的名字 argv[2] 端口号 argv[0] 程序的名字

2.9 UDP 套接字编程

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

UDP: 传送的数据可能乱序，也可能丢失

进程视角看UDP服务 UDP 为客户端和服务器提供不可靠的字节组的传送服务

第2章：小结

 应用程序体系结构
 客户-服务器  P2P  混合

 应用程序需要的服务品质描 述:
 可靠性、带宽、延时、安全

 Internet传输层服务模式
 可靠的、面向连接的服务： TCP
 不可靠的数据报：UDP

 流行的应用层协议:
 HTTP
 FTP
 SMTP, POP, IMAP
 DNS

 Socket编程

更重要的：学习协议的知识

 应用层协议报文类型：请求/响应报文：
 客户端请求信息或服务
 服务器以数据、状态码进 行响应

 报文格式：
 首部：关于数据信息的字段
 数据：被交换的信息

 控制报文 vs. 数据报文
 带内（一个TCP传两种报文）、带外 （两个TCP）
 集中式 vs. 分散式
 无状态 vs. 维护状态
 可靠的 vs. 不可靠的报文传输
 在网络边缘处理复杂性

一个协议定义了在两个或多个通信实体之间交换报文的格式和 次序、以及就一条报文传输和接收或其他事件采取的动作