◆ 博主名称： 小此方-CSDN博客 大家好，欢迎来到小此方的博客。
⭐️网络系列个人专栏： 【主题曲】计算机网络
⭐️此方的GitHub： github_此方
⭐️ 我们思考 (Rethink) · 我们重建 (Rebuild) · 我们记录 (Record)
文章目录
- 概要&序論
- 一、剩下的HTTP方法
- [二、从短连接到长连接：Connection 字段解析](#二、从短连接到长连接：Connection 字段解析)
-
- [2.1 HTTP/1.0 时代与短连接的弊端](#2.1 HTTP/1.0 时代与短连接的弊端)
- [2.2 HTTP/1.1 长连接机制与协商](#2.2 HTTP/1.1 长连接机制与协商)
-
- 2.2.1长链接是如何解决这一性能瓶颈的
- 2.2.2协商Connection字段确定是否要使用长链接
- [2.2.3 准确读取 HTTP 请求与长连接的实现](#2.2.3 准确读取 HTTP 请求与长连接的实现)
- [2.3 短连接与长连接的对比](#2.3 短连接与长连接的对比)
- 三、HTTP的特性------无连接、无状态
- 四、Cookie与Session
-
- 4.1Cookie为何诞生------HTTP无状态的弊端
- [4.2 Cookie的定义](#4.2 Cookie的定义)
- [4.3 Cookie的工作原理](#4.3 Cookie的工作原理)
- [4.4 Cookie的分类](#4.4 Cookie的分类)
- 4.5Cookie的巨大网络安全风险
- 五、session一定程度上解决了cookie带来的网络安全问题
概要&序論
Hello大家好，我是此方。本文继续深入 HTTP 协议，从 HTTP/1.0 的短连接出发，分析频繁建立连接带来的性能问题，以及 HTTP/1.1 如何通过 Connection 机制实现长连接。随后进一步理解 HTTP 的无连接、无状态特性，并由此引出 Cookie 与 Session，详细分析 Cookie 的工作原理、分类及安全风险，以及 Session 如何在一定程度上解决 HTTP 无状态带来的问题。
一、剩下的HTTP方法
前三篇HTTP，我们讲解了HTTP的主要的一些方法，还剩下一些，我们来收个尾。
- CONNECT 方法主要用于建立隧道，你发出的请求交给服务器后，服务器会将请求转发给后端的其他服务器。
- PUT 方法目前并不常用，因为现在有了更好的文件上传方案。
- HEAD 方法与 GET 类似，不同的是服务器只返回报文首部，不返回主体内容。
- DELETE 方法在实际生产中一般是禁止的，毕竟不能允许客户端随意删除服务器上的资源。
- OPTIONS 方法通常也是默认禁用的，主要用来查询服务器支持哪些请求方法。
如何测试 OPTIONS 方法？
二、从短连接到长连接：Connection 字段解析
2.1 HTTP/1.0 时代与短连接的弊端
在 HTTP/1.0 时代，短服务是最常用的一种网络服务。这是因为当时网络上的资源非常少，资源体积也比较小。
所谓的短连接，是指浏览器发出请求，服务器接收并处理请求，随后服务器主动关闭连接。由短连接支持的服务被称为短服务。
但是，随着网络世界的发展，短连接存在明显的效率弊端：
比如当前我们需要加载一个包含 1 个 HTML 页面和 3 张图片的网页，浏览器就需要发起 4 次 HTTP 请求。
在短连接模式下，服务器就要受理 4 次请求。每一次请求，服务器都需要重新经历：三次握手、accept 接收连接、fork 创建子进程处理。
这种频繁建立和关闭连接的方式非常费劲。在 HTTP/1.0 时代由于资源少还能勉强接受，但在如今一个网页动辄包含几十张图片的场景下（比如我们打开一个淘宝 ），短连接完全无法满足性能需求。
2.2 HTTP/1.1 长连接机制与协商
2.2.1长链接是如何解决这一性能瓶颈的
为了解决短连接的性能瓶颈，HTTP/1.1 引入了长连接方案。
长连接的核心原理在于：建立一条 TCP 连接后，就可以通过该连接连续交互非常多的请求和响应。浏览器可以一次性发起多个请求，服务器也可以一次性回复多个响应，避免了频繁建立和断开连接的开销。
2.2.2协商Connection字段确定是否要使用长链接
问题来了：如果有一端是老服务器，不支持HTTP1.1呢？所以需要客户端和服务器之间的协商！怎么协商？报文头部的 Connection 字段。
客户端在请求报文头中携带 Connection: keep-alive，表示客户端支持长连接。
如果服务器不支持长连接，响应头中会返回 Connection: close，并关闭连接；
如果服务器也支持长连接，响应头中同样会返回 Connection: keep-alive，双方保持连接继续交互。
所以我们马上得出结论！除了报文的交换，我们的客户端和服务器还要交换彼此的Connection字段，来选择是否要采用长连接的方式。
所谓长连接的本质，就是决定是否应当关闭刚才创建的连接。
我还没有讲完！一个新的问题来了：你能保证自己成功读取到多个HTTP请求吗？
2.2.3 准确读取 HTTP 请求与长连接的实现
长连接能够稳定运行的关键，在于服务器必须能够准确读取并区分每一个完整的 HTTP 请求。
根据 HTTP 协议格式规范，一个完整的 HTTP 请求包含：
依据该格式，只要我们遵循协议，就一定能够读取到一个完整的 HTTP 请求。能够成功读取一个，自然就能连续且完整地读取多个请求 。当时我们编写的网络版本计算机，本质上采用的就是这种长连接模式！
2.3 短连接与长连接的对比
结合文件描述符来看：
- 短连接：多个请求必须使用不同的文件描述符来响应，因为每次建立连接都需要重新 accept。
- 长连接：多个请求可以使用同一个文件描述符来完成连续的响应。
好，到目前为止，我一共出了四篇HTTP的文章，我们把HTTP的方法、状态码、常见的Hander（cookie还没有讲）全部讲完了，并且写了一个迷你的HTTP的服务器。现在应该回归回去，讲一讲HTTP的特性。然后引出我们的最后一个话题：CookieAndSession
三、HTTP的特性------无连接、无状态
常有人说"HTTP 协议是一个无连接、无状态的协议，即每次请求都需要建立新的连接，且服务器不会保存客户端的状态信息"。
问题来了，我们刚才不刚刚讲 HTTP 是支持长连接的吗？
实际上，我们刚才说的长连接指的是让 TCP 保持长连接。HTTP 本身是无连接概念的，只关心 request 和 response。所以刚才的长短连接的 connection 字段实际上只是表示一次连接中，HTTP 请求的个数是一个还是多个。
这也是为什么我们写的迷你HTTP服务器中要把 HTTP 和 TCP 解耦的原因，因为 HTTP 只管收发请求和应答，建立连接的事情是底层的 TCP 做的。连接长连接短不归 HTTP 管。
那么，如何理解无状态？
HTTP 本质就是一个"文件"服务器，只会：解析请求 + 把你需要的资源返回给你。HTTP 服务器不会记录：你历史上是否访问过某个网页。比如你访问了我的首页，你刷新一下，就会去重新请求一次，服务器不会因为"客户已经访问过了"就不受理请求。
HTTP没有记忆，没有状态，但是不代表浏览器不能坐视不管，每次请求都要重新请求一次，不行，太浪费资源了 ，于是浏览器就会在自己内部内置一些缓存。解决这个问题。------他就是cookie。
四、Cookie与Session
4.1Cookie为何诞生------HTTP无状态的弊端
无状态的坏处：无状态，会给用户造成困扰（不会记录用户信息）。 如何理解？如下案例：
- 用户点击访问某个需要用户登录之后，以登录状态访问服务器内部的资源。
- B端发起 request 请求，由于未登录，S端返回 response fail。
- 用户输入账号密码后再次发起 request，S端校验用户名和密码 -> 认证通过，随后返回 response success，并将资源返回回去。
- 当用户点击想要访问的下一个资源并发起 request 时，由于 HTTP 无状态，S端又要求"又要我进行登录"，这就非常为难用户。
问题来了：如何解决这个弊端呢？cookie就登场了。
4.2 Cookie的定义
HTTP Cookie（也称为Web Cookie、浏览器Cookie或简称Cookie）是服务器发送到用户浏览器并保存在浏览器上的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态、记录用户偏好等。
4.3 Cookie的工作原理
我画了一个板书，大家可以看一下：
- 当用户第一次访问网站时，服务器会在响应的HTTP头中设置 Set-Cookie 字段，用于发送 Cookie到用户的浏览器。
- 浏览器在接收到Cookie后，会将其保存在本地（通常是按照域名进行存储）。
- 在之后的请求中，浏览器会自动在 HTTP 请求头中携带 Cookie 字段，将之前保存的Cookie信息发送给服务器。
4.4 Cookie的分类
- 会话 Cookie（Session Cookie）：在浏览器关闭时失效。
- 持久 Cookie（Persistent Cookie）：带有明确的过期日期或持续时间，可以跨多个浏览器会话存在。
- 如果 cookie 是一个持久性的 cookie，那么它其实就是浏览器相关的，特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容，因为 cookie 文件通常以二进制或 sqlite 格式存储。一般我们查看，直接在浏览器对应的选项中直接查看即可。
谷歌的浏览器现在私密性比较好，看不到cookie了，我们用来做实验的是edge
4.5Cookie的巨大网络安全风险
我画了一个板书，大家可以看一下：
五、session一定程度上解决了cookie带来的网络安全问题
为了一定程度解决安全问题：session 它解决的是"敏感数据暴露"问题，而不是"身份验证拦截"的全部问题。
用户在前端输入 username=zs&passwd=123456 发起请求，服务器进行认证。
服务器端会维护很多的 session，先描述再组织维护起来。里面存放了用户的私密信息，即用户私密信息在服务端保存了。
认证通过后，服务器在 response 中设置 Set-Cookie: session_id = 12345678adsjfksd 返回给客户端，客户端将其保存在本地。
问题又来了：如果黑客获取到了 session id = 12345678adsjfksd，那黑客不就可以以你的身份进行访问了吗？
所以我们需要辅助方案：异常账号检测，ip溯源，地址变更异常。
总结：cookie+session专有名词我们称之为会话管理与会话保持。
------------HTTP：完结------------
好的本期内容就到这里，如果对你有帮助，还不要忘记点赞三联支持。我是此方，我们下期再见。bye!