第十六章 网络通信协议探讨要点.docx

第十六章 网络通信协议探讨要点.docx

《第十六章 网络通信协议探讨要点.docx》由会员分享，可在线阅读，更多相关《第十六章 网络通信协议探讨要点.docx（15页珍藏版）》请在冰豆网上搜索。

第十六章网络通信协议探讨要点

第十六章网络通信协议探讨

LINUX的源代码中属于网络的就有近38万行；我必须先花时间彻底解决网络编程问题，再论其它；所以、其它题目暂停更新；或许这样、APO操作系统的改动就会少一些。

Internet网络是一个公用网络，要知道林子大了、什么鸟都有；我们必须将安全放在第一。

说实在、我仔细看了ipv6协议，给我的印象就是希望越大、失望就越大。

总之，我认为ipv6是一个失败协议；本文就是我的观点和设想，当然以后还会修改、不可能一步到位。

一个多星期的边学、边写、边思考；给我的感觉就是那么多的协议，都是一个头痛医头、脚痛医脚的方案。

复杂、啰嗦、多余充斥我的脑海，如果我一个业余者都能看出那么多毛病，怎么都能成为标准？

我是想不通。

本文可能批判的地方较多，我也不好意思；但那毕竟是我的心声，是我内心的呐喊、与嘶叫，请理解。

对于网络设备、或称为节点，我们可以归纳为二大类：

网络终端设备-主机，和网络中的设备-路由器（路由器、交换机等）。

那么，协议应该有3种：

主机之间，主机和路由器，路由器之间。

好的协议应该是能保证用户通信安全，主机和路由器驱动程序简洁；和路由器高效、高速处理数据包的路径选择、和保证传输质量等。

网络安全的首要问题就是杜绝地址假冒、杜绝用户数据包的被窃取。

那么，我们必须对链路地址作认证、和注册。

一、网络安全

1、防止同一条链路下的以太网地址假冒

通常，表示主机的地址就是6字节的以太网地址（前3字节是厂家编码、后3字节是网卡序号）；那么IPV6的64位接口地址就显得多余、和浪费网络带宽了。

连接一台用户主机，基本上都是二层交换机的一个端口，跟别的主机是隔离的；不再是以前挂在同一条线路上。

当一台主机A想使用在同一条链路上的另一台主机B的以太网地址时，交换机发出警告、并给A一个错误报文。

不同链路上的以太网地址是可以相同，但在同一条链路上的就不允许相同。

6字节的地址分配可以到千万亿个以上，而通常是网卡决定的，不可能相同；相同的情形只会是用户故意修改造成。

所以、假冒其它用户的以太网地址只能是影响自己。

对于移动用户，可以随机生成以太网地址、或交换机分配。

每一台主机打开时，都会向其所属交换机发宣告报文“hello”、包含有主机的以太网地址和主机名字，交换机返回其自身的IP地址、即链路地址、和交换机的以太网地址；并查询端口表，看是否需要刷新。

连接几十个用户主机的交换机不一定就代表一个子网地址，一台用户主机也不一定就不是代表一个子网。

在一个子网下，理论上可以有千万亿个以上的主机。

不管如何，一个子网必定有一台做主管的带路由功能的交换机。

我们称一个子网下的所有主机都在同一个网段上。

同一个网段上的主机都是互为邻居，一个用户主机想查看其邻居；可以向其子网主管交换机提交申请报文；主管交换机将其管辖下、并在线的邻居信息返回报文；并不一定要通过广播来实行，也不需要什么路由器前缀公告。

用户主机的以太网地址、和其所属的主管交换机的64位链路地址就构成了一个IP地址。

用户主机想和另一个用户主机通信，那必须知道对方的IP地址才行。

因为IP地址就包含了以太网地址，所以、我们不需要ARP协议。

这样、我们的IP地址，似乎有很多个；这又能飞天？

即使你的MAC地址在不断的做不冲突的变换，你的链路地址是变不了的，最后、还是能追查到。

