dog250
码龄14年
  • 15,386,986
    被访问
  • 1,815
    原创
  • 8
    排名
  • 24,718
    粉丝
关注
提问 私信
  • 加入CSDN时间: 2008-03-06
博客简介:

Netfilter,iptables/OpenVPN/TCP guard:-(

博客描述:
我不会编程,但也不是一点都不会,我稍微会一些 :-)
查看详细资料
  • 8
    领奖
    总分 5,977 当月 264
个人成就
  • 博客专家认证
  • 获得8,036次点赞
  • 内容获得5,118次评论
  • 获得13,227次收藏
  • GitHub 获得255Stars
创作历程
  • 60篇
    2022年
  • 88篇
    2021年
  • 154篇
    2020年
  • 144篇
    2019年
  • 105篇
    2018年
  • 63篇
    2017年
  • 96篇
    2016年
  • 76篇
    2015年
  • 90篇
    2014年
  • 104篇
    2013年
  • 101篇
    2012年
  • 151篇
    2011年
  • 597篇
    2010年
  • 8篇
    2009年
成就勋章
TA的专栏
  • 笔记
    2篇
  • linux内核
    10篇
  • linux系统
    1篇
  • linux编程
  • windows编程
  • 历史研究
  • 帖子收藏
    1篇
  • 帖子收藏
    1篇
  • 思想者
    4篇
  • 操作系统设计
  • 数学和算法
    5篇
  • 杂感
    7篇
  • 系统设计
    2篇
  • linux tcp
    1篇
  • 最近
  • 文章
  • 资源
  • 问答
  • 帖子
  • 视频
  • 课程
  • 关注/订阅/互动
  • 收藏
搜TA的内容
搜索 取消

TCP滑动窗口辩证考

做新传输协议,必须忘掉TCP。要是总记得TCP,就会潜意识中往TCP靠,TCP那些不合时宜的东西会影响认知和判断。曾经我将TCP通告窗口标量化做隧道协议,效果不错,所以我想将TCP本身的通告窗口也标量化。标量化就是通告窗口不再和序列号相关,仅代表允许发送的配额。要理解TCP滑动窗口为何不合时宜,要从最初开始。TCP最初是纯粹的GBN(Go-back-N)协议,没有SACK,没有ofoq,为支持GBN,滑动窗口是端到端流控的唯一选择,若UNA丢失,在它之后发送的数据均不会被接收。引入SACK后,接收端
原创
发布博客 58 分钟前 ·
9 阅读 ·
0 点赞 ·
0 评论

TCP和宽容

网络对TCP很宽容,但TCP对网络并不宽容,这意味着转发节点必须小心翼翼处理TCP。核心IP网络本是尽力而为,面对TCP却有使不上劲儿的感觉。本文后面我会讲一个故事,在这个故事前,我先描述结论。转发节点无法并行处理同一条TCP流。若串行化,会有新问题,单程串行将影响TCP的burst,order pacing时序。转发节点的资源分配和利用严重影响TCP流的形态。无论两个CPU并行处理两个长程,还是分别处理一个半程,总吞吐和单包总延时都不变,不同的是对burst,order pacing的影响。两个并行
原创
发布博客 2022.05.20 ·
342 阅读 ·
2 点赞 ·
0 评论

TCP是“第一个系统”

人类一共创造三个系统:第一个系统是原型系统,仓促的原型,一小撮爱好者造就,精简,刚刚够用,不多也不少。第二个系统是经理系统,经理组织无数次会议讨论再讨论设计而成,臃肿低效满足完备性。第三个系统回归到现实,在第一个系统上叠加做了减法的第二个系统,是沉淀的结晶。TCP属于第一个系统。这可以解释为什么它的性能差,以及为什么难以优化。TCP从来没被设计过,仅为实现字节流的可靠传输而为之,不多也不少。甚至IP从TCP分离出来形成两个层也是几年后的事。最初的TCP和性能不沾边,完全不在考虑范畴,甚至拥塞控
原创
发布博客 2022.05.20 ·
401 阅读 ·
2 点赞 ·
0 评论

吞吐优化札记

