程序中监听的含义?

@smallpython #18
em.....也不知道我是不是理解有偏差。但是我觉得不能是单纯简单的“CPU 死循环”，可以写个程序把所有端口都监听起来看一下 CPU 的变化。。。

@jworg 还是知乎大神多啊

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

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

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

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

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

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

@lilydjwg 大概解释一下而已，而且这种东西软件为主，我也就是简单说说，毕竟不是计科出来的，我就是个修电表的。。关于网卡数据和随机数，访问 1037u.starsriver.net:1080 （家里放着的工控机）定位到 entropy 和 softnet 看一下关系两者就清楚了。

解释并没有错，只是在于看这段话的人是谁了。毕竟知识方向不一样，用不着相互批判。。。

科班出身？

硬件部分对于网络数据传输，也就只管二进制转模信号了，端口回来数据具体是个啥，怎么分配还是要软件来干，至于任务调度还是轮寻还是数据的处理。过程讲那么细都可以教科书了。关于网络系统有一本很厚的书，没看过。

cpu 是通电一直在工作的，只不过没有数据处理的时候晶震会慢下来，也就省电了。

现代网卡好象有 16k ＊ 512 还是多大的缓存区了，cpu 存储数据的压力不大，压力大的是硬盘。
如果没记错，所有的软件监听端口都直接依赖 os 的底层，那个库的源码。。。非常有硬件思维。明年我的课题估计就是拿 fpga 实现一下。。套接字都是已经编码好的，都是端口绑定之后的事情了，os 在这之前就会把数据分好。要真的搞清楚端口监听和绑定的细节就很有意思了，估计要触法 ip （ Intellectual Property ）墙，这部分已经不太属于软件方向了。

随机数是硬件实现的，有一个周期，cpu 只是读取一下而已。我记得在 linux 上对随机数在随机。。这种计算量对如今的设备，占用率不到万分之一。

南桥芯片提供给 cpu 的大部分外设任务调度，包括网卡的数据通信，以前单片机用的好象是 8 什么什么集成的可编程模块。。忘了，最基本的中断就是触发和比较，这个触发器指数字电路触发器。

硬件中断对高级语言写的软件层面作用已经不是很明显了，硬件时时刻刻在中断，一般的 pc 机一秒大概几百次到上万次。把硬件中断比作被针扎会疼，软中断就象是你看到数学题要想公式一样很复杂了，一般 os 层面的说的是软中断，总数差不多是硬件中断的五分之一。

@starsriver #26

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

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

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

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

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

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

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

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

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

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

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

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

@starsriver 虽然我不太懂,但丝毫不影响我喷你,你就是个蠢货,知道点皮毛就不知道怎么得瑟了,你要上天啊

@pussy2019 虫子总是到处飞？

说是 “监听” 不如说是 “记录”，底层接收（轮询亦或中断）网卡芯片传送过来的数据投递到网络子系统，网络子系统内部会检索有无 “目的端口” 这一记录项，然后再通过记录项对应的参数传递到对应的应用中，当然此时应用可能在轮询也可能处于阻塞中。

希望有大佬来详细解读一下

硬件中断，epoll 了解一下

问的是程序中的监听，不是系统的

监听端口，端口分为硬件端口和软件上的端口

硬件端口一直在接收数据（电平一直在变化），能不能被处理就看你的程序是不是在正确的时刻运行处理程序，在没有缓存的硬件结构里，数据到达时没有处理，那就丢了

网卡（一般）并不会区分收到的数据来自哪个应用程序和应该给哪个程序，它收到数据（包括预先定义好的所谓的端口号在硬件来看也只是数据），交给驱动软件处理，提取数据里的端口号（软件端口），再交给其对应的上层软件处理

至于上层软件能不能及时正确处理，可以轮询，也可以在硬件上设个触发器，让处理器在时间到或有对应事件发生时，让它及时处理，至于触发器，有多个，有优先级，由程序设定，触发时也能告诉处理器从哪段代码开始执行

@xuxuzhaozhao 你在说什么？( https://imgur.com/1KXZOmG)

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

请看 http://1037u.starsriver.net:1080/#menu_system_submenu_entropy;help=true （你自家放的工控机？）

> Ideally a system with high entropy demands should have a hardware device for that purpose (TPM is one such device).

注意关键词： "Ideally", "with high entropy demands", "should"

——

@lilydjwg #27

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

这不能证明什么，你 yes > /dev/null 试试？

@lilydjwg
> 原来访存违例和调试啥的都是软件中断实现的
> 软件中断也不是用户态进程能够直接接触到的
调试器（ gdb ）不是用户态程序？

思而不学

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

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

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