微信不是并不走 GCM/FCM 嘛？

微信通过 GCM/FCM 只是用作唤醒，没有内容的。真正的消息内容是在唤醒以后通过微信自己的渠道推送过来的。

一般来说，没什么影响，如果真的有很重大的影响，恐怖分子多带几个手机 不关机就可以了。这可比携带爆炸物容易多了。

现在依旧需要飞行模式，更多的是以前遗留下来的惯性，谁都不敢轻易的打破，毕竟可能要背锅。

楼主如果真的不愿意开飞行模式，也没关系，空乘人员也并不会检查，大约飞行到 3000 米以上的高度，开不开飞行模式都是没信号的。

人家那是工作，表面上尽量还是配合一下。

@azuring 就是看访问延迟较高的时候，CPU 跑满了没有，带宽跑满了没有，磁盘跑满了没有

@jiezhi 张小龙：又有人准备教我做产品？（手动狗头保命

但是我现在是工作专门用阿里小号申请了微信，里面也只有工作伙伴，转发就转发呗。反正节假日就 offline，追魂夺命 call ？不存在的。手机号也是一个专门的工作号，节假日都是自动转到语音留言上了。

当然这个操作不建议无脑实践，需要看工作性质以及老板对于你的态度再决定能不能休息日离线。

一个可能是高温降频，另一个可能是存储速度跟不上。我没搜过，米 5s 如果是 emmc，那存储的锅也是很有可能的。

至于内存在这应该不是主要原因

先不需要直接上工信部，可以先拨打 10015 表达诉求。

至于第三方公司，表示不能理解。不在联通的系统的套餐都无法开卡。最终网络注册都是在联通的管辖下。

@alphatoad #15,又不是不能用。real·真实。到现在很多大厂的 apk，在 Android 也只有 armeabi-v7a，同样的，又不是不能用。

TCP 打洞....读了两遍原文，基本了解下来就是 NAT 内网穿透，实现方式与原理均一致。你的实现方式大致是这样的
Client -> Router -> Server
举例
C: 10.10.10.1:7890/TCP => R: 10.10.10.1:7890/TCP <--> 61.61.61.1:23456/TCP => S: 61.61.61.1 -> :80/TCP

你的问题 1：每个连接时间不能太久，会被断开

不正常。活跃的端口映射不应该被断开，也就是 R 这里面的映射关系即使在不活跃的状态，也应该保持一段时间（如 2 分钟）更何况你下载时，是处于活跃状态。

你的问题 2：假如我同时发起成千上万的 TCP 连接，是不是也会把同个公网 IP 下其他人正在使用的端口给抢占呢

原则上是本着先到先得，单 IP 上的端口数量有限的，但这类二级运营商大量的飞针走线，内网穿透。真出现这种情况，也许会给你换个出口 IP。不过.....正常情况下，出口路由记录的映射关系是<内网 IP:端口 /出口端口 /目标服务器>，也就是说出口路由上的端口是可以复用的。多个内网 IP 出口均使用同一个公网端口，大家的目标服务器不同，返回的数据也可以依据服务器 IP 来区分转发给内网的哪个 IP

你的问题 3：TCP 打洞成功后，原先的连接就不可用了

讲道理，在出口路上上，只要映射关系还存在，是可以双向通讯的。但这取决于你所处网络环境的 NAT 类型(这个结论是基于 UDP 得到的，TCP 我不确定)。

https://zh.wikipedia.org/wiki/UDP%E6%89%93%E6%B4%9E

你的问题 4：OSX 和 Windows 上支持端口重用，但 Linux 却不支持，报端口被占用的错

超出射程了，不太了解你指的端口复用是什么。

咸鱼上淘个二手的网络摄像头，几十块钱，自己破解一下都支持 RTSP。当然买之前先确认这个型号可以破解。

我刚刚破解了一个两年前买的小蚁 1080P 带夜视的那款摄像头

所以有人出闲置嘛，换个地方吃灰，也许味道更好哟。

GCP 没有了解过，但是就一点，Cloudflare 的节点到源站并不是固定的（例如欧洲访客 一般就不会分配亚洲节点），与访问者具有强相关性。加上 Cloudflare 使用了 Anycast，因此节点 IP 也不一定可以代表节点位置。

你可以先小规模测试一下看，比如自己下载个 100M 文件，然后看看 GCP 是如何统计这个流量的。

@imnpc 虽然也是 Google 粉，但这一点，其实不看好 Google。毕竟其本质是个广告公司，自己不太可能给自己打脸的。至于 Firefox，希望它越来越好吧，尽管我并不会用。

@Hilong 很久没在阿里购物了，我记得天猫延迟发货，赔付价值货款 30%的天猫积分，每 24 小时内，最低不少于 500 积分，最高不超过 5 万个天猫积分。需要消费者主动投诉才赔付。（ 100 天猫积分=1 元）
淘宝集市延迟发货，每个订单需要赔付货款 5%现金（直接进入消费者支付宝余额），最低不少于五元（特殊类目最低不少于一元），最高不超过三十元。需要消费者主动投诉才赔付

@fy #27 嗯....我也不确定于是查了下资料，两者几乎是同时成立的，某种程度上，可以说说 SAE 更早一点点。资料来自于维基百科。

阿里云于 2009 年 9 月成立： https://zh.wikipedia.org/wiki/%E9%98%BF%E9%87%8C%E9%9B%B2
新浪云于 2009 年 8 月内部开发，同年 11 月正式推出第一个 Alpha 版本： https://zh.wikipedia.org/zh-hans/%E6%96%B0%E6%B5%AA%E4%BA%91

但是我记得 SAE 最初是邀请制的，基本上可以认为两者是相同的时间推向市场的。

记得当年云这个概念刚刚出来的时候，各家但凡有点名气的厂家都做云。然后就有人扒出来，新浪微博用阿里云，而不是自己的 SAE （我隐约记得当时阿里还没买下微博呢）

用了 CF，那源站直接拒绝掉除了 CF 以外的所有请求就可以了。
https://www.cloudflare.com/ips/

并且可以开启 SSL 双向验证，验证客户端不是 CF 也一律拒绝。
https://support.cloudflare.com/hc/zh-cn/articles/204899617

@MrKou47 这种设计才是合理（至少我这样认为）。举例来说，康师傅冰红茶，有 A/B/D/E 四种口味，外观包装均不同，在淘宝系，商家很可能会创建一个 SKU，并下设四个分类，供消费者选择，但是这四种口味是共享同一个 SKU，因此对于商家来说，无法区分哪种口味的销量更多，以决定库存情况，类似的，第三方比价插件也无法正常采集到每个商品的价格，因为 SKU 相同，并不代表的价格一定相同。

而京东的做法是，同商品，不同包装、口味，都会使用不同的 SKU，一个商品真的有几百种颜色、口味，那就创建几百个 SKU，这是没有任何问题的。

淘宝的 sku 其实有点坑，对于淘宝的设计，同一个 sku 可以对应完全不同的商品，价格，这取决于商家的设置。

这一点京东好很多，同一商品，不同颜色，口味等，全部采用不同的 sku