计算机网络要解决的是不同设备如何寻址、互联、可靠地交换数据，以及网络故障如何定位的问题。本文根据一次循序渐进的学习讨论，整理家庭局域网、地址与路由、TCP/UDP、DNS/NAT、HTTP/HTTPS、网络分层、VLAN 以及 OSPF/BGP 等知识，重点保留自己的理解与容易混淆的地方，供复习和后续实践使用。
\n家庭上网的简化路径：
\n手机 / 电脑 ── Wi-Fi 或网线 ── 家庭路由器 ── 运营商网络 ── 互联网 ── 网站服务器\n │\n 家庭局域网（LAN）我的理解： 家里的设备先加入同一个家庭网络，再通过路由器与外部网络通信。这个基本框架是正确的。需要补充的是，家庭无线路由器往往集成了无线 AP、以太网交换功能、路由和防火墙等功能。
\n| 设备 | \n主要关注 | \n典型作用 | \n
|---|---|---|
| 二层交换机 | \nMAC 地址、交换机端口 | \n在同一 VLAN 内转发以太网帧 | \n
| 路由器 | \n目的 IP、路由表 | \n在不同 IP 网络之间转发数据包 | \n
| 无线 AP | \nWi-Fi 接入与二层帧 | \n让无线终端接入局域网 | \n
注意：“交换机处于链路层、路由器处于网络层”适用于典型二层交换机与路由器。三层交换机也能执行 IP 路由。
\n192.168.1.10。它告诉网络数据包的源端与目的端在哪里。A4:5E:60:12:34:56。192.168.1.10:50000。记忆：IP 决定发往哪个主机或网络；MAC 决定当前链路这一跳交给谁；端口号帮助找到哪个应用端点。
\n我的早期理解中，把 MAC 地址说成“16 位”，这是错误的。常见以太网 MAC 地址是 48 位（6 字节），通常用 12 个十六进制数字表示。
\n典型 MA-L 分配方式是前 24 位组织标识（OUI）、后 24 位由组织分配，但 MAC 地址方案并非都必须按这一种方式理解。MAC 通常具有唯一性，却不是绝对不会重复，也可以被软件随机化或修改。修改对外呈现的 MAC 不等于硬件变成一块新网卡，更不必然需要烧录固件。
\nIPv4 地址有 32 位，子网掩码用于区分网络部分与主机部分。
\n示例配置（非实测）：
\n电脑 A：192.168.1.10/24\n电脑 B：192.168.1.20/24\n电脑 C：192.168.2.10/24\n\n/24 = 255.255.255.0网络地址的计算方式：
\n网络地址 = IP 地址 按位与 子网掩码A 和 B 的网络地址都是 192.168.1.0，C 的网络地址是 192.168.2.0。在普通网络规划中，A 和 B 可通过同一二层网络直接通信；C 通常需要路由器或三层交换机进行跨子网转发。
易混点： 不能永远只看 IP 前三组是否一致。比如 /25、/26 会在同一个 192.168.1.x 范围中划分更小的子网。还要考虑 VLAN、设备隔离和防火墙规则。
默认网关是目标网络没有更具体匹配路由时，设备通常选用的下一跳路由器。
\n假设电脑配置：
\nIP：192.168.1.10\n掩码：255.255.255.0\n默认网关：192.168.1.1访问 8.8.8.8 时，电脑发现目的地址不在本地子网，于是按路由表把 IP 包交给 192.168.1.1。
需要区分两种地址：
\n8.8.8.8。8.8.8.8 的 MAC。DHCP（动态主机配置协议）通常提供 IP、掩码、默认网关、DNS 等配置。常见首次获取地址的过程简称 DORA：
\nDiscover → Offer → Request → ACK我的理解与修正： 重新加入同一个网络时，设备可能尝试请求之前使用的 IP；但地址能否继续使用，取决于租约状态、服务器分配策略等，并不是“申请这个 IP 的永久权限”。
\n同一二层网络中，如果 A 已经知道 B 的 IPv4 地址，却不知道 MAC，可广播 ARP 请求：
\nA：谁拥有 192.168.1.20？\nB：我拥有该 IP，我的 MAC 是 BB:BB:BB:BB:BB:BB。\nA：将这条 IP → MAC 映射加入 ARP 缓存。ARP 广播的范围是同一个二层广播域。访问外部 IP 时，主机通常 ARP 查询网关的 MAC，而不是远端服务器的 MAC。
\nARP 欺骗利用传统 ARP 缺乏原生身份认证的特点，发送伪造 ARP 信息使其他设备缓存错误映射。例如：
\n正确：192.168.1.1 → 路由器真实 MAC\n错误：192.168.1.1 → 攻击者 MAC后续发送给网关的二层帧可能被引导至攻击者，造成中间人攻击或网络中断。攻击既可以借助伪造应答，也可能使用免费 ARP，不限定只有一种报文形式。
\n难以处理的原因在于：清掉缓存只是修复表面状态；如果攻击源持续发送虚假映射，缓存就可能再次被污染。某些设备还缺乏 DAI（动态 ARP 检测）、DHCP Snooping 等防护能力。
\n常见防护思路：管理设备接入、限制广播域、在支持的交换机上正确配置 DAI/DHCP Snooping、对固定节点进行适当绑定。MAC 变化不一定是攻击，还可能来自网关切换或设备更换。
\n| 表 | \n通常由谁维护 | \n根据什么查 | \n得到什么 | \n
|---|---|---|---|
| MAC 地址表 | \n二层交换机 | \n目的 MAC，结合 VLAN | \n出端口 | \n
| ARP 缓存表 | \nIPv4 主机、路由器 | \n下一跳 IPv4 地址 | \n下一跳 MAC | \n
| 路由表 | \n主机、路由器、三层交换机 | \n目的 IP 地址 | \n下一跳、出接口等 | \n
一个同子网通信的典型过程是：
\n跨网段通信时，ARP 解析的是下一跳网关的 MAC。这也解释了为什么 ARP 欺骗时，路由表本身可能完全正常，但数据仍被送到了错误的二层目的地。
\n| 教学五层模型 | \n主要职责 | \n示例协议或技术 | \n
|---|---|---|
| 应用层 | \n应用通信规则 | \nHTTP、DNS、DHCP、SMTP | \n
| 传输层 | \n进程通信、端口、可靠性机制 | \nTCP、UDP | \n
| 网络层 | \nIP 寻址、路由、诊断 | \nIPv4、IPv6、ICMP | \n
| 数据链路层 | \n本地链路帧交付 | \n以太网、VLAN | \n
| 物理层 | \n电、光、无线信号传输 | \n网线、光纤、无线介质 | \n
正式的 TCP/IP 四层模型 通常将链路层与物理层合并为“网络接口层”；OSI 七层 还在应用层以下单列表示层、会话层。实际互联网协议不一定严格一对一对应 OSI 每一层。
\n以基于 TCP 的 HTTPS 为例，逻辑封装过程是：
\n应用层 HTTP 请求\n ↓ TLS 加密保护\nTCP 首部 + TLS 数据\n ↓\nIP 首部 + TCP 报文段\n ↓\n以太网帧首部 + IP 数据包 + 帧校验序列\n ↓\n电信号 / 光信号 / 无线信号接收方按反方向逐层处理，即解封装。路由器转发时通常重新封装链路层帧、递减 IPv4 TTL；如果不存在 NAT 等额外处理，普通转发不会自动改变源、目的 IP。
\nTCP 的主要能力：建立连接、按序交付、确认与重传、滑动窗口、流量控制、拥塞控制。
\n三次握手（简化）：
\n客户端 服务器\n SYN ───────────────→\n ←─────────────── SYN + ACK\n ACK ───────────────→\n 建立连接典型四次挥手（简化）：
\n主动关闭方 被动关闭方\n FIN ───────────────→\n ←─────────────── ACK\n ←─────────────── FIN\n ACK ───────────────→TCP 是全双工的，两个方向的关闭可以分开进行。在一些情况下，最后的 ACK 与 FIN 报文也可合并，因此“四次挥手”是典型过程，不是所有连接都严格呈现四个独立报文。
\nTCP 是字节流：调用两次 send()，接收端不一定对应两次 recv()，应用需要自行定义消息边界。
UDP 不需要 TCP 式的三次握手，默认不保证可靠到达和顺序，保留数据报边界，首部仅 8 字节。
\n“无连接”不等于“只要知道 MAC 和 IP 即可发送”。UDP 仍然依赖 IP 寻址、链路层传输，并使用源端口与目的端口。UDP 上层也可以自行设计可靠传输机制，QUIC 就是一个典型例子。
\n| 比较 | \nTCP | \nUDP | \n
|---|---|---|
| 连接 | \n面向连接 | \n无连接 | \n
| 数据单位 | \n字节流 | \n数据报 | \n
| 可靠和按序交付 | \n协议内置 | \n不保证 | \n
| 首部 | \n最小 20 字节 | \n8 字节 | \n
| 常见用途 | \n文件传输、数据库、Web | \n实时音视频、游戏、部分 DNS | \n
滑动窗口：让发送方能维持多个未确认的字节，不必逐个数据段停止等待。TCP 的 ACK 确认号通常表示下一个期望按序收到的字节序列号，不是“第几个包”。
\nrwnd（接收窗口）。cwnd（拥塞窗口）。简化关系：
\n可容纳的最大在途数据量 ≤ min(rwnd, cwnd)如果已有数据未确认，还能继续发送的新数据量会进一步减少。经典拥塞控制包括慢启动和拥塞避免，但现代系统可能使用 CUBIC、BBR 等不同算法。
\nIPv4 数据包由首部与载荷组成。基本首部 20 字节，存在选项时可更长。重要字段有：
\n| 字段 | \n作用 | \n
|---|---|
| 源 IP / 目的 IP | \n寻址与转发 | \n
| TTL | \n限制逐跳转发次数 | \n
| Protocol | \n标识上层协议 | \n
| Total Length | \n整个 IPv4 数据包长度 | \n
| Identification / Flags / Fragment Offset | \nIPv4 分片控制与重组 | \n
| Header Checksum | \nIPv4 首部校验 | \n
常见 IPv4 Protocol 数值：ICMP = 1、TCP = 6、UDP = 17、OSPF = 89。
TTL（Time To Live）虽然名字有“时间”，但在现代 IPv4 转发中实际主要充当跳数限制。
\n发送端：TTL = 64\n经过第一台路由器：TTL = 63\n经过第二台路由器：TTL = 62\n……TTL 耗尽时，路由器丢弃数据包，通常发送 ICMP Time Exceeded。Windows 的 tracert 就利用逐渐增加的 TTL 探测沿途部分路由节点。
MTU（Maximum Transmission Unit）表示链路所能承载的最大网络层数据包大小。普通以太网常用 MTU 为 1500 字节。
\n当 IPv4 数据包超过下一跳 MTU 时：
\n分片增加额外首部开销；某片丢失还可能导致原数据报无法重组，因此网络通常会尽量避免不必要的分片。
\n| 项目 | \nIPv4 | \nIPv6 | \n
|---|---|---|
| 地址长度 | \n32 位 | \n128 位 | \n
| 示例 | \n192.168.1.10 | \n2001:db8:1234::10 | \n
| 基本首部 | \n最小 20 字节 | \n固定 40 字节 | \n
| 地址解析 | \nARP | \n基于 ICMPv6 的 NDP | \n
| 跳数限制 | \nTTL | \nHop Limit | \n
| 中间路由器分片 | \n条件允许时支持 | \n不执行分片 | \n
| 广播 | \n支持 | \n不使用广播 | \n
IPv6 地址空间更大，一般无需像家用 IPv4 一样依靠 NAPT 共享公网地址；但仍需要防火墙，且某些场景仍会使用 NAT64 等转换技术。
\nICMP 主要用于 IP 网络中的错误报告与诊断，不是 TCP 或 UDP 的一个端口服务。
\nping 通常通过 ICMP Echo Request / Echo Reply 测试可达性，并测量 RTT（往返时间）。tracert 利用不同 TTL 对中间路由器进行逐跳探测。示例命令（未在本文执行，不代表实测结果）：
\nping 192.168.1.1\nping 8.8.8.8\ntracert -d 8.8.8.88.8.8.8 是 Google Public DNS 提供服务的公网 IPv4 地址。电脑不需要与该地址处于同一子网；经默认网关、运营商网络及互联网路由转发，就可以到达提供该地址服务的网络节点。
能 ping 通只表示 ICMP 探测收到了响应，不表示当前一定在使用 Google DNS，也不代表 DNS、HTTPS 等所有业务都正常。Google 公共 DNS 使用 Anycast 等机制部署，不能简单理解为全世界都在 ping 同一台物理计算机。
\ntracert 某一跳出现 * * * 也不必然意味着故障：路由器可能限制 ICMP 回复，但仍正常转发业务数据。
DNS（Domain Name System）用于查询域名对应的记录，例如 A（IPv4）、AAAA（IPv6）、CNAME（别名）、MX（邮件服务器）、NS（权威名称服务器）等。
\nwww.example.com ── DNS 查询 ──→ 对应的 IP 地址记录递归解析器可能直接命中缓存，也可能依次联系根服务器、顶级域服务器和权威服务器。DNS 可以使用 UDP、TCP，以及 DoH/DoT 等加密传输方案。
\nNAT（Network Address Translation）改变数据包中的网络地址。家庭 IPv4 网络常见的是 NAPT/PAT，会利用端口映射让多个私有地址设备共享一个公网 IPv4 地址。
\n示例映射（非实测）：
\n192.168.1.10:50001 ──→ 公网 IP:40001\n192.168.1.20:50002 ──→ 公网 IP:40002路由器记录转换关系，以便把返回数据送回正确的内部终端。NAT 不等于防火墙；外部能否主动访问内部设备，还与 NAT 映射、端口转发、防火墙策略等有关。
\n容易混淆：DNS 解决“域名查 IP”；NAT 解决“地址和端口如何转换”。
\nHTTP 是应用层协议，定义客户端向服务器发送请求、服务器返回响应的规则。
\n示例 HTTP 请求（非抓包结果）：
\nGET /index.html HTTP/1.1\nHost: example.com常见方法有 GET、POST、PUT、PATCH、DELETE。常见状态码：
\n| 状态码 | \n含义 | \n
|---|---|
| 200 | \n成功 | \n
| 301 | \n永久重定向 | \n
| 400 | \n请求错误 | \n
| 401 | \n未通过认证 | \n
| 403 | \n拒绝访问 | \n
| 404 | \n资源不存在 | \n
| 500 | \n服务端内部错误 | \n
| 502 | \n网关收到无效上游响应 | \n
HTTP 本身不提供传输加密和服务器身份认证。HTTPS 通过 TLS 提供通信机密性、完整性保护及证书身份验证。
\nHTTP/1.1 或 HTTP/2\n ↓\n TLS\n ↓\n TCP\n ↓\n IPHTTP/3 是重要例外：它通过基于 UDP 的 QUIC 传输，并集成 TLS 1.3 握手机制。
\n数字证书通常包含域名、公钥、有效期和签名等信息；浏览器通过可信 CA 链及域名检查来验证服务器身份。HTTPS 不能证明网站内容本身值得信任。
\nHTTP 本身不会自动保存跨请求的用户登录身份，网站通常借助额外的会话或凭证机制。
\n| 概念 | \n本质 | \n
|---|---|
| Cookie | \n浏览器保存并按规则携带的数据 | \n
| Session | \n服务端或应用维护的会话状态 | \n
| Token | \n可供服务器验证的凭证 | \n
| JWT | \n一种结构化令牌格式，通常可通过签名验证 | \n
典型 Cookie + Session 流程：
\n用户登录 → 服务端验证 → 创建会话\n → 浏览器保存 Session ID Cookie\n → 后续请求携带 Cookie\n → 服务端根据 Session ID 查询会话Token 也可以放在 Cookie 中，不是只能放在 HTTP Authorization 头。普通签名 JWT 的 Payload 不是加密数据，不要在其中直接放密码、密钥等敏感信息。
VLAN（虚拟局域网）使同一套物理交换设备能够划分不同二层广播域。例如：
\nVLAN 10 → 研发部门 → 192.168.10.0/24\nVLAN 20 → 财务部门 → 192.168.20.0/24\nVLAN 30 → 访客网络 → 192.168.30.0/24一个 VLAN 配一个 IP 子网是常见设计，但 VLAN 与子网不是同一个概念，也不强制严格一一对应。
\n即使两台电脑都配置 192.168.1.x/24，如果它们位于隔离的 VLAN，也不能仅靠普通二层广播和 ARP 直接互通。不同 VLAN 间通信通常需要三层交换机或路由器，并受到 ACL/防火墙等策略约束。
VLAN 不是加密机制，它只能隔离二层广播域，不能单独替代防火墙。
\nSTP（生成树协议）通过逻辑阻塞部分冗余链路，避免二层环路及广播风暴。以太网二层广播帧不像 IPv4 包那样依靠 TTL 终止，因此交换环路需要特别处理。
\n家庭路由器常通过默认路由将未知外部目的地的流量交给运营商，不需要持有互联网全量路由信息。
\n| 项目 | \n静态路由 | \n动态路由 | \n
|---|---|---|
| 配置来源 | \n管理员手工设置 | \n协议自动学习 | \n
| 适用范围 | \n小型、稳定网络 | \n网络规模较大、拓扑变化较多 | \n
| 链路变化 | \n通常需额外处理 | \n协议可重新收敛 | \n
| 开销 | \n通常较低 | \n需要交换控制信息与计算 | \n
OSPF 通过 Hello 维护邻居关系、交换 LSA 链路状态通告、维护 LSDB，并通过 SPF（最短路径优先）算法根据 Cost 计算路径。这里“最短”是协议度量开销较小，不一定表示地理距离短。
\nOSPF 直接封装在 IP 中，协议号为 89，不通过 TCP/UDP 端口。
BGP 是路径向量路由协议，广泛用于自治系统（AS）之间交换网络前缀可达性信息，也存在 iBGP 在 AS 内传播 BGP 路由的场景。
\nBGP 根据本地策略及路由属性选路，AS_PATH 是其中一个重要属性，但BGP 不保证总选择 AS_PATH 最短的路线。BGP 使用 TCP 端口 179。
| 项目 | \nOSPF | \nBGP | \n
|---|---|---|
| 典型用途 | \nAS 内部路由 | \nAS 之间路由交换与策略控制 | \n
| 协议类别 | \n链路状态 | \n路径向量 | \n
| 主要依据 | \n链路状态、Cost | \n策略和路由属性 | \n
| 传输 | \nIP 协议号 89 | \nTCP 179 | \n
假设电脑已经通过 DHCP 得到：
\nIPv4：192.168.1.10/24\n默认网关：192.168.1.1访问 https://www.example.com 时，可以从逻辑上理解为：
这不是严格单线发生的时间顺序：DNS 请求、TCP 握手、TLS 握手本身也都要依靠 IP 和链路层传输，NAT 发生于相应的数据包经过网关时。
\n以下命令仅为学习和排查用例，不是本次学习中提供的实际运行记录。其中示例网关应按实际网络配置修改。
\n命令：查看本机配置及缓存
\nipconfig /all\narp -a\nroute print -4\ngetmac /v命令：测试连通性与路由路径
\nping 127.0.0.1\nping 192.168.1.1\nping 8.8.8.8\ntracert -d 8.8.8.8命令：查看 DNS 与连接
\nnslookup www.baidu.com\nnslookup www.baidu.com 8.8.8.8\nnetstat -ano排查时可以从本机配置、到网关、到外部 IP、DNS、TCP/HTTPS 应用逐步定位。需要注意：ping 被拦截、tracert 不回复中间节点，都不等于实际数据业务一定中断。
\n| 易混之处 | \n正确记法 | \n
|---|---|
| 同一个局域网 = 互联网 | \n错，LAN 内通信可以独立于互联网 | \n
| MAC 地址 16 位 | \n错，常见以太网 MAC 是 48 位 | \n
| 修改 MAC = 换了一块网卡 | \n错，软件修改不改变网卡硬件 | \n
| DHCP 重新连接一定分配原 IP | \n错，取决于租约和服务器策略 | \n
| 同一子网 IP 就一定能通信 | \n不一定，还要有二层连通性与允许的访问策略 | \n
| ARP 可以查询远端公网服务器 MAC | \n通常不会，先查询本地下一跳 MAC | \n
| UDP 无连接 = 不需要端口 | \n错，UDP 同样使用端口号 | \n
| MAC 表 = ARP 表 = 路由表 | \n三者分别解决端口、地址映射、路由下一跳 | \n
| ping 通 8.8.8.8 = DNS 正常 | \n错，ping 主要测试 ICMP 连通性 | \n
| TCP 流量控制 = 拥塞控制 | \n前者关注接收方，后者关注网络 | \n
| HTTPS = 网站一定安全 | \n错，TLS 保护通信并验证连接身份，不保证内容可信 | \n
| VLAN = 子网 | \n错，VLAN 在二层，IP 子网在三层 | \n
| BGP 总选最短 AS_PATH | \n错，选路受策略和多种路由属性影响 | \n
目前已经建立起一条比较完整的理解链条：DHCP 提供网络配置 → DNS 解析域名 → 路由表决定下一跳 → ARP 获得链路层地址 → 交换机按 MAC 转发 → IP 跨网转发 → TCP/UDP 提供进程间传输 → HTTP/HTTPS 等应用协议交换数据。
\n本文以概念学习和命令示例为主，尚未提供 Wireshark 抓包、路由器配置截图或真实故障排查结果，不能把上述示例当成实测结论。适合下一阶段动手验证的内容有：
\narp -a、route print -4 和 ipconfig /all，解释一条实际上网连接的下一跳。tracert 输出，区分“节点不回复 ICMP”和“路由转发真的失败”。最终记忆：MAC 解决当前链路的交付，IP 解决跨网络的寻址与转发，TCP/UDP 解决应用进程间的数据传输；其余协议和机制围绕地址分配、解析、安全、管理及路径维护相互配合。
\n", "tags": [ "计算机网络", "TCP/IP", "网络基础", "网络协议" ] }, { "id": "https://yyboom.me/2026/11/10/servlet-notes/", "url": "https://yyboom.me/2026/11/10/servlet-notes/", "title": "Servlet 学习笔记", "date_published": "2026-11-10T16:00:00.000Z", "content_html": "java编写的服务端程序，主要功能用于交互式浏览和修改数据。狭义的Servlet是指Java语言实现的一个接口，广义的Servlet是指任何实现了这个Servlet接口的类，一般情况下，人们将Servlet理解为后者。Servlet可以响应任何类型的请求,但是大多数情况只用于扩展基于Http协议的服务器。
\n\n\n目前的Servlet已经内嵌在tomocat中
\n
Servlet API 包含以下4个Java包：\njavax.servlet 其中包含定义servlet和servlet容器之间契约的类和接口。
\njavax.servlet.http 其中包含定义HTTP Servlet 和Servlet容器之间的关系。
\njavax.servlet.annotation 其中包含标注servlet，Filter,Listener的标注。它还为被标注元件定义元数据。
\njavax.servlet.descriptor，其中包含提供程序化登录Web应用程序的配置信息的类型。
\nServlet接口定义了Servlet与servlet容器之间的契约。这个契约是：Servlet容器将Servlet类载入内存，并产生Servlet实例和调用它具体的方法。但是要注意的是，在一个应用程序中，每种Servlet类型只能有一个实例。
\n用户请求致使Servlet容器调用Servlet的Service（）方法，并传入一个ServletRequest对象和一个ServletResponse对象。ServletRequest对象和ServletResponse对象都是由Servlet容器（例如TomCat）封装好的，并不需要程序员去实现，程序员可以直接使用这两个对象。
\nServletRequest中封装了当前的Http请求，因此，开发人员不必解析和操作原始的Http数据。ServletResponse表示当前用户的Http响应，程序员只需直接操作ServletResponse对象就能把响应轻松的发回给用户。
\n对于每一个应用程序，Servlet容器还会创建一个ServletContext对象。这个对象中封装了上下文（应用程序）的环境详情。每个应用程序只有一个ServletContext。每个Servlet对象也都有一个封装Servlet配置的ServletConfig对象。
\n", "tags": [ "Java", "Servlet" ] }, { "id": "https://yyboom.me/2026/03/31/JWT%E4%BB%A4%E7%89%8C/", "url": "https://yyboom.me/2026/03/31/JWT%E4%BB%A4%E7%89%8C/", "title": "JWT令牌", "date_published": "2026-03-31T10:21:58.000Z", "content_html": "JWT全称为JSON Web Token，是一种用于身份验证的开放标准。它是一个基于JSON格式的安全令牌，主要用于在网络上传输声明或者用户身份信息。JWT通常被用作API的认证方式，以及跨域身份验证。
\nJWT令牌由三部分组成，分别是头部（Header）、载荷（Payload）和签名（Signature）。头部包含了令牌使用的加密算法信息，载荷包含了所需传输的用户信息，签名用于保证令牌的完整性和真实性，防止令牌被篡改。
\n用户认证请求
\n客户端（如浏览器、App）向服务器发送认证请求，通常是提交用户名和密码等凭证。
服务器验证与生成Token
\n服务器收到请求后，验证凭证是否正确。若验证通过，服务器会生成一个JWT Token，该Token包含用户身份信息（如用户ID、角色等）的JSON数据，并使用密钥进行签名（确保Token的完整性和真实性）。
服务器返回Token给客户端
\n服务器将生成的JWT Token返回给客户端，通常是通过HTTP响应的头部（如Authorization字段）或响应体返回。
客户端存储Token
\n客户端收到Token后，将其存储在本地，常见的存储方式有浏览器的本地存储（localStorage/sessionStorage）或移动端的本地数据库。
客户端携带Token发送请求
\n后续客户端在访问需要认证的资源时，会在HTTP请求的头部（如Authorization字段）中携带JWT Token。
服务器验证Token
\n服务器收到请求后，会检查请求头中的Token。首先验证Token的签名是否有效（确保Token未被篡改），然后解析Token中的信息，确认用户身份和权限。
服务器处理请求并返回响应
\n若Token验证通过，服务器会根据请求处理业务逻辑，并返回相应的结果给客户端；若验证失败，服务器会返回错误信息（如401 Unauthorized）。
**总结：**简单来说，JWT的使用流程就是客户端通过认证获取Token，然后在后续请求中携带Token，服务器通过验证Token来确认用户身份和权限，从而实现身份认证和授权的功能。
\n\n\n", "tags": [ "JWT", "身份验证" ] }, { "id": "https://yyboom.me/2026/03/31/MongoDB/", "url": "https://yyboom.me/2026/03/31/MongoDB/", "title": "MongoDB", "date_published": "2026-03-31T10:21:58.000Z", "content_html": "首次访问通过认证获取Token，后续用Token替代重复认证，既保证安全又提升效率。同一个用户端首次通过登录注册拿到token后，后续访问只需在请求头带上token，服务器验证通过就能正常访问资源，无需重复登录。
\nJWT Token存储在HTTP的泄露风险：
\n\n
\n- \n
\n网络传输风险
\n
\n中间人攻击：Token在HTTP请求头中以明文（或Base64编码）传输，若网络环境不安全（如公共WiFi），攻击者可通过抓包工具获取Token，进而利用其伪造身份访问资源。- \n
\n存储安全问题
\n
\n本地存储漏洞：客户端将Token存储在localStorage/sessionStorage或本地数据库，若设备被恶意软件感染，Token可能被窃取，导致账户被盗用。- \n
\n服务器端隐患
\n
\n日志泄露：服务器日志若记录了完整请求信息，Token会被存储在日志中，若日志管理不善，可能被内部人员或攻击者获取。
\n风险规避建议
\n使用<u>HTTPS</u>：强制所有请求通过HTTPS传输，利用SSL/TLS加密协议保护Token安全。
\n短期Token有效期：设置Token的过期时间（如1小时），到期后需重新认证，降低Token被盗用的风险。
\n存储优化：移动端可使用更安全的存储方式（如iOS的Keychain、Android的Keystore），浏览器端避免将敏感信息存入localStorage。注解：<u>HTTPS</u>通过SSL/TLS加密协议保护Token的核心原理是加密传输和身份验证，具体如下：
\n\n
\n- 建立安全连接
\n
\n握手阶段：客户端与服务器通过SSL/TLS协议进行“握手”，协商加密算法（如AES、RSA）和会话密钥。此过程中，服务器会发送证书（含公钥），客户端验证证书有效性，确保连接到合法服务器。- 加密Token传输
\n
\n对称加密：握手完成后，双方使用协商好的会话密钥对HTTP请求/响应进行加密。Token作为请求头的一部分（如Authorization字段），会被加密后传输，即使数据被拦截，攻击者也无法获取Token明文。- 身份验证与完整性保护
\n
\n数字签名：服务器证书包含数字签名，客户端可通过CA机构验证其真实性，防止中间人伪造服务器身份窃取Token。同时，TLS协议通过哈希算法（如SHA-256）确保数据完整性，若Token在传输中被篡改，客户端可检测到并拒绝接收。- 会话管理
\n
\nSSL/TLS会话机制：通过会话ID和加密上下文，确保Token仅在安全会话中有效。一旦会话结束，Token的传输安全性将依赖于客户端的存储保护，因此建议结合短期Token有效期和安全存储方式（如Keychain、Keystore）进一步增强安全性。
\n简单来说，SSL/TLS为Token传输构建了“加密隧道”，从传输安全、身份验证到数据完整性全方位保护，降低Token泄露风险。
MongoDB是一种高性能、开源的，面向文档的NoSQL数据库，使用JSON风格的文档存储数据。以其灵活的数据模型和强大的扩展性而闻名。与传统的关系型数据库（如MySQL）不同，MongoDB使用文档存储数据，更适合处理非结构化或半结构化的数据。它支持动态模式，允许不同文档具有不同的字段结构。MongoDB的设计目标是提供高性能、高可用性和易于扩展的数据库解决方案。
\n灵活的文档模型：数据以文档形式存储，支持嵌套结构，适合复杂数据类型。
\n高性能：支持内存中的数据存储，提供高性能的读写操作。
\n水平扩展：通过分片（Sharding）支持水平扩展，适合大规模数据集。
\n丰富的查询语言：支持复杂的查询操作，包括聚合、索引和全文搜索。
\n跨平台：支持Linux、Windows和macOS等多种操作系统。
\nNginx是十分轻量级的HTTP服务器。Nginx，它的发音为“engine X”，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器。
\n\n\n\n
\n- Web服务器：它的本职工作是将你电脑上的网页文件（HTML， CSS， 图片）发送给用户的浏览器。
\n- 反向代理服务器：这是它更强大、更常用的角色。它接收客户端的请求，然后代表客户端去向后端的多个服务器索取资源，最后将整合好的结果返回给客户端。客户端并不知道后端的具体情况。
\n- 邮件代理服务器：它也能处理邮件相关的协议。
\n
\n\n\n
\n- 传统服务器的"一人一岗"模型：像Apache的旧模式，每个用户连接都会创建一个新的操作系统进程或线程。当连接数达到几千时，服务器就会因为进程/线程的创建和切换开销而变得非常缓慢。
\n- Nginx的"事件驱动"异步模型：Nginx使用一个（或少数几个）主进程来管理多个工作进程。每个工作进程都是"事件驱动"的，能够同时处理数千个连接。它不会为一个连接等待，而是当某个连接有"事件"（比如数据可读了）时才去处理它。这就像餐厅经理同时监听很多张桌子的呼叫铃，而不是一直站在一张桌子前等待。
\n
结果：Nginx可以用很少的系统资源（CPU和内存）处理海量的并发连接。这是它能成为当今互联网顶流的核心原因。
\n这是Nginx最常用的场景之一。
\n负载均衡：当你的网站流量很大时，一台服务器肯定不够。你会有多台应用服务器。Nginx可以站在它们前面，像交通警察一样，把用户的请求按照一定策略（轮询、权重、最少连接等）分发给这些服务器，防止任何一台服务器过载。
\nnginx
\n# 示例配置：定义一个名为 \"myapp\" 的后端服务器组\nupstream myapp {\n server 192.168.1.10:8080 weight=3; # 这台机器性能好，给它3个权重\n server 192.168.1.11:8080; # 这台性能一般，默认权重1\n}\n\nserver {\n listen 80;\n location / {\n proxy_pass http://myapp; # 将所有请求转发给 myapp 组\n }\n}Nginx处理静态文件（图片、CSS、JavaScript、HTML）的能力极强。通常，我们会让Nginx直接处理这些请求，而将动态请求（需要程序处理的）转发给后端的应用服务器（如Tomcat, Django, Node.js）。这种"动静分离"的策略极大地提升了网站的整体性能。
\n当你的网站使用HTTPS时，需要进行加密和解密操作，这很消耗CPU。Nginx可以承担这个工作，它负责与客户端完成SSL握手和解密，然后将明文的请求转发给后端服务器。这样后端服务器就不用操心加密的事了，可以专注于业务逻辑。
\nNginx可以缓存从后端应用服务器返回的响应。如果下一个用户请求相同的资源，Nginx可以直接从缓存里返回，而不用再去麻烦后端服务器。这极大地减少了响应时间和后端压力。
\nNginx以稳定著称，可以7x24小时不间断运行。即使后端某个应用服务器宕机了，Nginx也能检测到并将其从负载均衡组中移除，保证大部分用户不受影响。
\n假设你访问 https://www.example.com/shop/product/123
你的浏览器向 www.example.com 的443端口（HTTPS）发起请求。
请求到达托管 example.com 的服务器，Nginx正在监听443端口。
Nginx接收到请求，首先完成SSL握手。
\nNginx查看请求的路径 /shop/product/123。
根据预设的规则（location 指令），Nginx判断这是一个动态请求，需要由后端的Java应用处理。
nginx
\nserver {\n listen 443 ssl;\n server_name www.example.com;\n # ... SSL配置 ...\n\n location /static/ { # 静态文件直接由Nginx处理\n root /var/www/html;\n }\n\n location /shop/ { # 动态请求转发给后端\n proxy_pass http://backend_java_app;\n }\n}Nginx将请求转发给 backend_java_app 定义的一组Java应用服务器中的一台。
Java服务器处理请求，从数据库查出产品123的信息，生成HTML页面，返回给Nginx。
\nNginx将这个响应返回给你的浏览器。
\n浏览器解析HTML，发现里面还有CSS和图片链接（如 /static/css/style.css），于是又向同一个Nginx发起新的请求。
这次，Nginx看到是 /static/ 路径，直接从服务器的硬盘上读取 style.css 文件，并以极快的速度发送给浏览器。
这是一个经典的对比，能帮你更好地理解Nginx的定位：
\n| 特性 | \nNginx | \nApache | \n
|---|---|---|
| 架构模型 | \n事件驱动，异步非阻塞 | \n进程/线程驱动（传统模式），一个连接一个进程 | \n
| 资源消耗 | \n低，尤其在高并发下 | \n高，并发连接数增多时资源消耗剧增 | \n
| 静态内容 | \n性能极高 | \n性能很好 | \n
| 动态内容 | \n通常需要转发给后端处理器（如PHP-FPM） | \n可以通过模块（如mod_php）在内部直接处理 | \n
| 配置语法 | \n简洁、直观 | \n更灵活、功能强大，但也更复杂 | \n
| 主要用途 | \n反向代理、负载均衡、静态服务 | \n传统的全能Web服务器，特别适合共享主机 | \n
简单总结：Nginx更擅长处理高并发连接和充当"交通指挥"，而Apache传统上更擅长在单个服务器内深度处理动态请求。现代架构中，它们常常协同工作：Nginx在前端做反向代理和静态处理，Apache在后端处理动态内容。
\n", "tags": [ "Nginx", "Web 服务器", "反向代理" ] } ] }