一、HTTP 请求头

HTTP 请求头是客户端与服务器交互的“元数据通道”，它以键值对的形式传递请求的附加信息，每一行是一个键值对，键和值之间使用冒号+空格分隔。这些键值并非随意定义，大部分是RFC 标准文档中规定的行业规范，现已成为 Web 开发中约定俗成的规则。

1. Host 头部：服务器定位的关键标识

Host 是 HTTP 请求头中最核心的字段之一；
比如：Host: gitee.com:(端口号)；端口号默认：HTTP中默认是80 ，HTTPS中默认是443
作用是：告知服务器当前请求访问的目标主机域名/IP+端口

• 核心作用：在虚拟主机场景下，一台服务器可能部署多个网站，服务器通过 Host 字段区分请求对应的站点，将请求转发给正确的服务进程；
• 与 URL 的关系：绝大部分情况下，Host 字段的值与 URL 中的主机信息，两者的信息是一致，但若使用代理服务器时，URL 可能是代理地址，而 Host 字段仍会传递原始目标主机信息，
  即使使用代理，服务器依然可以通过 **Host** 获取真实的目标主机；
• HTTPS 场景的特殊性：HTTPS 协议中，传输时可能会涉及到”加密“（HTTPS），但URL 本身不会被加密，但请求头header和请求body正文会被加密，服务器收到请求之后，也可以做一个最终校验，验证url内容和header中加密的内容是否一致。

2. Content-Length 与请求正文长度

Content-Length 字段用于告知服务器请求正文（body）的字节长度，是服务器判断请求是否完整的重要依据：

• 无body请求：GET 请求通常没有正文，服务器无需依赖 Content-Length，直接读取到空行即可认为请求结束；
• 有body请求：POST、PUT 等包含正文的请求，服务器必须通过 Content-Length 字段，读取指定长度的字节数，才能完整接收请求正文，避免出现数据截断或粘包问题；
• 与 TCP 的关联：HTTP 是基于 TCP 实现的应用层协议（HTTP/1.1 及之前版本），TCP 是面向流的协议，服务器无法自动区分一个连接上的多个 HTTP 请求，Content-Length 就是服务器判断请求边界的关键标识。

3. TCP 协议下的 HTTP 请求处理

对于TCP来说一个链接可以发送多个请求，服务器收到数据时需要区分一下，哪个部分是一个完整的http请求数据
HTTP 请求本质上是将“首行+请求头+空行+正文”的字符串写入 TCP Socket 中，服务器需要通过特定规则区分不同的 HTTP 请求：

1. 无body请求：服务器读取到空行后，即可认为当前请求结束，直接处理；
2. 有body请求：服务器先读取到空行后，解析header中并根据 Content-Length 字段的值，读取对应固定长度的字节数，再处理请求；
3. 连接复用：HTTP/1.1 支持长连接，一个 TCP 连接上可以发送多个 HTTP 请求，服务器通过上述规则依次解析每个请求，实现连接复用，减少 TCP 握手开销。

对比 UDP 协议：UDP 是面向报文的协议，每个 UDP 数据报就是一个完整的应用层数据，调用一次 receive 操作就能获取一个明确的 UDP 数据包，无需额外的边界标识，这也是 HTTP 选择 TCP 作为传输层协议的重要原因之一。

4. Content-Type：响应正文的“说明书”

**Content-Type**** 字段表示请求的body中的数据格式**，也是告知客户端，响应正文的 MIME 类型，客户端会根据这个类型解析和渲染响应内容，是服务器与客户端之间的“格式约定”。

（1）常见的 Content-Type 类型与解析逻辑

