网络基础-应用层协议-HTTP/HTTPS

HTTP

基本概念

🚀超文本传输协议（Hypertext Transfer Protocol，HTTP）是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
🚀HTTP协议默认使用的80号端口。
🚀什么是URL：

URL（Uniform Resource Locator）是指统一资源定位符，是用于完整地描述Internet上网页和其他资源的地址的一种标识方法，也被称为"网址"。

🚀URL中的encode与decode:

encode:
像/ ？# &等这种符号在url中有特殊的意义。如果某个参数中存在这些符号，就要对这些字符进行转义。转义规则：将字符转化为对应的16进制，然后从右往左取4位，每2位做一位，前面加上%->%AB%CD
decode:就是encode的逆过程

协议格式

请求报文

🚀请求报文主要分为四个部分：

1. 请求行
2. 请求头信息
3. 空行（用于分割报头与有效载荷）
4. 有效载荷

每一部分通过换行符分隔

🚀请求行的格式：请求方法 请求资源地址 协议版本

请求方法

其中请求方法包括GET/POST/PUT/DELETE等
GET：获取一个静态网页/也能用于提交参数
POST：创建新的资源/提交某种数据例如，登录注册都是用POST方法提交参数
PUT：用于更新服务器上的某种资源
DELETE：用于删除服务器上的某种资源

GET与POST的异同
相同点：二者都可以用于提交参数。
不同点：GET方法提交的参数是通过URL的方式，且提交的参数大小上限为1024字节。POST方法提交参数是放到报文的有效载荷中的，相比于GET方法POST提参的方式更加私密但是二者都是不安全的，至少要经过加密处理。

请求资源地址

请求资源地址：/a/b/c/d.html
本质就是Web服务器下的某种资源的路径，其中第一个/，并不是我们服务器的根目录，而是Web根目录。

协议版本

协议的版本通常为HTTP1.0或者HTTP1.1

应答报文

🚀应答报文主要分为四个部分

1. 状态行
2. 响应头信息
3. 空行（由于报头与有效载荷分离）
4. 有效载荷

每一部分通过换行符分隔

🚀状态行的格式：协议版本 状态码 状态描述

常见Header

🚀无论是请求头信息还是响应头信息，其格式都是采用Key:Value的形式进行组织的。
🚀下面展示一些常见的头信息字段：

Content-Type:正文数据类型(text/html…) — 根据需要进行查询即可
Content-Length:正文的长度
Host:ip地址+端口号 — 客户端告诉服务器，它所请求的是哪个主机的哪个端口
User-Agent:声明客户端的操作系统和浏览器版本
Location:通常与状态码3XX搭配使用，告诉客户端接下来去哪里访问
Cookie:将用户的信息告诉客户端，客户端将信息临时存储在本地，通常与Session搭配使用。
Set-Cookie:在响应报文中服务器设置Cookie信息返回给客户端
Etag:将请求资源的唯一标识返回给客户端

断点续传功能的实现
所谓断点续传就是客户端从服务器上下载某种资源时，由于网络出现问题导致下载终止，那么网络恢复时只需接上上次下载的位置继续下载即可，不用从头开始下载。
🚀实现逻辑：

服务器设置Etag字段，告诉客户端它请求资源的唯一标识
当遇到突发情况下载中断，然后恢复时，继续下载
客户端设置If-Range字段，内容就是下载资源的唯一标识
客户端还会设置Range字段，Range字段的格式：bytes=xxx-yyy/文件总大小
xxx和yyy：请求资源的开始字节位置和结束字节位置
服务器收到If-Range字段时，会去检查客户端传来的If-Range对应的value内容与其请求的资源的唯一标识是否一致，如果一致那么再读取其Range字段，知晓具体请求的部分，返回即可，并设置状态码206。

常见状态码与状态描述

1XX：信息性状态码：通常表示请求正在处理
2XX：成功状态码

200：OK 表示请求成功。
202：Accepted 服务器已经接收到请求但是尚未处理完成

3XX：重定向状态码

301：Moved Permanently：永久重定向表示请求的资源已经重新分配URL，以后使用资源现有的URL去访问
302：Found：表示资源分配了新的URL，希望客户端本次使用新的URL去访问
307：Temporary Redirect ：与302相同都是临时重定向，下次客户端还是使用老的URL进行访问，但是302可能会使老的请求方法POST重定向为GET方法，但是307会禁止将POST方法重定向为GET方法。

4XX：客户端错误状态码

404：Not Found：表示请求的资源不存在
403：Forbidden：表示请求的资源被拒绝

