HTTP请求过程HTTPSTLS原理

网络分层模型

OSI七层模型

OSI 七层协议实现起来过分复杂，而且运行效率很低；制定标准的周期太长，当OSI 国际标准制定出来时，基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了。OSI 七层模型虽然失败了，但是却提供了很多不错的理论基础。为了更好地去了解网络分层，OSI 七层模型还是非常有必要学习的。

• 应用层
• 表现层
• 会话层
• 传输层
• 网络层
• 数据链路层
• 物理层

TCP/IP四层协议

• 应用层
• 传输层
• 网络层
• 网络接口层

HTTP超文本传输协议

1. 域名解析 ，解析出对应IP地址
2. 解析成功之后，发起TCP三次握手建立连接
3. 建立连接后发起HTTP请求
4. 服务器响应HTTP请求，浏览器得到html代码
5. 浏览器解析html代码，并请求静态资源(html/css/js等)
6. 然后浏览器渲染，展示给用户

域名解析过程

1.浏览器dns缓存; 

2.系统dns缓存; 

3.网络配置中的LocalDNS服务器（80%这一步就找到了）; 

4.根域名服务器(由LocalNDS请求并返回5的地址); 

5.主域名/顶级域名服务器(全球只有几台/由LocalDNS请求并返回6的地址); 

6.NameServer注册域名服务器(就是你注册域名的服务提供商) 

HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive ，这样的话建立的连接就可以在多次请求中被复用了。

HTTP/1.0 和HTTP/1.1

1. 连接方式 : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
2. 状态响应码 : HTTP/1.1中新加入了大量的状态码。
3. 缓存处理 : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用 :HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
5. Host头处理 : HTTP/1.1在请求头中加入了Host字段。

Cookie和Session

1. Cookie技术

Cookie是HTTP报文的一个请求头，Web应用可以将用户的标识信息或者其他一些信息（用户名等）存储在Cookie中。用户经过验证之后，每次HTTP请求报文中都包含Cookie，这样服务器读取这个Cookie请求头就知道用户是谁了。Cookie本质上就是一份存储在用户本地的文件，里面包含了每次请求中都需要传递的信息。

2. Session技术

由于Cookie以明文的方式存储在本地，而Cookie中往往带有用户信息，这样就造成了非常大的安全隐患。而Session的出现解决了这个问题，Session可以理解为服务器端开辟的存储空间，里面保存了用户的状态，用户信息以Session的形式存储在服务端。当用户请求到来时，服务端可以把用户的请求和用户的Session对应起来。那么Session是怎么和请求对应起来的呢？答案是通过Cookie，浏览器在Cookie中填充了一个Session ID之类的字段用来标识请求。

URI 和 URL 的区别是什么?

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。

URI 的作用像身份z号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

状态码分类

• 1** Informational信息（服务器收到请求，需要请求者继续执行 *** 作）
• 2** Success成功（ *** 作被成功接收并处理）
• 3** Redirection重定向（需要进一步的 *** 作以完成请求）
• 4** ClientError客户端错误（请求包含语法错误或无法完成请求）
• 5** ServerError服务器错误（服务器在处理请求的过程中发生了错误）

HTTPS

HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证，解决了 HTTP 数据透明的问题。默认端口号是 443。

SSL 和 TLS 的区别 （没有太大区别）

SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷。

很快，在 1999 年，SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

SSL 和 TLS加密原理

HTTPS采用混合加密算法，即共享秘钥加密（对称加密）和公开秘钥加密（非对称加密）。TLS可以简单分为两步：1密钥交换；2数据加密。

非对称加密采用两个密钥(一个公钥，一个私钥)。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者所知。非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。

在双方通信之前，需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的，传输报文对任何人是可见的，密钥的交换肯定不能直接在网络信道中传输。因此，使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样，通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。 

为了公钥传输的信赖性问题，第三方机构应运而生——证书颁发机构（CA，Certificate Authority）。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书，证书存储在服务器上，并附有 CA 的电子签名。当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

带有证书的公钥传输机制(SSLClient-SSLServer握手过程)

 [事前两点准备工作]：

• 数字证书认证机构的公开秘钥（CA公钥）已事先植入到浏览器里；
• 数字证书认证机构用自己的私有密钥对服务器的公开秘钥摘要做数字签名，生成公钥证书，并颁发给服务器。

参考：SSL：握手过程详解 - 知乎

1. client--->server：Client hello