如果用户主机作为网站服务，是不能随意更改MAC地址的；那需DNS服务数据库也相应更改才行。

有时候，我们只有用户域名的网站字符串地址；那需要向DNS域名服务器查询。

DNS的IP地址通常是基本固定的、在安装网络时，就设置在你的主管交换机上了、或你设置在主机上。

在你hello时，主管交换机的返回报文中就有DNS的IP地址。

表面上，我们是用网站字符串地址访问网站，实际上、主机要先用存储在主机上的DNS的IP发报文给DNS查询到对应的网站IP之后、才能真正的访问相应网站。

经常访问的网站IP地址，我们可以保存到一个临时文件；这样、以后就可先查临时文件中的数据，如果有相关网站IP，就不需要查询DNS了。

2、防止链路地址假冒

64位的链路地址包含：

16位TLA世界级电信公共骨干网接入点，32位NLA下级聚合体、通常是大型ISP网络服务商，16位SLA节点级聚合体、子网地址。

一些机构或小型ISP可以申请多个连续的子网地址、或1个NLA（包含64K个子网地址）来构造局域网络。

所以、链路地址是通过申请、登记、注册才获得的，每个子网所在的地域位置、创建时间、负责人等信息都备案在上级NLA、或TLA数据库中。

可能有人会说，我只要在发送数据包时，将源IP中的链路地址改变为自己设置的链路地址，那就可以起到假冒作用了。

这是不行的、你的主管交换机都会在你的源IP中的链路地址打上正确的链路地址印记，并在链路地址最高字符写入你的连接交换机的端口号标记；以便上级更好的做本地交换。

如果你是出到大网的，自然有更上级的交换机在出去时、打上正确的链路地址印记。

即使你能搞掂SLA，还有上级NLA的监控维护服务器啊；你的SLA总有个连接到NAL的端口吧，一旦进入该端口时的数据包中的源链路地址范围不对，就给记录在案了。

用户级交换机通常是链路层、用以太网地址做交换；但主管交换机再往上的、通常是3层交换机了，即是用链路地址做标记交换。

就像一个金字塔，汇聚到最顶端的骨干网时，每个端口的数据包数目巨大，但通常都是许多数据包（可能数百万包）整合到一包、标记交换（如ATM等标记交换机）到另一端口。

这时，MUT不可能是1518B了；或许是4GE=128GB。

对于网络，我是外行、新手；主要靠想象。

所以，本文仅供参考；我会使用APO来设计、规划、模拟路由器，2层、3层、4层交换机，标记交换机，虚拟网络VLAN组服务器，网络编程等等。

安全、简洁是首要；可惜太多的资料要看了，速度会放慢。

学院派啊，学院派；你们的脑袋也太复杂了，整出一大堆协议，有必要吗？

那个IPV6啊，就只有源主机可以分段是改进得好外；没有发现什么比较先进的地方。

链路地址汇聚、IP4就这样了；接口地址跟以太网地址重复、浪费啊。

你说、简化了IPV4的协议字段数，但那个扩展头要复杂得多啊！

一个就行了，一个MTU大小的包就含多个扩展头、那代码量太大了。

那个指定路径路由器、或中间点路由器扩展头，随着网络设备的发展、除了浪费路由器资源，将是没屁用的功能；还不踢掉，失望。

那个版本位段IPV4、IPV6有屁用，各协议组合时、地址有重复啊；浪费。

ICMP协议应该是想办法将路由器、网关、主机之间的协议简化、合一啊，却越搞越复杂。

只有你们晚上做梦时，可以自我欣赏吧；我是学得一肚子气。

安全性，完全没考虑好、要从源头解决啊，搞个复杂的IPSEC有屁用、花拳绣腿。

认证、加密无需搞进协议里的，多余。

最为失望的是，你们都认识到以字节、或字分段；在64位CPU对数据包组装时、会搞死人的！

搞成64位分段、你们除了吹嘘64位操作比8位的字节要快8倍外，有没有用你们的复杂脑袋想想啊？

