linux内核技术内幕_《深入理解LINUX网络技术内幕》学习笔记之Something Irony

前言：

上次整理笔记还是八月份，一晃一个月，国庆都到了。因为《性能之巅》最后一个部分网络实在是看不懂，所以决定深入学习一下网络的知识。于是决定开始啃《深入理解LINUX网络技术内幕》

无奈这本书为了做到通俗易懂，每一个概念都用一堆细节铺垫介绍。这样读下来，虽然每一章都有新的思路和收获，但是回想各种铺垫和细节，只觉得无聊，不知道该整理什么。

全书总共七个部分，目前刚读完第三部分。在茫茫多的细节里，总算挑出来了一个有点意思的，记录一下加深印象。如果将来有机会推荐给别人这本书，也算是有个能讲的小故事。

正文：

在本书 288 页 13.5 小节，有这么一段描述：

为了节省空间，IEEE 决定使用大于 1536 的值以表示 Ethernet 协议。有些早已存在加上标识符后依然低于 1536 的协议，也已更新为满足这项准则。
然而，802.2 和 802.3 协议使用这个字段存储帧的长度（注5）。介于 1501 和 1536 之间的值，再此字段中是违法的。

描述中的（注5）写到：这种安排的原因说来话长。好奇的话，我建议你阅读《Interconnections,Second Edition:Bridges, Routers, Switches》以及《 InternetWorking Protocols》作者解释时充满了讽刺意味（ where the author explains it with considerable irony.）。

读书读累了，不如干点有意思的事情，找一下这两本书，看下作者到底怎么个充满讽刺意味的。

于是找到了Interconnections_-_Bridges,_routers,_switches._2nd_ed.pdf , 并且找到了相关的2.7 小节：被复用的字段(Multiplexing Field)

大体浏览了一遍，发现大体浏览是看不懂的，所以干脆把这一小节翻译一下吧:

译文：

在接收方，一个站点（station）可能会安装多个高层协议，同样的，发送方也可以使用许多不同的协议将数据包发送到广播地址。当一个包（packet）到达站点的时候，需要有一种方法决定使用哪一种协议解析。

比如，如果检测到一个包不是合法的 ip 包，那么就可以确定这个包不应该使用 ip 协议而是其他协议解析。但是大部分的协议在设计的时候，没有考虑有可能与其他协议产生歧义，所以并没有什么方法可以高效的根据包的内容判断应该使用什么协议解析。

我们在人类语言中也有同样的问题。如果你在街上问别人:"Can you please tell me how to get to the nearest subway stop?",你问的那个人可能只会说火星语，不会说英语，他听不懂你在说什么。或者更糟，火星语中类似的声音非常不礼貌，在这种情况下，这种生物，不仅不会领你去地铁站，甚至可能会用它的射线枪熔化你。

要想解决这个问题，必须有一种通用的方法，在你发出信息之前，指出你使用的语言。

尽管人类语言没有这种通用方法，但是局域网（LANs）定义了一种方法（参见 2.5 小节），局域网协议 header 中有一个字段用于标识使用的协议。

在最初的以太网设计中，有一个16位长的字段 protocol type 。该字段由 Xerox 进行全局管理，任何想要定义协议的人都会与 Xerox 协商以获得协议的编号。

在802委员会将局域网标准化时，提出了一个更灵活的方案，使用两个字段分别表示源和目的的协议（见图2.6）。这些字段被称为 service access points (SAPs).包括SSAP (source service access point) 和 DSAP (destination service access point)。该方案的灵活性体现在，发送端和接收端可以使用不同的数字表示同一种协议。

SAP字段的长度为8位。并且与LAN地址一样，其中两个位是保留的。其中一个保留位用于“global/local”，它与地址字的含义一样，表明该协议编号是否由802委员会分配。802委员会分配的协议编号能保证全球唯一。

另一个保留位也跟地址字的含义一样，用于表示“group/individual”。如果设置为group，该数据包将由系统中的多个高层协议接收。这个保留位就比较坑了。地址字段中之所以有这个保留位，是为了方便硬件对包分片，SAP不是硬件解析的，所以这不是保留这个位的原因。另外，大多数情况下，同一个局域网的所有设备都安装相同的协议，很难想到有一个包被多个上层协议解析的需求。

当然了，我们有整整 8 个位，这么多的位可以使用，为了这么稀有的需求，保留 1 个位又有何不可呢？（Hint:前面的有点讽刺，也有点辛酸。实际上，即使整个 8 位全部用上，也就只能定义256种协议，根本不够用，直到下面提到的 SNAP SAP 被发明以后，才总算解决了问题）

全部置1的SAP被保留不用，表示广播地址。除了"G/L"位以外，全部置0的SAP也被保留，表示该包是纯粹的L2包，不需要上层协议解析。（可以参照图2.7来理解）

由于只有6个位用来标识协议，802委员会不能向每个希望设计协议的组织授予号码。802委员会并没有按照先到先得的原则分配号码，而是给设计协议制定了严格的规则。只有符合规则的协议才能得到802委员会的批准。

对于那些好不容易申请到号码的协议，因为是全球唯一的，SSAP 和 DSAP 只能相等，相当于使用了两个字段的空间存储一个字段的内容。

对于那些没有全局分配SAP值的协议，系统管理员可以自由选择编号。但是配置会相当复杂，如果配置不全，接收端收到了未知的sap就不知道如何回复。

为了使SAP这个设计可用，802委员会又给出了另一个方案。当SAP的值设置为16进制aa的时候，该字段不再表示某个具体的协议，而是表示，使用头部后续扩展字段protocol type来标识上层协议。802委员会可以授予全球唯一的protocol type，这样就可以支持超过256种协议了。

最初的计划是，protocol type字段是16位，因为最开始xerox设计的时候就使用了16个位，他们觉得xerox这么做肯定是有原因的。但是后来有人注意到 802 报头包含奇数个八位（octet）。如果protocol type字段是奇数个八位，则会使整个报头成为偶数个八位，这将提高希望字段对齐16位的计算机上的性能。

同时也有人注意到，如果 protocol type 字段长于 3 个八位，就可以统一“protocol type” 和 MAC地址的授权，这样就减少了802委员会一半的工作量。为什么这么说呢？802委员会把48位的mac地址分成

组进行授权，每次授权的时候，得到的地址的前24位（3个八位）是相同的。

如果在授权地址的时候，也顺便把以这 3 个八位开头的协议编号也授权给相同的组织，这样不就省事了。如果这样的话，假设协议类型字段是4个八位，当一个组织申请MAC地址的时候，相当于同时获得了

= 256 个协议编号。

protocol type字段最终被定为5个八位，因为5是大于3的最小奇数。

使用 SNAP SAP 时，DSAP 和 SSAP 都设置为16进制的aa。

在我看来，802.2定义的所有字段，不管是 SAPS 还是 LLC 不仅浪费空间，还让协议解析更加复杂难懂，明明只需要 protocol type 这一个字段就够了。

MAC地址和protocol type字段结构如图 2.8 所示。

结论：

现在感受到作者的讽刺意味了，但是，802委员会为什么不使用xerox最初的设计呢？

因为实在是不知道该整理什么，又希望能把笔记坚持下去。所以才翻译这一小段，虽然确实没什么意思，至少提高了一点英文技能。

话说这本书300多页里边，竟找不到一个有意思的点，这件事情也实在是有点Irony。。。

希望这本书读完的时候，能有点质变的东西吧～～

最后，让我们保持独立思考，不卑不亢。长成自己想要的样子！ (引用自 我非常喜欢的B站up主 ”独立菌儿“->猛戳链接<-的口头禅）