【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.8
name=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)
Welcome to my website
① 响应行
响应行由协议版本、状态码和状态描述组成。格式如下：
<协议版本> <状态码> <状态描述>
协议版本：表明使用的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的密语】的全部内容，欢迎指正~
码文不易，还请多多关注支持，这是我持续创作的最大动力！
