电池电量检测系统实战：ADC采样、分压电路与容量校准全解析
2026/9/11 21:46:32
先直接说结论：应用层协议这块，是计算机网络里“性价比”最高的一部分。你如果正在准备期末考试、考研408、或者刚入职写接口，把序列化与反序列化、HTTP、HTTPS这三件事串起来吃透，后面再看什么RPC框架、微服务通信、Web安全，都会顺很多。这篇文章不按教材目录平铺，而是按我实际接触项目时的顺序，从“两个程序怎么说话”开始，讲到HTTP报文结构，再拆HTTPS的加密原理，最后说几个高频排错和考试/面试速查点，尽量让你看完就能用上。
1. 序列化与反序列化：数据必须变成“网上能传的样子”
计算机网络的目标很简单，就是让一台机器上的数据能被另一台机器正确理解。但这里有个很现实的问题：程序在内存里的对象、结构体，都是“活”的，有指针、有类型、有嵌套关系。你要是直接把这块内存原封不动丢到网线上，对面机器收到的只是一堆没有任何边界的二进制流，根本不知道哪里是头、哪里是尾，更不明白每个字段到底该按什么类型解释。所以，在此之前必须先做序列化。
1.1 为什么需要序列化：一份快递的打包与拆包
序列化的本质，就是把内存对象变成可存储、可传输的字节序列；反序列化则是逆过程，把收到的字节重新还原成程序能用的对象。我一般喜欢拿寄快递类比：你内存里有一套完整的家当（对象），快递公司不可能把一个沙发原样塞进货车，你得先拆开、压缩、装箱（序列化），到了目的地再拆箱、组装（反序列化）。网络传输也一样，TCP只负责可靠地搬运字节流，至于字节流怎么组织、怎么解释，是应用层协议的事，而序列化就是“约定好的装箱方案”。
如果两台不同的程序，一个用C++，一个用Java，数据结构定义不一样、字节序不一样、整型长度不一样，那传输时必须有一套两边都认可的中间格式。这就是为什么我们通常不会直接把结构体指针塞进Socket发送，而是先转成JSON字符串、XML字符串，或者更紧凑的二进制格式。一句话：序列化方案决定了双方能“听懂”什么，也决定了传输效率和兼容性。
1.2 主流序列化方案怎么选：JSON、XML、Protobuf对比
选序列化方案，本质上是在几个维度上做权衡：人能不能看懂、体积大不大、解析快不快、跨语言强不强、版本升级好不好兼容。
| 方案 | 可读性 | 体积 | 解析性能 | 跨语言 | 典型场景 |
|---|---|---|---|---|---|
| JSON | 好，肉眼可读 | 较大，有大量冗余键名 | 中上，取决于库 | 极好 | Web API、配置文件、调试首选 |
| XML | 较差，标签冗余 | 大 | 较慢 | 很好 | 老旧系统、部分企业接口、配置文件 |
| Protobuf | 差，二进制不可读 | 很小 | 极快 | 好，需要生成对应代码 | 高并发RPC、微服务内部通信 |
| MessagePack | 一般 | 较小 | 较快 | 较好 | 需要比JSON省流量、又不想上Protobuf的场景 |
我在实际工程里有个经验：对外接口、前后端联调、日志打印，首选JSON，因为可读性就是生产力，出了问题打开抓包工具一眼能看出字段对不对。对内、对高吞吐的服务间通信，再考虑Protobuf这类二进制方案，它能省不少带宽和CPU。
这里要提醒一句：JSON虽然“看起来”哪都能用，但解析JSON本身消耗不小。在嵌入式设备上做JSON解析尤其痛苦，比如STM32这类MCU上跑HTTP接口，我见过不少人在内存只有几十KB的单片机上硬搓cJSON，最后不是堆溢出就是解析卡顿。这种场景反而要考虑极简的键值对格式或者Protobuf-lite。
1.3 手写一条“自定义协议”：从Socket收到的到底怎么切
光说理论不过瘾，我不止一次被问到：既然序列化之后是一堆字节，那我用Socket发过去，接收方怎么知道一条“消息”在哪结束？这里就带出应用层协议设计的关键问题——消息边界。
TCP是流式协议，它不会自动帮你划分消息。你send了两次4字节，接收方可能一次recv就收到8字节，也可能分了三次收到。这就叫粘包/拆包。解决办法通常是两条路：
- 固定长度：每条消息定长，比如都按1024字节对齐，不够就补空字符。简单粗暴，但浪费带宽，适合字段结构极其固定的场景。
- 长度前缀：先传4字节表示消息体长度，再传消息体。接收方先读4字节，再按长度读后面的数据。这是最常用的方案之一。
- 特殊分隔符：像HTTP那样，用空行或指定字符分隔。HTTP靠“空行区分Header和Body”，而Body长度由
Content-Length头决定，其实还是“长度前缀”的思路。
下面给一个极简的Python TCP演示，展示如何用“4字节长度前缀 + JSON内容”组织一条应用层消息。
import socket import json import struct def pack_message(obj: dict) -> bytes: body = json.dumps(obj).encode("utf-8") # 4字节无符号整型做长度前缀 header = struct.pack("!I", len(body)) return header + body def unpack_message(sock: socket.socket) -> dict: # 先读4字节头 header = recv_exact(sock, 4) (body_len,) = struct.unpack("!I", header) body = recv_exact(sock, body_len) return json.loads(body.decode("utf-8")) def recv_exact(sock: socket.socket, n: int) -> bytes: buf = b"" while len(buf) < n: chunk = sock.recv(n - len(buf)) if not chunk: raise ConnectionError("连接被断开") buf += chunk return buf这段代码在真实的网络编程里有三个细节，很多人容易踩坑：
- recv不保证一次收满，必须循环读，直到读够指定长度。上面
recv_exact就是这个作用。 - 使用大端序
!I，保证不同字节序的机器解析长度字段结果一致。你要是用struct.pack("I")，在某些小端机器上收到的长度值可能完全对不上。 - JSON里不能出现超大数字时用字符串，否则跨语言解析会丢精度，尤其Java和JavaScript的Number处理差异很大。
2. HTTP协议拆解：互联网上最通用的“对话模板”
聊完序列化，接下来进入HTTP。可以说HTTP是应用层协议里面应用最广泛、面试提问密度最高的一个。你写网页、调接口、刷手机App，背后全是HTTP，它本质上是“浏览器/客户端”和“服务器”之间约定好的一套问答格式。
2.1 HTTP报文到底长什么样：把一次请求拆开看
HTTP报文分请求报文和响应报文。请求报文由四部分组成：请求行、请求头、空行、请求体。响应报文则对应为：状态行、响应头、空行、响应体。注意那个空行，它特别关键，是Header和Body的分界线，也回答了前面说的消息边界问题——Header结束的标准就是遇到一个空行。
拿一次最普通的“打开网页”举例，客户端实际上发出去的内容大致是这样：
GET /index.html HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html Connection: keep-alive服务器返回：
HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 1234 Date: Wed, 05 Mar 2025 08:00:00 GMT <!DOCTYPE html> <html>...请求行里的GET是方法，/index.html是URI，HTTP/1.1是版本。响应行里的200是状态码，OK是短语说明。这个结构看起来很简单，但所有复杂能力，比如缓存、会话、长连接、断点续传，都是在这些Header字段上长出来的。
第一次学的时候，我建议你打开浏览器的开发者工具（F12），切到Network标签页刷新任意网页，随便点一个请求看它的“请求头”和“响应头”。这一步比盯着教科书背三天都管用，看完你会对报文结构有肌肉记忆。
2.2 请求方法与状态码：不是为了背，而是为了理解语义
HTTP方法很多，实际开发和考试里高频的是GET、POST、PUT、DELETE、HEAD、OPTIONS。学它们时最重要的是理解两个概念：安全性和幂等性。
- 安全性：这个请求会不会改变服务器资源状态。GET、HEAD、OPTIONS是安全的，因为它们只是查询。
- 幂等性：同一个请求执行一次和执行多次，结果一样。GET、PUT、DELETE是幂等的，POST不是。
我见过不少刚写后端的人误把“增删改查”做成四个POST，这在功能上没问题，但接口语义就会很混乱。比如DELETE重复调用两次，第一次成功、第二次返回404，服务端如果处理成“只要资源不存在就算成功”，那接口就是幂等的。清理用户的重复提交、重试机制，很大程度上依赖你把这些语义设计对了。
状态码方面，不用背全部，但必须能快速归类：
| 分类 | 范围 | 含义 | 常考例子 |
|---|---|---|---|
| 1xx | 100-199 | 信息性响应 | 100 Continue |
| 2xx | 200-299 | 成功 | 200 OK、204 No Content |
| 3xx | 300-399 | 重定向 | 301永久、302临时、304 Not Modified |
| 4xx | 400-499 | 客户端错误 | 400参数错、401未认证、403禁止、404不存在 |
| 5xx | 500-599 | 服务端错误 | 500内部错、502网关错、503服务不可用、504超时 |
为什么强调3xx？因为304在浏览器缓存里天天出现。你访问一个静态资源，服务器返回304表示“客户端缓存的版本还能用”，浏览器就直接用本地缓存，不重新下载。这对性能优化意义很大，后面排查慢请求时也常看到它的身影。
2.3 Header、Cookie、Session：无状态协议怎么记住“曾经来过”
HTTP本身是无状态的，也就是说服务器默认不记得你上一次请求是谁。但现代业务几乎全都要状态：购物车、登录态、个性化推荐。于是就有了Cookie、Session、Token这类补丁机制。
流程是这样的：你第一次登录后，服务器创建一个Session，把Session ID写到响应头的Set-Cookie里；浏览器收到后把Cookie存起来，之后每次请求都自动带上Cookie: sessionid=xxx。服务器看到这个ID，就知道对应哪个用户的会话了。
我当年做实验踩过一个坑：后端把Session存内存里，结果服务一重启所有人的登录态全失效了。后来改成把会话数据放Redis，才解决多实例共享问题。这个场景在分布式环境下尤其明显，单个服务器能靠“内存Session”撑住，服务一多就必须要集中式会话存储。
还有个高频面试点要厘清：Cookie和Session是不同层面的东西。Cookie是浏览器端存储，Session是服务器端存储，Cookie只是Session常用的一种传递手段。现在前端项目更喜欢用Token（比如JWT）无状态化，但核心思路和Session一样：让服务器识别“你是谁、你有什么权限”。
2.4 连接管理：从短连接到HTTP长连接、连接复用
早期HTTP/1.0时代，每次请求都要重新建立一条TCP连接，请求完立刻断开。网页上几十个资源就要反复握手挥手，性能非常差。后来HTTP/1.1引入Connection: keep-alive，默认支持长连接，同一个TCP连接上可以连续发送多个请求，避免反复建连的开销。这个点对应后端常说的“连接复用”，在压测和调优时特别重要。
但HTTP/1.1的长连接有一个“队头阻塞”问题：同一连接上，前面请求的响应没回来，后面的请求就得排队等。HTTP/2用“多路复用”解决了一部分问题——一个连接上可以同时跑多个请求，每个请求有独立的流ID。HTTP/3更进一步，把底层从TCP换成了基于UDP的QUIC，减少连接建立和丢包重传带来的延迟。
日常开发里，你在Nginx、后端框架里看到的keep-alive配置就是在管理这条长连接。设计时要注意一个平衡：连接空闲太短，频繁建连浪费；空闲太长，占用服务器文件描述符和内存。常规做法是设一个空闲超时，比如60秒到120秒之间。
2.5 请求体Content-Type和序列化的“接头暗号”
HTTP能承载的数据类型非常丰富，靠的是Content-Type字段。你POST一个JSON给后端，请求头里必须写明Content-Type: application/json；如果传表单，则是application/x-www-form-urlencoded；上传文件常用multipart/form-data。
这就和第一节的序列化机制接上了：HTTP本身不关心你的Body是JSON还是XML，它只负责用Header告诉对端“这堆字节应该按什么格式去反序列化”。所以HTTP可以看作一个通用容器，你可以把JSON、XML、Protobuf字节流全部塞进Body传输。两边只要Content-Type匹配、反序列化器一致，就能正常通信。
做后端接口时，最常见的报错就是“解析请求体失败”，十有八九是客户端发的Content-Type和服务端期望的不一致。我调试这类问题一般先看一眼请求头，再确认后端读取Body的方式，基本几秒就能定位。
3. HTTPS：给HTTP加三道锁
HTTP虽然好用，但它本身是明文传输。数据经过的每一个路由器、运营商、Wi-Fi热点都可能完整看到你发的字节。你能想象登录时把密码明文发出去吗？所以必须加密，这就是HTTPS存在的意义。HTTP + TLS，才是HTTPS。
3.1 明文HTTP的三宗罪
- 窃听：传输内容能被中间节点直接读到，账号密码、聊天记录、信用卡号全部裸奔。
- 篡改：中间人不仅能看，还能改。比如篡改网页内容插广告、把下载链接替换成病毒包。
- 冒充：你访问了
bank.com，但实际上连的可能是攻击者搭的假站点。没有身份验证时，用户没法确认服务器的真实身份。
这三点对应了密码学里的机密性、完整性、身份认证。HTTPS本质上就是同时解决这三个问题的产品。
3.2 密码学三兄弟：对称加密、非对称加密、哈希摘要
讲HTTPS前，这三个概念必须分清，否则后面的流程看不懂：
- 对称加密：加密解密用同一个密钥。快，适合加密大量数据，比如AES。问题是密钥怎么安全地传给对方？如果密钥也要走明文网络，等于白加密。
- 非对称加密：一对密钥，公钥加密、私钥解密，或反过来，比如RSA、ECC。公钥可以公开分发，私钥只有自己持有，天然解决了密钥交换问题。但性能远不如对称加密。
- 哈希摘要：把任意长度数据算成固定长度摘要，比如SHA-256。不可逆，用来做完整性校验——数据一旦被改动，摘要立刻对不上。
HTTPS的策略很巧妙：用非对称加密安全地协商出一个对称密钥，然后用对称密钥加密后续所有传输内容。这样就兼顾了安全性和性能。
3.3 HTTPS握手：一次完整的“加密协商”过程
用最简单的话描述一次HTTPS请求的核心过程：
- 客户端发起握手，告诉服务器它支持的TLS版本和加密套件列表。
- 服务器从列表里选一个方案，同时返回自己的证书（证书里包含服务器公钥和身份信息）。
- 客户端验证证书是否可信。没问题就用这个公钥加密一个“预备主密钥”发给服务器。
- 服务器用私钥解密，拿到预备主密钥。双方用它各自计算出相同的对称会话密钥。
- 之后所有HTTP数据都用这个对称密钥加密传输。
这中间，第3步的“验证证书可信”是整个HTTPS信任链条的根基。如果证书验证能绕过，中间的加密形同虚设。
我在调试过程中常看到有人在代码里写“信任所有证书”，这能解决本地自签名证书的报错，但一旦放到生产环境又忘了改回来，等于直接删掉了HTTPS的防护。这个坑特别危险，一定要在内心给自己画条红线：本地调试可以临时跳过证书校验，线上绝对不能。
3.4 数字证书与CA信任链：谁来证明“我是我”
刚才提到了证书。证书不是服务器自己说了算，而是由第三方机构（CA，证书颁发机构）来签发。CA的职责是核实申请者的身份，然后用自己手里的CA私钥对“域名 + 服务器公钥 + 有效期”等信息做签名。
客户端验证证书的过程，本质是验证“签名是否来自可信CA”。你的电脑、手机里内置了一批根证书，这些根证书来自全球公认的CA机构。如果服务器证书的签发者能一路追溯到某个根证书，浏览器就认为可信。这个过程叫信任链校验。
这也是为什么自签名证书会被浏览器警告：因为它不在系统信任列表里，没有CA帮你背书。解决方案有两种：要么在系统里手动安装这个证书并信任它（内网测试常用），要么就用正规CA签发的证书。很多开源项目提供的mkcert工具就是帮你本机生成一个被当前设备信任的CA和证书，实测下来非常方便。
为什么抓包工具能看到HTTPS明文？这也是初学者问得最多的一个问题。Fiddler、Charles这些工具的原理并不是“破解”了加密，而是做了中间人：它向客户端出示一个自己生成的证书，客户端（如果信任了它的根证书）会认为这个连接是安全的，于是用那个证书的公钥加密数据；同时抓包工具又作为“客户端”去和真正的服务器建立另一个HTTPS连接。这样抓包工具就在中间同时拥有两条连接的解密能力，能明文看到所有流量。它和恶意中间人攻击的区别在于：你主动选择信任了抓包工具的根证书。所以“信任根证书”这个操作，从来不是小事。
3.5 HTTP和HTTPS的区别，一张表讲透
| 项目 | HTTP | HTTPS |
|---|---|---|
| 协议组成 | HTTP | HTTP + TLS |
| 默认端口 | 80 | 443 |
| 加密 | 无，明文 | 对称加密传数据，非对称加密协商密钥 |
| 身份认证 | 无 | 依赖CA证书链验证服务器身份 |
| 数据完整性 | 无法保证 | TLS握手和传输层自带完整性校验 |
| 性能 | 快 | 略有握手开销，现代硬件下可忽略 |
| SEO与浏览器提示 | 常被标记“不安全” | 正常展示锁标识 |
实际部署HTTPS时，除了申请证书，还要配HTTP自动跳转到HTTPS，把80端口请求301到443，否则用户习惯性敲网址还是会走明文。另外，只要支持TLS 1.2以上的版本就足够安全，旧版本最好直接禁用。
4. 协议知识怎么落地：抓包、排错与复习速查
学协议最忌讳的是只背概念、不动手。我强烈建议你有空做一次抓包实验，哪怕只是看几个请求，理解程度都会不一样。
4.1 一次抓包实验，把HTTP和HTTPS“看”明白
工具直接用Wireshark或者浏览器F12都行。拿F12举例：打开任意网页，刷新，点开一个请求，你能同时在Headers里看到请求URL、请求方法、状态码、请求头、响应头，在Payload里看到请求参数。
我建议你做一个对照实验：分别访问一个HTTP站点和一个HTTPS站点，抓包对比看载荷内容。HTTP站点能看到请求头里的明文Cookie、请求参数，而HTTPS站点在Wireshark里如果不做解密配置，看到的全是加密后的乱码。只做这一步，你就能直观理解“明文”和“加密”的差别有多大。
如果要用Wireshark解密HTTPS流量，可以在环境变量里配置SSLKEYLOGFILE，让浏览器导出会话密钥，然后让Wireshark加载这个文件。这个方法在调试TLS握手问题时非常好用，但记得调试完就关掉日志，避免密钥泄露。
4.2 高频状态码排错实录
日常开发和排查问题的时候，状态码是最直接的线索。我整理了高频的几个，以及对应的排查思路：
- 400 Bad Request：请求语法有问题。先看请求体是不是JSON格式错误、Content-Type是否匹配、参数类型是否对。
- 401 Unauthorized：没带认证信息或认证信息错误。登录态失效、Token过期也是这个。
- 403 Forbidden：服务器认出了你，但不让你访问。权限不足，或者IP/UA被拒绝了。
- 404 Not Found：路径不存在。最常检查的是URL拼写、路由前缀、Controller映射。
- 405 Method Not Allowed：方法不对。比如只支持POST的接口你用了GET。
- 500 Internal Server Error：服务内部异常。去看后端日志。
- 502 Bad Gateway：网关或代理拿不到上游的有效响应。常见是后端服务挂了、没启动、或响应超时。
- 504 Gateway Timeout：上游处理太久，网关等不住了。排查慢SQL、死循环、下游依赖是否超时——这些都必须看日志才能定位。
整个排查思路就一句话：先分清是客户端的问题还是服务端的问题，再按层次从请求头、参数、路由、到服务端日志逐层往下看。
4.3 期末/考研408应用层高频考点速查
考虑到这可能是很多人的复习材料，最后整理一份速查表：
| 考点 | 核心内容 |
|---|---|
| 应用层的作用 | 为应用程序提供网络服务，定义报文格式和语义 |
| 序列化本质 | 对象与字节流的互相转换，解决异构系统和网络传输问题 |
| 常见序列化格式 | JSON、XML、Protobuf，对比可读性、体积、性能 |
| HTTP报文结构 | 请求行/状态行 + 头部 + 空行 + 实体 |
| GET vs POST | 语义差异、安全性、幂等性、可缓存性 |
| 状态码分类 | 2xx成功、3xx重定向、4xx客户端错、5xx服务端错 |
| Cookie与Session | 无状态协议的状态管理、分布式会话问题 |
| HTTP长连接 | keep-alive、连接复用、队头阻塞 |
| HTTPS原理 | 对称加密+非对称加密+证书链，握手流程 |
| HTTP与HTTPS区别 | 端口、加密、身份认证、完整性、性能 |
这里再补充一个常见笔试题：为什么HTTPS比HTTP多了证书校验这一步？因为它不仅要保证传输内容不被偷看，还要保证你通信的对端没有被冒充。如果只做加密不做认证，攻击者完全可以把自己伪装成真的服务器，和你完成“加密通信”并把数据原样转发给真正的服务器，从中读取一切内容——这就是典型的中继型中间人攻击。
在我个人经验里，应用层协议最值得花时间的地方，反而不是死记格式，而是抓住“协议 = 约定 + 边界”这个本质。HTTP靠空行和Content-Length划边界，WebSocket靠帧头划边界，自定义TCP协议靠长度前缀划边界。你只要理解了通信双方在边界和语义上达成一致这件事，再看到任何应用层协议，都能快速抓住它要解决的问题。最后一个建议：学完这部分，别急着合上书，打开Wireshark抓一次自己的流量，看到HTTP和HTTPS的差别，你就真正入门了。