wireguard-go的转发模型相当棒,它将整个流程分成了3段流水线接力,下面是一个方向的逻辑,另一个方向省略:​加密池的设计好。考虑到加密是耗时操作,要减少串行加密延时,多个goroutine并行加密多个packet是不错的,但要加一个保序逻辑,上图中的Lock/UnLock就是干这个的。但测试结果不如人意,3段流水线接力反而不如简单撸到底的boringtun。流水线旨在减少单流长程处理带来的吞吐损耗,但这只是在理想情况下忽略控制开销的结论。为了保序引入的Lock/Unlock不是spin操作,
原创
发布博客 2022.05.18 ·
386 阅读 ·
1 点赞 ·
0 评论

用流水线提高转发吞吐

流水线不会缩短延时,但能提高吞吐。长程逻辑是转发吞吐劣化的罪魁祸首:​优化方案有两种:​多CPU涉及保序处理,比较复杂,一般不采用,如善用的RSS均不会对单流进行并行处理,因此一般将长程分割成多个短程,流水线接力。各软件转发产品的实现不谈,仅谈wireguard,抛砖引玉。wireguard采用的是第二种方式:这就是单流吞吐比Open虚拟专网好的原因,路线是对的,但wireguard-go未竟全功。我觉得loop1和loop2还是太长了,紧接着TUN的loop应该只做一件事:将TUN
原创
发布博客 2022.05.15 ·
1507 阅读 ·
4 点赞 ·
2 评论

时间换空间的TCP

原题应该是“以时间换空间的端到端”,但端到端可能不为人知,就说成TCP。TCP天生不为性能而生,TCP天生节省带宽和内存,天生的时间换空间。为节省空间开销,宁可多几轮来回。TCP天生以多花点时间来确保“可靠传输”这个底盘。体现在两方面:不允许乱序,节省接收端内存,否则就要维护ofo队列。TCP短头,增加数据载荷率,提高有效带宽利用率。1970年代,内存昂贵,网络带宽昂贵,除保证可用性,优化性能简直是中邪。空间约束下,TCP就成了TCP。结果是发送端获得的反馈信息不足,GBN就是自然的选择,几
原创
发布博客 2022.05.14 ·
1620 阅读 ·
0 点赞 ·
0 评论

TCP与去中心化

我暂时将直连对等通信看作是一个去中心化的实例。都说互联网是去中心化的,其实并不是。虽然互联网的前身ARPA网的初衷是去中心化以防核打击,但发展到最后,显然这个目标并没有在互联网实现。现代互联网使用更多资源跑B/S,C/S服务,用于资源的获取,而不是对等通信。资源曾经集中在门户,如今集中在云机房,而云资源必然构建在从属于某个公司的平台,显然不是去中心的。P2P曾流行,但很快被遍地打压而销声匿迹。本文从TCP的视角刨一刨。建立TCP连接,要有一个主动端和一个被动端,其中被动端在收到主动端的SYN时,必须
原创
发布博客 2022.05.14 ·
1727 阅读 ·
0 点赞 ·
0 评论

我为什么错怪了goroutine

前段时间写了篇随笔:我错怪了goroutine有点长,本文缩一下。我并不懂golang,只会照猫画虎,我一直以为goroutine是比thread更轻量的执行体,系统开销依然会随着goroutine的数量而线性增加,在大并发场景显然存在扩展性问题,但其实并不是。下图解释:​左上角是传统方式,有扩展性问题,右上角是异步方式,epoll收事件,loop处理,这是大家都认可的方式,下面是goroutine方式,和异步方式差异是不用自己loop事件,runtime帮调度,没有系统开销,为啥就觉得它会跟传
原创
发布博客 2022.05.13 ·
2067 阅读 ·
1 点赞 ·
1 评论

TCP的不可靠传输

一个常见的面试题:UDP如何实现可靠传输。既然有TCP了,干嘛用UDP重新实现一遍,就算非要卷,能比QUIC更好吗?显然,这问题没意义。还有另一个问题,TCP如何实现不可靠传输。数据传输只有两个协议可选(这里不抬杠),TCP或UDP,对于那些某些数据可以丢失某些却必须送达的传输业务而言,就要在UDP上重写一个协议,可理解为松散可靠传输。实现这种协议工作量不小,收益却不大。so,人们往往选择复用TCP,当然也继承了TCP的缺陷,如队头拥塞,而这是大多数卡顿,传输低效的根源。换句话说,TCP根本就无法实
原创
发布博客 2022.05.12 ·
1917 阅读 ·
3 点赞 ·
0 评论

