@seki 这里只是举例，不讨论实现本身，用 var 和 let 不影响代码行为，我觉得用 var 更能体现一些特点所以用了 var

@wzb0909 谢谢，block 了

@todd7zhang 我其实不是很理解 tcp 的有序性，因为之前朦胧印象中实验结果与理论上不符，不过因为是很久远以前的事了也不是记得很清楚。

所以理论上如果仍然发出上述两个长请求，如果请求 1 中的某一个封包因为网络波动丢掉了，TCP 是会自动重传，再补传的封包收到前，无论 server 读取多少次，都不能从 recv 读取任何东西是吗（即使网卡已经收到了后续的封包）。

我印象中我以前的实验是 recv 始终能读出东西，丢掉的封包会被跳过，很神秘

@liprais 我个人使用过程中两种模式都没给我带来过任何不爽。但我其实很想知道如果以后还要设计更新的语言，那种模式是更合理的

@todd7zhang 感谢回复，我看了一下你的代码，感觉跟我说的不太一样，可能我没有描述清楚。我预想中的情况是，即使使用 header 标明长度，假设 client 在同一个连接中发出两次请求，分别为 herder = 102400 & 102400*'i'，即长度为 102400 的 i 字符，且带了一个描述长度的标头。之后又发送了一个 herder = 102400 & 102400*'j'的请求，即将上个请求中所有的 i 转换成 j，由于这两个请求都较长，会被拆成多次发送。

那么服务端第一次接收到 102400header 后，会读取接下来 102400 个字节作为一个请求。但接下来 102400 中未必是连续的请求 1，可能掺杂入请求 2 的内容，这种错误可能由网络波动导致，我不知道如何在本地模拟，本地由于没有网络延迟，一般 clinet 连续发出两个请求，server 也就连续收到两个请求，不太容易产生错位的情况

另外 lz 测试过基于 http 相对 tcp 构建的效率吗。我之前测试本地回环，进程间 socket 通信一个来回大概在 100 微秒这个数量级，http2 之类的协议是不是能达到类似效果？

想请问一下 lz，以前想用 socket 实现一个简单的 rpc，但是遇到问题。从效率角度讲，最好两者之间建立一次连接后可以一直使用，不需要重连。那么假设客户端向服务端发出两次请求，内容都比较长，需要拆分成多个封包发送，如果因为网络延迟，可能导致服务端收到的两个请求的封包的内容掺杂起来，这种情况应该如何解决呢

说个题外话，lz 考虑过压缩 io 流吗，最近发现压缩可以有效缩减传输量

@ivyliner 抱歉，我不用任何苹果生态产品，所以我没有 ios 或 macos

@Bijiabo 大概五年前开始就各种听说阿里云负面新闻了，最大的一次是 csdn 转出事件。我司所有服务现在也慢慢转出阿里云了，稳定没看见，价格贵倒是立竿见影

@xiangyuecn 因为实际业务场景不可能那么单纯，popen 一次就完事。实际处理中你可能需要修改已有文件，这样的话先命令行解码，再编辑，再命令行编码，可靠性和维护难度显然远低于程序内部 IOstream 一把梭，所以我称之为不能可编程化。楼上提供了一个第三方冗余，因为不影响整个操作流程，只是在结尾通过命令行调用一个附加品，所以我说这个可以。显然区别很明显。

我原贴当中就说了两种方案，用户级的备份逻辑显然是后一种选择，先问冗余肯定是因为要平衡效率和成本。比如你有 100T 的文件要备份，另外搞一些硬盘，将数据变成 200T 当然是能够解决，我只是综合考量失效后成本和备份成本，感觉这样对抗电子衰变已经可以接受了。

我很好奇这种级别的失效阿里云要负多少法律责任。感觉 ECS 失效是跟支付宝失效一个级别的大事故，如果我公司在上面运行了一些核心服务，造成的财产损失谁来负责。我很不希望听到类似于阿里云在用户协议中写明了这种情况用户自负，所以他不用负任何责任之类的故事

@gyf304 请问这个 CRC 应该如何理解，我理解的 CRC 都是在传输过程中发生的，比如写入硬盘的时候硬盘校验 CRC，来证明实际写入和希望写入相同。但是 zip 这个，感觉对应不上这个过程？


@neteroster 感谢，有时间研究一下，如果命令行模式能满足需求的话，popen 调用似乎成本也不高。最好是新建一个冗余文件而不修改源文件，这样完全作为外挂，不影响原有实现

另外 LZ 这个是小机箱吧，我以前折腾静音的同时本来是想搞个 itx 超迷你机箱，很喜欢这种整合的感觉，但是后来发现小机箱是静音的大敌，首先小机箱就过不去电源这关，强行上小电源一个个都吵的飞起。我后来换成了 matx 直接解决了很多问题，如果 LZ 换成 ATX 的话静音上会简单的多。

以前折腾过静音主机，感觉 LZ 这个情况感觉基本是无解。水冷肯定是不靠谱的方案，上水冷该响还是响，而且加了泵的声音，更吵了。

机器中主要几个响的部分都是有机械单元的部分，主要是机械硬盘、电源、风扇。我以前折腾的时候，电源这个没什么定制的办法，最后搞了个海韵，确实是静音的，效果不错。机械硬盘也没什么可定制的，直接全换成固态。

风扇方面是另一个噪音大头，主要分显卡、CPU 、机箱三块。显卡一般操作是拆风扇，换上自定义风扇，操作难度略高。我个人的方案是搞了个被动散热卡，性能基本 LOL 水平，遇到的坑是即使是被动散热，满载直接 90 多度，感觉很不利于二极管健康，所以后来上面又加装了个风扇。

CPU 方面定制度最高，有很多非常良好的风冷散热设计，你可以搞一个性能很强的平台，配合一个大体积的散热模块，只需要很微弱的风就能保持良好的温度。

风扇个人使用体验上，可变风扇维持在 200 转左右的时候声音是几乎听不到的，大概耳朵贴在机箱上才能听到转动，满足了我个人的需求。支持这么低转数的风扇不多，猫扇比较有名但是比较贵，我个人是淘宝上买的国产扇，效果也挺好的

@learningman 感谢，请问这个是什么触发原理。我开启了以后访问网站时第一次会触发，之后就都不会了

@James369
@XIVN1987
python 有 jit 不用特意查，pypy 拿欧盟 20 亿捐款已经是很多很多年前了。另外 cpython 有 jit 解释器，pyston 大概发布于去年十月，理论上具有与 cpython 完全相同的兼容性。当然实际测试中这个 jit 还是聊胜于无，跟 v8 那种 jit 不可同日而语

个人感觉前端学习过程中不得不面对过度封装的问题，实际上业务部分占的内容很少，甚至几乎没有，大部分学习时间是习惯各个框架的抽象以及使用方法等等，所以自学困难是正常的，这也是前端的行业壁垒之一，如果连这点壁垒都没有，前端程序员数量怕是还要增长一个数量级。。