HTTP协议版本的发展（HTTP/0.9、1.0、1.1、2、3）

目录
HTTP协议层次图
HTTP/0.9
例子
HTTP/1.0
Content-Type 字段
Content-Encoding 字段
例子
1.0版本存在的题目：短链接、队头阻塞
HTTP/1.1
Host字段
Content-Length 字段
分块传输编码
1.1版本存在的题目
HTTP/2
HTTP/2数据传输
2版本存在的题目
HTTP/3
队头阻塞题目总结
HTTP1.1断点续传
如果服务器支持断点续传
如果服务器不支持断点续传
断点续传的应用
HTTP Keep-Alive 机制

---

   HTTP协议层次图

  

    HTTP/0.9

  HTTP/0.9是最早的一个版本，在1991年发布，只有GET一种哀求方法，并且不支持哀求头。只支持纯文本一种内容，服务器只能相应HTML格式的字符串，且不能插入图片。HTTP/0.9具有典型的无状态、无毗连特性。  例子

  哀求：   

1. GET /index.html

复制代码

相应：

1. <html>
2.   <body>Hello World</body>
3. </html>

复制代码

    HTTP/1.0

  HTTP/1.0协议于1996年发布，是一种无状态、无毗连的应用层协议。   

• 增加POST、HEAD等哀求方法。
  
• 引入头部信息。除了要传输的数据之外，每次通讯都包含头信息，用来描述一些信息。
  
• 传输数据格式不再局限于HTML格式。根据Content-Type可以支持多种数据格式，不光可以用来传输文字，还可以传输图像、音频、视频等二进制文件。
  
• 引入cache缓存机制。
  
• 引入状态码。
  

     Content-Type 字段

  关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。
  下面是一些常见的Content-Type字段的值。
     text/plain
   text/html
   text/css
   image/jpeg
   image/png
   image/svg+xml
   audio/mp4
   video/mp4
   application/javascript
   application/pdf
   application/zip
   application/atom+xml
   
  Content-Encoding 字段

  由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段阐明数据的压缩方法。
     Content-Encoding: gzip
   Content-Encoding: compress
   Content-Encoding: deflate
    客户端在哀求时，用Accept-Encoding字段阐明自己可以接受哪些压缩方法：
     Accept-Encoding: gzip, deflate
        例子

  哀求：

1. GET / HTTP/1.0
2. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
3. Accept: */*

复制代码

    客户端哀求的时候，可以利用Accept字段声明自己可以接受哪些数据格式。Accept: */*：表明户端可以接受任何格式的数据。
    相应：

1. HTTP/1.0 200 OK Content-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84<html>
2.   <body>Hello World</body>
3. </html>

复制代码

        1.0版本存在的题目：短链接、队头阻塞

      

• 短链接：每个TCP毗连只能发送一个哀求，当服务器相应后就会关闭这个TCP毗连，下一次哀求需要再次建立TCP毗连。每次建立、释放TCP毗连需要三次握手四次挥手，以是当网页需要发送多个HTTP哀求时，就会造成性能题目。
  
• 队头阻塞：下一个哀求必须在前一个哀求相应到达之前才能发送，若前一个哀求相应一直不到达，那下一个哀求就不发送，同样后面的哀求也被阻塞了。
  

                   HTTP/1.1

    为解决HTTP/1.0短毗连造成的性能开销，HTTP/1.1引入了长期毗连。      

• 新增了哀求方式PUT、PATCH、OPTIONS、DELETE等。
  

      

• 增强缓存计谋：如Etag、If-Unmodified-Since、If-Match、If-None-Match等可供选择的了缓存头来控制缓存计谋。
  

      

• 客户端哀求的头信息新增了Host字段，用来指定服务器的域名。
  

      

• 引入长期毗连（即长毗连） ：可以通过设置connection: keep-alive来保持HTTP毗连不停开，制止频繁的建立、释放毗连。如果客户端和服务器端发现对方一段时间没有活动，就可以主动关闭毗连。不过，规范的做法是，客户端在末了一个哀求是，发送connection: false来明确要求服务器关闭TCP毗连。（1.1默认有长链接，1.0需要手动的添加connection: keep-alive才能保持长链接）
  
