OSI七层模型

• 你想发送"今天天气真好"给朋友

• 问题：如何让计算机理解你的意图？

• 解决：需要微信这样的应用程序，定义消息格式、用户界面

• 你的中文消息需要转换为计算机能理解的格式

• 问题：如何统一数据表示？不同系统如何理解彼此的数据？

• 解决：UTF-8编码、JSON格式、可能的加密

• 你和朋友需要建立一个"对话"

• 问题：如何管理这次通信？如何知道对方在线？如何处理断线重连？

• 解决：建立会话连接、维护通信状态

• 消息要完整无误地送达朋友

• 问题：如何确保数据不丢失、不重复、按顺序到达？

• 解决：TCP协议提供可靠传输，端口号区分不同应用

• 消息要找到朋友的手机

• 问题：全世界这么多设备，怎么找到目标设备？

• 解决：IP地址标识设备，路由器选择传输路径

• 消息在每一跳传输中都要可靠

• 问题：如何在直接相连的设备间可靠传输？

• 解决：以太网帧、WiFi帧，MAC地址标识直接邻居

• 最终要通过某种物理方式传输

• 问题：如何把数字信号转换为物理信号？

• 解决：电信号、光信号、无线电波

1. 每层解决一个核心问题：从"用户想要什么"到"物理世界如何实现"

2. 自然的依赖关系：上层依赖下层提供的服务

3. 问题的必然性：这些问题是任何网络通信都必须解决的

应用层（Application Layer）

• 核心问题：人类如何与计算机沟通？如何表达"我想发消息"这个意图？

• 根本需求：把人类的想法转换为计算机能理解的指令

1. 用户界面：提供输入框、发送按钮

2. 协议定义：定义消息格式，比如JSON：

3. 业务逻辑：处理好友关系、消息状态、离线存储等

传输层（Transport Layer）

• 核心问题：两个程序如何可靠地交换数据？

• 根本挑战：网络是不可靠的（会丢包、重复、乱序），但应用需要可靠性

1. 建立连接：你的微信与朋友的微信建立TCP连接

2. 端口区分：你的手机可能同时运行微信、QQ、浏览器，如何区分？
• 微信使用端口8080
• QQ使用端口8000
• 浏览器使用端口443

3. 可靠传输：
• 发送：微信→TCP→"今天天气真好"（序号001）
• 接收确认：朋友的TCP→"收到序号001"→你的TCP
• 如果没收到确认，就重发

网络层（Internet Layer）

• 核心问题：全世界有几十亿台设备，如何找到目标设备？

• 根本挑战：网络是一个巨大的迷宫，需要寻址和路由

1. 全球寻址：
• 你的手机IP：192.168.1.100
• 朋友的手机IP：203.208.60.1
• 就像门牌号码一样，全球唯一

2. 路由选择：数据包要经过多个路由器

3. 包头信息：

网络接口层（Network Interface Layer）

• 核心问题：数字信号如何在物理世界中传输？

• 根本挑战：计算机内部是0和1，但物理世界需要电信号、光信号、无线电波

1. 物理传输方式选择：
• 如果用WiFi：转换为2.4GHz无线电波
• 如果用4G：转换为特定频段的无线信号
• 如果用网线：转换为电信号脉冲

2. 局域网寻址：
• MAC地址：每个网卡的物理地址
• 你的手机WiFi：AA:BB:CC:DD:EE:FF
• 路由器：11:22:33:44:55:66

3. 帧封装：

4. 信号转换：
• 数字"1"：高电压或特定频率
• 数字"0"：低电压或另一个频率

整体流程总结：

1. 应用层：用户意图 → 结构化消息

2. 传输层：消息 → 可靠的数据段

3. 网络层：数据段 → 全球可路由的包

4. 网络接口层：包 → 物理信号

1. 网络接口层：物理信号 → 数据包

2. 网络层：检查IP地址，确认是给我的

3. 传输层：重组数据，确认完整性

4. 应用层：显示消息给朋友

1. 应用层 (Application Layer) - “包裹里的具体内容和寄送服务的类型”

• 核心任务： 处理特定应用程序的通信需求，定义我们能“看到”和“使用”的网络服务规则。

• 通俗解释： 这一层决定了你要用网络来干什么。是想发一封电子邮件？还是想看一个网页？或者是进行文件传输？或者解析一个域名（比如把 www.google.com 变成 IP 地址）？不同的应用场景，就有不同的规则（协议）。

• 包裹比喻：
• 你想寄的是一封信件（对应邮件协议 SMTP/POP3/IMAP）。
• 你想请求一本商品目录册（对应网页协议 HTTP/HTTPS）。
• 你想寄送一个大箱子里的文件（对应文件传输协议 FTP）。
• 你想查询“小明家”的具体地址在哪条街（对应域名解析协议 DNS）。

• 主要协议举例： HTTP (网页), HTTPS (安全网页), SMTP (发邮件), POP3/IMAP (收邮件), FTP (文件传输), DNS (域名解析), Telnet (远程登录) 等。

• 数据单位： 通常称为 消息 (Message) 或直接就是 数据 (Data)。

Http

• 名字： 超文本传输协议 (Hypertext Transfer Protocol)。

• 本质： 互联网上应用最广泛的一种网络协议（就是一套通信规则）。

• 作用： 它是客户端 (Client)（比如你的浏览器）和服务器 (Server)（比如存放网站内容的服务器）之间进行请求和响应的标准。主要用于从万维网服务器传输超文本标记语言（HTML）页面、图片、文件等资源。

• 简单说： HTTP 就是浏览器和网站服务器之间沟通的“普通话”。

