计算机网络 自顶向下方法笔记2

第二章 应用层

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

这一层只涉及到选择哪一种连接服务来实现应用程序的通信

应用层享受着运输层提供的进程之间进行直接通信的服务。在此服务上进行设计应用程序

2.1应用层协议原理

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

网络核心设备并不在应用层上起作用，仅在较低层起作用。应用软件被限制在端系统。

2.1.1网络应用程序体系结构

规定如何在各种端系统上组织该应用程序。现代网络软件中两种主流体系结构：客户-服务器体系结构，对等（P2P）体系结构

• 客户-服务器体系结构：总是打开的主机叫做服务器，服务于来自许多其他称为客户的主机的请求。客户之间不直接通信。服务器具有固定的、周知的IP地址。配备大量主机的数据中心常用于创建强大的虚拟服务器
• P2P体系结构：对数据中心的专用服务器有最小的（或没有）依赖。应用程序在简短的主机对之间使用直接通信，这些主机对成为对等方。某些应用具有混合的体系结构（eg：服务器跟踪用户IP地址，报文在主机间发送）。具有自拓展性，但由于高度非集中式难以管理。

2.1.2进程通信

网络上进行通信的是进程。两个不同端系统的进程通过交换报文相互通信

1. 客户和服务器进程：在一对进程之间的通信会话场景中，发起通信的进程被标识为客户进程，在会话开始时等待联系的进程是服务器进程（不论是客户-服务器还是P2P应用程序体系结构）  有时使用术语“应用程序的客户端和服务器端”
2. 进程与计算机网络之间的接口：进程通过叫套接字的软件接口（类似房子的门，外面是网络基础设施）向网络发送接收报文。套接字是同一台主机内应用层和运输层之间的接口。开发者对运输层几乎没有什么控制权。
   也称应用程序编程接口API
3. 进程寻址：为了标识接收进程，需要定义主机地址（IP地址）、指定运行在接收主机的接收进程的标识（端口号）。 （这是运输层的问题）

 2.1.3可供应用程序使用的运输 服务（运输层协议提供服务）

服务要求： 

1.  可靠数据传输：确保数据能无差错地、数据正确的、完全交付给接收进程。容忍丢失的应用则无需考虑。
2. 吞吐量：运输层协议能够以某种特定的速率提供确保的可用吞吐量。可用吞吐量为发送进程能够向接收进程交付比特的速率。具有吞吐量要求的应用叫带宽敏感的应用。弹性应用能够根据当前可用的带宽利用可供使用的吞吐量。
3. 定时：保证时延
4. 安全性：提供安全性服务

2.1.4因特网提供的运输服务

因特网（TCP/IP网络）提供两个运输层协议：TCP（2RTT）,UDP(1 RTT)

1. TCP服务：包括面向连接的服务、可靠的数据传输服务（无差错、按适当顺序交付所有发送的数据）、拥塞控制机制（为因特网带来整体好处）
   SSL安全套接字层，为TCP的安全性强化，在应用层实现
2. UDP服务：UDP是种不提供不必要服务的轻量级运输协议，它仅提供最小服务（基础服务）。无连接，提供不可靠数据传输服务。没有包括拥塞控制机制（可以用选定的任何速率向其下层网络层发送数据）
3. 网络层运输协议所不提供的服务：没有提供吞吐量和定时保证的服务。但今天的因特网能为时间敏感应用提供满意的服务。   
   因特网电话应用通常能容忍某些丢失但要求达到一定的最小速率，故运行在UDP上。如果UDP通信失败则TCP做备份

 2.1.5应用层协议

 前面学习了通过将报文发送进套接字实现网络进程间的相互通信。而应用层协议清楚定义了进程如何互相传递报文，也就是报文的细节：报文类型、语法、语义、响应规则。

应用层协议只是应用程序的一部分。

2.2Web和HTTP

新型应用万维网World Wide Web
Web及其协议作为平台，为许多应用服务

HTTP仅定义在客户程序以及服务器程序之间的通信协议，并不在意浏览器如何解释web页面

2.2.1HTTP概况

Web的应用层协议是超文本传输协议HTTP，由两个程序实现：客户程序、服务器程序，通过交换HTTP报文进行会话。HTTP定义了报文的结构以及客户和服务器进行报文交换的方式

• Web页面（文档）由对象组成
• 对象：一个文件，可以是HTML文件、JPEG图形……。他们通过URL地址寻址
• 多数Web页面有一个HTML基本文件以及几个引用对象，HTML基本文件通过URL引用对象
• URL地址由存放对象的服务器主机名以及对象的路径名组成 
• Web浏览器实现了HTTP客户端，故称为客户
• Web服务器实现了HTTP服务器端，存储WEB对象

 HTTP使用TCP作为他的支撑运输协议。提供了可靠数据传输服务，每个HTTP报文都能完整地被接收。这就是分层体系结构最大的优点：即HTTP协议不用担心数据丢失，也不关注TCP在数据丢失和乱序故障中恢复的细节，这是TCP以及协议栈较低层协议的工作

 2.2.2非持续连接和持续连接

