V2EX › spance 的所有回复 › 第 3 页 / 共 16 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯

2016-03-25 21:38:44 +08:00

回复了 won 创建的主题 › 咖啡 › 挂耳咖啡专业版，近乎速溶的价格，预定送 50G 梯子

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

2016-03-23 15:56:51 +08:00

回复了 dxfree 创建的主题 › 问与答 › 我的 iPhone 上的 Google 通讯录，咋整？

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

2016-03-23 15:55:26 +08:00

回复了 mengjue 创建的主题 › 分享发现 › 今天无意间发现的，在 chrome 的密码管理器里面，可以直接看到原始的保存的密码！

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

2016-03-23 15:51:57 +08:00

回复了 dxfree 创建的主题 › 问与答 › 我的 iPhone 上的 Google 通讯录，咋整？

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

2016-03-21 14:59:55 +08:00

回复了 zhidd 创建的主题 › 问与答 › php 页面每次访问后，都会释放所有资源，也就是说，单例的写法，没什么意义，有人说 php 是页面级别，除了页面级别，单例写法没用

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

2016-03-19 23:23:16 +08:00

回复了 snsd 创建的主题 › 宽带症候群 › vultr 东京到贵阳联通的速度，慢得惊人

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

2016-03-19 22:30:49 +08:00

回复了 snsd 创建的主题 › 宽带症候群 › vultr 东京到贵阳联通的速度，慢得惊人

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

2016-03-19 22:26:22 +08:00

回复了 zhjits 创建的主题 › 问与答 › Excel 如何批量对特定条件统计满足和不满足的数量？

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

2016-03-19 21:37:20 +08:00

回复了 snsd 创建的主题 › 宽带症候群 › vultr 东京到贵阳联通的速度，慢得惊人

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

2016-03-19 21:32:48 +08:00

回复了 snsd 创建的主题 › 宽带症候群 › vultr 东京到贵阳联通的速度，慢得惊人

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

2016-03-15 23:08:03 +08:00

回复了 yescola 创建的主题 › 宽带症候群 › 某电梯速度~~~ 还算 OK

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

2016-03-11 10:38:52 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

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

2016-03-10 23:18:57 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

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

2016-03-10 23:07:34 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

2016-03-10 23:02:32 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

2016-03-10 22:56:49 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

2016-03-10 22:39:33 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

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

2016-03-10 22:27:58 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

2016-03-10 22:13:26 +08:00

回复了 spance 创建的主题 › 宽带症候群 › SUFT vs 锐速 100MB 传输测试

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

2016-03-08 15:04:40 +08:00

回复了 fowse 创建的主题 › 机械键盘 › 猩盘崛起：亮出你的键盘！

@xyu_ovi 对于这些精简过度的键盘布局，的确是想要而又不敢要，窃以为键盘除了可以砍掉数字键区，其它键区的布局和存在已经是长期合理了。

1 2 3 4 5 6 7 8 9 10 ... 16

❮

❯