能否看长远些？

能否不鼠目寸光！

人类在发展啊，连我一个业余爱好者都在设计用256位的高速总线了，2GE/S=64GB/S；将来、就是一次操作32字节、甚至64字节，难道、你的IPV6还能更改？

设备也要丢掉？

只要把分段改为64字节为单位，那都能兼容字节、32位、64位、128位、256位、512位；反之、不成立啊。

学院派啊，我无语了。

3、数据包安全

如果要考虑防止ISP服务商、或一些监控软件对数据包的窃听；那么，只能对数据包内的数据进行加密了。

可以使用公开的常用加密算法，也可以定义自己的加密算法、只要通信双方认可就行。

二、网络通信协议：

网络通信除了标准协议外，也应该能支持用户自定义的协议。

路由器主要的任务就是转发数据包，还需实现网络控制消息协议（internetcontrolmessageprotocol）ICMP。

不过、ICMP是IP层上的协议，如果不是使用IP包的、还需另外定义控制消息协议；那需要路由器认识才行。

TYPE.15-11共5位协议类型，TYPE.15=1是非IP协议：

0X8137IPX协议、0X8035为RARP、Ethernet802.2.LLC、Ethernet802.2.LLC.SNAP、用户自定义协议、等等。

TYPE.15=0是IP协议：

1、互联网控制报文协议ICMPAPO，

2、IPA/TCP,IPA为APO的IP协议，

3、IPA/UDP，

4、IPV4，

5、IPAICMP，ICMP的差错报文、应答报文协议，

6、IPV6，

7-15其它、或用户自定义。

路由器、交换机通常只是处理第一项ICMPAPO，其它项是转发、除非目标地址是自己。

如果数据报有错误时，会做第5项APOICMP的差错报文；如果是路由器组播地址、或目标是路由器地址，也会做第5项APOICMP的应答报文。

对于用户组播，我希望是全球型的、而非单纯是局域网VLAN。

网上的关于组播资料（IPV4、或IPV6），或许我笨了些、真的看了半天、没有明白过来。

我想：

先不说112位的组播地址，就拿32位组播地址ID来说；假设一个小组可以有64K个用户，那32位就可有64K个小组。

我们是不可能知道那一个用户主机、在什么时候加入了那n个小组的。

要想实现对组播ID的转发，那用户主机的主管交换机就要建立最少一张表吧；假设主管交换机有1K个用户、那表大小是1K个记录项；每个记录项是用户MAC地址、端口号、组播ID1-IDn、上行端口号。

嗯、全世界的小组数不止64K个，好、我们又换种方式：

24位的组播标识地址、40位组地址ID、48位小组成员MAC地址。

就算、每个小组成员最多能加入64K个小组，那组播ID1-IDn最少要安排64K个列字段啊、一个列字段40位，不算别的，我们就算32位、64K个列字段；那表大小也要64KW*1K=64MW=256MB。

路由器、交换机就是查表、识辨就要耗尽资源了，还能做转发？

主管交换机的上一级需要的表更大，能实现吗？

还是我没考虑到？

还是学院派的虚妄？

我的设想是：

用户组播功能从路由器、交换机中剔除，用户组播应该是应用层的事情，而路由器、交换机只是实现二层、三层、四层的数据包交换；主要用于转发。

路由器、交换机的组播只是有限的组播，局限于周边；或局部节点、或本地节点、或子网节点。

而用户组播功能是由某个服务器、或用户主机来实现；这种用户组播功能是相当灵活、强大的；表大小不受限、可以构建许多个组；易于实现权限，组成员管理；轻松构建全球性的VLAN。

但组播服务器的带宽要高些，这需要在NLA、或TLA上建立组播服务器才合理。

1）、APO的IP数据包帧结构：

头部占2E=64B，包含MAC、IPA、TCP/UDP/ICMPA字段。

