网络与跨域

系列文章目录

《JavaScript 基础与进阶笔记》(前期偏基础巩固与常见面试点,后续进入闭包、异步、工程化等进阶主题)


文章目录

  • 系列文章目录
  • 前言
  • [一、HTTP 浏览器缓存(与第 24 篇存储的区别)](#一、HTTP 浏览器缓存(与第 24 篇存储的区别))
    • [1.1 强缓存 vs 协商缓存](#1.1 强缓存 vs 协商缓存)
    • [1.2 易混:`Cache-Control` 常见值](#1.2 易混:Cache-Control 常见值)
  • 二、同源策略与跨域
    • [2.1 同源](#2.1 同源)
    • [2.2 CORS(主流方案)](#2.2 CORS(主流方案))
    • [2.3 简单请求 vs 预检(Preflight)](#2.3 简单请求 vs 预检(Preflight))
    • [2.4 开发环境代理](#2.4 开发环境代理)
  • [三、Cookie、Session 与 JWT(与第 24 篇衔接)](#三、Cookie、Session 与 JWT(与第 24 篇衔接))
  • [四、TCP 三次握手(简述)](#四、TCP 三次握手(简述))
  • [五、HTTPS 简述](#五、HTTPS 简述)
  • 六、一次请求的粗略顺序(串讲题)
  • 七、易混淆点归纳
  • 八、思考与练习
  • 总结

前言

第 24 篇讲的是浏览器里 主动存数据 ;本篇进入 网络层 :资源怎么 缓存 、前后端分离怎么 跨域 、登录态 Cookie / Session / JWT 怎么理解,以及简历常问的 TCP 三次握手 与 HTTPS。内容多,按「缓存 → 跨域 → 鉴权 → TCP/HTTPS」串起来;Fetch/XHR/WebSocket 细节放在下一篇。


一、HTTP 浏览器缓存(与第 24 篇存储的区别)

浏览器存储(第 24 篇) HTTP 缓存(本篇)
机制 JS/Cookie 主动读写 浏览器按 响应头 自动缓存 网络资源
典型 Token、主题、IndexedDB JS/CSS/图片、API 响应

1.1 强缓存 vs 协商缓存

复制代码
请求资源
  → 强缓存未过期? ──是──→ 直接用本地副本(不发请求或 200 from cache)
  → 否 → 发请求
  → 协商缓存:带 If-None-Match / If-Modified-Since
  → 未变 → 304 Not Modified(用本地副本,body 为空)
  → 已变 → 200 + 新 body
类型 控制方式 行为
强缓存 Cache-Control: max-age=...、Expires 未过期 不发请求
协商缓存 ETag / Last-Modified 发请求验证,未变则 304
http 复制代码
/* 强缓存 --- 带 hash 的静态资源 */
Cache-Control: public, max-age=31536000, immutable

/* 协商 --- 再次请求 */
If-None-Match: "abc123"
If-Modified-Since: Wed, 10 Apr 2026 00:00:00 GMT

/* 未修改 */
HTTP/1.1 304 Not Modified

1.2 易混:Cache-Control 常见值

值 含义
max-age=3600 强缓存 3600 秒
no-cache 可以存 ,但使用前必须 向服务器验证(常配合 ETag)
no-store 不存任何缓存
immutable 期内内容不变,适合带 contenthash 的文件

工程实践 :app.[hash].js → 长 max-age + immutable ;index.html → no-cache(每次验证,引到新 hash 资源)。


二、同源策略与跨域

2.1 同源

协议 + 域名 + 端口 三者一致才 同源 。

例:https://a.com:443 与 https://a.com/api 同源 ;http://a.com 与 https://a.com 不同源。

浏览器 同源策略 限制:不同源的页面 JS 读不到 对方 DOM、Ajax/Fetch 默认读不到 响应(会报跨域错误)。

2.2 CORS(主流方案)

服务端通过响应头声明 允许哪些源 访问:

http 复制代码
Access-Control-Allow-Origin: https://myapp.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 86400
javascript 复制代码
/* 前端携带 Cookie */
fetch("https://api.example.com/data", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  credentials: "include",
  body: JSON.stringify({ id: 1 }),
});

2.3 简单请求 vs 预检(Preflight)

简单请求 (满足方法 GET/HEAD/POST、Content-Type 为简单类型、无自定义头等)→ 直接发,不先 OPTIONS。

非简单请求 (如 Content-Type: application/json、自定义 Authorization)→ 浏览器先发 OPTIONS 预检,通过后再发真实请求。

javascript 复制代码
/* 预检失败常见原因 */
/* 1. Allow-Origin 未包含当前页源 */
/* 2. Allow-Headers 未包含 Authorization 等自定义头 */
/* 3. Allow-Methods 未包含 PUT/DELETE 等 */

2.4 开发环境代理

Vite/Webpack devServer.proxy 把 /api 转发到后端,浏览器只请求 同源 的 dev 服务器,绕过 浏览器跨域限制(生产仍靠 CORS 或同域部署):

javascript 复制代码
// vite.config.js
export default {
  server: {
    proxy: {
      "/api": { target: "http://localhost:8080", changeOrigin: true },
    },
  },
};

注意 :CORS 是 浏览器 行为;curl、Postman 不受 同源限制。


三、Cookie、Session 与 JWT(与第 24 篇衔接)

方案 存什么 特点
Cookie + Session Cookie 带 sessionId ;状态在 服务端(内存/Redis) 传统 Web;分布式要 Session 共享
JWT Token 自包含 Payload (Base64,非加密) 无状态 API;注销靠短过期 + 黑名单/Refresh Token
复制代码
Cookie + Session:登录 → 服务端建 Session → Set-Cookie(sessionId) → 后续请求自动带 Cookie
JWT:登录 → 服务端签发 JWT → 前端存 Cookie(localStorage) → 请求头 Authorization: Bearer xxx

易混:

  • JWT Payload 勿存密码;可被解码,只是签名校验防篡改
  • HttpOnly Cookie 存 Token 可减 XSS 窃取;须配合 SameSite 防 CSRF
  • 第 24 篇已讲 Cookie 属性;本篇强调 鉴权架构 选型

四、TCP 三次握手(简述)

建立 TCP 连接:SYN → SYN-ACK → ACK ,双方进入 ESTABLISHED 后才发 HTTP。

复制代码
客户端                    服务端
  │── SYN seq=x ──────────→│
  │←─ SYN-ACK seq=y,ack=x+1│
  │── ACK ack=y+1 ────────→│
  │      连接建立           │

为何三次 :确认双方收发能力;避免 旧 SYN 导致错误连接。

与 HTTP :每次新连接(或复用前)需握手;HTTPS 在 TCP 之上还有 TLS 握手 。

断开 是 四次挥手(建立三次、断开四次,别混)。


五、HTTPS 简述

HTTPS = HTTP + TLS ,默认端口 443 ,传输 加密,防窃听与篡改(不防 XSS/CSRF 等应用层问题)。

TLS 握手(概念) :协商算法 → 验证 CA 证书 → 交换会话密钥 → 后续用 对称加密(如 AES)传数据。

对比 HTTP HTTPS
端口 80 443
数据 明文 加密
证书 无 服务端证书链

HSTS :Strict-Transport-Security 强制浏览器后续只用 HTTPS,防降级攻击。


六、一次请求的粗略顺序(串讲题)

复制代码
DNS 解析 → TCP 三次握手 →(HTTPS:TLS 握手)
→ 发 HTTP 请求(带 Cookie、缓存相关头)
→ 强缓存/协商缓存判断 → 服务端处理
→ 响应(Set-Cookie、Cache-Control、CORS 头、body)
→ 浏览器解析渲染 / JS 处理 JSON

与第 23 篇「输入 URL 后发生什么」可对照记忆;本篇补 缓存头、CORS、鉴权 细节。


七、易混淆点归纳

  1. no-cache ≠ 不缓存 ;no-store 才是不存。
  2. 304 无 body,仍用本地缓存副本。
  3. CORS 需服务端配头;前端 alone 无法「解开」跨域。
  4. Allow-Origin: * 与 credentials: include 不能同时用。
  5. JWT Payload 不是加密;Session 状态在服务端,JWT 无状态。
  6. HTTPS 保证传输安全,不代替 输入校验、XSS 防护。

八、思考与练习

1. Cache-Control: no-cache 和 no-store 区别?

解析:no-cache 可缓存但每次要验证;no-store 完全不存储。

2. 带 Authorization 头的 POST 跨域失败,可能原因?

解析:触发 预检 ;服务端未正确返回 Allow-Origin/Allow-Headers/Allow-Methods,或 Origin 不在白名单。

3. 为何带 contenthash 的 JS 适合 max-age=31536000, immutable?

解析:文件名变即新资源;旧文件永不变,可 长期强缓存。

4. Session 和 JWT 各适合什么架构?

解析:Session 传统单体/服务端存态;JWT 分布式无状态 API,注意过期与注销策略。

5. HTTPS 能防 XSS 吗?

解析:不能 ;HTTPS 只保护 传输层 ,XSS 是 页面执行恶意脚本,需 CSP、转义、HttpOnly 等。


总结

  • HTTP 缓存:强缓存(max-age)→ 协商缓存(ETag/304);静态长缓存、HTML 常 no-cache。
  • 跨域 :同源策略;CORS 响应头;非简单请求 OPTIONS 预检 ;开发可用 proxy。
  • 鉴权 :Cookie+Session vs JWT;与第 24 篇 Cookie 属性配合理解。
  • TCP/HTTPS:三次握手建连;HTTPS 加密传输 + 证书。

下一篇讲 网络请求与实时通道:XHR、Fetch、SSE、WebSocket(系列第 26 篇)。

相关推荐
国科安芯4 小时前
一颗当两颗用:ASC4T245S 的“两组独立 2 位 + 控制挂靠 VCCA“账
网络·电平转换·抗辐射·在轨服务
冯胤清4 小时前
《Jev-IDS:网络入侵检测一种系统模型》论文深度分析总结
网络
福兮说5 小时前
设计稿是 #4A7C6F,页面量出来是 #4B7C6F:HEX、HSL、透明度、canvas 来回转的七个坑
前端·javascript·css·canvas
郑州光合科技余经理5 小时前
海外版外卖加盟:总站与分站配送规则怎么分开管
java·开发语言·前端·后端·uni-app·php·ai编程
91刘仁德6 小时前
HTTP协议详解:从URL到HTTP服务器的完整实战
服务器·网络·笔记·网络协议·http
Sarapines Programmer6 小时前
【Wireshark】安装与使用指南
网络·测试工具·wireshark
小呆呆6666 小时前
副业搞起来,小说,漫画,漫剧的成本优化思路
前端·后端·面试
Dovis(誓平步青云)6 小时前
浇水提醒刚弹出又消失,植物状态别只存一个百分比
开发语言·前端·javascript·pdf·ecmascript·电脑
码艺-Alimjan7 小时前
Vben Admin 新增维吾尔语 Vben-Modal的关键坑之一
前端·javascript·vue.js
可乐鸡翅yeah_7 小时前
hls.js 手动自定义 http 请求 loader,修改请求头实战
开发语言·前端·javascript·网络协议·http·ecmascript·m3u8在线