流式解析http build query 字符串

 

脚本:

 

受jq的启发

这个parser很奇怪, 处理的是 value 嵌套value的情况,生产上有这种情况,但是很少见。

tcp 的滑动窗口

tcp的滑动窗口是用来流控的,但是,如果一方不遵守,会怎样呢?如下:

 

我们发现,虽然8085一直提示说win只有430,但是59822却完全无视,直接发送1448大小的数据; 8085也没有生气,也没有不ack,是不是很好玩。

好景不长,59822 觉得不好意思了,改发500大小的数据包了:

 

对于甲方来说,发送了一个小的win ,乙方未必按照小的win发送数据,只要甲方总能ack乙方发送的所有数据,乙方就可以总是发送一个很大的数据包;对于甲方来讲,其实可以通过不ack乙方,或者ack部分数据来制服乙方的。

最近在忙啥

自从雄飞提离职,我就开始了解lua版本的dmp,开始是性能优化,修补丢数据的情况,添加监控,分析指纹数据的流程,直到添加caid的支持。

最近这些事情不敢太随意,步步细心的去做,只是最近添加caid的事情,催的有些急,测试不到位,出了不少问题。

本来答应凯超那里做一些规则引擎的配置节目的事情,以及试金石的优化,都没时间做呢。

总结:

  • 程序总是要有bug的,写完就上线,一定就出错,欲速则不达。
  • 上完线不等于完事儿,必须多方面验证
  • 尤其对数据的写操作,要有如果写错了的预案
  • 有些时候,错误的认知会关上通往真理的大门,敢于否定自己,想办法来验证自己的想法,没有验证的结论就不一定对,就好比没有测试的程序就一定会出错一样

lua 之 require

lua 的 require 会自动避免重复加载的,如:

hello.lua

要想重复加载也行:

由此也可以通过package.loaded 知道都load了哪些包了:

如何知道进程运行在哪个核上

 

下图是htop能直观看到的数据:

第一个CPU很忙,太多的时间花费在了内核,为什么内核那么消耗CPU:

该CPU主要干了三件事:

  1. 硬终端  (估计这个是导致kacpid非常忙的根源)
  2. 软终端  (主要是网卡中断)
  3. 内核进程kacpid

连续执行如下命令会发现acpi中断非常多,而且确实都是发生在CPU0上的,自然处理该中断的也就是CPU0了;如果说要把网卡软中断和acpi中断分开,那么就是,要么把acpi从CPU0挪走,要么把网卡软中断从CPU0挪走