1. 客户端发起请求 (Client sends Request)： 你的浏览器想看一个网页或图片，就会按照 HTTP 协议的格式，打包一个“请求”消息发给服务器。

2. 服务器处理请求 (Server processes Request)： 网站服务器收到这个请求，理解你想干什么（比如想要哪个页面的数据）。

3. 服务器返回响应 (Server sends Response)： 服务器处理完后，同样按照 HTTP 协议的格式，打包一个“响应”消息发回给浏览器。这个响应里可能包含请求的资源（HTML 代码、图片数据等），或者一个说明（比如“你找的东西不存在”）。

1. 客户端-服务器 (Client-Server): 总是由客户端主动发起请求，服务器被动响应。服务器一般不会主动给客户端发消息。

2. 无状态 (Stateless): 这是 HTTP 的一个核心特点！服务器默认不记录任何关于客户端上一次请求的信息。每个请求都是独立的。
• 好处： 服务器不用维护大量状态信息，设计简单，更容易扩展（处理更多用户）。
• 如何保持状态？ 实际应用中（如购物车、登录状态），需要通过 Cookies 或 Session 等技术来“记住”用户状态。但这不是 HTTP 协议本身的功能，而是基于 HTTP 的扩展机制。
• 比喻： 就像一个记性不好的客服，每次你打电话过去，都得重新告诉他你是谁、你上次咨询了什么，除非他用了客户管理系统（Cookies/Session）做了记录。

1. 起始行 (Start Line):
• 请求行: 包含 请求方法 (Method) + 请求 URL + HTTP 版本。
• GET /index.html HTTP/1.1 （意思是：我想用 GET 方法获取 /index.html 这个资源，用的是 HTTP/1.1 协议）
• 状态行 (响应才有): 包含 HTTP 版本 + 状态码 (Status Code) + 状态描述。
• HTTP/1.1 200 OK （意思是：服务器用 HTTP/1.1 协议回复你，状态码是 200，表示成功）

2. 首部 / 头部 (Headers):
• 包含很多键值对，用来传递额外的重要信息。
• 请求头例子: Host: www.example.com (我想访问的主机), User-Agent: Chrome/123 (我的浏览器类型), Accept-Language: zh-CN (我希望优先看到中文内容), Cookie: ... (携带之前服务器给我的身份小饼干)。
• 响应头例子: Content-Type: text/html (我发给你的是 HTML 文本), Content-Length: 1024 (数据长度是 1024 字节), Set-Cookie: ... (给你一个身份小饼干下次带来), Cache-Control: no-cache (这个响应不要缓存)。

3. 主体 / 正文 (Body):
• 可选部分。真正要传输的数据就在这里。
• 请求体: 比如你用 POST 方法提交表单时，用户名密码等数据就在请求体里。GET 请求通常没有请求体。
• 响应体: 服务器返回的 HTML 代码、图片数据、JSON 数据等就在响应体里。

• GET: 获取资源。（最常用）

• POST: 提交数据让服务器处理（比如创建新用户、提交表单）。（常用）

• PUT: 替换服务器上的资源（用请求体里的数据完整替换目标资源）。

• DELETE: 删除服务器上的资源。

• HEAD: 和 GET 类似，但只获取响应头，不要响应体（用于检查资源是否存在、是否修改等）。

• OPTIONS: 询问服务器支持哪些请求方法。

• 新鲜度 (Freshness / Expiration): 决定多久内可以直接用缓存 (max-age)。

• 验证 (Validation): 缓存过期后如何向服务器确认缓存是否仍有效 (If-Modified-Since, If-None-Match)。

• 概念： 缓存的资源能在多长时间内被认为是“新鲜”的，可以直接使用而无需询问服务器？

• 主要控制头：
• Cache-Control (首选): 这是目前最主要、最灵活的缓存控制头。它包含很多指令：
• max-age=<秒数>: 指定资源能被视为新鲜的最长持续时间（从响应生成时开始计算）。例如 Cache-Control: max-age=3600 表示这个资源在接下来 1 小时内都是新鲜的，可以直接用缓存。
• public: 表明响应可以被任何缓存（包括浏览器、CDN 等共享缓存）缓存。
• private: 表明响应只能被单个用户的浏览器缓存，不能被共享缓存缓存（比如包含用户信息的 HTML 页面）。
• no-cache: 注意：不是“不缓存”，而是**“每次使用缓存前必须去服务器验证一下资源是否仍然有效”**。详见下面的“验证”部分。
• no-store: 这个才是“完全不缓存”。浏览器和所有中间缓存都不得存储这个响应的任何部分。通常用于敏感数据。

• 工作流程： 如果浏览器发现缓存里的资源还在“保质期”内（max-age 没过），就直接从缓存加载，速度飞快！

• 基于最后修改时间:
• 服务器首次响应时带上：Last-Modified: <文件最后修改日期>
• 浏览器验证时带上请求头：If-Modified-Since: <上次收到的最后修改日期> (意思是：这个日期之后文件修改过吗？)

• 基于 ETag (实体标签 - 更精确):
• 服务器首次响应时带上：ETag: "一个独一无二的版本标识符" (比如文件内容的哈希值)
• 浏览器验证时带上请求头：If-None-Match: "上次收到的那个ETag" (意思是：这个资源的 ETag 还是不是这个值？)
• ETag 更好，因为它能检测到文件内容变化，即使修改日期没变（比如替换了内容相同但时间戳更新的文件）。

• 如果资源没变: 服务器会返回一个非常小的 304 Not Modified 响应（状态码 304，没有响应体 Body）。浏览器收到 304 就知道：“哦，我缓存的版本还能用！” 于是就加载缓存的版本。这大大节省了带宽！

