Eddie Wang

包格式 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是路由的名，值是一个正数，正数代表了路由执行单元的索引位置。...

[[TOC]] 事件路由简介 在某些模块中，我们看到有一些模块自定义的事件路由。 例如dispatcher模块，或者rtpengine模块。 event_route[dispatcher:dst-down] { xlog("L_ERR", "Destination down: $rm $ru ($du)\n"); } event_route[rtpengine:dtmf-event] { xlog("L_INFO", "callid: $avp(dtmf_event_callid)\n"); xlog("L_INFO", "source_tag: $avp(dtmf_event_source_tag)\n"); xlog("L_INFO", "timestamp: $avp(dtmf_event_timestamp)\n"); xlog("L_INFO", "dtmf: $avp(dtmf_event)\n"); } disapcher模块 在dispatch.c文件中，我们看到如下代码 if(!ds_skip_dst(old_state) && ds_skip_dst(idx->dlist[i].flags)) { ds_run_route(msg, address, "dispatcher:dst-down", rctx); } else { if(ds_skip_dst(old_state) && !ds_skip_dst(idx->dlist[i].flags)) ds_run_route(msg, address, "dispatcher:dst-up", rctx); } ds_run_route还是定义在dispatch.c文件中， static void ds_run_route(sip_msg_t *msg, str *uri, char *route, ds_rctx_t *rctx) 接着又一个重要调用。 这里似乎在查找路由。 route这个参数其实就是dispatcher:dst-down， 或者 dispatcher:dst-up， 那么event_rt又是什么鬼呢？ rt = route_lookup(&event_rt, route); event_rt是一个route_list的结构体...

背景 多个SIP注册服务器之间，如何同步分机的注册信息呢？ 简单的方案就是使用共享数据库的方式同步注册信息，这个方案实现起来简单，但是分机的注册信息本身就是个需要频繁增删改查的，数据库很可能在大量注册分机的压力下，成为性能的瓶颈。 除了数据库之外，OpenSIPS和kamailio分别提供了不同的方案。 OpenSIPS提供的方案是使用cluster模块，cluster模块在多个实例之间同步分机的注册信息，注册信息的格式是OpenSIPS自定义的格式。 Kamailio的方案是DMQ模块， DMQ听起来高大上，放佛是依赖外部的一个服务。 但它其实就是扩展SIP消息，通过SIP消息来广播分机的注册信息。 KDMQ sip:notification_peer@192.168.40.15:5090 SIP/2.0 Via: SIP/2.0/UDP 192.168.40.15;branch=z9hG4bK55e5.423d95110000 To: <sip:notification_peer@192.168.40.15:5090> From: <sip:notification_peer@192.168.40.15:5060>;tag=2cdb7a33a7f21abb98fd3a44968e3ffd-5b01 CSeq: 10 KDMQ Call-ID: 1fe138e07b5d0a7a-50419@192.168.40.15 Content-Length: 116 User-Agent: kamailio (4.3.0 (x86_64/linneaus)) Max-Forwards: 1 Content-Type: text/plain sip:192.168.40.16:5060;status=active sip:192.168.40.15:5060;status=disabled sip:192.168.40.17:5060;status=active 源码分析 该模块一共暴露了8个参数，其中7个参数都是简单类型，INT和STR，就直接取对应变量的地址就可以了。 其中notification_address参数是用来配置集群中其他节点的通信地址的，因为要配置多次，所以需要用一个函数来解析。 // dmq.c static param_export_t params[] = { {"num_workers", PARAM_INT, &dmq_num_workers}, {"ping_interval", PARAM_INT, &dmq_ping_interval}, {"server_address", PARAM_STR, &dmq_server_address}, {"server_socket", PARAM_STR, &dmq_server_socket}, {"notification_address", PARAM_STR|PARAM_USE_FUNC, dmq_add_notification_address}, {"notification_channel", PARAM_STR, &dmq_notification_channel}, {"multi_notify", PARAM_INT, &dmq_multi_notify}, {"worker_usleep", PARAM_INT, &dmq_worker_usleep}, {0, 0, 0} }; 这些参数都没有加上static关键词，主要目的为了在dmq模块的其他c文件能使用。...

