HTTP/HTTPS ②-Cookie || Session || HTTP报头

这里是Themberfue

上篇文章介绍了HTTP报头的首行信息

本篇我们将更进一步讲解HTTP报头键值对的含义~~~

❤️❤️❤️❤️

报头Header

✨再上一篇的学习中，我们了解了HTTP的报头主要是通过键值对的结构存储和表达信息的；我们已经了解了首行的HTTP方法和URL；那么我们继续深入一些其他的键值对含义吧

Host

✨host在英文中有 "主人" "主机" 的意思，所以在HTTP协议中，host的值所存储的就是目标服务器的主机名或IP地址以及可选的端口号。例如：www.bilibili.com[:8086]
它是HTTP/1.1中强制要求的字段，每个HTTP/1.1请求必须包含Host字段，否则服务器会返回400 Bad Request。
host的值的内容URL的主题内容大差不差，不过，在传输URL时是不会对URL加密的，被加密的一般是Header和Body的内容，所以服务器在收到请求后，也可以做一个检验，检验host的内容和URL的内容是否发生改变。

作用

1. 支持虚拟主机（Virtual Hosting）：

多个网站可以托管在同一台服务器上，使用相同的IP地址。
Host字段的值指定客户端希望访问的具体网站。例如：
请求A
GET /index.html HTTP/1.1
Host: www.example1.com请求B
GET /index.html HTTP/1.1
Host: www.example2.com
服务器通过Host字段区分请求，返回对应的网站内容。

2. 支持非标准端口：

Host字段可以指定端口号，使服务器知道客户端访问的具体服务。例如：
GET /api/data HTTP/1.1
Host: www.example.com:8080
这里的:8080明确了目标服务运行在8080端口，而不是默认的80端口。

3. 增强请求路由能力：

在负载均衡或反向代理场景中，Host字段帮助服务器路由请求到对应的后端服务器。

Content-Length

✨中文直接翻译过来就是：内容长度，Content-Length指代的就是HTTP协议中body正文的内容长度，单位是字节。
我们知道，通过HTTP构造的数据包只是在应用层上的，我们还需经过传输层、网络层.....，通过Content-Length，传输层就可以直到这个HTTP数据包的正文内容有多少，读到哪里，知道消息体的预期长度。
若是没有Content-Length，这说明这个请求或者响应就没有body正文，一般读到空行就表示该数据包读完了，若有Content-Length，就按照Content-Length所给定的值来读取body正文的内容。
前面编写TCP代码时，我们使用 hasNext() 方法，也就是在暗指读到空行就结束读取。

作用

1. 消息完整性校验：

客户端或服务器通过Content-Length字段知道消息体的预期长度。
如果接收到的数据长度与Content-Length字段的值不符，则认为数据可能丢失或损坏。

2. 分块数据解析：

在持久连接中，服务器需要知道消息体的确切长度，以便从流中提取完整的消息。

3. 提高通信效率：

通过提前知道消息体长度，可以优化内存分配和处理逻辑。

Content-Type

✨在当今的互联网时代，网络上的数据非常之多，数据类型也非常之多：纯文本、超文本、富文本、图片、视频......
所以，在传输数据时，也需要知道该数据是哪个类型的；那么，Content-Type就充当此角色，Content-Type表示请求的body的数据格式，也提示了接受方如何解析body中的数据。
Content-Type用于指示消息体中数据的媒体类型（MIME类型）；它告诉接收方（浏览器或服务器），如何解析和处理消息体的数据内容。
Content-Type负责标明数据的类型和格式；它在请求和响应中都有广泛的应用，确保了数据的正确传输和解析。

携带的数据类型

✨HTTP可携带的数据类型还是比较全面、比较多的，例如：

