像狗一样奔跑 👋🏼

红红火火恍恍惚惚... 打开了我的博客，发现今年一年都没有再更新了，好像是自己懒了，好像是别的其他什么理由，但终归不是什么好的事情。但一年到头了总得写点什么，来纪念一下转瞬即逝的2023。 生活 前些天和一女孩聊天的时候，她问我为什么不发朋友圈，我才意识到，哦原来已经一年多没有发过朋友圈了，和我博客停更的时间差不多了。我本身不是一个喜欢发朋友圈的人，也不擅长写那些极好的文案，拍那些好看的图片，总觉得将这些分享给其他人是一件难为情的事情。 套用女孩的一句话：没有分享朋友圈的日子里，也有在好好的生活。 今年疫情放开后，出行不再受到限制了，于是我去了一趟西安、两趟长沙，虽然每次时间都不长，没有去太多景点，但好歹也算是尝了特色美食，不虚此行吧。本来还想再去趟天津的，可是一直被耽搁，估计也没机会了。 今年虽然也没钱，但到了年底，还是配齐了电脑，算是鸟枪换炮吧，工作游戏两不误，都能兼顾上了。是的，所谓的兼顾就是一台专门打游戏，一台用于工作嘿嘿... 工作 2023年其实是工作的一年，大部分的工作填满了我的日常，也可能是因为没有很多的人际交往吧，导致平时没有什么活动，只能将时间投入工作了。 今年真正....

很久没有更新blog了，为什么呢，也许跟去年发生的一些事情有关，也确实是不知道写什么好，在说不准的某个时间点里，我突然就开始摆了，摆的彻彻底底。 今年其实在家里的帮助下，完成了人生中的两件大事吧，自己也配了一直都很想要的电脑，可以说是该拥有的都有了吧，花了很多的钱，可是收获的快乐却没有想象中那么多，人生中有很多不如意之事，有的人遇到了开心或不开心的事情，可以大大方方的向其他人倾诉，有的人却觉得难为情，不知道如何开口，不巧，我就是后者。 还好今年我遇到了一个关心我的女孩，虽然我们素未谋面，可是在我难过的时候，她会打电话过来安慰我，关心我，这是在我生命的前二十多年中从未有过的，让我感受到了很多温暖。但是最近我们之间的沟通交流变得很少了，可能跟她最近失业有关，但也有我的问题，我不知道该怎么去关心、安慰她。她在靠近，我不知道怎么快速向她靠近，她远离，我也不知道怎么缩短我们之间的距离。其实是这样的，我不知道如何表露我的情感了，我害怕说出来没有结果，自己像个小丑，所以错失了很多机会。现在我感觉即使说出来也没有什么机会了，可是我不想失去她，我想要她和我分享生活，我想要走进她的生活

时间过得好快，一转眼，2022年就过去了。在今年的上半年，不管是生活还是博客，我都有好好的安排，可是进入五月份之后，情况突然就变了。可能是因为疫情，也可能是因为其他原因，突然就不想努力了，开始了长达半年的摆烂生活，仿佛一下子失去了人生目标。当然我也有在好好工作，可是却没了进取的心思，此时我才明白陪伴的力量，在人生路上有个伴是多么的好，当然我不是说现在的我的生活不好，只是终究会有些难以排解的心情，只能自己默默消化。 这一年，起初我的项目进展的是不太顺利了，做了两个多月的东西，需求突然更换，然后又重头开始，当然到现在来说，总体还算是顺利，其中离不开同事的包容与帮助。同时也让我感受到了自己与其他同事之间能力的差距，我的进步空间还很大，可是突然就摆烂了几个月... 应该是在六月份吧，还是七月份，我打球的时候受了一次挺严重的伤，当然那时我并没有当回事，因为之后打球什么的也感觉不到。可是伤病是逐渐累积的，它就在你一次一次的不以为然之中悄然给你爆发最大的伤害，终于我感觉到不对劲了，去医院检查了核磁共振后，才发现我的膝盖原来有这么多的毛病，医生告诉我不能再运动了，要彻底歇息好再考虑运动这件事，最好连楼....