TCP与移动性

又跟朋友聊TCP,这次说到了移动性。一个TCP连接是绑定五元组的,该连接的生命周期呢,五元组不可改变,如果IP变化了,需要重新建立一个新的连接,这是众所周知的。如果在TCP连接上直接构建应用,一旦IP地址发生了变化,该应用必须自己处理连接的重建。若希望应用无感于IP地址的改变,常见的方法是增加一个会话层。很早以前我做Open-V-P-N的时候,就是采用了这个方法,在协议头里增加了一个全局唯一的SID,用于识别连接。现在QUIC协议也是这样处理的。还有别的方案吗?还有一种扁平的方案,将IP地址的变化直
原创
发布博客 2022.05.10 ·
2083 阅读 ·
4 点赞 ·
1 评论

提高吞吐就要减少操作次数

高吞吐,大并发,不怕数据大,最怕数量大。网络处理怕小包,文件操作怕小文件,无论每一个小包还是每一个小文件,它们均消耗元操作和元数据,如每一个数据包都触发一次中断,而中断是有固有调度开销的,中断数量越多,开销越大。小文件类似,再小的文件也要有inode,ident等固定元数据描述。元开销是固定的。时间方面和空间方面元开销都与数量正相关。时间开销体现在并发调度,本质上是查找,这个已经说了好多次。空间上是元数据开销,这个不谈。时间开销优化方法两种:一次处理尽可能多的量。多次操作尽可能合并成。第一
原创
发布博客 2022.05.08 ·
2079 阅读 ·
2 点赞 ·
0 评论

传输和计算

昨天的一篇短文:通用计算机器今天假期最后一天,接着说几句。图灵机将步骤按照时间展开,替代将部分空间中连线延展,成就了通用计算机器,我们现在的计算机都是图灵机的形式。这就必然会有内存和CPU之间的通信,就算如火如荼的存内计算也不过是小范围优化,既然词中还有“存”,便没有改变本质,内存和CPU依旧两隔。但时间展开和空间展开真的就是固然对立的吗?非也。虽然计算组件不能在空间扩展,因为太占地方,但已经按照时间扩展的步骤却可以自由组合和递归,实现新的功能。这便是Unix哲学的实例了。组合使用命令,cat
原创
发布博客 2022.05.04 ·
2583 阅读 ·
3 点赞 ·
2 评论

通用计算机器

还是下面这句话:将固定的资源在所有使用者中分配,而不是为每一个使用者分配固定额度的资源。还是那个简单的倒换,通用计算机就设计出来了。人们就意识到内存和CPU之间的总线成了瓶颈,于是人们拼命缩短这条总线的长度,甚至将内存控制器封装进CPU内部。无论怎么折腾,CPU和内存依然内外两隔,沟通媒介始终存在。人们把锅甩给了冯诺依曼体系,甚至图灵机。对,就是那条纸带和会移动的机器头,它们始终内外两隔。这种分离带来的二者之间的沟通损耗是回避不了的,但也正是这种分离,让图灵机变得通用。把一个计算组件定义为输
原创
发布博客 2022.05.03 ·
2543 阅读 ·
1 点赞 ·
0 评论

Linux TCP并不是全双工的

我说过好几次Linux TCP不是全双工的,没人信,也可能不知道我在说什么,总是有人拿TCP规范来怼我,说TCP就是全双工的,两边可以同时发送数据,显然没get到我的点。Linux TCP半双工体现在以下方面:Linux TCP接收ACK反馈和由此反馈激励发送数据在同一个CPU上,不能同时进行。Linux TCP接收数据以及对该数据的即时ACK反馈在同一个CPU上,不同同时进行。Linux TCP socket发送数据和接收数据均需要lock socket,不能同时进行。这下说明白了吗?还不信
原创
发布博客 2022.05.03 ·
2602 阅读 ·
2 点赞 ·
3 评论

从Unix看文言文为什么短

