第二章 应用层

互联网中应用层的协议最多

网络应用程序的研发要点：

写出能够分别在不同端系统运行，并通过网络相互通信的程序。

• 浏览器程序：运行在用户主机上
• Web服务器程序：运行在web服务器主机上

应用程序软件只在端系统运行，不需在网络核心设备上运行

• 网络核心设备无应用层，只有较低层（路由器只有网络层及以下，交换器只有链路层及以下，集线器只有物理层）

网络应用程序体系结构：

​ 应用程序体系结构：规定如何在各种端系统上组织应用程序，有研发者设计

• 客户机/服务器
  • 在给定的一对进程之间的通信会话场景中，发起通信的进程被表示为客户，在会话开始时等待联系的进程是服务器
  • 服务器
    • 不是单个的机器
    • 总是打开的状态
    • 为多个客户机请求提供服务
    • 永久的IP地址
  • 客户机
    • 总是打开或间歇打开
    • 向服务器发出请求
    • 具有动态的IP地址
    • 彼此之间不直接通信
• 对等（P2P）
  • 无（最少）打开的服务器
  • 任意端系统（对等方）可以直接通信
  • 对等方间歇地连接，IP地址不固定
  • 可扩展度高，但是难以管理
  • 未来面对的挑战：ISP友好，安全性，激励
• 客户机/服务器与P2P的混合

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

进程通信：

• 同一主机中两个进程间的通信：由操作系统控制（通过管道，共享内存，消息队列，信号量）
• 不同主机中进程间的通信：通过网络交换报文进行
  • 发送进程：产生报文并向网络发送
  • 接收进程：接收报文，并回送报文

套接字：

​ 同一台主机内应用层与运输层之间的接口。也叫应用程序和网络之间的应用程序接口API，是在网络上建立网络应用程序的可编程接口

应用层协议：定义了运行在不同端系统上的应用程序进程间传递报文的格式和方式。是网络应用的一部分。

• 协议三要素：语法，语义，时序
• 具体内容1.交换的报文类型
• 具体内容2.各种报文类型的语法
• 具体内容3.字段的语义

Web应用的四部分：

• HTML、Web浏览器、Web服务器程序，以及一个应用层协议HTTP(超文本传输协议)

应用层协议原理

进程通信需要解决的问题：

1. 进程标识和寻址问题
   • 进程为了接收报文，必须对进程进行标识。即SAP。所采用的传输层协议：TCP或UDP
     • 主机：唯一的32位IP地址
     • 进程：端口号
   • 一个进程用IP+port标识 端结点
   • 本质上一对主机进程之间的通信由两个端节点构成
   • 周知端口：
     • 用户代理：8080
     • Web服务进程（HTTP协议）：80
     • 邮件服务进程（SMTP协议）：25
     • FTP协议：21
     • DNS：53
     • SSH：22
     • HTTPS：443
2. 传输层-应用层提供的服务
   • 层间接口必须要携带的信息
     • 要传输的报文，SDU
     • 本方应用进程的标识
     • 对方应用进程的标识
   • 传输层实体根据信息进程TCP（UDP）报文段的封装
   • 如果每次应用层都传输完整的报文，太繁琐易错，不便于管理
     • TCP socket，一个本地标识，两个进程之间的通信需要建立连接
       • 可以用一个整数唯一标识两个应用实体之间的通信关系，四元组（两方的IP和端口）
       • 不必每个报文的发送都指定这4元组，穿过层间接口的信息量变小
     • UDP socket
       • 两个进程之间的通信无需建立连接
       • 代表本地IP和本地port，传输报文时必须提供对方IP和port
       • 每个报文都是独立传输的
       • 前后报文可能给不同的分布式进程
       • 只能用一个整数表示应用实体的表示
3. 如何使用传输层提供的服务
   • 定义应用层协议：报文格式，解释，时序等
   • 协议是运行在不同端系统上的应用进程如何相互交互报文。
   • 应用协议仅仅是应用的一个组成部分
   • 公开协议：由RFC文档定义，允许互操作，如HTTP，SMTP
   • 专有协议：协议不公开，skype
4. 应用需要传输层提供什么样的服务
   • 可靠的数据传输（无数据丢失），通信进程可以无差错、按适当顺序交付发送的数据。没有数据丢失和重复
   • 带宽/吞吐量（数据传输率），具有吞吐量要求的应用程序被称为带宽敏感的应用。弹性应用能够根据情况或多或少地利用可供使用的吞吐量
   • 定时（数据传输的时间限制）
   • 安全性
5. TCP：
   • 面向连接的服务，可靠的服务，流量控制，拥塞控制，面向连接的服务
     • 拥塞控制：当发送方和接收方之间的网络出现拥塞时，会抑制发送进程速率