HTML：text/html => 浏览器便会解析其中的标签，把标签转换为界面显示
CSS：text/css => 浏览器便会解析其中的选择器以及属性，将这些样式应用到指定的内容上
JS：application/javascript => 浏览器便会通过JS引擎执行这些JS代码的逻辑
JSON：application/json => 浏览器通常不会做处理，由程序员来对这些JSON数据进行操作
图片：image/png、image/jpg => 浏览器按照图片的二进制格式，解析出来并显示在页面上
文本类型（text）：用于传输纯文本数据。
Content-Type: text/plain; charset=UTF-8
Content-Type: text/html; charset=UTF-8
图片类型（image）：用于传输图片数据。
Content-Type: image/jpeg
Content-Type: image/png
应用类型（application）：用于传输二进制数据或特殊格式的数据。
Content-Type: application/json
Content-Type: application/xml
Content-Type: application/pdf
Content-Type: application/octet-stream
多媒体类型（audio、video）：用于传输音频或视频文件。
Content-Type: audio/mpeg
Content-Type: video/mp4
多部分类型（multipart）：用于传输多部分数据（如文件上传）。
Content-Type: multipart/form-data; boundary=------WebKitFormBoundary
携带的格式

✨Content-Type: <主类型>/<子类型>; <参数>

主类型：数据的大类别，例如text、image、application等。
子类型：具体的数据格式，例如html、jpeg、json等。
参数（可选）：附加信息，常见的是字符编码（如charset=UTF-8）。
Content-Type: text/html; charset=UTF-8
作用

1. 明确数据格式：

发送方通过Content-Type告知接收方消息体的数据格式。
接收方根据Content-Type正确解析消息体，避免误解。

2. 跨平台兼容：

不同的系统、语言或平台都可以通过Content-Type理解数据格式，实现兼容性。

3. 提高效率：

客户端或服务器可以快速根据Content-Type选择合适的工具或库处理数据，而不需要额外推断。

User-Agent

✨在2025年的今天，有各式各样的设备都可以访问网页，这些设备的性能不同，屏幕大小不同；为了让用户在不同设备上都有一个良好的浏览体验，提前知道用户访问的设备信息，从而返回不同的响应结果，这是非常重要的。
所以，User-Agent便充当了这么一个角色；User-Agent翻译过来就是用户代理，其描述了用户访问网页时所使用的设备信息。
User-Agent用于标识客户端的信息，它告诉服务器发起请求的客户端是什么类型的设备、使用什么操作系统、运行什么软件（如浏览器）等。

常见结构

✨典型的User-Agent字符串由多个部分组成，以空格分隔，主要包括：

产品名称（软件名、浏览器名等）。
版本号。
操作系统信息。
其他组件。
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36
Mozilla/5.0：

起源于早期的Netscape浏览器，后来成为一种惯例。
表示兼容Mozilla标准。
Firefox（火狐浏览器）也是之一

(Windows NT 10.0; Win64; x64)：

操作系统信息：
Windows NT 10.0：Windows 10。
Win64：64位版本。
x64：基于x64架构。

AppleWebKit/537.36：

使用的渲染引擎（WebKit）及其版本。
浏览器内核

Chrome/96.0.4664.93：

浏览器名称和版本。

Safari/537.36：

表明浏览器兼容Safari。
Safari是苹果公司开发的浏览器，用于苹果系统上

常见示例

1. 桌面浏览器

Chrome：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Safari/537.36
FireFox：
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
2. 移动浏览器