Content-Type	数据类型	客户端解析行为
text/html	HTML 文档	浏览器解析 HTML 标签，把标签转换成页面显示，渲染为网页，加载其中的 CSS、JavaScript 等资源
text/css	CSS 样式表	浏览器解析这其中的选择器和属性，并将 CSS 规则应用到页面元素上，实现页面样式
application/javascript	JavaScript 脚本	浏览器解析并执行脚本代码，实现页面的动态交互逻辑
application/json	JSON 数据	浏览器不做任何渲染，直接将数据传递给 JavaScript 代码，由js前端逻辑处理
image/jpeg/image/png	图片数据	浏览器尝试按照图片的二进制格式，解析出来，渲染并显示图片

例如，当服务器返回 Content-Type: text/html; charset=utf-8 时，浏览器会将响应正文当作 HTML 文档解析，并使用 UTF-8 编码显示中文，避免乱码；如果返回 Content-Type: application/json，浏览器会将数据传递给前端的 AJAX 回调函数，由代码处理 JSON 数据。

（2）动态语言与 Content-Type

JSP、PHP 等服务端动态语言，本质上是将动态生成的字符串输出到 HTTP 响应中，服务器会根据配置自动设置 Content-Type，例如 JSP 页面默认返回 text/html，JSON 接口返回 application/json。开发者也可以手动设置 Content-Type，控制客户端的解析行为。

5. User-Agent：客户端的“身份标识”

User-Agent 字段是表示用户使用的设备的浏览器和操作系统的信息等；也就是客户端向服务器传递的设备、浏览器、操作系统信息：
比如格式为：
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36

（1）User-Agent 的组成部分拆解

• Mozilla/5.0：兼容标识，早期浏览器的遗留字段，现代浏览器普遍保留；
• Windows NT 10.0; Win64; x64：操作系统信息，示例中为 Windows 10 64 位系统；
• AppleWebKit/537.36：浏览器内核信息，Chrome 浏览器使用 WebKit 内核；
• Chrome/130.0.0.0：浏览器类型和版本号；
• Safari/537.36：兼容标识，Chrome 基于 WebKit 开发，因此保留了 Safari 的兼容标识。

（2）User-Agent 的核心作用

• 设备与系统识别：服务器通过 User-Agent 判断用户的设备类型（PC/手机/平板）、操作系统、浏览器版本，返回适配的响应内容，例如手机端返回移动端页面，PC 端返回桌面端页面；
• 兼容性适配：针对不同浏览器的兼容性差异，服务器可以根据 User-Agent 返回不同的资源，例如旧版本 IE 浏览器返回兼容的 JavaScript 代码；
• 流量统计与分析：网站的流量分析工具会通过 User-Agent 统计用户的设备分布、浏览器占比，优化产品适配策略；
• 移动端与桌面端区分：手机端浏览器的 User-Agent 会包含 Android、iPhone 等标识，服务器可据此判断设备类型，返回对应的页面版本。

（3）User-Agent 的特殊场景与局限性

• 浏览器版本更新：随着浏览器的更新，User-Agent 中的版本号会不断变化，服务器需要持续适配新的浏览器版本；
• 32 位与 64 位系统：Win64; x64 表示客户端运行在 64 位系统上，早期 32 位系统的 User-Agent 中没有该标识，服务器可据此判断系统位数，返回对应的资源；
• 伪装与修改：User-Agent 可以被客户端修改，因此不能作为唯一的设备识别依据，仅用于非敏感场景的适配。

响应式编程，通过CSS中的媒体查询功能，感知到当前窗口的尺寸(宽度)，通过不同的尺寸，设置不同的央视，一个页面，就可以适配不同的窗口

---

二、Referer 头部

Referer 字段描述了当前页面的来源页面，即用户的当前页面是从哪个页面跳转过来的，是 HTTP 请求头中用于追踪请求来源的关键字段。

1. Referer 的基础概念与示例

• 场景 1：用户直接在浏览器地址栏输入 https://www.sogou.com 访问页面，请求中没有 Referer 字段；
• 场景 2：用户从 https://www.sogou.com 主页点击链接跳转到搜索结果页，搜索结果页的请求中，Referer 字段为 https://www.sogou.com；
• 场景 3：用户从搜索结果页点击广告跳转到广告页面，广告页面的请求中，Referer 字段为搜索结果页的 URL，例如 https://www.sogou.com/web?query=...。

