计网中的HTTP/HTTPS

一、 HTTP（超文本传输协议）

1. HTTP的特点

HTTP是超文本传输协议。
是用于服务器传输超文本到本地浏览器的传送协议；
是基于TCP/IP通信协议进行传送数据流（HTML文件、图片文件、查询结果）；
是基于应用层的面向对象的协议；
协议工作于客户端-服务器架构之上。浏览器作为HTTP客户端通过URL向HTTP服务器端（即Web服务器）发送请求。Web服务器根据接收到的请求，向客户端发送响应信息；
HTTP使用URI（统一资源标识符）来传输数据和建立连接

2. URI（统一资源标识符）

HTTP使用URI（统一资源标识符）来传输数据和建立连接；

URL的构造

URL是特殊的URI，包含了用于查找某个资源的足够信息，URL的例子如下

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

这里面的分隔符包含：

"//"（协议部分的分隔符）
":"（域名和端口的分隔符）
"/"（虚拟目录的分隔符）
"?"（文件名和参数的分隔符）
"#"（参数和锚部分的分隔符）

3. HTTP常见的状态码

1xx 类状态码属于 提示信息 ，是协议处理中的⼀种中间状态，实际⽤到的⽐较少。
2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。
3xx 类状态码表示客户端请求的资源发⽣了变动，需要客户端⽤新的 URL 重新发送请求获取资源，也就是重定向 。
4xx 类状态码表示客户端发送的报⽂有误 ，服务器⽆法处理，也就是错误码的含义。
5xx 类状态码表示客户端请求报⽂正确，但是 服务器处理时内部发⽣了错误 ，属于服务器端的错误码。

4. HTTP常见字段

参考此文：【HTTP 请求头、响应头常见字段分析_响应头字段-CSDN博客】

二、HTTPS（超文本传输安全协议）

1. HTTP和HTTPS有哪些区别？

前者是超文本传输协议，信息是明文传输，存在安全风险。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输；
HTTP建立相对简单，TCP三次握手后就能进行HTTP的报文传输。而HTTPS在三次握手之后，还要进行SSL/TLS的握手过程，才能进入加密报文传输；
HTTP的默认端口号为80，HTTPS的默认端口号为443；
HTTPS协议需要向CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2. HTTPS解决了HTTP的什么隐患？

由于HTTP是明文传输，所以安全上会出现三个风险：

窃听⻛险 ，⽐如通信链路上可以获取通信内容（数据保密性）。
篡改⻛险 ，⽐如强制植⼊垃圾⼴告，视觉污染（数据完整性）。
冒充⻛险 ，⽐如冒充淘宝⽹站（通信双方身份的真实性）。

HTTPS在HTTP的基础上，在TCP层加入了SSL/TLS协议，可以很好的解决上面的风险。做到了：

信息加密 ：交互信息⽆法被窃取。
校验机制 ：⽆法篡改通信内容，篡改了就不能正常显示。
身份证书 ：证明淘宝是真的淘宝⽹。

3. HTTPS是如何解决上面的三个隐患的？

（1）混合加密解决窃听风险

HTTPS 采⽤的是对称加密 和**⾮对称加密** 结合的「混合加密」⽅式：

在++通信建立前采用非对称加密++的方式交换"会话秘钥"，后续就不再使用非对称加密；

在++通信建立过程中全部采用对称加密++的会话秘钥的方式加密明文数据。

对称加密： 只使⽤⼀个密钥，运算速度快，密钥必须保密，⽆法做到安全的密钥交换。
⾮对称加密： 使⽤两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。

（2）摘要算法+数字签名保证传输的内容不被篡改

i. 摘要算法

为了保证传输的内容不被篡改，我们可以对内容计算出一个唯一的「指纹」，然后连同内容一起发送给对方。对方收到后，先用同样的算法对内容也计算出一个「指纹」，再和发送方传来的「指纹」做比对。如果两者一致，说明内容完好无损；否则，就能判定内容被篡改了。

在计算机里，这个「指纹」是通过**摘要算法（哈希函数）**计算出的哈希值。哈希值具有两个重要特性：唯一性 ------不同内容几乎不可能产生相同的哈希值；不可逆性------无法通过哈希值反向推导出原始内容。

但是，摘要算法真的能保证通信安全吗？

并不能。 它只能保证内容没有被篡改，但无法保证「内容 + 哈希值」这个整体没有被中间人整个替换掉 。因为整个过程**++缺少对消息来源的认证++**------客户端无法确认收到的数据究竟是来自真正的服务器，还是一个冒充者伪造的。

可见，光有摘要算法还不够，我们还需要一种机制来验证消息的身份------也就是证明这条消息确实是来自服务器，而不是别人冒充的。

ii. 数字签名

为了解决摘要算法无法认证消息来源的问题，我们需要引入非对称加密。

非对称加密使用一对密钥：

公钥：可以公开给所有人；
私钥：由持有者严密保管，绝不泄露。

这两个密钥可以双向加解密：

公钥加密，私钥解密：目的是保证内容传输安全。因为公钥加密后的内容，只有私钥持有者能解密，其他人无法窥探。
私钥加密，公钥解密 ：目的是确认身份。因为私钥只有持有者才有，如果公钥能成功解密某段内容，就能证明该内容确实来自私钥持有者。

实际应用中，考虑到非对称加密性能开销较大，我们不会直接用私钥加密整个内容，而是采用数字签名的方式：服务端用私钥对内容的哈希值进行加密，这段加密后的哈希值就是「数字签名」。

服务端保管私钥，并将对应的公钥预先分发给客户端。当客户端收到「内容 + 数字签名」后，会做两件事：

用同样的摘要算法计算内容的哈希值；
用公钥解密数字签名，得到服务端计算的哈希值。

如果两个哈希值一致，且公钥能成功解密签名，就证明：内容未被篡改，且确实来自服务器。

（3）数字证书杜绝冒充

通过前文，我们知道：

可以通过哈希算法来保证消息的完整性；
可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的⼀⽅发送的）；

但是，如果公钥是伪造的呢？是否还缺少身份认证的环节？
设想一下：客户端收到了服务器发来的「内容 + 签名」，也用手里的公钥成功解密了签名，一切看起来都很正常。但问题在于------这个公钥真的是服务器发来的吗？ 如果它在传输途中被中间人偷偷换掉，后续所有基于这个公钥的验证都将失去意义。中间人完全可以用自己的私钥生成签名，再把伪造的公钥发给客户端。客户端用假公钥一验，发现能解密通过，便信以为真。此时，表面上一切验证通过，实际上通信早已被劫持。

这就是经典的中间人攻击（Man-in-the-Middle Attack，MITM）。

问题的根源在于：客户端无法确认收到的公钥到底属于谁。 就像收到一张写着别人名字的名片，你无法仅凭名片本身确认对方的真实身份。

要解决这个问题，需要一个可信的第三方机构来为公钥作担保，这个机构就是 CA（数字证书认证机构，Certificate Authority）。

CA 的核心作用就是将「公钥」与「服务器的真实身份」绑定在一起 ，具体通过颁发数字证书来实现，流程如下：

服务器将自己的公钥连同身份信息提交给 CA；
CA 审核通过后，将这些信息打包，并用 CA 自己的私钥对其进行数字签名，生成一张数字证书；
服务器向客户端通信时，先将这张证书发送过去；
客户端收到后，用 CA 的公钥（这个公钥通常预置在操作系统或浏览器中，称为「根证书」）来验证证书上的签名。

如果签名验证通过，说明这张证书确实是由可信的 CA 颁发的，进而可以确认：证书里的公钥确实属于这个服务器，身份可信。