• 如果资源变了: 服务器会返回一个正常的 200 OK 响应，包含全新的资源内容和可能更新的缓存头。浏览器就用这个新版本，并更新缓存

• 1xx (信息性): 收到请求，继续处理。（不常见）

• 2xx (成功): 请求已成功被服务器接收、理解、并接受。
• 200 OK: 请求成功。（最常见）

• 3xx (重定向): 需要后续操作才能完成请求。
• 301 Moved Permanently: 请求的资源已永久移动到新 URL。
• 302 Found: 请求的资源临时移动到新 URL。
• 304 Not Modified: 资源未修改，可使用缓存的版本。

• 4xx (客户端错误): 请求包含语法错误或无法完成请求。
• 400 Bad Request: 请求无效 (比如格式错误)。
• 401 Unauthorized: 未授权 (需要登录认证)。
• 403 Forbidden: 服务器理解请求，但拒绝执行 (权限不足)。
• 404 Not Found: 找不到请求的资源。（非常常见）

• 5xx (服务器错误): 服务器在处理请求的过程中发生了错误。
• 500 Internal Server Error: 服务器内部错误。（常见）
• 503 Service Unavailable: 服务器暂时过载或维护。

• HTTPS = HTTP + SSL/TLS (安全套接层/传输层安全协议)。

• 简单说，就是在 HTTP 传输之前，先用 SSL/TLS 对通信内容进行加密，并在通信双方之间验证身份。

• 解决了 HTTP 的两大问题：
• 数据没加密（不安全）： 中途可能被窃听。HTTPS 加密了。
• 身份没验证（不安全）： 可能访问了假冒的网站。HTTPS 通过证书验证服务器身份。

• 现在网站基本都强制使用 HTTPS。

1. 加密 (Encryption) - 防止偷听
• 做什么？ 把你和网站之间传输的数据（比如密码、银行卡号）变成一堆乱码。
• 怎么做？ 双方会先用一种复杂的方式（非对称加密）商量好一个只有你们俩知道的“暗号”（对称密钥）。之后的所有通信都用这个“暗号”来加密和解密。
• 效果： 就算有黑客在中间截获了数据，看到的也只是一堆无意义的乱码，无法得知原始内容。就像你用密码锁锁住了箱子，不知道密码的人打不开。

2. 身份验证 (Authentication) - 防止假冒
• 做什么？ 确认你正在访问的网站是真的，而不是一个伪装的钓鱼网站。
• 怎么做？ 网站需要向一个权威的第三方机构（证书颁发机构，CA）申请一个“身份证”，叫做 SSL/TLS 证书。你的浏览器在访问网站时，会检查这个证书是不是由可信的机构颁发的、有没有过期、是不是给这个网站的。
• 效果： 就像你去银行，需要看银行工作人员的工牌确认身份一样，浏览器通过检查证书来确认网站的“身份”，防止你被骗到假网站。

3. 数据完整性 (Integrity) - 防止篡改
• 做什么？ 确保数据在传输过程中没有被偷偷修改。
• 怎么做？ 数据在发送前会生成一个“指纹”（消息认证码，MAC）。接收方收到数据后，会用同样的方法再算一次“指纹”，然后比较两个“指纹”是否一致。
• 效果： 如果数据在传输中被改动了，那么计算出的“指纹”就会不一样，接收方就能立刻发现数据被动过手脚了。就像快递箱上的封条，如果封条破了，你就知道里面的东西可能被动过了。

1. 验证身份：确认对方是真的

2. 协商密钥：安全生成共享加密密钥

3. 防止窃听：确保通信内容不被第三方看到

1. 网站本身可能不安全：
• 服务器漏洞： 即使通信是加密的，如果网站服务器本身存在安全漏洞（比如 SQL 注入、XSS 跨站脚本攻击），黑客仍然可能窃取存储在服务器上的数据，或者在网站上植入恶意代码。HTTPS 只保护传输过程，不保护服务器本身。
• 网站内容可能是恶意的： 一个钓鱼网站或包含恶意软件的网站也可以使用 HTTPS。浏览器地址栏的“锁”标志仅仅表示你和这个网站之间的连接是加密和经过验证的，并不代表这个网站的内容是善意或安全的。你仍然可能被诱骗输入敏感信息或下载病毒。

2. 证书不能保证网站信誉：
• 域名验证 (DV) 证书很容易获取： 最基础的 SSL/TLS 证书（DV 证书）只验证申请者对域名的控制权，并不严格审查申请者的真实身份或商业信誉。因此，诈骗分子也可以为他们的钓鱼网站申请到有效的 HTTPS 证书。
• 忽略证书警告： 如果用户在浏览器弹出证书错误警告时选择“继续访问”，那么 HTTPS 提供的身份验证保护就失效了。

3. 客户端（你的电脑/手机）可能不安全：
• 恶意软件/病毒： 如果你的设备感染了病毒或木马，它们可以在数据被 HTTPS 加密之前（比如在你键盘输入时）或解密之后（在浏览器显示时）窃取你的信息。
• 不安全的网络环境： 在某些极端情况下（例如，被强制安装了恶意的根证书），中间人攻击仍然可能发生。

4. 协议或实现本身可能存在漏洞：
• 虽然很少见，但 SSL/TLS 协议本身或其具体实现（比如某个软件库）偶尔会被发现存在漏洞（如过去的 Heartbleed 漏洞），需要及时更新打补丁。
• 配置错误： 服务器管理员如果错误地配置了 HTTPS（比如使用了过时或不安全的加密算法），也会降低安全性。

• 存储：浏览器本地文件

• 发送：自动携带在请求头中

• Session数据：服务器内存/数据库