BU64BEMAC{//最小长度2E=18+46=64B，最大长度=1526B

//IP数据包分段单位是2E一片，所以分段数据含头部最多23片、46E=1472B。

//如果以一片为1E，则含头部最大47E=1504B，分段数据最大45E=1440B。

BU1EMACIP{//以太网和IP头部、1E（1行）=32B；路由器处理入口。

BU48MDA;//以太网目标地址

BU48MSA;//以太网源地址

BU16TYPE;//类型和长度。

//TYPE.15IPX;1、0X8137IPX等非IP协议；0、IP协议。

//TYPE.14-11TYPEP;协议类型标识。

//TYPE.10-0LEN;数据包字节长度。

BU8TTL;//跳数限制。

BU8TOS;//8位传输优先级、流量类型。

BU64SLADD;//源链路地址。

SLADD+MSA=源IP地址

BU64DLADD;//目标链路地址。

DLADD+MDA=目标IP地址

}

union{//APO的TCP协议头、1E；支持4GB的文件流传输。

BU32length;//文件流总字节长度，不含头部64字节（2E）。

BU32sheetoff;//低26位片偏移、分段单位1片=64字节。

//sheetoff.31MF;更多分段标志（morefragment），0、最后一个分段

//sheetoff.30-26tcplen;5位选项长度。

BU32flowlabel;//32位流标签

BU20BTCP{//标准TCP协议头。

BU16SPORT;//源端口

BU16DPORT;//目的端口

BU32seqnum;//序号。

BU32connum;//确认号。

BU16trflag;//控制标志。

BU16windows;//窗口

BU16cheksum;//校验和。

BU16urgentp;//紧急指针。

}

}

//

TCP协议太复杂了，也要结合ICMP做大的改进。

希望能改革MTU，为2KE=64KB；这时，我们的分段单位就可以设为1片=256字节=8E；甚至1片=1个扇区=16E。

//

union{//APO的UDP协议头、1E，带弱连接；支持4GB的文件流传输。

BU32length;//文件流总字节长度，不含头部64字节（2E）。

BU32sheetoff;//低26位片偏移、分段单位1片=64字节。

//sheetoff.31MF;更多分段标志（morefragment），0、最后一个分段

//sheetoff.30RRQ;以数据包头后的文件名、映射到一个流标签，读请求。

//sheetoff.29WRQ;以数据包头后的文件名、映射到一个流标签，写请求。

//sheetoff.28RRQ;以流标签、分段偏移、段片数，重传一个段请求。

//sheetoff.27DATA;正常的DATA传输。

//sheetoff.26ACK;确认应答。

BU32flowlabel;//32位流标签

BU16rwmode;//读、写请求的传输模式。

BU16eroorm;//差错码，非0则有错。

BU8Busedata;//用户自定义。

BU8BUDP{//标准UDP协议头。

BU16SPORT;//源端口

BU16DPORT;//目的端口

BU16segnum;//文件流的段数；不分段时就是数据报长度。

BU16cheksum;//校验和。

}

}

union{//APO的组播UDP协议头、1E，支持弱连接，由组播服务器处理。

//每个组播UDP包、需要相应的组播服务器转发到其它成员。

数据报还是同一份、

//但目标IP地址成为多个；可以任播、组播；组成员必须保存有组服务器IP。

BU32length;//文件流总字节长度，不含头部64字节（2E）。

BU32sheetoff;//低26位片偏移、分段单位1片=64字节。

//sheetoff.31MF;更多分段标志（morefragment），0、最后一个分段

//sheetoff.30RRQ;以数据包头后的文件名、映射到一个流标签，读请求。

//sheetoff.29WRQ;以数据包头后的文件名、映射到一个流标签，写请求。

//sheetoff.28RRQ;以流标签、分段偏移、段片数，重传一个段请求。

//sheetoff.27DATA;正常的DATA传输标志。

//sheetoff.26ACK;确认应答。

BU32flowlabel;//32位流标签

BU16rwmode;//读、写请求的传输模式。

BU16eroorm;//差错码，非0则有错。

BU8Busedata;//用户自定义的IGMP协议，查询、注册、注销等。

//比如：

1字节命令（任播、组播、查询、注销、注册、无连接等）、1字节代码号

//（优先级、标志、状态等），4字节组标识，2字节设备类型等。

BU8BUDP{//标准UDP协议头。

BU16SPORT;//源端口

BU16DPORT;//目的端口

BU16segnum;//文件流的段数；不分段时就是数据报长度。

BU16cheksum;//校验和。

}

}

}

