lilydjwg

@no1xsyzy #36 这是 /dev/urandom 和 yes 的差别：

https://img.vim-cn.com/85/e96192a830c7b248c5bf60bbbf84c18156bc8d.png

@no1xsyzy #36 哦，我忘记说中间插入个 pv 看数据量了。你可以对比一下 /dev/urandom 和 yes 的生成速率。
@no1xsyzy #37 但是 gdb 是调用内核提供的 API （ ptrace ）的呀，是间接的呢。

@starsriver #26

> 硬件部分对于网络数据传输，也就只管二进制转模信号了，端口回来数据具体是个啥，怎么分配还是要软件来干，

是啊。剩下的都是网卡固件处理，然后转交 CPU 由 OS 继续处理。端口号都是 OS 的网络栈处理的。硬件要是干这个，那得把整个 TCP/IP 都给实现了……（感觉路由器都不想这么干吧）

> 关于网络系统有一本很厚的书，没看过。

那书里涉及到的东西太多了，远不止怎么收发数据这么简单。

> 随机数是硬件实现的，有一个周期，cpu 只是读取一下而已

不是所有设备上都有硬件随机数发生器的。

> 我记得在 linux 上对随机数在随机。。这种计算量对如今的设备，占用率不到万分之一。

你 cat /dev/urandom > /dev/null 试试？

> 硬件中断对高级语言写的软件层面作用已经不是很明显了

不写 OS 层的软件，谁接触得到硬件中断呀。OS 可不放心用户态的程序乱搞中断。

软件中断我没怎么了解过，刚看了一下维基百科。原来访存违例和调试啥的都是软件中断实现的。所以，软件中断也不是用户态进程能够直接接触到的。

我对硬件部分不太了解，因为我是软件工程师嘛。

@guolaopi #21 这个……内存的变化应该更明显。

@starsriver #14 你觉得你自己不蠢，可你说的也没几个对的。

不可能死循环轮寻 => 处理大流量的设备上是可能的，因为几乎每次轮询都有数据，效率比中断高不少
os 的触发器，就是别人说的中断 => 这里讨论的是硬件中断
每时每刻都会产生随即数来决定该为哪个服务分配资源 => 产生随机数挺累的，CPU 怎么可能一直去做，还干不干活了？任务调度是有算法的，一般使用带优先级的队列或者位图之类的东西，并不会使用缓慢的随机数
当对应编号及缓存地址存在数据缓存或者出现头数据，触发器会开始工作 => 并没有一个叫「触发器」的硬件会帮忙 CPU 做这部分处理
处理完后数据被寄存到内存里 => CPU 是先复制网络数据到内存里，再决定要如何处理。因为网卡的存储空间有限，你不及时处理就丢包了

@smallpython #19 「中断」是一个术语。CPU 工作的时候，网卡过来有事打断了 CPU，这就叫作中断。CPU 这时候根据中断向量表，找到对应于网卡中断的处理程序，然后 CPU 就知道有网络数据过来了。

只有在很繁忙的设备上才会使用轮询去处理网络数据。

当然，网卡是一直处于准备好接收数据的状态的。

@seeker #4 你没分清楚 bind 和 listen 是干什么的。bind 是绑定本地地址。listen 是设置 TCP / UNIX 套接字的状态，好让内核能够相应的处理。

正常工作的网络程序，也不是写个死循环 accept 就完事了。阻塞方案的方案，为实际处理事务需要通过子进程 / 线程来处理连接。调用 accept 的线程需要立即重新 accept 以等待下一个连接。不要写成我学编程的那样，不能同时处理多个连接……

accept 是阻塞的这说法也不对。accept 是否阻塞，取决于套接字是否设置了 O_NONBLOCK 标志。

@Fishdrowned #9 不对。网络处理有两种方式：轮询和中断。通用计算机中，通常操作系统会通过中断的方式来获知有新数据到达。

CPU 没事干了怎么办？降频省电啊！一直没事干怎么办？电力紧张的话（比如移动设备），可以休眠啊。

至于用户态的监听（ listen ）。呃，它就是设置一下连接的状态而已……用户态程序要获知新数据的到达，需要使用阻塞调用（ accept ）、I/O 复用接口（ epoll / poll / select ）、异步 I/O 等方案。

啊咧，几天前我终于收到更新啦～