计算机网络【02】应用层

---

02 应用层

网络应用是计算机网络存在的理由，如果不能构想出任何有用的应用，也就没必要去设计支持它们的网络协议了。

时间	因特网应用
1970 1980年代	文本电子邮件、远程访问计算机、文件传输、新闻组
1990中期	万维网、Web冲浪、搜索、电子商务
20世纪末	即时讯息、对等（P2P）文件共享
21世纪	IP电话VoIP、IP视频会议Skype、YouTube、点播电影Netflix、在线游戏

网络分层模型，七层的OSI和五层的TCP/IP
I层通过I层协议实体向I+1层提供服务，TCP/IP体系中，应用层协议通过运输层协议提供的服务来实现。

学习目标

本章会学习有关网络应用的原理和实现方面的知识。

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

• 运输层服务模型
• 客户 / 服务器范例
• 对等模式范例
• 内容分发网

通过流行的应用层协议学习协议

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

写应用程序

• socket API

一、应用层协议原理

研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。

一个应用程序和远端机器上的另一个应用程序通信，这是构建网络的目的所在。

两端应用程序运行在各自的主机中，他们之间的协议是端到端的，与网络无关。
网络只是为应用程序提供服务，应用程序依靠这些服务，借助他们之间的协议实现数据交互。

写网络应用程序
运行在不同的端系统，通过网络相互通信，如web服务器程序，与浏览器软件通信
不需要为网络核心写程序
网络核心设备不运行用户程序，端系统上的应用程序可快速开发和传播

1.应用程序体系结构

---

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

有一个总是打开的主机称为服务器，服务于来自许多其他称为客户的主机的请求。

服务器：一直在线的主机，具有固定的、周知IP地址，通常位于数据中心；
客户：与服务器通信，可能间隙性连接，可能只有动态IP地址，客户之间不直接通信。
客户机是服务请求方，服务器对其请求做出响应；服务器一般一直在线等待客户请求的到来。

应用程序包括：Web、FTP、Telnet、电子邮件。
常常出现一台单独服务器主机跟不上它所有客户请求的情况，因此配备大量主机的数据中心，被用于创建强大的虚拟服务器

---

对等（P2P）体系结构

对位于数据中心的专用服务器有最小的（或没有）依赖。
对等方应用程序在间断连接的主机对之间使用直接通信 的主机。

没有一直在线的服务器，任意端系统间直接通信，一方请求其他方提供服务，也为其他方提供服务。
自扩展：新的加入者带来新的服务能力，也带来新的服务需求。
参与者间隙性连接，IP地址可变，复杂的管理

应用程序包括：文件共享BitTorrent、对等方协助下载加速器（如 迅雷）、因特网电话和视频会议（如 Skype）

---

一些应用具有混合的体系结构，结合了客户-服务器和P2P的元素。

2.进程通信

进程：在主机上运行的程序。（进行通信的实际上是进程 不是程序）
同一主机，两个进程使用“进程间通信”机制进行，由操作系统定义。
在不同主机上的进程间的通信通过交换报文

客户进程——发起通信
服务器进程——等待来者

P2P架构的应用程序兼具客户进程和服务器进程

套接字（插口）—应用程序和网络之间的应用程序的编程接口

进程发送报文到套接字，也从套接字接收报文

套接字类似门，进程类似于房子

• 发送进程将报文推出门
• 发送报文依靠门外的运输基础设施将报文传送到接收进程的套接字

进程寻址

为接收报文，进程必须具备标识符 + 地址，标识符包括IP地址+端口号
主机设有32位唯一IP地址
（只有主机IP地址并不足够，主机上有许多进程在运行）

端口号例：HTTP服务器80，邮件服务器25，欲发送HTTP报文给web服务器.
IP地址：128.119.245.12，端口号：80

应用层协议需定义的内容

• 交换报文的类型：如，请求，响应
• 报文格式：有哪些字段，这些字段的描述
• 报文语法：上述字段的含义
• 规则：何时，如何发送和接收报文
• 开放的协议：RFCs定义，允许互操作性，如HTTP，SMTP
• 专有协议：如，Skype，微信

3.应用程序可使用的运输服务

应用层所需要的运输服务

• 数据完整性：某些应用（如文件传输，web交互）需要100%可靠的数据传输；一些应用（如音频）可以容忍一些丢包
• 时序：某些应用（如因特网电话/交互式游戏）需要低时延；一些对时延没有要求，如邮件
• 吞吐量：某些应用（如多媒体）需要最小吞吐量保障；一些应用无所谓
• 安全：加密，数据完整性