2. Referer 在广告系统中的核心作用：CPC 广告统计

按点击计费（CPC）广告是互联网广告的主流模式，广告主需要统计广告被点击的次数，Referer 字段是实现这一统计的关键：

1. 用户点击广告：用户在搜索结果页点击广告链接，浏览器向广告页面发送请求，请求头中携带搜索结果页的 Referer；
2. 计费服务器记录日志：用户点击广告后，先访问广告平台的“计费服务器”，计费服务器记录请求的 Referer 信息，标记为一次有效点击，再从计费服务器跳转到到广告页面
3. 数据对账：广告主通过计费服务器的日志统计点击次数，广告平台也会统计日志，双方通过 Referer 字段的数据进行对账，确保计费准确。

3. Referer 篡改与广告欺诈风险

Referer 字段可以被客户端修改，早期广告平台存在 Referer 篡改的欺诈行为：

• 部分用户或第三方工具会修改请求的 Referer 字段，伪装成其他来源的点击，骗取广告费用；
• 这种行为会给广告平台造成经济损失，因此广告平台会通过多种方式验证 Referer 的真实性，例如 IP 校验、请求行为分析等。

4. HTTPS 对 Referer 的保护与广告行业的变革

2015 年前后，互联网广告平台开始从 HTTP 切换到 HTTPS，核心原因之一是 Referer 字段在 HTTPS 传输中会被加密保护：

• HTTP 时代，Referer 字段以明文传输，运营商、网络设备可以轻松读取和修改，甚至存在运营商劫持广告流量的行为；
• HTTPS 协议对 HTTP 数据报进行加密传输，Referer 字段无法被中间人篡改，广告平台的计费数据更加安全可靠；
• 随着 HTTPS 的普及，HTTP 网站逐渐退出主流，到现在，互联网上几乎找不到纯 HTTP 的网站，Referer 字段的安全性得到了保障。

三、Cookie 机制：浏览器与服务器的“会话记忆”

Cookie 是浏览器允许网页在本地硬盘存储数据的一种机制，不是让网页代码直接访问文件系统，而是做了一层抽象，而是浏览器的cookie提供了键值对存储机制，因此它解决了 HTTP 协议无状态的问题，让服务器可以识别用户身份、维持会话状态，是 Web 开发中用户认证的核心技术。

1. Cookie 的本质与存储机制

• 无状态 HTTP 的痛点：HTTP 协议本身是无状态的，服务器无法区分两次请求是否来自同一个用户，每次请求都是独立的，无法记录用户的操作状态；
• Cookie 的定义：Cookie 是浏览器为网页提供的“键值对存储机制”，网页无法直接访问用户的文件系统，而是通过浏览器提供的 Cookie API，在本地存储少量键值对数据；
• Cookie 的传输流程：浏览器存储 Cookie 后，后续向服务器发送请求时，会自动将 Cookie 键值对添加到 Cookie 请求头中，传递给服务器，服务器通过 Cookie 识别用户。

2. Cookie 的存储结构与浏览器开发者工具

Cookie 按照维度进行组织，每个 Cookie 包含多个属性：

• Name：Cookie 的键名，例如 sessionid、ABTEST；
• Value：Cookie 的值，由程序员自定义，通常是字符串格式；
• Domain：Cookie 生效的域名，例如 .sogou.com，表示该 Cookie 在 sogou.com 及其子域名下都有效；
• Path：Cookie 生效的路径，例如 /，表示该 Cookie 在整个域名下都有效；
• Expires/Max-Age：Cookie 的过期时间，过期后浏览器会自动删除该 Cookie；
• HttpOnly：标记 Cookie 是否只能通过 HTTP 请求传递，无法通过 JavaScript 访问，防止 XSS 攻击；
• Secure：标记 Cookie 是否只能通过 HTTPS 协议传输，增强安全性。

