运维好像就是搬运自行车的吧？至少美团的运维就是搬自行车的 [doge]
https://i.imgur.com/wSfpoR0.jpg

先说你调的这个“别的平台”的服务是否可以按你的需要修改？不可以的话，你又用不了推送，那就只能短轮询了，要提高效率只能缩短轮询时间间隔，避免 CPU 占用的话，可以根据 CPU 负载动态调整轮询时间间隔，应该也只能这样了。

如果这个服务平台可以根据你的需求做修改调整，首选肯定是支持推送，回调你的 webhook ，但由于网络原因（ NAT 之类的）不能做 webhook 推送的话，也可以考虑支持 websocket ，建立 websocket 来进行推送。或者另一种修改思路是把短轮询接口改成长轮询，即你本地请求后，服务端不作响应，直到服务端处理完毕后立即响应，如果服务端在请求超时时间内（几十秒）仍然没有处理完毕，则响应一个未完成的响应，你收到后立即重试就行。这样虽然还是小间隔的轮询请求，但是请求时长被放大到几十秒，属于 io 时间不消耗 CPU ，也会比短轮询更实时。

就浏览器，打开 DevTools ，查看 network ，操作的时候按时间顺序挨个看请求来判断接口用途。比较重点关注 Fetch/XHR 类型的请求就行。
比如上传文件是用的 POST https://file.wx.qq.com/cgi-bin/mmwebwx-bin/webwxuploadmedia ，需要关心请求头和请求参数，简单看了下，应该重点关注 Cookie 和 mmweb_appid 两个 header 就行，然后弄清 POST body 里的参数含义就行。
OPTIONS 类型的请求通常可以忽略，用来做复杂请求预检的。

@marcojbk 普通人用不着展示你的 IP ，捣乱的人展示的 IP 全世界到处飞也肯定不是自己的。IP 展示出来对普通人除了搞地域歧视和网络暴力以外也没啥用，而要抓捣乱的人也没有必要把 IP 展示出来。
结合控制舆论，热搜榜是人为操控的、点赞数是 mock 的，所以这功能更像是先让大家习惯看到归属地，然后一些国内的特殊事件就可以直接人为改显示的归属地，毕竟没有人能验证消息刚发出来时归属地是哪，后台数据库都可以直接改，而一条标着“境外”的消息就可以直接算作“辟谣”了。

iptables 或者 nftables 。
iptables 的资料多一些，但是各种参数不太好记。我倾向于用 nftables ，资料也不少，配置文件也便于阅读理解。
你这个就是个简单的 DNAT ，生成个 DNAT 的路由规则就行了，指定匹配源地址 NAT 到目的地址

@unt 现在国内是都要实名认证才能买域名，要解析到国内 ip 主机还要域名备案，备案少说半个月起，还要你自己邮寄材料，审核不通过还要重新邮寄。

解析到非大陆的 ip 不需要备案。国外买域名不需要实名。

有 GC 机制的语言也会发生内存泄漏，通常与全局变量有关。
你的确不需要深入了解 GC ，但当问到你 GC 概念的时候，你能告诉他你了解一些概念。
前两天看一个视频里的老哥说的我比较认同：你说你会写代码吧，你会，能解决问题吧？有时候能解决出来，有时候解决不了，这个就是最大的问题。当你在实际岗位上的时候，你有时候行，有时候不行，那谁敢用你啊？所以核心问题就在于没有你不行的时候。
如果哪天真碰上了个内存泄漏问题，找你来调查，你上来一句“内存泄漏是啥意思啊？硬件问题吗？”这哪行啊！
所以，即便你对 GC 并没有深入的了解过，但你至少知道里面有哪些概念，哪天真碰上了，找你来调查，你能快速的找到解决办法，这才是面试考察的重点。

@KoMAsS121 #12 老美的算法后门实锤应该算是的，NIST 通过特殊设计的加密参数可能导致 RSA 被破解。
但举一反三到不是，国密带后门是直接写在脸上的：私钥要求放 CA 里……

@whileFalse 以前有的，CNNIC ，后来被封杀了，封杀原因搜一搜就知道，证书权限太高，第三方公司拿 CNNIC 的证书签 google 域名的假证书……

@yaoyao1128 通常不做展示的话，不会插换行符的，所以就是 33%

@pigspy 现在没人用透明代理了吧？

HTTP 2xx: 正常结果，一定是成功的操作，仅包含业务数据，不包含其他内容 status: success 之类的
HTTP 4xx: 客户相关错误，状态码可以提供大范围的错误信息分类（未登录、无权限、访问频繁之类的），这些错误都是正常情况下的错误，可以给出具体理由的，属于预期错误，通常理论上完全不需要开发、运维介入的错误，用户自己知道错哪了，能不能解决也是用户自己可以判断的。
HTTP 5xx: 服务相关错误，可以通过状态码进行分类分为业务错误和网关错误。如果是业务自己的错误（比如数据库连接断了、空指针了之类的），那就是 500 ，这类错误通常是需要开发人员去定位的异常情况，也就是未知的 bug 。而网关错误通常是明确的，配置错误 502 、临时维护 503 、业务挂了 504 。
其中 4xx 和 5xx 错误，状态码只提供大分类，响应结构中再包含可公开的具体的细分错误详情。

举个例子：用户访问了一个不存在的 URL ，分为 3 种可能，1 业务错误：没有这个资源，2 业务错误：没有权限，同时需要防止用户了解资源的存在性，3 网关错误：找不到对应的业务。
对于 1 和 2 来说，返回 HTTP 404 再合适不过，HTTP body 指示找不到可访问的资源；而对于 3 来说，应该返回 502 ，HTTP body 指示找不到可用服务。

这样，在网关记日志的时候就不需要解析 HTTP body 了，通过状态码就能过滤出错误日志，并且按照大分类分好：
通常开发只需要关注 500 的业务错误、运维关注除了 500 以外的其他 5xx 错误。而 4xx 的错误通常只需要关注计数就行，错误数在一定量级以下就是正常，超过一定量级就需要报警让开发介入调查了。2xx 的日志只在查业务逻辑的时候才会关注，平时直接忽略。