• Session ID：Cookie中存储

• 存储：localStorage/sessionStorage/内存

• 发送：手动添加到Authorization头

JWT解决集群部署

第一性原理：集群部署的核心问题

Session在集群中的问题

场景：电商网站的集群部署

问题演示：

第1步：用户登录（分配到服务器A）

第2步：用户购物（分配到服务器B）

Session集群的传统解决方案

方案1：粘性会话 (Sticky Sessions)

方案2：Session复制

方案3：共享Session存储

JWT的无状态解决方案

核心原理：自包含的身份凭证

JWT结构详解

JWT集群场景演示

所有服务器共享相同的密钥

第1步：用户登录（服务器A处理）

第2步：用户购物（服务器B处理）

JWT解决集群问题的核心机制

1. 无状态特性

2. 自验证能力

3. 分布式友好

实际部署对比

Session集群部署复杂度

JWT集群部署简单度

JWT的局限性

1. Token撤销困难

2. Token大小问题

3. 密钥管理挑战

第一性原理总结

1. 状态外置：把状态从服务器内存移到客户端Token中

2. 自包含：Token包含所有必要的用户信息

3. 密码学保证：通过签名确保Token未被篡改

4. 时效性：通过过期时间控制Token生命周期

• 水平扩展简单：新增服务器无需状态同步

• 故障恢复快速：服务器重启不影响用户会话

• 架构解耦：认证服务与业务服务解耦

• 跨域友好：适合微服务和分布式架构

1. 第一步：登录时获取服务器"盖章"的JWT

2. 第二步：把JWT保存在客户端（localStorage/sessionStorage/内存）

3. 第三步：每次API调用都在Authorization头中带上JWT

4. 验证：服务器验证"印章"真伪，确认用户身份

完整的SSO + JWT工作流程

第1阶段：SSO登录流程

第2阶段：JWT保存和使用

第3阶段：日常使用

关键角色分工

Google的作用

Claude系统的作用

前端的作用

时间线总结

核心洞察

1. SSO只是获取JWT的方式：一旦拿到JWT，Google就不再参与了

2. JWT是Claude系统的通行证：不是Google的令牌，是Claude自己签发的

3. 前端自动化：一旦配置好，你不需要手动处理JWT，前端框架自动处理

4. 无感体验：你感觉像是"一直登录着"，实际是每个请求都在验证JWT

• 特点:
• 基于 TCP 协议。
• 文本格式传输请求和响应头。
• 请求-响应模型: 通常一个连接一次处理一个请求，响应回来后才能处理下一个（有流水线技术 Pipelining 但问题多，基本不用）。

• 主要问题:
• 队头阻塞 (Head-of-Line Blocking): 同一个 TCP 连接上，如果第一个请求的响应没回来，后面的请求就算处理完了也得等着。浏览器通常开多个 TCP 连接 (比如 6 个) 绕过这个问题，但开销大。

• 比喻: 单车道。一次只能跑一辆车（请求），后面的车得等前面的过去。

• 目标: 解决 HTTP/1.1 的性能瓶颈。

• 主要改进:
• 仍然基于 TCP 协议。
• 二进制格式: 解析更高效。
• 多路复用 (Multiplexing): 可以在一个 TCP 连接上同时发送多个请求和接收多个响应，响应可以不按顺序到达。解决了 HTTP 层面的队头阻塞。
• 头部压缩 (Header Compression - HPACK): 减少请求头的大小，节省带宽。
• 服务器推送 (Server Push): 服务器可以主动推送资源（如 CSS, JS）给客户端，无需客户端额外请求。

• 遗留问题:
• 虽然解决了 HTTP 层面的队头阻塞，但底层的 TCP 协议本身仍然存在队头阻塞。如果一个 TCP 包丢失，整个连接上的所有请求流都得等这个包重传，即使其他流的数据已经到了。

• 比喻: 把单车道升级成了多车道高速公路 (但路面材质还是 TCP)。可以在同一条路上同时跑多辆车（请求/响应并行）。但如果路上某个地方出了个小事故（TCP 丢包），整条高速公路都可能堵一下。

关键区别：不同层面的队头阻塞

HTTP/1.1的队头阻塞 - 应用层阻塞

HTTP/2的队头阻塞 - 传输层阻塞

具体例子对比

场景：下载1个大文件(HTML) + 2个小文件(CSS、JS)

HTTP/1.1的表现：

HTTP/2的表现 (无丢包)：

HTTP/2的表现 (有丢包)：

核心差异总结

更直观的比喻

HTTP/1.1 - 单车道收费站

HTTP/2 - 多车道收费站 (共用一个收费员)

HTTP/3 - 多车道收费站 (每道独立收费员)

实际测试数据

• HTTP/1.1 → HTTP/2: 解决了应用层的串行问题，但TCP的问题依然存在

• HTTP/2 → HTTP/3: 解决了传输层的队头阻塞问题

• 目标: 解决 HTTP/2 遗留的 TCP 队头阻塞问题，提升连接速度和稳定性。

• 主要革新:
• 不再基于 TCP，而是基于 QUIC 协议 (运行在 UDP 之上)。这是最核心的变化。
• 彻底解决队头阻塞: QUIC 的流是独立的，一个流的数据包丢失不影响其他流的传输。
• 更快的连接建立: QUIC 将 TCP 握手和 TLS (加密) 握手合并，减少了建立安全连接所需的往返时间 (0-RTT 或 1-RTT)。
• 内置加密: 加密是 QUIC 的一部分，强制执行，更安全。
• 连接迁移 (Connection Migration): 当你的网络变化时（比如从 Wi-Fi 切换到 4G），连接可以保持不断开，体验更流畅。