正文 为了满足不同用户不同程度的优化需要，gcc提供了近百种优化选项，用来对编译时间，目标文件长度，执行效率这三方面进行不同的取舍和平衡。简单来说就是gcc提供了从O0-O3以及Os这几种不同的优化级别供用户选择，在这些选项中，包含了大部分有效的编译优化选项，并且可以在这个基础上，对某些选项进行屏蔽或添加，从而大大降低了使用的难度。下面围绕这几个不同级别的优化选项进行简单介绍 -O0：默认的编译选项，不做任何优化 -O和-O1：对程序做部分编译优化，对于大函数，优化编译占用稍微多的时间和相当大的内存。使用该选项，编译器会尝试减小生成代码的尺寸，以及缩短执行时间，但并不执行需要占用大量编译时间的优化。 -O2: 比 -O1更高级的选项，进行更多的优化。gcc将执行几乎所有的不包含时间和空间折中的优化。当设置O2选项时，编译器并不进行循环打开()loop unrolling以及函数内联。与O1比较而言，O2在优化增加了编译时间的基础上，提高了生成代码的执行效率。 -O3： 比O2更进一步的进行优化 -Os： 主要对程序的尺寸进行优化，打开了大部分O2优化中不会增加程序大小的优化选项，并对程....

前言 最近在工作中部署生产系统的时候遇到了一个问题：网卡能收到数据，但系统进程却收不到相关数据，查了半天发现是rp_filter的问题，今天就记录一下。 正文 rp_filter（Reverse Path Filtering）参数定义了网卡对接收到的数据包进行反向路由验证的规则。它有三个值，0，1，2，具体含义如下： 0：关闭反向路由校验 1：开启严格的反向路由校验。对每个进来的数据包，校验其反向路由是否是最佳路由。如果反向路由不是最佳路由，则直接丢弃该数据包。 2：开启松散的反向路由校验。对每个进来的数据包，校验其源地址是否可达，即反向路由是否能通（通过任意网口），如果反向路由不同，则直接丢弃该数据包。 反向路由校验 所谓反向路由校验，就是在一个网卡收到数据包后，把源地址和目标地址对调后查找路由出口，从而得到反向后的路由出口，然后根据反向路由出口进行过滤。 当rp_filter的值为1时，要求反向路由的出口必须与数据包的入口网卡是同一块，否则就会丢弃数据包； 当rp_filter的值为2时，要求反向路由必须是可达的，如果反向路由不可达，则会丢弃该数据包； 当rp_filter的值....

正文 在Linux下抓包需要使用tcpdump命令，本文就主要对该命令进行一个简单的学习与总结。 简介 tcpdump是一个抓包工具。它能够监听、记录通过某一个主机进出的网络流量。并且可以保存到文件，或者再从文件读取抓下来的数据包。它保存下来的包也可以导入到wireshark里面，利用gui工具进行查看。当然非常重要的一点是，抓取的时候能够设置各种各样的过滤器，在海量数据里寻找有用信息。 使用 首先，使用tcpdump要使用root登录或者sudo权限，且在使用时如果不加任何参数，它会抓网络设备中第一个设备的包(不包括lo)，并且打印出每个包的简短信息。 -nn：tcpdump遇到协议号或者端口号时，不将这些号码转换成对应的协议名称或者端口名称。比如，21端口是FTP端口，我们希望直接显示21，而非FTP。 -x：告诉tcpdump命令，需要把协议头和包内容都原原本本的显示出来(tcpdump会以16进制和ASCII的形式显示)，这在进行协议分析时是绝对的利器。 -t：输出不打印时间戳 -c：设置抓取的包的个数 -s：限定包的大小，默认每个包存68bytes。加上-s选项，调整这个参....

