计算机网络系列文章(五)应用层

计算机网络系列五篇文章传送门

1. 概述篇
2. 网络接口层
3. 网络层
4. 传输层
5. 应用层(本文)

概述

应用层包含了OSI七层模型的会话层、表示层和应用层。应用层为传输层以及以下的层提供完整的通信服务，是面向用户的一层。

应用层主要定义应用间通信的规则：

• 应用进程的报文类型（请求报文、应答报文）
• 报文的语法、格式
• 应用进程发送数据的时机、规则。

应用层是距离我们使用最近的，我们需要什么样的服务就使用什么样的协议，发邮件就使用Smtp协议，传输文件使用FTP，打开网页使用http，但是DNS协议却是所有上层协议都必须要使用的，另外http协议非常重要也会介绍。

DNS协议

DNS即域名系统（Domain Name System），它是：

• 一个由分层的DNS服务器实现的分布式数据库
• 一个使得主机能够查询分布式数据库的应用层协议

简单来说，人们很难记住IP数字地址，于是可以将数字地址转换为简单易记名词的域名系统，DNS的任务就是将域名解析为IP。

域名由点、字母和数字组成。点分割不同的域，域名可以分为顶级域、二级域、三级域，如www.taobao.com：

• 顶级域com
• 二级域taobao
• 三级域www

顶级域有cn（中国）、us(美国)、com（公司）和gov（政府）等。

DNS采用分布式层次数据库，没有一台DNS服务器拥有因特网上所有主机的映射，相反这些映射分布在所有DNS服务器上。DNS服务器类型有三种：根DNS服务器、顶级域(TLD)DNS服务器、域名服务器。

DNS域名解析流程是怎样的？

以www.baidu.com为例：

上图中分 8 个步骤介绍了域名解析的流程，但在此之前会先检查本机的缓存配置和hosts解析， 然后才真正执行上图的流程：

• 客户端通过浏览器访问域名为 www.baidu.com 的网站，发起查询该域名的 IP 地址的 DNS 请求。该请求发送到了本地 DNS 服务器上。本地 DNS 服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果。如果没有，本地 DNS 服务器还要向 DNS 根服务器进行查询。
• 本地 DNS 服务器向根服务器发送 DNS 请求，请求域名为 www.baidu.com 的 IP 地址。
• 根服务器经过查询，没有记录该域名及 IP 地址的对应关系。但是会告诉本地 DNS 服务器，可以到域名服务器上继续查询，并给出域名服务器的地址(.com 服务器)。
• 本地 DNS 服务器向 .com 服务器发送 DNS 请求，请求域名 www.baidu.com 的 IP 地址。
• com 服务器收到请求后，不会直接返回域名和 IP 地址的对应关系，而是告诉本地DNS 服务器，该域名可以在 baidu.com 域名服务器上进行解析获取 IP 地址，并告诉 baidu.com 域名服务器的地址。
• 本地 DNS 服务器向 baidu.com 域名服务器发送 DNS 请求，请求域名 www.baidu.com 的 IP 地址。
• baidu.com 服务器收到请求后，在自己的缓存表中发现了该域名和 IP 地址的对应关系，并将 IP 地址返回给本地 DNS 服务器。
• 本地 DNS 服务器将获取到与域名对应的 IP 地址返回给客户端，并且将域名和 IP 地址的对应关系保存在缓存中，以备下次别的用户查询时使用。

DHCP协议

DHCP(Dynamic Host Configuration Protocol: 动态主机设置协议)是一个局域网协议，是应用UDP协议的应用层协议。它主要用于为内部网络或网络服务供应商自动分配IP地址，其默认监听端口为67。

加入一台电脑A连接wifi后：

• 电脑A使用UDP协议广播DHCP发现报文
• DHCP服务器发出DHCP提供报文
• 电脑A向DHCP服务器发出DHCP请求报文
• DHCP服务器回应并提供IP地址

HTTP协议

HTTP是Hyper Text Transfer Protocol的缩写，该协议是用于从万维网服务器传输超文本到本地浏览器的传送协议，且它是基于TCP/IP通信协议来传递数据。简单来说，它就是一种约定协议，一种客户端跟服务端之间的约定协议。

HTTP协议的特点

• 简单快速-每个资源固定（URI）
• 灵活-能完成不同数据类型传输
• 无连接-连接一次就会断开，不会保持连接
• 无状态-服务端不保存客户端状态

报文的组成

1. 请求报文：

2. 相应报文：

3. 方法：

