HTTP详解

HTTP

概念

• HTTP是一个用于在两点之间传输文字、图片、音频、视频等超文本数据等约定和规范

---

五大类HTTP状态码

• 1xx：提示信息，表示目前是协议处理的中间状态，还需后续操作
• 2xx：成功，报文已经收到并被正确处理
  • 200 OK：表示一切正常。若为非HEAD请求，服务器返回的响应头会有body数据。
  • 204 No Content：同200，但响应头没有body数据。
  • 206 Partial Content：表示响应返回的body数据是其中的一部分，也是服务器处理成功的状态。
• 3xx：重定向，资源位置发生变动，需要客户端重新发送请求
  • 301 Moved Permanently：表示永久重定向，即资源已不存在，需用新的URL再次访问。
  • 302 Found：表示临时重定向，即资源还在，暂时需要另一个URL来访问。
  • 301和302用响应头中的Location指明后续要跳转的URL。
• 4xx：客户端错误，请求报文有误，服务器无法处理
  • 400 Bad Request：表示客户端请求的报文有错误。
  • 403 Forbidden：表示服务器禁止访问资源。
  • 404 Not Found：表示请求的资源在服务器上不存在或未找到。
• 5xx：服务器错误，服务器在处理请求时内部发生了错误
  • 500 Internal Server Error：表示服务器发生未知错误。
  • 501 Not Implemented：表示客户端请求的功能还不支持 – 即将开业，敬请期待。
  • 502 Service Unavailable：表示服务器忙，暂无法响应。

---

常见字段

1. Host：客户端发送请求时，用来指定服务器的域名。
   • Host: www.A.com
2. Content-Length：表明本次返回的数据长度。
   • Content-Length:1000 – 该资源大小1000个字节
3. Connection：常用于客户端请求服务器使用TCP持久连接。
   • Connection:keep-alive
4. Content-Type：用于服务器回应时，告诉客户端，本次数据时什么格式。
   • Content-Type: text/html ; charset=utf-8 – 发送的是网页，编码为utf-8
   • 客户端指定可以接受哪些数据格式：Accept: / – 任意
5. Content-Encoding：表示服务器返回的数据使用了什么压缩格式。
   • Content-Encoding: gzip
   • Accept-Encoding: gizp, deflate – 客户端指定可以接受的压缩方式

---

GET 与 POST

1. 区别
   • GET：是指从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
   • POST：是指向URL指定的资源提交数据，数据就放在报文的body里。
2. 安全和幂等
   • 安全：是指请求方法不会破坏服务器上的资源。
   • 幂等：是指多次执行相同的操作，结果都是相同的。
   • GET方法就是安全且幂等的，因为他是只读操作，无论操作几次，其数据都是安全的，且每次结果都一样。
   • POST因为是新增或提交数据的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据会创建多个资源，所以不是幂等的。

---

HTTP特性

• 优点：简单、灵活和易于扩展、应用广泛和跨平台。

1. 简单
   • HTTP基本的报文格式为header+body，头部为key-value,易于理解。
2. 灵活和易于扩展
   • HTTP中的请求方法、URI/URL、状态码、头字段等都允许自定义和扩充。
   • HTTP工作在应用层(OSI第七层)，则它**下层可以随意变化

• 缺点：无状态、明文传输，不安全

1. 无状态双刃剑

   • 无状态的好处：服务器不会记忆HTTP的状态，所以不需要额外的资源来记录状态信息，可以减轻服务器的负担。
   • 无状态的坏处：既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
     • 如：登陆->添加购物车->下单->结算->支付，这些操作都需要知道用户身份，若无关联，则每一次都要询问身份信息
     • 解决方法如Cookie技术(存储在用户本地终端上的数据)，客户端请求一次后，服务器会发一个装有客户信息的小贴纸，再次请求时，则服务器就可以有效识别

2. 明文传输双刃剑

   • 明文意味着在传输过程中的信息，是可方便阅读的，通过F12和抓包都可以查看；但在传输的漫长的过程中，信息的内容很容易被窃取，毫无隐私可言。