• 比喻: 不再用原来的高速公路 (TCP)，而是换了一套全新的、更先进的交通系统 (QUIC/UDP)，比如像是多条独立的磁悬浮轨道。一条轨道出问题（丢包），其他轨道照常运行。上车（连接建立）更快，安检（加密）是标配，还能无缝换乘（连接迁移）。

核心原理：QUIC的流级别独立性

TCP vs QUIC的根本差异

具体实现机制

1. 数据包结构差异

2. 丢包处理机制

实际例子：网页加载

场景：加载一个网页，包含HTML、CSS、JS三个文件

HTTP/2 + TCP的表现：

HTTP/3 + QUIC的表现：

技术实现细节

1. 流的独立性保证

2. 包的复用与解复用

性能对比数据

第一性原理总结

1. 架构层面：从"单一有序流"改为"多个独立流"

2. 协议层面：QUIC在UDP基础上重新设计了可靠性机制

3. 实现层面：每个流维护独立的状态和序号空间

• TCP的问题：天生就是单一字节流，无法绕过

• QUIC的解决：重新设计传输层，流级别的独立性

• 根本差异：TCP修复漏洞，QUIC重新建房子

• 请求-响应模式 (Request-Response): 必须是客户端先发起请求，服务器才能响应。服务器不能主动向客户端推送信息。

• 单向性: 数据流主要是从服务器到客户端（获取资源），或者一次性的从客户端到服务器（提交表单）。

• 为了实时怎么办？(HTTP 的“笨办法”):
• 轮询 (Polling): 客户端像个“急性子”，每隔很短时间（比如 1 秒）就主动问服务器：“有新消息吗？有新消息吗？”。即使没新消息也得问，非常浪费资源和流量。
• 长轮询 (Long Polling): 客户端问服务器：“有新消息吗？”，服务器收到后“憋着”，不马上回答，直到真的有新消息了才回复客户端。客户端收到回复后，立刻再发一个同样的长轮询请求继续“憋着”等。这比轮询好点，但仍然有延迟（消息到达和下一次请求之间），且服务器需要维持连接，开销也不小。

• 在线聊天室（你希望新消息立刻显示，而不是等几秒轮询一次）

• 股票行情实时更新

• 多人在线游戏（需要低延迟地同步玩家状态）

• 协同编辑文档（比如 Google Docs）

• 实时数据监控仪表盘

1. 真正的全双工通信 (Full-Duplex):
• 一旦 WebSocket 连接建立成功，客户端和服务器之间就建立了一条持久性的、双向的通道。
• 双方都可以随时主动向对方发送数据，不需要等待对方的请求。就像建立了一条电话线，双方可以随时自由通话，而 HTTP 更像是寄信，必须你寄一封，我回一封。

2. 更低的开销和延迟:
• WebSocket 连接只需要一次初始握手（这个握手是借用 HTTP 协议完成的，请求头里包含 Upgrade: websocket）。
• 握手成功后，后续的数据传输使用的是 WebSocket 自定义的、更轻量级的数据帧 (Frame)，头部开销比每次都带一堆 HTTP Headers 小得多。这使得传输非常高效，延迟也更低。

3. 持久连接:
• 连接一旦建立，除非一方明确关闭或网络中断，否则会一直保持。避免了 HTTP (即使是 Keep-Alive) 需要为每个逻辑上的“推送”反复建立或管理连接状态的开销。

• WebSocket 的“基因”就是为了实时、双向通信而生。 它提供了一个持久、低开销、全双工的通信通道。

• 它们是互补关系，不是替代关系。
• 获取网页、图片、文件等资源，进行一次性的表单提交，用 HTTP（及其各版本）仍然是最高效、最合适的。
• 需要实时聊天、实时数据更新、在线游戏等场景，用 WebSocket 是更优的选择。

2. 传输层 (Transport Layer) - “选择快递公司和打包方式”

• 核心任务： 在两个应用程序之间建立端到端的连接，管理数据传输的可靠性或效率，并将大块数据分段。

• 通俗解释： 这一层不关心包裹具体内容是什么，只关心怎么把它安全、有序或快速地从你的应用程序（比如浏览器）送到对方的应用程序（比如网站服务器）。它负责“打包”数据，并选择合适的“运输服务”。

• 包裹比喻：
• 选择服务类型：
• TCP (传输控制协议): 像顺丰或EMS快递，提供可靠服务。它会先打电话确认对方在不在家（建立连接），给每个小包裹编号（序列号），对方收到要签收确认（ACK），如果丢了会重寄（重传），还会根据路况调整速度（流量控制/拥塞控制）。虽然慢点，但保证送到，且顺序正确。适合网页、邮件、文件传输这种不能出错的应用。
• UDP (用户数据报协议): 像普通平邮，只管把包裹扔进邮筒，不保证一定送到，也不保证顺序，速度快，开销小。适合视频会议、在线直播、DNS查询这种能容忍少量丢失（或者应用层自己会处理）且对实时性要求高的场景。
• 端口号 (Port Number): 在包裹上写上“XX 公司 市场部收”或“XX 小区 3 号楼 101 室收”。端口号就是用来区分同一台电脑上不同应用程序的“房间号”，确保数据交给正确的程序处理（比如 Web 服务通常用 80/443 端口，邮件服务用 25 等）。

• 数据单位： TCP 数据段称为 段 (Segment)，UDP 数据段称为 数据报 (Datagram)。

第一性原理思考：传输数据的两种哲学

• TCP思路："我要确保数据完整、有序、可靠地到达"

• UDP思路："我只管快速发送，其他的你们自己处理"

具体场景对比

