@2232588429
明显是你们那里人员不足

找个有 BGA 拆焊台的再换，别找用风枪的
风抢的芯片温度没法精确控制，拆焊台可以
（大多数焊接问题都是由于受热不均匀引起的[不是热就好，要质量是有温度曲线这事的]）
（但一般用拆焊台的都是修显卡 /主板那些）

@chairuosen
理想状态下至少少了调度时间（走路）
而且备餐时候合并了同类任务，至少可以并行操作了
(一杯可乐，一杯橙汁，再来一杯红茶，这东西完全是可以跨订单同步制作的）
(以前的方式必须调度并争夺饮料机的锁资源[走路，加冰、等待(争夺资源)、放杯]）
(过程中如有失误会导致子任务丢失 /出错，忘记饮料 /忘记不加冰)

这种流程的优势在于点餐员工和备餐员工分开。
仔细观察会发现，厨房变成了流水线作业形式
备餐员工依赖屏幕给出的餐单备餐，再由外面柜台工作人员把东西放入餐盘。
一般而言，饮料区会有一个员工独立负责。

整体效率实际上是提高了不少
这是一个标准的生产者消费者模式队列，所有中间过程都有缓存（柜台）
而以前的方式是阻塞调度，一个人干很多事，大多数时间是花费在调度上面（走路）

补充：其实只要一杯饮料的情况下任何方式都需要等待饮料机队列处理完毕了才可处理，老方式并没有更快
（插队是另一回事）

@trepwq
那不就是光猫么
和家用宽带一样搞就好

这报价，直接买 GEN8 吧

静态 IP 吧？接个交换机上去就好了

@sennes
自己做板子树莓派的性能就太弱了
提醒： GPIO 的性能并不高（读写都得过 CPU ）

不过最终还是看需求吧

@Kilerd
不买才是正道，性能糟糕

做硬件的人对树莓派应该提不起什么兴趣
性能局限太大，接口可玩性太低，几乎所有需求都会有相应的积木原件可供购入

不如范围拓宽点搞个硬件群吧

车多了，收费站也就多起来了

也有可能光衰太大

补充： 18 楼拼写错误， SPF->SFP （ Small form-factor pluggable transceiver ，小封装可插拔收发器）

@yxc
无线网络是共享信道，千兆都不到（或者难以达到）
现在已经开始推千兆光网了，未来 20 年 100M 入户这个就有点绝对了
六类网线在千兆网络中意义不大，万兆网络又不可能用六类，多出的钱不如铺一组光纤来得实在

铺光纤不一定是全光网络，点对点光网也是很有用的，带个盘柜之类的，以后的发展谁能预料呢

光纤只有单模 /多模区分，其中某些特性依据光纤标准不同有所区别
例如：线径、容许弯曲度、色散、光衰等。。。
（具体标准就是楼上说的各种类型）

一般设备光纤部分是使用 SPF 插槽，允许依据实际情况选择合适的光电转换器
SPF 的光电转换器其实就是一个激光器配上适应的外围电路，把电信号转换成光信号
光纤本身的几芯是说一根线里面光纤的数目，一般布线会考虑一组使用再加一组备份
如果是单模网络，自然就是多芯的单模光纤，多模网络同样。
（也可以用单芯线，但是中间断了就必须重新布线了）

现在而言多模的光电转换部分价格较为低廉，但是线材较贵
单模的光电转换较贵，但是线材价格低廉

一路网络需要多少线芯是依据网络而定的，例如现在的家用光纤宽带使用的是便于布线的单纤 PON
下行是一个波长，上行是另一个波长，所以能在单纤内传输不怕干扰
这种光纤通常使用单模光纤，缺点是这种光模块价格较高（相对）
（单模原因是一般这种使用形式都是远距离传输，只有单模能符合要求）

另一种就是上行下行分开的双线形式，自然需要两条光纤
一般内网布线都是这种居多，使用的是 LC 接头（一个 SC 接头的宽度能容量两条纤）
二手的光纤网卡也是这种类型居多（那种光模块固定在板上的光纤卡）
通常使用多模光纤（毕竟机房内部）

综上，考虑以后升级，上一组便宜的多芯单模光纤，接头做 FC （拧螺纹那种）（ 4 芯是基础）
以后接机器的时候用跳线转接（淘宝一堆定制厂商，便宜实惠）（记得编号标好线序）
然后在打算短期内搞个廉价光网的一段搞个多模（ 4 芯）带宽大概是 4G 一组
（万兆要价格降下来得等千兆家用普及，那时候模块肯定便宜，网卡也会跟着降价）

@DuckJK
网卡收到的数据通过中断的方式通知内核处理，数据的传递一般是 DMA
（不可能 CPU 直接读不然负载太高了）
（ DMA 直接拷贝数据到系统内存，当然也有可能是网卡上的缓冲区，这个说不准）
（通知或许除了中断还有别的处理方式，这个不了解，因为频繁的中断会非常耗费 CPU 资源）
所有的 Socket 都是内核分配管理的，网卡在通知内核收到包以后，内核就去获取这一个包然后解析
（可以理解成中间有个缓冲区，内核从缓冲区取数据）
内核处理包的过程会验证包是否合法，然后路由到合适的地方
（这个路由包含多种意思，一个是数据包的路由另一个是转发到合适的处理程序[的缓冲区]）
如果是 TCP ，底层的会进行拥塞控制处理（组包、验证、依据情况发回 ACK 信息各种各样）
（驱动能在拥塞控制之前接管所有 TCP 处理，这也是锐速的原理）
组成合法的流数据以后再发往给上层应用的缓冲区，通知上层应用


“如果 zlib 支持流解压缩，那就是跟压缩数据大小没关系，只要是合法压缩数据，都可以解压缩，只是从 readbuffer 到 zlib 的 buffer ，是不是可以这么理解。 ”
就是这么回事，我并不知道 zlib 是否支持流解压，也没查。。这个依据实际情况判断
（推广到别的编码方式也一样）

“ reponse.content 在未提供长度的情况下阻塞到链接断开，这个链接断开是跟 read 的长度有关系么？还是到什么样的情况下链接断开？谢谢啦”
这个原因是 HTTP 头未提供数据长度的情况下客户端并不知道数据有多大
只能阻塞到 TCP 链路主动断开才能获知已经收完数据
（如果有防火墙的地方，这个数据很可能是损坏的，因为防火墙有可能提前掐断这个链路）

@DuckJK
zlib 如果支持流解压，那么你只是把数据从一个缓冲区搬到另一个缓冲区而已
如果 zlib 不支持流解压，那么你提供给 zlib 的必须是一个合法的压缩数据

response.content 的动作应该会在 HTTP 头有提供长度的情况下阻塞缓存完整数据
在未提供长度的情况下阻塞到链接断开。
如果是解包时候的处理，同上一段

“用 Python 实现只保留 list 里个位数为 2 的数。”
希望你的问题没写错

@current
针对 23 楼的回复，网卡收包以后是先通知内核，内核处理完了再通知应用层。
应用层收到的 TCP 数据不一定可靠，但绝对是合法数据。
（不可靠的原因是校验码碰撞）