二、应用层

应用层协议原理

络应用的原理：

络应用协议的概念和实现方面

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

络应用的实例：

互联 流行的应用层协议

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

编程：

络应用程序

• Socket API

创建一个新的 络应用

编程

• 在不同的端系统上运行
• 通过 络基础设施提供的服务，应用进程彼此通信

络核心中没有应用层软件

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

络应用体系结构

• 客户-服务器模式（C/S：client/server）
• 对等模式（P2P：Peer To Peer）
• 混合体：客户-服务器和对等体系结构

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

服务器

• 一直运行
• 固定的IP地址和周知的端口 （约定）
• 扩展性：服务器场（数据中心进行扩展、扩展性差、可靠性差）

客户端

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

对等体（P2P）体系结构

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

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

Napster

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

即时通信

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

进程通信

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

客户端进程

发起通信的进程

服务器进程

等待连接的进程

• 在同一主机内，使用进程间通信机制通信（操作系统定义）
• 不同主机，通过交换** 文（Message）**来通信（使用OS提供的通信服务；按照应用协议交换 文，借助传输层提供的服务）
• 注意：P2P架构应用也有客户端进程和服务器进程之分

进程标示和寻址问题

进程为了接受 文，必须有一个标识，即：SAP（发送也需要）

• 主机：唯一的32位IP地址
• 所采用的传输层协议：TCP or UDP
• 端口 （Port Numbers）

一些知名的端口

HTTP：TCP 80

Mail：TCP 25

FTP：TCP 2

一个进程：用IP+port标识 端节点

本质上，一对主机进程之间的通信由两个端节点构成

传输层-应用层提供服务是如何

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

需要穿过层间的信息

套接字（Socket）

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

套接字等同于门户

HTTP概况

HTTP：超文本传输协议

• web应用层协议
• 客户端/服务模式（客户端请求、接收和显示Web对象；服务器对请求进行响应）

HTTP 1.0：RFC 1945

HTTP 1.1：RFC 2068

使用TCP

• 客户端发起一个与服务器的TCP连接（建立套接字），端口 为80
• 服务器接收客户端的TCP连接
• 在浏览器与Web服务器交换HTTP 文
• TCP连接关闭

HTTP是无状态的

• 服务器并不维护关于客户的任何信息

维护状态的协议很复杂！

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

HTTP连接

非持久的HTTP

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

持久HTTP

• 多个对象可以在一个TCP连接上传输
• HTTP/1.1默认使用持久连接

两种HTTP连接的特点

非持久HTTP连接的缺点

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

持久HTTP优点

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

非流水方式

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

流水方式

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

HTTP 文

两种类型：请求、响应

HTTP请求 文（ASCII，人能阅读）

提交表单输入

POST方式

包含在实体主体（entity body）中的输入被提交到服务器

URL方式

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

方法类型

HTTP响应状态码

Cookies能带来什么

• 用户验证
• 购物车
• 推荐
• 用户状态

如何维持状态

协议端节点：在多个事务上，发送端和接收端维持状态

cookies：http 文携带状态信息

Cookies与隐私

• Cookies允许站点知道许多关于用户的信息
• 可能将它知道的东西卖给第三方
• 使用重定向和cookie的搜索引擎还能知道用户更多的信息
• 广告公司从站点获得信息

Web缓存（代理服务器）

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

• 用户设置浏览器：通过缓存访问Web
• 浏览器将所有的HTTP请求发给缓存（如果缓存在，缓存直接返回对象；如果不在，缓存请求原始服务器，然后再将对象返回给客户端）

FTP

文件传输协议

• 向远程主机上传输文件或者接收文件
• 客户/服务器模式（客户端：发起传输的一方；服务端：远程主机）
• ftp：RFC 959
• ftp：端口 为21

FTP命令、响应

邮件服务器

• 邮箱中管理和维护发送给用户的邮件
• 输出 文队列保持待发送邮件的 文
• 邮件服务武器之间的SMTP协议：发送Email 文（客户：发送方邮件服务器；服务器：接收端邮件服务）

SMTP【RFC 2821】

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

邮件 文格式

SMTP：交换Email 文的协议

RFC 822：文本 文的标准

• 首部行（To、From、Subject）
• 主体（ 文，只能是ASCII码字符）

邮件访问协议

DNS总体思路和目标

DNS主要思路

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

DNS主要目的

• 实现主机名-IP地址的转换（name/IP translate）
• 其他目的（主机别名到规范名字的转换：Host aliasing；邮件服务器别名到邮件服务器的正规名字的转换：Mail server aliasing）
• 负载均衡：Load Distribution

DNS命名空间

DNS域名结构

域名

域与物理 络无关

名字服务器

一个名字服务器的问题

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

区域（zone）

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

RR格式

DNS大致工作过程

名字解析过程

目标名字在Local Name Server中（查询的名字在该区域内部；缓存（cashing））

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

递归查询

名字解析负担都放在当前联络的名字服务器上

问题：根服务器的负担太重（可以使用迭代查询解决）

DNS协议、 文

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

提高性能：缓存

攻击DNS

服务器传输

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

• 发送一个copy：F/Us
• 发送N个copy：NF/Us

客户端

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

速率对比

问题：单点故障、性能瓶颈、版权侵犯

完全分布式：Gnutella

• 没有中心服务器
• 开放文件共享协议
• 泛洪查询

类似于广度优先搜索，向周边peer询问查询文件，周边peer再向其周边peer询问查询，所以需要限制查询范围（限制跳跃查询次数）

Gnutella：协议

混合体：KaZaA

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

BitTorrent

每个peer在自己拥有的块数达到一个值时（不至于一个没有），它在后续请求块时将会采用稀缺优先策略，这样有利于整个结构

请求、发送块

在上载的每个大周期中会出现随机选择上载对象的小周期（利于发现更好的”合作伙伴“），其他的小周期则选择之前有过良好合作的伙伴

Tracking Server服务器维护某个文件的peer洪流

DHT（结构化）P2P

peer和peer节点之间构成环、树等结构性关系

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

CDN

视频流化服务和CDN

多媒体：视频

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

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

套接字编程数据结构（前提）

sockaddr_in

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

3、当与客户端连接请求到来

代码

Client

Server

UDP套接字编程

Socket编程

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

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

传送的数据可能乱序、也可能丢失

UDP为客户端和服务器提供了不可靠的字节组的传送服务

C/S socket交互：UDP