1. 请求消息处理过程 请求可以 直接丢弃，不返回任何响应。对于恶意请求，SIP Flood攻击，最好不要返回任何响应。 直接返回状态码，不做转发，例如直接返回301重定向 无状态转发 有状态转发 执行分支路由，分支路由也可以将消息丢弃 无论有无状态，请求发出去前都会执行onsend_route路由，在onsend_route内部，已经不能对SIP消息再做拦截 2. 响应消息处理过程 首先执行reply_route{}, 在这个路由里可以将消息丢弃 然后判断消息是否有状态的 有状态，这执行onreply_route[ID]路由 如果响应是失败的，还可以执行failure_route[ID], 当前前提是在请求路由里是否设置了钩子 在失败路由可以，可以再次设置新的目标地址，进行转发； 设置了新的目标地址后，还可以设置分支路由 Tip 这里要注意的是，响应路由在失败路由之前执行。 3. 重传处理

-a mode Auto aliases mode: enable with yes or on, disable with no or off 一般都是关闭 --alias=val Add an alias, the value has to be '[proto:]hostname[:port]' (like for 'alias' global parameter) 设置对外别名, 在多个对外别名时，相比于在脚本中写死, 更好的方式 是在启动时传入, alias一般都是服务的对外域名或者IP 如果km有多个对外域名，并且不同的环境都不同，这块配置就合适在脚本里写死 --atexit=val Control atexit callbacks execution from external libraries which may access destroyed shm memory causing crash on shutdown. Can be y[es] or 1 to enable atexit callbacks, n[o] or 0 to disable, default is no....

