如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 始终是低字节。
因此，校验和是可变的，具有不同字节序的相同数据（地址和计数）。
I think you're right. The code in the RFC adds the last byte in as low-order, regardless of whether it is on a litte-endian or big-endian machine.
In these examples of code on the web we see they have taken special care with the last byte:
https://github.com/sjaeckel/wireshark/blob/master/epan/in_cksum.c
and in
http://www.opensource.apple.com/source/tcpdump/tcpdump-23/tcpdump/print-ip.c
it does this:
if (nleft == 1)
sum += htons(*(u_char *)w<<8);
Which means that this text in the RFC is incorrect:
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.
以下代替原始奇字节处理的代码是可移植的（即可以在大端和小端机器上工作），并且不依赖于外部函数：
if (count > 0)
{
char buf2[2] = {*addr, 0};
sum += *(unsigned short *)buf2;
}
（假设 addr 是 char * 或 const char *）。