Samuel_luo。

计网——应用层

二、应用层

应用层协议原理

网络应用的原理：

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

传输层的服务模型
客户-服务器模式
对等模式（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）

需要穿过层间的信息

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

要传输的报文（对本层来说：SDU）
谁传的，对方的应用进程的标识：IP+TCP（UDP）端口号
传给谁，对方的应用进程的标识：对方的IP+TCP（UDP）端口号

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

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

层间信息的代表

如果socket API每次传输报文，都携带如此多的信息，太繁琐易错

所以，用一个代号标识通信双方或者单方：socket

TCP socket

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

socket≠端口号（socket是应用层与传输层的一个约定）

TCP之上的套接字（socket）

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

四元组：（源IP，源port，目标IP，目标port）
唯一的指定了一个会话（两个进程之间的会话关系）
应用使用这个标识，与远程的应用进程通信
简单，便于管理

层间信息代码

UDP socket

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

UDP之上的套接字（socket）

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

二元组：IP，port（源端指定）
UDP套接字指定了应用所在的一个端节点
在发送数据报时，才用创建好的本地套接字，就不必再发送每个报文中指明自己所采用的ip和port
但是在发送报文时，必须要指定对方的IP和UDP port（另一个端节点）

套接字（Socket）

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

套接字等同于门户

如何使用传输层提供的服务，实现应用进程之间的报文交换，实现应用

定义应用层协议：报文格式、解释、时序等等
编制程序，使用OS提供的API，调用网络基础设施提供通信服务传报文，实现应用失序等

应用层协议

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

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

应用协议仅仅只是应用的一个组成部分

Web应用：HTTP协议，web客户端，web服务器，HTML

公开协议：

由RFC文档定义
允许互操作
如HTTP

专用（私有）协议：

协议不公开
如Skype

如何描述传输层的服务

数据丢失率

有些应用要求100%的可靠数据传输

有些应用能容忍一定比例的数据丢失

延迟

一些应用对数据有严格的时间限制

吞吐

一些应用必须需要最小限度的吞吐，从而是的应用能够有效的运转

一些应用能充分利用可供使用的吞吐

安全性

机密性

完整性

可认证性

传输层提供的服务

TCP服务

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

UDP服务

不可靠数据传输
不提供的服务：可靠、流量控制、拥塞控制、时间带宽保证、建立连接

UDP的必要性

能区分不同的进程，IP服务不能
无需建立连接，省去了时间
不做可靠性工作
没有拥塞控制和流量控制，应用能够按照设定的速度发送数据

安全TCP

TCP&UDP

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

SSL

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

SSL在应用层

采用SSL库，SSL库使用TCP通信

SSL socket API

应用通过API将明文交给socket，SSL将其加密在互联网上传输

Web与HTTP

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

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默认使用持久连接

响应时间模型

往返时间RTT（round trip time）

一个小的分组从客户端到服务器，在回到客户端的时间

响应时间

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

2RTT + 传输时间

两种HTTP连接的特点

非持久HTTP连接的缺点

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

持久HTTP优点

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

非流水方式

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

流水方式

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

HTTP报文

两种类型：请求、响应

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

通用格式

提交表单输入

POST方式

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

URL方式

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

方法类型

HTTP响应报文

HTTP响应状态码

用户-服务器状态：cookies

4个组成部分

在HTTP响应报文中有一个cookie的首部行
在HTTP请求报文中有一个cookie的首部行
在用户端系统中保留有一个cookie文件，由用户浏览器管理
在Web站点有一个后端数据库

Cookies能带来什么

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

如何维持状态

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

cookies：http报文携带状态信息

Cookies与隐私

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

Web缓存（代理服务器）

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

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

特点

缓存既是客户端又是服务器
通常缓存是由ISP安装

为何要使用Web缓存

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

条件GET方法

FTP

文件传输协议

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

控制连接与数据连接分开

FTP客户端与FTP服务器通过端口21联系，并使用TCP为传输协议
客户端通过控制连接获得身份确认
客户端通过控制连接发送命令浏览远程目录
收到一个文件传输命令时，服务器打开一个到客户端的数据连接
一个文件传输完成后服务器关闭连接
服务器打开第二个TCP数据连接用来传输另一个文件
控制连接：**带外（out of band）**传送
FTP服务器维护用户的状态信息：当前路径、用户账户与控制连接对应（有状态）

FTP命令、响应

EMail

3个主要组成部分

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

用户代理

又名“邮件阅读器”
撰写编辑和阅读邮件
输入和输出邮件保存在服务器

邮件服务器

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

SMTP【RFC 2821】

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

总结

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

与HTTP比较

邮件报文格式

SMTP：交换Email报文的协议

RFC 822：文本报文的标准

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

多媒体扩展

MIME：多媒体邮件扩展（multimedia mail extension），RCF 2045、2056

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

邮件访问协议

POP3协议与IMAP

DNS（Domain Name System）

DNS必要性

IP地址标识主机、路由器
单IP地址不好记忆，不便人类使用（没有意义）
人类倾向于使用一些有意义的字符串来标识Internet上的设备
存在着“字符串”——IP地址的转换的必要性
用户提供要访问机器的“字符串”的名称
由DNS负责转换成为二进制的网络地址

DNS的历史

DNS总体思路和目标

DNS主要思路

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

DNS主要目的

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

DNS命名空间

DNS域名结构

域名

域名的管理

域与物理网络无关

DNS根名字服务器

名字服务器

一个名字服务器的问题

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

区域（zone）

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

TLD服务器

顶级域（TLD）服务器：负责顶级域名和所有国家级的顶级域名（Network solutions公司维护com TLD服务器；Educause公司维护edu TLD服务器）

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

资源记录（resource records）

RR格式

DNS记录

DNS大致工作过程

本地名字服务器

名字解析过程

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

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

递归查询

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

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

迭代查询

根（及各级域名）服务器返回的不是查询结果，而是下一个NS的地址

最后由权威名字服务器给出解析结果

当前联络的服务器给出可以联系服务器的名字

DNS协议、报文

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

提高性能：缓存

维护问题：新增一个域

攻击DNS

总的来说，DNS比较健壮

P2P应用

纯P2P架构

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

文件分发：C/S vs P2P

C/S模式

服务器传输

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

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

客户端

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

P2P模式

服务器传输

最少需要上载一份拷贝

发送一个拷贝的时间：F/Us

客户端

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

最小下载带宽客户单耗时：F/d_min

所有客户端总体下载量NF

最大上载带宽是：Us + Σu
除了服务器可以上载，其他所有的peer节点都可以上载

速率对比

P2P类型

非结构化P2P

peer和peer节点无序，随机的组合

文件分发

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

方案：集中、分散、半分散

集中式目录

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

完全分布式：Gnutella

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

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

Gnutella：协议

Gnutella：对等方加入

混合体：KaZaA

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

KaZaA：查询

BitTorrent

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

请求、发送块

tit-for-tat

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

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

DHT（结构化）P2P

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

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

CDN

视频流化服务和CDN

多媒体：视频

储存视频的流化服务

边下边播，下一点播放一点

多媒体流化服务：DASH

CDN（Content Distribution Networks）

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

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

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

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

CDNs

案例

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

sockaddr_in

hostent

TCP套接字编程

Socket编程

应用进程使用传输层提供的服务才能够交换报文，实现应用协议，实现应用

TCP/IP：应用进程使用Socket API访问传输服务

地点：界面上的SAP（Socket）

方式：Socket API

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

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

TCP：可靠的、字节流服务
UDP：不可靠的服务