编程基础-HTTP/HTTPS

type

status

date

slug

summary

1 HTTP

1.1 HTTP基本概念

HTTP 是超⽂本传输协议，也就是HyperText Transfer Protocol。

1.1.1 HTTP常见状态码

状态码	含义	常见状态码
1xx	`1xx` 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少。	ㅤ
2xx	`2xx` 类状态码表示服务器成功处理了客户端的请求	200、204、206
3xx	`3xx` 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL 重新发送请求获取资源，也就是重定向。	301、302、304
4xx	`4xx` 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。	400、403、404
5xx	`5xx` 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。	500、501、502

1.1.2 HTTP常见字段

Host 字段：客户端发送请求时，⽤来指定服务器的域名。 Host: www.baidu.com

Content-Length 字段 ：服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。 Content-Length: 1000

Connection 字段 ：Connection 字段最常用于客户端要求服务器使⽤ TCP 持久连接，以便其他请求复⽤。 HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为Keep-Alive 。

Content-Type 字段 ：Content-Type 字段⽤于服务器回应时，告诉客户端，本次数据是什么格式。Content-Type: text/html; charset=utf-8

Content-Encoding 字段 ：Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使用了什么压缩格式。客户端在请求时，⽤ Accept-Encoding 字段说明自己可以接受哪些压缩⽅法。 Accept-Encoding: gzip, deflate

下图为访问百度的返回字段

1.1.3 HTTP常见方法

方法	说明
GET	GET方法用于使用给定的URI从给定服务器中检索信息，即从指定资源中请求数据。使用GET方法的请求应该只是检索数据，并且不应对数据产生其他影响。
POST	POST方法用于将数据发送到服务器以创建或更新资源，它向 URI 指定的资源提交数据，数据就放在报⽂的 body 里。
HEAD	HEAD方法与GET方法相同，但没有响应体，仅传输状态行和标题部分。这对于恢复相应头部编写的元数据非常有用，而无需传输整个内容。
PUT	PUT方法用于将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。
DELETE	DELETE方法用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容。
CONNECT	CONNECT方法用来建立到给定URI标识的服务器的隧道；它通过简单的TCP / IP隧道更改请求连接，通常实使用解码的HTTP代理来进行SSL编码的通信。
OPTIONS	OPTIONS方法用来描述了目标资源的通信选项，会返回服务器支持预定义URL的HTTP策略。
TRACE	TRACE方法用于沿着目标资源的路径执行消息环回测试；它回应收到的请求，以便客户可以看到中间服务器进行了哪些（假设任何）进度或增量。

1.2 HTTP特性

优点

简单 HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式，易于理解，降低了学习和使⽤的⻔槛。

灵活和易于扩展 HTTP协议⾥的各类请求⽅法、 URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发⼈员⾃定义和扩充。

同时 HTTP 由于是⼯作在应⽤层（ OSI 第七层），则它下层可以随意变化。

HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层， HTTP/3 甚⾄把 TCP 层换成了基于 UDP 的QUIC。

应用广泛和跨平台 互联⽹发展⾄今， HTTP 的应⽤范围⾮常的⼴泛，从台式机的浏览器到⼿机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡， HTTP 的应⽤⽚地开花，同时天然具有跨平台的优越性。

缺点

无状态

⽆状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存⽤来对外提供服务。

⽆状态的坏处，既然服务器没有记忆能⼒，它在完成有关联性的操作时会⾮常麻烦。

解决方案Cookie：Cookie通过在请求和响应报⽂中写⼊ Cookie 信息来控制客户端的状态。在客户端第⼀次请求后，服务器会下发⼀个装有客户信息的「⼩贴纸」，后续客户端请求服务器的时候，带上「⼩贴纸」，服务器就能认得了了，

明文传输、不安全

1.3 HTTP版本演变

1.3.1 HTTP/1.0 → HTTP/1.1

性能提升：

使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。

⽀持管道（pipeline）网络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以减少整体的响应时间。

HTTP/1.1 的性能瓶颈：

请求 / 响应头部未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；

发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；

服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；

没有请求优先级控制；

请求只能从客户端开始，服务器只能被动响应。

1.3.2 HTTP/1.1 → HTTP/2

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。

性能提升：

头部压缩：HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重复的部分。

HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。

二进制格式：HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

收到报⽂后，⽆需再将明⽂的报⽂转成二进制，⽽是直接解析二进制报⽂，这增加了数据传输的效率

