Eddie Wang

用过nginx的都知道，改了nginx的配置文件，只需要执行nginx -s reload就可以让改动生效，而不用重启整个服务。 在kamailio和opensips中，也有类似的热重载功能。 在kamailio中，如果要热重载配置文件，只需要执行kamcmd app_jsdt.reload即可。 在opensips中，如果要热重载配置文件，只需要执行opensips-cli -x mi reload_routes即可。 理想很丰满，现实很骨感。 如果要只是修改路由模块，两者都可以做热重载。 如果要动态的新增一些模块，那就必须要重启。 Kamailio的实现方案 必须要用KEMI框架： cfg + [lua|js|python|ruby] 用这个框架，你写的路由脚本将包括两个部分 核心模块，全局配置，模块加载，模块配置，事件路由这部分内容还是写在cfg文件中。 请求路由、响应路由、分支路由、失败路由等这部分内容可以用lua、js、 python等来写。 在热重载的时候，实际上只有外部脚本会被重新加载，而核心模块是不会被重新加载的。 因为部分路由用其他脚本编写，必然涉及到性能比较。官方给出的结论是，在同等条件下，lua的性能是最好的。 https://www.kamailio.org/wikidocs/devel/config-engines/#interpreters-performances 但是实际生产环境如何，还不好说。 另外一点，就是并不是所有模块都实现了KEMI框架的接口，可能存在风险。 OpenSIPS的实现方案 OpenSIPS在3.0版本首次引入了热重载路由脚本的能力，脚本还是cfg，没有引入其他语言。 https://www.opensips.org/Documentation/Interface-CoreMI-3-0#toc8 结论 总体而言，目的是相同的，都是为了热重载路由。 kamailio的方案看似灵活，实则复杂。如果cfg本身就能做热重载，那么就没必要引入其他语言。 我更倾向使用OpenSIPS的方案 参考 https://blog.opensips.org/2019/04/04/no-downtime-for-opensips-3-0-restarts/

架构图 kamailio 1.x版本 kamailio 3.x版本。相比于1.x版本，两个核心模块移动到外部模块。 核心模块 The core includes: memory manager SIP message parser locking system DNS and transport layer management (UDP, TCP, TLS, SCTP) configuration file parser and interpreter stateless forwarding pseudo-variables and transformations engines RPC control interface API timer API The internal libraries include: some components from old Kamailio v1.5.x core database abstraction layers (DB API v1 and v2) management interface (MI) API statistics engine SIP消息处理 请求处理 响应处理。 这里可以看到，是先执行响应路由，再执行失败路由。 ...

目标 kamailio将所收到的SIP消息封装成HEP格式，然后已UDP发送给Hep Server 环境说明 kamailio版本 5.6 Hep server地址 192.168.0.100 kamailio脚本 listen 参考文档 https://www.kamailio.org/docs/modules/5.6.x/modules/siptrace.html https://github.com/sipcapture/homer/discussions/619 https://github.com/sipcapture/homer/wiki/Examples%3A-Kamailio

HEP简介 HEP协议目前叫做EEP(Extensible Encapsulation Protocol), 那之前的缩写HEP的H，我只能推测为homer。 这个协议的主要功能是对VoIP连路上的数据包，例如SIP进行封装，方便后续分析SIP信令图。 目前这个协议已经升级到V3版本，在这个pdfHEP3_Network_Protocol_Specification_REV_36中有详细的介绍。 今天我们主要看这个协议的V3版本的协议是如何实现的。 包头 packet-beta title HEP Packet 0-3: "版本号" 4-5: "总长度" 6-15: "数据段(变长)" HEPv3的包头是6个字节，主要分为三个部分 版本号：固定4个字节长度，是HEP3 总长度：固定2个字节长度，是包的总长度，这个总长度包括了包头的六个字节。所以HEP包的大小范围一般是6-65535之间。 数据段：数据段的长度不固定 注意事项：假如从传输层读到1000个字节的数据，在解析前6个字节是，发现总长度(total length)的子段是1200，那就说明本次读到的数据还不是一个完整的 数据段解析 数据段由固定6字节长度的头部和变长的payload部分。 packet-beta title HEP Packet 0-1: "vendor ID" 2-3: "type ID" 4-5: "length" 6-15: "payload" vendor ID: 固定2字节长度, 其实意义不大， type ID: 固定2字节长度，这个子段很重要，决定了payload的类型。可以理解为是一个对象的key, 然后把payload理解为value length: 固定2字节长度，范围是0-65535，这个字段是也是整个数据段的长度，也就是包括了6个字节的段头 payload: 长度是length的长度-6，表示数据长度 hep协议有个type ID的映射表 chunk type ID 类型 描述 0x0001 uint8 IP类型，0x02=IPv4, 0x0a=IPv6 0x0002 uint8 协议类型 0x06=TCP, 0x11=UDP， 可以参考IP协议号列表 其他的字段还有很多，可以参考HEP3_Network_Protocol_Specification_REV_36 ...

