HTTP协议必知必会详解

系列文章目录

摘要

在学习 Web 容器、后端开发的过程中，HTTP 协议是绕不开的基础。很多开发者虽然日常天天用 HTTP，却对其核心机制一知半解：HTTP 和 HTML 到底有什么区别？无状态协议是怎么实现用户登录状态保持的？长连接和无状态为什么不矛盾？

本文将从 HTTP 的本质出发，带你拆解一次完整的 HTTP 请求过程，分析请求与响应的报文结构，深入讲解 Cookie 与 Session 的工作原理，同时解答很多开发者容易混淆的长连接与无状态的关系，帮你彻底搞懂 HTTP 协议的核心知识点，为深入学习 Tomcat、Jetty 等 Web 容器打下坚实基础。

一、开篇：你真的分得清 HTTP 和 HTML 吗？

在深入学习 Tomcat、Jetty 这类 Web 容器之前，我想先问你一个问题：HTTP 和 HTML 有什么区别？

这其实是一个很好的入门测试，能帮你快速检验自己对 HTTP 协议的理解程度。因为 Tomcat 和 Jetty 本质上就是HTTP 服务器 + Servlet 容器，如果连最基础的 HTTP 协议都没搞懂，想要深入理解 Web 容器的工作原理，无异于空中楼阁。

如果你对这个问题还有些迟疑，没关系，跟着本文一起，我们重新把 HTTP 协议的核心知识点梳理一遍。

二、HTTP 的本质：浏览器与服务器的 “约定语言”

很多人都知道，HTTP 是应用层协议，基于 TCP/IP 协议来传输数据，比如 HTML 文件、图片、接口数据等等。但很多人忽略了一点：HTTP 协议本身不关心数据包在网络里是怎么传输的，它核心要解决的，是客户端和服务器之间的通信格式问题。

举个很简单的例子：当你在浏览器里输入网址，想要从服务器获取一个 HTML 页面的时候，浏览器要做两件事：

1. 和服务器建立 Socket 连接，这是网络通信的基础，有了这个连接，双方才能收发数据。
2. 把自己的需求打包成数据，通过这个连接发给服务器。
   第一步很好理解，那第二步里，浏览器要怎么告诉服务器我想要什么？

• 我是要获取数据，还是要提交表单？
• 我想要的是哪个资源？是首页还是用户列表？
• 我能接收什么格式的返回数据？能不能支持压缩？
  这些信息如果没有一个统一的格式，服务器根本没办法解析。比如浏览器发了一堆乱码一样的字符，服务器怎么知道你要干嘛？

三、一次完整的 HTTP 请求，到底经历了什么？

很多开发者天天发 HTTP 请求，却从来没认真想过，从你点击链接，到页面展示出来，这中间到底发生了多少步？我们来完整走一遍这个流程：

1. 触发请求：用户在浏览器里输入网址回车，或者点击了一个超链接，浏览器捕获到这个操作，知道要发起网络请求了。

2. 发起 TCP 连接请求：浏览器根据域名解析出服务器的 IP 地址，然后向服务器的对应端口（默认 80）发起 TCP 连接请求。

3. TCP 三次握手建立连接：服务器收到连接请求后，双方经过 TCP 三次握手，确认彼此的收发能力都正常，正式建立起 TCP 连接。

4. 打包请求数据：浏览器把用户的请求，按照 HTTP 协议的格式，打包成一个 HTTP 请求报文。

5. 网络传输请求：把这个报文通过之前建立的 TCP 连接，发送给服务器，经过网络路由，最终到达服务器的应用程序。

6. 服务器解析请求：服务器的 HTTP 服务程序（比如 Tomcat）拿到这个报文，按照 HTTP 协议的格式解包，解析出客户端的需求：你要访问哪个路径？用的什么方法？传了什么参数？

7. 处理业务逻辑：服务器根据解析出来的请求，处理对应的业务：如果是静态资源，就直接读文件；如果是动态接口，就调用对应的后端程序，拿到处理结果。

8. 打包响应数据：服务器把处理结果，再按照 HTTP 协议的格式，打包成响应报文。

9. 网络传输响应：把响应报文通过 TCP 连接发回给浏览器，经过网络传输到达客户端。

10. 浏览器解析响应：浏览器拿到响应报文，按照 HTTP 协议解包，拿到里面的内容，如果是 HTML，就开始解析渲染页面。

11. 页面渲染展示：浏览器把解析好的 HTML、CSS、JS 处理完，最终把页面展示给用户。

而我们常说的 Tomcat、Jetty 这类 Web 容器，在这个过程中，负责的就是接受连接、解析请求、处理请求、发送响应这几个核心步骤。

要注意的是，一台服务器可能要同时处理成千上万的浏览器请求，如果一个个串行处理，效率会极低。所以 Tomcat 这类容器都会用多线程技术，把这些步骤并行化，来提升并发处理能力，这也是我们后续深入学习 Web 容器的核心重点之一。

四、拆解 HTTP 报文：请求与响应的内部结构