正文 首先，编译程序时必须要加上-g参数。 简单总结一下GDB调试命令 gdb 可执行程序 // 使用调试模式 gdb 可执行程序 *.core // 进入调试模式，并查看错误信息 r/run // 运行程序 b/breakdown 文件名:行数 // 在某一行添加一个断点 p/print 变量名 // 打印变量值 watch 变量名 // 监控变量在程序运行过程中的变化 bt/backtrace // 查看栈帧信息 frame 帧号 // 进入指定栈帧 GDB(GNU Debugger)是UNIX及UNIX-like下的强大调试工具，可以调试ada,c,c++,asm,minimal,d,fortran.objective-c,go,java,pascal等语言。本文以C语言为例，介绍GDB启动调试的多种方式。 ### 启动调试 对于C程序来说，要想使程序可被调试，需要在编译时加上 **-g** 参数，保留调试信息，否则不能使用GDB进行调试，但如果不是自己编译的程序，并不知道是否带有-g参数，如何判断一个文件是否带有调试信息呢? 答：可以直接对该文件使用gdb命令，如 ```....

正文 cpp的STL并不是万能的，最近在使用STL时，发现list容器的size()方法和empty()方法的时间复杂度居然不一样，通过查阅资料发现，list中size()方法居然是对整个容器从头遍历一遍，empty()方法则是判断首尾两个指针是否相等。这样一来，在性能要求非常高的情况下，若要对list判空，则只能用empty()方法。 在网络通信过程中，性能并不完全取决于程序写的好坏，也与通信机器本身、是否绑定CPU核心、以及带宽有很大关系。在我对项目进行集成测试的时候，发现将系统部署在我的开发虚拟机上时，两个进程的通信速度就有瓶颈，而将机器部署在实际的测试机器上时，在一般速度下，这个瓶颈就自然消失了。 在记录一个坑，这个坑之前其实踩过一次了，但是我没有长记性，又踩了一次，这就是对指针取地址的这个操作了。 对于一个数组，若要对其进行操作，如memcpy，一般这样来做 char buffer[4096]; char name[30]; memcpy(name, buffer, sizeof(name)); memcpy(name, &buffer[0], sizeof(name....

前文 在实际项目开发过程中，经常会遇到一个目标文件需要使用不同目录下的源文件。如有个项目，构成如下所示: -base -base.cpp -base.h -src -makefile -%.cpp -%.h src目录下的源文件使用到了base库中的函数，因此在编译makefile时，需要用到base库，base库在另一个目录下，此时就需要使用混合编译的技巧。 正文 其实混合编译没什么技巧，只需要在编译时，将base库所在目录添加进makefile中即可。 CXXFALG = -m64 -Wall -std=c++11 BASE_PATH = ../base OBJS = $(BASE_PATH)/base.o test.o TARGET = test all:$(TARGET) @echo "Done everything successfully" $(TARGET): $(OBJS) $(CC) $(CXXFALG) -I $(BASE_PATH) $(OBJS) -o $(TARGET) %.o: %.cpp $(CC) -c $(CXXFALG) -I $(B....

正文 问题描述 在socket多播（组播）编程中，一个套接字已经加入了一个多播组，开始持续接收数据。在实时接收数据的过程中，上游多播组或者路由器发生意外，导致套接字无法接收到实时数据。然后套接字加入备多播组收取数据。过了几分钟后，原多播组或者路由器恢复正常，此时套接字是否会收到两份数据？在发生意外的情况下，如果套接字想只接收一份数据，应该怎么做呢？ 正文 目前有两个想法： 对数据进行过滤，在recvfrom()收数据的时候，如果收到的不是当前多播组发送的数据，就将其丢掉 在发生意外后，先不急着退出组播组，关闭套接字，而是先创建另一个套接字，然后再执行退出多播组，关闭套接字的操作，之后是否只会收到一份数据呢？这个想法仍需要验证 思考 如果是路由器出现问题了，那是否意味着套接字不可能再从这个路由器所在链路收到数据了呢？