• Version: TLS 1.2：客户端使用的 TLS 版本号。
• Session ID：会话 ID，首次连接时该字段为空，即 Session ID Length 为 0。表示客户端告诉服务器是新的会话，没有其他会话要恢复。在后续的连接中，这个字段可以保存会话的唯一标识。服务器可以借助会话ID在自己的缓存中找到对应的会话状态。在会话恢复过程中会用到该字段，此时 Session ID 不为 0。
• Random：随机数，用于生成通信过程中的对称秘钥。前 4 个字节为 GMT Unix 时间信息，增强随机性。
• Cipher Suite：客户端支持的加密套件列表。一个加密套件是一个四件套，包含四个功能：密钥交换算法、身份认证算法 、对称加密算法和信息摘要算法。
• Compression：客户端支持的压缩算法。如果为null，表示没有使用压缩算法。
• Extensions：扩展。可包含多个该字段。

2. server--->client：Server hello

• Version：确定通信使用的 SSL 版本号。
• Random：随机数，用于生成通信过程中的对称秘钥。
• Cipher Suite：选择使用的加密套件。服务器从 Client Hello 的 Cipher Suite 中选择一个密码套件。如果没有可选择的，即服务器不支持客户端的加密套件，那么服务器返回握手故障并且断开连接。
• Session ID：如果 Client Hello 中的该字段不为 0，那么服务器就在以前缓存的会话中查找该会话，找到后就恢复会话。如果 Client Hello 中的该字段为 0，那么服务器就重新建立一个会话，并把该字段赋值。

3. server--->client：Certificate

• 服务端证书（server.crt）：客户端用此证书验证服务端是否合法。

4. server--->client：Server Key Exchange

该帧只存在于秘钥交换算法（Key Exchange）为 DH 或 ECDH 的帧中。如果秘钥交换算法为 RSA，那么此帧不存在。

5. server--->client：Certificate Request

该帧存在于双向验证过程中，用于请求客户端证书。

6. server--->client：Server Hello Done

通知客户端 Server Hello 相关的信息已经发送完成。

7. client--->server：Client Key Exchange

RSA Key Exchange：

• 客户端产生预主秘钥（pre-master secret)，使用从服务器证书中得到的公钥（public key）加密预主秘钥后发往服务器；
• 服务器收到加密后的预主秘钥后，使用其私钥将其解密。
• 此时，客户端和服务器都有客户端随机数，服务器随机数，预主秘钥。双方使用这三者产生通信过程中的主秘钥（master secret）；
• 双方互相发送 Change Cipher Spec 和 Encrypted Handshake Message。

DH（ECDH）Key Exchange：

• 服务器使用其私钥将客户端随机数，服务器随机数，服务器 DH（ECDH）参数签名，生成服务器签名，发向客户端（Server Key Exchange）；
• 客户端使用服务器发送过来的公钥和签名得到服务器 DH 参数；
• 客户端向服务器发送 DH 参数（Client Key Exchange)；
• 双方使用客户端 DH 参数，服务器 DH 参数生成预主秘钥。然后使用客户端随机数，服务器随机数，预主秘钥产生主秘钥；
• 双方互相发送 Change Cipher Spec 和 Encrypted Handshake Message。

8. client--->server：Certificate Verify

该帧存在于双向验证过程中，用于客户端自证该证书属于客户端。

9. client--->server：Change Cipher Spec

客户端告知服务器，客户端已经生成了主秘钥，并且后续的通信将使用该秘钥进行加密。

10. client--->server：Encrypted Handshake Message

这是客户端使用主秘钥加密的第一个数据，发向服务器。服务器使用此消息验证自身生成的主秘钥的正确性。

11. server--->client：Change Cipher Spec

服务器告知客户端，服务器已经生成了主秘钥，并且后续的通信将使用该秘钥进行加密。

12. server--->client：Encrypted Handshake Message

这是服务器使用主秘钥加密的第一个数据，发向客户端。客户端使用此消息验证自身生成的主秘钥的正确性。

双向认证和单项认证

双向认证一般是在客户端验证服务端的基础上，加上服务端对客户端的验证，这要求

1. 服务端明确提出要求，通过5.certificate request命令
2. 客户端发送证书（certificate命令）和证书验证（certificate verify命令）

会话密钥重用

SSL/TLS握手过程比较繁琐，同时非对称加解密性能比对称密钥要差得多；如果每次重建连接时都需要进行一次握手会产生较大开销，因此有必要实现会话的重用以提高性能。

常用的方式包括：

SessionID(RFC 5246)，客户端和服务端同时维护一个会话ID和会话数据状态；重建连接时双方根据sessionID找到之前的会话密钥实现重用；

SessionTicket(RFC 5077)，由服务端根据会话状态生成一个加密的ticket，并将key也发给客户端保证两端都可以对其进行解密。该机制相较sessionID的方式更加轻量级，服务端不需要存储会话状态数据，可减轻一定压力。

其它应用层协议

Telnet:远程登陆协议

SSH:安全的网络传输协议

Telnet 协议 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种非常安全的协议SSH所取代的主要原因。

FTP:文件传输协议

主要提供文件传输服务，基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽 *** 作系统和文件存储方式。