请教大家一个问题，TCP是绝对100%可靠的吗？

用TCP进行文件的传输，经常发现接收后的文件的校验码不对了，小文件还好，大文件出错概率比较高，会不会是TCP传输过程中出错？我要不要在传输过程中做校验？

解决方案 »

  1.   

    TCP是可靠的，看看你的代码是怎么处理的？
      

  2.   

    TCP不是100%正确的,因为他只是简单的 16位相加,如果有一个16位 错误,比原来的数值大1,而有另一个16位,也错误,比原来的数值小1,那CRC的结果是正确的,而文件已破坏了.
      

  3.   

    不要在传输过程中校验,要保验绝对正确,只有使用更复杂的校验算法,会大大降低传送效率,最好在应用层收到所有包后在校验，因为TCP传送中ＣＲＣ的错误机率还是很小的。
      

  4.   

    tcp 是可靠的,这里所说的可靠是指tcp 会保证你接收到的数据是正确的(tcp 不会把错误的数据交给你)，但不代表 tcp 传输时不会出现错误，，除非你要自己做一套类似 tcp 的传输控制协议，否则你没有必要对tcp进行干预。
      

  5.   

    只要你能接收到的数据就是可靠的，因为TCP有差错控制，会丢弃错误的包 请求重发，如果接收数据错误是你代码的错误
      

  6.   

    在测试的时候出现这种问题
    100%是你自己代码的问题
    因为你的代码在测试的时候还没有伟大到值得别人使用IP层替换方式进行攻击
    这种攻击的代价是极其昂贵而且复杂的
    在一般情况下，除非军用等级，完全可以认为TCP是100%正确的
    具体可以看TCP/IP协议1-3
      

  7.   

    如果楼上的话是正确的话
    那么所有的FTP协议，HTTP协议，POP/SMTP协议
    必须全部被改写并加入校验机制
    问题是到现在为止，IETF好象没有任何关于传输不安全而有专家提出草案的IP层替换理论上说的容易，实际操作起来，你无法知道路由实际经过，在INTERNET上，你要替换，首先你要有抓IP包的路径和能力，事实上在两个陌生IP点之间，你根本没有能力去抓，你怎么抓？抓了以后你还要保证或者阻塞这个IP包，或者保证你的包比这个IP包早到目标机器，抓都不好抓，更别说立即替换了，别对我说其中一个IP点在你的同一个内网内并且端口屏蔽没做，或者你就是网关；还有一种方法就是不抓包，而瞎猜，使用IP包直发，这个概率比哈雷彗星撞地球的概率还小。给你个简单的例子，ftp 服务器122.3.12.56 Client: 220.32.1.16 ,而你的机器IP： 85.122.2.46,你怎么去抓，怎么去替换？ 你能知道它是怎么路由的？ 提供下载文件校验MD5或者SHX的目的，并不是简单的针对传输过程，而主要是为了防止有人恶意在原始包中插入非法的文件或者代码或者修改原始文件。
      

  8.   

    也就是说： 这个文件可以或者可能在下载后被再次发布给别人，但是为了防止某些人串该原始数据，特地加了MD5或者SHX等校验码，这样可以保证再次发布后用户依然能知道自己下载的东西是否被人修改过
      

  9.   

    你们提反对意见的人，会算校验码吗?首先申明，我可以用　二层的包，构建出ＨＴＴＰ包，并访问网页，那种 IP层替换方式进行攻击 是小儿科了，用低层攻击手段，我几乎可以截断任何没有加密的协议，如web,msn,telent 等，当会话两端连接以后，我可以中间截断，假冒其中一端和别一端通信.所以如果连 校验码 都不会算的人，请闭上你们的嘴，只会让人笑话．
      

  10.   

    我不懂的，
    我错了,
    没让FBI看上，真是浪费人才啊，
    楼上的继续
      

  11.   

    顺便请你帮个忙，我现在登陆CSDN中，请你截断吧，
    CSDN都是明文，没有什么SSL，SSH之类的加密，截断吧
    我在线等待中
      

  12.   

    to husheng34(随意生活)我觉得你挺有意思啊，题目都没理解清楚就乱说话，我问你，你伪造的数据要想让tcp 交给应用层首先是不是要通过 tcp 的校验码检测？如果tcp 发现较验码错误会怎么办？ 是丢弃还是继续交给应用层？如果校验码正确呢？所以说校验码检测和数据伪造根本就是两个问题，用校验码不是为了解决数据伪装的，这点你要搞清楚。校验码的主要目的是要解决数据在电器设备上传输时受到电信号或磁场等因素干扰导致数据错误的，不是用来防止伪装的。别告诉我你这么厉害一个人连这都不懂。
      

  13.   

    还有楼上几位说“所以会有提供下载文件的检验码的站点”这是为了防止数据伪造或者篡改的，不是为了解决 tcp 校验码问题。
      

  14.   

    TCP协议主为了在主机间实现高可靠性的包交换传输协议看来我的观点的确不正确，在这里承认错误！TCP 的确无法%100的实现可靠性。向受我误导的朋友们道歉 呵呵
      

  15.   

    TCP是可靠的，是相对于UDP来说的：
    TCP在发出一个包后，会等待对方返回一个确认包，如果在一定时间内没有受到确认包，那么它会再发一次，重发次数跟操作系统有关。发送超过一定次数后没有受到确认包，那么人为连接已经断开
    而UDP则是不管对方有没有受到，它只管发送楼上说的检验码，只是防止在传输过程的电气错误，它只能保证包正确性保持在一定的范围之内--这个范围在目前的技术不是100%
      

  16.   

    感谢大家如此的热心，没想到这个问题居然牵扯出了这么一大段的激烈的讨论，但是根据我的影象，在TCP中所使用的校验码正如前面有人所说的，还只是比较原始的校验和的方式，这种方式检验的强度还很弱，很有可能在出错的情况下无法检测到错误的包，看来我有必要给我的程序再加上校验的部分。谢谢大家，如果大家觉得不对，请指教。
      

  17.   

    在保证数据链路层可靠的基础上，TCP是可靠的，不会出现包丢失的现象，除非被人恶意修改，而数据链路层是会出现错误的，毕竟没有哪个纠错码可以说自己能够100%纠错，只是保证在一定概率下不出现大的错误。而如果LZ的大文件传输经常出错，就有必要检查一下连线了，更换网线再试试看。
      

  18.   

    这种问题 看看tcp 卷一就很清楚了。
      

  19.   

    晕了。这种问题根本是程序写的不好，竟然怀疑到TCP身上去了。
      

  20.   

    怀疑TCP也是可能的。但我想自己的问题还是多一些，任何一种核验码，都有出错的概率，但既然它是一种核验码，其可靠性绝对是可以接受的。但一般的核验，基本上逃不出一个实质，即用正确的数据核验错误的数据，这一点应该没什么问题吧？那么想想这么一种情况——错误的数据比正确的还多呢？此时错误的数据就变成正确的了！所以，我以为，核验的本质是基于一种假设——正确的数据比错误的数据多。
    走个极端，发10个字节，全部错误，包括核验码，那么在验证数据的时候，有没有可能得出数据正确的结果呢？显然是有的!