在电影《邪不压正》中，关于写日记的经典对白是 "正经人谁写日记啊？" "是啊" "你写日记吗？" "我不写。你写日记吗？" "谁能把心里话写日记里？" "写出来的那能叫心里话？" "下贱！" 给我灌输一种感觉写日记的人往往是虚伪的。 然而，最近我看了季羡林先生两本书《牛棚杂忆》和《留得十年》，我不得不对季先生佩服的五体投地，眼角朦胧，鼻头发酸。 我在德国十年的日记，一天不缺，恐怕有一两百万字。–《留德十年》 做一件小事，坚持10年。 这是什么样动机，是因为毅力吗？ 如果说做一件事让自己感觉很难，不想做，但是做了很长时间，可以称之为毅力。 我觉得除了毅力，更多的一种喜欢，一种习惯。一种把思想自然流露指尖，落笔成文的自然天性。 我不记得以前上学时，有没有度过季先生的。然而季先生的大名，还是略有耳闻的。 但是除了季先生的大名的，其他的事情，几乎不了解。 看了两本书书后，我不禁对季先生生有有一种心驰神往。 我不知道季先生原来是清朝末年的人。经历过清末、民国、二战、解放、文化大革命… 我不知道季先生原来去德国留过学，而且是是坐火车去的。 德国哥廷根的风景描写，让我脑海里呈现一种宫崎骏动画般画面。 我不知道原来季先生在德国还经历过二战。 我不知道季先生原来还在文化大革命中，数次被打倒。 季先生的文风朴实，感情自然流露。你能从他的文字中看到一个普通人懦弱与勇气、迷茫与坚持、欲望和克制。 我喜欢季先生的文风，也喜欢季先生的为人。 我觉得，归根结底，我喜欢真实，厌恶粉饰。

包格式 UDP包头工占用8个字节, 其中源端口和目标端口各占2个字节，长度占2个字节，校验和占2个字节。 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ | Source | Destination | | Port | Port | +--------+--------+--------+--------+ | | | | Length | Checksum | +--------+--------+--------+--------+ | | data octets ... +---------------- ... User Datagram Header Format 字段 源端口，可选字段，默认为0，如果是有意义的其他端口，表示后续响应可以送回到该端口 目标端口，必须字段，用来关联目标主机上进程监听的端口 长度，长度是整个UDP包的长度，也就是包头 + 包的数据，包头固定8字节，那么length的最小长度就是8 校验和，用来验证传输过程中是否发生了错误。校验和的计算结果与源IP、目标IP、UDP的包长有关。 如果校验和失败，那么消息会被丢弃。 有些校验和计算的工作会被放置在网卡上，从而减少CPU的负载。当然如果在网卡上因为校验和的问题被网卡丢弃，上层应用是收不到不到UDP包的。但是用tcpdump可以抓到这种校验和有问题的包。 思考1： 为什么源端口可以设置为0？ 答：有些UDP包，是不需要响应的，只需要发送出消息。 参考 https://datatracker.ietf.org/doc/html/rfc768 https://wdd.js.org/opensips/ch7/big-udp-msg/ https://wdd.js.org/network/udp-checksum-offload/