数据流：HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。

客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。

多路复用：HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不用按照顺序⼀⼀对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题， 降低了延迟，⼤幅度提⾼了连接的利用率。

服务器推送：HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。

1.3.3 HTTP/2 → HTTP/3

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
HTTP/1.1 中的管道（ pipeline）传输中如果有⼀个请求阻塞了，那么队列后请求也统统被阻塞住了。
HTTP/2 多个请求复⽤⼀个TCP连接，⼀旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP。

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的⼀个丢包全部重传问题。

UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。

TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。

HTTPS 要建立⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。 QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数

1.3.4 HTTP各版本层次图

2 HTTPS

2.1 HTTP 与 HTTPS 的区别

HTTP 是超⽂本传输协议，信息是明⽂传输，存在安全风险的问题。 HTTPS 则解决 HTTP 不安全的缺陷，在TCP 和 HTTP 网络层之间加⼊了 SSL/TLS 安全协议，使得报⽂能够加密传输。

HTTP 连接建⽴相对简单， TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。而HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。

HTTP 的端口号是 80， HTTPS 的端口号是 443。

HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2.2 HTTPS安全性实现

混合加密

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

在通信建⽴前采用⾮对称加密的⽅式交换「会话秘钥」，后续就不再使⽤⾮对称加密。

在通信过程中全部使用对称加密的「会话秘钥」的⽅式加密明⽂数据。

采⽤「混合加密」的⽅式的原因：

对称加密只使⽤⼀个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。

非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发⽽私钥保密，解决了密钥交换问题但速度慢。

摘要算法

摘要算法⽤来实现完整性，能够为数据⽣成独⼀⽆⼆的「指纹」，⽤于校验数据的完整性，解决了篡改的⻛险。

客户端在发送明⽂之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」⼀同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过⽐较客户端携带的「指纹」和当前算出的「指纹」做⽐较，若「指纹」相同，说明数据是完整的。

数字证书

客户端先向服务器端索要公钥，然后⽤公钥加密信息，服务器收到密文后，⽤⾃⼰的私钥解密。这就存在些问题，如何保证公钥不被篡改和信任度？

所以这⾥就需要借助第三⽅权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

通过数字证书的⽅式保证服务器公钥的身份，解决冒充的⻛险 。

证书签名和验证过程：

公钥加密私钥解密，私钥加密公钥解密。
CA公钥已经事先置入到了浏览器或者操作系统里。

步骤	服务端	CA	客户端
1	服务器把`自己的公钥注册到CA`	ㅤ	ㅤ
2	ㅤ	`CA用自己的私钥`将服务器的公钥和域名的其他信息加密成证书并颁发给服务器	ㅤ
3	ㅤ	ㅤ	客户端发起网络请求
4	ㅤ	ㅤ	客户端拿到服务器的数字证书后`使用CA公钥解密`，确认服务器数字证书的真实性
5	ㅤ	ㅤ	从数字证书获取服务器公钥后，使用`服务器公钥对报文加密`传输

两种情况：

如果数字证书被其他人篡改，由于加密数据不是CA私钥加密而来，所以无法解密成功。

如果攻击者知道A.com使用的是某家CA机构的证书，那么他也去这家CA机构申请一个合法的证书，然后在浏览器请求A.com时对返回的加密证书数据进行替换。

由于攻击者申请的证书也是由正规CA机构制作的，因此这段加密数据可以成功被解密。但CA机构在制作的证书时除了网站的公钥外，还要包含许多其他数据，用来辅助进行校验，比如说网站的域名。如果域名对不上依然检验失败

。

1 HTTP

1.1 HTTP基本概念

1.1.1 HTTP常见状态码

1.1.2 HTTP常见字段

1.1.3 HTTP常见方法

1.2 HTTP特性

优点

缺点

1.3 HTTP版本演变

1.3.1 HTTP/1.0 → HTTP/1.1

性能提升：

HTTP/1.1 的性能瓶颈：

1.3.2 HTTP/1.1 → HTTP/2

性能提升：

1.3.3 HTTP/2 → HTTP/3

1.3.4 HTTP各版本层次图

2 HTTPS

2.1 HTTP 与 HTTPS 的区别

2.2 HTTPS安全性实现

混合加密

摘要算法

数字证书

2.3 HTTPS建立连接过程