wordpress 后台很慢网站关键词优化的价格

昨天发了一篇 非技术文章，很多人找我讨论，浓缩成一句话，就是 “死道友而不死贫道”，我的简历上写着这些把戏能带来什么，我的 blog 上写着这么做是多么无耻，哈哈。
看看共享链路上如何挤占带宽：

如果 B 倔强地也要保住自己在 start 点的 bw 怎么办？假设 B 确实通过 inflate inflight 保住了自己原来的 bw，A 又不服又要抢回来怎么办？来看看这个过程：

多流均保带宽的代价是高昂的。丢包导致每一个脉冲的能耗白白浪费，而排队延时则意味着存储器的能耗。保带宽的结果，损人不利己，这里就解释了。
看个有趣的：Relentless Congestion Control
如果放宽算法的公平性约束，抢带宽，让带宽就自然多了，非常像高速公路的场景了，你想快就快，不太过分且我也没啥急事就让让你，当然，我也一样。算法的核心是：
instead of applying a multiplicative reduction to cwnd after a loss, cwnd is reduced by the number of lost segments.
完全基于范雅各布森报文守恒，精确填充管道：发出去 a，丢了 b，cwnd = a - b。relentless cc 承认自己非标：
Relentless Congestion Control conforms to neither the details nor the philosophy of current congestion control standards.
与其它 draft 几乎无例外想转正不同，relentless cc 甚至不以标准化为目标，只记录一种可能性：
We are not even planning to standardize it at this time. The goal of the document is to illustrate what new protocol features and properties might be possible if we relax the “TCP-friendly” mandate.
看一下 relentless cc 的工作图示：

这方式是不是更温柔呢。
如前述，执意保固定带宽有大代价，只要别硬杠，一般不会有大冲突。流多了就都慢点，自己有需要，随时 probe，如果大家没有特别要紧的事非要给你挤回去，一般都会默认的。relentless cc 只是在不停地执行 cwnd = cwnd - losses。
非要硬来的话，说说 arq 和 fec，二者结合效果更好，比方说尾部 fec，重传 fec。fec 就是提前重传。既然预测到丢包率，重传就是必然的，等到后面实际丢包(这是必然的)再重传，不如提前重传，用 fec 的话讲就是发送冗余。但由于拥塞丢包本身就是发送行为的函数，拥塞 fec 效果未必好(大概率很差)，无论任何时候拥塞都要谨慎对待。
总有人说不受控的 udp 要比 tcp 快，其实一个优秀的 udp-based 协议并不比 tcp 快，它至少把 tcp 那些东西重新在 udp 上实现了一遍，比如 quic，最后就成了 yat-yet another tcp 了。但凡为 udp 做加法，只能让它更慢，但慢并不意味着不好，端到端传输协议要全局看。

浙江温州皮鞋湿，下雨进水不会胖。