28号 - 抗体 28号晚上，我觉得嗓子有点刺痛。因为前两周发过一次烧，我觉得这次嗓子痛应该不会是发烧的前奏了，毕竟身体是有抗体的。 我高估了之前产生的抗体。 29号 - 梦 从29号上午开始，身体就好像在温水煮青蛙，最高到达惊人的峰值40度。 为了控制体温，我先洗个热水澡，吃了布洛芬，躺在床上，拿了一块冰袋，裹在卫生纸里，搁在脑门上。身体挺直，裹着两层厚被。 长夜慢慢，睡睡醒醒。 我梦见自己变成了一棵树，脚上好像长出了根须，缓慢的往地下生长。穿过泥土，与蚯蚓擦肩而过。穿过岩石，被石油染黑。然而到达的却是一块冰山，冰冷坚硬。 手上长出了树干，像天空伸展，摊开自己的枝叶，还没等我享受片刻温暖，太阳仿佛飞速向我飞来，炙热的阳光让我瞬间枯黄，灰飞烟灭。 长夜慢慢，我不敢辗转反侧。我头上还顶着一块冰。 30号 - 发热门诊 终于熬到早上，再测试一遍体温，38度。 算了，还是去医院吧。 穿戴整齐，刚下楼，迎面吹来一阵冷风。我有种无法压抑的，想要咳嗽的冲动，但是我必须忍住，我知道这咳嗽必然“感天动地"。 风继续吹，我忍不住咳了出来，那感觉，仿佛有人伸手把我的气管从我的嘴巴里扯了出来。 到了医院，发热门诊是单独一层的小房子，和气派的十几层的门诊大楼相比，简直像个保安室。 发热门诊虽小，但也五脏俱全。 进门先做鼻拭子，量体温，挂号。 再做血液分析，然后就排队等叫号。医生看了报告，说我是甲流，开了两盒药，一盒抗病毒，一盒用来退烧。 从医院出来，已经中午。我走进医院旁边的永X大王，准备随便吃点。 我挑了一个座位，扫码下单，点了馄炖、蒸蛋、豆浆、银耳莲子羹。 等餐期间， 我发现对面有个中年人大叔，穿这黑色的宽大的羽绒服，胡子拉碴、头发稀少， 他时不时的巡视着其他的人。 没过过久，我等到自己的餐。 馄炖上撒了淡黄的鸡蛋丝和黑色海苔碎，鸡蛋丝吃起来像绳子，海苔碎味同嚼蜡。混度汤非常浑浊，像是用了一天的澡堂池子水。馄炖我就吃了一个，就放弃了。 蒸蛋应该是预制菜，放在黑色塑料小杯中，应该是微波炉加热的。我吃了一口，味道奇怪。 豆浆没什么好说的，毕竟也味道也没有下降空间了。 银耳莲子羹还不错，我都个喝完了。 吃饱喝足，顺便我把医生给我开的药也吃了，我起身离开，刚走到餐桌不到2米， 就瞥见那个大叔匆匆走向我的餐桌。 急诊室 我吃完饭，回到家，每隔一个小时测一次体温，体温很稳定，稳定在38度左右。 一直到晚上，我的体温还是没怎么下降。 老婆给我打电话，说让我赶紧去急诊，去输液，光吃药效果不好，高烧不退会要人命的。 但是我觉得没必要，因为尽然发热门诊的医生都没有让我输液，说明我不需要输液，或者说输液也没有多大作用。 老婆说：“你想让我中年丧夫吗？” 我无话可说，只能默默穿上衣服，带上口罩，去了早上那家医院的急诊。 晚上9点急诊室人来人往，络绎不绝，仿佛是白天的门诊。 我挂上号，接着又等了将近1个小时，终于等到我了。 给我看病的是位女医生。 ”医生，我在你们医院发生门诊早上就看过了，诊断是甲流，药也吃了，到现在还是38度，还是给我输液吧。“，我说 ”甲流不是一天两天能好的，至少要发热三天，而且输液效果也不大“，医生说 “那我也烧了两天了，再烧下去人要烧没了。你给我开个输液的吧” “好的吧，那我就给你开一次输液，你看看效果” 一顿拉扯，我终于能输液了。其实输的也不是什么特殊的东西，就是一带左氧和一袋维C。 输完液，已经晚上11点50，叫了车，回到家里。感觉嘴巴好苦，还好家里有甜的冰糖心苹果。 我啃完第一个苹果，每一口都是苦味。接着我再啃一个苹果，每一口都还是苦味。 如果不是因为发烧，我简直立即想去吃点火锅底料漱漱口。 归梦 睡觉前，我又量了一次体温。体温恢复到37度，看起来正常正常了。 我不知道这是吃药起的效果还是输液的效果。 但是两盒药的价格是270，其中一盒西药50，另一盒重要220。 输液呢，一袋左氧+维C，总共也不过才30。 让我想起了电影《大腕》的名言 31号 这是24年的最后一天，美丽的烟花在天空中绽放璀璨的光芒。 有些人觉得烟花美丽，有些人只觉得吵。

内存布局 堆和栈之前有大片的空白虚拟内存空间，用多少映射多少 堆和栈是像相反的方向增长

[[TOC]] route_list route.h定义了几个函数分别用来获取、查找、新增route // src/core/route.h int route_get(struct route_list *rt, char *name); int route_lookup(struct route_list *rt, char *name); void push(struct action *a, struct action **head); struct route_list { struct action **rlist; int idx; /* first empty entry */ int entries; /* total number of entries */ struct str_hash_table names; /* name to route index mappings */ }; rlist 我们对route_list数据模型进行简化: rlist是一个固定长度的一维数组，通过索引来访问对应的值。如果数组的空间不足，那么就创建一个两倍大的空数据，然后先把原始数据复制过去。这种复制方式保持的原始数据的索引位置。有点像golang的切片扩容机制。 这里最为重要的就是保持数组元素的索引位置在扩容后不变。 static inline int route_new_list(struct route_list *rt) { int ret; struct action **tmp; ret = -1; if(rt->idx >= rt->entries) { // 两倍扩容 tmp = pkg_realloc(rt->rlist, 2 * rt->entries * sizeof(struct action *)); if(tmp == 0) { LM_CRIT("out of memory\n"); goto end; } /* init the newly allocated memory chunk */ memset(&tmp[rt->entries], 0, rt->entries * sizeof(struct action *)); rt->rlist = tmp; rt->entries *= 2; } if(rt->idx < rt->entries) { ret = rt->idx; rt->idx++; } end: return ret; } str_hash_table 我们对hash_table的数据模型进行简化，它其实就是一hash表，key是路由的名，值是一个正数，正数代表了路由执行单元的索引位置。 ...