背景：许多因特网应用中，客户和服务器在相当长的时间范围内通信，其中一系列请求会间断性一个个发送或规则的间隔周期性发送。此时，如果使用TCP进行交互，每个请求响应对是经过一个单独的TCP连接发送（非持续连接）还是所有报文都经过相同的TCP发送（持续连接）

HTTP对于这两种连接都可以使用

RTT往返时间：短分组从客户到服务器然后再返回客户的时间

1. 非持续连接HTTP：总的响应时间为两个RTT+服务器传输HTML文件的时间
   缺点：①必须为每一个对象建立和维护一个全新的连接，这样服务器需要分配缓冲区，有着严重的负担②每一个对象要两个RTT的交付时延。一个RTT创建TCP，另一个用于请求和接收对象。
2. 持续连接HTTP1.1：保持TCP连接打开。流水线式：对对象的请求可一个接一个的发出，而不必等待未决请求的回答。

 2.2.3HTTP报文格式

HTTP请求报文 

•  实体体在使用POST方法时才使用，在提交表单时使用（但是提交表单不一定要用POST，也可以使用GET）
• HEAD调试跟踪
• PUT上传对象到服务器中
• DELETE允许删除服务器的对象

 HTTP响应报文

实体体部分是报文的主要部分，包含了所请求的对象本身 

例子见教材

状态码如下

 如何决定首部行有哪些内容呢？和浏览器以及服务器本身配置有关

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

HTTP服务器并不保存关于客户的任何信息，HTTP是一个无状态协议。简化了服务器的设计。

we但web服务器通常希望能识别客户，所以使用cookie

cookie技术有四个组件：

1. 响应报文（set-cookie:  ）和请求报文(cookie:  )中的一个cookie首部行
2. 用户端系统保留一个cookie文件，由用户的浏览器进行管理
3. 位于web站点的一个后端数据库

cookie跟踪例子见教材

cookie可以用于标识一个用户。可以在无状态的HTTP之上建立一个用户会话层

2.2.5web缓存

web缓存器也叫代理服务器。可以通过配置浏览器使得所有HTTP请求报文首先指向Web缓存器

Web缓存器使用过程实例 见教材

两个原因：减少响应时间、减少接入链路到因特网的通信量

升级链路带宽vs增加web缓存器的例子：web缓存器情况下的响应时延低于升级链路的时延

CDN内容分发网络 即地理上安装的分散缓存器，使大量流量实现本地化

2.2.6条件GET方法

存储在缓存器中的对象副本可能是陈旧的 。所以HTTP允许缓存器证实他的对象是否是新的

方法为GET +首部行"if-modified-since"+之前收到响应报文的last modified的时间

如果该对象没有被修改，那么服务器返回一个空实体的响应报文（304 not modified）（如果包含该对象，则只会浪费带宽，并增加用户感受到的响应时间），告诉缓存器可以转发存储的对象副本

2.3电子邮件

3个组成部分：用户代理（允许用户阅读回复转发保存攥写报文）、邮箱服务器（有邮箱和外出报文队列（如果交付失败，则保持报文稍后尝试重发））、简单邮件传输协议SMTP （使用TCP可靠数据传输服务，在邮件服务器之间传输，有两个部分：运行在发送方邮件服务器的客户端以及运行在接收方邮件服务器的服务器端）

2.3.1SMTP

SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器，也用来从发送方用户代理传送到发送方邮件服务器

限制所有邮件报文的体部分只能采用7bitASCII码表示。多媒体数据需要从二进制转化成7bitASCII码，传输后再解码还原成多媒体数据。然而HTTP传送前不需要编码成ASCII码

SMTP基本操作（SMTP命令，是握手协议的一部分）见教材

SMTP一般不使用中间邮件服务器发送邮件

SMTP是如何将报文在邮件服务器之间进行传输的？

客户SMTP现在25号端口建立一个到服务器SMTP的TCP连接（如果服务器SMTP没开机，则稍后尝试连接）。建立完连接后（运输层的连接），执行应用层的握手，指示发送方、接受方的邮件地址，之后，再进行传输报文（持续TCP连接，如果客户（SMTP客户，也就是发送方邮件服务器）还有其它报文要发送可以在相同TCP连接上继续传输，最后TCP连接关闭）。

SMTP客户与SMTP服务器之间交换报文文本的例子 见教材 

注意，客户每发送一条命令，服务器都会做出回答。

每个邮件由MAIL FROM开始到.结束

如果发送邮件服务器有多个报文要发送到同一个接收端，由于SMTP用的是持续连接，所以发送完所有的报文才会发送QUIT

2.3.2与HTTP的对比 

共同点：都用于传送回文件（HTTP报文和对象，电子邮件报文） ，持续连接

区别：

1. HTTP拉协议、SMTP推协议；
2. SMTP报文要求使用7bitsASCII码（如果包含非7bitsASCII码，则要进行编码）
3. HTTP把每个对象封装到HTTP响应报文中，而SMTP将所有报文对象放在一个报文

