网络标头如何在位级别表示

Question

位表示的标头结构如何让我们以 icmp 标头为例，因为该 icmp 具有最少的字段。

| TYPE | CODE | CHECKSUM |
       CONTENT


Just for example then let's assign some value to the field :

Type Size = 1 byte
Code Size = 1 byte
Checksum = 2 byte
Content = 4 byte

位级别的格式头会是这样吗

00010100 00001010 1111000000001111 00000000000000000000000000000000

如您所见，我根据标头格式序列将标头格式化为位。其中类型是第一个字段，代码是第二个字段，校验和是第三个字段，数据是第四个字段

00010100 = 20 where is this the type field
00001010 = 10 where is this the code field
1111000000001111 = where is this a checksum
00000000000000000000000000000000 = and this was equal to the payload or the content.

但是在现实世界的示例中，格式化为位的网络标头是否会遵循我在示例中所示的标准标头格式序列？

我还必须注意系统使用的字节顺序才能正确读取标头吗

Answer 1

我担心你的问题在堆栈溢出中不会很好地工作，但这是我可以回答的，可能会有所帮助

1. “现实世界”中是否遵守这些标准？

一般来说，是的，互联网实际遵循的标准（IPv4、IPv6、TCP/IP 系列等）。这就是为什么大多数时候一切都是互操作的。 （我并不是想听起来尖酸刻薄，以前有一个时代不遵循标准，有时甚至是编写标准的供应商也不遵循。您可能需要找到具有 30 多年网络经验的人，但他们不会如果您在同一句话中说“数据包嗅探器”和“IPX | AppleTalk | SMB | LMHost”，我会喜欢它。

所以，是的，如果您阅读 ICMP 的低级别数据包跟踪，它应该向您显示它说：“blah blah”，并且如果您将显示更改为字节级别（我不知道是否每个分析器都会转换为按位显示），然后您会看到内容符合规范。并且字节将采用大端字节序。

2. 字节排序：

您的 API 应该阐明用法，但相关的现代 RFC 更喜欢大端字节序。除非您正在编写在最低级别执行此操作的内容，否则大多数 API 都会处理此问题。

很久以前，一些架构（Intel 32 位？）内部是小端字节序，并且具有稀疏编码的网络/操作系统堆栈，他们希望程序员将小端字节序转换为大端字节序。那是一个非常重要和/或昂贵的时代，因此一些早期的应用程序是在没有考虑到这一点的情况下编写的。结果是大量 PC 进行了互操作，而其他一切都对正在发生的事情感到困惑。