在浏览器开发者工具的 Application 面板中，可以查看当前页面的所有 Cookie，清晰地看到每个 Cookie 的键值对和属性，例如搜狗搜索的 Cookie 中，包含 ABTEST、SNUID、IPLOC、cuid 等多个键值对，这些都是程序员根据业务需求自定义的。

HTTP部分	处理方式	目标
url 的 query string	程序员自定义	结合实际情况，基于 HTTP 实现一些个性化的功能需求
header 部分也是键值对	标准规定	结合实际情况，基于 HTTP 实现一些个性化的功能需求
header 中 cookie 里存的数据还是键值对	程序员自定义	结合实际情况，基于 HTTP 实现一些个性化的功能需求
body 是 json 格式，仍然是键值对	程序员自定义	结合实际情况，基于 HTTP 实现一些个性化的功能需求

3. Cookie 的来源与业务场景

Cookie最终还是发回给服务器；并且也是从服务器发送（后端决定）

Cookie 中的数据分为两类：

• 程序员自定义的业务数据：例如搜索平台的用户标识、广告平台的会话标识，用于业务逻辑处理；
• 通用业务数据：最典型的是用户登录认证场景，通过 Cookie 实现会话维持。

（1）登录认证的完整流程：Cookie 与 Session 的联动

session对象也是可以存储用户自定义的数据的表示当前这一次会话的详细信息；所谓会话就是客户端和服务端进行一次连接和访问

用户登录认证是 Cookie 最典型的应用场景，流程如下：

1. 用户提交登录请求：用户在登录页面输入用户名和密码，向服务器发送登录请求；
2. 服务器验证身份：服务器查询数据库，验证用户名和密码是否匹配；
3. 生成会话标识：验证通过后，服务器生成一个随机字符串作为 sessionid，创建对应的 Session 对象，存储用户的登录状态信息；
4. 存储 Session 数据：服务器将 sessionid 和 Session 对象作为键值对，存储在内存的哈希表中；
5. 返回 Cookie：服务器通过 Set-Cookie 响应头，将 sessionid 发送给浏览器，浏览器存储该 Cookie；
6. 后续请求自动携带 Cookie：用户后续向服务器发送请求时，浏览器会自动在 Cookie 请求头中携带 sessionid；
7. 服务器识别用户：服务器通过 sessionid 查找对应的 Session 对象，获取用户的登录状态，无需用户重复登录。

（2）Set-Cookie 响应头的格式与示例

服务器通过 Set-Cookie 响应头向浏览器设置 Cookie，格式为：
Set-Cookie: ABTEST=0|1732418297|v17; expires=Tue, 24-Dec-24 03:18:17 GMT; path=/; domain=.sogou.com

其中各属性的作用：

• ABTEST=0|1732418297|v17：Cookie 的键值对；
• expires=Tue, 24-Dec-24 03:18:17 GMT：Cookie 的过期时间，过期后浏览器自动删除；
• path=/：Cookie 生效的路径，根路径下所有请求都携带该 Cookie；
• domain=.sogou.com：Cookie 生效的域名，sogou.com 及其子域名下的请求都携带该 Cookie。

4. Cookie 的过期机制与安全策略

• 过期时间设置：服务器在 Set-Cookie 中可以设置 Cookie 的过期时间，分为两种类型：
  • 会话 Cookie：未设置过期时间，浏览器关闭后自动删除，常用于临时会话；
  • 持久 Cookie：设置了过期时间，存储在本地硬盘中，直到过期时间才会删除，常用于“记住我”功能；
• 过期策略的业务应用：
  • 高安全性场景（如银行、办公系统）：Cookie 过期时间短，用户一段时间不操作就会自动登出，防止他人冒用；
  • 低安全性场景（如视频网站、娱乐平台）：Cookie 过期时间长，用户可以长期保持登录状态，提升使用体验；