6. UDP
   • 不可靠的服务
   • 能够区分不同的进程，无需建立连接，不做可靠性工作，应用能够按照设定的速度发送数据
7. 未提供的服务：
   • TCP和UDP都不提供安全性服务，所以SSL在应用层提供
   • 不确保最小传输速率：发送进程受拥塞控制机制制约
   • 不提供时延保证：数据传输的时间不确定

Web and HTTP

Web的应用层协议是HTTP超文本传输协议

Web浏览器实现了HTTP的客户端，Web服务器实现了HTTP的服务端

Web页：由若干对象组成。对象是文件。

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

URL（uniform resource locator）：通用资源定位符。格式：协议名，用户：口令.主机名/路径名：端口

HTTP:超文本传输协议（Hyper Text Transport Protocol），Web的应用层协议。运行在TCP协议之上，HTTP是无状态的，服务器并不维护关于客户的任何信息.请求报文为ASCII。HTTP协议定义了报文的格式以及客户机和服务器交换报文的方式

• 非持续HTTP，最多只有一个对象在TCP连接上发送。下载多个对象需要多个TCP连接
  • HTTP/1.0使用非持久连接
  • 缺点：必须为每一个请求的对象建立和维护一个全新的连接，给web服务器带来了负担，每个对象都要经受两倍RTT的时延
• 持续HTTP
  • 1.流水线型：一次请求多个资源
  • 2.非流水线型：一次请求一个资源
    • TCP连接空闲时间很短
  • 多个对象可以在一个TCP连接上传输
    • HTTP/1.1默认使用持久连接

**响应时间模型 —> 往返时间（round-trip-time RTT）：**一个小分组从客户端到服务器，再回到客户端的时间（传输时间忽略）

响应时间：

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

请求一个文件的总响应时间：两个RTT时延加上服务器发送文件的时间-----2RTT+文件传输时间

提交表单输入：

1. Post 在提交信息后加上提交实体
2. Get 在URL后 加上信息参数

HTTP请求报文格式：

第一行叫做请求行，有三个字段：

• 方法字段：GET，POST，HEAD，PUT，DELETE
• URL字段
• HTTP版本字段

后继的行叫做首部行：主机名，是否使用持续连接，用户代理（浏览器的类型），返回的语言

HTTP响应报文：

分为三部分：

• 初始状态行：协议版本字段，状态码，相应状态信息
• 6个首部行
• 实体体，报文的主要部分

HTTP响应状态码：

• 200:ok,请求成功
• 301:Moved Permanently ，请求的对象已转移
• 400：Bad Request，请求报文不被服务器理解
• 404：Not Found，请求的文档没有在该服务器上发现
• 505：HTTP Version NOt Supported，服务器不支持请求报文使用的HTTP版本

Cookies：

客户端与服务器第一次发请求时没有cookie，服务器生成一个新的cookie之后发送给客户端。

Cookies的组成部分：

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

Cookie可以维持状态，允许站点知道许多关于用户的信息。

Web缓存（代理服务器）

目标：代替原始服务器满足HTTP请求

起始（原始服务器）：对象最初存放并始终保持其拷贝的服务器

• 用户设置浏览器：通过缓存访问Web
• 浏览器将所有的HTTP请求都发给缓存
• web缓存器会检查本地是否存储了该对象副本

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

Web缓存的好处：

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

通过使用内容分发网络CDN，web缓存器正在因特网中发挥着越来越重要的作用

存储在缓存器中的对象副本可能是陈旧的，或者在服务器端已经修改了，需要通过条件GET语句：

• 如果请求报文使用GET方法，并且请求报文中包含一个”If-Modified-Since:“首部行，那这个HTTP请求报文就是条件GET请求
• 响应报文 首行出现 “304 Not Modified”表示资源没有修改过

FTP：文件传输协议

向远程主机上传输文件或从远程主机接收文件

用户通过一个FTP用户代理与FTP服务器交互。

文件传输过程：

1. 用户提供远程主机的主机名
2. 提供用户标识和口令：在该TCP连接上向服务器传送
3. 服务器验证通过后，进行文件传送（双向）

客户/服务器模式：

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

FTP服务器端口号为21.

客户端通过控制连接获得身份确认，之后可以通过发送命令浏览远程目录。

FTP是有状态的协议，使用了两个并行的TCP连接，控制命令和数据传输，分为两个不同的连接。此时控制命令为带外传输。

• 控制连接：用于在两主机间传输控制信息（21号端口）。控制连接是持续的：在整个用户会话期间一直保持
• 数据连接：用于准确传输文件（20号端口）。数据连接是非持续的

FTP VS HTTP

• FTP的控制信息是带外传送
• HTTP的控制信息是带内传输
• FTP协议是有状态的
• HTTP协议是无状态的

Email：STMP，POP3，IMAP

3个主要组成部分：

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

