我也要用- 博客(1729)
- 资源 (4)
- 论坛 (5)
- 收藏
- 关注
RSS订阅
原创 闲谈IPv6系列文章集锦
本文总结一个目录提纲，只要是给自己看的，记录一下哪些东西已经总结过了。闲谈IPv6-6to4隧道和ISATAP隧道： https://blog.csdn.net/dog250/article/details/88644797闲谈IPv6-说说IPv6地址分配和BGP： https://blog.csdn.net/dog250/article/details/88430415闲谈IPv6...
2019-03-18 22:38:43
36394
15
原创 从电话网到IP互联网再到CDN
电话网中的操作，最终目标是找到一根通往被叫端的插口，然后把主叫来自的电线插入被叫的插口。这显然是一个中心化的操作。TCP/IP网络中的操作，最终目标是找到一台标识目标IP地址的主机，中间节点的操作显然只是找到下一跳即可，这显然是一个分布式的操作。NDN/CDN网的操作，最终目标是找到内容，只要遇到匹配(摘要签名对应，这涉及到了非对称密码技术)的内容，返回即可。我们一直都觉得TCP/IP网络很完美，但我们在互联网中的所有操作真的是为了寻址一个IP地址吗？我们寻址的明明是内容啊。进一步，地址能标识内.
2021-04-10 11:25:44
1796
2
原创 UDP实现高并发其实非常简单(续集)
上周放假时跟着小小学python，就写了一个所谓 “高并发UDP服务器” ，详见：https://blog.csdn.net/dog250/article/details/115413967之所以这么写是因为我想让UDP服务看起来像TCP服务而已，但还是发现了新东西。我所谓的 服务 ，专门指的是那种长连接，高并发的服务。在上面这个随笔里，我的观点是 让socket的数量上去，并发也就上去了，剩下的就交给CPU了 ，因此最直接的方式就是预先创建海量的reuseport UDP socket，bind到
2021-04-10 09:56:56
571
原创 伪造ACK实现TCP数据注入
TCP创造并发展于1970年代～1980年代，这注定了它能工作但脆弱。在TCP伊始，最重要的是可用，而不是高效，也不是安全，因此，在端到端TCP连接的中间，利用伪造的ACK，你很容易完成一种叫做 中间人攻击 的事情。如果你用“TCP劫持”，“TCP中间人”，“TCP注入”等作为关键词百度或者Google，绝大部分内容都在SYN报文上做文章，诸如会话Reset，会话劫持，SYN Flood攻击等等，但实际上还有更好玩的恶作剧。通过在中间路径上伪造ACK，你可以：提前确认数据，扰乱TCP的ACK时钟，
2021-04-04 13:09:23
1187
4
原创 UDP实现高并发其实非常简单
UDP越来越被重视了，人们期望它和TCP一样，但是呢？…UDP能不能像TCP那样做高并发？内核早在3.9版本就支持REUSEPORT了，但直到2015年底，我也只能做个表面上(看起来像那么回事，但实际上就是垃圾的东西)的东西：https://blog.csdn.net/dog250/article/details/17061277但也只是看起来像，除此之外，我当时的想法相当于垃圾。UDP做高并发非常简单，和TCP的accept模型似乎没有什么区别，下面是一个随手撸的代码，主要是跟着小小学pytho
2021-04-03 11:30:03
913
原创 隐藏与篡改Linux命令行参数
如果一个程序的命令行是一个password之类的不便展示的字符串，如何不让ps打印出来呢？ps是从/proc/$pid/cmdline里拿的命令行，而/proc/$pid/cmdline则是在内核空间解析用户程序的stack区域获取的数据，那么答案很简单，只需要覆盖掉这个区域即可，下面是个示例：#include <stdio.h>#include <stdlib.h>#include <string.h>int main(int argc, char **ar
2021-04-03 08:31:10
7212
6
原创 漫谈分组交换网之二
倒退？螺旋上升？电话网络在持续接近100年的时间一直都是网络的代名词，冷战时期出炉的分布式去中心化分组交换网在30年后便被一种叫做SDN的理念挑战，这意味着什么？谁才是正确的？曾经的电话网络是被巨头主宰的，如今的互联网又有同样的趋势，然而互联网不是去中心化的吗？互联网先锋们曾经嘲笑电话网就是一个接线的网络，让他们看看现如今的SD-WAN，是不是也是一个接线的网络呢？逻辑的“线”代替了昔日的“铜线”而已。一切都在重复，云计算和昔日哑终端登录何异？Google和贝尔何异？就看谁掌握资源了。在电线是资
2021-03-27 20:12:18
1053
原创 漫谈分组交换网
这是一篇散文，不讲技术讲历史的。为什么写这么一篇在绝大多数同行看来毫无意义的文科手笔呢，其实正是想讽刺这些人。互联网和电话网的差异就是 分组交换 和 电路交换 吗？教科书上就是这么讲的，但这就够了吗？远远不够，所以我补充下缺失的部分。19世纪电话的发明是人类通信史上的创举。电话的意义不在电话本身，而在于越来越多的电话构成的越来越复杂的网络，而这张网络正是现代互联网的前身。如果这张网络一开始就是完美的，便谈不上进化了，幸运的是，它离完美太远，缺陷太多。我们先看下原始的电话网是如何工作的：电话之
2021-03-27 10:25:28
735
原创 我为什么反对把Enter作为发送快捷键
微信，QQ，飞书，钉钉等常用社交软件电脑版默认会把Enter设置为“发送”快捷键，我是很反对的。上个月有同事在群里问如何获取一个转瞬即逝的进程的全路径，显然查/proc/$pid/cmdline的话怕是手速不够快，由于迄至5.x版本的Linux内核API已经足够丰富，以至于已经天然支持了获取全路径的API，即 get_cmdline 。我快速在我自己的虚拟机里进行尝试：#!/usr/bin/stap -g%{#include <linux/skbuff.h>#include <
2021-03-21 11:52:06
1257
5
原创 tayga nat64优化的自省揭示tun虚拟网卡的正确玩法
tayga可以完成NAT64转换，它看起来阵势很大，一般能用yum/apt-get直接源上安装的软件都是信得过的软件，我也因此信得过tayga，无论是功能，还是性能。所以我也就没有去看它的代码，直接拿来主义使用了。可是tayga的大并发测试远不达预期，它竟然是一个使用单队列tun网卡的单进程单线程程序，其结构就是一个大循环：tayga不停地从tun字符设备读取IPv6或者IPv4报文，经过6-4/4-6转换后再发回该tun字符设备。看到这般场景，我的老毛病便又犯了。用多个线程分别执行大循环。用多队
2021-03-20 08:04:32
941
1
原创 tun虚拟网卡该怎么玩不该怎么玩
tun设备多用来在用户态模拟网络转发设备，比如隧道的端点，路由器，NAT网关等，但作为转发设备的模拟，其编程模型和作为数据始发站的服务器编程模型有着大不同。我们先看一下最简单的tun程序模型：tun字符设备和TCP/UDP socket连接作为文件描述符被均等地poll，将从一个fd收到的数据经过加工之后写入另一个fd。但这种思路是错误的。是不是觉得性能底下，而tun设备有多队列模式，可以将一个tun虚拟网卡打开为多个文件描述符，下面的样子：但还是不对。哪里出了问题呢？接下来我基于上述的 单体结
2021-03-20 07:44:58
997
1
原创 我们为什么不能多丢点儿TCP的ACK报文呢？
TCP的拥塞控制需要ACK形成的self-clock来促使数据包的继续发送，但这只是1988年范雅各布森的观点，即 保持VJ管道的满载但不溢出的理想 。显然，这个理想直到今天也没有实现。后来BBR把VJ管道改造了，以pacing rate而不是cwnd才进行拥塞控制，然而不管怎么说，pacing rate也是依赖ACK的，只是没有AIMD那么重度依赖而已，self-clock可以弱化，甚至取消。这意味着不需要连续的ACK了，只要能采集到一个max bandwidth，并且在一个既定的max-filter
2021-03-13 11:43:49
1119
原创 漫谈TCP BBR的收敛动力学(convergence dynamics)
如果一个算法的某处说明没有数学支撑，那肯定是不能令人放心的，BBR的收敛性模型从来都是模糊的，不如AIMD那样直接，但还是有一些有意思的动力学过程在里面的。在Neal Cardwell的github里藏着一篇关于BBR收敛动力学的文档 BBR bandwidth-based convergence ：https://github.com/google/bbr/commit/c38ae279b67fe1e9b485903daa3f808f7c6e44d4这篇文档的结论是：初始化带宽越小的流在up p
2021-03-13 10:09:52
1094
1
原创 十年前范雅各布森关于bufferbloat的讨论
周末下雨，在家扒拉了几篇10年前的论文。我主要是有个疑问，BBR真的是Von Jacobson的idea吗？毕竟论文作者有他的名字，我想知道范雅各布森在BBR里的角色是什么。但我没有找到。不过还是挖出一些有趣的东西。2011年的一篇论文《BufferBloat: What’s Wrong with the Internet?》：https://queue.acm.org/detail.cfm?id=2076798这一篇是一个关于bufferbloat的讨论，我摘录了其中有趣的一些段落。配置大bu
2021-03-07 10:19:29
1859
6
原创 在Linux内核接收路径查找top 1的IP地址
在实际工作中，我终于遇到了一些实实在在的面试题：算法题：一个包含海量节点的无序链表，已知里面有多个重复元素，找出重复次数最多的那个，给出时间复杂度。比如20-1-2-3-5-7-3-20-12-3，重复元素有3个3，2个20答案显然是3。在进行流量分析，DDoS检测与防护，流量清洗等动作时，一个很常见的需求就是“求top N”，与之相关的算法可谓汗牛充栋：排序最大堆LRUBitmap counter…理论算法很多，但在实战中总是会碰到各种工程问题，比如说并发操作的锁开销不可避免，那么
2021-03-06 09:26:17
1435
原创 漫谈TCP BBR正当时
上周随意发的一篇朋友圈，引出本文：但凡有信道仲裁的地方就不能用self–clock，这就跟我之前说的很多vpn是半双工处理一样，这是wifi，xG的根本问题，用pacing代替burst，这是创举自时钟和channel仲裁的冲突，（同一个链路，交替突发，自时钟相互影响。与我之前说的收发在同一个线程类似）bbr弃用自时钟，保持pacing，ack只是用来测量带宽长rtt打开窗口慢将不再是问题，因为不再需要所谓“打开窗口”了。"pacing_rate is BBR’s primary contr
2021-03-06 07:36:51
1440
原创 漫谈TCP加速的笑话
人们普遍对拥塞控制存在误解。人们普遍认为设计一个牛逼的拥塞控制算法就能提高TCP的传输性能。人们普遍认为拥塞控制是为优化存在的。不仅仅如此。人们普遍认为有意义的事都是为优化而存在的。我记得我高中的时候，数学老师讲完一道题的巧妙解之后，我总是在下面嚷嚷我还有更麻烦的方法来解这道题，我的意思是不想等下课了大家一个个来问我问题，与其如此，我还不如公开一种大家都懂但更麻烦的方法呢，当大家都在追求奇技淫巧时，我显得有点特立独行。与此类似，TCP的拥塞控制就是一种麻烦的方法，加上拥塞控制机制之后，数据可能传
2021-02-27 11:31:28
6975
23
原创 漫谈TCP bufferbloat的根源-Jacobson管道
在前面的文章中，我经常提到bufferbloat，关于这个词的解释，我几乎都是明嘲暗讽地把锅甩到Reno/CUBIC这类基于AIMD的算法身上，声称它们是 buffer友好的 ，必须填充buffer的 ， 随之而来的就有设备厂商的推波助澜，用越来越大的buffer赢得用户的普遍认可，反过来促进buffer进一步被Reno/CUBIC填满，如此一个类似Windows-Intel的循环…然而这却不是本质，那么本质是什么？还得从Jacobson的原始论文中挖掘：http://www.cs.binghamton
2021-02-27 08:41:02
1676
原创 漫谈TCP新算法Elastic-TCP
自适应的CCA(Congestion Control Algorithm)给人一种简洁明快的感觉。Elastic-TCP是一种新近的算法，比BBR还新，但比BBR简洁多了，可以从Wiki上了解其大概：Elastic-TCP has been proposed in February 2019 by Mohamed A. Alrshah et al. to increase the bandwidth utilization over high-BDP networks to support recen
2021-02-27 06:19:40
1676
原创 漫谈TCP High Speed与TCP Africa(TCP China)
回到朴素的Reno，我们知道它是一个典型的AIMD算法。Reno算法非常简单：AI过程：拥塞避免阶段每一个RTT增加一个窗口。MD过程：遭遇丢包时，窗口减到原来的一半。但AIMD是一个一般性的算法，Reno只是其中的一个实例解而已，因此把AIMD的描述一般化是合适的：AI过程：拥塞避免阶段每一个RTT增加aaa个窗口。MD过程：遭遇丢包时，窗口减少原来的bbb，即减少到(1−b)W(1-b)W(1−b)W。我们看它锯齿状的cwnd-time图：设丢包时最大的窗口为WWW， 很容易算
2021-02-21 09:59:49
2044
原创 漫谈TCP Vegas如何收敛到公平
TCP Vegas，嗯，TCP维加斯，维加斯，你好。Vegas是一个典型的AIAD算法。我不是常说AIMD可以收敛到公平吗？这是有控制论作为理论基础的，AIAD，MIMD无论如何都不可能收敛，它们要么原地打转，要么正反馈到彻底失控。知道你的魔改为什么让事情更糟糕了吗？因为你不懂控制论，你的魔改可能造成了正反馈，类似把话筒对着喇叭的那种。可是Vegas就是一个AIAD算法啊。Why Vegas？其它算法都是在到达同步点实施Decrease操作的，可是Vegas的同步点是分布式的，所以在任何一个
2021-02-15 20:26:11
2378
3
原创 漫谈TCP Westwood和BBR
我很想知道westwood算法的深意，不仅仅是算法本身，还包括它的名字。是的，为什么叫westwood？有朋友告诉我这是一个地名，并建议我去美国西海岸转一圈，然后我就发现IT圈子里不明所以看起来高大上的名字都是地名，并不比石家庄，驻马店，后厂村，西二旗什么的高级，我就放心了，原来如此。后来我在wiki上确认了一下，果然如此：The name “Westwood” was chosen by S. Mascolo as due homage to the home of UCLA where he w
2021-02-13 22:22:07
6715
3
原创 漫谈bufferbloat以及TCP公平性
昨天大年三十下了一整天雨，去了一趟上海迪士尼，非常惊喜，人非常少，全程不用排队，几乎玩遍了所有的项目，估摸着以后是不会再去了。如果没有人排队，那些占地面积巨大的迂回曲折的综合排队设施就很尴尬地完全成了摆设，但你依然不得不 “迂回曲折” 地经过它们，即便是一路小跑，也要花不少的时间绕过那九曲回廊，如果你是第一次去，还以为穿过这种迷宫式的九曲回廊是项目的一部分呢。…都没人排队了，要这些排队设施还有什么用？本文接着前天那篇接着写：https://blog.csdn.net/dog250/article/
2021-02-12 08:31:17
3762
5
原创 漫谈BBR算法的收敛点和公平性
明天大年三十，去趟迪士尼，今天下班早，睡前写下这篇，结束这一农历年。其实写这篇的初衷起因于我对那些看见4个窗口就想加到8个窗口的人鄙视，并且这些人几乎都是狂暴之人，我发现那些做业务逻辑的只要懂点TCP都不会好好说话，事实上他们大多数人什么都不懂，只有什么都不懂的人才会自以为是，天天鄙视别人。对于TCP的优化，我听过无数遍 “丢包就慢点降窗，不丢包就快点增窗呗，这还不简单！” 我只是觉得他们只想炫耀。就像我很讨厌网吧的网管以及阿里巴巴的运维一样，我也很讨厌那些对TCP夸夸其谈却给不出任何建设性建议的人，
2021-02-10 21:59:25
6958
10
原创 请不要裸操作sk_buff，请使用sk_buff的API
写这篇文章，我只是为了嘲笑我自己。我其实什么都不懂。我总是觉得sk_buff的API太难用了，但也可能是我不会用才会这么认为…无论如何，我一直不喜欢这个东西。为了证明TCP/UDP的校验和的脆弱性，我想演示一个效果，即交换一下TCP的payload的两个uint16值，它的校验和保持不变，所以我们必须为每一个文件单独再生成一个MD5文件。我的代码是这么写的：unsigned short *pstart, tmp;...tcph = (struct tcphdr *)((char *)iph +
2021-02-06 12:09:04
2485
3
原创 聊聊运营商对UDP的QoS限制和应对
UDP和运营商有什么关系？这个问题有点大且突兀。只要不是在三大运营商上班的，其实我们都是端到端用户，而端到端用户对于网络的认知必然是盲目的，我们不知道路由器对我们的流量做了什么，我们更没有能力去控制它们，我们只能猜测。本来一个技术范畴的讨论一旦涉及到了猜测，就不是技术讨论了，而是社会学讨论，这往往会带来无休止的辩论，争吵，在此其中，独占鳌头的往往不是靠技术实力，而是靠口才和措辞，或者还有夹杂着各种手势的抑扬顿挫。我是极其讨厌充斥着此类调调的场合的，我在这种场合往往会选择闭嘴，然后离开。人们无休止地讨
2021-02-06 11:33:48
9426
7
原创 漫谈TCP-AIMD/BBR的公平性以及buffer bloat
周三的时候，我发了一则朋友圈：aimd是公平的这个事实很容易从数学上证明，但是朴素的aimd会带来全局同步。解决reno家族全局同步的策略就是概率性随机丢弃，避免所有流同时md，然而bbr却没法从数学上证明这种策略是公平的，至少我是证明不了。。。周六早上3，4点钟自然醒，写篇意识流。了解TCP Reno/CUBIC的都应该知道，基于AIMD的Reno家族的窗口/时间曲线是一个锯齿状。锯齿看似是固有的，不可消除的，因为包括CUBIC在内的Reno家族CC(congestion control)
2021-01-30 08:28:39
8051
7
原创 简单基于tun实现的用户态NAT64
嗯，但还是想实现一个完整的用户态NAT64，今天上班，所以没多少时间，下班到家正好家人还没睡，在看殷墟考古(参与殷墟挖掘的尹焕章是我老婆的外婆的爸爸…鲜卑人的后裔…我老婆也是继承祖业，然而也仅仅是爱好，整天研究盗墓之类的把戏…)，我也就可以再折腾一会儿了。写点感悟吧。昨天下午实现了一个NAT64简版，只是一个ICMP单流的NAT64转换，验证一下可信性而已。代码如下：https://github.com/marywangran/simpletun/blob/main/tunnat64.c效果写在RE
2021-01-24 22:00:04
2812
2
原创 像玩乐高一样玩simpletun
netcat小巧而灵活，能应付各种你需要的网络测试。但要明白netcat所能应对的网络场景基本都和端到端有关，比如和TCP，UDP有关。网络还有另一面，即链路本身。如果你想模拟一个防火墙，模拟一个NAT怎么办？用netcat能做到吗？这个时候你可能就必须自己写内核模块了吧。Netfilter？eBPF？NFV？这些都太复杂了！可以在用户态完成的时候就尽量在用户态搞，简单稳定最重要。我推荐simpletun。simpletun并不是某个著名的开源软件，但是在网上一找可以找一大片，随便找一个杂耍即可
2021-01-23 08:51:03
8428
9
原创 长肥管道(LFT)中TCP的艰难处境与打法
一年多没有深夜惊起而作文了，又逢雨夜，总结一些思路。带宽一定的情况下，网络的吞吐理论上不受时延的影响，虽然管道长了一点，但截面积是一定的。然而当你用TCP去验证这一结论时，往往得不到你想要的结果：一个长肥管道很难被单条TCP连接填满(一条TCP流很难在长肥管道中达到额定带宽)！我们做以下拓扑：首先我测算裸带宽作为基准。测试接收端为172.16.0.2，执行iperf -s，测试发送端执行：iperf -c 172.16.0.2 -i 1 -P 1 -t 2结果如下：------
2021-01-23 08:19:15
3807
13
原创 谁动了你的五元组-nf_conntrack与NAT的性能
在互联网上一个五元组标识一个应用程序到远端的另一个应用程序的连接。要保证端到端的可达性，显然在全局范围内，五元组必须是唯一的。保证五元组的全局唯一性看起来是个重体力劳动，以IPv4网络为例，仅仅考虑TCP和UDP，一个五元组空间包括两个32位IPv4地址，两个16位端口以及一个协议，总共232×2+16×2+12^{32\times 2+16\times 2+1}232×2+16×2+1种组合。穷尽这么大一个空间来寻找一个没有被使用的元组绝对是重体力劳动。然而在分布式的互联网环境，五元组的全局唯一性其实
2021-01-16 10:50:20
2668
1
原创 网络Midbox处理TCP的方式对TCP吞吐的影响
昨天下班的路上，我发了一则朋友圈：今天抓到一条大鱼，隧道的TCP载荷吞吐提升一倍多，哈哈，周末愉快！很多隧道都用同一个线程处理同一个tcp流，这显然不对，应该用不同的线程分别处理一个流的两个方向。但很多用户态隧道都是同一个线程处理同一条tcp连接的，这是问题。这个问题在很多人看来真的很low，依然是那种不过如此的问题，因为怕被笑话，我故意把事情说的很low，但这只是一种措辞处理的技巧，本来这事儿就这么过去了。但深入思考是我的习惯，我发现这竟然是一个普遍的问题，就准备记录下来。这不是一个和性
2021-01-16 09:14:48
2449
原创 谁动了你的五元组-Linux Netfilter NAT之nf_nat_alloc_null_binding
Linux的Netfilter NAT实现中，为什么会有一个nf_nat_alloc_null_binding(在低版本内核比如2.6，它叫alloc_null_binding)调用？该函数是在一条流没有命中任何NAT规则的时候调用了，其内部实现和对待命中了NAT规则的流的方式几乎一样，唯一的约束是，它只能修改一条流的源端口。问题是，既然没有命中任何规则，为什么要修改流的源端口呢？我早就想好好解释一下这个问题了，但我一直觉得有人已经解释过了，所以就没有写任何东西。周二下午家里有事正好休假，等待期
2021-01-16 07:08:16
2448
原创 手艺人舍bpftrace而取systemtap的代价和思考
上个礼拜我就想喷eBPF了，由于周末时间实在太紧，就准备拖延一周，但还是立了个flag，先发了个朋友圈：ebpf就像牛皮藓一样，已经遍布在linux内核的各个角落，每个调用点都看上去很随意，毫无规划，让人觉得好像自己觉得哪里需要这么一个调用点并不很难…但实际上如果你真的去尝试在某处加一个ebpf调用点时，就会觉得这件事和清除牛皮藓的过程非常类似，修改散落在各个目录的多个文件，还得重新编译，大概率失败，还要重新做一次，很难一次做干净，当你好不容易成功了，会有一种“不过如此”的嗟叹…我曾将ebpf比
2021-01-09 08:25:47
10711
8
原创 Linux Netfilter/NAT的两个典型问题
上周有一天下班回家路上，在一个三流技术群被一群网络新手和大佬一起鄙视是什么感觉？只因为我在讨论Netfilter而没有说eBPF，XDP，DPDK？嗯，我必须好好说道说道。十年前以及更久，那是Netfilter的黄金时期，几乎任何网络相关的功能，均可以在Netfilter上实现，当时懂Netfilter的人绝对是Linux网络领域的大佬，但是随着进入了移动互联网时代，互联网巨头们在大流量大并发的大背景驱使下，Linux内核协议栈已经显得力不从心，于是各种优化手段蜂拥而至，几乎革了内核协议栈的命。人们将协
2021-01-01 11:27:00
3173
1
原创 第一次使用Linux内核的Tracepoint的体验
我并不觉得丢人，一点也不。我是说我工作这么多年做和Linux内核相关的事，竟然在上上周才第一次使用tracepoint。这并不奇怪，我不会的东西还多着呢，比方说，我一直强调的，我不会编程，我也不会用git。言归正传，如果这么多年我都没用过tracepoint，那么作为替代，我用什么呢？如果我调试内核或者调试内核模块，最最最常用的方法就是在代码里加一条printk(如果是用户态程序，我就加一条printf。)，我来告诉你理由：printk/printf 不需要安装任何别的依赖包。printk/p
2021-01-01 10:36:55
3018
原创 IPv6 socket侦听in6addr_any的问题
当我们 netstat -lnt 查看本机侦听端口的时候，经常会看到类似下面的展示：tcp6 0 0 :::22 :::* LISTEN 658/sshd: /usr/sbin显然，sshd创建了一个IPv6 socket，在in6addr_any地址上侦听22号端口。此时，我用一个该机器的IPv4地址去连接22号端口，通还是不通呢？为了避开无关的讨论，我假设net.ipv6.bindv6onl
2021-01-01 08:27:10
2295
原创 闲谈IPv6-为了每一粒沙，真实的代价！
周六早上，哈哈，喷一篇无关紧要的。IPv6最经典的广告词，可以为地球上每一粒沙子分配一个IP地址。提起IPv6，人们总是用这句话形容其地址之多，多到一个这么一个形象的天文数字。到底能不能为地球上每一粒沙子分配一个IPv6地址我们姑且不论，假设这是真的，我这里想摆一摆的是，存储所有的IPv6地址需要多大的物理空间。注意！是物理空间，只有这样才能体现出实施IPv6真实的，现实中的代价。一粒沙子到底多大呢？经常看到有人实际计算地球上沙子数量的时候用毫米做尺寸量级，但实际上那不是沙子，那是珠子。真正的沙
2020-12-26 09:10:32
3342
1
原创 Linux soft lockup时远程调试的可能性
曾经写过一个模块，当运行Linux内核的机器死机时，SSH肯定无法登录了，但只要它还响应中断，就尽力让它可以通过网络带回一些信息。陈年的事了：https://blog.csdn.net/dog250/article/details/43370611今日重提这件事，不陌生，但纠结。本文不谈sysrq，也不谈别的。Linux内核在发生soft lockup的时候，是可以ping通的，只要没有关中断，ping通一般没有问题。既然可以ping通，何必不带回一些真正重要的信息而不仅仅是echo的reply？
2020-12-19 11:08:14
9310
7
原创 IPv6的TSO/GRO/GSO及其Linux实现的不妥
很明确的一件事是，IPv6不允许中间设备对报文分片。具体为什么这么设计，就是为了简单高效。因此，IPv6报头简洁了不少。但TSO貌似并未违背取消IPv6分片的初衷，硬件把一些都处理的妥妥的，在路由软件层看来，一切好像没有发生过一样。我先简单解释一下TSO和IP分片的区别：我们来看一个简单的实验，用IPv6从服务端拉一个大文件，服务端和客户端的抓包如下：在客户端看来，没有IP分片，因此它不需要做分片重组的动作，它实实在在就是收到了一个完整的7140字节的报文，就好像这个报文就是从服务端真实发出的一
2020-12-19 09:02:21
3367
3
关于linux内核以及其他个人体会的文集
2009-09-07
一个iptables的stateless NAT模块实现
2014-12-27
模块化的nf-HiPAC
2014-11-21
dog250的留言板
发表于 2020-01-02 最后回复 2020-03-21
我的blog为何被屏蔽了，用户名为：dog250
发表于 2009-02-06 最后回复 2017-04-05
《java编程思想》的内容哪里体现了“思想”
发表于 2014-04-01 最后回复 2015-08-26
我的blog被删了，共享文章
发表于 2009-02-07 最后回复 2010-05-14
请删除我的一个资源 【解决并回复】
发表于 2010-04-18 最后回复 2010-05-14
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人 TA的粉丝