APO的以太网包格式：

14字节、4个字段；IP包格式：

18字节、4个字段；数据包格式：

最大1518字节。

APO的TCP/UDP/ICMP：

32字节、12字段。

2）、APO的网际信报控制协议（ICMP）

有2类ICMP报文，应答、差错报文IPAICMP总是起始于数据包的2E包头后面、而信令报文则被封装到类似UDP格式的ICMPAPO协议1E。

从设备上分类则有：

1、主机、路由器的宣告、请求报文。

2、路由器、或主机到主机的应答、差错报文。

3、路由器间的协议报文（内部网关协议IGP（包括RIP、IGRP、OSPF、EIGRP、IS-IS等），外部网关协议BGP、也称为EGP）。

没用、取消！

为何要分为2类ICMP报文？

因为信令报文ICMPAPO是路由器必须检查、处理的，而应答、差错报文IPAICMP对于路由器来说、通常只是转发；而最终是由目的节点来处理。

对于应答、差错报文，我们往往要保留TCP/UDP/ICMPAPO的头部、以便节点知道缘由、从而方便处理。

交换机都有路由功能，二层交换机的路由实现较为简单一些；三层交换机就能实现大部分的路由功能。

二层交换机是以MAC地址作交换、而三层交换机是以链路地址作交换。

交换机必须实现的基本功能有：

1、包头长度检查（二层交换机不检查）。

2、检查校验和。

3、本节点的地址、设备编号、时间戳提交。

4、跳数处理。

5、出错时、发出差错ICMP报文。

6、转发（二层是据MAC地址，三层是据链路地址）。

7、对本节点的请求、应答处理。

8、在一个子网内MTU最少要做到64KB。

到此、在APO网络中，将节点、路由器等广播地址全部去掉；只有用户层的组播功能，路由器、交换机不再处理广播数据报。

要知道交换机、路由器是交换、转发数据报，不是广播机！

不要连姓什么都忘了。

三、ICMPAPO协议

每一个子网必须有一台主管交换机，它保存有子网下的所有主机MAC、端口表。

一个子网不要超过2K台主机，全球子网地址可达到16E+18；那么庞大的子网地址数量，没必要一个子网带太多的主机。

用户开机时，会有一个主机宣告ICMPAPO报文发送；该报文只是到达主管交换机路径上的相关交换机会处理，并更新它们的MAC表；主管交换机还要做MAC地址是否重复的处理，重复则回发差错ICMP报文。

泛洪广播会过多的浪费带宽、应彻底清除。

邻居请求ICMPAPO报文，也只是主管交换机才会应答；而不是子网下的所有交换机都应答；避免重复的邻居信息，但需要用户主机到主管交换机间有2K*32B=64KB的MTU。

交换机、路由器也同样有一个宣告开机报文，和邻居信息请求报文；我们不能将它们封装在一起吗？

探查ICMP报文是探查从源到目的的路径上所有路由器的IP地址、时间戳、MTU、跳数等信息。

我们的目标是简化路由器、交换机代码量，而非让他们执行许多垃圾协议。

那个全网广播命令、只有白痴才会去实行。

我们应该彻底清除掉所有广播地址，清扫掉这些扰乱市场的因素；还网络一个清净，网络只有点对点通信；用户组播实质还是用点对点通信在用户层完成的。

