2.1应用层协议原理

2.1.1网络应用程序体系结构

客户端服务器体系结构:
- 不直接通信
- 服务器具有固定的IP地址
- 需要大量服务器来应付客服端请求
- 具体例子包括web，FTP和Telnet、电子邮件
对等(P2P)体系结构
- 应用程序在间断连接的主机对之间使用直接通信，这些主机称为对等方
- 对专用服务器依赖较小
- 主要包括流量密集型应用，如文件共享BitTorrent、对等方协助下载加速器(迅雷)
- 自扩展性

2.1.2 进程通信

两个不同端系统上的进程通过报文来相互通信

客户和服务器进程
对每对通信进程, 我们通常将这两个进程之一标识为客户（client）,而另一个进程标识为服务器（server）。对于Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器
进程和计算机网络之间接口

每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。
进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。套接字是同一台主机内应用层与运输层之间的接口
应用程序开发者对于运输层的控制仅限于：①选择运输层协议；②也许能设定几个运输层参数，如最大缓存和最大报文段长度

进程寻址
为了向特定目的地发送邮政邮件，目的地需要有一个地址，包括包括:

目的地主机IP，32比特
目的地主机端口号

2.1.3 可供应用程序使用的运输服务

从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性

可靠数据传输: 当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程
吞吐量: 运输层协议能够以某种特定的速率提供确保的可用吞吐量，具有吞吐量要围求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）。许多当前的多媒体应用是带宽敏感的，尽管某些多媒体应用程序可能采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码，带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application ）能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。电子邮件、文件传输以及Web传送都属于弹性应用
定时: 服务为了有效性而要求数据交付有严格的时间限制
安全: 运输协议能够加密由发送进程传输的所有数据

因特网提供的运输服务

TCP

面向连接的服务: 应用层开始传输数据前握手建立TCP连接，结束传输报文会拆除连接
可靠数据传输: 通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据
无论TCP还是UDP都没有提供任何加密机制，在应用层基础上使用安全套接字层SSL，当一个应用使用SSL时，发送进程向SSL套接字传递明文数据；在发送主机中的SSL则加密该数据并将加密的数据传递给TCP套接字。加密的数据经因特网传送到接收进程中的TCP套接字。该接收套接字将加密数据传递给SSL,由其进行解密。最后，SSL通过它的SSL套接字将明文数据传递给接收进程
拥塞控制

UDP

无连接的，因此在两个进程通信前没有握手过程
不可靠，乱序
没有拥塞控制

因特网运输协议不提供服务

2.1.5 应用层协议

应用层协议通常定义了:

交换的报文类型，是请求还是相应
各种报文类型的语法
字段含义
进程何时如何发送报文，如何响应

应用层协议只是网络应用的一部分，Web的应用层协议是HTTP,它定义了在浏览器和Web服务器之间传输的报文格式和序列，此外web还包括HTML，web浏览器等

2.1.6 网络应用

Web: http
文件传输: ftp
电子邮件: smtp
目录服务: dns
流式视频
P2P

2.2 Web和HTTP

万维网是因特网之一

2.2.1 HTTP概括

Web的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP）,它是Web 的核心，客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP报文进行会话，http建议在tcp基础上。

Web页面（Web page）（也叫文档）是由对象组成的，多数web页面包括一个HTML基本文件和一个引用对象，HTML基本文件通过对象的URL地址引用页面中的其他对象。每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名
Web浏览器实现了 HTTP 的客户端
Web服务器（Webserver）实现了 HTTP的服务器端，它用于存储Web对象
HTTP定义了 Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式，当用户请求一个Web页面(如点击一个超链接)时，浏览器向服务器发出对该页面中所包含对象的 HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应，HTTP是无状态协议，即重新请求会重新发送

2.2.2 非持续连接和持续连接

非持续连接
在非持续连接情况下，从服务器向客户传送一个Web页面的步骤:

RTT: 往返时间，指一个短分组从客户到服务器然后再返回客户所花费的时间，RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延

总的响应时间就是两个RTT加上服务器传输HTML文件的时间

持续连接

一个完整的Web页面（上例中的HTML基本文件加上10个图形）可以用单个持续 TCP连接进行传送。
位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行
一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接

2.2.3 HTTP报文格式

HTTP请求报文

请求行

方法: GET、POST、HEAD、PUT和DELETE
1. get：大多数web请求
2. post: 提交表单
3. head: 调试跟踪
4. put: 上传对象到服务器
5. delete: 删除服务器对象
URL
版本

首部行

Host 客户端主机
Connection: close 不要使用持续连接
User-agen: 服务器发送请求的浏览器的类型
Accept-language: 用户想得到该对象的语言

实体体

使用GET为空
使用POST包含的就是用户在表单字段中的输入值，用表单生成的请求报文不是必须使用POST方法

HTTP相应报文

1个初始状态行：协议版本、状态码、相应状态信息
6个首部行:
Connection： close首部行告诉客户，发送完报文后将关闭该TCP连接
Date：首部行指示服务器产生并发送该响应报文的日期和时间
Serve: 服务器
Last-Modified：首部行指示了对象创建或者最后修改的日期和时间
Content-Length：首部行指示了被发送对象中的字节数
Content-Type：首部行指示了实体体中的对象是HTML文本
实体体

2.2.4 用户与服务器的交互：cookie

cookie组件:

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

2.2.5 Web缓存

Web缓存器（Web cache）也叫代理服务器，Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此

2.2.6 条件get

