原以为只有 QQ 在上传心跳包的我真是 naive

这个一看就是遥测数据收集吧，大厂自己研发，小厂使用第三方（比如国内的 oneapm ）

还是希望能多一些像楼主这样的人，能够监督大厂的行为。没人监督很容易被滥用。

@smilexyk #40
不知道什么原因，我这里显示是不安全的链接

@smilexyk #40 好吧是我这里的问题，我自己发的图都显示不了。。。不知道 Chrome 怎么了。

@SpicyCat 可能我用的新浪图床还没有支持 https ，然后最新的 chrome 会提示不安全

@jsq2627 到不了这个水平啊……要是我有监督大厂的这个水准，我也用不着来这里询问大家的看法了，可以学习 Price Tag 作者怒斥新浪那样直接面刚腾讯了 QAQ

刚刚又发生了一件非常好玩的事情，重启电脑打开 Surge 后 QQ 登陆不上了，看了一下请求，果然……

反复尝试数次之后终于成功登陆……不知道是不是因为放弃了 QAQ

还是 windows10 的 uwp 好， qq 连截图的功能都没有，假如我要截图，要用系统自带的截图软件，然后复制进去

@smilexyk 少跟我扯 HTTP HTTPS 好不好，你看过 HTTP Payload 没有？第三方截获到除非能解密到信息否则都没啥用，谁不知道应该普及 SSL ， 但这就是国内现状，你这半桶水看到点信息就以为可疑我看了都想笑。我这帖就是说你们这些质疑的请拿出干货证据来，否则就是浪费大家时间而且达成不了什么成果。

Block 还我清净。

@famouslastword 第一， HTTP Payload 看过一些，表示以本人的能力加密后的密文确实看不出来具体内容，但是 http 的风险并不是你一句信息加密过了就能解决的；第二，我完全无意浪费您的时间，欢迎 Block 我，这样您的 Timeline 也不会被我这种小白占领，我们时间不值钱慢慢研究这到底有什么风险，您时间宝贵，去干您认为更值得的事情吧。

因为我系统上的 QQ 和微信不会发这个东西我也没办法去验证，从包的大小来看，比较倾向于是普通的健康检查，既然楼主用的是 surge dashboard ，应该会发现这个 dashboard 自己也会定期发 crashlytics.com 的请求

@otakustay 其实本人同样倾向于这个属于正常的检查，问题在于他这个检查第一藏在一个工具类 Framework 里，第二没有采用 https 传输，另外重试的时间太短又不会主动停止，让我觉得有些难以接受。另外我刚刚研究出来一个或可复现的方法，先退出 QQ ，打开 Surge REJECT 掉 monitor.uu.qq.com 这个地址，然后再进入，有一定概率触发多次请求这个地址的行为，不知道你们的机器上能否复现。

地沟油也是常识，所以别人出门吃饭，有点怀疑，还非得说：你那么在意健康，别出门吃啊？
因为错误的可能性，却要别人改变正当的权利。

@roist 是的，某人的态度就是：觉得自己被骚扰或被强奸了，然后就每天衣服都不穿，脸上写着，你们都随意来干我吧！

block +1

@famouslastword

@otakustay crash report ？不能关闭吗？

@smilexyk 真不想回复你，不懂别装懂好不好， http 风险在你这个质疑的场景除了信息是否加密过还能有什么其他风险？你倒是说出来啊，无非就是怕第三方截获破解信息。还有什么触发多次请求的拜托 netcode 都有重试机制啊。

还有那些被 trigger 的人，真理就是有本事就不用，有本事就去改变，而不是在这里吐嘈都吐不到重点。

给大家带来麻烦了，这个确实是 RQD 历史版本的 Bug （内部版本 Bugly ），已经联系业务方更新 SDK 版本修复了。这个 Bug 会一直尝试上报联网统计数据以便统计 Crash 率，并不是在发送监控数据，也不包含任何敏感数据。

我一会详细描述下这个 Bug 。

首先给大家道歉，给大家惹麻烦了，也让微信受委屈了。

这个网络请求确实是 RQD SDK 发起的， RQD 即 腾讯内部使用的 Bugly (bugly.qq.com)，主要用途是为 App 提供质量监控服务。

在 V2EX 发现这个帖子后，我们紧急排查，发现在 RQD 历史版本（受影响版本发布时间为 2015 年）中确实存在对异常处理不当的 Bug ，具体表现为网络请求失败后会进行重试，没有设置重试次数及其他的退出条件。

受影响的业务逻辑为联网信息上报模块，这个联网信息上报的用途是为了统计 Crash 率，并不会包含用户的隐私信息，这点我可以跟大家保证。

我们已经跟受影响的业务方联系升级替换问题版本了，后续大家可以通过升级软件解决这个问题，如果大家还是觉得有困扰的话，不妨继续屏蔽等待新版。

v2ex 上的同学都很专业，有同学提出担心使用 HTTP 协议上报数据有风险。其实我们在 2015 年 9 月 就已经响应 Apple ATS 的号召，对通信方式进行了升级，目前 RQD 和 Bugly 的最新版本都已升级到 HTTPS 协议进行通信，请大家放心。

另外还想重申一下， Bugly SDK 现网版本都不受此 Bug 影响，如果有在使用 Bugly 的小伙伴请继续放心使用，有任何问题请随时跟我们联系。

@famouslastword 同志我又没有逼你回复我……不想回复您可以不回复啊……然后再来说你问的问题：
第一， http 为何不安全：做一个很简单的设想，假设我伪装成了上述的请求地址，向客户端发出请求，请求客户端上传数据，在同一时间发送大量请求，就可以瞬间占满上行带宽，更严重的可以参考前面某位被 QQ 段时间大量请求导致防火墙崩溃的仁兄。 http 为什么不安全？不是因为你能想到他能拿来干什么，而是因为你根本想不到有心之人会拿来干什么。
第二，关于请求失败重试的问题，我承认绝大多数 crash report 都会有这个机制，但是我相信绝大多数的 crash report 都会有最大请求数的设定， crashlyrics 也没有说上传失败之后锲而不舍每 15s 来一次坚持几个小时吧？