5XX：服务器错误状态码：

500：Internal Server Error：表示请求时服务器内部发生错误

Cookie&Session

🚀Http本身是无状态的，但是用户希望有会话保持的功能。Cookie实现原理：用户在第一次访问服务器时，服务器会通过设置Set-Cookie字段的方式将用户的信息，返回给客户端，浏览器会将用户的信息进行本地保存（可能是内存，也可能是文件级），当再次访问服务器时，浏览器会在本地读取用户信息，将用户信息提交给服务器，免去了用户再次认证的工作。
🚀Cookie&Session：单纯使用Cookie的方式可能中途被黑客劫持信息的情况，那么黑客就能获取用户的账号密码等信息，如果用户的其他应用使用的也是同样的账号密码，那么造成用户的损失是较大的，进而产生了Cookie+Session的方式，用户在第一次访问服务器的时候，在服务器端会创建一个Session对象（用于存储用户信息）存储在服务器端（内存级或者是文件级），并且产生与Session对象一一对应的Sessionid，通过设置Set-Cookie字段将Sessionid返回给客户端，这样在客户端存储就是一个Sessionid并没有直接存储用户的信息。

http协议特点

1.Http协议是明文传送，是不安全的，后面的Https协议就是对Http协议进行加密处理
2.Http是无连接的：指的是只有当客户端请求时才会建立连接，请求完毕后就是释放连接。这样可以把资源尽快的释放出来，服务于其他客户端。Http及时的释放连接可以大大提高服务器的执行效率
3.Http是无状态的：Http协议本身是无状态的，即服务器不会保留与客户端交易时的任何状态信息，每一次请求都是独立的。这样能够减轻服务器的记忆负担，提高响应速度。

HTTPS

基本概念

🚀HTTPS （全称：Hypertext Transfer Protocol Secure ），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 。

🚀HTTPS协议默认使用的是443端口。

对称加密与非对称加密

🚀对称加密：同一个密钥可以同时作用于信息的加密和解密。
🚀对称加密的特点：计算量小，速度快，效率高。常见算法：DES。

例如，客户端发送一个数字6，使用对称加密算法，加密后的密文为6^8，服务器得到这个密文后，用同样的密钥进行解密，6 ^ 8 ^ 8 = 6.通过异或来加密就是典型的对称加密。
🚀非对称加密：用两个密钥进行加密和解密：公钥和私钥。并且用公钥加密的密文只能用私钥来解密，反之通过私钥加密的数据只能通过公钥来解密。
🚀非对称加密的特点：算法强度复杂，加密速度没有对称加密速度快。常见算法：RSA

数据摘要&数据指纹

🚀数据摘要&数据指纹：原理就是通过单项的散列函数对数据进行运算，生成一段固定长度的数据摘要。但是这并不是一种加密机制，因为没有解密，但是可以用来判断一份数据有没有被篡改，一份数据中只要有一个字母被修改那么形成的数据摘要就有很大的差距。常见算法：MD5。

🚀数据摘要的应用场景举例：

1.账号的登录注册，用户的密码是存储在公司的数据库中的，但是一定不是明文保存，因为一旦数据库泄漏那么产生的影响较大，所以一般在公司数据库中存储的都是用户密码的数据摘要，当用户登陆时，通过对用户输入的密钥进行摘要然后与数据库中存储的数据进行对比。

2.百度网盘的秒传原理：用户在百度网盘上传一份资源后，这份资源会被存储在百度的某个数据库中，并且会给这份资源生成一份数据摘要。例如：用户1在百度网盘中上传了一部电影，用户2上传了一部与用户1同样的电影，百度网盘会先将用户2上传的电影做一次摘要，与数据库中已上传的资源做对比，如果相同证明数据库中已经存在这个数据了，直接建立一个软连接即可。

HTTPS工作过程探究

🚀既然HTTPS协议是对HTTP协议的改进，对数据进行了加密，下面来探究以下HTTPS工作过程。

只采用对称加密

🚀这总方式存在明显的安全漏洞：客户端与服务器如何做到使用同一个密钥？先通过发送一个报文告诉对方使用的密钥是什么？这种方式过于简单，一旦被报文被黑客劫持，那么加密就没有意义。

只采用非对称加密

🚀服务器产生一对密钥，将公钥发送给客户端，客户端以后发送的数据都要先通过公钥加密，这样只有服务器端才能够，对报文解密，同样服务器端发送的数据只有客户端才能解密。这种方式同样存在安全漏洞，无法保证服务器将密钥发送到客户端过程的安全性。

双方都采用非对称加密

