HTTP详解

阿楷不当程序员

已于 2022-02-27 21:33:00 修改

阅读量655

点赞数

分类专栏：笔记文章标签： http 服务器 https 网络协议 tcp/ip

于 2022-01-13 21:34:00 首次发布

本文链接：https://blog.csdn.net/nivegiveup/article/details/122483022

版权

笔记专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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：表示服务器忙，暂无法响应。

常见字段

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

GET 与 POST

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

HTTP特性

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

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

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

无状态双刃剑
- 无状态的好处：服务器不会记忆HTTP的状态，所以不需要额外的资源来记录状态信息，可以减轻服务器的负担。
- 无状态的坏处：既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
  - 如：登陆->添加购物车->下单->结算->支付，这些操作都需要知道用户身份，若无关联，则每一次都要询问身份信息
  - 解决方法如Cookie技术(存储在用户本地终端上的数据)，客户端请求一次后，服务器会发一个装有客户信息的小贴纸，再次请求时，则服务器就可以有效识别
明文传输双刃剑
- 明文意味着在传输过程中的信息，是可方便阅读的，通过F12和抓包都可以查看；但在传输的漫长的过程中，信息的内容很容易被窃取，毫无隐私可言。
不安全
- 通信使用明文(不加密)，内容可能会被窃听。如：账号信息容易泄漏，那你号没了。
- 不验证通信方的身份，因此有可能遭遇伪装。如：访问假的淘宝、拼多多，那你钱没了。
- 无法证明报文的完整性，所以有可能已遭篡改。如；网页上植入垃圾广告，视觉污染，眼没了。

HTTP/1.1性能

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

长连接
- 即持久连接，减少一次TCP连接(三次握手)所带来的通信开销。
- 持久连接的特点是，只要任意一端没有明确提出断开连接，则保持TCP连接状态。
‌管道网络传输
- 即在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以‌减少整体的响应时间。
- 如，客户端同时发送A、B请求，服务器按照顺序先回应A请求，再回应B请求。若第一个回应较慢，则后续请求会排队等待响应，即「队头阻塞」。
队头阻塞
- 「请求-应答」的模式加剧了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算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段，只发送索引号，这样就‌提高速度了。
1. 二进制格式
  - HTTP/2全面采用了‌二进制格式，头信息和数据体都是二进制，统称为桢(frame)：‌头信息桢和数据帧。
2. 数据流
  - HTTP/2的数据包不是按顺序发送的，同一连接里连续的数据包，可能会有不同回应。因此，必须要对数据包左标记，指出它属于哪个回应。
  - 每个请求或回应的所有数据包，称为一个数据流(Stream)。每个数据流都标记一个独一无二的编号，其中客户端发出的数据流编号为奇数，服务器为偶数。
  - 客户端还可以‌指定数据流的优先级。优先级越高，服务器就会先响应。
3. ‌多路复用
  - HTTP/2是可以在‌一个连接中并发多个请求或回应，而不用按照顺序一一对应。
    * 移除了1.1中的串行请求，不需要排队等待，不会出现「对头阻塞」问题，‌降低里延迟，大幅度提高里连接的利用率。
如在一个TCP连接里，服务器收到了客户端A和B的两个请求，如果发现A处理过程非常耗时，于是就回应A请求已经处理好的部分，接着回应B请求，完成后，再回应A请求剩下的部分。
1. 服务器推送
  - HTTP/2还在一定程度上改善了传统的「请求-应答」工作模式，服务不再是被动地响应，也可以‌主动向客户端发送消息。