对CRC校验是否多余的问题？

[wangsiyuanoo]

基于TCP发送文件，按一个包512字节的大小发送
对发送的每个包做CRC校验
发现，服务器对收到的包做CRC校验时，一些包的CRC值和客户端传过来的CRC值不相等！但有的包是相等的！
都是一个CRC算法，为什么有的对，有的不对呢？

如果去掉CRC校验，文件一样可以发送成功，数据内容也是对的！
CRC校验就显的多余了。。。

我糊涂了。。。
加CRC就是为了保证数据的完整性
可现在却出现不加反而是完整的，加了反而不对。

下面贴一下CRC校验的实现：

unsigned long g_Crc32Table[256] = 
{
	0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
		0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
		0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
		0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
		0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
		0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
		0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
		0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
		0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
		0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
		0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
		0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
		0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
		0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
		0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
		0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
		0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
		0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
		0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
		0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
		0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
		0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
		0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
		0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
		0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
		0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
		0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
		0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
		0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
		0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
		0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
		0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
		0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
		0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
		0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
		0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L,
		0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL,
		0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L,
		0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL,
		0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L,
		0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL,
		0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L,
		0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L,
		0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL,
		0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L,
		0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L,
		0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L,
		0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L,
		0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L,
		0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L,
		0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL,
		0x2d02ef8dL
};
ULONG CServerDlg::GetCRC32( char * pData, DWORD dwDataSize )
{
	if ( NULL == pData)
	{
		WriteErrorLog("[GetFileCRC32] if ( NULL == pData)");
		return -1;
	}
	char * pCrcData = pData;
	if ( NULL == pCrcData)
	{
		WriteErrorLog("[GetFileCRC32] if ( NULL == pCrcData)");
		return -1;
	}
	ULONG  crc(0xffffffff);    
	while(dwDataSize--)
		crc = (crc >> 8) ^ g_Crc32Table[(crc & 0xFF) ^ *pCrcData++];

	return crc^0xffffffff;
}

[zyq5945]

好像TCP/IP协议底层自己有校验的。
传递非字符数据，要考虑主机字节序和网络字节序，htonl,htons和ntohl,ntohs。

[buckv31]

对于TCP是不需要CRC校验的

[wangsiyuanoo]

[Quote=引用 1 楼 zyq5945 的回复:]
传递非字符数据，要考虑主机字节序和网络字节序，htonl,htons和ntohl,ntohs。
[/Quote]
这对我来说倒是新知识
可以讲的再详细一点么？
谢谢

[zyq5945]

http://www.cnblogs.com/kevinmeng/archive/2009/04/19/1439068.html
字节序和硬件平台有关，不同的平台，字节序不同。(字节序顾名思义字节的排列顺序)只有多于一个字节的数据类型，才有字节序的问题。比如short或者 int类型。char是没有这个问题的。字节序就是在硬件里面，一般是内存里面，如何存储和表示这些数据类型。如果高字节放到高地址上，就是大端模式（big endian)，如果高字节放到低地址上，就是小端模式（little endian)。

网络通讯中，定义网络协议时，都指定用大端模式。所以通用的办法就是，不管主机的字节序是什么，往网络上发送前，都转换成网络字节序，也就是用htons或htonl；而从网络收到的数据，不管主机是什么字节序，都转换成主机字节序，也就是ntohs或者ntohl。按照这条规则，一般来说，不会出什么问题了。

举个例子，一个int型的整数在计算机中占4个字节，那么就有两种排列方法：
整数0x01020304的两种表示方法
低地址 。。。。。。。。高地址
04 03 02 01 －－－－－－》方法1(小端格式:高字节放到低地址上)
01 02 03 04 －－－－－－》方法2(大端格式:高字节放到高地址上)网络字节序

其中方法1和方法2的区别就是高位放到高地址还是低地址。

方法1 叫做小端格式，方法2叫做大端格式，网络上使用的大端格式，而主机格式随着不同的机器不同，为了使得不同的主机格式能够无歧义的和网络格式相互赋值，一般牵涉到网络的开发库会定义一套两种格式之间的转换函数，这样直接使用转换函数就可以完成两者之间的转换。

在windows中有htons，ntohs，htonl，ntohl等一套函数，分别用来完成2个字节和4个字节的转换。


关于函数的记忆：

htons可以翻译成：host to net short; ntohs可以翻译成：net to host short

htonl可以翻译成：host to net long; ntohl可以翻译成:net to host long

[sevencat]

要求不高的话不需要这个crc.
不对是你程序某个地方有些bug，跟网络没关系。

[Wenxy1]

CRC校验，在通讯系统中常见。
CRC能检查出错误并修正一部分错误。

[udknight]

你的发送和接受的包可能有时候不一样。

[sssnowman]

TCP不用检验的！