【大家好，我是爱干饭的猿，本文介绍应用层HTTP协议、HTTPS协议、当你在浏览器中输入网址后，到底发生了什么事情？HTTPS 如何进行的加密？对称加密、非对称加密、CA证书又是什么？

后续会继续分享Spring、SpringMVC、MyBatis及其他重要知识点总结，如果喜欢这篇文章，点个赞👍，关注一下吧】

上一篇文章：《【web】计算机网络网络层、应用层、数据链路层协议详解》

🚀1. HTTP 协议

1.1 什么是HTTP

HTTP (Hyper Text Transfer Protocol 全称为 “超文本传输协议”) 是一种应用非常广泛的应用层协议。

HTTP 往往是基于传输层的 TCP 协议实现的，(HTTP1.0, HTTP1.1, HTTP2.0 均为TCP, HTTP3 基于 UDP 实现) 目前我们主要使用的还是 HTTP1.1 和 HTTP2.0。

1.2 理解应用层协议

主要职责：描述业务

学过 TCP/IP , 已经知道目前数据能从客户端进程经过路径选择跨网络传送到服务器端进程 [ IP+Port ]，但是我们的任务并没有结束，我们把数据从A端传送到B端， TCP/IP 解决的是顺丰的功能，而两端还要对数据进行加工处理或者使用，所以我们还需要一层协议，不关心通信细节，关心应用细节！这层协议叫做应用层协议。

1.3 HTTP 协议格式

HTTP 是一个文本格式的协议. 可以通过 Chrome 开发者工具或者 Fiddler 抓包, 分析 HTTP 请求/响应的细节

抓包结果：

a. HTTP请求

编辑

首行: [方法] + [url] + [版本]
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用n分隔;遇到空行表示Header部分结束
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度;

b. HTTP响应

编辑

首行: [版本号] + [状态码] + [状态码解释]
Header: 请求的属性, 冒号分割的键值对;每组属性之间使用n分隔;遇到空行表示Header部分结束
Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有一个Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页面内容就是在body中

协议格式总结

编辑

为什么 HTTP 报文中要存在 “空行”?

因为 HTTP 协议并没有规定报头部分的键值对有多少个. 空行就相当于是 “报头的结束标记”, 或者是 “报头和正文之间的分隔符”

HTTP 在传输层依赖 TCP 协议, TCP 是面向字节流的. 如果没有这个空行, 就会出现 “粘包问题”

1.4 HTTP 请求 (Request)

1. 认识 URL

如何表达我们要请求哪个资源，就需要URL(Uniform Resource Locator 统一资源定位符)

统一资源标识符(Unique Resource ldentifier URI)，平时我们俗称的 “网址” 其实就是说的 URL，互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它。

URL 基本格式：

编辑

比如一个URL: https://www.ddd.com/web/login.html?userId=10000&classId=100

https : 协议方案名. 常见的有 http 和 https, 也有其他的类型
user:pass : 登陆信息. 现在的网站进行身份认证一般不再通过 URL 进行了. 一般都会省略
www.ddd.com : 服务器地址. 此处是一个 “域名”, 域名会通过 DNS 系统解析成一个具体的 IP 地址. (通过 ping 命令可以看到, v.bitedu.vip 的真实 IP 地址为 118.24.113.28 )
端口号: 上面的 URL 中端口号被省略了. 当端口号省略的时候, 浏览器会根据协议类型自动决定使用哪个端口. 例如 http 协议默认使用 80 端口, https 协议默认使用 443 端口
/web/login.html : 带层次的文件路径
userId=10000&classId=100 : 查询字符串(query string). 本质是一个键值对结构. 键值对之间使用 & 分隔. 键和值之间使用 = 分隔
片段标识: 此 URL 中省略了片段标识. 片段标识主要用于页面内跳转

URL哪些部分可以省略？

https://协议名: 可以省略, 省略后默认为 http://
ip 地址 / 域名: 在 HTML 中可以省略(比如 img, link, script, a 标签的 src 或者 href 属性). 省略后表示服务器的 ip / 域名与当前 HTML 所属的 ip / 域名一致
端口号: 可以省略. 省略后如果是 http 协议, 端口号自动设为 80; 如果是 https 协议, 端口号自动设为 443
带层次的文件路径: 可以省略. 省略后相当于 / . 有些服务器会在发现 / 路径的时候自动访问 /index.html
查询字符串: 可以省略
片段标识: 可以省略

2. 认识请求 “方法” (method)

编辑

GET 方法

GET 是最常用的 HTTP 方法. 常用于获取服务器上的某个资源. 在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求. 另外, HTML 中的 link, img, script 等标签, 也会触发 GET 请求。

GET 请求的特点

首行的第一部分为 GET
URL 的 query string 可以为空, 也可以不为空
header 部分有若干个键值对结构
body 部分为空
实际 URL 的长度取决于浏览器的实现和 HTTP 服务器端的实现

在浏览器端, 不同的浏览器最大长度是不同的, 但是现代浏览器支持的长度一般都很长; 在服务器端, 一般这个长度是可以配置的。

