2016年10月_dog250

12月 11月 10月 09月 08月 07月 06月 05月 04月 03月 02月 01月

原创 TCP BBR算法的带宽敏感性以及高丢包率下的优化

bbr算法比较简单也比较容易理解，所有关于它的优化也就同样不复杂了。请注意，任何优化都只针对特定场景的，根本不存在一种放任四海而皆准的算法。我们分析Google的测试报告时，比较容易被忽视的是其bbr算法的部署场景。如果可以完美复现Google的B4网络，那么测试结果应该就跟Google是一致的，但不得不说，bbr算法内置了很多的参数(目前的版本中是写死的)，Google方面有没有

2016-10-30 16:10:04 18195 1

我一再强调，BBR算法是个分界点，所有的TCP拥塞控制算法，被分为BBR之前和BBR之后的(其实发现，这并不是我个人的观点，很多人都这么认为，所有想写本文探个究竟)。当然这里的”所有“并不包括封闭的那些算法，比如垃圾公司Appex的算法，或者伟大的垃圾微软的算法。任何的算法都内含了一个进化的过程，CUBIC和Reno看起来非常不同，但是却属于同一个思想，因此可以说，CUBIC是Reno的高级版本，

2016-10-29 07:12:43 43714 6

原创从TCP拥塞本质看BBR算法及其收敛性(附CUBIC的改进/NCL机制)

本文试图给出一些与BBR算法相关但却是其之外的东西。1.TCP拥塞的本质注意，我并没有把题目定义成网络拥塞的本质，不然又要扯泊松到达和排队论了。事实上，TCP拥塞的本质要好理解的多！TCP拥塞绝大部分是由于其”加性增，乘性减“的特性造成的！也就是说，是TCP自己造成了拥塞！TCP加性增乘性减的特性引发了丢包，而丢包的拥塞误判带来了巨大的代价，这在深队列+AQM情形下尤其明显。

2016-10-26 22:54:18 22366 7

原创推荐一部短片《How TCP/IP works》

我是一个比较懂网络的人，但我不是学者，我不是老师，我也不是码农，事实上我有阅读综合症，我思维比较松散跳跃，而且我也不怎么会编程，这就意味着我不可能是一个学者，不可能成为老师，也不可能成为码农。但是，我懂网络。我想表达的并不是我多么懂网络，而是想说，我特别喜欢给别人讲我知道的东西，不光是网络技术，还包括古罗马历史，问问我身边的人就知道了... 我十年来一直期待的一个东西，如今终于有了，

2016-10-23 16:06:55 7308 2

原创 Google's BBR拥塞控制算法如何对抗丢包

我不知道该怎么说。总之，便舍船，从口入，我看不到黄发垂髫并怡然自乐！在BBR之前，存在着两种拥塞控制算法，基于丢包的和基于时延的，不管哪一种都是基于探测的，换句话说，基于丢包的算法将丢包作为一种发现拥塞的手段，而基于时延的算法则是将时延增加作为发现拥塞的手段，它们之所以错误是因为它们的初衷就是错的：丢包算法：为了发现拥塞就不得不制造拥塞，这TMD的太JIBA讽刺了，为了戒毒，就必须

2016-10-23 15:40:26 19709 4

原创 Google's BBR拥塞控制算法模型解析

在进入这篇文章的正文之前，我还是先交代一下背景。1.首先，我对这次海马台风对深圳的影响非常准确，看过我朋友圈的都知道，没看过的也没必要知道，白赚了一天”在家办公“是收益，但在家办公着实效率不高，效果不好。2.我为什么可以在周五的早上连发3篇博客，一方面为了弥补因为台风造成”在家办公“导致的时间蹉跎，另一方面，我觉的以最快的速度分享最新的东西，是一种精神，符合虔诚基督徒的信仰而不是道德约束。3.上半

2016-10-22 22:10:53 21833 15

原创该不该抛弃那匹马呢？