攻击分类 网络层 ICMP Flood攻击: ICMP（Internet Control Message Protocol，因特网控制报文协议）是TCP/IP协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。ICMP协议本身特点决定了它非常容易被用于攻击网络上的路由器和主机。当攻击者向目标网络发送大量的ICMP数据包时，目标主机会耗费大量的CPU资源去处理和响应，直至耗尽设备资源，无法为合法用户提供正常服务。 ARP Flood攻击: ARP（Address Resolution Protocol，地址解析协议）是用来将IP地址解析为MAC地址的协议。ARP协议主要以广播的方式发送ARP请求。同网段内的主机都可以收到广播请求，这为攻击者提供了可乘之机。攻击者通过发送大量的ARP请求，使有限的网络资源被无用的广播信息所占用，造成网络拥堵。其次，因为ARP协议没有安全认证机制，所以只要主机接收到ARP应答包，都会缓存在ARP表中，这为ARP欺骗提供了可能。 IP分片攻击: IP协议在传输数据包时，会将数据报文分为若干分片进行传输，并在目标系统中进行重组。IP分片是网络环境中经常发生的事件，但是，如果数据被人为恶意分片就会产生DDoS攻击。攻击者将经过恶意分段的数据包发送至目标网络，导致目标网络耗费大量资源进行重组，直至资源枯竭。 传输层攻击 SYN Flood攻击: SYN Flood是互联网最原始、最经典的DDoS攻击之一，主要利用了TCP协议的三次握手机制。攻击者通常利用工具或控制僵尸主机向服务器发送海量的变源IP地址或变源端口的SYN报文，服务器响应报文后产生大量的半连接，直至系统资源被耗尽，服务器无法提供正常的服务。 ACK Flood攻击: 攻击者通过僵尸网络向目标服务器发送大量的ACK报文，报文带有超大载荷，会引起链路拥塞。或向目标服务器发送极高速率的变源变端口请求，导致转发设备异常，从而引起网络瘫痪。 UDP Flood攻击: UDP Flood攻击常用于大带宽DDoS攻击。攻击者使用包含无状态UDP协议的IP数据包充塞目标主机的端口，受害主机会寻找与UDP数据包相关的应用程序。如果没有找到，就向发送者回发一条“目标不可达”消息。一旦目标主机被攻击流量淹没，系统就会失去响应，从而造成合法用户无法正常访问的现象。 应用层攻击 DNS Flood攻击: 攻击者通过操纵大量傀儡机器，对目标网络发起海量域名查询请求，以中断该域的DNS解析。这种攻击将会破坏网站、API或Web应用程序响应合法流量的能力，让合法用户无法查找到用于调用特定资源的地址，导致业务暂时中断或停止。 HTTP Flood攻击: HTTP GET 攻击：攻击者操控多台设备向目标服务器发送对图像、文件或其他资产请求，当目标服务器被传入请求和响应所淹没时，来自正常流量源的业务请求也将被拒绝。 HTTP POST 攻击：与发送 POST 请求所需的处理能力和带宽相比，处理表单数据和运行必要数据库命令的过程相对密集。这种攻击利用相对资源消耗的差异，直接向目标服务器发送大量POST请求，直至目标服务器容量饱和并拒绝服务为止。 CC攻击: CC攻击常用于攻击提供网页访问服务的服务器。攻击者通过代理服务器向目标服务器发送大量貌似合法的请求，使CPU长时间处于高负荷运行状态，永远都有处理不完的连接。攻击会导致正常访问被中止，最终宕机崩溃。 SIP注册 Flood攻击: 攻击者发送大量的SIP注册请求到SIP服务端，SIP服务器需要查询数据库，拖慢正常的数据库查询，也回占用大量的资源来维护注册的事务。 FAQ 防火墙能否拦截DDOS攻击？ 拦截不了，防火墙就好比饭店的保安，保安再多，但是饭店门口道路交通堵塞了，饭店的营业额下降，再多的保安也无能为力 在遭受DDOS攻击后，用什么手段防御？ 购买硬件设备：除了比较贵之外，对于使用云服务器的服务也无能为力 更换公网IP：对于使用云服务器来说，更换云服务器的公网IP看起来比较简单方便。但是也有麻烦的地方，比如自己的服务可能要涉及到配置改变和服务重启，和自己相关的第三方，也可能要修改IP的访问地址 使用云服务厂商提供的DDOS服务 如何感知到自己的服务正在遭受DDOS攻击？ 异常大的流量波动 正常用户大量离线 参考 https://info.support.huawei.com/info-finder/encyclopedia/zh/DDoS%E6%94%BB%E5%87%BB.html https://www.microsoft.com/zh-cn/security/business/security-101/what-is-a-ddos-attack

公开自己的错误 我在写博客时，有时候脑海里总会蹦出一个小人，面露鄙夷的脸色对我说：你写这么多没啥技术含量的垃圾，公开在网上，难道不怕暴露自己的无知吗？ 说实话，我是有这样的担忧。 因为我是有自知之明的，我知道自己估计也是黄老师那种"样样通，样样松"的人。 写的东西也都是一些表面的东西，甚至有错误的可能。这并不是自谦。 我一直无法找到反击脑海里小人的理由。 今天，我在读一本书的时候，学到了一个概念，这个概念叫做坎宁安定律。 在互联网上获得正确答案的最好方法并不是提出问题，而是发布错误的答案 也许我的答案是错误的，但是它并没有被隐藏我脑海的某个角落，二是被公开在了网上。 即使我的小破站再小，必然也会有几个阅读量吧，或许能有读者对错误的答案提出自己的异议。 学习金字塔理论 如果仅仅是通过阅读学习，学习内容的平均存留率只有5%。 如果把学习内容公开，这其中就暗示了你可能需要把自己学到的内容教授给他人这一心理。 那么在记录笔记的时候，就会想办法把问题讲解的让别人更清楚，从而加深了自己的学习知识吸收。 参考 https://baike.baidu.com/item/%E5%AD%A6%E4%B9%A0%E9%87%91%E5%AD%97%E5%A1%94/9515094