有个老项目，通过 Squid 提供文件下载功能，利用 delay_parameters 实现带宽控制，问题是我玩不转 Squid，于是盘算着是不是能在 Nginx 里找到类似的功能。

    HBase 0.92版本之后，Region Server的Compact过程根据待合并的文件大小分为small compaction和large compaction两种，由此可能导致在集群写入量大的时候Compact占用过多的网络出口带宽。本文将详细描述集群使用过程中遇到这一问题的排查过程及其解决方法。

    限制带宽简直就是系统管理员的永恒话题之一。当然我这里就不讨论端口限速什么的了，百度一下一大把。但如果要的是限制某个特定进程的带宽，事情就有趣多了。

    我们在做网络服务器的时候，通常会很关心网络的带宽和延迟。因为我们的很多协议都是request-reponse协议，延迟决定了最大的QPS，而带宽决定了最大的负荷。 通常我们知道自己的网卡是什么型号，交换机什么型号，主机之间的物理距离是多少，理论上是知道带宽和延迟是多少的。但是现实的情况是，真正的带宽和延迟情况会有很多变数的，比如说网卡驱动，交换机跳数，丢包率，协议栈配置，光实际速度都很大的影响了数值的估算。 所以我们需要找到工具来实际测量下。

    我们在做网络服务器的时候，通常会很关心网络的带宽和延迟。因为我们的很多协议都是request-reponse协议，延迟决定了最大的QPS，而带宽决定了最大的负荷。 通常我们知道自己的网卡是什么型号，交换机什么型号，主机之间的物理距离是多少，理论上是知道是知道带宽和延迟是多少的。但是现实的情况是，真正的带宽和延迟情况会有很多变数的，比如说网卡驱动，交换机跳数，丢包率，协议栈配置，光实际速度都很大的影响了数值的估算。 所以我们需要找到工具来实际测量下。 网络测量的工具有很多，netperf什么的都很不错。 我这里推荐了qperf，这是RHEL 6发行版里面自带的，所以使用起来很方便，只要简单的: yum install qperf 就好。

    你有一个队列在Rabbit中。你有一些客户端从该队列消费。如果你完全不配置QoS设置(basic.qos)，这样Rabbit将以网络和客户端容许的尽可能快地速度发送队列中的所有消息到客户端。因为消费者在自己的RAM中缓存所有的消息，他们的内存将暴涨。如果你查询Rabbit，可能出现队列中是空的，但可能有以百万计的未确认的消息，因为它们在客户端，等待客户端应用程序处理。如果您添加了一个新的消费者，没有消息保留在队列中以被发送到新的消费者。消息只是被缓存在现有客户中，并有可能在那很长一段时间，即使有其它变为可用的消费者可以更快处理这些消息。这很不理想。

    末学很惭愧，网络做了多年，时延和带宽的概念一直没有搞的很清楚，认为二者是反比关系，即低时延对应高带宽。其实不对，请教了一下同事，总结如下： 上述两个系统是带宽相同的系统，上面是高时延，下面是低时延。可以看出，高时延系统中，报文从进入系统到流出系统做的操作更多，耗时更长，但是并不影响带宽。同时可以看出来，高时延系统也不容易，必须有足够的内存queue足够多的输入才能在不影响带宽情况下做更多的处理。

    网络协议里关于流量控制、提高交互效率、提高稳定性的部分，个人认为是最难的部分，以致于在LINUX内核里相关的实现都有BUG。前些年在追查一些网络故障的时候，看了些文档，一直想写些总结文章，但是这方面的内容实在太零散了，相关的RFC文档都好几个，把这些内容都说一遍，基本就把TCP/IP协议说了一遍。就只能挑几个CASE说了1、连接耗尽，这一般是短连接造成的。解决方案是，用长连接。这个方法看起来简单，其实很难，长连接会...

    很久没更新博文了,主要还是觉得自己的思维没有进一步提高,今天简单记录下,以前总是以正向的方式去思考问题,其实对自己进行一些反向的思考收获可能更大.修改了下原文,原来有些话说的有点太感性,希望对于看到的人有帮助.1:对于Squid的使用思考缓存服务目前有很多种,可能并没有很多人意识到为什么用Squid或者Memcached.他们解决的应用场景其实不一样的.期望用缓存解决所有复杂的事情,其实带来的管理代价是无穷的.通过最近的分析发...

    John的总结是：TCP缓启动意味着网络延迟严格的限制了新链接的吞吐量。他针对这种情况给出以下的建议：非常小心的考虑每一个字节的内容考虑什么应该放在最前面的部分数据包保持你的cookie足够小在前面的三个数据包里为有用的资源打开链接先下载小的资源接受光的速度（使内容更贴近用户）