常见应用对运输服务的需求

4.因特网提供的运输服务

因特网运输协议服务

TCP服务

• 在收发双方间可靠运输
• 流控：发送方勿淹没接收方
• 拥塞控制：当网络负荷重，发送方减速
• 不提供：时序，最低吞吐量保证，安全
• 面向连接：需要在收发双方间建立连接
• SSL安全套接字层：是对TCP的加强，在应用层实现，针对隐私和其他安全问题

UDP服务

• 不提供不必要服务的轻量级运输协议，仅提供最小服务
• 不可靠传输
• 不提供：可靠性，流控，拥塞控制，时序，吞吐量保证，安全，连接建立

因特网应用、应用层及其运输层协议

一些应用选择TCP最主要原因是：TCP提供了可靠数据传输服务，确保所有数据最终到达目的地。
还有一些应用可以忍受某些丢失但要求达到一定的最小速率会选择UDP ：为了设法避开TCP的拥塞控制机制和分组开销，但一些防火墙被配置为阻挡UDP流量，因特网电话应用通常设计成如果UDP通信失败则使用TCP作为备份。

SSL——使TCP更安全

• TCP&UDP：未加密，密码也经明文传输
• SSL：提供加密的TCP连接，数据完整性，端点鉴别（认证）
• SSL位于应用层：应用程序使用SSL库，与TCP对话
• SSL socket API：输入到SOCKET的明文在因特网上变成密文传输

5、应用层协议

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文

• 交换的报文类型，如请求报文和响应报文
• 各种报文类型的语法，如报文中的各种字段及字段描述
• 字段的语义，这些字段中信息的含义
• 确定一个进程何时以及如何发送报文，对报文进行响应的规则

有些应用层协议由RFC文档定义，位于公共域中。

二、web和HTTP

web页包括一些对象（HTML文件，JPEG图像，JAVA小程序，音频文件…）
web页包括基本的HTML文件，该文件包括若干引用对象
每个对象由URL统一资源定位符定位，如：

1、HTTP概述（超文本传输协议）

web的应用层协议是超文本传输协议HTTP，在 [RFC 1945]、[RFC 2616] 进行了定义。

客户/服务器模式

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

• 客户：浏览器，请求、接收（用HTTP协议）和显示web对象

• 服务器：作为对上述请求的响应，Web服务器发送（用HTTP协议）对象

• 
  HTTP使用TCP作为支撑运输协议

• 客户发起TCP连接（创建套接字到服务器）

• 服务器接收客户的TCP连接

• HTTP报文（应用层协议报文）在浏览器（HTTP客户）和Web服务器（HTTP服务器）之间交换

• TCP连接关闭（释放、拆除）

HTTP是无状态协议

• 服务器不会保留过去的连接的有关信息
• 若要维护状态，协议将很复杂
  - 需维护历史状态
  - 若服务器或客户崩溃，他们各自记录的状态可能不一致，需要协调

2、HTTP connections

• 持续HTTP 持续连接
  - 所有的请求及其响应经想用的TCP连接发送
  - 一个TCP可以传输多个对象

• 非持续HTTP 非持续连接
  - 每个请求经一个单独的TCP连接发送
  - 在TCP连接上至多发送一个对象，然后连接关闭
  - 下载多个对象需要多个连接
  
  采用非持续连接的HTTP

• RTT（往返时延）：一个小包从客户到服务器并返回

• HTTP响应时间
  - RTT用于发起TCP连接
  - RTT用于HTTP请求及少数几个字节的响应
  - 文件传输时间
  - 非持续HTTP响应时间=2RTT+文件传输时间

非持续HTTP的问题

• 每个对象需要2RTT
• 每个TCP连接均需OS开销
• 浏览器经常同时打开多个TCP连接，以获取对象

采用持续连接的HTTP

• 服务器发送响应后，保持连接处于打开状态
• 后续HTTP报文可继续在此连接上交互
• 客户获得一个对象后立即发送新的请求
• 所有对象合计仅花1 RTT略多一点点的时间（文件传输时间相比往返时间短很多）

3、HTTP报文格式

HTTP响应状态码

状态码出现在响应报文的第一行

• 200 OK：请求成功，请求的对象在此报文后部
• 301 Moved Permanently 永久移居：请求的对象搬走了，新位置在此报文后面位置
• 400 Bad Request 此请求服务器不懂：服务器不能理解此报文
• 404 Not Found 没找到：此服务器上没找到请求的文档
• 505 HTTP Version Not Supported ：不支持该HTTP版本

