请送 500G 梯子，可以不要咖啡么。。。

@dxfree 选项： vCard 格式（用于导入到 Apple Address Book 或其他应用）

OS Account -> chrome user + user data
这 2 个都被别人使用了，那就没有什么可以保证安全了。

https://www.google.com/contacts/ 然后导出，然后到 iCloud 中导入以后就用 iCloud 保持同步，如果你只有 apple 家族设备，那么这个方法应该最简单。

php 没有生命周期，像 java python ruby nodejs 。。。这些 web 应用结构上都有 application session page 等生命周期， php 这货只是一个进化版的 cgi 而以，遇请求则解析，没有生命没有周期。
你说的这是数据库连接池， php 这种以 cgi 为底线的结构上是不可能存在的。于是别人在 web 容器的生命周期可以干的事情， php 要放到每一个页面响应中去完成。

@snsd 主流都适用，如果需要帮助可以到这个找我 https://gitter.im/spance

@yexm0 电信、联通、教育网，从 1ms 到 600ms 延迟， 10mbps 到 100mbps 接入， suft 都已有过大量测试。你可以先做测试，基于数据来发表看法，网络这个东西不可以去猜，咱们猜不透的。

=COUNTIF($A:$A, ">0.5")
=COUNTIF($A:$A, "<0.3")
=COUNTIF($A:$A, "=1")

@snsd @laoyur
如果乐意尝鲜，可以试试 https://www.v2ex.com/t/262631

很久了，真的很久，没有见过这么感人的靓丽的蓝色 xp, 配合 win2003 也是感动的要死了。
简单点的方法， ServerSpeeder Windows

如果是 HK 中转，那这 35Mbps 并不稀奇或者略差；
如果是 US 中转，那这 35 就是相当不错的成绩了。
另外，一般 4k 大概有 20+Mbps 就可以流畅传输了，剩下就是能不能硬解的问题了。

@20150517 文章开始就有介绍，服务端 bmon 观察流量。是字体不够大么。。。

@sadscv 效果相似但不一样，一个是反向代理加速的产品，一个是负责传输流的协议。
一台发动机装在汽车上可以跑，装在发电机上可以发电，装在起重机上可以吊东西，就是这个意思。

@mhycy 这些问题都是要继续测试改进的或者已经解决的，相比公平性而言吞吐是主要考虑的问题，希望多来测试和改进。

@messyidea 多多关注，有问题的话多交流。

@nbndco tcp 使用随机起点和循环编号，而 suft 使用连续编号，从 0 到 u32 最大，而且暂时不准备实现编号循环。
没有基于字节编号，基于包的编号，并且 suft 的 sack 实现更能有利于实现准确的重传。

@mhycy 设计上延迟和丢包都不会吞吐有很多的影响，而延迟大抖动和丢包率畸变会带来一些影响。
如果两路或者多路 suft 流都在瞬时并发，可能会出现发送速度突发高峰，这个已经在考虑中，有兴趣的话希望来参与进来。

@Devin 双倍发包，重发率=100%，发送量=200%，实际能享受的有效吞吐大约 50%，也是公平性最差的方法，迅速的塞满各级路由器队列或者被丢掉，还能有比双倍更差的方法么？

@mhycy 指定传输带宽， ARQ 自动平衡发送速度，不会每逢丢包就退让带宽，但也不过度抢占平衡口以外的带宽，相比 tcp 而言公平性要差一些。

@tyhunter 目前还在协议改进优化期，还未开始投入应用。如果应用，专用协议需要 c/s 两端都支持 suft 。

@oplang 多参与测试也是一种改进贡献啊。

@Strikeactor 专用协议有特定的场景需要并不是来替代 tcp 的，保存高吞吐还要节省流量外加大延迟+丢包，能取得 3M 流量的节省已属十分不易。有兴趣希望多参与测试和一起改进。