• 加入管道机制：基于HTTP/1.1的长链接，在同一个TCP毗连里，允许多个哀求同时发送。但是还是有题目：假设客户端需要哀求两个资源。从前的做法是，在同一个TCP毗连里，先发送A哀求，然后等待服务做出相应，收到后再发出B哀求。管道机制允许欣赏器同时发出A哀求和B哀求，但服务器还是按照哀求次序，先相应A哀求，再相应B哀求，以是这并不是真正意义上的并行传输。现阶段的欣赏器厂商实现并行传输，采用的做法是允许打开多个TCP会话，这就是我们所熟悉的欣赏器对同一个域下能够并行加载6~8个资源的限制。（以是说HTTP/1.1 管道解决了哀求的队头阻塞，但是没有解决相应的队头阻塞）
  
• HTTP/1.1支持文件断点续传：RANGE:bytes，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX体现要求服务器从文件XXXX字节处开始传送，断点续传。返回码是206(Partial Content)
  

      

• Content-length字段：声明本次回应的数据长度。
  

      

• 分块传输编码：利用Content-Length字段的前提条件是服务器发送相应之前，必须知道相应的数据长度。对于一些很耗时的动态操纵来说，这意味着，服务器要比及全部操纵完成才能发送数据，显然这样的效率不高。更好的处置惩罚方法是，产生一块数据，就发送一块，采用“流模式”(stream)，取代“缓存模式”(buffer)。因此，1.1版本规定可以不利用Content-Length字段，而利用“分块传输编码”，只要哀求或回应的头信息有Transfer-Encoding字段，就表明相应将由数目未定的数据块构成。
  

              Host字段

      Host 哀求头字段的引入紧张是为相识决虚拟主机（Virtual Hosting）的题目，即 一台物理服务器托管多个域名网站时，如何准确区分不同域名的哀求。         

• HTTP/1.0 的题目：在 HTTP/1.0 中，哀求只包含路径（如 GET /index.html），不包含域名信息。如果一台服务器托管了 example.com 和 test.com，服务器无法区分哀求是发给哪个域名的。
  
• HTTP/1.1 的解决方案：强制要求客户端在哀求头中添加 Host 字段，明确指定目的域名：服务器会根据 Host 字段将哀求路由到对应的网站。如下：
  

   

1. GET /index.html HTTP/1.1
2. Host: example.com

复制代码

   
    Content-Length 字段

    一个TCP毗连现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是Content-length字段的作用，声明本次回应的数据长度。
   

1. Content-Length: 3495

复制代码

   上面代码告诉欣赏器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。
    在1.0版中，Content-Length字段不是必须的，因为欣赏器发现服务器关闭了TCP毗连，就表明收到的数据包已经全了
   
   
    分块传输编码

   

1. Transfer-Encoding: chunked // 分块传输

复制代码

   每一个非空的数据块之前，会有一个16进制的数值，体现这个块的长度。末了是一个大小为0的块，就体现本次回应的数据发送完毕：
   

1. HTTP/1.1 200 OK
2. Content-Type: text/plain
3. Transfer-Encoding: chunked
5. 25
6. This is the data in the first chunk
8. 1C
9. and this is the second one
11. 3
12. con
14. 8
15. sequence
17. 0

复制代码

   
        1.1版本存在的题目

        1.1利用长期毗连、管道化优化了性能，但没有彻底解决队头阻塞题目。                       HTTP/2

         

• 二进制分帧：HTTP/1.1版本的头信息必须是文本（ASCII编码），数据体可以是文本，也可以是二进制，HTTP/2则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为“帧”(frame)：头信息帧和数据帧。如下图：
  
  
  
• 多路复用：HTTP/2版本会复用TCP毗连。在一个毗连里，客户端和服务器端都可以同时发送多个哀求或相应，而且不用按照次序一一对应，这样就制止了“队头阻塞”。（多路复用是通过 流Streams和 二进制帧Frames实现的，而非直接复用原始 HTTP 消息）
  
• 数据流：因为 HTTP/2 的数据包是不按次序发送的，同一个毗连里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标志，指出它属于哪个回应。
  

                         HTTP/2 将每个哀求或回应的全部数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标志数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。                 数据流发送到一半的时候，客户端和服务器都可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP毗连。这就是说，HTTP/2 可以取消某一次哀求，同时保证TCP毗连还打开着，可以被其他哀求利用。                 客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。                       

• 头信息压缩：HTTP 协议不带有状态，每次哀求都必须附上全部信息。以是，哀求的许多字段都是重复的，比如Cookie和User Agent，千篇一律的内容，每次哀求都必须附带，这会浪费许多带宽，也影响速度。HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息利用gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，全部字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
  

            

