TCP/IP是可靠性传输协议，它能保证数据能按顺序的方式到达目的地。看到以上描述在写TCP/IP应用的时候似乎就可以放心了，只要程序不出意外就数据输传就是正确。但最近在做一个文件传输工作的时候确得到的结果并不是这样，发现网络环境和一次发送数据大会影响整个输传结果。以下是这两晚的测试情况

　　测试内容描述：

　　每个文件块信息包大概是120k左右

　　采用异步5连接输传，双方的Socket.SendBufferSize和Socket.ReceiveBufferSize都设置为64K

　　测试服务器分别有：

　　局域网：ServerA

　　在美国机房：ServerB 延时高，Ping有时会超时

　　测试client一台，通过ADSL上网。

　　以下是Client从Sever下载文件的情况：

　　服务器8K SendBuffer，客户端是8K ReceiveBuffer

　　从ServerA下载文件，分别下载多个文件几M到几百M不等，下载后文件正确。

　　从ServerB下载文件，分别下载多个文件，几M或更小的文件有部分正确，大文件基本都是错误。两端记录的发送的字节数和接收的字节相等，符合文件大小，程序也没有跟踪到数据接收异常导致的协议分解错误。

　　服务器4K SendBuffer，客户端8K ReceiveBuffer

　　从ServerA下载文件，分别下载多个文件几M到几百M不等，下载后文件正确。

　　从ServerB下载文件，分别下载多个文件，文件的正确率比较高，不过还是大文件相对错误比较多。当开启迅雷下载后情况就开始变坏，大部分接收到的文件都出问题，两端记录的发送的字节数和接收的字节相等，符合文件大小，程序也没有跟踪到数据接收异常导致的协议分解错误

　　服务器2K SendBuffer，客户端8K ReceiveBuffer

　　从ServerA下载文件，分别下载多个文件几M到几百M不等，下载后文件正确。

　　从ServerB下载文件，分别下载多个文件，下载结果没有发现错误文件。当开启迅雷下载后还是有个别文件错误，两端记录的发送的字节数和接收的字节相等，符合文件大小，程序也没有跟踪到数据接收异常导致的协议分解错误

　　服务器1K SendBuffer，客户端8K ReceiveBuffer

　　从ServerA下载文件，分别下载多个文件几M到几百M不等，下载后文件正确。

　　从ServerB下载文件，分别下载多个文件，下载结果没有发现错误文件。当开启迅雷下载后没有发现文件错误。

　　测试文件发送到Server和下载的情况基本差不多，这说明了在网络不好的情况处理发送大数据包似首容易产生错误，但看TCP/IP协议讲解这情况似乎不存在，因为当一个发送数据超过某个值的时候，TCP会划分块进行传输并保证其顺序。但网络不好的情况测试结果接收的数据有错误，但处理的数据大小是正确的，也并没影响整个协议的分解。由于对CP/IP协议、低层和路由处理的不了解，暂没找到具体原因......不排除程序存在还没发现的错误，打算给发送的文件数据加上校验再测试一下看情况

　　补充一下

　　以上测试只修改了一个属性

　　TcpUtils。SendBufferLength = 1K，2K，4K，8K

　　但只有1K的测试结果奇怪地没出现文件错误，其了几中均出现仅仅是对ServerB，对ServerA来说没有出现，2K，4K也只是开启迅雷的时候错误情况多。