【Linux-网络】HTTP的清风与HTTPS的密语

🎬 个人主页：谁在夜里看海.

📖 个人专栏：《C++系列》《Linux系列》《算法系列》

⛰️ 道阻且长，行则将至

📚 引言

📚 一、HTTP

📖 1.概述

📖 2.URL

🔖结构

🔖转义

📖 3.格式

🔖请求格式

🔖响应格式

📚二、HTTPS

📖 1.概念

📖 2.加密方式

🔖对称加密

🔖非对称加密

📖 3.数据摘要

🔖概念

🔖数字签名

📖 4.HTTPS的工作过程

🔖过程推断

🔖证书

📚 引言

上一篇文章我们讲述了TCP/UDP协议，那是位于传输层的负责端到端通信，确保数据的可靠传输的协议，这篇文章我们来谈一谈应用层的协议。

如果说传输层协议的作用是确保数据能够传输到位，那么应用层协议的作用就是确保数据能被正确解析。具体地说，应用层协议决定了数据在网络上传输时的结构、顺序、传输规则以及数据如何被应用程序解释，应用层协议有效支持不同设备、操作系统和应用程序之间的相互通信和数据交换。

应用层协议可以由我们程序员自己定义，只需要通信双方遵守相同的协议即可，不过在现实中，已经有许多现成且优秀的应用层协议供我们参考使用，其中之一就是我们下面要讲述的HTTP(超文本传输协议)。

📚 一、HTTP

📖 1.概述

HTTP（HyperText Transfer Protocol） 是一种用于客户端（通常是浏览器）与服务器之间传输超文本（主要是网页）的协议。它是Web通信的基础协议，用于支持浏览器与Web服务器之间的请求和响应。

虽然HTTP的通用客户端是浏览器，但这并不意味着HTTP是基于浏览器的协议，事实上它广泛用于各种客户端与服务器间的通信，除了浏览器之外，其他许多应用（如移动应用、API、爬虫等）也使用HTTP协议进行数据交换：

① 在浏览器中：我们使用HTTP协议来请求Web服务器上的资源。当你输入一个网址（如www.example.com）并按下回车时，浏览器实际上向服务器发送一个HTTP请求，服务器返回相应的HTTP响应，其中包含网页内容。

② 其他应用程序：HTTP并不仅限于浏览器，其他应用程序（如移动应用、桌面应用、API接口等）也可以通过HTTP协议与服务器进行数据交换。

📖 2.URL

URL（Uniform Resource Locator）是一种用于标识互联网资源的地址，我们平时俗称的“网址”就是URL，URL除了可以指向网页，还可以指向图片、视频、文件、API接口等网络资源。它的作用是帮助客户端（如浏览器）在互联网上找到并访问特定的资源。

🔖结构

一个典型的URL格式如下：

http://user:pass@www.example.jp:80/dir/index.htm?uid=1#ch1

① 协议 http:// 指定了访问该URL时使用的协议，http标识使用HTTP(超文本传输协议)；

② 用户信息 user:pass@ 这个部分是可选的，表示URL的用户名和密码，通常用于需要身份验证的站点。user是用户名，pass是密码，这种方式称为基本认证；

③ 主机名 www.example.jp 这是服务器的主机名（或域名），表示要连接的Web服务器地址；

④ 端口 :80 这是可选的，表示与目标服务器通信时使用的端口号。80是HTTP协议的默认端口。如果未指定端口，HTTP会默认使用端口80；

⑤ 路径 /dir/index.htm 这部分表示服务器上的资源路径，指向某个文件或目录；

⑥ 查询参数 ?uid=1 这是URL的查询部分，通常用于向服务器传递额外的参数;

⑦ 片段标识符 #ch1 片段标识符是URL的一个可选部分，通常用于标识资源中的某个位置或段落。

🔖转义

像 / ? : 等这样的字符, 已经被URL当做特殊意义理解了，因此这些字符不能随意出现。因此，某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义。

转义的规则如下: 将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY 格式

例如：

这里“+”就被转义成“%2B”。

urlencode 和 urldecode 分别是编码和解码的过程，我们可以用在线转义工具对URL进行转义：

UrlEncode编码和UrlDecode解码-在线URL编码解码工具

📖 3.格式

HTTP有两种基本的消息格式：请求格式（Request）和响应格式（Response）

🔖请求格式

请求格式由以下几个部分组成：

请求行
请求头
空行
请求体

示例：

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8name=John&age=25

① 请求行

请求行包含请求方法、请求的资源路径和协议版本

<方法> <请求路径> <协议版本>

方法：HTTP请求的方法指明客户端希望对指定资源执行的操作。常见的方法有：

GET：请求指定资源，仅读取资源，不进行修改（幂等，即多次执行统一操作结果不变）

POST：向指定资源提交数据（不幂等，多次提交会创建多份资源）