HTTP 协议中定义了9种方法来表明对Request-URI指定的资源的不同操作方式，其中HTTP1.0 定义了3种请求方法： GET, POST 和 HEAD 方法，HTTP1.1 新增了6种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法

• GET：向特定的资源发出请求
• POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改
• HEAD：向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息
• OPTIONS：返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送的请求来测试服务器的功能性
• PUT：向指定资源位置上传其最新内容
• PATCH：是对 PUT 方法的补充，用来对已知资源进行局部更新
• DELETE：请求服务器删除 Request-URI 所标识的资源
• CONNECT：HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
• TRACE：回显服务器收到的请求，主要用于测试或诊断

4. 首部（请求头/响应头）：

请求首部

响应首部

通用首部

实体首部

5. 状态码：

状态码表示了响应的一个状态，可以让我们清晰的了解到这一次请求是成功还是失败，如果失败的话，是什么原因导致的，当然状态码也是用于传达语义的。如果胡乱使用状态码，那么它存在的意义就没有了。

2XX 成功

• 200 OK，表示从客户端发来的请求在服务器端被正确处理
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
• 206 Partial Content，进行范围请求

3XX 重定向

• 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
• 302 found，临时性重定向，表示资源临时被分配了新的 URL
• 303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
• 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
• 307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX 客户端错误

• 400 bad request，请求报文存在语法错误
• 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

• 500 internal sever error，表示服务器端在执行请求时发生了错误
• 501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
• 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

同样是重定向307，303，302的区别？

• 302是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码又出来了两个303和307。
• 303明确表示客户端应当采用get方法获取资源，他会把POST请求变为GET请求进行重定向。 307会遵照浏览器标准，不会从post变为get。

持久连接

HTTP请求都要经过TCP三次握手建立连接，四次分手断开连，如果每个HTTP请求都要建立TCP连接的话是极其费时的。

请求头中的 Connection: keep-alive 的作用可以在请求完成后，保持TCP连接一段时间而不关闭， 如果这个期间又有HTTP请求的话，直接使用这个TCP连接，省去了建立新的连接的时间。大大减少了连接的建立以及关闭时延。

HTTP/1.1中浏览器默认开启了Connection: keep-alive。服务端可以设置 Connection: close 来关闭持久连接。

通过设置 timeout，一定时间后在此 TCP 连接没有请求就会关闭。

同时服务端还会设置一个参数叫最大请求数，比如当最大请求数是300时，只要请求次数超过300次，即使还没到超时时间，服务端也会主动关闭连接。

不同 ID 代表不同的 TCP 连接。不同域名需要分别创建 TCP连接。TCP 请求的连接有先后顺序，无法并发执行。浏览器允许并发创建 TCP，如Chrome 允许最多6个并发。

在HTTP2里面有个信道复用的概念，在TCP/IP连接上面，可以并发的发送HTTP请求。在我们连接网站的时候，只需要一个TCP连接。如果不同域，则会有多个TCP连接。

HTTPS协议

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

HTTPS的作用：

• 内容加密建立一个信息安全通道，来保证数据传输的安全；
• 身份认证确认网站的真实性
• 数据完整性防止内容被第三方冒充或者篡改

HTTPS和HTTP的区别：

• https协议需要到CA申请证书。
• http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

SSL与TLS

HTTPS 还是通过了 HTTP 来传输信息，只是信息通过SSL/ TLS 协议进行了加密。

SSL (Secure Socket Layer，安全套接字层)：

SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3.0版本。

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TSL (Transport Layer Security，传输层安全协议)：

用于两个应用程序之间提供保密性和数据完整性。

TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL/TLS协议作用：

• 认证用户和服务器，确保数据发送到正确的客户机和服务器；
• 加密数据以防止数据中途被窃取；
• 维护数据的完整性，确保数据在传输过程中不被改变。

SSL/TLS的握手过程

1. 客户端首次发出请求

由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。

客户端需要提供如下信息：

• 支持的协议版本，比如TLS 1.0版
• 一个客户端生成的随机数，稍后用于生成”对话密钥”
• 支持的加密方法，比如RSA公钥加密
• 支持的压缩方法

2. 服务端首次回应

服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端，这里的随机数是整个过程的第二个随机数。

服务端需要提供的信息：

• 协议的版本
• 加密的算法
• 随机数
• 服务器证书

3. 客户端再次回应

客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。 客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。

ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。

4. 服务器再次响应

服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。

5. 后续客户端与服务器间通信

确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。

值得特别提出的是： SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。