明文交互。

1.用户代理：

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

2.邮件服务器

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

3.邮件访问协议：

• POP：邮局访问协议 post office protocol
• IMAP：Internet邮件访问协议
• HTTP

STMP（邮件传送协议）

SMTP使用持久连接，要求报文为7位ASCII编码，使用TCP可靠数据传输服务

客户使用TCP来可靠传输邮件报文到服务器端口号25。

SMTP不使用中间邮件服务器发送邮件，即TCP 连接是从发送方到接收方的直接相连

SMTP VS HTTP

共同点：

• 都用于从一台主机向另一台主机传送文件
• 持续HTTP和SMTP都使用持续连接

区别：

• HTTP是拉协议：用户使用HTTP从服务器拉取信息。 其TCP连接是由想获取文件的机器发起
• SMTP是推协议：发送邮件服务器把文件推向接收邮件服务器，其TCP连接是由要发送文件的机器发起
• SMTP使用7位ASCII码格式，HTTP没有限制
• 对含有文本和图形 (或其他媒体类型)的文档
  • HTTP把每个对象封装在它各自的HTTP响应报文中发送
  • 电子邮件则把所有报文对象放在一个报文中

MIME（多用途因特网邮件扩展）

SMTP不能传送可执行文件或其他的二进制对象

MIME：用于非ASCII数据传输。将非ASCII数据编码后传输，接收方再解码还原。

​ BASE64：大小写a-z，0-9，+,/

邮件访问协议

取邮件是一个拉操作，而SMTP协议是一个推协议

POP3：

在用户代理打开了一个到邮件服务器(服务器)端口110上的TCP连接后，开始工作

工作步骤:

1. 特许阶段：用户代理发送用户名和口令获得下载邮件的特许。（身份认证）
2. 事务处理阶段：用户代理取回报文，可对邮件进行某些操作
3. 更新阶段：邮件服务器删除带有删除标记的报文，结束POP会话

IMAP:

POP3缺陷：用户读取邮件后，服务器不再保存

IMAP： 功能强

• 在用户的PC机上运行IMAP客户程序，然后与ISP的邮件服务器上的IMAP服务器程序建立TCP连接
• 用户在自己的PC机上就可以操纵邮件服务器的邮箱，就像在本地操纵一样，是一个联机协议
• 未发出删除命令前，一直保存在邮件服务器
• 实现起来复杂

基于web的电子邮件：

DNS

域名解析系统。提供域名到IP之间的转换。

DNS的必要性：

• IP地址标识主机，路由器。但是IP不好记忆
• 存在着“字符串”-IP地址的转换的必要性
• 人类用户提供要访问机器的“字符串”名称
• DNS负责转换成为二进制的网络地址

DNS的主要思路：

• 分层的，基于域的命名机制
• 若干分布式的数据库完成名字到IP地址的转换
• 运行在UDP之上端口号为53的应用服务
• 核心的Internet功能，但以应用层协议实现
• DNS通常直接由其他的应用层协议（HTTP，SMTP，FTP）使用，以将用户提供的主机名解析为IP地址

DNS主要目的：

• 实现主机名-IP地址的转换
• 主机别名到规范名字的转换
• 邮件服务器别名到邮件服务器的正规名字的转换
• 负载均衡

DNS域名结构

• 一个层面命名设备会有很多重名
• DNS采取层次树状结构的命名方法
• Internet根被化为几百个顶级域：通用的和国家的
• 每个域下面可划分为若干子域
• 树叶是主机

域名管理

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

域与物理网络无关：

• 域遵从组织界限，而不是物理网络
• 域的划分是逻辑的，而不是物理的

名字空间划分为若干区域：Zone

集中式的设计存在问题：单点故障，通信容量，远距离的集中式数据库，维护

4.本地DNS服务器

3.权威DNS服务器：组织机构的DNS服务器，提供组织机构服务器可访问的主机和IP之间的映射

2.顶级域（TLD）服务器：负责顶级域名和所有国家级的顶级域名

1.根服务器

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

DNS大致工作过程：

• 应用调用解析器
• 解析器作为客户向Name Server发出查询报文（封装在UDP段中，从53号端口发送）
• Name Server返回响应报文
  • 查询有
    • 递归查询：跟服务器负担很大
    • 迭代查询

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

P2P应用

Peer节点上下载能力是有限的资源

• 非结构化P2P

  • 结点与结点之间的联系是无规则的

  • 1.有一个集中化的目录

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

  • 2.完全分布式

  • 3.混合体：每个对等方要么是一个组长，要么隶属于一个组长

• DHTC（结构化）P2P

  • 节点与节点之间的联系可以构成环，树等

客户-服务器体系结构的分发时间（分发时间，所有N个对等方得到该文件的副本所需要的时间）

