计算机网络(自顶向下方法)-应用层

1.应用层协议原理

2.1 应用层协议原理

一些网络应用的例子

 E-mail
 Web
 文本消息
 远程登录
 P2P文件共享
 即时通信
 多用户网络游戏
 流媒体(YouTube, Hulu, Netflix)

网络应用的体系结构

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

进程通信

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

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

TCP之上的套接字（socket）

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

UDP之上的套接字（socket）

套接字（Socket）

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

应用层协议

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

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

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

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

Internet 传输层提供的服务

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

Q: 为什么要有 UDP?

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

安全TCP

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

2.2 Web and HTTP

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

HTTP概况

HTTP连接

非持久HTTP
 最多只有一个对象在TCP连接上发送
 下载多个对象需要多个TCP连接
 HTTP/1.0使用非持久连接
持久HTTP
 多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输
 HTTP/1.1 默认使用持久连接

响应时间模型

HTTP请求报文

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

用户-服务器状态：cookies

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

1. 在HTTP响应报文中有一个cookie的首部行
2. 在HTTP请求报文含有一个cookie的首部行
3. 在用户端系统中保留有一个cookie文件，由用户的浏览器管理
4. 在Web站点有一个后端数据库
   例子：
    Susan总是用同一个PC使 用Internet Explore上 网 她第一次访问了一个使
   用了Cookie的电子商务网站
    当最初的HTTP请求到达服务器时，该Web站点产生一个唯一的ID，并以此作为索引在它的后端数据库中产生一个项

Web缓存 (代理服务器)

 缓存既是客户端又是服务器
 通常缓存是由ISP安 装 (大学、公司、居民区ISP)
为什么要使用Web缓存？
 降低客户端的请求响应时间
 可以大大减少一个机构内部网络与Internent接入链路上的流量
 互联网大量采用了缓存：可以使较弱的ICP也能够有效提供内容

解决缓存不一致的问题

2.3 FTP

FTP: 文件传输协议

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

2.4 Email

EMail: SMTP [RFC 2821]

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

简单的SMTP交互
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: [e-mail]
S: 250 [e-mail]… Sender ok
C: RCPT TO: [e-mail]
S: 250 [e-mail] … Recipient ok
C: DATA
S: 354 Enter mail, end with “.” on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP：总结

 SMTP使用持久连接
 SMTP要求报文（首部和主体）为7位ASCII编 码 SMTP服务器使用
CRLF.CRLF决定报文的尾部
HTTP比较：
 HTTP：拉（pull）  SMTP：推（push）  二者都是ASCII形式的命令/
响应交互、状态码
 HTTP：每个对象封装在各自的响应报文中
 SMTP：多个对象包含在一个报文中

POP3

IMAP

2.5 DNS

DNS(Domain Name System)
 DNS的必要性
 IP地址标识主机、路由器
 但IP地址不好记忆，不便人类使用(没有意义)  人类一般倾向于使用一些有意义的字符串来标识Internet上的设备
例如：[e-mail] 所在的邮件服务器
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)
 树叶是主机

从本域往上，直到树根
中间使用“.”间隔不同的级别
例如：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)
 名字服务器允许被放置在区域之外，以保障可靠性

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工作流程

本地名字服务器（Local Name Server）

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

DNS协议、报文

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

攻击DNS

DDoS 攻击
 对根服务器进行流量轰炸攻击：发送大量ping
 没有成功
 原因１：根目录服务器配置了流量过滤器，防火墙
 原因２：Local DNS 服务器
缓存了TLD服务器的IP地址, 因此无需查询根服务器
 **向TLD服务器流量轰炸攻击：发送大量查询 **
 可能更危险
 效果一般，大部分DNS缓存了TLD
重定向攻击
 中间人攻击
 截获查询，伪造回答，从而攻击某个（DNS回答指定的IP）站点
 DNS中毒
 发送伪造的应答给DNS服务器，希望它能够缓存这个虚假的结果
 技术上较困难：分布式截获和伪造
利用DNS基础设施进行DDoS
 伪造某个IP进行查询， 攻击这个目标IP
 查询放大，响应报文比查询报文大
 效果有限

2.6 P2P 应用

纯P2P架构

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

文件分发: C/S vs P2P

问题: 从一台服务器分发文件（大小F）到N个peer需要多少时间？
 Peer节点上下载能力是有限的资源

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

P2P文件分发： BitTorrent

 文件被分为一个个块256KB
 网络中的这些peers发送接收文件块，相互服务

BitTorrent: 请求，发送文件块

