因为开发环境很多时候都是在服务器上，即便在本地搭建，也虚拟机，这也相当于是远程环境。虽然本地emacs也可以访问远程文件，不过我比较习惯在服务器上安装emacs，然后ssh登陆上去在TUI下用。然后再开一个tmux保持会话。 有时候需要在emacs中copy一些内容到本地，比如一段警告需要搜一下。或者一段日志之类。这时候这段内容就需要一个穿越过程：emacs到tmux到ssh到本地终端到本...

async/await 回顾一下前面的解析状态机。它在每一个流表模块提供的flow_t node也就是链接上执行，当执行不下去的时候就跳出来，出让执行权限给其他的链接。看起来像是为每一个链接都实现了一个微型的执行体，使得在同一个执行路径中，让流量处理程序可以并发处理大量的链接。这其实和async/await的异步模式很像。 async/await在实现上涉及到很多概念，但简单来说，它就相...

既然解析的过程就是状态转换，那自然想到状态机。如果能把解析过程分为不同的状态，然后作为一个状态机来轮转。那协议解析过程可以切分为不同的阶段，每个阶段仅关注自己的事儿。解析就是解析，状态转换就是转换，他们分开。这样的解析过程会清晰直观简洁。整个解析过程就是有多个状态组合起来的状态机。其实，所有协议都是状态机。 首先确定都需要划分哪些状态，比如SMTP可以分成下面几个状态： enum ...

能从链接中拿到一行一行的数据，就可以开始解析SMTP了。 解析过程 解析过程就是循环读取一行数据，然后按照协议顺序逐行解析。伪代码如下： while (get_line() != 0) { if (state == ERROR) return; if (state == HEAD) { // 处理head的过程 state = BOD...

对数据的假设 在数据包基础上开始协议解析不是不可以，甚至有时候还更简单。比如我们想解析SMTP的maifrom命令，它几乎在所有邮件通信过程中都完整地在一个单独的包中。甚至字符数量更多的邮件头也是如此。但是却不能作出它们一定就完整地在一个包中的假设，因为TCP协议并没有这种要求。虽然在绝大多数邮件服务器的实现中都会表现如上面描述，但是如果你想故意逃避被流量检测程序还原你的邮件通信，你完全可...

这里所说的网络流量处理，包括常说的IDS，IPS，NTA, NDR，XDR，DPI，网络行为审计，防火墙之类需要在数据包层面对流量进行判断审计之类的操作。如果只需要简单的处理比如流量统计，那只需要++就行了。如果要做更准确深入的分析判断，就得需要对这些数据解码。从IP TCP 一直到应用层如SMTP。要针对SMTP的协议内容作出判断分析审计，就需要解析SMTP协议。 IDS，IPS等流量处...