尝试

4、用户-服务器的交互 cookie

Cookie 并不是它的原意“甜饼”的意思, 而是一个保存在客户机中的简单的文本文件, 这个文件与特定的 Web 文档关联在一起, 保存了该客户机访问这个Web 文档时的信息, 当客户机再次访问这个 Web 文档时这些信息可供该文档使用。由于“Cookie”具有可以保存在客户机上的神奇特性, 因此它可以帮助我们实现记录用户个人信息的功能, 而这一切都不必使用复杂的CGI等程序。

举例来说, 一个 Web 站点可能会为每一个访问者产生一个唯一的ID, 然后以 Cookie 文件的形式保存在每个用户的机器上。如果使用浏览器访问 Web, 会看到所有保存在硬盘上的 Cookie。在这个文件夹里每一个文件都是一个由“名/值”对组成的文本文件,另外还有一个文件保存有所有对应的 Web 站点的信息。在这里的每个 Cookie 文件都是一个简单而又普通的文本文件。透过文件名, 就可以看到是哪个 Web 站点在机器上放置了Cookie(当然站点信息在文件里也有保存) 。

四个部件

• HTTP响应报文的cookie首部行
• 下一个HTTP请求报文中的cookie首部行
• cookie文件，位于用户主机，由用户浏览器管理
• web网站后端数据库
• 示例：从PC访问因特网-首次访问某特定电子商务网-当初始HTTP请求到达网站，网站创建-唯一ID，后端数据库中为该ID建立一个表项
  
  cookies可用于：认证/授权，购物车，推荐，用户会话状态（web版电子邮件）
  cookies可能存在隐私泄露问题

如何保持状态：

• 协议端点：在发送方/接收方维持状态
• cookies：http报文包含状态

5、Web缓存（代理服务器）

代表初始Web服务器来满足HTTP请求的网络实体。

目标：满足客户请求，而不连接到原始服务器。

用户在浏览器中设置：通过Cache访问Web
浏览器发送所有HTTP请求到cache

• 对象在cache：cache返回对象
• 否则，cache向原始服务器请求该对象，然后返回给客户
  cache既做服务器又做客户对原始请求客户——是服务器；对原始服务器——是客户
  通常由ISP部署cache（大学、公司、居民服务ISP）

cache作用

• 缩短响应客户请求的时间
• 减少机构网络接入链路上的流量
• 因特网上有大量cache，使内容服务商高效地分发内容（P2P文件共享同理）

三、Email

三个主要部件：用户代理，邮件服务器，简单邮件传输协议SMTP

用户代理（邮件阅读器）

构成，编辑，阅读邮件报文；发出、到达的报文均存储在服务器

邮件服务器

邮箱，进入的邮件报文
待发出的邮件报文队列
SMTP协议，邮件服务器之间的协议：客户-发送服务器；服务器-接收服务器

1、SMTP[RFC 2821]

SMTP是因特网电子邮件中主要的应用层协议
用TCP可靠地传输邮件消息端口号25

直接传输: 从发送方邮件服务器到接收方服务器发送邮件

三阶段：握手 (打招呼)——消息传输——关闭
命令/响应 交互(就像HTTP那样)
• 命令: ASCII文本
• 响应: 状态码和短语
SMTP用持续链接，要求消息必须是7位ASCII编码，服务器见CRLF.CRLF知消息结束
与HTTP比较：

• HTTP：拉——每个对象封装在其自己的响应报文中
• SMTP：推——多个对象在一个消息的多个部分中被发送
• 都有ASCII码命令/响应交互，状态码

尝试SMTP交互

2、邮件报文（消息）格式

3、邮件存取协议

SMTP：分发/存储到接收者服务器
邮件存取协议：从服务器取回

• POP3：Post Office Protocol[RFC 1939]：认证，下载
• IMAP：Internet Mail Access Protocol[RFC 1730]：更多特性，包括操纵存在服务器上的消息
• HTTP：gmail，Hotmail，Yahoo！
  

四、DNS域名系统

识别主机有两种方式：通过主机名或IP地址

DNS域名系统：进行主机名到IP地址转换的目录服务
DNS协议运行在UDP之上，使用53号端口

建立IP地址和名字之间的对应关系

• 由分层DNS服务器实现的分布式数据库，由许多名字服务器层次式实现。
• 一个使得主机能够查询分布式数据库的应用层协议。主机，名字服务器通信以解决地址/名字间的转换

1、DNS提供的服务