• 服务器推送：HTTP/2允许服务器不需要客户端的哀求就可以主动向客户端发送资源。
  

                         常见场景是客户端哀求一个网页，这个网页里面包含许多静态资源。正常情况下，客户端必须收到网页后，剖析HTML源码，发现有静态资源，再发出静态资源哀求。实在，服务器可以预期到客户端哀求网页后，很可能会再哀求静态资源，以是就主动把这些静态资源随着网页一起发给客户端了。                       

• 流量控制： HTTP/2不同于HTTP/1.1的只要客户端可以处置惩罚，服务端就会尽可能快地发送数据。HTTP/2提供了客户端调解传输速度的本领（服务端也可以），在每一个数据帧中告诉对方，发送方想要接受多少字节的数据。
  

            HTTP/2数据传输

        

            从图中可见，全部的HTTP/2通讯都在一个TCP毗连上完成，这个毗连可以承载任意数目的双向数据流。
     每个数据流以消息的形式发送，而消息由一个或多个帧构成。这些帧可以乱序发送，然后再根据每个帧头部的stream id标识符来重新组装。
     举个例子，每个哀求是一个数据流，数据流以消息的方式发送，而消息又分为多个帧，帧头部记载着stream id用来标识当前帧所属的数据流，不同属的帧可以在毗连中稠浊在一起。接收方可以根据stream id将帧再归属到各自不同的哀求中去。
     另外，多路复用（毗连共享）可能会导致关键哀求被阻塞。HTTP/2里每个数据流都可以设置优先级和依靠，优先级高的数据流会被服务器优先处置惩罚和返回给客户端，数据流还可以依靠其他的子数据流。
     
     
          2版本存在的题目

           队头阻塞：
      HTTP/2 的多路复用依靠于一条 TCP 毗连，而 TCP 是面向字节流的协议，要求数据按次序到达，如果某个TCP 包丢失，那么整个毗连会等待重传，导致全部流被阻塞。
      
               HTTP/3

          HTTP/3 基于 QUIC 协议（Quick UDP Internet Connections），解决了 HTTP/2 的遗留题目。                    

• TCP 队头阻塞：HTTP/2 的 多路复用 在 TCP 上运行时，若一个包丢失，全部流（Stream）都会被阻塞。HTTP/3 利用 QUIC（基于 UDP），每个流独立传输，丢包只影响当前流，其他流不受影响。
  

             HTTP/3 只利用一个 UDP 毗连，但在这个毗连内部通过 QUIC 协议 实现了多路复用，而不是建立多个 UDP 毗连。在单个 UDP 毗连内创建多个Streams流，每个 HTTP 哀求/相应对应一个独立的 QUIC 流（利用Stream ID标识），这些流共享同一个 UDP 毗连，但相互独立，以是一个流丢包不会阻塞其他传播输消息。
            

• 淘汰握手延迟HTTP/2 需要 TCP 三次握手 + TLS 握手（1~2 RTT），而 HTTP/3 的 QUIC 直接内置 TLS 1.3，支持：        
  
  
  
  • 1-RTT 初次毗连（比 HTTP/2 更快）。
    
  • 0-RTT 恢复毗连（对之前访问过的服务器可立即发送数据）。
    
  
  

                    

                               队头阻塞题目总结

            HTTP1.0存在短链接、队头阻塞题目                       HTTP/1.1 通过以下改进淘汰了部分性能题目，但未彻底解决队头阻塞：                  

• 长期毗连（Keep-Alive）：默认复用同一个 TCP 毗连，制止了频繁建立毗连的开销。
  
• 管道化（Pipelining）：允许客户端在未收到相应时发送多个哀求（理论上的优化）。（相应必须按哀求次序返回：如果第一个哀求的相应延迟（例如服务器处置惩罚慢或网络延迟），后续已发送的哀求相应会被阻塞，纵然它们已经准备停当。）
  

                        HTTP/2 和 HTTP/3：                  

• HTTP/2：通过多路复用（Multiplexing）在单个毗连上并行传输多个哀求/相应，彻底解决了应用层的队头阻塞。但若底层 TCP 丢包，仍会因重传导致全部流阻塞（TCP 层队头阻塞）。
  