PUT：向指定资源上传数据（如果资源存在，替换该资源；资源不存在则创建，因此幂等）

DELETE：删除指定资源

HEAD：与GET类似，不过只获取响应头部，不获取实体内容

请求路径：指定要请求的资源的路径（可以是相对路径或绝对路径）

协议版本：表明使用的HTTP协议的版本，常见的有HTTP/1.1和HTTP/2

② 请求头

请求头是由多个键值对组成，用于提供额外的请求信息，如浏览器类型、支持的编码格式、Cookie信息等。请求头通常包括以下内容：

Host：指定服务器的域名或IP地址

User-Agent：客户端的浏览器和操作系统信息

Accept：浏览器可以处理的响应内容类型

Content-Type：请求体的内容类型，通常在POST或PUT请求中使用

Authorization：用于HTTP认证的信息

Cookie：客户端的Cookie信息

③ 空行

请求头和请求体之间会有一个空行，用于分隔请求头和请求体部分。

④ 请求体

请求体包含了实际发送到服务器的数据，通常在POST、PUT等请求方法中使用。对于GET等方法，请求体一般为空。

🔖响应格式

响应格式由以下几个部分组成：

响应行
响应头
空行
响应体

示例：

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
Server: Apache/2.4.7 (Ubuntu)<html><body><h1>Welcome to my website</h1></body>
</html>

① 响应行

响应行由协议版本、状态码和状态描述组成。格式如下：

<协议版本> <状态码> <状态描述>

协议版本：表明使用的HTTP协议版本

状态码：服务器返回的数字代码，表示响应的状态

2xx：请求成功（如200 OK）

3xx：重定向（如301 Moved Permanently）

4xx：客户端错误（如404 Not Found）

5xx：服务器错误（如500 Internal Server Error）

状态描述：状态码的简要描述（如OK、Not Found）

② 响应头

响应头包含了关于服务器、响应内容以及其他一些元数据的描述。常见的响应头包括：

Content-Type：响应体的媒体类型

Content-Length：响应体的大小（以字节为单位）

Server：服务器软件的名称

Location：用于重定向的URL

Set-Cookie：设置客户端的Cookie

③ 空行

响应头和响应体之间也有一个空行，用于分隔响应头和响应体部分。

④ 响应体

响应体包含了实际的资源数据或响应内容。它可以是HTML页面、JSON数据、图片等。

📚二、HTTPS

📖 1.概念

由于HTTP的内容是明文传输的，明文数据会经过路由器、WiFi热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击，所以我们才需要对数据进行加密。

加密就是把明文（要传输的信息）进行一系列变换，形成密文；

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

在这个加密和解密的过程中，往往需要一个或者多个中间的数据辅助这个过程，这样的数据就叫做密钥。

HTTPS在HTTP的基础上加入了SSL/TLS（安全套接字层/传输层安全协议）加密协议，用来对网络通信进行加密和认证，从而确保数据在传输过程中不被窃取、篡改或伪造。简单来说，HTTPS是HTTP协议的加密版本，用于保护HTTP通信的安全性。

📖 2.加密方式

加密方式有许许多多，但总体可以分成对称加密和非对称加密

🔖对称加密

采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的。

工作原理：

① 加密：发送方使用密钥将明文数据转换成密文；

② 传输：密文通过不安全的通道（网络）发送到接收方；

③ 解密：接收方使用相同的密钥将密文还原成明文。

⚠️加密与解密的实现基于通信双方使用相同的加密/解密算法，因此加密算法可以看作是公开的

例如：简单的对称加密，加密/解密算法为按位异或

明文a ^ 密钥b 得到密文c；

密文c ^ 密钥b 还原会明文 a。

因为加密和解密都使用同一个密钥，所以密钥的管理和安全性至关重要。如果密钥泄露，任何人都能解密收到的数据。

🔖非对称加密

与对称加密不同，非对称加密的加密与解密所使用的密钥是不同的，其中一个是公开密钥（简称公钥），一个是私有密钥（简称私钥）。

工作原理：

① 加密：发送方使用公钥将明文数据转换成密文；

② 解密：接受放使用私钥将密文数据还原成明文。

（当然公钥和私钥也可以反着用）

这种方式的核心思想是，虽然每个人都可以通过公钥来加密数据，但只有持有相应私钥的人才能解密数据。由于公钥和私钥是成对生成的，公钥和私钥之间具有数学上的关系，但私钥不能从公钥推算出来。

⚠️这种方法最大的缺点是：运算速度⾮常慢。

📖 3.数据摘要

上述的加密方法可以确保明文数据不会泄露，即使密文在传输过程中被中间人截取，但如果没有对应的密钥就无法将密文还原成明文。但是除此之外，我们还需要考虑一个问题，那就是数据完整性。

