IT | 词汇科普手册Ⅱ
目录
1.报文(Message)
2.Token(令牌)
Token vs. Cookie
Token vs. Key
"碰一碰"支付
3.NFC
4.Nginx
5.JSON
6.前置机
前置机vs.Nginx反向代理
以PDA、WMS举例前置机场景
7.RabbitMQ
核心功能
1.报文(Message)
报文（Message）是系统或组件之间交换的数据单元，通常遵循特定的格式和协议。
报文是网络中传输的数据块，包含控制信息（如协议头）和有效载荷（实际数据）。
常见类型：
- 请求报文：客户端向服务器发送的请求（如HTTP请求）。
- 响应报文：服务器返回的应答（如HTTP响应）。
- 协议报文：如TCP/IP协议中的数据包、DNS查询报文等。
报文的核心作用
- 标准化通信：确保发送方和接收方能正确解析数据。
- 可靠性：通过状态码、校验和等机制保证数据完整性。
- 效率：分块传输、压缩等优化手段（如HTTP的
Transfer-Encoding: chunked）。
2.Token(令牌)
Token vs. Cookie
| 特性 | Token | Cookie |
|---|---|---|
| 本质 | 一段签名的数据（如*JWT），包含用户信息。 *JSON Web Token | 由服务器通过HTTP头（Set-Cookie）发送到浏览器的小型文本文件。 |
| 存储位置 | 客户端自由存储（LocalStorage、内存等）。 | 由浏览器自动管理，存储在用户设备中。 |
| 依赖关系 | 无状态（不依赖浏览器或HTTP协议）。 | 依赖浏览器和HTTP协议（需自动携带Cookie头）。 |
| 代码示例 |  |  |
-
用Token：需要跨域、无状态、移动端支持，或API优先架构。
-
用Cookie：依赖浏览器会话、简化开发（如传统Web应用）。
典型使用场景
Token：
- 前后端分离架构（如React/Vue + API）。
- 移动端APP与后端通信。
- 第三方API授权（OAuth 2.0）。
Cookie：
- 传统服务端渲染（如PHP、Ruby on Rails）。
- 需要浏览器自动管理会话的场景（如电商网站登录）。
关键区别：
| 对比维度 | Token | Cookie |
|---|---|---|
| 跨域支持 | 天然支持跨域（CORS配置即可）。 | 受同源策略限制（需配置SameSite、Domain等属性）。 |
| 安全性 | 更安全（可防CSRF，需防XSS）。 | 需防范CSRF（如加SameSite、Token双重验证）。 |
| 移动端/API友好性 | 适合移动端和非浏览器场景（如APP）。 | 主要针对浏览器场景。 |
| 存储控制 | 客户端完全控制存储方式。 | 由浏览器自动管理，无法直接控制过期时间（需服务器设置）。 |
| 状态管理 | 无状态（Token自包含用户信息）。 | 通常需服务器维护会话状态（如Session ID）。 |
Token vs. Key
| 对比项 | Token（令牌） | Key（密钥/钥匙） |
|---|---|---|
| 主要用途 | 临时身份凭证（如登录后的通行证）。 | 更通用，可能是加密密钥、API密钥、密码等。 |
| 时效性 | 通常有过期时间（如JWT 24小时后失效）。 | 可能长期有效（如SSH密钥）。 |
| 安全性 | 可被设计为一次性或短期有效。 | 长期密钥泄露风险更高（如密码明文存储）。 |
| 技术实现 | 往往包含用户信息（如JWT）。 | 可能只是一串随机字符（如API Key）。 |
"碰一碰"支付
“碰一碰”支付（如NFC或二维码）的核心是 动态令牌（Token），流程类似：
-
生成临时Token：
支付宝APP生成一个限时有效的加密Token（如一次性的付款码或NFC信号），包含你的身份和交易信息。
（这就像游乐园手环，但每次支付换一个新“手环”）。 -
近场传输：
通过NFC或二维码将Token传递给收款设备（如POS机）。 -
服务器验证：
收款设备将Token传给支付宝服务器，服务器解密后确认交易合法性，完成扣款。
3.NFC
NFC（Near Field Communication，近场通信） 是一种让两台设备在极短距离内（通常3-5厘米）快速无线传输数据的技术。（vs.纯天然果汁NFC（Not From Concentrate）“非浓缩还原”）
技术原理（简化版）
- 电磁感应：读卡器（如POS机）产生磁场，给NFC标签（如公交卡）供电并通信。
- 被动模式：卡片无需电池（像“电子标签”）。
- 主动模式：两部手机互相通信（如Android Beam）。
| 场景 | 怎么用NFC？ |
|---|---|
| 支付宝/微信“碰一碰”支付 | 手机贴近POS机，“嘀”一声完成付款。 |
| 公交卡/地铁卡 | 手机或卡片靠近闸机，直接刷卡通行。 |
| 门禁卡/电子钥匙 | 手机模拟门禁卡，贴一下就能开门。 |
| 文件传输 | 两部手机背对背一碰传照片（如安卓Beam）。 |
- 距离极短：小偷没法隔空偷信号（不像Wi-Fi/蓝牙可能被远程拦截）。
- 动态加密：比如支付时生成的Token每次不同，截获了也无法复用。
- 需手动触发：必须主动贴近，避免误操作。
| 特性 | NFC | 蓝牙/Wi-Fi |
|---|---|---|
| 距离 | 3-5厘米（防偷窥）。 | 几米到几十米（可能被远程攻击）。 |
| 速度 | 慢（适合小数据）。 | 快（适合传大文件）。 |
| 配对 | 不用配对，一碰即连。 | 需手动配对或输入密码。 |
| 耗电 | 几乎不耗电。 | 耗电较高。 |
4.Nginx
Nginx（发音为“engine X”）是一款高性能的开源Web服务器，同时也可作为反向代理、负载均衡器和HTTP缓存使用。
| 优势 | 说明 |
|---|---|
| 高性能 | 占用内存少，能同时处理10万+并发连接（比传统服务器如Apache更高效）。 |
| 反向代理 | 隐藏真实服务器，提升安全性（像“中介”帮你转发请求）。 |
| 负载均衡 | 把用户请求分发给多台服务器，避免某一台崩溃（像餐厅多个厨师分担压力）。 |
| 热部署 | 更新配置无需重启服务，业务不中断。 |
5.JSON
JSON（JavaScript Object Notation） 是一种轻量级的数据交换格式，用来在不同系统之间传递和存储数据。它的核心特点是易读、易写、易解析。
本质：一种纯文本的“数据描述语言”，用简单的键值对（key: value）来组织数据。
设计初衷：替代复杂的XML，让数据更简洁、更适合网络传输。
常见用途：
- 前后端API通信（比如前端从后端获取用户数据）。
- 配置文件（比如VSCode的设置文件
.json）。 - 存储简单数据库（如NoSQL数据库MongoDB）。
JSON就是“数据界的普通话”，用简单的文本描述结构化数据，让不同系统能轻松互相理解。
（如果你网购时看到“加载中…”，大概率是前端正在解析后端发来的JSON数据 📦）
6.前置机
前置机是IT系统中一种常见的中间层设备或服务，主要用于隔离、转发、预处理客户端与后端核心系统之间的数据交互。
角色定位：像银行柜台前的“大堂经理”
- 客户（外部请求）不直接接触柜员（核心系统），先由大堂经理（前置机）核对需求、分流任务。
- 核心作用：保护核心系统 + 提高效率。
应用场景：
| 场景 | 前置机的作用 | 举例 |
|---|---|---|
| 金融支付系统 | 接收POS机/扫码支付请求，验签后转发给银行核心系统。 | 超市刷卡时，交易先经过银联前置机。 |
| 医院信息系统（HIS） | 对接医保平台，预处理医保结算数据。 | 患者医保报销时，数据先通过医院前置机审核。 |
| 政务系统 | 隔离外部互联网和内部政务网，过滤非法请求。 | 市民网上办事，请求先到政务前置机安全检查。 |
前置机vs.Nginx反向代理
| 对比项 | 前置机 | Nginx反向代理 |
|---|---|---|
| 定位 | 业务逻辑处理（如加密、报文转换）。 | 单纯流量转发和负载均衡。 |
| 部署位置 | 更靠近核心系统（内网）。 | 通常部署在DMZ区（内外网交界）。 |
| 复杂度 | 需定制开发业务逻辑。 | 通用配置，开箱即用。 |
以PDA、WMS举例前置机场景
7.RabbitMQ
RabbitMQ 是一款开源的消息队列（Message Queue）中间件，用最直白的比喻来说，它就像现实世界中的“快递站”，专门解决不同系统或服务之间的异步通信和数据传递问题。
核心功能
-
接收、存储、转发消息：
比如系统A需要通知系统B处理任务，但B暂时忙不过来，RabbitMQ会暂存消息，等B准备好再递送。
类比：快递站代收包裹，等你有空时再派送给你。 -
解耦系统：
发送方（生产者）和接收方（消费者）无需知道对方的存在，通过RabbitMQ间接通信。
类比：你网购时，卖家（生产者）和快递公司（RabbitMQ）打交道，你（消费者）只和快递员沟通。