• HTTP/3：基于 QUIC 协议（UDP 实现），解决了 TCP 层的队头阻塞，每个流独立传输，丢包不影响其他流。
  

                                 
     
          HTTP1.1断点续传

          HTTP/1.1 通过 Range 哀求头 和 Content-Range 相应头 支持文件的断点续传（Partial Content），允许客户端只哀求资源的某一部分，而不是整个文件。这在下载大文件、视频流或恢复停止的下载时非常有用，可以     有效制止重复下载。              如果服务器支持断点续传

           

客户端发起带 Range 头的哀求：客户端在哀求中指定需要下载的字节范围（如从第 1000 字节开始）。

     

1. GET /large-file.zip HTTP/1.1
2. Host: example.com
3. Range: bytes=1000-2000

复制代码

            

• Range: bytes=start-end：哀求文件的特定字节范围（end 可省略，体现直到文件末端）。
  
• 例如：         
  
  
  
  • Range: bytes=0-499 → 哀求前 500 字节
    
  • Range: bytes=500- → 哀求从第 500 字节到文件末端
    
  • Range: bytes=500-999,2000-2499 → 哀求多个范围（较少利用）
    
  
  

                  

      

如果服务器支持断点续传，会返回 206 状态码，并标明返回的数据范围：

      

1. HTTP/1.1 206 Partial Content
2. Content-Range: bytes 1000-2000/5000
3. Content-Length: 1001
4. Content-Type: application/zip
6. [文件数据...]

复制代码

              

• Content-Range: bytes start-end/total：           
  
  
  
  • start-end：实际返回的字节范围
    
  • total：文件的完备大小（如果未知，可以用 * 代替）
    
  
  
• Content-Length：返回的数据长度（这里是 2000 - 1000 + 1 = 1001 字节）
  

                     

        

客户端继承下载剩余部分：客户端可以继承发送新的 Range 哀求，直到文件下载完成。

                                        注意：如果客户端哀求的字节范围不合法，比如超出了哀求文件的大小，那么服务端就会返回416状态码。                                          StatusRequestedRangeNotSatisfiable（哀求的状态范围不满足） = 416                                                    如果服务器不支持断点续传

        如果服务器不支持 Range 哀求，会直接返回 200 OK 和整个文件：
      

1. HTTP/1.1 200 OK
2. Content-Length: 5000
3. Content-Type: application/zip
5. [完整的文件数据...]

复制代码

       客户端需要查抄状态码是 206 还是 200 来判断是否支持断点续传。
                 StatusPartialContent（状态部分内容）= 206
               
                断点续传的应用

                 

• 大文件下载（如 ISO 镜像、视频文件）：下载工具（如迅雷、IDM）可以分块下载，提高速度。如果下载停止，可以从停止的位置继承下载，而不是重新开始。
  
• 视频/音频流（HTTP Streaming）：播放器可以只哀求视频的某一段（如 Range: bytes=0-1023），实现边下边播。
  
• 断网恢复：欣赏器或下载管理器可以记载已下载的字节位置，恢复时发送 Range 哀求继承下载。
  

                                                                  HTTP Keep-Alive 机制

                  HTTP Keep-Alive（也称为长期毗连，Persistent Connection）是一种允许在单个TCP毗连上发送和接收多个HTTP哀求/相应的机制。它通过复用TCP毗连，淘汰因频繁建立/关闭毗连带来的性能开销。                                   工作原理：                           

• 传统HTTP（无Keep-Alive）：每个HTTP哀求完成后立即关闭TCP毗连，下次哀求需重新建立毗连（三次握手）。
  

                           

1. 请求1 → 响应1 → 关闭连接
2. 请求2 → 响应2 → 关闭连接

复制代码

                           

• 启用Keep-Alive后：多个HTTP哀求复用同一个TCP毗连，淘汰握手和挥手次数。
  

                           

1. 请求1 → 响应1 → 请求2 → 响应2 → ... → 关闭连接

复制代码

                             实现方式：                              

• HTTP/1.1：默认启用Keep-Alive（无需显式声明），除非哀求头包含 Connection: close。
  
• HTTP/1.0：需显式在哀求头中添加 Connection: keep-alive。
  

                              示例哀求头：                                                   

1. GET /index.html HTTP/1.1
2. Host: example.comConnection: keep-alive  # 显式启用（HTTP/1.0需此字段，HTTP/1.1可省略）

复制代码

        
         
         参考：
         HTTP 协议的历史演变和设计思路 
         稀土掘金：HTTP协议各个版本之间的区别