请求块：
 在任何给定时间，不同peer节点拥有一个文件块的子集
 周期性的，Alice节点向邻居询问他们拥有哪些块的信息
 Alice向peer节点请求它希望的块，稀缺的块
发送块：一报还一报tit-for-tat
 Alice向4个peer发送块，这些块向它自己提供最大带宽的服务
 其他peer被Alice阻塞 (将不会从Alice处获得服务)
 每10秒重新评估一次：前4位
 每个30秒：随机选择其他peer节点，向这个节点发送块
 “优化疏通” 这个节点
 新选择的节点可以加入这个top 4

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：集中式目录中存在的问题
 单点故障
 性能瓶颈
 侵犯版权
文件传输是分散的，而定位内容则是高度集中的

查询洪泛：Gnutella

 全分布式 没有中心服务器
 开放文件共享协议
 许多Gnutella客户端实现了Gnutella协议
 类似HTTP有许多的浏览器
覆盖网络：图
 如果X和Y之间有一个TCP连接，则二者之间存在一条边
 所有活动的对等方和边就是覆盖网络
 边并不是物理链路
 给定一个对等方，通常所连接的节点少于10个

Gnutella：对等方加入

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

利用不匀称性：KaZaA

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

Kazaa小技巧
 请求排队
 限制并行上载的数量
 确保每个被传输的文件从上载节点接收一定量的带宽
 激励优先权
 鼓励用户上载文件
 加强系统的扩展性
 并行下载
 从多个对等方下载同一个文件的不同部分
 HTTP的字节范围首部
 更快地检索一个文件

2.7 CDN

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

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

多媒体: 视频

CBR: (constant bit rate): 以固定速率编码
 VBR: (variable bit rate): 视频编码速率随时间的变化而变化
 例子:
 MPEG 1 (CD-ROM) 1.5 Mbps
 MPEG2 (DVD) 3-6 Mbps
 MPEG4 (often used in Internet, < 1 Mbps)

存储视频的流化服务：

多媒体流化服务：DASH

 DASH: Dynamic, Adaptive Streaming over HTTP
 服务器:
 将视频文件分割成多个块
 每个块独立存储，编码于不同码率（8-10种）
 告示文件（manifest file）: 提供不同块的URL
 客户端:
 先获取告示文件
 周期性地测量服务器到客户端的带宽
 查询告示文件,在一个时刻请求一个块，HTTP头部指定字节范围
如果带宽足够，选择最大码率的视频块
会话中的不同时刻，可以切换请求不同的编码块 (取决于当时的可用带宽)

“智能”客户端: 客户端自适应决定
 什么时候去请求块 (不至于缓存挨饿，或者溢出)
 请求什么编码速率的视频块 (当带宽够用时，请求高质量的视频块)
 哪里去请求块 (可以向离自己近的服务器发送URL，或者向高可用带宽的服务器请求)

Content Distribution Networks

 挑战: 服务器如何通过网络向上百万用户同时流化视频内容 (上百万视频内容)?
 选择1: 单个的、大的超级服务中心“mega-server”
 服务器到客户端路径上跳数较多，瓶颈链路的带宽小导致停顿
 “二八规律”决定了网络同时充斥着同一个视频的多个拷贝，效率低（付费高、带宽浪费、效果差）
 单点故障点，性能瓶颈
 周边网络的拥塞
评述：相当简单，但是这个方法不可扩展

选项2: 通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验
 enter deep: 将CDN服务器深入到许多接入网
更接近用户，数量多，离用户近，管理困难
Akamai, 1700个位置
 bring home: 部署在少数(10个左右)关键位置，如将服务器簇安装于POP附近（离若干1stISP POP较近）
采用租用线路将服务器簇连接起来
Limelight

Content Distribution Networks (CDNs)

 CDN: 在CDN节点中存储内容的多个拷贝
• e.g. Netflix stores copies of MadMen
 用户从CDN中请求内容
• 重定向到最近的拷贝，请求内容
• 如果网络路径拥塞，可能选择不同的拷贝

案例学习: Netflix

2.8 Socket编程

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

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

TCP 套接字（Socket ）编程

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

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客户端(TCP)

UDP 套接字编程

UDP: 在客户端和服务器之间没有连接
• 没有握手
• 发送端在每一个报文中明确地指定目标的IP地址和端口号
• 服务器必须从收到的分组中提取出发送端的IP地址和端口号
UDP: 传送的数据可能乱序，也可能丢失
进程视角看UDP服务
UDP 为客户端和服务器提供不可靠的字节组的传送服务

样例: C客户端 (UDP)