HTTP五大知识点总结

• HTTP基本概念
• Get和Post
• HTTP特性
• HTTPS与HTTP
• HTTP/1.1 HTTP/2 HTTP/3演变

HTTP基本概念

---

HTTP基本概念

HTTP：超文本传输协议(HyperText Transfer Protocol)，是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

HTTP常见的状态码

200 OK：一切正常，返回响应头有body数据

204 No Content：与200基本一致，响应头无body数据

206 Partial Content：响应返回的body数据并不资源的全部

301 Moved Permanently：永久重定向，资源已不存在

302 Found：临时重定向，资源存在

304 Not Modified：301和302在响应头里有Location字段，浏览器会自动重定向新的URL，但304不具有跳转含义，表示资源未修改，也称缓存重定向和缓存控制

400 Bad Request：表示请求报文有错误

403 Forbidden：表示服务器禁止访问资源

404 Not Found：请求的资源在服务器上不存在

500 Internal Server Error：表示服务器有错误

501 Internal Server Error：表示客户端请求功能还不支持

502 Bad Gateway：表示服务器自身工作正常，访问后端服务器发生错误

503 Service Unavailable：表示服务器很忙，暂时无法响应

HTTP常用字段

• Host：客户端发送请求时，用来指定服务器的域名（有了该字段，可以将请求发送到同一台服务器上的不同网站）

• Content-Length：服务器返回数据时表明本次回应的数据长度

• Connection：最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用

Connection:keep-alive

• Content-Type：用于服务器回应客户端本次数据格式

Contnet-Type:text/html;charset=utf-8