• 主机名到IP地址转换
• 主机别名（标准名，别名）
• 邮件服务器别名
• 负载分散（重复的Web服务器，许多IP地址对应于一个名字）

2、DNS工作机理概述

为何不采用集中式DNS？
原因：单点故障，流量太大，遥远的集中式数据库，维护难度

在单一DNS服务器上运行集中式数据库完全没有可扩展能力，因此，DNS采用分布式的设计方案。

根域名服务器

• 若本地域名服务器不能解答客户查询，联系根域名服务器
• 根域名服务器：若不知道，联系权限域名服务器–>获得结果–>回复给本地域名服务器
• 
  TLD顶级域名服务器
• 负责com, org, net, edu, aero, jobs, museums, 以及所有顶级国家域名.如:uk,fr,ca,jp，cn
• Network Solutions 负责维护.com TLD的服务器
• Educause 负责.edu TLD

权限域名服务器

• 组织机构自己的DNS服务器,提供该组织内已命名主机的权威主机名-IP地址映射
• 可由组织自己维护，也可由服务商提供

本地DNS服务器

• 严格说，不属于DNS体系
• 每个ISP (住户ISP,公司,大学)有一个，亦称 “默认域名服务器”
• 当主机作DNS查询,该查询被送到其本地域名服务器
  • 由本地缓存，存储最新的名字－地址对（可能过期)
  • 作为代理,转发查询到DNS体系

缓存，更新记录

• 服务器掌握一个名字-IP对后，缓存
  • 缓存在某个时间TTL后失效
  • TLD服务器也经常缓存在本地服务器，因此不需要经常访问根服务器
• 缓存的表项常常会过期
  • 如果主机改变了IP地址，因特网上总有部分DNS服务器缓存了老的、过期的记录
• 更新 / 修改机制由IETF标准建议
  • RFC 2136

五、P2P文件分发

使用P2P体系结构，对总是打开的基础设施服务器有最小的（或没有）依赖，成对简写的主机（对等方）彼此直接通信。

2016年止，最为流行的P2P文件分发协议是BitTorrent。

1、P2P体系结构的扩展性

F表示被分发的文件长度（以比特计）
N表示要获得的该文件副本对等方的数量
分发时间是所有N个对等方得到该文件的副本所需要的时间。

客户-服务器体系结构的分发时间Dcs，在该体系结构中，没有对等方参与来帮助分发文件

P2P体系结构分发时间取决于每个对等方如何向其他对等方分发该文件的各个部分。

对于客户-服务器体系结构，随着对等方数量的增加，分发时间呈线性增长并且没有界；而对于P2P体系结构，最小分发时间不仅总是小于客户-服务器体系结构的分发时间，而且对于任意的对等方数量N，总是小于1小时。

具有P2P体系结构的应用程序能够是自扩展的。
原因是：对等方除了是比特的消费者外还是他们的重新分发者。

2、BitTorrent

BitTorrent是一种用于文件分发的流行P2P协议

一般的下载服务器为每一个发出下载请求的用户提供下载服务，而BitTorrent的工作方式与之不同。分配器或文件的持有者将文件发送给其中一名用户，再由这名用户转发给其它用户，用户之间相互转发自己所拥有的文件部分，直到每个用户的下载都全部完成。这种方法可以使下载服务器同时处理多个大体积文件的下载请求，而无须占用大量带宽。

普通的HTTP/FTP下载使用TCP/IP协议，BitTorrent协议是架构于TCP/IP协议之上的一个P2P文件传输协议，处于TCP/IP结构的应用层。 BitTorrent协议本身也包含了很多具体的内容协议和扩展协议，并在不断扩充中。

六、视频流和CDN

1、视频流

视频是一系列的图像，通常以一种恒定的速率（每秒24或30张）
一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素是由一些比特编码来表示亮度和颜色。

从网络观点看，视频最为突出的特征是高比特率。（比特率越高，图像质量越好）

对流式视频最为重要的性能度量是平均端到端吞吐量。

2、内容分发网CDN

为了应对向分布于全世界的用户分发巨量视频数据的挑战。

一种CDN可以是专用CDN，即它由内容提供商自己所拥有，如谷歌的CDN分发Youtube；
另一种CDN可以是第三方CDN，它代表多个内容提供商分发内容。

CDN采用两种不同的服务器安置原则

• 深入：通过在遍及全球的接入网ISP中部署服务器集群来深入到ISP接入网中。
• 邀请做客：通过在少量关键位置建造大集群来邀请到ISP做客。

七、套接字编程

1、UDP套接字编程

2、TCP套接字编程

总结