本来我想给本文取个《思维定势，创新与情怀》这个题目，后来觉得有点大，恰好昨天跟同事抽烟间隙聊到了bbr算法多么的创新顺带扯到了工业革命中蒸汽机发明以及后来汽车的发明，也吐槽了旧势力的愚昧与无知，所以，题目就跟100多年前的工业革命有关了。事情是这样的。当蒸汽机刚刚被发明出来时，仅仅是用来驱动水泵的，很快就用到了棉纺织业，但是却迟迟无法用于车辆，直到发明了火车以及后来

2016-10-21 07:31:59 13813

原创 RACK为TCP BBR提供动力源

先从需求谈起吧。在上一篇文章《Google's BBR TCP拥塞控制算法的四个变速引擎》的最后，我提到bbr算法作为一个标称功率十足的引擎需要源源不断的能源供给，而这类能源就是数据包。又提到，TCP的快速重传机制几乎只会将判断为LOST的数据包重传一次，因此当重传数据包再次丢失，滑动窗口无法滑动的时候，将会无法提供数据包发送，bbr引擎就会失速，此时只能等待TCP的超时！当然，超

2016-10-21 07:12:13 8803 1

原创 Google's BBR TCP拥塞控制算法的四个变速引擎

台风海马来临前的两个几乎通宵的夜晚，我用一篇关于BBR算法的文章的迎接海马！公司在昨晚响应深圳市停工，停课号召，发布了在家办公(请注意，不是放假...)通知...其实吧，我觉得停电才是王道，你觉得呢？在前一篇关于bbr算法的文章《来自Google的TCP BBR拥塞控制算法解析》(这可能是第一篇中文版的bbr算法相关的文章)中，我简述了bbr算法的框架，算是大致介绍了。本文中，我想深入bbr算法p

2016-10-21 05:29:51 22656 5

原创关于Linux TCP接收缓存以及接收窗口的一个细节解析

关于TCP的接收缓存以及通告窗口，一般而言懂TCP的都能说出个大概，但是涉及到细节的话可能理解就不那么深入了。由于我最近的工作与TCP有关，顺便又想起了很久之前遇到的一个问题：明明在接收端有8192字节的接收缓存，为什么收了不到8000字节的数据就ZeroWindow了呢？当时我的解决方案是直接扩大接收缓存完事，然后就没有然后了。后来深挖了一下细节，发现了很多曾经不知道的东西，如今对TCP的理解想

2016-10-11 22:01:53 21658 9

原创 TCP接收到重叠数据(overlap)后的行为解析-附带一个有关Delay ACK和超时重传的优化

本文写于国庆长假第一天早晨，正好碰到今天热线值班，终于不用假期出去添堵折腾了(14年来[自离开高中]，从来没有过过一个完整的可以休息的假期！预定了N次在家的假期，失败了N次，谎称过几次加班，但也不是长计，因为必须要离开家，实在也没地方去，我觉得此生假期难自由了，然而如果公司硬性规定必须在家值班，那也是不啻一种上好的方法啊！哈哈)，作文一篇，以表达对假期自由的感慨！最开始的事实首先，我们先明确Lin

2016-10-01 09:18:46 16885 2

一个iptables的stateless NAT模块实现

如果你在寻找Linux上配置诸如Cisco设备上的static双向NAT的方法，这个或许就是你想要的； what？你觉得它完不成PAT？是的，它不行。但是想做PAT为何不使用现有的iptables实现呢？它可以自动为你解决元组唯一性问题。不要从概念上分析，事实上，static双向NAT是完全对称的，一对一的，也只有在BOX两边的网络在拓扑级别是完全对等的情形下，这种NAT或许才是有用的，Cisco设备经常处在这样的位置，比如一个很大的stub节点的出口位置，比如两个domain的中间位置... 我将名字取为STATIC-2-WAY-NAT，比较长也比较怪，完全不符合UNIX的小写短名传统，我的想法是：这样可以少写很多的帮助信息，因为名字就是自解释的。

2014-12-27

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

Netfilter