近段时间，黑盒测试的工作越来越多，packetdrill用到的也就水涨船高，脚本量在不断地膨胀。可是，网上的资料依旧是少的可怜，只好在摸索中前进。咦嘘乎！只得在碰壁中不断进化。

对于packetdrill，大量的写脚本并非难事，可恶的是对脚本的理解。 Google对待packetdrill的态度不比它其他的孩子，除了书写规范和一堆范例，很难找到其他的脚本指南。于是，在脚本这点上吃尽了苦口。

但没办法，除非我愿意花大量时间去解构代码，但我没有，我的目的只是用packetdrill去达到我的目的罢了，仅此而已！

但大量试错和脚本分析后，我还是摸到了packetdrill在脚本定义和分析上的一些脉络，于是我等不及Google的更新，在它之前就打算披露出来，原因无外乎是，想让packetdrill形成一个生态，既然Google不做，我就先一点点补充好了。

一个正确的脚本，关键点在于注入包和检验包的书写。 其他的部分，方便被“终端”检查出来。只有这里，在掌握了一定的逻辑后，就能很轻松的写自己需要的脚本和分析别人的脚本了。

根据图解，一点点来解构下packetdrill脚本。

还是拿了TCP举例。

首先，packetdrill在写一个脚本时，都会扮演C/S的一个角色，可能是客户端，或是接收端。在确认角色后，都应该学会站在这个角度上看问题。

对于三次握手而言，packetdrill总是从client到server的握手，这里不需要担心，在脚本中这里几乎保持一致。

在TCP established中，发包操作是从角色处触发，而**“ACK应答”**自然是对端触发的。所以packetdrill对于注入包，是两端都可以注入，只需要注意“发包操作”和“ACK应答”的规范即可。

而packetdrill对于检验包，是与注入包有些许不同的。

检验包时，packetdrill总是只在自己扮演的角色处有检验点，只对自己的端验证。而因为对端是不可掌握的（没有检验点），所以不能对对端的“包行为”检验。

按图解，如果我们站在了Server端。

+0 > . 1:1(0) ack 7001 win 257

这样的写法是错误的。但我们总会犯下这样的错误，却浑然不知。

最后，packetdrill四次挥手亦是从client到Server，没有什么好说道的，就此画个句号。

---

写在最后

packetdrill 是一个好用的黑盒网络验证工具，搭配上EBPF基本是事半功倍的。

痛点嘛，无外乎是Google对于packetdrill的忽视。但这也不影响什么，packetdrill借力于开源，必然还是大有可期的。

写完后，发现也并不像是一篇指南，但貌似又想不出什么切合的标题，遂作罢。