@julyclyde #12 你说的对，51 确实是太老了，但是对于硬件有兴趣初学者来说 51 的 dataset 应该是很短很简单的了，初学者首先需要了解时钟、寄存器的作用和配置逻辑、地址空间管理分配、你写的代码如何作用于 io 、以及串口这些简单通信协议，而且还有那么多大学教材可用，过时归过时，但是计算机的这些基础眼见时间内应该是不会变的，合适的入门门槛还是很有利于学习进度的，不过似乎楼主想学习的操作系统和编译原理并不需要了解这些

协议定义是一回事，有没有被广泛实现使用就是另一回事了，毕竟理论和工程实现并不是一回事，osi 定义已经是几十年前的事了，当时也并未遇见到网路能发展到如今如此复杂的程度，未被大范围采用实现确实有不合理的地方，算是名存实亡吧

赞同 #2 ，初学者这还是选用毕竟老的但是好多大学课程都会用的 51 系列，或者现在使用量非常广的 stm 系列，硬件不比软件，且不说资料真的太少找起来非常麻烦，更要命的是个型号之间只能说大体相同，你找到的资料还需要对应型号才行，软件系统一般都有初始兼容，硬件几乎就都没这特性，而且好歹软件还能有个日志和错误输出，单片机没弄好之前就是个砖头，硬件权威的应该是各芯片的 dataset ，但是吧没点基础估计你都看不懂

@bambo 也许可以看哪个转哪个呗

@acbot 个人觉得 ipoe 应该算是只定义了实现流程，比如通过 dhcp 协议传递校验信息和管理会话过期，但实际服务端如何做校验、如何实现会话管理和 qos 并没有严格详细规定，这似乎也就是各家运营商在大结构固定但具体实现却又不完全统一的原因，而且吧所以在 openwrt 这样常用路由固件中并没有看到通用实现

静态地址需要 arp 协议接受的，当然不走 arp 知道 mac 地址直接发包也行，不过 ipoe 只是用 dhcp ，最简单的不过是 dhcp 分配再直接做 mac 和 ip 地址绑定就行，dhcp 过期时解绑，这样不需要改动网络协议你自己设置 ip 也是没用的

tunnel/udp2raw 和远程服务器之间再挂个 tcp 转发代理

tunnel/udp2raw 前面再挂个代理呗，代理转发的时候就可以支持域名解析了吧，本地只是转发流量的话性能也不会有多大损失

不过话说你不是做的是 https 连接池么，那么不就是要被后续请求继续使用么，那么只要保证后续请求都是同一个域名的，这个本来就没问题的吧，几乎 http 服务端都是支持的吧，并不需要额外实现

数据库不支持保存点吧，比如 mysql 好像就没有保存点支持

但是如果你是想复用 tsl 连接，那么显然可以啊，tls 连接本来和你传输的数据无关，如果你是想复用这个 tcp 连接再重新建立一个 tls 或者传输其他协议的数据，不修改服务端的情况下肯定不能了

如果服务端不能修改的话不能，否则不就是代理么，服务端自己解析不同数据包分别处理

@eviladan0s #6 持续用个几天就出来了，丢包率会慢慢升高，并不是一下子就完全挂了，再说不能用本身也是丢包率过高，当然如果短时间流量过高也会完全断了，但一般都是非常高的丢包率

FPGA 的编程语言和 c 可是完完全全不一样的，习惯了 c 的话估计也很难理解 FPGA 咋回事，或者你可以先搞个板子来先玩一下

@lmshl #17 https://github.com/snower/slock
顺便说我已经做出来了，真的不是在嘴炮，3 节点多机强一致阶段大概能有超过 10 万 qps ，并行阶段能接近 200 万 qps ，极其简单的协议也可以直接集成在 openresty 里，我还是觉得这种在非淘宝拼多多这种超大站点，这个应该是最容易实现维护的架构了，毕竟只要你不是动辄秒大量商品库存，只要在现有订单系统前添加拦截流程就可以，几乎不需要针对秒杀逻辑对订单系统做单独调整

@lmshl #17 网络请求又不是串行的，整个分布式锁本来也就只在加减一才串行，哪里有问题了，就算要多机强一致，网络请求同步过程依然可以并行，多机强一致下百万以上 qps 可能做不到，十几万 qps 也还是可以的，一旦库存抢完就进入完全并行阶段，百万以上 qps 不很轻松么，这个的实现有简单，直接集成在网关里也没毫无问题，这显然已经是改造最小集成最简单的方案了

@lmshl #14 那你这分布式锁实现有问题吧，否则按你这么说 mysql 也无法完成超过这个限值了，那怎么搞岂不是都没用了

超不超卖的本来也不难处理吧，想要尽可能可靠从秒杀来说，既然库存非常小否则也不叫秒杀了，那么就应该除了让正常库存进入下单流程外，其他请求的处理过程都尽可能短，最好到达网关就直接返回，你再搞快照搞回滚，那么不是增加了可能出错的点了吧，多一步就多一步出错的点，啥都不用做自然也不可能有任何异常了

@lmshl #4 粗略看下，秒杀的难点本来也不是多快，否则这的人大概率都能写出一个处理 10k 以上 qps 的程序，现实中秒杀麻烦的是除了要处理商品库存订单问题外，还有营销折扣系统、优惠系统、风控系统、配送与地址系统等等，这一系列下来之后会是一个非常长的流程，在各系统负载一致和事务一致处理起来会非常麻烦，从这一点上来说，直接使用带库存数分布式锁直接拦截在所有系统前面才是最容易实现且靠谱的方案，反而是使用队列平滑再反馈结果其实更麻烦

而且还有现实大概率不会出现却又不得不考虑的崩溃恢复问题，队列造成了较长处理链路是清理的复杂性想满足秒杀场景下较短的崩溃恢复时间还是十分难的，使用分布式锁拦截则可以设置较短的等待时间即可，也没有进入下单的业务流程，随着时间超时后就会自然恢复

@vopsoft #10 那有啥用，我说的是一般只一个进程只能用一个核心，7 层代理那就应该和 7 层比，和 4 层比个啥啊，4 层代理一般情况下都是受限于网速来的