<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[Network, Linux Kernel]]></title><description><![CDATA[笔记]]></description><link>https://blog.youkuaiyun.com/mrpre</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; mrpre]]></copyright><item><title><![CDATA[linux内核内存二次机会算法&refualt算法]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/162240575</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/162240575</guid><author>mrpre</author><pubDate>Tue, 23 Jun 2026 17:53:32 +0800</pubDate><description><![CDATA[linux 内核传统LRU的二次机会算法实现细节]]></description><category></category></item><item><title><![CDATA[一个存在10年的tcp建链失败的问题]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/152134117</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/152134117</guid><author>mrpre</author><pubDate>Fri, 26 Sep 2025 20:39:33 +0800</pubDate><description><![CDATA[最终的结果是什么，客户端往往三次握手和第一个数据包，是同一时间发送的出去的，服务端，如果并发处理了（当然如果正确配置了RSS或者RPS，其实不会触发这个问题，但是现实往往没那么简单），第一个ACK包进行了request_sock的摘除以及新socket的插入，但是在摘除后还未插入期间，客户端的第一个数据包进来了，就不会命中ehash，从而导致导致命中listen的socket。接着搞笑的事情又发生了，没下文了，直到最近，有人提出问题，然后开始有进展了。这个问题2015年有了。]]></description><category></category></item><item><title><![CDATA[模拟大端系统]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/145775064</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/145775064</guid><author>mrpre</author><pubDate>Fri, 21 Feb 2025 13:24:59 +0800</pubDate><description><![CDATA[首先安装交叉编译器，接着安装qemu-user-static。这里期望使用mips(大端)来演示。下面是ubuntu下的演示，centos环境搭建过于复杂。，模拟大端、小端的cpu下运行程序。]]></description><category></category></item><item><title><![CDATA[提交linux kernel patch流程]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/143483675</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/143483675</guid><author>mrpre</author><pubDate>Mon, 04 Nov 2024 14:32:56 +0800</pubDate><description><![CDATA[给linux内核提交patch流程]]></description><category></category></item><item><title><![CDATA[配置mutt访问163邮箱]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/143483526</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/143483526</guid><author>mrpre</author><pubDate>Mon, 04 Nov 2024 14:19:12 +0800</pubDate><description><![CDATA[mutt 不支持 imap id 特性，只能使用neomutt了，否则拉不到163邮箱。]]></description><category></category></item><item><title><![CDATA[无namespace下的veth+bridge实验]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/130924873</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/130924873</guid><author>mrpre</author><pubDate>Mon, 29 May 2023 11:33:26 +0800</pubDate><description><![CDATA[veth+bridge在Linux模拟交换机]]></description><category></category></item><item><title><![CDATA[Linux TCP MIB统计汇总]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/130423529</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/130423529</guid><author>mrpre</author><pubDate>Fri, 28 Apr 2023 11:49:55 +0800</pubDate><description><![CDATA[在 linux >= 4.7 才将所有TCP丢包收敛到 函数tcp_drop中。]]></description><category></category></item><item><title><![CDATA[CSI以及本地盘的相关实现记录]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/125295928</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/125295928</guid><author>mrpre</author><pubDate>Wed, 15 Jun 2022 14:14:03 +0800</pubDate><description><![CDATA[CSI有众多接口，按逻辑共分为三类，开发者需要按照需求实现对应的接口。外部组件(node-driver-registrar、external-provisioner 等)会通过unix socket+gpc调用这些接口。在CSI代码中经常可以看到这么几句话，就是注册对应的接口。
之所以分这么多类，是因为这些类是不同的外部组件分别调用的。实际上，你开发的CSI pod 完全可以全部注册这些类，然后CSI pod + External-Provisioner 部署在一起时，该CSI pod就会被调用contro]]></description><category></category></item><item><title><![CDATA[ipvs 导致syn 重传问题]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/124931671</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/124931671</guid><author>mrpre</author><pubDate>Mon, 23 May 2022 17:50:43 +0800</pubDate><description><![CDATA[(本篇讲的是IPVS自身到指的syn重传，和RS的PAWS没关系)
sysctl_conn_reuse_mode 为0 时，如果当前IPVS的session是TIME_WAIT或者其他状态，任何进来的packet都会根据当前的session进行转发。这就造成一个问题，如果客户端请求都是短连接，
那么IPVS的session都是TIME_WAIT状态，如果客户端来了一个SYN包，那么SYN包也会将当前的session变成SYN_RECV，然后不会重新调度RS。特别是，如果我们将RS权重为0，此时一个SYN过来]]></description><category></category></item><item><title><![CDATA[ip_forward 如何影响IPVS转发流程]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/124862287</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/124862287</guid><author>mrpre</author><pubDate>Thu, 19 May 2022 14:18:50 +0800</pubDate><description><![CDATA[先理清几个概念
/proc/sys/net/ipv4/ip_forward	等价于下面的 /proc/sys/net/conf/all/forwarding
/proc/sys/net/ipv4/conf/xx/forwarding   针对指定的dev xx进行设置
/proc/sys/net/ipv4/conf/all/forwarding  需要对当前所有device进行设置，当然不同的属性，all 的逻辑不一样，需要one by one的的看
/proc/sys/net/ipv4/conf/defa]]></description><category></category></item><item><title><![CDATA[PAWS 到底是什么]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/124633999</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/124633999</guid><author>mrpre</author><pubDate>Sat, 07 May 2022 16:36:12 +0800</pubDate><description><![CDATA[名词
PAWS : Protection Against Wrapping Sequence
ISN: Init sequence Number
SEQ 回环
TCP的 seq 是一个u32的递增数字，SYN和FIN会消耗一个seq，其次每个TCP的payload都会消耗对应长度的seq，也就是说，对于每一个TCP连接而言，seq是单调递增的，所以u32会溢出于是就回环了，回环本身没有什么问题，常见的通过将seq强转成有符号比较，if ((s32)current &gt; (s32)last)，永远能简单高]]></description><category></category></item><item><title><![CDATA[netlink 读取数据流程]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/124369965</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/124369965</guid><author>mrpre</author><pubDate>Sat, 23 Apr 2022 21:23:32 +0800</pubDate><description><![CDATA[前言
本篇缘起是我要实现类似ss -i 的功能，通过netlink获取系统中的所有socket信息
代码如下
//发送tcpdiag的数据
sendto(netlinkdf, msg,...)
//sleep足够时间，使得内核处理
//因为每次都读取少部分数据，以为内核没来得及处理
sleep(10)

char buffer[10000]
len = recvfrom(buffer, sizeof(buffer), 0);

上面流程中，recvfrom 返回的字节大小，小于buffer大小，理应我们认为]]></description><category></category></item><item><title><![CDATA[tcp_diag 内核相关实现 以及调用层次]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/124348400</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/124348400</guid><author>mrpre</author><pubDate>Fri, 22 Apr 2022 16:09:19 +0800</pubDate><description><![CDATA[tcp_diag 内核相关实现
前言
tcp_diag 是一个内核模块，本文的目的是梳理调用关系，如果从用户态的socket一路调用到tcp_diag模块dump出所有socket的。
大致分层关系 总结如下：netlink层-&gt;sock_diag层-&gt;inet_diag层-&gt;tcp_diag
用户态代码
类似 ss 功能的代码可以从 https://man7.org/linux/man-pages/man7/sock_diag.7.html 中获得，但是它只是打印 unix_socket]]></description><category></category></item><item><title><![CDATA[浅谈skiplist在LevelDB的应用]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/119778933</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/119778933</guid><author>mrpre</author><pubDate>Wed, 18 Aug 2021 14:12:14 +0800</pubDate><description><![CDATA[什么是跳表
具体参考 http://zhangtielei.com/posts/blog-redis-skiplist.html
Leveldb 为什么用跳表
首先 skiplist作为memtable的数据结构，如果光为了存储kv，那么任何数据结构都能被使用，像Redis的dict。但是 LevelDB 有个特性，就是put 2个相同的key，那么2份相同的key会同时存在于 memtable 中，而不是通常人们理解的使用新的value把老的value替换掉。这就意味着，get时需要保证取到的是新的val]]></description><category></category></item><item><title><![CDATA[flannel 原理 之 TUN模式]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/115180402</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/115180402</guid><author>mrpre</author><pubDate>Wed, 24 Mar 2021 16:32:13 +0800</pubDate><description><![CDATA[flannel 原理 之 TUN模式
首先，TUN模式 原理详见 https://wonderful.blog.youkuaiyun.com/article/details/113105456 ，通常用来两个私网通过公网穿越。总的来说要熟悉掌握TUN设备的特性，被路由到TUN设备发出去的数据，都会被Open TUN的socket读到，做到拦截；write到TUN的数据，都会被TUN重放到协议栈，模拟了TUN设备所在的机器收包操作。
流程
假设当前 2台node node1为11.238.116.75 node2的物理I]]></description><category></category></item><item><title><![CDATA[flannel 原理 之 子网划分]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/115180077</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/115180077</guid><author>mrpre</author><pubDate>Wed, 24 Mar 2021 16:26:17 +0800</pubDate><description><![CDATA[flannel 原理 之 子网划分
Docker
通常情况下， 2台物理机上分别安装Docker，Docker分别在2台物理机上，docker0的网桥，其IP地址属于私网网段，例如物理机地址是10.x.x.x，docker0地址通常是192.x.x.x。 任何在物理机上启动的container，其分配的eth0地址都是 192.x.x.x。 但是2台独立的物理机上的container之间是无法通信的，因为物理网络里是没有192.x.x.x网段的信息，无法对其进行路由，更何况物理网络作为基础设施，也不可能动态]]></description><category></category></item><item><title><![CDATA[TUN 设备原理]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/113105456</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/113105456</guid><author>mrpre</author><pubDate>Mon, 25 Jan 2021 10:58:27 +0800</pubDate><description><![CDATA[TUN 设备原理
本文要解决的就是 sslvpn 的运行机制。例如如何使用tun设备，是的连个独立的私网ip能够跨公网访问
simpletun
首先玩一下简单的例子 https://github.com/gregnietsky/simpletun.git 然后有个直观的感受
我们找2台机器 分别使用make命令编译上述代码，生成 二进制 simpletun
A物理ip 11.238.116.73
B物理ip 11.238.116.75

在B机器上执行
sudo ./simpletun -i tun90 -]]></description><category></category></item><item><title><![CDATA[Redis cluster 原理]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/109338757</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/109338757</guid><author>mrpre</author><pubDate>Wed, 28 Oct 2020 17:47:45 +0800</pubDate><description><![CDATA[Redis cluster 原理
Redis cluster 设计文档可见:
https://redis.io/topics/cluster-spec#configuration-handling-propagation-and-failovers
相关资料
https://chanjarster.github.io/post/redis-cluster-config-propagation/
在当前Redis6.0的版本中，可以使用 redis-cli --cluster create命令来规划一个集群，]]></description><category></category></item><item><title><![CDATA[redis 模块编程中 key value的生命周期]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/107613573</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/107613573</guid><author>mrpre</author><pubDate>Mon, 27 Jul 2020 15:56:46 +0800</pubDate><description><![CDATA[RedisModule_OpenKey
本节探讨下 RedisModule_OpenKey 中 key-value 何时释放。
首先   的数据结构如下
struct RedisModuleKey {
    ....
    robj *key;
    robj *value;
    ....
}

我们关心的是 RedisModuleKey 本身以及 其中  的 key和value值的生命周期
RedisModuleKey 本身 通过 RedisModule_OpenKey申请，模块内存管理自动将 ]]></description><category></category></item><item><title><![CDATA[Golang 对分片 append 是否会共享数据]]></title><link>https://blog.youkuaiyun.com/mrpre/article/details/107486979</link><guid>https://blog.youkuaiyun.com/mrpre/article/details/107486979</guid><author>mrpre</author><pubDate>Tue, 21 Jul 2020 13:38:50 +0800</pubDate><description><![CDATA[Golang 对分片 append 是否会共享数据
Golang 官方对 slice 的说明见文章：https://blog.golang.org/slices-intro 大部分特别是前半部分，写的非常详细，但是最后关于append相关部分，就让人感觉浅尝辄止了。
首先，先写结论：append 返回的slice对象，有可能会共享入参slice的底层（意味着对返回对象slice的赋值会影响入参slice）也可能不共享入参slice的底层。
先给几个例子
例1：
package main

import (
]]></description><category></category></item></channel></rss>