Android：
Mozilla/5.0 (Linux; Android 11; Pixel 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.93 Mobile Safari/537.36
iPhone：
Mozilla/5.0 (iPhone; CPU iPhone OS 14_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Mobile/15E148 Safari/604.1
3. 搜索引擎爬虫

Googlebot：
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Bingbot：
Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
作用

1. 适配响应内容：

服务器可以根据客户端的User-Agent信息，返回适合该设备的内容。
根据不同的设备返回呈现不同的样式，不同的排版，这便是响应式编程。
例如，给移动设备返回简化页面，给桌面设备返回完整版页面。

2. 统计与分析：

网站通过记录User-Agent分析用户使用的设备、浏览器、操作系统等，优化产品策略。

3. 调试和诊断：

开发者通过User-Agent信息了解客户端环境，定位问题。

4. 安全和反爬虫：

服务器可以根据User-Agent区分正常用户和爬虫，也可以设置特定策略限制某些类型的访问。

KHTML, like Gecko

✨这个标识感兴趣的了解即可，不感兴趣可以直接跳过了。
KHTML, like Gecko用来表明浏览器的渲染引擎及其兼容性；
KHTML 是一个开源的浏览器渲染引擎，最初由 KDE 项目为 Konqueror 浏览器开发。解析 HTML 和 CSS，呈现网页内容；处理 JavaScript 的执行。轻量级：设计目标是简洁和高效；灵活性强：为后来的浏览器渲染引擎（如 WebKit）奠定了基础。
Gecko 是 Mozilla 开发的浏览器渲染引擎，用于 Firefox 和其他基于 Mozilla 的浏览器。强大的标准兼容性；可扩展性高，支持多种插件和扩展功能；更新迭代快，适应最新的 Web 技术。
like Gecko 表明当前浏览器的渲染行为与 Gecko 引擎兼容，尽管它可能并非真正基于 Gecko。这是为了在服务器端解析 User-Agent 时，提高浏览器的兼容性。一些网站或服务会根据 User-Agent 优化内容。如果声明与 Gecko 兼容，则可以避免某些不必要的功能限制。
由于苹果公司在 KHTML 的基础上开发了 WebKit，用于 Safari 浏览器。WebKit 最终成为许多现代浏览器的基础（如 Chrome 的 Blink 引擎）。为了兼容旧版的服务器解析逻辑，WebKit 在 User-Agent 中保留了 KHTML 的标识。like Gecko 则是为了表明 WebKit 的渲染效果类似于 Gecko，从而避免被视为不兼容的浏览器。
KHTML, like Gecko 是一种历史遗留标识，最初用于声明浏览器兼容性，避免因 User-Agent 解析引起的兼容性问题。它已经成为现代浏览器中 User-Agent 的惯用格式，即使没有实际功能意义，但可以提高服务器对浏览器的兼容性处理。

Referer

✨我们知道，当今的网页已经不仅仅局限于一个网页（虽然也有SPA）；在某些情况下，我们需要知道当前网页是从哪个网页跳转来的；所以，Referer 便充当了这么个角色。
Referer翻译过来就是 "来路"，其用于标识当前请求的来源页面。它的主要作用是告诉服务器，该请求是从哪个 URL 链接点击跳转过来的。

作用

1. 统计与分析

服务器可以通过 Referer 头字段了解流量来源，例如某个用户是从搜索引擎、广告链接还是其他页面访问了当前页面。
便于网站管理员优化流量入口。

2. 追踪导航路径

Referer 记录了用户从哪个页面跳转而来，方便了解用户的访问路径。

3. 防盗链

某些网站通过 Referer 检查请求来源，防止其他网站未经授权直接引用其资源（如图片、视频等）。

4. 广告投放效果评估

广告主可以通过 Referer 数据统计广告链接的点击率和效果。

Referer对广告系统的作用

✨广告系统的计费方式很多，其中一个比较有名的就是 CPC（点击计费），也就是按用户的点击量来计费，例如点击一次就5分钱。
所以需要统计某个投放的广告点击了多少次；比如按一个月来算：一个月后，需要浏览器开发商和广告主都统计点击量，然后核对数据是否一致，随后由广告主支付相应的广告费用。
浏览器开发商统计点击量就比较方便了，只需要在点击时先访问该开发商的 "计费服务器" ，再访问该广告；计费服务器通过记录日志从而生成相应的数据。
而广告主就比较麻烦了，因为广告主可能向不止一家浏览器开发商投放广告，所以就需要知道该广告是从哪个浏览器点击来的，那么通过 Referer 就可以很快的知道是从哪个浏览器点击来的，从而对各个浏览器的点击量分别统计。
但由于 HTTP协议最初是明文传输的，所以再传输时，Referer 可能会被别人篡改，如果被篡改了，统计的数据就变少了，这造成的损失就大了啊。运营商（ISP）劫持就是当时比较常见的，所有互联网服务都要经过运营商的设备，所以运营商就有机会对这里面的数据进行修改，运营商也要恰钱的啊，运营商当然也会投放广告，运营商便更改成了运营商的 Referer，从而运营商这边的点击量就 "多" 了。
当时的法律明文对这些的判处还是比较模糊的，为了解决这个问题，国内的大厂就开始纷纷使用 HTTPS协议，HTTPS协议可以对 Referer 进行加密，这样运营商就不能轻易更改了，随后愈来愈多的互联网厂商都纷纷跟进使用 HTTPS协议。在2025的今天，想要看到使用 HTTP协议的网站是很难的。

Referer 的改进：Referrer Policy

✨为了解决 Referer 的隐私问题，现代浏览器引入了 Referrer Policy，它允许开发者控制 Referer 信息的发送方式。常见的 Referrer Policy 选项：

no-referrer

不发送任何 Referer 信息。

no-referrer-when-downgrade

仅在跨协议从 HTTPS 跳转到 HTTP 时不发送 Referer（默认行为）。

origin

只发送来源的主域名，例如 https://example.com。

strict-origin-when-cross-origin

同源请求发送完整 Referer，跨域请求只发送来源的主域名。

origin-when-cross-origin

同源请求发送完整 URL，跨域请求只发送主域名。

Cookie

✨Cookie 翻译就是 "曲奇" (bushi，Cookie 是一种存储在用户浏览器中的小型数据文件，用于在客户端和服务器之间共享状态信息。它由服务器通过 HTTP 响应发送，并由浏览器在后续请求中回传给服务器。
浏览器在展示页面的过程中，是通过 JS 代码来执行一些操作，当时 JS 无法直接访问你电脑的文件系统，这是浏览器给 JS 做的一个限制，这么做是为了防止某些不法分子直接读取你的文件系统然后做些不可描述的事情。
因此浏览器引入了 Cookie机制，Cookie就是浏览器允许网页在本地硬盘存储数据的一种机制；并非通过 JS 代码直接访问文件系统，而是做了一层抽象，浏览器的 Cookie提供了键值对存储机制。

作用

1. 会话管理

维持用户登录状态，例如购物车内容、用户偏好等。

2. 个性化设置

保存用户的语言偏好、主题颜色等设置，以便在下次访问时自动应用。

3. 跟踪与分析

用于统计用户行为数据，例如记录访问次数、来源等。

✨Cookie可以通过浏览器自带的开发者工具查看，我们以 bilibili 的Cookie 为例：
✨这Cookie里的键值对是什么意思？我们当然不知道，因为这是程序员自定义的，只有写这些代码才能看懂这是些是什么含义。

Cookie的结构

✨虽然 Cookie 的内容是由程序员定义的，但其结构和格式是由 HTTP 协议统一规定的，以保证不同的浏览器和服务器可以正确解析和传输数据。程序员可以在键值和属性的设置上自由发挥，但必须遵循协议规范来实现一致性和可操作性。
Set-Cookie: key=value; Attribute1=Value1; Attribute2=Value2Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; Max-Age=3600
session_id=abc123：键值对，表示存储的具体数据。
Path=/：Cookie 作用范围，指定在该路径下的请求会附带该 Cookie。
HttpOnly：限制 Cookie 只能通过 HTTP 请求访问，防止 JavaScript 操作，增强安全性。
Secure：要求仅在 HTTPS 连接中发送。
Max-Age=3600：设置 Cookie 的存活时间（秒）。
Domain：指定该 Cookie 可用的域名。
.........

Cookie 的生命周期

会话 Cookie

默认情况下，Cookie 是临时的，仅在浏览器会话期间有效（关闭浏览器即删除）。

持久化 Cookie

使用 Max-Age 或 Expires 属性设置过期时间，使其在浏览器关闭后仍有效。

Cookie 的特性与限制

大小限制

每个 Cookie 的大小通常限制在 4KB。

数量限制

每个域名下的 Cookie 数量有限（通常为 20-50 个）。

同源限制

Cookie 只能在设置它的域及其子域中使用。

Cookie 的安全性问题

劫持风险

未加密的 Cookie 在传输过程中容易被拦截（可通过 Secure 属性缓解）。

跨站脚本攻击 (XSS)

恶意脚本可能窃取 Cookie（可通过 HttpOnly 属性避免）。

跨站请求伪造 (CSRF)

恶意网站可能利用用户的 Cookie 发起伪造请求（可结合 Token 验证抵御）。

Cookie 与现代替代方案

✨随着隐私需求的提升和浏览器技术的发展，Cookie 在某些场景中正逐渐被其他技术取代：

LocalStorage/SessionStorage

更适合存储客户端数据，不会自动发送到服务器。

Token-Based Authentication

使用 JWT（JSON Web Token）替代 Cookie 来存储用户认证信息。

SameSite 属性

限制跨站点请求时发送 Cookie，有效缓解 CSRF 攻击。

Session

✨Session 翻译过来就是 "会话"，是一种在服务器端保存用户状态信息的机制，用于跟踪和管理用户的会话。它通过一种唯一标识符（Session ID）将用户的请求与服务器上的状态关联起来，通常与 Cookie 一起使用。
Session可以用来在用户与服务器之间维持状态信息，它解决了 HTTP 协议本身是无状态协议的问题。在 HTTP 的通信中，服务器无法直接知道两次请求是否来自同一个用户，而 Session 提供了这样一个机制，可以让服务器“记住”用户的状态。
简单来说就是保存用户的一些信息，但是在服务器端存着，因为这些数据通常较为隐私。而 Cookie 通常保存在客户端。
Cookie 中的 Session-id 通常是会过期的，这由开发人员自己设定，根据不同的业务场景设置不同的过期时间。
在某些视频网站、论坛网站等用户信息不敏感的场景下，例如：B站、抖音、贴吧、知乎等平台，其过期时间通常比较长。
在某些银行App、网银等用户信息敏感的场景下，其过期时间通常非常短，短到你关闭了App就可能需要重新登录。

Session 的基本原理

✨在绝大多数网站都有登录和用户认证功能，而这里便是 Session 的一个经典使用场景

1. 客户端发起请求

用户首次访问服务器时，服务器会为该用户创建一个唯一的 Session 对象。

2. 生成 Session ID

服务器生成一个唯一的 Session ID，用于标识用户会话，并将该 ID 返回给客户端。

3. 客户端存储 Session ID

Session ID 通常通过 Cookie 存储在客户端，或直接附加在 URL 参数中。

4. 服务器存储会话信息

服务器将用户的状态信息（如登录状态、购物车内容等）存储在服务器的内存、数据库或文件系统中。

5. 后续请求

每次客户端发送请求时，会附带 Session ID，服务器通过 Session ID 查找到对应的会话信息。

特点

存储在服务器端：用户的具体数据存储在服务器中，比 Cookie 更加安全。
支持大规模信息：Session 可以存储复杂、较大规模的数据结构，而 Cookie 的容量较小（约 4KB）。

短期存储：Session 通常与用户的会话周期一致（用户关闭浏览器或会话超时后失效）。

生命周期

创建：当用户第一次访问应用时，服务器创建 Session。

访问：每次用户请求时，服务器会根据 Session ID 获取用户的会话信息。

销毁：Session 可以通过以下方式销毁：

        主动调用销毁方法（如用户注销）。

        达到超时时间（通常默认 30 分钟）。

        服务器重启或存储 Session 的媒介被清空。

优点

数据存储在服务器，安全性更高。
支持更复杂、更大规模的数据存储。
易于扩展和管理。

缺点

会增加服务器的存储压力，尤其是高并发场景下。
如果依赖 Cookie 保存 Session ID，可能受到 Cookie 限制。
在分布式系统中需要额外机制（如共享存储或会话粘性）保持一致性。

实际场景中的应用

用户登录：用户登录成功后，服务器生成 Session，保存用户的登录状态及相关信息。
电商购物车：用户未登录时的购物车信息可以保存在 Session 中，登录后与数据库中的购物车合并。
跨页面的数据传递：当用户在多步操作（如填写表单）中需要保持上下文状态时，可以将数据存储在 Session 中。

✨这边还有一个小例子，可以更好的说明 Session 的重要性：

去医院看病通常需要挂号，挂完号之后就给你办理个就诊卡，办理就诊卡通常需要你填写一些你的个人信息，而医生将这些个人信息存入到电脑；这些个人信息就好比 Session，而就诊卡就好比 Session-id。
比方说你去看儿科，刷一下就诊卡，医生电脑上就显示出了这个患者的全部信息，随后医生作了一些检查，叫你去检验科，刚刚做过的检查存入到Session中。
你来到了检验科，重复上诉操作，就叫你去影像科拍片
你来到了影像科，重复上诉操作，就叫回到儿科
你回到了儿科，再刷一遍就诊卡，就显示出了你刚刚就诊的一些情况，医生根据这些情况做进一步判断你的病情。

在这个过程中，都是通过就诊卡 Sesson-id 来确认你的个人信息的，就不需要额外更多的信息了，你的隐私信息都在医院那边"安全"存储着。