本文主题如上所示：相信大家都有 Windows 操作系统充当 “软件路由” 为其它局域网-以太网设备提供网络吞吐性能不足的烦恼。
那么本文提出的技术观点可能会让这种问题得到有效的缓解，局域网其它设备通过 Windows 主机所指示提供的网关。
标准技术组成至少需要以下几个部分：
1、ARP
2、LLDP链路层发现协议
3、DHCP
4、IP协议
????????4.1、TOS/DSCP QOS服务质量控制
????????4.2、IP分片、组帧
????????4.3、TTL跃点及生命周期
????????4.4、ICMP/TCP/UDP
????????4.5、IGMP、GRE
5、VLAN: 802.1q/802.1p
????????5.1、COS QOS服务质量控制【可不要】，主用来做标签VNP、IPTV机顶盒之类的东西
6、分级FIFO报文传送队列
似乎看上去似乎很多令人感到头疼与麻烦，但是不要忘了家用路由网关是不要考虑那么多东西的，该砍掉的都砍掉只要保证至少以下几个部分就可以。
那么就只剩下以下几个部分：
ARP + IP分片/组帧 + ICMP/TCP/UDP协议的支持就可以，DHCP协议支持？人们在想什么呢？局域网里面存在多个DHCP服务器会导致混乱的，除非在新的二级子网下面，但都说是局域网里面工作，自然不允许在提供额外DHCP协议服务器。
想一想：
用户通过WIFI连接上局域网，用户设备发送广播消息：DHCP_discover，局域网多个DHCP都向用户设备发送 DHCP_offer，那么会导致什么结果？用户设备此时应该向那个DHCP服务器发送 DHCP_request？如果由人们实现的局域网网关与用户设备完成DHCP续约/分配，然而用户并不希望通过该网关上网会不会变得很麻烦，DHCP实现与提供并无技术难点，但它衍生的问题却不是那么容易解决的。
OK：上面废话扯得太多没有太大必要，使用 “WinPcap/Npcap” 来实现局域网网关，那么人们就必须使用桥接技术，并且给网关搞一个局域网内唯一的MAC以太网地址
原因是因为：不使用桥接的方式，运行网关程序的 Windows 系统主机会认为这些报文发送给自己的，操作系统会放入协议栈及防火墙来处理，TCP/RST或丢去帧报文，ICMP/UDP等等都丢弃报文，因为没有任何匹配这些资源的内核资源条目。
所以假设，运行网关程序的 Windows 网卡局域网配置为：
IP：192.168.100.100
GW：192.168.100.1
MASK：255.255.255.0
那么，人们可以配置自定义网关程序的，桥接网卡(虚拟的,不存在于物理层面上)配置为：
IP：192.168.100.200
GW：192.168.100.1
MASK：255.255.255.0
局域网其它设备配置默认网关IP为：192.168.100.200，而不是 192.168.100.1。
为我们自定义的IP网关分配一个有效MAC地址，好的办法是找一个废弃的路由器把它的MAC提取出来充当网关的MAC地址，因为路由器只要是合法正规厂商MAC地址都是备案确保全球唯一的，这样子只要不遇到智障网络电子设备乱搞MAC地址就不会出现MAC地址冲突。
由于我们不需要提供为局域网在提供DHCP服务器，而用户只能通过在设备上面 “配置静态IP，指定网关为我们的网关程序的IP地址（桥接）”，那么网关就不需要去做ARP广播向局域网网内所有设备通报MAC/IP成对。
因为按照标准每个网络实现都会确保在局域网内访问局域网其它设备会先检索ARP_ENTRY表，找不到成对关系时会发送ARP广播，询问某某局域网IP的MAC地址是什么？所以人们抓包时会发现一些?Tell？ARP请求，当我们的网关程序ARP应答了局域网其它设备IP的ARP请求，那么局域网其它设备就可以通过IP+MAC地址向我们的网关发送IP协议报文。
那么一个有意思的话题是：
“为什么局域网其它设备可以通过MAC+IP访问到网关呢？”答案是局域网内通信，路由器实际上是充当“交换机”的作用，而一个路由器/交换机网口（电口）可以绑定多个IP+MAC成对映射关系，只要没有到达条目老化时间过期就是有效的，如果是网口+IP+MAC一对一强制关系，那么以太网桥接技术就不可能实现的。
剩下那部分处理IP报文后续有空再聊，今天就不摆了，其实那部分处理上面考虑为民用其实技术难度上没什么的，就是相对麻烦而已。