场景1：发送一封重要邮件

场景2：观看直播视频

详细特性对比

1. 连接性

2. 可靠性保证

序列号和确认

超时重传

流量控制

拥塞控制

3. 性能对比

实际应用场景

TCP适用场景：

1. 网页浏览 (HTTP/HTTPS)

2. 文件传输 (FTP)

3. 电子邮件 (SMTP)

UDP适用场景：

1. 视频直播

2. 在线游戏

3. DNS查询

4. IoT传感器数据

混合使用场景

QUIC协议 (HTTP/3的基础)

WebRTC

第一性原理总结

问数据的特性：

1. 数据完整性 > 传输速度 → TCP

2. 传输速度 > 数据完整性 → UDP

3. 实时性 > 历史数据 → UDP

4. 历史数据 > 实时性 → TCP

问应用的容错能力：

1. 不能丢失任何数据 → TCP

2. 可以容忍少量丢失 → UDP

3. 需要严格顺序 → TCP

4. 顺序不重要 → UDP

问网络环境：

1. 可靠网络，追求性能 → UDP

2. 不可靠网络，追求稳定 → TCP

3. 移动网络，频繁切换 → UDP + 自定义可靠性

• TCP: "我来负责可靠性，你专注业务逻辑"

• UDP: "你来控制一切，我只提供最基础的传输"

TCP

1. 半连接（Half-Open Connection）
• 发生在TCP三次握手的前两个步骤（SYN和SYN-ACK）。此时，服务器收到客户端的SYN包后，会将连接放入半连接队列（SYN Queue），等待客户端的ACK确认。
• 此阶段连接未完全建立，资源占用较少，但可能受到SYN Flood攻击（恶意发送大量SYN包耗尽服务器资源）。

2. 全连接（Established Connection）
• 当三次握手完成（客户端发送ACK后），连接从半连接队列转移到全连接队列（Accept Queue），等待服务器调用accept()处理。
• 此时连接已完全建立，双方可正常通信。

1. 我 -> 你： “喂，在吗？我想和你说话。” (发送 SYN)

2. 你 -> 我： “在呢，说吧！” (回复 SYN-ACK)

• 服务器无法确认客户端是否收到了它的“同意”： 服务器发出“在呢，说吧！” (SYN-ACK) 之后，它不知道客户端是否真的收到了这个回复。如果这个回复在路上丢了，客户端会认为连接没建立，可能会重试或者放弃。但服务器却认为连接已经“半建立”了，它会傻傻地等着客户端说话，甚至分配了资源。这就造成了服务器资源的浪费和状态不一致。

• 无法处理“失效的连接请求”： 想象一个极端情况：
• 我很早之前给你打过一个电话（发送了一个 SYN），但这个电话信号不好，在网络里绕了很久很久才到你那。
• 我早就因为没收到回复而放弃了，甚至已经挂机了。
• 现在，这个“迟到的”电话请求 (SYN) 突然到达了你那里。
• 你一看，“哦，有人要跟我说话”，于是你回复“在呢，说吧！” (SYN-ACK)。
• 因为只有两次握手，你回复之后就认为连接建立了，开始等待。
• 但我（客户端）早就挂机了，根本不会理睬你的回复，或者收到回复后发现不是我当前想要的连接，会发送一个 RST（重置）报文。但服务器在你回复之后、收到 RST 之前，已经认为连接建立了，分配了资源。如果这种情况频繁发生（网络中充满了这种迟到的 SYN），服务器资源就会被大量无效的“半连接”耗尽。

1. 我 -> 你： “喂，在吗？我想和你说话。我的开场白是第 X 句。” (SYN, Seq=X)
• 客户端证明自己能发送。

2. 你 -> 我： “在呢！收到了你的第 X 句（所以我知道你能发，我也能收）。我也准备好了，我的开场白是第 Y 句。” (SYN-ACK, Seq=Y, Ack=X+1)
• 服务器证明自己能收（收到了 SYN）、能发（发出了 SYN-ACK），并确认了客户端的起始序号。

3. 我 -> 你： “收到！知道了你的开场白是第 Y 句。” (ACK, Ack=Y+1)
• 客户端证明自己能收（收到了 SYN-ACK），并确认了服务器的起始序号。

• 双方确认： 通过这三步，客户端和服务器都确认了：
• 自己能发。
• 自己能收。
• 对方能发。
• 对方能收。

• 同步初始序列号： 双方都知晓了对方的起始序列号（X 和 Y），为后续可靠传输（按顺序发送和确认）打下基础。

• 防止失效连接请求： 在上面那个“迟到的 SYN”场景中：
• 迟到的 SYN (Seq=X) 到达服务器。
• 服务器回复 SYN-ACK (Seq=Y, Ack=X+1)。
• 客户端收到这个 SYN-ACK 后，发现自己当前并没有发起这个连接（或者序列号对不上），它知道这是个过期的请求，就会发送一个 RST 报文给服务器。
• 服务器收到 RST 后，就知道这个连接是无效的，会释放资源，不会傻等。 关键在于第三次握手，客户端的最终确认（ACK）或者拒绝（RST）给了服务器明确的信号。

1. 我 -> 你：SYN

2. 你 -> 我：ACK (确认收到 SYN)

3. 你 -> 我：SYN (表明自己也准备好了)

4. 我 -> 你：ACK (确认收到你的 SYN)

• 两次握手不够： 服务器无法确认客户端是否收到自己的响应，容易造成资源浪费和处理失效连接请求的问题。

• 三次握手正好： 刚好能够让双方都确认对方的收发能力，并同步初始序列号，同时能有效处理历史连接请求。是建立可靠连接所需的最少步骤。

