Network

network namespace network namespace 是实现网络虚拟化的重要功能,它能创建多个隔离的网络空间,它们有独自的网络栈信息。不管是虚拟机还是容器,运行的时候仿佛自己就在独立的网络中。这篇文章介绍 network namespace 的基本概念和用法,network namespace 是 linux 内核提供的功能,这篇文章借助 ip 命令来完成各种操作。ip 命令来自于 iproute2 安装包,一般系统会默认安装,如果没有的话,请读者自行安装。 NOTE: ip 命令因为需要修改系统的网络配置,默认需要 sudo 权限。这篇文章使用 root 用户执行,请不要在生产环境或者重要的系统中用 root 直接执行,以防产生错误。 ip 命令管理的功能很多, 和 network namespace 有关的操作都是在子命令 ip netns 下进行的,可以通过 ip netns help` 查看所有操作的帮助信息。 默认情况下,使用 ip netns 是没有网络 namespace 的,所以 ip netns ls 命令看不到任何输出。 创建 network namespace 也非常简单,直接使用 ip netns add 后面跟着要创建的 namespace 名称。如果相同名字的 namespace 已经存在,命令会报 Cannot create namespace 的错误。 ip netns add net1 ip netns ls ip netns 命令创建的 network namespace 会出现在 /var/run/netns/ 目录下,如果需要管理其他不是 ip netns 创建的 network namespace,只要在这个目录下创建一个指向对应 network namespace 文件的链接就行。 ...

archlinux ip forward, ip_forward 开启数据包转发 vim /etc/sysctl.d/30-ipforward.conf net.ipv4.ip_forward=1 net.ipv6.conf.default.forwarding=1 net.ipv6.conf.all.forwarding=1 sysctl -a |grep net.ipv4.ip_forward 配置 nftables 的转发规则 nftables 默认在 forward 链抛掉所有数据。 如果启用了 nftables, 一定修改一下 nftables 的默认配置文件。否则报文在 iptables 的 forward 链 accept 之 后会被 nftables 规则抛掉。 https://wiki.archlinux.org/index.php/Internet_sharing ip_forward 与路由转发 https://blog.51cto.com/u156838989/1880744

IP,TCP 和 HTTP 172.16.128.0/24 经常看到这类IP地址"/24"表示什么意思？ 子网掩码, 代表多少个1 子网掩码是4个8位2进制数组成的, 换化成10进制是就是现在这样的, 如255.255.255.0, 换成2进制的话就是11111111 11111111 11111111 00000000, 前面有24个1, 也就是ip/24, 192.168.1.1/24 就表示ip是192.168.1.1, 子网掩码是255.255.255.0 http://objccn.io/issue-10-6/ 当 app 和服务器进行通信的时候,大多数情况下,都是采用 HTTP 协议。HTTP 最初是为 web 浏览器而定制的,如果在浏览器里输入 http://www.objc.io ,浏览器会通过 HTTP 协议和 www.objc.io 所对应的服务器进行通信。 HTTP是运行在应用层上的应用协议,而不同的层级上都有相应的协议在运行。层级的堆栈关系一般可以这么描述: Application Layer - e.g. HTTP – Transport Layer - e.g. TCP – Internet Layer - e.g. IP – Link Layer - e.g. IEEE 802.2 所谓的 OSI (Open Systems Interconnection,开放式系统互联) 模型定义了七层结构。本文会关注应用层 (application layer)、传输层 (transport layer) 和网络层 (internet layer),它们分别代表了典型的 HTTP 的应用的 HTTP,TCP 以及 IP。在 IP 之下的是数据连接和物理层级,比如像 Ethernet 的实现之类的东西 (Ethernet 拥有一个数据连接部分以及一个物理部分) 。 ...

windows netsh 端口转发 http://aofengblog.blog.163.com/blog/static/631702120148573851740/ 在windows上用netsh动态配置端口转发 下载LOFTER客户端 使用多个虚拟机，将开发环境和工作沟通环境分开 (即时通，办公系统都只能在windows下使用…) ，将开发环境的服务提供给外部访问时，需要在主机上通过代理配置数据转发。 VirtualBox提供了端口转发的功能，可以将主机中的端口转发至指定IP的虚拟机中的端口，支持TCP协议和UDP协议。但有一个缺点: 需要重启虚拟主机才生效。 其实在Windows中，如果想做端口转发，可以使用Windows自身携带的服务:netsh，使用netsh interface portproxy指令，新增和修改配置信息后，即时生效，并且重启系统后配置信息仍然存在，非常方便。适用于WindowsXP、Windows7，其他的版本还没有试过，支持IPv4和IPv6，但是只支持TCP协议。 新增端口转发 命令 netsh interface portproxy add v4tov4 - 添加通过 IPv4 的 IPv4 和代理连接到的侦听项目。 netsh interface portproxy add v4tov6 - 添加通过 IPv6 的 IPv4 和代理连接到的侦听项目。 netsh interface portproxy add v6tov4 - 添加通过 IPv4 的 IPv6 和代理连接到的侦听项目。 netsh interface portproxy add v6tov6 - 添加通过 IPv6 的 IPv6 和代理连接到的侦听项目。 命令语法 以netsh interface portproxy add v4tov4为例，其语法格式如下: netsh interface portproxy add v4tov4 [listenport=]| ...

tcp状态 LISTENING, ESTABLISHED, TIME_WAIT, CLOSE_WAIT TCP协议规定, 对于已经建立的连接, 网络双方要进行四次握手才能成功断开连接, 如果缺少了其中某个步骤, 将会使连接处于假死状态, 连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接, 所以很有必要保证无用连接完全断开, 否则大量僵死的连接会浪费许多服务器资源。在众多TCP状态中, 最值得注意的状态有两个: CLOSE_WAIT 和 TIME_WAIT。 LISTENING 状态 TCP 服务启动后首先处于侦听 (LISTENING) 状态。 ESTABLISHED 状态 ESTABLISHED的意思是建立连接。表示两台机器正在通信。 CLOSE_WAIT 对方主动关闭连接或者网络异常导致连接中断, 这时我方的状态会变成 CLOSE_WAIT 此时我方要调用 close() 来使得连接正确关闭 TIME_WAIT 我方主动调用 close() 断开连接, 收到对方确认后状态变为 TIME_WAIT。 TCP 协议规定 TIME_WAIT 状态会一直持续 2MSL (即两倍的分段最大生存期), 以此来确保旧的连接状态不会对新连接产生影响。处于 TIME_WAIT 状态的连接占用的资源不会被内核释放, 所以作为服务器, 在可能的情况下, 尽量不要主动断开连接, 以减少 TIME_WAIT 状态造成的资源浪费。 目前有一种避免 TIME_WAIT 资源浪费的方法, 就是关闭 socket 的 LINGER 选项。但这种做法是 TCP 协议不推荐使用的, 在某些情况下这个操作可能会带来错误。 http://www.cppblog.com/prayer/archive/2009/04/01/78592.html http://www4.cs.fau.de/Projects/JX/Projects/TCP/tcpstate.html TIME_WAIT CLOSE_WAIT http://blog.csdn.net/kobejayandy/article/details/17655739 在服务器的日常维护过程中,会经常用到下面的命令: ...

‘MITM,ARP缓存中毒’ http://www.cnblogs.com/songhan/archive/2012/07/25/2607704.html ARP介绍 ARP是个地址解析协议。最直白的说法是: 在IP-以太网中，当一个上层协议要发包时，有了节点的IP地址，ARP就能提供该节点的MAC地址。 ARP缓存: ARP cache 是个用来储存(IP, MAC)地址的缓冲区。当ARP被询问一个已知IP地址节点的MAC地址时，先在ARP cache 查看，若存在，就直接返回MAC地址，若不存在，才发送ARP request向局域网查询。【在A不知道B的MAC地址的情况下，A就广播一个ARP请求包，请求包中填有B的IP(192.168.1.2)，以太网中的所有计算机都会接收这个请求，而正常的情况下只有B会给出ARP应答包，包中就填充上了B的MAC地址，并回复给A。A得到ARP应答后，将B的MAC地址放入本机缓存，便于下次使用。本机MAC缓存是有生存期的，生存期结束后，将再次重复上面的过程。】【ARP请求和ARP回复。请求和回复的目的在于确定与特定IP地址相关的硬件MAC地址，这样流量才能够在网络上找到目的地。请求数据包被发送给网络段上的每台设备并发出信息"我的IP地址是XX.XX.XX.XX，我的MAC地址是 XX:XX:XX:XX:XX:XX，我需要将信息发送给这个IP地址XX.XX.XX.XX，但是我不知道它的硬件地址，请这个IP地址将其MAC地址回复给我?“回复会以ARP回复数据包的形式，并回复说"你好，传递设备，我就是你要找的IP地址XX.XX.XX.XX，我的MAC地址是 XX:XX:XX:XX:XX:XX”，收到回复后，传递设备会更新其ARP缓存表，然后设备就可以与另一台设备进行通信。】 ARP欺骗 任何机器都可以向另一台主机发送ARP回复数据包，并迫使主机更新其ARP缓存。假冒IP和MAC。 ARP协议并不只在发送了ARP请求才接收ARP应答。当计算机接收到ARP应答数据包的时候，就会对本地的ARP缓存进行更新，将应答中的IP和MAC地址存储在ARP缓存中。 因此，当局域网中的某台机器B向A发送一个自己伪造的ARP应答，而如果这个应答是B冒充C伪造来的，即IP地址为C的IP，而MAC地址是伪造的，则当A接收到B伪造的ARP应答后，就会更新本地的ARP缓存，这样在A看来C的IP地址没有变，而它的MAC地址已经不是原来那个了。由于局域网的网络流通不是根据IP地址进行，而是按照MAC地址进行传输。所以，那个伪造出来的MAC地址在A上被改变成一个不存在的MAC地址，这样就会造成网络不通，导致A不能Ping通C！这就是一个简单的ARP欺骗。 危害 拒绝服务 一个黑客可以只做简单的操作就将一个重要的IP地址和一个错误的MAC地址绑定。 例如，黑客可以发送一个ARP响应报文 (到你的计算机) 将你所在网络的路由器 (即我们常说的网关，译者注) IP地址和一个根本不存在的MAC地址绑定起来。你的计算机以为它知道默认网关在哪，但是事实上它的所有数据包，其目的地址都不在这个网络的网段上 (因为那个不存在的MAC不在此局域网的网段上，译者注) ，它们最后消逝在了无尽的比特流中 (即因数据包的生命周期到了而信号消失，译者注)。仅仅这一下，黑客就能阻止你连上因特网。 中间人攻击 黑客利用ARP缓存中毒来截获你的局域网中两台设备之间的网络信息。例如，我们假象黑客想要窃听你的计算机，192.168.0.12，和你的网络路由器 (即网关，译者注) ，192.168.0.1，之间的通信信息。 黑客先发送一个恶意的ARP “响应” ( 因为在此之前根本没有请求) 到你的路由器，将他的计算机的MAC地址和192.168.0.12绑定。 然后，黑客在发送一个恶意的ARP响应到你的计算机，将他的MAC地址和192.168.0.1绑定起来。 现在你的机器以为黑客的计算机是你的路由器了。 最后，黑客开启一个叫IP转发的系统功能。这个功能让黑客能将所有来自你的计算机的网络信息转发到路由器。 现在，只要你尝试上网，你的计算机就会将网络信息发送到黑客的机器上，然后黑客再将其转发到路由器。由于黑客仍然将你的信息转发到网络路由器，所以你并不会察觉到他已经截获了所有你的网络信息，或许还窃听了你的明文密码或者劫持了你曾经安全的网络会话。 MAC洪泛 MAC洪泛是一种旨在网络交换机的ARP缓存中毒技术。当这些交换机流量超载时它们常常进入到 “集线器” 模式。在 “集线器” 模式中，交换机由于太过繁忙而不能执行它的端口安全检测功能，而是仅仅向网络中的每一台计算机广播所有的网络数据。利用大量的假冒ARP响应数据包去洪泛一台交换机的ARP映射表，黑客能使大多数制造商的交换机超载，然后当交换机进入 “集线器” 模式时，就可以发送 (恶意的) 包去嗅探你的局域网。 防御 小型网络 静态IP地址和静态ARP映射表。 大型网络 “端口安全” 功能是允许你强制使你的交换机在每个端口只允许 (IP地址对应的) 一个MAC地址通过。这个功能会阻止黑客改变他机器的MAC地址或试图映射多个MAC地址到他的机器上。 一般网络 ARP监视工具，比如ARPwatch，当有不正常的ARP通信时它会提醒你。 http://www.xker.com/page/e2010/1122/99144_4.html http://net.anquan365.com/protocol/other/201112/166775.html

Windows 共享网络设置 (有线网络和无线网络） 有线共享网络 打开连接 Internet 的 “本地连接 属性” 窗口，切换到“共享”标签页 在“共享” 标签页中，勾选 “允许其他网络用户通过此计算机的Internet连接来连接”，确定；如果网络连接中超过两个连接，则还需要选择需要共享的连接 打开另一个需要共享的连接的“本地连接 属性”窗口，选择“Internet 协议版本4 (TCP/IPV4）属性”，设置静态IP，这里的设置的IP网段应避开连接Internet的网段，否则易造成IP冲突等问题 这样配置后，这个网卡就想当于共享网络的网关，其他要共享此连接的电脑只需要设置将IP地址配置成同一网段与上述不同即可 (如192.168.71.2），其余配置不变 无线共享网络 无线共享在双网卡的情况下，用于共享需要是无线网卡，这里可以采用与上述相同的方式进行无线网络共享；当然也可使用如360出的免费360wifi，可以不用进行配置 如果进行上述配置后，各连接正常，但是无法访问Internet，则是由于Internet Connection Sharing(ICS)服务未启动。 右键“我的电脑”-》管理-》服务和应用程序-》服务-》双击Internet Connection Sharing(ICS)-》启动 双击Internet Connection Sharing(ICS)状态栏显示“已启动”即可 ———————————————— 版权声明：本文为CSDN博主「小蜗coding」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/acsder2010413/article/details/40395621

tcp http 调试, 抓包工具, wireshark, Fiddler wireshark wireshark 的前身是Ethereal，2006年因为其创始人Gerald Combs的跳槽而改名为wireshark。它是一个跨平台的软件，可以在unix系列、linux、mac os、windows等多个平台上面进行网络协议抓包工作。同时他也是一个开源软件，有兴趣的话可以下载源码深入了解。我们可以通过wireshark官网进一步了解相关知识及下载该软件。 fiddler fiddler 的定位是网页调试工具，能记录所有客户端和服务器的http和https请求，允许你监视，设置断点，甚至修改输入输出数据。我们还可以为fiddler安装自己所需的插件，从而更好的利用fiddler的强大功能。详细介绍信息可以通过fiddler官网进一步了解， 做Web开发或者Web分析经常需要查看Http通讯的过程，项目实践中，很多Web相关的各种各样稀奇古怪的问题，最后都能通过分析HTTP流量得以解决。我到现在用过的比较好用的两个Http流量分析工具，一个是HTTP Watch，另外一个是Fiddler。 HTTP Watch HTTP Watch是我最早用过的HTTP流量分析工具。它只能用于IE和Firefox浏览器上。 它有两种使用界面，一种是以插件的形式附加在浏览器上面，供实时分析使用。你可以看到当前窗口中所有的HTTP请求/响应过程。另外它允许把实时分析的结果保存为后缀名为hwl的文件，然后用其自带的Http Watch Studio工具打开，这样既方便了以后对此过程再次进行分析，也方便与其他人共享，易于调试。下面是它的插件界面的截图，非常清新简洁: image 它的界面非常简单，主要分成三部分: 工具栏，HTTP消息概览，HTTP消息细节窗口。 工具栏主要是方便你快速过滤出你想要分析HTTP消息。 image 你可以按照HTTP流量内容类型去筛选，例如只查看图片相关的HTTP流量。或者根据Url是否包含某特定字符串进行过滤，等等。另外工具栏也提供了"清缓存"和"清Cookie"两个非常常见的操作。 HTTP消息概览栏可以让你快速查看当前窗口中的所有HTTP消息，每个HTTP消息花费的时间，以及服务器返回的状态码，请求的Url等等。默认它还会按照HTTP消息发起的页面进行分组，方便查看。 最底部就是每条HTTP消息的详细信息。最后面的Stream标签页显示的是最原始的HTTP请求/响应流。这里记录的信息是最详细的。 image 为了方便分析常见的需求，它将HTTP消息分成几个部分，也就是你上面看到的Headers、Cookies、QueryString、PostData等等标签页所展示的内容。下面的图展示了此次HTTP通讯涉及的Cookie，每个Cookie的键值，作用的主机域以及路径、过期时间等。 image HTTP Watch Studio就不做介绍了，基本和插件版本的一致，只不过可以脱离浏览器直接分析以前保存的HTTP通讯过程。 HTTP Watch提供了基础版本以及专业版本，其中基础版本是免费的。事实上基础版本提供的功能已经能够适用于大多数的情况了。 官方站点: http://www.httpwatch.com Fiddler Fiddler是微软推出的一个免费的HTTP流量分析工具。一开始我以为他只支持IE——毕竟是微软的东西——加之常见的功能HTTP Watch都已经够用了，就没怎么关注。这些天因为要调试Chrome浏览器上的一些问题，而Chrome自带的开发者工具又非常糟糕，搜着搜着又再次找到了Fiddler。 image Fiddler的界面和HTTP Watch差不多，都是分成三部分，工具栏+HTTP通讯总览+HTTP消息细节。只不过默认情况下它把HTTP消息细节窗口放到了右边。 用了一阵子发现，HTTP Watch能做到的，基本在Fiddler上都可以实现。不过Fiddler的界面显得比HTTP Watch要复杂一些，因为它提供了一些HTTP Watch没有的功能。下面主要介绍的是它和HTTP Watch不一样的地方，一样的功能就略过了。 Fiddler能够监视所有本地进程的HTTP消息，而不仅限于IE、Firefox这些浏览器。这比HTTP Watch适用范围更广。下图显示了google talk和Visual Studio发起的HTTP请求. image 安装完Fiddler之后你会发现IE还有Firefox中都多了个Fiddler的插件，Fiddler的原理实际上是在本地启动HTTP代理服务器，因为除了Firefox以外，很多应用程序包括其他浏览器都会应用IE上设置的代理。所以Fiddler只需要设置IE和Firefox这两个浏览器的代理服务器即可。这个插件做的事情实际上就是起到动态切换代理服务器的作用。 选中左侧某条特定的HTTP请求，Fiddler会在右侧帮你统计一下当前选中的HTTP消息的一些性能指标，例如发送/接受字节数，发送/接收时间，还有粗略统计世界各地访问该服务器所花费的时间。 image 在右侧窗口中，你可以采用各种视图去解析同一个HTTP请求/响应。例如以纯文本视图，或者图片视图，十六进制视图等等。它还提供了一个压缩测试工具，告诉你如果启用了Gzip或者deflate等压缩之后能够节省多少传输字节。 image Fiddler会记录下每次HTTP通讯的过程，然后允许你在不将请求发送给服务器的情况下返回之前记录的响应结果。 Fiddler还允许你对HTTP请求下断点，然后你可以根据情况来决定每个请求所返回的响应。 如果你想测试一些特殊的HTTP请求或者修改当前请求一些报头的时候，你不需要自己再写一个小程序去实现这样的功能，因为在Fiddler提供了直接编写HTTP请求的功能。你可以模拟浏览器去发送HTTP消息。 Fiddler支持插件机制，如果你觉得它提供的功能还不够用，那么你可以安装各种插件以增强它的功能或者编写自己的插件。官网上提供了几个不错的插件供免费下载。一个可以用于对HTML和Javascript代码进行语法着色，还有一个可以监视Web应用程序的安全隐患。 官方站点: http://www.fiddler2.com 总结 总的来说，HTTP Watch的使用相比Fiddler更简洁、容易上手。但是只适用于IE和Firefox。Fiddler功能更为强大，适用范围更广，而且还是免费的。具体用哪个就得看实际需求了。 1.为什么是Fiddler? ...

Raspberry Pi配置为无线路由器 http://www.cnblogs.com/DaochenShi/p/3152981.html 因为自己有个RPi，但是之前用的8188CUS芯片的无线网卡不支持，虽然当时买的时候是为了让笔记本连双WiFi的，因此只挑了个最便宜的。后来发现没法在RPi上面做AP，于是就又重新买了个。国内也有树梅派的论坛讨论过哪些无线网卡的支持，发现Ralink的芯片可以，因此就再花了34块钱买了个腾达的W331M，使用最新的Raspbian内核来进行操作 (非最新的话可能需要自己编译驱动) 。 以下是结合上面的参考链接给出的如何将RPi搭建为一个路由器: 首先是必备材料: RaspberryPi B版 (就是带有线网卡的那个版) ，内存512/256都可以，我的是256的。 一个已经可以正常运行的SD卡，这个如何准备我在我的另外一篇随笔当中提到过，所以这里不再赘述。 一个可以支持AP模式的无线网卡。 有线网卡也得联网。 然后是必备技能: 如果你是无显示器运行的，则需要会使用nano (vi也可以) 如果你是有显示器运行的，那么可以在图形界面下面以root或者sudo来运行文本编辑器 总之，就是你得会编辑文本文件才可以进行下面的操作。 感谢原文给出的驱动提示，这里也抄一下。请确认无线网卡支持AP模式或者Master模式，已知下列网卡的具体情况: Edimax 不支持 Access Point AirLink 101 / AWL5088 不支持 Access Point Ralink RT5370 支持 Access Point 想看你使用的是那种芯片？用lsusb吧！(省略了部分输出) pi@raspberrypi ~ $ lsusb … Bus 001 Device 007: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter 呼……一大波前提说完了，下面要干正事了！ 先说一下大概步骤: 打开WiFi 指定IP，也就是建立一个WiFi局域网 使用NAT，也就是能让你WiFi网络和有线网络可以通信。 正文开始了: 安装软件 sudo apt-get install hostapd udhcpd 配置DHCP，也就是编辑文件/etc/udhcpd.conf ，基本上按照下列内容来做: <img alt="复制代码" src="http://common.cnblogs.com/images/copycode.gif" /> start 192.168.42.2 # This is the range of IPs that the hostspot will give to client devices. end 192.168.42.20 interface wlan0 # The device uDHCP listens on. remaining yes opt dns 8.8.8.8 4.2.2.2 # The DNS servers client devices will use. opt subnet 255.255.255.0 opt router 192.168.42.1 # The Pi’s IP address on wlan0 which we will set up shortly. opt lease 864000 # 10 day DHCP lease time in seconds ...

nl80211 not found 加载mac80211模块， modprobe mac80211 http://blog.sina.com.cn/s/blog_64de8a0301018jty.html

Netty version latest 4.1.68 current 4.1.22 Netty是Java领域有名的开源网络库，特点是高性能和高扩展性，因此很多流行的框架都是基于它来构建的，比如我们熟知的Dubbo、Rocketmq、Hadoop等 Netty是由JBOSS提供的一个java开源框架. Netty提供异步的, 事件驱动的网络应用程序框架和工具，用以快速开发高性能、高可靠性的网络服务器和客户端程序. 也就是说，Netty 是一个基于NIO的客户，服务器端编程框架, 使用Netty 可以确保你快速和简单的开发出一个网络应用，例如实现了某种协议的客户，服务端应用。Netty相当简化和流线化了网络应用的编程开发过程，例如，TCP和UDP的socket服务开发。 “快速"和"简单"并不意味着会让你的最终应用产生维护性或性能上的问题。Netty 是一个吸收了多种协议的实现经验，这些协议包括FTP,SMTP,HTTP，各种二进制，文本协议，并经过相当精心设计的项目，最终，Netty 成功的找到了一种方式，在保证易于开发的同时还保证了其应用的性能，稳定性和伸缩性。 netty uml @startuml interface ChannelHandlerContext interface ResourceLeakHint class NioEventLoop{ protected void run() private void processSelectedKeys() private void processSelectedKeysOptimized() private void processSelectedKey(SelectionKey k, AbstractNioChannel ch) } class AbstractNioByteChannel class NioByteUnsafe{ public final void read() } class DefaultChannelPipeline{ AbstractChannelHandlerContext head public final ChannelPipeline fireChannelRead(Object msg) } class HeadContext class AbstractChannelHandlerContext { AbstractChannelHandlerContext next AbstractChannelHandlerContext prev DefaultChannelPipeline pipeline ChannelHandlerContext fireChannelRead(final Object msg) AbstractChannelHandlerContext findContextInbound() void invokeChannelRead(final AbstractChannelHandlerContext next, Object msg) void invokeChannelRead(Object msg) boolean invokeHandler() } DefaultAttributeMap<|--AbstractChannelHandlerContext ChannelHandlerContext<|--AbstractChannelHandlerContext ResourceLeakHint<|--AbstractChannelHandlerContext DefaultChannelPipeline <|- AbstractChannelHandlerContext HeadContext <|- DefaultChannelPipeline class SimpleChannelInboundHandler { public void channelRead(ChannelHandlerContext ctx, Object msg) public void channelActive(ChannelHandlerContext ctx) } ChannelInboundHandlerAdapter<|--SimpleChannelInboundHandler class ServerBootstrap class AbstractBootstrap interface Cloneable Cloneable<|--AbstractBootstrap AbstractBootstrap<|--ServerBootstrap @enduml 时序图 @startuml SingleThreadEventExecutor -> NioEventLoop: run() NioEventLoop -> NioByteUnsafe: read() AbstractChannelHandlerContext -> AbstractChannelHandlerContext: ChannelHandlerContext fireChannelRead(final Object msg) AbstractChannelHandlerContext -> AbstractChannelHandlerContext: AbstractChannelHandlerContext findContextInbound(int mask) AbstractChannelHandlerContext -> AbstractChannelHandlerContext: invokeChannelRead(final AbstractChannelHandlerContext next, Object msg) AbstractChannelHandlerContext -> ChannelHandler: invokeChannelRead(Object msg) ChannelHandler --> Handler0: channelRead @enduml https://netty.io/4.1/api/io/netty/channel/ChannelPipeline.html ...

raspberry pi eth0 x60s wlan0 squid raspberry pi eth0:192.168.0.59, mask 255.255.255.0 -> x60s eth0:192.168.0.1, mask 255.255.255.0, gateway:192.168.1.1, dns:192.168.1.1 -> x60s wlan0:192.168.1.119 mask:255.255.255.0 gateway:192.168.1.1 dns:192.168.1.1

wifi Wi-Fi是一种允许电子设备连接到一个无线局域网 (WLAN）的技术，通常使用2.4G UHF或5G SHF ISM 射频频段。 802.11a 5 GHz 1999 年发布。 各种调制类型的数据传输率：6、9、12、18、24、36、48 和 54 Mbps。 带 52 个子载波频道的正交频分复用 (OFDM）技术。 不需要许可证的国家信息基础设施 (UNII）频道内的 12 个 5 GHz 互不重叠频带。 802.11b 2.4 GHz 传送速度为11Mbit/s IEEE802.11b的后继标准是IEEE802.11g； 在2.4-GHz-ISM频段共有14个频宽为22MHz的频道可供使用。 1999 年发布。 各种调制类型的数据传输率：1、2、5.5 和 11 Mbps 高速直接序列展频 (HR-DSSS）。 工业、科技和医疗 (ISM）领域内的三个 2.4 GHz 互不重叠频带。 802.11g 2.4GHz OFDM 原始传送速度为54Mbit/s，净传输速度约为24.7Mbit/s (跟802.11a相同）。 2003 年发布。 各种调制类型的数据传输率：6、9、12、18、24、36、48 和 54 Mbps；可以使用 DSSS 和 CCK 转换为 1、2、5.5 和 11 Mbps。 带 52 个子载波频道的正交频分复用 (OFDM）技术；使用 DSSS 和 CCK 向下兼容 802.11b。 工业、科技和医疗 (ISM）领域内的三个 2.4 GHz 互不重叠频带。 ...

trickle userspace bandwidth shaper 限速 200k trickle -s -u 200 -d 200 git pull 参数 -s, standalone mode 不依赖 trickled -u, 上传速率 KB/s -d, 下载速率 KB/s https://github.com/mariusae/trickle https://wiki.archlinux.org/title/trickle