POST 方法

POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面). 通过 HTML 中的 form 标签可以构造 POST 请求, 或者使用 JavaScript 的 ajax 也可以构造 POST 请求

POST 请求的特点

首行的第一部分为 POST
URL 的 query string 一般为空 (也可以不为空)
header 部分有若干个键值对结构
body 部分一般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的长度由 header 中的 Content-Length 指定

谈谈 GET 和 POST 的区别

语义不同: GET 一般用于获取数据, POST 一般用于提交数据.
GET 的 body 一般为空, 需要传递的数据通过 query string 传递, POST 的 query string 一般为空, 需要传递的数据通过body 传递 GET 请求一般是幂等的, POST 请求一般是不幂等的. (如果多次请求得到的结果一样, 就视为请求是幂等的)
GET 可以被缓存, POST 不能被缓存. (这一点也是承接幂等性)

补充说明:

关于语义: GET 完全可以用于提交数据, POST 也完全可以用于获取数据.
关于幂等性: 标准建议 GET 实现为幂等的. 实际开发中 GET 也不必完全遵守这个规则(主流网站都有 “猜你喜欢” 功能, 会根据用户的历史行为实时更新现有的结果.
关于安全性: 有些资料上说 “POST 比 GET 请安全”. 这样的说法是不科学的. 是否安全取决于前端在传输密码等敏感信息时是否进行加密, 和 GET POST 无关.
关于传输数据量: 有的资料上说 “GET 传输的数据量小, POST 传输数据量大”. 这个也是不科学的, 标准没有规定 GET 的 URL 的长度, 也没有规定 POST 的 body 的长度. 传输数据量多少, 完全取决于不同浏览器和不同服务器之间的实现区别.
关于传输数据类型: 有的资料上说 “GET 只能传输文本数据, POST 可以传输二进制数据”. 这个也是不科学的. GET 的 query string 虽然无法直接传输二进制数据, 但是可以针对二进制数据进行 url encode

其他方法

PUT 与 POST 相似，只是具有幂等特性，一般用于更新
DELETE 删除服务器指定资源
OPTIONS 返回服务器所支持的请求方法
HEAD 类似于GET，只不过响应体不返回，只返回响应头
TRACE 回显服务器端收到的请求，测试的时候会用到这个
CONNECT 预留，暂无使用这些方法的 HTTP 请求可以使用 ajax 来构造

3. 认识请求 “报头” (header)

header 的整体的格式也是 “键值对” 结构. 每个键值对占一行. 键和值之间使用分号分割

常用请求头：

Host 表示服务器主机的地址和端口.
Content-Length 表示 body 中的数据长度.
Content-Type 表示请求的 body 中的数据格式
User-Agent (简称 UA) 表示浏览器/操作系统的属性
Referer 表示这个页面是从哪个页面跳转过来的
Cookie Cookie 中存储了一个字符串，通过这个字段实现 “身份标识” 的功能

4. 认识请求 “正文” (body)

正文中的内容格式和 header 中的 Content-Type 密切相关

application/x-www-form-urlencoded: form 表单提交的数据格式
multipart/form-data: form 表单提交的数据格式(在 form 标签中加上 enctyped=”multipart/form-data” . 通常用于提交图片/文件
application/json: 数据为 json 格式

1.5 HTTP 响应（Response）

1. 认识 “状态码” (status code)

状态码表示访问一个页面的结果

以 1xx 为开头的都表示接收请求正在处理。

以 2xx 为开头的都表示请求成功响应。

编辑

以 3xx 为开头的都表示需要进行附加操作以完成请求。

编辑

以 4xx 的响应结果表明客户端是发生错误的原因所在。

编辑

以 5xx 为开头的响应标头都表示服务器本身发生错误。

编辑

2. 认识响应 “报头” (header)

响应报头的基本格式和请求报头的格式基本一致. 类似于 Content-Type , Content-Length 等属性的含义也和请求中的含义一致

3. 认识响应 “正文” (body)

正文的具体格式取决于 Content-Type

响应中的 Content-Type 常见取值有以下几种:

text/html : body 数据格式是 HTML

text/css : body 数据格式是 CSS

application/javascript : body 数据格式是 JavaScript

application/json : body 数据格式是 JSON

1.6 通过 Java socket 构造 HTTP 请求与响应

1. 构造 HTTP 请求

public class HttpClient {
    public HttpClient(){}

    public static void main(String[] args) throws Exception{
        Socket socket = new Socket("127.0.0.1", 80);
        OutputStream os = socket.getOutputStream();
        PrintWriter writer = new PrintWriter(new OutputStreamWriter(os, "utf-8"));
        String request = "GET / HTTP/1.0rnrn";
        writer.println(request);
        writer.flush();

        InputStream is = socket.getInputStream();
        byte[] buf = new byte[10240];
        int n = is.read(buf);
        String response = new String(buf, 0, n, "utf-8");
        System.out.println(response);
    }
}

2. 构造 HTTP 响应

public class HttpServer {
    public HttpServer(){}

    public static void main(String[] args) throws Exception{
        ServerSocket serverSocket = new ServerSocket(80);

        while (true){
            Socket socket = serverSocket.accept();
            OutputStream os = socket.getOutputStream();
            PrintWriter writer = new PrintWriter(new OutputStreamWriter(os, "utf-8"));

            String html = "<a href='https://www.baidu.com'>百度一下</a>";
            byte[] bytes = html.getBytes("utf-8");
            int contentLength = bytes.length;
            // Content-Type: application/octet-stream;
            String response = "HTTP/1.0 200 OKrnContent-Type: text/html; charset=utf-8rnContent-Length: 49rnrn" + html;
            writer.println(response);
            writer.flush();
            socket.close();
        }
    }
}

1.7 HTTP 请求响应过程（当你在浏览器中输入网址后，到底发生了什么事情？）

让我们通过一个例子来探讨一下，我们假设访问的 URL 地址为 http://www.ddd.com/web/index.html，当我们输入网址并点击回车时，浏览器内部会进行如下操作：

DNS服务器会首先进行域名的映射，找到访问www.ddd.com所在的地址，然后HTTP 客户端进程在 80 端口发起一个到服务器 www.ddd.com 的 TCP 连接（80 端口是 HTTP 的默认端口）。在客户和服务器进程中都会有一个套接字与其相连。
HTTP 客户端通过它的套接字向服务器发送一个 HTTP 请求报文。该报文中包含了路径 www.ddd.com/web/index.html 的资源，HTTP 服务器通过它的套接字接受该报文，进行请求的解析工作，并从其存储器(RAM 或磁盘)中检索出对象 http://www.ddd.com/web/index.html，然后把检索出来的对象进行封装，封装到 HTTP 响应报文中，并通过套接字向客户进行发送。
HTTP 服务器随即通知 TCP 断开 TCP 连接，实际上是需要等到客户接受完响应报文后才会断开 TCP 连接。
HTTP 客户端接受完响应报文后，TCP 连接会关闭。
HTTP 客户端从响应中提取出报文中是一个 HTML 响应文件，并检查该 HTML 文件，然后循环检查报文中其他内部对象。
检查完成后，HTTP 客户端会把对应的资源通过显示器呈现给用户。

至此，键入网址再按下回车的全过程就结束了。上述过程描述的是一种简单的请求-响应全过程，真实的请求-响应情况可能要比上面描述的过程复杂很多。

🚀2. HTTPS协议

2.1 什么是HTTPS

HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层.

HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被窃听、篡改、伪造的情况。

简单来说HTTPS = HTTP + TLS(SSL)

2.2 “加密” 是什么

加密就是把明文 (要传输的信息)进行一系列变换, 生成密文

解密就是把密文再进行一系列变换, 还原成明文

用来辅助的就是密钥。

1. 对称加密（AES算法）

对称加密:加密和解密的密钥是相同的。

加密(明文，密钥)=密文
解密(密文，密钥)=明文

速度快

2. 非对称加密（RSA算法）

非对称加密:加密和解密的密钥是不同的。

加密(明文，密钥1)=密文
解密(密文，密钥2)=明文

速度慢

3. CA证书

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个证书. 这个证书包含了刚才的公钥, 也包含了网站的身份信息。

这个证书可以理解成是一个结构化的字符串, 里面包含了以下信息:

证书发布机构
证书有效期
公钥
证书所有者
签名
签名密文
…

CA 机构用自己的私钥对签名进行加密，得到签名密文，如果客户能用CA给的公钥将签名密文解密为签名。说明签名没问题，证书就没问题。

加密(签名，CA私钥)=签名密文
解密(签名密文，CA公钥)=签名

4. 加密和数据摘要的区别

加密：数据经过加密，可以被解密
数据摘要：数据经过hash后，不能得到原数据

2.3 HTTPS 的加密工作过程（TLS(SSL) 过程）

既然要保证数据安全, 就需要进行 “加密”.

所以引入对称加密，其实就是通过同一个 “密钥” , 把明文加密成密文, 并且也能把密文解密成明文

但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了，因此密钥的传输也必须加密传输，使用引入了非对称加密。

简单来讲：使用对称加密的方式解决明文传输，使用非对称加密解决密钥的传输，传输的是密文和被加密的密钥。

编辑

客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器.
由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥
服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据.
后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义

但是客户端如何获取到公钥?客户端如何确定这个公钥不是黑客伪造的?

为了确保公钥来自服务器，所以引入了CA证书。

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等.
如果相等, 则说明证书是没有被篡改过的

通过签名比对，解决证书一定是由CA颁发。数字签名（消息摘要结束Message Digital) 哈希算法MD5/ SHA-512 私钥加密，公钥解密的方式，保证传输方。

TLS(SSL) 就是 HTTPS 的加密工作过程。

分享到此，感谢大家观看！！！

如果你喜欢这篇文章，请点赞加关注吧，或者如果你对文章有什么困惑，可以私信我。

🏓🏓🏓