🚀客户端与服务器都生成一对密钥，然后交换公钥，这样服务器发送的数据只有客户端能够解密，客户端发送的数据只有服务器能够解密。但是无法避免中间人攻击行为，且都才用对称加密的效率过低。

对称加密+非对称加密

🚀服务器端生成一对密钥，将公钥发送给客户端，客户端在本地生成对称加密密钥，将客户端生成的密钥通过服务器的公钥进行加密发送给服务器，以后双方都采用对称加密的方式进行加密通信，效率对比上一种方式有所提升，但是仍然无法避免中间人攻击的行为。

双方都采用非对称加密&对称加密+非对称加密-共同的弱点

两种方式都存在同样且致命的问题：客户端无法判断收到的公钥确实是来自服务器的，如果这个公钥是来自中间人的，那么这种加密方式就毫无意义。

中间人攻击

🚀以对称加密+非对称加密收到中间人攻击的过程：
🚀服务器生成一对密钥S/S’，服务器将S’密钥发送给客户端，但是不幸报文被黑客截获，这个黑客产生一对密钥R/R’，将R’公钥发送给客户端，这时客户端不能区分这个公钥是否来自于服务器，客户端会生成对称加密密钥，通过R’发送给服务器，实际上是发给了中间人，这时，中间人再生成一个对称加密密钥X，将X发送给服务器，这样这个中间人就夹在了客户端与服务器之间，既可以得到服务器发送给客户端的数据，也可以得到客户端发送给服务器的数据。

受到中间人攻击的本质：客户端无法辨认收到的公钥是否真正的来自服务器端。

证书/CA认证

数据签名

🚀数据签名是基于非对称加密，对数据摘要进行加密后的结果就叫做数据签名。
🚀CA证书签名形成过程：CA机构有自己的公钥和私钥，私钥是不对外公布的，CA机构的公钥在浏览器中是内置的，CA机构会对服务端申请的证书内容进行Hash运算得到的数据摘要通过CA机构的私钥进行加密，得到数据简明。

CA认证过程

🚀服务端在使用HTTPS协议之前要先向CA机构发送一份CSR文件，来申请证书，证书内容包括，签发机构，有效期，服务端使用的域名，公钥，等信息。证书还需要一个数据签名，数据签名=对证书内容进行摘要后使用CA机构的私钥进行加密后的结果。

最终方案

🚀客户端在访问服务器时，服务器会首先将证书发送给客户端，其中就包括服务端的公钥。
🚀客户端识别证书的过程：1.判断证书是否还在有效期内。2.判断证书的签发机构是否受信任（操作系统中已经内置了受信任的证书签发机构）3.对证书的数据签名使用CA机构的公钥解密得到证书内容的数据摘要，然后通过同样的Hash算法对本证书的内容做数据摘要，比对两份摘要是否一致。4.还要比对证书上的域名与之前访问的域名是否一致以防中间人掉包整个证书。

使用最终方案的一些问题

中间人篡改证书怎么办？

🚀1.篡改证书内容：客户端收到证书后，会对证书的内容做Hash得到数据摘要，与数据签名解密后的摘要做对比，如果篡改了证书内容，两个摘要就会匹配不成功的。
🚀2.篡改整个证书的内容：中间人将证书的内容修改后，并且对内容做一次摘要，并且对摘要做数据签名，发送给客户端。这样做客户端也是能察觉出来的，因为客户端使用的是CA机构的公钥对数据签名解密的，如果中间人篡改了证书的数据签名的话，是解密不成功的。

中间人掉包整个证书怎么办？

🚀首先中间人没有能力制造假的证书，因为浏览器都是使用的CA机构的公钥对数据签名做解密的，如果使用假的证书，浏览器会解密失败的。那么中间人就要申请真的CA证书，那么中间人就要向CA机构提供自己的各种信息，相信他也不会这么做，即使这么做了之后，同样会出现问题，浏览器识别到证书中的域名与自己想访问的域名不一致，也会识别证书失败的。

为什么使用数据签名？

🚀防止中间人改掉证书的内容，然后重新生成一份摘要。

为什么不直接加密，而是对摘要加密？

🚀缩小密文的长度，加速密文的加密和机密提高效率。

HTTPS协议使用到的密钥

🚀一共设计到三组密钥：1.CA机构的公钥和私钥。2.服务器端生成的一对非对称加密密钥。3.客户端生成的对称加密密钥。 最终服务器与客户端之间使用的是客户端生成的对称加密密钥进行通信的，前两个密钥都是为了保证这个对称加密密钥的可靠性。