3. 不安全

   • 通信使用明文(不加密)，内容可能会被窃听。如：账号信息容易泄漏，那你号没了。
   • 不验证通信方的身份，因此有可能遭遇伪装。如：访问假的淘宝、拼多多，那你钱没了。
   • 无法证明报文的完整性，所以有可能已遭篡改。如；网页上植入垃圾广告，视觉污染，眼没了。

---

HTTP/1.1性能

• HTTP协议是基于‌TCP/IP,使用了「‌请求 - 应答」的通信模式。

1. 长连接
   • 即持久连接，减少一次TCP连接(三次握手)所带来的通信开销。
   • 持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
2. ‌管道网络传输
   • 即在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以‌减少整体的响应时间。
   • 如，客户端同时发送A、B请求，服务器按照顺序先回应A请求，再回应B请求。若第一个回应较慢，则后续请求会排队等待响应，即「队头阻塞」。
3. 队头阻塞
   • 「请求-应答」的模式加剧了HTTP的性能问题。
   • 因为当请求序列被阻塞时，后面排队的所有请求都被阻塞。

---

HTTP与HTTPS

• 区别
  1. HTTP是明文传输，存在安全风险；HTTPS加入了SSL/TLS安全协议，能够加密传输。
  2. HTTP建立简单，TCP三次握手便可传输；HTTPS在TCP三次握手后，需要进行SSL/TLS的握手过程，才可进入加密报文传输。
  3. HTTP端口号为80，HTTPS端口号为443。
  4. HTTP S协议需要向CA申请数字证书，来保证服务器的身份是可信的。
• HTTPS解决的问题
  • HTTP存在的风险：‌窃听风险、‌篡改风险、‌冒充风险。
  • HTTP‌S在HTTP与TCP层之间加入了SSL/TLS协议，解决了以上风险：
    1. ‌信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
    2. ‌效验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
    3. 身份证书：证明淘宝时真多淘宝网，但你的钱还是会因为「剁手」而没。
• HTTPS如何解决上述三个风险
  • ‌混合加密的方式实现信息的‌机密性，解决了窃听的风险。
  • ‌摘要算法的方式实现完整性，为数据生成独一无二的「指纹」，用于效验数据的完整性，解决被篡改的风险。
  • 将服务器公钥放入到‌数字证书中，解决了冒充的风险。
  1. 混合加密
     • 通过‌混合加密的方式可以保证信息的‌机密性，解决了窃听的风险。
     • HTTPS采用的是‌对称加密和‌非对称加密结合的「混合加密」方式：
       • 在通信建立前采用非对称加密的方式交换「会话密匙」，后续就不再使用非对称加密。
       • 在通信过程中全部使用‌对称加密的「会话密匙」的方式加密明文数据。
         ‌注：对称加密是指同一个密匙可以同时用作信息的加密和解密；非对称加密是指需要两个密匙来进行加密和解密，这两个密匙是公开密匙和私有密匙
  2. 摘要算法
     • ‌客户端在发送明文之前，会通过摘要算法算出「指纹」，把「指纹+明文」一起加密称秘闻后发送给服务器。
     • 服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据时完整的。
  3. 数字证书
     • 客户端先向服务器端索要公匙，然后用公匙加密信息，服务器收到密文后，用自己的私匙解密。
     • 这就存在些问题，如何保证公匙不被篡改和信任度？
     • 这里需要借助第三方权威机构CA，将‌服务器公匙放在数字证书中，只要证书是可信的，公匙就是可信的。