• 四次握手冗余： 可以实现同样目的，但效率更低，没有必要。

• 谁会进入？ 主动关闭连接的那一方。通常是客户端（因为它通常先请求结束），但也可能是服务器。在四次挥手的第四步，主动方发送了最后一个 ACK 后，它不会立即进入 CLOSED 状态，而是进入 TIME_WAIT 状态。

• 干嘛的？（存在的意义） 这个状态是 TCP 可靠性的最后一道屏障，主要有两个目的：
1. 确保对方（被动关闭方）能收到最后的 ACK： 想象一下，如果主动方发送完最后的 ACK (第四次挥手) 后立刻消失 (进入 CLOSED)，但这个 ACK 在路上丢了。被动方 (此时在 LAST_ACK 状态) 就收不到这个 ACK，它会超时并重发 FIN (第三次挥手)。但此时主动方已经消失了，这个重发的 FIN 就没人理睬了，被动方可能会一直重发 FIN，或者最终收到一个 RST 报文，导致连接关闭不“优雅”。TIME_WAIT 状态的存在，就是为了让主动方停留足够长的时间 (通常是 2 * MSL)，以确保如果最后的 ACK 丢失，它还能收到对方重发的 FIN，并重新发送一次最后的 ACK，帮助对方顺利关闭。
• MSL (Maximum Segment Lifetime): 报文段最大生存时间。指一个 TCP 报文在网络中能够存活的最长时间。超过这个时间，报文就会被丢弃。2 * MSL 的时间足以保证一个方向的报文及其确认报文都能在网络中消失。
2. 防止“已失效的连接请求报文段”出现在新连接中： 考虑一种情况：一个连接 (比如 Client A: Port X -> Server B: Port Y) 关闭了。非常快地，一个新的连接又使用了完全相同的四元组 (Client A: Port X -> Server B: Port Y) 建立起来。如果在旧连接关闭时，网络中还有一些“迷路”的、属于旧连接的数据包（因为网络延迟等原因），它们可能会在这个新连接建立后才到达。如果没有 TIME_WAIT 状态，这些旧包就可能被新的连接错误地接收，造成数据混乱。TIME_WAIT 状态持续 2 * MSL 时间，就是为了确保在旧连接关闭后，所有可能残留在网络中的、属于该旧连接的报文段都已自然消失，从而保证新连接不会受到旧连接的干扰。

• 如果 TIME_WAIT 状态太多会怎么样？
• 主要问题：占用资源，特别是端口号。 每个 TIME_WAIT 状态的连接虽然不再传输数据，但仍然在内核中占据一个套接字 (socket) 结构，消耗内存资源。更关键的是，它会占用一个本地端口号。
• 后果：端口耗尽。 对于需要频繁、大量、快速建立短连接的场景（比如作为客户端的负载均衡器、爬虫、高并发的 Web 服务器去请求后端服务等），如果每次连接关闭后都要经历一个较长 (几十秒到几分钟) 的 TIME_WAIT 状态，那么可用的临时端口号 (ephemeral port range) 很快就会被用光。一旦端口耗尽，系统就无法发起新的 TCP 连接了，导致业务失败。
• 怎么办？
• 系统参数调优（有风险）： 比如减小 tcp_tw_reuse (允许将 TIME_WAIT 状态的端口复用于新的出站连接，较安全) 或 tcp_tw_recycle (快速回收 TIME_WAIT 连接，在 NAT 环境下有坑，不推荐开启)，或者缩短 TIME_WAIT 的时长 (修改内核参数 tcp_fin_timeout，但通常不建议)。
• 应用层面优化： 使用长连接 (Keep-Alive) 代替短连接，减少连接建立和关闭的次数。使用连接池。
• 增加可用端口范围： 修改系统配置 ip_local_port_range。

• 谁会进入？ 被动关闭连接的那一方。通常是服务器。在四次挥手的第二步，被动方收到了主动方的 FIN，并发送了 ACK 后，就进入 CLOSE_WAIT 状态。

• 干嘛的？（存在的意义） 这个状态表示：“我已经收到了对方（主动关闭方）的关闭请求，并且已经告诉他我知道了 (ACK sent)。但是，我这边可能还有数据要发送，或者我的应用程序还没有准备好关闭这个连接（还没调用 close() 函数）。” TCP 层需要等待本地应用程序调用 close() 方法，然后 TCP 层才会发送自己的 FIN (第三次挥手)，并将状态转移到 LAST_ACK。

• 如果 CLOSE_WAIT 状态太多是为什么？
• 核心原因：应用程序的锅！ 大量连接长时间停留在 CLOSE_WAIT 状态，几乎总是意味着服务器端的应用程序存在问题。具体来说，就是应用程序在收到对方关闭连接的信号后（通常是 read 操作返回 0 或特定错误码），没有及时调用 close() 函数来关闭这个对应的 Socket 连接。
• 可能的原因：
1. 代码逻辑 Bug： 程序可能在某个分支、循环或异常处理中忘记了调用 close()。
2. 程序阻塞： 处理该连接的线程可能被阻塞了（比如等待某个锁、等待 I/O、死循环），导致无法执行到 close() 语句。
3. 资源耗尽： 服务器资源（如线程池满了、内存不足）导致无法及时处理连接关闭的逻辑。
4. 业务逻辑复杂： 可能业务逻辑设计上，关闭连接前需要完成很多耗时操作，导致 close() 调用延迟。
• 后果：资源泄露！ 和 TIME_WAIT 不同，CLOSE_WAIT 状态会一直持续下去，直到应用程序调用 close() 为止。如果应用程序永远不调用，这个连接就会永远停留在 CLOSE_WAIT 状态。这会导致：
• 文件描述符耗尽： 每个 CLOSE_WAIT 连接都占用一个文件描述符 (file descriptor)。如果数量过多，会耗尽系统的文件描述符限制，导致无法接受新的连接或打开新的文件。
• 内存泄露： 每个连接占用的内存资源无法释放。
• 拖垮服务器： 大量半关闭的连接持续消耗系统资源，最终可能导致服务器响应缓慢甚至宕机。
• 怎么办？
• 排查应用程序代码： 仔细检查处理网络连接的代码，确保所有可能的代码路径在连接需要关闭时都正确调用了 close()。
• 检查线程/进程状态： 使用 jstack (Java)、gdb (C/C++) 等工具检查处理这些连接的线程是否被阻塞或卡死。
• 监控服务器资源： 检查 CPU、内存、文件描述符使用情况。
• 代码Review和测试： 加强代码审查和异常情况的测试。