//客户端请求时，可以使用Accept字段声明自己可以接受哪些数据格式
Accept：*/*

• Content-Encoding：说明服务器返回的数据使用的压缩格式

Contnet-Encoding:gzip

//客户端请求时，可以使用Accept字段声明自己可以接受哪些数据格式
Accept-Encoding：gzip,deflate

GET与POST

---

两者的区别

1. Get：从服务器获取资源，包括静态文本、页面、图片

2. Post：向服务器提交数据，数据放在报文的body里

两者方法都是安全和幂等的吗？

安全和幂等：

• 所谓安全是指请求方法不会破坏服务器上的资源
• 所谓幂等是指多次执行相同的操作，结果都是相同

显然，GET方法是安全且幂等的，但POST不是

HTTP/1.1特性

---

HTTP（以下都指1.1版本）优点

• 简单：基本报文格式是header+body
• 灵活和易于拓展：HTTP协议允许开发人员自定义和扩充
• 应用广泛和跨平台：天然具有跨平台优越性

HTTP缺点

1. 无状态双刃剑

   • 无状态好处：服务器不会记忆HTTP的状态，不需要额外的资源来记录状态信息
   • 无状态坏处：在完成关联性操作时非常麻烦，解决方法是用Cookie技术
     

   Cookie通过在请求和响应报文中写入Cookie信息控制客户端状态（在客户端第一次请求，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了）

2. 不安全：（可以通过HTTPS解决）

   • 通信使用明文传输不加密（窃听风险）
   • 不验证通信方的身份（篡改风险）
   • 无法证明报文的完整性（冒充风险）

HTTP性能

1. 长连接：早期HTTP/1.0是短连接，每发起一个请求都要建立一次TCP连接（三次握手），增加了很多通信开销，后期提出长连接通信方式，也称之为持久连接，特点是只要任意一端没有明确提出断开连接，则保持TCP连接状态。
   

2. 管道网络传输：即在同一个TCP连接里面，客户端可以同时发起多个请求，服务器按照顺序响应，减少整体的响应时间。
   

3. 队头阻塞：是指顺序发送的请求序列中的一个请求因为某种原因被阻塞，后面排队的所有请求都一同被阻塞，会导致客户端一直请求不到数据。
   

HTTP与HTTPS

---

两者区别

• HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 是在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

• HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

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

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

HTTP/1.1有哪些问题？HTTPS是如何解决的？

1. 窃听风险：明文传输容易泄露信息

   • 混合加密

 原理：1）加密：通信过程使用对称密钥对明文进行加密，使用公钥对会话密钥进行加密；2）解密：用私钥对加密过的会话密钥进行解密，使用解密后的会话密钥对密文进行解密。

2. 篡改风险：没有校验机制，内容会被篡改

   • 摘要算法

     能够为数据生成独一无二的指纹，用于校验数据的完整性，解决篡改风险
     

     客户端在发送明文之前会通过摘要算法算出明文的摘要，服务器解密之后会用同样的摘要算法算出发送过来的明文，两者进行比较判断有无数据篡改。

3. 冒充风险：不进行身份验证

   • 数字证书

     将服务器公钥放在数字证书中，只要证书是可信的，公钥就是可信的，流程如下：

   

HTTPS如何建立连接，其间交互了什么？

​ SSL/TLS协议基本流程：

• 客户端像服务器索要并验证服务器的公钥

• 双方协商生产会话密钥

• 双方采用会话密钥进行加密通信
  

1. ClientHello

   客户端首先向服务器发起加密通信请求，也就是CLientHello请求，发送以下信息：

   • 客户端支持的SSL/TLS协议版本
   • 客户端生产的随机数（Client Random），用于生产会话密钥
   • 客户端支持的密码套件列表，如RSA加密算法

2. SeverHello

   服务器收到客户端请求后，向客户端发出SeverHello响应，回复如下内容：

   • 确认SSL/TLS协议版本，不支持则关闭加密通信
   • 服务器生产的随机数（Server Random），用于生产会话密钥
   • 确认密码套件列表，如RSA加密算法
   • 服务器的数字证书

3. 客户端回应

   首先确认数字证书的真实性，若没有问题则使用服务器公钥加密报文，并发送如下信息：

   • 一个随机数（pre-master key）。该随机数会被服务器公钥加密。至此，服务器和客户端有3个随机数，使用双方协商的加密算法各自生成本次通信的会话密钥。
   • 加密通信算法改变通知，表示随后的信息都将用会话密钥加密通信。
   • 客户端握手结束通知，表示客户端的握手阶段已经结束。并把之前所有内容发生的数据做个摘要，用来供服务端校验。

4. 服务器的最后回应

   服务器收到客户端的第三个随机数之后，通过协商的加密算法，计算出本次通信的会话密钥，然后向客户端发送最后的信息：

   • 加密通信算法改变通知，接下来的信息都将用会话密钥加密通信
   • 服务器握手结束通知，并把之前所有内容发生的数据做个摘要，用来供客户端校验。

   至此，整个SSL/TLS握手阶段全部结束，接下来就是客户端和服务器的加密通信，就是普通的HTTP协议。

HTTP/1.1、HTTP2、HTTP3演变

---

HTTP/1.1相比于HTTP/1.0的改进

• 使用TCP长连接改善HTTP/1.0短连接造成的性能开销
• 支持管道（pipeline）网络传输，可以减少响应时间

HTTP/2相比于HTTP/1.1的改进

HTTP/2是基于HTTPS的，所以HTTP/2具有保障

1. 头部压缩

   HTTP/1.1中请求/响应头部（Header）未经压缩就发送，首部信息越多延迟越大。每次互相发送相同的首部造成的浪费较多。

   HTTP/2会压缩头，如果同时发送多个请求，Header一样或相似，则协议会消除重复的部分，即所谓HPACK算法，在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号提高速度。

2. 二进制格式

   HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。

   头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。

   这样可以大大提高数据传输的效率。
   

3. 数据流

   HTTP/1.1中服务器是按请求的顺序响应的，如果服务器响应慢会导致客户端一直请求不到数据，造成队头阻塞，且没有请求优先级控制。

   HTTP/2的数据包不是按顺序发送的，每个请求或回应的数据包被称为一个数据流（Stream），且有独一无二的编号，规定客户端发出的数据流为奇数，服务器发出的数据流编号为偶数，客户端还可以指定数据流的优先级，服务器会先响应优先级高的请求。

4. 多路复用

   HTTP/1.1中采用串行请求，需排队等候，会造成队头阻塞等问题。

   HTTP/2可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。
   

5. 服务器推送（Server Push 也叫 Cache Push）

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

   HTTP/2在一定程度上改善了传统的请求-应答工作模式，服务器可以主动向客户端发送消息。

HTTP/3相比于HTTP/2的改进

HTTP/2主要问题是：对于多个HTTP请求在复用一个TCP连接时，下层TCP协议不知道有几个HTTP请求，一旦出现丢包现象就会触发TCP重传机制，这样所有的HTTP请求都必须等待这个丢了的包被重传回来。

由于UDP不管顺序也不管丢包，所以不会出现队头阻塞和丢包重传问题。

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

• QUIC中当某个流丢包时，只会阻塞这个流，其他流不会受到影响

• TLS升级到1.3版本，头部压缩算法也升级到QPack

QUIC实际上是一个在UDP上的伪TCP+TLS+HTTP/2的多路复用协议，但现在普及仍非常慢。

参考整理自 程序员小吴 微信公众号（五分钟学算法）