• HTTPS是如何建立连接的？其间交互了什么？
  • SSL/TLS协议基本流程：
    • 客户端向服务器索要并验证服务器的公匙。
    • 双方协商生产「会话秘钥」。
    • 双方采用「会话秘钥」进行加密通信。
  • SSL/TLS协议建立的详细流程：
    1. ClientHello
       • 首先，由客户端向服务器发起加密通信请求，也就是‌ClientHello请求。在这一步，客户端主要向服务器发送以下信息：
         1. 客户端支持的SSL/TLS协议版本，如TLS 1.2版本。
         2. 客户单生产随机数(Client Random)，后面用于生产「会话秘钥」。
         3. 客户端支持的密码套件列表，如RSA加密算法。
    2. ‌SeverHello
       • 服务器收到客户端请求后，向客户端发出响应，也就是ServerHello。服务器回应的内容如下：
         1. 确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信。
         2. 服务器生产的随机数(Server Random)，后面用于生产「会话秘钥」。
         3. 确认的密码套件列表，如‌RSA加密算法。
         4. 服务器的数字证书。
    3. ‌客户端回应
       • 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
         1. 一个随机数(pre-master key)。该随机数会被服务器公钥加密。
         2. 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
         3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
       • 上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，‌各自生成本次通信「会话秘钥」。
    4. 服务器的最后回应
       • 服务器收到客户端的第三个随机数(‌pre-master key)之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
         1. 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通话。
         2. 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
       • 至此，整个SSL/TLS的握手阶段全部结束，而后进入加密通信，使用普通的HTTP协议，只不过用「会话秘钥」加密内容。

---

HTTP/1.1、HTTP/2、HTTP/3演变

• HTTP/1.1相比HTTP/1.0提高了什么性能？

  • 改进：
    • 使用TCP长连接的方式改善了HTTP/1.0短连接造成的性能开销。
    • 支持管道(pipeline)网络传输，减少整体的响应时间。
  • 瓶颈：
    • 请求/响应头部(Header)未经压缩就发送，首部信息越多延迟越大。只能压缩Body的部分；
    • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
    • 服务器按请求顺序响应，若响应慢，则会造成对头阻塞；
    • 没有请求优先级控制；
    • 请求只能从客户端开始，服务器只能被动响应。

• HTTP/2对如上问题作了什么优化？

  • HTTP/2基于HTTPS，安全性较为保障。
  • 改进：
  1. 头部压缩
  • HTTP/2会‌压缩头(Header)，若同时发送多个请求，且头相同或相似，则会‌消除重复的部分。
  • 这就是HPACK算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段，只发送索引号，这样就‌提高速度了。
  2. 二进制格式
     • HTTP/2全面采用了‌二进制格式，头信息和数据体都是二进制，统称为桢(frame)：‌头信息桢和数据帧。
  3. 数据流
     • HTTP/2的数据包不是按顺序发送的，同一连接里连续的数据包，可能会有不同回应。因此，必须要对数据包左标记，指出它属于哪个回应。
     • 每个请求或回应的所有数据包，称为一个数据流(Stream)。每个数据流都标记一个独一无二的编号，其中客户端发出的数据流编号为奇数，服务器为偶数。
     • 客户端还可以‌指定数据流的优先级。优先级越高，服务器就会先响应。
  4. ‌多路复用
     • HTTP/2是可以在‌一个连接中并发多个请求或回应，而不用按照顺序一一对应。
       * 移除了1.1中的串行请求，不需要排队等待，不会出现「对头阻塞」问题，‌降低里延迟，大幅度提高里连接的利用率。

  如在一个TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就回应A请求已经处理好的部分，接着回应B请求，完成后，再回应A请求剩下的部分。

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

如在浏览器刚请求HTML的时候，就提前把可能会用到的JS、CSS文件等静态资源主动发给客户端，‌减少延时的等待，也就是服务器推送(Server Push，也叫Cache Push)。

• HTTP/2的缺陷，HTTP/3作出的优化
  • 2主要的问题在于，多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。所以一旦发生了丢包现象，就会出发TCP的重传机制，这样一个TCP连接中的‌所有的HTTP请求都是必须等待这个丢了的包被重传回来。

HTTP/1.1中的管道(pipeline)传输中如果有一个请求阻塞了，那么队列后请求也通通被阻塞住了
HTTP/2多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的HTTP请求
* 这都是基于TCP传输层的问题，所以‌HTTP/3把HTTP下层的TCP协议改成了UDP。