BU64BEMAC{//ICMPAPO是节点必须检查、执行的协议。

BU1EMACIP;//MAC、IP头32字节。

union{//APO的ICMPAPO协议头、1E，无连接。

BU8imcptype;//报文类型：

宣告、邻居请求、探查。

BU8imcpcode;//代码号。

BU16devtype;//源设备类型（主机，2-3-4层交换机等）、网络中的级数。

BU32PTID;//源设备的进程号（或端口号）、线程号（或标识）。

BU32times;//报文发送时的时间戳us。

BU16MTU;//源设备的MTU。

BU16cheksum;//校验和。

BU16Bicmpdata;//用户自定义的数据。

}

}

1、链路地址汇聚三层交换机

图1，假设我是一个ISP网络服务商，获得了一个NLA下级聚合体地址，具有64K个的子网地址；三层交换机的上级端口2个、下级端口48个。

我们先不考虑备用交换机，和非线性分割；那么A层（顶端、只需一台）交换机有47个下级端口、每个端口线性分割子网地址后，为包含1394个子网地址的子网集束；第48端口为余下的18个子网地址用于服务器。

那么，B层的47个交换机的每个交换机的29个下级端口连接下级的C层交换机（每个C层端口包含48个子网地址集束），有2个端口是单子网地址、直接连接子网主管交换机；余下的17个端口用于B层交换机互连，以减少跳数。

到达B层某个交换机j的数据包，如果目的地是B层的另一个交换机i、如有互联、那么一跳就行了，否则需经A层交换机做2跳。

C层交换机的48个下级端口（每端口一个子网地址）就连接到子网主管交换机。

用户主机要发数据包到ISP网络外，那么、需要经0-3级到达其子网主管交换机（用户主机0级、hub是1级、用户接入交换机是2级、主管交换机是3级）、再2-3级（C、B、A，或B、A）才能到达外网。

这样一来，三层交换机将是非常简洁，路由表最多48项；每一项记录是：

端口号、子网集束（16位的子网开始地址、结束地址）。

到达交换机的数据包，先查NLA地址、不同则往上级端口转发（如果从上级端口来的、则直接抛弃），相同、则用子网地址查路由表、没有符合项则往上级端口转发（如果从上级端口来的、则直接抛弃）；有符合项、则按照相应端口号往下级转发。

骨干交换机也是类似的，不过是用更大的子网集束NLA地址来判断吧了。

整个网络基本上就是2-4层交换机，网关内、外等协议全部简化成2对ICMP报文类型：

宣告、应答，和邻居请求、应答。

那些垃圾的、人为复杂的协议通通清掉。

2、二层交换机

就是用MAC地址来转发数据包，每个主管交换机只有一个子网地址，最多管理2K个用户主机。

用户主机可能通过HUB端口才连接到上一级2层用户接入交换机，所以交换机的每个下级端口会有一张端口MAC表，每项是：

设备类型级数、活动标志、MAC地址、活动定时器、主机名字（最多10字符）等。

对于主管交换机最多2K项；24口交换机也就24项；48口交换机也就48项。

对于一个子网，网内的通信需要更大的数据报（64KB）；64KB=2KE，包头只占数据报的0.1%。

用户主机发一个请求邻居报文，其主管交换机就返回一个大的数据包、包含了子网上所有活动邻居的信息；简单多了。

对于路由交换机的情形略有不同。

在三层交换机时、它的宣告，其上级路由交换机会返回一个链路地址前缀、和子网束报文；接着、它需要扫描下级端口，并为下级端口分配子网地址束；这也是属于一个强权型请求邻居报文；通常A层、B层是手工分配（几百万用户、只需手工分配50台交换机），C层是每个下级端口一个子网地址的自动分配。

在二层交换机时、也类似，不过换成是MAC地址。

对于交换机、宣告是上级端口的分配，请求是处理下级端口分配。

对于用户主机、宣告是其所在用户交换机端口的刷新设置，请求只有邻居请求。

3、用户主机

用户主机可发出宣告（类型0）、邻居请求（类型1）、探查（类型2）、这3