服务器必须向N个对等方的每个传输该文件的一个副本，务器传输NF比特，上载速率是Us分发该文件的时间至少为NF/U。

具有最小下载速率的对等方的下载速率——dmin，即dmin=min{d1,dp,…,dN}。具有最小下载速率的对等方不可能在少于F/dmin秒时间内获得该文件的所有F比特。最小分发时间至少为F/dmin

• 最小分发时间 Dcs=max{NF/us，F/dmin}

P2P体系结构的分发时间

在分发的开始，只有服务器具有文件。为使对等方得到该文件，该服务器必须经其接入链路至少发送该文件的每个比特一次。因此，最小发送时间至少是F/us。

具有最小下载速率的对等方不可能在少于F/dmin秒时间内获得该文件的所有F比特。最小分发时间至少为F/dmin。

系统的总上载能力等于服务器的上载能力us加上每个节点的上载能力ui，总的速率就是us+u1…+ui，总共上传NF比特，时间为NF/(us+u1+…+uN)

P2P最小分发时间：

• DP2P=max{F/us，F/dmin，NF/(us+u1+…+uN)}

BitTorrnet

洪流:参与一定特定文件分发的所有对等方的集合

每个洪流具有一个基础设施节点，成为追踪器，当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中

与某个对等方建立TCP连接的所有对等方成为该对等方的**“临近对等方”**

P2P对等体应该从邻居请求哪些块呢？

• （最稀缺优先（rarest first）的技术）
  针对她没有的块在她的邻居中决定最稀缺的块（邻居中副本数量最少的块），并首先请求那些最稀缺的块。
  使最稀缺块得到更为迅速的重新分发——（大致地）均衡每个块在洪流中的副本数量。

P2P对等体应该向哪些邻居请求块呢？

对换算法：

• Alice优先选择以最高速率向他提供数据的邻居。
  • 对每个邻居都持续地测量接收到比特的速率，并确定以最高速率流入的4个邻居。
  • 每过10秒，她重新计算该速率并可能修改这4个对等方的集合。这4个对等方被称为疏通。
• 每过30秒Alice将随机地选择一名新的对换伴侣并开始与那位伴侣进行对换。
• 除了这5个对等方（“前”4个对等方和一个试探的对等方）的所有其他相邻对等方均被“阻塞”，即它们不能从Alice接收到任何块。

P2P系统拓扑形式

根据结构关系可以将P2P系统细分为四种拓扑形式：

• 中心化拓扑
• 全分布式非结构化拓扑
• 全分布式结构化拓扑（Decentralized Structured Topology，也称作DHT网络）采用分布式散列表（Distributed Hash Table, 简写成DHT）技术来组织网络中的结点；
• 半分布式拓扑

P2P文件共享特点

• 直接在对等方间传输:所有内容不经过第三方服务器
• 高度的可扩展能力:利用众多对等方集合中的资源去分发内容
• 使用客户机/服务器模式:请求的对等方是客户机，被选中的对等方是服务器

一个对等方如何确定哪个对等方有所需要的内容。

（1）集中式目录:

• 专门的目录服务器提供目录服务，收集可共享的对象，建立集中式的动态数据库
• 属于客户机/服务器与P2P的混合结构
• 存在的问题：单点故障，性能瓶颈，侵犯版权，可靠性差

（2）查询洪泛

• 是一个公共域文件共享应用程序
• 全分布方式：无中心服务器
• 对等方先形成一个抽象的逻辑网络（覆盖网络）：通过洪泛查询，找到所需对象
• 特点：设计简单，扩展性差，“查询报文”在网络中产生很大的流量

（3）利用不均匀性（ KaZaA）

• 无专用服务器，但对等方地位不平等。
• 对等方先形成一个层次的覆盖网络，通过查询，找到所需对象。
• 对等方根据通信关系划分若干组，组成层次结构。组员将共享内容告诉组长，相关组长之间建立TCP连接
• 特点：层次覆盖网络，查询流量不大，
  • 设计技巧：请求排队，激励优先权（上载文件比下载文件多的用户优先），并行下载

CDN

多媒体流化服务：DASH

Dynamic Adaptive Streaming Over HTTP

服务器：

• 将视频文件分割成多个块
• 每个块独立存储，编码于不同码率
• 告示文件：提供不同块的URL

客户端：

• 先获取告示文件
• 周期性地测量服务器到客户端的带宽
• 查询告示文件，在一个时刻请求一个块，HTTP头部指定字节范围
• 智能的客户端：
  • 什么时候去请求块
  • 请求什么编码速率的视频块
  • 哪里去请求块

CDN：Content distribution networks

视频可以通过CDN，全网部署缓存节点，存储服务内容，就近为用户提供服务，提高用户体验。

在CDN节点中存储内容的多个拷贝。

用户从CDN中请求内容；