2.3.3邮件报文格式 

电子邮件报文本身 

2.3.4邮件访问协议 

过去，客户都是直接登录到服务器主机运行邮件阅读程序的 。今天，邮件访问采用客户-服务器体系结构。

如果在本地PC放置一个邮件服务器，由于个人PC不可能24小时一直在线，所以接收方通过用户代理访问存储在总是保持开机的共享邮件服务器上的邮箱

客户要将邮件发送到目的地接收邮件服务器的话，需要经过两步。需要经过自己的邮件服务器中继，否则用户代理没有办法到达目的地接收服务器？

 邮件访问协议：POP3,IMAP,基于web的电子邮件HTTP（gmail，雅虎）  用于将邮件从接收方邮件服务器传送到接收方用户代理（图2-16）

2.4DNS：因特网的目录服务

2.4.1DNS提供的服务

DNS域名系统的主要任务：主机名（域名）（人喜欢）<->IP地址（路由器喜欢） 

DNS是：①由分层的DNS服务器实现的分布式数据库②一个使主机能查询该分布式数据库的应用层协议 （1.客户-服务器体系结构运行在端系统之间2.端系统之间通过下面的运输协议UDP传送DNS报文）DNS不是一个与用户打交道的应用，是为用户应用程序提供核心功能的应用。

DNS通常是由其他应用层协议所使用的，如hTTP协议使用DNS服务具体例子见教材

DNS除进行主机名和IP地址的转换外，还有其他功能：主机别名、邮件服务器别名、分配负载。

2.4.2 DNS工作机理

集中式DNS服务器存在许多问题。

1. 分布式、层次数据库：三种类型的DNS服务器+本地DNS服务器 递归+迭代查询 中间DNS服务器为多层权威DNS服务器的表示
2. DNS缓存：在本地DNS服务器中 。改善时延性能并减少因特网中DNS报文数量 。映射不是永久的。能够缓存TLD服务器的IP地址，所以很少询问根DNS服务器

2.4.3DNS记录和报文

记录：

DNS服务器存储了资源记录RR 四元组  type=A、NS、CNAME、MX

邮件服务器和其他服务器可以使用相同主机名（别名）。但规范主机名不同。

如果一台DNS服务器是用于某主机的权威DNS服务器，则返回A记录。否则，返回NS+A两条记录

DNS报文：DNS查询报文和DNS回答报文

DNS数据库中插入记录：需要向注册登记机构提供我的权威DNS服务器的名字和IP地址（NS(主机名->DNS服务器名)、A（DNS服务器名，IP地址））。以及web服务器的类型A资源记录    还有邮件服务器的类型A资源记录

2.5P2P文件分发

客户-服务器体系结构极大的依赖于总是打开的基础设施服务器。

两种体系结构之间在文件分发中的对比。向大量主机（对等方集合）分发文件

1.P2P体系结构的扩展性：对于任意对等方数量N，最小分发时间总是有界的。因为对等方除了是比特的消费者还是比特的重新分发者

2.BitTorrent：用于文件分发的P2P协议 基本概念 请求哪些块？（最稀缺优先：针对自己没有的块里面邻居中副本最少的块） 响应哪些请求呢？（提供给以最高速率发送文件的4个邻居+1个试探的对等方） ”一报还一报“

3.P2P另一个应用DHT

2.6视频流和内容分发网

2.6.1因特网视频

比特流可以权衡视频的质量。可通过压缩比特率来压缩视频。平均端到端吞吐量应与视频比特率一样大

 2.6.2HTTP流和DASH

流式视频：字节

HTTP流对所有客户都发送相同编码的视频

经HTTP的动态适应性流（DASH）允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频块

2.6.3CDN内容分发网

建立单一的大规模数据中心会出现三个问题。

故建立一个分布网

CDN管理分布在多个地理位置的服务器，服务器存储视频、并将每个用户请求定向到一个将提供最好用户体验的CDN位置 

CDN有两种服务器安置原则：深入、邀请做客

CDN操作细节：截获用户请求、确定适合的服务器集群、将请求重定向到适合的集群服务器

1. CDN利用DNS来截获、重定向
2. 集群选择策略：客户发来DNS查找，可得知LDNS的IP地址。据此来选择集群①地理上最为临近②实时测量

2.6.4学习案例 

1. Netflix：CDN分发视频，适应性流DASH，不需要DNS重定向来连接CDN服务器，直接通过亚马逊云告知CDN服务器的IP地址，推高速缓存（内容在非高峰时段推入服务器）
2. YouTube：CDN分发视频，需要DNS重定向，HTTP流，
3. 看看：P2P交付。现在采用混合CDN-P2P流式系统。在视频开头用CDN服务器请求内容，后期使用P2P交付（如果P2P流量充分，否则采用混合流式）

2.7套接字编程：生成网络应用

 操作止步于选择TCP/UDP，在套接字之上进行操作。