如果：①请求报文使用GET 方法；并且②请求报文中包含一“IfModified.Since：”首部行。那么，这个HTTP请求报文就是一个条件GET请求报文

2.3 因特网中的电子邮件

用户代理:类似outlook的应用
邮件服务器：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。当Bob要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器(使用用户名和口令)来鉴别Bob。如果Alice的服务器不能将邮件交付给Bob的服务器, Alice的邮件服务器在一个报文队列（message queue）中保持该报文并在以后尝试再次发送。
简单邮件传输协议SMTP: 运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端

2.3.1 SMTP

SMTP操作流程以Alice发给Bob为例:

2.3.2 和HTTP对比

相同点:

HTTP从Web服务器向Web客户（通常是一个浏览器）传送文件（也称为对象）；SMTP从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）
都使用持续连接

不同点:

HTTP主要是一个拉协议，用户通过HTTP从服务器上拉取信息，SMTP基本是一个推协议，从客户邮件服务器推送到收件人邮件服务器
SMTPP要求每个报文（包括它们的体）采用7比特ASCII码格式。如果某报文包含了非7比特ASCII字符（如具有重音的法文字符）或二进制数据（如图形文件），则该报文必须按照7比特ASCII码进行编码
HTTP把每个对象封装到它自己的HTTP响应报文中, 而SMTP则把所有报文对象放在一个报文之中

2.3.3 邮件报文格式

每个首部必须含有一个From：首部行和一个To：首部行；一个首部也许包含一个Subject:首部行以及其他可选的首部行

2.3.4 邮件访问协议

代理到发邮件服务器: SMTP
发邮件服务器到收邮件服务器: SMTP
收邮件服务器到收邮件代理: POP3(第三版邮局协议)、IMAP(因特网邮件访问协议)

POP3
POP3按照三个阶段进行丁作：特许（authorization）、事务处理以及更新。

特许: 用户代理发送（以明文形式）用户名和口令以鉴别用户
事务处理: 对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息
更新: 出现在客户发出了 quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文

不同用户代理之间可以采取下载删除和下载保留方式来同步删除或者保留标记要删除的邮件

POP3服务器并不在POP3会话过程中携带状态信息，因此更简单，POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法

IMAP

当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联
收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件
IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去査询匹配的邮件
IMAP服务器维护了 IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联
它具有允许用户代理获取报文某些部分的命令，如果用户带宽低并且报文大非常有用

用于web的服务器
使用浏览器收发电子邮件，用户和邮件服务器之间使用HTTP协议

2.4 DNS

DNS作用:

把主机名转换成IP地址
获取主机别名
邮件服务器别名
负载均衡(一个主机名对应不同IP)
因特网主机标识方法:
主机名: www.baidu.com
IP地址: 172.47.0.1 4个字节
DNS: 域名系统，是:：①一个由分层的DNS服务器（DNS
server）实现的分布式数据库；②一个使得主机能够查询分布式数据库的应用层协议，③DNS协议运行在UDP之上，使用53号端口

与HTTP、FTP和SMTP协议一样，DNS协议是应用层协议，其原因在于：①使用客户-服务器模式运行在通信的端系统之间；②在通信的端系统之间通过下面的端到端运输协议来传送DNS报文

DNS响应过程如下:

分布式、层次数据库

根DNS服务器
顶级域DNS服务器
权威DNS服务器
本地DNS服务器
DNS递归查询步骤

2. DNS缓存

在一个请求链中，当某DNS 服务器接收一个DNS回答时，它能将映射缓存在本地存储器中，如果相同主机再次查询改DNS服务器时，本地DNS服务器即可返回回答，DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。

3. DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(RR)，RR提供了主机名到IP地址的映射，每个DNS回答报文包含了一条或多条资源记录，资源记录包含如下:
Name, Value, Type, TTL
Type情况如下:

A Name为主机名，Value为该主机对应IP地址
NS Name为域，Value为如何获得该域中主机IP地址的权威DNS服务器主机名
CNAME Value是别名为Name的主机对应的规范主机名
MX Value是个别名为Name的邮件服务器的规范主机名

DNS报文：

前12个字节为首部字段
问题区域包含正在进行的查询信息
回答区域包含了对最初请求的名字的回答区域

nslookup

2.5 P2P文件分发

对于客户-服务器体系结构，随着对等方数量的增加，分发时间呈线性增长并
且没有界。然而，对于P2P体系结构,最小分发时间不仅总是小于客户-服务
器体系结构的分发时间，并且对于任意的对等方数量总是小于1小时。因
此，具有P2P体系结构的应用程序能够是自扩展的。

2.6 视频流和内容分发网络

2.6.1 因特网视频

对流式视频的最为重要的性能度量是平均端到端吞吐量。为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大

2.6.2 HTTP流和DASH

DASH：经HTTP的动态适应流，在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应于不同的质量水平。客户动态地请求来自不同版本且长度为几秒的视频段数据块。当可用带宽量较高时，客户自然地选择来自高速率版本的块；当可用带宽量较低时，客户自然地选择来自低速率版本的块。

使用DASH后，每个视频版本存储在HTTP服务器中，每个版本都有一个不同的 URL。客户首先请求该告示文件并且得知各种各样的版本。然后客户通过在HTTP GET请求报文中对每块指定一个URL和一个字节范围，一次选择一块。在下载块的同时，客户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。自然地，如果客户缓存的视频很多，并且测量的接收带宽较高，它将选择一个高速率的版本

2.6.3 内容分发网络

CDN: 如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向客户流式传输视频时的同时在本地存储一个副本