玳瑁的嵌入式日记D32-0903（网络编程）
1. 关于 C/S 模型
- 客户端专用性：C/S 架构里的客户端是专用程序，是为特定服务定制的。就像游戏客户端，不同游戏有各自专属的客户端，只为对应游戏服务。而且这些客户端需要单独安装在用户设备上，像安装 QQ 客户端一样，安装过程需要用户操作，后续更新也得用户主动或由程序提示进行，维护成本相对高。
- 协议多样性：除了能使用 HTTP 协议，还能采用自定义协议或者其他标准协议。比如一些企业内部的管理系统，为了满足特定的数据传输和业务逻辑需求，会使用自定义协议，这样能更灵活地控制数据交互的格式和流程；而像一些基于标准通信规范的系统，会使用标准协议来保证不同模块间的兼容性。
- 资源与功能：资源大多存储在客户端本地，这使得客户端能在一定程度上离线使用部分功能。比如某些单机游戏客户端，下载好游戏资源后，不联网也能进行游戏（当然联网功能会受限）。同时，因为客户端可以直接操作本地资源，所以能实现更复杂的功能，像专业的图像编辑软件客户端，能进行大量复杂的图像渲染、特效制作等操作。
2. 关于 B/S 模型
- 客户端通用性：客户端是通用的浏览器，不需要用户专门安装特定程序。用户只要有浏览器，就能访问各种基于 B/S 架构的网站，像购物网站、新闻网站等，使用门槛低。
- 协议单一性：主要使用 HTTP 协议（包括 HTTPS）。HTTP 协议是互联网上应用最广泛的协议之一，具有良好的通用性和规范性，这使得不同的浏览器和服务器之间能方便地进行通信，保证了 Web 应用的广泛兼容性。
- 资源与功能：资源存储在服务器端，客户端通过网络从服务器获取资源并展示。这意味着客户端对资源没有本地存储的依赖，但也受限于网络连接，没有网络就无法获取资源。由于受 HTTP 协议等 Web 技术的限制，功能相对 C/S 模型来说没那么复杂，更适合展示类、信息查询类等相对轻量的应用，像网页版的文档查看工具，功能就比较简洁
| 对比维度 | 服务器 / 客户端（C/S）模型 | 浏览器 / 服务器（B/S）模型 |
|---|---|---|
| 客户端形态 | 专用软件（APP、桌面程序）或浏览器 | 仅需浏览器（Chrome、Safari 等） |
| 部署与维护 | 客户端需安装、更新，维护成本高 | 无客户端部署，仅需更新服务器，维护成本低 |
| 跨平台兼容性 | 差（需适配 Windows/macOS/Android 等） | 好（浏览器跨平台，无需开发多版本） |
| 性能与交互性 | 高（直接通信，支持复杂交互如游戏、绘图） | 中等（依赖浏览器，复杂交互需插件） |
| 适用场景 | 企业应用、在线游戏、专用工具 | 互联网网站、轻量应用（如博客、电商） |
3. 关于 P2P（对等网络）
在 P2P 网络中，没有严格的服务器和客户端之分，每个参与的节点（Peer）既是资源的提供者，也是资源的获取者。比如常见的文件共享 P2P 网络，每个用户的设备既可以把自己的文件分享给其他用户下载，也可以从其他用户那里下载文件，节点之间直接进行通信和资源交换，不需要通过中心服务器来中转所有的资源请求和传输，这种模式在文件共享、分布式计算等场景中有广泛应用。
TCP（Transmission Control Protocol，传输控制协议）是互联网协议族（TCP/IP）中的传输层协议，主要负责在网络中为应用程序提供可靠的、面向连接的数据传输服务。以下从多个方面对它进行介绍：
1. 基本特点
- 面向连接：在数据传输之前，发送方和接收方需要通过三次握手（Three - way Handshake）建立连接。//以用户在浏览器访问网页为例，首先客户端向服务器发送一个带有 SYN（同步序列号）标志的数据包，表示想要建立连接；服务器收到后，会回复一个带有 SYN + ACK（确认应答）标志的数据包，确认收到请求并同意连接；最后客户端再发送一个带有 ACK 标志的数据包，完成连接建立。这样的连接建立过程确保了双方都准备好进行数据传输。
- 可靠传输：TCP 采用了多种机制来保证数据可靠传输。发送方会对每个发送的数据段进行编号，接收方收到数据段后，会向发送方发送确认信息（ACK）。如果发送方在一定时间内没有收到确认，就会重传该数据段。此外，TCP 还会对收到的数据进行排序，确保数据按照正确的顺序交付给应用层。
- 流量控制：接收方会根据自己的接收能力，通过窗口机制通知发送方自己能够接收的数据量。例如，接收方处理数据的速度较慢，它就会减小通知发送方的窗口大小，让发送方减少数据发送量，避免数据积压导致丢失。
- 拥塞控制：当网络出现拥塞时，TCP 会自动调整发送数据的速率。比如采用慢启动、拥塞避免、快重传和快恢复等算法，防止过多的数据涌入网络，缓解网络拥塞状况。
2. 工作原理
- 数据分段与封装：应用层的数据被传递给 TCP 后，TCP 会将其分割成合适大小的数据段，并为每个数据段添加 TCP 头部信息，头部包含源端口号、目的端口号、序列号、确认号等字段。之后，这些数据段会被进一步封装成 IP 数据包，在网络中传输。
- 传输与确认：发送方将数据段发送出去后，会启动定时器等待接收方的确认。接收方收到数据段后，检查数据是否完整，若完整则发送确认信息给发送方；若不完整或丢失，则不发送确认，等待发送方重传。
- 连接释放：数据传输完成后，通过四次挥手（Four - way Handshake）来释放连接。客户端先发送一个带有 FIN（结束标志）的数据包表示要关闭连接；服务器收到后，回复一个 ACK 确认收到关闭请求，此时服务器可能还有数据要发送，等数据发送完，服务器再发送一个 FIN 包；客户端收到服务器的 FIN 包后，回复一个 ACK 确认，至此连接正式关闭。
3. 应用场景
- 网页浏览：用户通过浏览器访问网页时，浏览器与 Web 服务器之间的数据传输通常使用 TCP 协议。因为网页包含文字、图片、视频等多种信息，需要可靠的传输来保证数据完整无误地显示在用户面前。
- 文件传输：像 FTP（文件传输协议）在进行文件传输时，默认使用 TCP 协议来保证文件内容在传输过程中不丢失、不损坏，确保文件能够正确地从服务器端传输到客户端或者反之。
- 电子邮件：无论是发送邮件（SMTP 协议）还是接收邮件（POP3 或 IMAP 协议），都依赖 TCP 协议来保证邮件内容的可靠传输，包括邮件的文本、附件等。
- 远程登录：如 Telnet、SSH 等远程登录协议，使用 TCP 协议来建立稳定的连接，保证用户在远程主机上输入的命令和接收的反馈信息能够准确无误地传输。
4. 与 UDP 对比
- 可靠性：TCP 是可靠传输，有确认、重传、排序等机制；而 UDP（用户数据报协议）是不可靠传输，不保证数据一定能到达接收方，也不对数据进行排序等操作。
- 传输效率：TCP 由于有复杂的控制机制，在传输效率上相对较低；UDP 没有连接建立和复杂的控制过程，传输效率较高，适合对实时性要求高但对可靠性要求相对较低的场景，如视频直播、在线游戏等。
- 头部开销：TCP 头部有 20 个字节（不包含选项字段），开销相对较大；UDP 头部只有 8 个字节，开销较小 。
粘包
粘包的本质是 TCP 协议的 “面向字节流” 特性 与应用层 “按数据包解析” 需求之间的矛盾
TCP 协议不认为数据是 “一个一个的包”，而是将其视为连续的字节流（类似水流，没有天然分隔）。TCP 仅保证字节流的 “可靠性”（不丢、不重复、有序），但不保证 “发送一次 = 接收一次”。
粘包的解决方案：核心是 “定义数据边界”
既然粘包的根源是 “接收方无法识别数据边界”，解决方案的核心就是 在应用层协议中明确约定 “如何划分一个完整的数据包”，常见方案有 4 种：
1. 固定长度（Fixed Length）
- 原理：约定每个数据包的长度固定（例如，每个包都是 1024 字节）。接收方每次读取固定长度的数据，若不足则等待后续数据补全，若超出则截断（超出部分作为下一个包的开头）。
- 优点：实现简单，无需额外解析边界。
- 缺点：灵活性差 —— 若数据实际长度远小于固定长度，会浪费带宽（填充无效字节）；若数据长度超过固定长度，需手动拆分。
- 适用场景：数据长度固定的场景（例如，工业设备传感器的固定格式采集数据）。
2. 分隔符（Delimiter）
- 原理：约定一个特殊的 “分隔符”（例如，
\r\n、|，需确保分隔符不会出现在业务数据中），发送方在每个完整数据包末尾添加分隔符；接收方持续读取数据，直到遇到分隔符，此时分隔符前的内容即为一个完整数据包。 - 优点：灵活性高，无需预先知道数据长度。
- 缺点：需处理 “分隔符冲突”—— 若业务数据中包含分隔符（例如，文本消息中出现
\r\n），会被误判为数据包结束，需通过 “转义”（如\r\n转义为\\r\\n）解决，增加复杂度。 - 适用场景：文本类数据（例如，HTTP 协议的
\r\n\r\n作为请求头结束符、Redis 的 RESP 协议用\r\n分隔指令）。
3. 长度字段前缀（Length Prefix）
- 原理：在每个数据包的开头添加一个 “长度字段”（通常是 2 字节或 4 字节的整数），该字段明确表示后续业务数据的字节数。接收方先读取长度字段，再根据长度读取对应字节数的业务数据，即可得到完整数据包。
- 优点：无带宽浪费、无分隔符冲突，是最通用的方案。
- 缺点：需固定长度字段的字节数（例如，2 字节最多表示 65535 字节的数据，若业务数据超过此长度需用 4 字节），且需处理 “大小端” 问题（不同设备存储整数的字节顺序可能不同）。
- 适用场景：几乎所有二进制数据场景（例如，WebSocket 协议的帧头部包含 payload 长度、自定义 TCP 私有协议）。
| 对比维度 | TCP（传输控制协议） | UDP（用户数据报协议） |
|---|---|---|
| 连接方式 | 面向连接（三次握手 / 四次挥手） | 无连接（直接发送） |
| 传输可靠性 | 可靠（不丢、不重、有序） | 不可靠（可能丢包、乱序、重复） |
| 传输单位 | 面向字节流（无边界，可能粘包） | 面向数据报（有边界，无粘包） |
| 流量控制 | 支持（滑动窗口机制） | 不支持（需应用层实现） |
| 拥塞控制 | 支持（慢启动、拥塞避免等） | 不支持（需应用层实现） |
| 头部开销 | 大（固定 20 字节，最大 60 字节） | 小（固定 8 字节） |
| 通信方式 | 仅点对点（一对一） | 点对点、广播、组播（一对多） |
| 延迟与效率 | 延迟高、效率低（连接 / 控制开销大） | 延迟低、效率高（无额外开销） |