• 它是 可靠的：通过 序号、确认应答、超时重传 保证数据不错、不丢、不乱。

• 它是 面向连接的：通过 三次握手 建立连接，四次挥手 断开连接，保证双方状态同步。

• 它有 流量控制：通过 滑动窗口 匹配收发双方的处理能力。

• 它有 拥塞控制：通过 慢启动、拥塞避免 等机制，适应网络状况，防止搞垮整个网络。

• 它是 面向字节流的：应用层无需关心数据如何分包。

3. 网络层 (Internet Layer / Network Layer) - “写清跨省市的详细地址，规划全国路线”

• 核心任务： 负责将数据包从源主机路由到目标主机，跨越多个不同的网络。核心是寻址和路由。

• 通俗解释： 这一层就像是全球邮政系统的核心，负责看懂包裹上的最终地址（IP 地址），并决定这个包裹下一站应该交给哪个中转站（路由器），最终能从你的城市送到朋友所在的城市。

• 包裹比喻：
• IP 地址 (Internet Protocol Address): 就像包裹上写的完整的、唯一的收件人街道地址（例如：XX省 XX市 XX区 XX路 XX号）。它标识了你的电脑或朋友的电脑在整个互联网中的逻辑位置。有 IPv4 和 IPv6 两种格式。
• 路由器 (Router): 就像沿途的邮政分拣中心。每个路由器只看目标 IP 地址，然后根据自己的“地图”（路由表），决定把包裹发往下一个最合适的路由器，一跳一跳地接近目的地。
• IP 协议本身是“不可靠”的： 它只负责指路，但不保证包裹一定能送到，或者按顺序到达（这个保证由上层 TCP 负责）。

• 数据单位： 称为 包 (Packet) 或 IP 数据报 (IP Datagram)。

IP

• 如果是： 太好了！我直接把文件“扔”过去就行了（通过局域网内部的交换机直接发送）。

• 如果不是： 那我得把文件交给“小区门卫”（也就是网关/路由器），让门卫帮忙转寄出去。

• 你的 IP: 192.168.1.100
• 二进制: 11000000.10101000.00000001.01100100

• 子网掩码: 255.255.255.0
• 二进制: 11111111.11111111.11111111.00000000

• 目标 IP: 192.168.1.150
• 二进制: 11000000.10101000.00000001.10010110

• 你的子网掩码: 255.255.255.0
• 二进制: 11111111.11111111.11111111.00000000

• 你的网络地址（小区名）是 192.168.1.0。

• 目标电脑的网络地址（小区名）也是 192.168.1.0。

• 目标 IP: 8.8.8.8
• 二进制: 00001000.00001000.00001000.00001000

• 你的子网掩码: 255.255.255.0
• 二进制: 11111111.11111111.11111111.00000000

• 你的网络地址是 192.168.1.0。

• 目标 8.8.8.8 的网络地址是 8.8.8.0。

• IP 地址： 网络设备的唯一标识，是寻址的基础 (包括 IPv4/IPv6, 公网/私网, 子网掩码)。

• IP 数据报： 标准化的数据封装格式，包含源/目的地址等关键信息。

• 路由： 基于路由表的逐跳转发机制，决定数据包的传输路径。

• 尽力而为： 不保证可靠性、顺序性，是 IP 的核心特点 (快但不靠谱)。

• TTL： 防止数据包在网络中无限循环的机制。

4. 网络接口层 (Network Interface Layer / Link Layer) - “最后一公里的快递员和交通工具”

• 核心任务： 处理在**同一个物理网络（局域网）**内部的数据传输，将 IP 数据包封装成帧，并处理物理硬件地址（MAC 地址）和具体的物理传输介质。

• 通俗解释： 这是最底层，负责实际的“跑腿”工作。当包裹到达你朋友所在城市的最后一个邮局（路由器）后，这一层负责把它准确送到朋友家的具体门牌号。它也规定了是用卡车、摩托车还是自行车（对应网线、Wi-Fi 等）来送。

• 包裹比喻：
• MAC 地址 (Media Access Control Address): 像是身份证号或者设备网卡的唯一序列号，或者你家在小区里的具体门牌号。它只在同一个局域网内（比如你家里的所有设备连到同一个路由器）才有效，用来标识网络中的具体设备。当路由器要把包裹交给最终的电脑时，它需要知道这台电脑的 MAC 地址。
• 物理传输： 把数字信息（0和1）转换成电信号（通过网线）、光信号（通过光纤）或无线电波（通过 Wi-Fi），在物理链路上发送出去。
• 协议举例： 以太网 (Ethernet) 协议（用于有线连接）、Wi-Fi (IEEE 802.11) 协议（用于无线连接）。

• 数据单位： 称为 帧 (Frame)。