与 UDP 不同，TCP 协议为了提高利用率，设计了流量控制与拥塞控制机制。两者均使用类似的窗口算法，但它们的目的上存在本质上的不同。流量控制解决发送方与接收方之间的速度不匹配问题，是一个端到端的问题。而拥塞控制解决发送方和网络之间能力不匹配的问题，是一个全局性问题。

流量控制

流量控制用于防止发送方发送的数据过多、过快，而接收方的接收、处理能力有限，导致接收方缓冲区溢出的问题。

流量控制，是通过滑动窗口协议来实现的。这个窗口决定发送方能发送多少未收到 ACK 确认的数据。

Loco.rs 是一个基于 Rust 的 全栈开发框架，采用 Ruby on Rails 的思路，整合应用开发中需要的依赖、工具、开发模式等，降低选择成本，快速开始应用开发。

快速开始

安装 CLI 工具：

1
2

cargo install loco
cargo install sea-orm-cli

CLI 工具就绪后，通过 loco new 即可交互式地创建基础项目框架。

通过 cargo loco start 即可启动项目，默认在 localhost 接口上监听 5150 端口。

默认模版即包含了用于状态检查的 /_ping 和 /_health 接口：/_ping 接口返回 OK 状态，用于负载均衡器确认应用已启动；/_health 接口检查数据库、队列等状态正常后才返回 OK 状态，用于检查应用运行状态。

在使用 SaaS 类型生成的项目模版中，已生成用户认证相关的实体、API等，可实现注册、登录、重置密码等流程。

Leptos 是一个基于 Rust 的 Web 开发框架，使用细粒度更新的方式响应式地更新页面，提供较好的性能。这里对 Leptos 提供的 Leptos Axum Workspace 模版进行分析，了解其项目结构和开发流程。

项目启动

安装必要依赖

1
2

cargo install cargo-leptos cargo-generate
npm i -g sass

初始化 Leptos Axum Workspace 项目

1

cargo leptos new -g leptos-rs/start-axum-workspace -n leptos-axum-workspace-playground

在 end2end 目录中安装测试依赖

1
2

pnpm i
npx playwright install

端到端测试执行

1

cargo leptos end-to-end

启动支持热重载的开发服务器

1

cargo leptos watch

此时服务器将启动并监听 localhost:3000 地址，打开即可进入页面。

Loco.rs 通过命令行可快速生成模版项目，这里对生成的模版项目结构进行分析，以便理解 Loco.rs 工作原理，并为整合其他组件做准备。

项目启动

安装 CLI 工具：

1
2

cargo install loco
cargo install sea-orm-cli

使用 CLI 工具交互式创建模版项目

1

loco new

启动项目

1

cargo loco start

完成后将在 localhost:5150 上启动服务，通过浏览器访问即可打开页面。

TCP 连接的开启和结束都需要基于状态机进行多次交互，这里对 TCP 的三次握手和四次挥手流程进行分析。

HTTPS 是 HTTP 协议的安全加密版本，将 HTTP 流量封装在 TLS 加密信道中通信。为了完成这个通信过程，需要在客户端和服务器间完成加密通信协商，下面对这个过程进行分析。

抓取分析样本

为了尽可能观测到整个 HTTPS 交互过程，并尽可能在 Wireshark 中解密所有流量，我们启动一个受控的 HTTPS 服务器，发起一个 HTTPS 请求，并记录这个过程中的所有数据包。

整个实验在一个 Kali Linux 虚拟机中进行，测试流量发送与抓包解析等工作均在这个虚拟机中进行。使用 Kali Linux 虚拟机的好处在于：各种工具齐全，不需要额外安装；没有各种遥测服务的干扰，找到的包非常纯净，可以快速定位整个流程。

为了清晰理解 Seata 工作机制，在出现问题时能快速找到原因并给出对应的解决方案，下面对 Seata 应用部分源码进行分析。这部分主要关注 Seata 在应用中的介入部分，对于 TM、RM 的实现部分分析会另开一文进行记录。这里主要针对 AT 模式进行展开，其他模式可基于相似的起点开始源码的阅读和学习。

在数据库中存储的数据，最终需要都需要落到磁盘上进行持久化保存。这里对 MySQL 的数据存储结构进行分析。

MySQL 中，表数据由存储引擎负责存取。下面的数据存储结构以 InnoDB 存储引擎为准。在 InnoDB 存储引擎中，数据保存在 /var/lib/mysql/ 目录下，对于创建的每个数据库，会用数据库名称创建一个同名目录。该目录中，包括 db.opt 文件存储数据库的默认字符编码等信息。另外，为每个数据表创建同名的 frm 和 ibd 两个文件。frm 文件存储数据表的元数据，包括表结构等信息。ibd 文件存储数据表的表数据，也称为表空间文件。

Slint 的应用架构如下图所示：

Slint 应用使用为 UI 设计的 Slint DSL 对 UI 进行描述。这些 UI 代码通过若干 .slint 文件构成，每个 .slint 文件中可以描述若干个组件，这些组件之间进行复用，并构造一个完整的 UI 界面。

为了展示 Slint 界面，需要通过 Slint 编译器将 .slint 文件编译为 Slint 的内部表示后原生运行。这个编译的过程可以在应用程序编译时完成，也可以在程序运行时再进行。

在运行时内部，按 .slint 描述的界面元素，构成一棵 UI 元素树，在进行渲染时便基于这个 UI 元素树进行。

Slint 使用的属性、回调、模型元素也在运行时内部维护。这些元素也是应用程序代码与 UI 之间沟通的桥梁。用户界面与应用程序逻辑的交互全部通过这几类元素完成。

基于最终的 UI 元素树可以计算得到每个像素值，这些值需要展示到显示设备上。这个计算每个像素值并向显示设备传输的过程便由渲染器实现。

为了相互用户的输入，需要与输入设备交互，并将这些交互封装为输入事件传入运行时，从而分发到对应的处理函数，并产生最终的交互。

在 MySQL 执行语句中，需要经过一系列模块的协同工作，最终完成 SQL 语句的执行。

下图展示了 SQL 语句执行的过程。