说了这么多格式，那 HTTP 的报文到底长什么样？我们拿一个真实的登录请求来拆解一下，你一看就懂了。

4.1 HTTP 请求报文

这是极客时间登录接口的真实请求，我们把它整理成标准格式：

POST /account/ticket/login HTTP/1.1 Accept: application/json, text/plain, */* Accept-Encoding: gzip, deflate, br Accept-Language: en,de;q=0.9,zh-CN;q=0.8,zh;q=0.7,en-US;q=0.6 Connection: keep-alive Content-Length: 115 Content-Type: application/json Host: account.geekbang.org User-Agent: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.81 Safari/537.36 {"country":86,"cellphone":"139********","password":"*******","captcha":"","remember":1,"platform":"web"}

你可以看到，一个完整的 HTTP 请求报文，分为三个部分：

1. 请求行：就是第一行，包含三个信息：

   • 请求方法：这里是POST，表示这是一个提交数据的请求，除此之外还有 GET、PUT、DELETE 等常用方法。

   • 请求路径：/account/ticket/login，表示要访问的服务器接口路径。

   • HTTP 版本：HTTP/1.1，表示用的是 1.1 版本的 HTTP 协议。

2. 请求头：从第二行开始，到空行之前的部分，都是请求头，这是一系列的键值对，用来传递一些附加的信息：

   • Accept：告诉服务器，我客户端能接收什么类型的返回数据。

   • Accept-Encoding：我支持的压缩方式，这样服务器可以返回压缩后的数据，减少传输体积。

   • Content-Type：我这次请求的正文是什么格式，这里是application/json，说明正文是 JSON 格式的数据。

   • Host：要访问的主机域名，因为一台服务器可能部署了多个网站，靠这个来区分。

   • User-Agent：客户端的标识，告诉服务器我是什么浏览器、什么版本，服务器可以根据这个做不同的适配。

3. 请求正文：空行之后的部分，就是真正要传输的业务数据，这里就是我们提交的登录账号密码信息。

当这个请求到达 Tomcat 之后，Tomcat 会把这些字节流解析成一个Request对象，把请求行、请求头、正文这些信息都封装进去，然后交给 Web 应用去处理。

4.2 HTTP 响应报文

处理完之后，服务器会返回响应，同样的，响应报文也分为三个部分，我们还是看这个登录请求的响应：

HTTP/1.1 200 OK Connection: keep-alive Content-Type: application/json; charset=UTF-8 Date: Sun, 24 Feb 2019 11:50:20 GMT Set-Cookie: expires=Wed, 06-Mar-2019 GMT; Max-Age=864000; path=/; domain=.geekbang.org; HttpOnly {"code":0,"msg":"登录成功","data":{"token":"xxxxxx"}}

1. 状态行：第一行，同样三个信息：

   • HTTP 版本：HTTP/1.1

   • 状态码：200，表示请求处理成功，除此之外还有 404（找不到资源）、500（服务器错误）、302（重定向）等常用状态码。

   • 状态描述：OK，对状态码的文本描述。

2. 响应头：同样是键值对，传递附加信息，比如这里的Set-Cookie，就是服务器告诉浏览器，要把这个 Cookie 存起来，下次请求带上。

3. 响应正文：空行之后的部分，就是服务器返回的业务数据，这里是登录的结果信息。

Web 应用处理完请求之后，会生成一个Response对象，Tomcat 再把这个对象转换成标准的 HTTP 响应报文，发给浏览器，一次请求就完成了。

五、无状态协议的 “破局者”：Cookie 与 Session

HTTP 协议有一个很重要的特点：无状态。

什么意思？就是协议本身，请求和请求之间是没有任何关系的，服务器不会记得你上一次请求了什么，也不会记得你是谁。每一次请求，对服务器来说都是一次全新的、独立的请求。

这就带来了一个问题：比如你登录淘宝，把商品加入购物车，然后刷新页面，服务器如果不记得你是谁，那它就会以为你是个新用户，提示你未登录，购物车也空了，这显然是不能接受的。

所以，为了让服务器能识别用户，在无状态的 HTTP 协议之上，就诞生了 Cookie 和 Session 这两个技术。

5.1 Cookie：存在客户端的 “身份小纸条”

Cookie 本质上，就是服务器让浏览器存在本地的一份小数据。

当你第一次登录服务器的时候，服务器在响应头里通过Set-Cookie，告诉浏览器：“你把这个用户标识存起来，下次给我发请求的时候，记得把这个信息带上”。

然后浏览器就会把这个 Cookie 存在本地，之后每次给这个服务器发请求的时候，都会自动在请求头里带上这个 Cookie。这样服务器拿到 Cookie，就能识别出你是谁了。

简单来说，Cookie 就是一份存在用户本地的 “小纸条”，每次请求都带着它，让服务器能认出你。

5.2 Session：存在服务端的 “用户储物柜”

但是 Cookie 有个问题：它是存在用户本地的，而且是明文传输的，如果我们把用户的账号、密码这些敏感信息都存在 Cookie 里，很容易被窃取，有很大的安全隐患。

所以 Session 就出现了。Session 可以理解为，服务器在自己的内存里，给每个用户开辟了一个 “储物柜”，用来存用户的状态信息，比如用户 ID、登录状态这些。

那服务器怎么把请求和这个储物柜对应起来呢？很简单，服务器给每个储物柜生成一个唯一的编号，也就是Session ID，然后把这个编号通过 Cookie 发给浏览器，让浏览器存起来。

之后每次请求，浏览器带着这个 Session ID 的 Cookie 过来，服务器拿到这个 ID，就能找到对应的那个储物柜，拿到用户的状态信息了。

这样一来，敏感的用户信息都存在服务器端，传到客户端的只有一个没有意义的 Session ID，既安全，又减少了网络传输的体积，因为不用每次都传一大堆用户信息了。

5.3 Session 的创建与管理

那 Session 是什么时候创建的呢？是在服务器端创建的。

以 Java Web 为例，当你的 Web 应用调用HttpServletRequest.getSession()方法的时候，Tomcat 这类 Web 容器就会检查请求里有没有 Session ID，如果没有，就会创建一个新的 Session，生成唯一的 Session ID，然后把这个 ID 通过 Cookie 返回给浏览器。

为了保证 Session 的可靠性，Tomcat 还提供了多种持久化方案：

• 不会把 Session 只存在单机内存里，不然服务器重启，用户的登录状态就没了。

• 通常会把 Session 存在 Redis 这类高性能的中间件里，这样就算服务器集群部署，所有节点都能共享 Session，不会出现用户在不同节点之间切换就掉线的问题。

• 同时 Session 有过期时间，Tomcat 会开一个后台线程，定期清理过期的 Session，释放服务器的资源。

六、解惑：长连接和无状态，真的矛盾吗？

很多人学到这里都会有一个疑问：

HTTP 是无状态的，多个请求之间没有关系，但是 HTTP/1.1 里又引入了长连接，多个请求可以共用同一个 TCP 连接，这不是矛盾了吗？

其实这完全不矛盾，因为这两个东西，根本就不是一个层面的东西。

我们先回顾一下：

• 在 HTTP/1.0 的时候，每次请求都要新建一个 TCP 连接，请求完了就把连接关掉。就好比你每次寄信，都要新修一条路，寄完就把路拆了，下次再寄再修，这显然效率很低，修路的开销太大了。

• 所以 HTTP/1.1 引入了长连接，通过Connection: keep-alive来开启，默认就是开启的。意思是，这个 TCP 连接，一次请求完了不关掉，下次你还要给这个服务器发请求，就直接用这个已经修好的路，不用再重新修路了，省下了 TCP 三次握手的开销。

但是，长连接是 TCP 层面的连接复用，而 HTTP 的无状态，是应用层的协议特性。

也就是说，就算多个请求共用同一个 TCP 连接，这些请求本身还是独立的：

• 每个请求都包含了服务器处理这个请求需要的所有信息，服务器不需要记住上一个请求的状态，就能处理当前的请求。

• 就好比，路是同一条路，但是你寄的每一封信，都是独立的，每封信里都写好了完整的收件人、内容，收信人不需要记得你上一封信寄了什么，拿到这封信就能处理。

这两者完全不冲突，长连接只是优化了传输层的效率，并没有改变 HTTP 协议本身无状态的特性。

而且要注意，HTTP/1.1 的长连接虽然解决了连接复用的问题，但是带来了一个新的问题：队头阻塞。因为同一个连接里的请求，是要排队处理的，前面的请求没处理完，后面的请求就得等着。这个问题直到 HTTP/2.0，通过二进制分帧的方式，才彻底解决。

总结

到这里，我们把 HTTP 协议的核心知识点都梳理了一遍，总结一下：

1. HTTP 的本质：它是浏览器和服务器之间约定的通信格式，HTTP 是 “信封”，用来规定怎么传输数据，而 HTML、JSON 这些是 “信的内容”，是传输的数据本身。

2. 请求流程：一次完整的 HTTP 请求，要经过 TCP 连接建立、请求打包传输、服务器处理、响应打包返回、浏览器渲染这一系列步骤。

3. 报文结构：HTTP 的请求和响应，都分为行、头、正文三个部分，通过标准化的格式，让双方能够互相解析。

4. 状态保持：HTTP 本身是无状态的，所以我们用 Cookie 来在客户端存标识，用 Session 来在服务端存用户状态，实现了用户登录这类有状态的功能。

5. 长连接与无状态：两者并不矛盾，长连接是 TCP 层的连接复用，用来提升传输效率，而无状态是 HTTP 应用层的特性，两者互不影响。

搞懂了这些，你就已经掌握了 HTTP 协议的核心必知必会的知识点，这也是你深入学习 Web 容器、后端开发的重要基础。

不知道你有没有搞懂这些知识点？你在日常开发中，有没有遇到过和 HTTP 协议相关的有趣问题？欢迎在评论区留言讨论。