如果密文被中间人截取，他可以在不清楚密钥的情况下对密文进行修改，这样接收方得到的就不是原来的密文，也无法还原成正确的明文了，所以我们还需要保证密文在传输过程中不被修改。于是引入了数据摘要的概念。

🔖概念

数据摘要（数字指纹）的基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字摘要并不是⼀种加密机制，因为它没有解密的过程。

工作原理：

① 生成摘要：对数据进行运算生成数字摘要；

② 验证完整性：接收方对数据进行相同运算，将结果与摘要进行比对，若相同则表示未被修改。

⚠️但还有问题，如果中间人对数据修改后，将摘要也一并修改了，这样接收方就看不出来数据被篡改了，这该怎么解决呢？

🔖数字签名

既然如此，我们将数据摘要也进行加密，就得到了数据签名。我们使用非对称加密方式，那么接收方的验证步骤就变成了：

① 使用私钥将数字签名还原成数字摘要；

② 将数据用哈希函数进行运算，得到结果与数字摘要进行比对，验证完整性。

📖 4.HTTPS的工作过程

直接介绍HTTPS的工作原理可能会有些难以理解，有了以上的知识储备，我们可以自行推断一下HTTPS的工作过程：

🔖过程推断

① 只使用对称加密

即通信双方各自持有一个相同的密钥，发送数据时，使用密钥对明文加密；接收数据时使用密钥将密文还原。如果这个密钥只有通信双方知晓，那么通信安全就可以得到保证。

但是并没有想象的这么简单，服务器需要同时对很多客户端提供服务，如果与每个客户端使用的密钥都不一样，那么服务器还需要维护客户端与密钥的关联关系，这非常繁琐。这种方法行不通。

② 只使用非对称加密

如果通信双方都使用非对称加密呢，即双方都持有各自的公钥私钥对，通信过程为：

1️⃣在通信前，双方先交换各自的公钥；

2️⃣服务器发送数据：使用客户端的公钥对数据加密；服务器接收数据：使用自己的私钥对数据解密。

3️⃣客户端发送数据：使用服务器的公钥对数据加密；客户端接收数据：使用自己的私钥对数据解密。

⚠️但是我们上面提到了，非对称加密的最大问题是运算速度很慢，如果双方都使用非对称加密的话，效率太低了。这种办法也行不通

③ 非对称加密+对称加密

方法①的运行速度快，但问题在于，服务器要存储管理每个客户端的对称密钥，不论是否正在进行通信。那么我们可不可以优化一下，只在通信的过程中保存对称密钥，通信结束就解除绑定：

1️⃣服务器拥有一对非对称密钥对，与客户端进行通信前，先将公钥发送给客户端；

2️⃣客户端将自己的对称密钥通过公钥加密，发送给服务器；

3️⃣服务器通过解密得到对称密钥，之后的通信就可以通过这个对称密钥进行了。

上述过程只进行了一次非对称加密解密过程，后面的操作全都是对称的，这样一来相比方法②大大提高了效率，看似是最可行的，但是！

上述过程都忽略了一个重要问题：如果在通信开始前，中间人攻击就已经存在了呢？

拿方法③举例，服务器将公钥发送给客户端时被中间人截获，中间人把自己的对称密钥加密后发送给服务器，这样一来，中间人就可以假冒客户端与服务器进行通信，而服务器对此一无所知；

相同地，中间人可以将自己的公钥发送给客户端，并获取客户端的对称密钥，这样一来，中间人就可以假冒服务器与客户端进行通信，客户端对此也一无所知！

上面的问题关键在于：客户端不能确定公钥的来源，如果可以确定公钥来自于服务器，就可以放心地将私钥加密发送过去了。

要解决上述问题，就要引入证书的概念：

🔖证书

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威。

所以服务器向客户端发送的其实是包含公钥信息的证书，那么客户端怎么通过证书验证公钥的来源正确性呢？

方法①：直接查看域名信息是否正确，但是如果证书被中间人篡改了呢，公钥已经被替换了呢？

这里就要用到我们提到过的数据签名。通过数据签名，我们可以确保证书的完整性，具体步骤为：

1️⃣客户端收到证书，向CA机构申请还原签名为数据摘要（私钥只有CA机构拥有，确保了安全性）；

2️⃣将明文信息通过哈西函数进行运算，将结果与摘要比对，如果相同，则公钥可信；如果不相同，则公钥不可信。

如此一来，就解决了中间人攻击的问题。

❓那如果中间人发送了一个合法的证书呢（中间人向CA机构申请了一个证书）

✅只需要查看域名信息即可

❓如果中间人用于申请证书的域名与真域名极度相似，造成混淆呢

✅这就需要公安机关来“重拳出击”了✊

以上就是【HTTP的清风与HTTPS的密语】的全部内容，欢迎指正~

码文不易，还请多多关注支持，这是我持续创作的最大动力！