• 公共电脑的 Cookie 风险：在网吧、图书馆等公共电脑上，用户登录后 Cookie 会存储在本地，下一个用户可以通过 Cookie 登录该账号，因此公共电脑上的浏览器通常会在关机后自动还原系统，清除所有 Cookie。

四、Session 机制：服务器端的“会话记忆”

Session 是服务器端存储用户会话信息的机制，它与 Cookie 配合使用，解决了 HTTP 无状态的问题，让服务器可以记录用户的会话状态。

1. Session 的本质与概念类比

Session 描述了客户端和服务器之间的一次交互关系，就像用户去医院就诊的一次流程：

1. 挂号：用户在医院挂号，办理就诊卡，就诊卡上存储唯一的会话 ID；
2. 就诊流程：用户到儿科门诊、检验科、影像科就诊时，刷就诊卡，医生的电脑上会显示该患者的所有信息；
3. 信息传递：检验科的医生开具检查单，检查结果会直接关联到用户的就诊卡，回到儿科门诊时，医生可以直接查看检查结果；
4. 会话结束：用户离开医院，本次就诊会话结束，就诊卡的会话信息失效。

在 Web 开发中，客户端就像就诊的用户，服务器就像医院，sessionid 就像就诊卡，Session 对象就像用户的就诊信息，服务器通过 sessionid 识别用户，关联用户的会话数据。

2. Session 与 Cookie 的区别与联动

特性	Cookie	Session
存储位置	客户端浏览器	服务器端
存储内容	少量键值对数据，通常是字符串	任意类型的对象，可存储用户的详细会话信息
安全性	存储在客户端，可能被篡改、窃取	存储在服务器端，安全性更高
生命周期	可设置过期时间，会话 Cookie 随浏览器关闭失效	服务器可设置会话超时时间，超时后 Session 对象被销毁
依赖关系	浏览器自动携带，服务器无需额外维护	依赖 Cookie 传递 sessionid，服务器通过 sessionid 查找 Session 对象

Cookie 和 Session 是互补的机制：Cookie 负责在客户端存储会话标识，Session 负责在服务器端存储会话数据，二者配合实现了用户会话的维持。

3. Session 的业务应用场景

• 用户登录状态维持：这是 Session 最核心的应用场景，服务器通过 Session 存储用户的登录状态、用户信息，后续请求通过 Cookie 中的 sessionid 识别用户；
• 购物车功能：电商网站中，用户未登录时，购物车数据存储在 Session 中，登录后可将 Session 中的购物车数据同步到用户账号；
• 表单提交防重复：服务器在 Session 中存储表单的唯一标识，用户提交表单时验证该标识，防止重复提交；
• 权限控制：服务器通过 Session 存储用户的权限信息，验证用户是否有权限访问特定资源。

4. Session 的超时与销毁机制

• 超时设置：服务器会设置 Session 的超时时间，例如 30 分钟，用户 30 分钟内没有任何请求，服务器会销毁对应的 Session 对象；
• 超时的业务影响：Session 超时后，用户需要重新登录，获取新的 sessionid 和 Session 对象；
• 手动销毁：用户主动登出时，服务器会销毁对应的 Session 对象，同时浏览器会删除存储的 sessionid Cookie；

五、总结

HTTP 请求头、Cookie、Referer、Session 是 Web 开发中实现客户端与服务器交互的核心机制：

• 请求头是客户端与服务器传递元数据的通道，Host、Content-Type、User-Agent 等字段是请求解析和响应处理的关键；
• Referer 字段实现了请求来源的追踪，是广告计费、防盗链等场景的核心技术；
• Cookie 解决了 HTTP 无状态的问题，通过键值对存储在客户端，实现会话标识的传递；
• Session 存储在服务器端，与 Cookie 配合实现用户会话的维持，是登录认证、权限控制等业务的基础。

理解这些机制的底层逻辑和应用场景，是后端开发、前端开发、App 开发的必备知识，希望大家收获新的知识！