TCP/UDP标头中的端口端号错误

我们知道有两种类型——大端（BE）和小端（LE）。因此，我们通常在应用层使用LE，即所谓的“主机字节顺序”。
通常在应用中，我们通过以下方式将传输协议的主机字节顺序（LE）端口转换为网络字节顺序（BE）：

struct sockaddr_in sockaddr = {0};
// ...
sockaddr.sin_port = htons(60592);

实际上，所有网络协议都使用BE字节表示

在本例中，主机字节顺序中的

60592

将是

ECB0

，如我的计算器所示。所以我认为它应该在传输头内部交换到

B0EC

，但它没有。我错在哪里

---

60592是十六进制的0xECB0。作为一个16位无符号值，它被分成两个8位字节，最低有效字节的值为0xB0，最高有效字节的值为0xEC。使用小尾端字节顺序的机器将首先在内存中存储最低有效字节的值，因此它将存储为序列0xB0、0xEC。如果使用

memcpy（）

将这两个字节复制到网络数据包中，则这些字节将以相同的顺序0xB0、0xEC出现在数据包中。但是，网络协议以大端字节顺序表示16位值，因此字节序列0xB0、0xEC表示16位无符号值0xB0EC或45292

---

在使用小尾端字节顺序的机器上，

htons（60592）

将产生值45292或0xB0EC。它将以字节序列0xEC，0xB0的形式存储在内存中。当使用

memcpy（）

复制到网络数据包中时，数据包中的字节将以相同的顺序0xEC、0xB0出现。在使用big-endian字节顺序的网络协议中，字节序列0xEC，0xB0表示需要的16位无符号值0xECB0或60592。

我相信您是反向的。存储在LE中的数字60592实际上是0xB0EC。“我们知道有两种类型的endian——big endian（BE）和little endian（LE）”。我多么希望那是真的。幸运的是，除非你想支持已有40多年历史的硬件，否则你可以假装它是。