rfc - RFC1071 中的 "C"代码算法在大端机器上运行良好吗？

Question

如 RFC1071 中所述, 在奇数字节的情况下计算校验和时，最后一个字节要多加一个0字节:



但是在“C”代码算法中，只添加了最后一个字节:



上面的代码确实适用于 [Z,0] 等于 Z 的小端机器，但我认为在 [Z,0] 等于 Z*256 的大端机器上存在一些问题。

所以我想知道 RFC1071 中的示例“C”代码是否仅适用于小端机器？

-------------新增---------------

RFC1071 中描述了另一个“将总和分成两组”的示例:



我们可以把这里的数据(addr[]={0x00, 0x01, 0xf2})例如:



这里，“标准”代表公式[2]中描述的情况。 ]，而“C-code”代表C代码算法情况。

正如我们所看到的，在“标准”情况下，无论字节序差异如何，最终和都是 f201，因为在“交换”之后 [Z,0] 的抽象形式没有字节序问题。但它在“C 代码”情况下很重要，因为无论是大端还是小端，f2 始终是低字节。

因此，校验和是可变的，在不同的字节序上具有相同的数据(addr&count)。

Answer 1

我想你是正确的。 RFC 中的代码将最后一个字节添加为低序，无论它是在小端机器还是大端机器上。

在网络上的这些代码示例中，我们看到他们特别注意最后一个字节:

https://github.com/sjaeckel/wireshark/blob/master/epan/in_cksum.c

并在

http://www.opensource.apple.com/source/tcpdump/tcpdump-23/tcpdump/print-ip.c

它这样做:

if (nleft == 1)
    sum += htons(*(u_char *)w<<8);

这意味着 RFC 中的这段文字是不正确的:

Therefore, the sum may be calculated in exactly the same way regardless of the byte order ("big-endian" or "little-endian") of the underlaying hardware. For example, assume a "little- endian" machine summing data that is stored in memory in network ("big-endian") order. Fetching each 16-bit word will swap bytes, resulting in the sum; however, storing the result back into memory will swap the sum back into network byte order.