文言文为什么短?我是搞网络的工人,略懂文字,从Unix视角谈。Unix/Linux程序很像文言文,列举一些:ls, pwd, sed, awk, ab, bc, cd, cc, cat, dd, df, ex, fg, ip不是干这一行的基本不明白上面这些命令是干什么的。再看一些文言词:汝 子 若 君 尔 彼 其 或 所 何 安是不是很像。这里面有什么关联?存储开销Unix早期磁盘磁带昂贵,古代龟甲竹简丝帛纸张昂贵,信息越短越好。传输开销Unix早期直到1990年代,网络带
原创
发布博客 2022.05.01 ·
5851 阅读 ·
28 点赞 ·
13 评论

从心脏为什么只有一个看系统设计

曾遇到一个很有意思的问题,当时给出了一个回答:https://www.zhihu.com/question/392259415/answer/2385499293​今天正好五一假期又出不去,把答案再深入细化一下。首先声明,我不是搞生物医学的,甚至连爱好都算不上,我是一个搞网络传输的普通工人,以系统设计的视角来瞻仰人体之妙。下图是一个简单的循环系统图示:很明显,唯一的心脏是以串行泵血的方式工作的,而肺泡却是多实例并行,多个肺泡组成一个肺叶,理论上肺叶的数量可以超过两个,为什么会这样呢?如果不这样
原创
发布博客 2022.04.30 ·
1647 阅读 ·
1 点赞 ·
2 评论

流越多,带宽利用率越低?

多条流共享同一瓶颈链路时,涉及到并发调度问题。调度在微观上就是查找,调度本身会带来开销。视角放远一点,我们仅当开销是个黑盒,不问细节,看看怎么回事。类比进程调度,多进程分时运行,想象中时间被所有进程完全分享,实际上调度本身也占用时间,随着进程规模增加,调度开销也增加,O(1)调度的代价是调度周期的延长,因此O(1)理论上不存在,现实中log级已很好。因此,时间利用率随进程规模增加而降低。开销与规模正相关,多流收敛也一样。多流之间互不相识,不知对方存在,完全自组织,靠感知带宽,RTT等反馈的变化知道别
原创
发布博客 2022.04.30 ·
4734 阅读 ·
8 点赞 ·
5 评论

并发的核心是查找

并发的核心是查找,之前解释过,今夜豪雨,再说两句。并发问题实质是可扩展问题,好的并发系统开销不应随并发entity数量的增加而线性增加,时间复杂度应在O(n)以下。并发和并行不同,并行是同时执行,但entity数量并不永远和硬件数量匹配,当entity数量大于硬件数量,总会有多个entity共享一套硬件,一套硬件处理多个entity,就是并发。并发entity最终还是要串行,并发的本质是分时串行,并发处理的核心是“随时查找一个最适合使用时间片的entity。”并发技术是一种调度技术,调度多个enti
原创
发布博客 2022.04.27 ·
2300 阅读 ·
5 点赞 ·
4 评论

信息传输的本质

下午发了一则朋友圈:​接着第二个话题继续说。说说老本行相关的。信息传播的本质目的是互动。只有互动才能激起风暴。果真如此,有必要将信息大块大块地从一个地方复制到另一个地方吗?每次传输的信息只具有一个固定的含义,两次传输的信息彼此正交,这样效率才最高。如果有多个含义,就分多次传输,因为第一个信息的反馈会影响第二个信息。既然小信息才更好,为何大家将大部头视为经典呢?如果一本书写不厚,就会被轻视?直接原因是思维定势,人们在过去几千年一直这么认为,很难改变认知。根本原因是古代没有支撑小消息的传输的技术,
原创
发布博客 2022.04.24 ·
1640 阅读 ·
5 点赞 ·
0 评论

瞧内核地址空间映射

将固定的资源在所有使用者中分配,而不是为每一个使用者分配固定额度的资源。Windows为每个进程映射了一个独立的内核地址空间,布局非常正则,比如页表在固定的地址A,PCB在固定的地址B,该独立的地址空间通过MMU映射到物理内存。如下图:每个进程需要额外内存作为页表映射独立的内核地址空间本身,随进程增多,这部分内存开销线性增加。理论上Windows进程地址空间任何部分都可换出到磁盘,优点是系统可承载的进程数不受物理内存限制,缺点是换入换出会影响性能。好坏不评说。颠倒一下,还是那个技巧,每个进程不再独
原创
发布博客 2022.04.23 ·
1426 阅读 ·
2 点赞 ·
0 评论
加载更多