浅谈数据容灾系统中带宽、延迟、并发流、效率等

network

本文节选自即将出版的《大话存储2》的第17.9一节，出版社保留版权信息。先发出来让大家先睹为快。同时欢迎提出错误和建议，谢谢！ 17.9 带宽、延迟及其影响         100Mb/s，这个速率意味着什么呢？有人说，每秒可以传输10MB的数据（8/10b 编码下）。通常情况下，这种说法是对的。但是如果发送方与接收方之间的距离变得很远，比如数百公里甚至一千公里，那么这种说法，你会发现根本不成立。我们现在就来分析一下。         大家知道，光或者电信号的传输是有固定速度的，即近似每秒30万公里（其实远未达到，光在光缆中的传播速率只有20万公里每秒，电信号在电缆中的传播速率则近似21万公里每秒。基本上是光在真空或者空气中速率的三分之二）。如果两点之间距离为1000公里，那么信号传一个来回（传到对端，然后对端给以ACK应答）所耗费的时间就是1000÷300000×2≈6.6ms。什么概念呢？也就是你想把1bit的数据传输到一千公里之外的地方，那么至少你要耗费6.6ms。那么传输10bit、100bit、1Kb、100Mb，需要多长时间呢？首先想到的是，至少比传1bit要慢。到底需要多长时间？来看这个公式：传输来回时间=（数据量÷链路速率×2）+（传输距离÷光速×2）。数据在传输的时候，是首先会被通过编码电路将数据串行化编码然后放到电路或者光路上传输，这个编码速率，就是链路带宽，100Mb/s的带宽与1000Mb/s的带宽，区别就在于后者在单位时间内可以编码相当于前者10倍量的数据，但是不管链路带宽有多少，数据被编码之后，数据在电路上的传输所耗费的时间对各种速率的链路来讲都是一样的，因为传输的时候已经与链路编码速率（带宽）无关了，传输到对方之后，对方还需要解码（所以编码所耗费的时间也要乘以2），同样也是取决于链路带宽。         所以，当两点之间传输距离很近的时候，比如1千米，那么传输时延≈0.0066ms，基本上可以忽略了。所以那个公式变为：传输时间=（数据量÷链路速率）。所以说，链路速率越大，只代表其编码速度越快，而不代表传输速度越快，传输速度是固定的，都是光速。再打个比喻，有一辆长途车，50个人排队上车，排队上车需要120s，汽车行驶需要60000s，50个人排队下车需要120s。50个人被排队送上车，就好比数据被串行编码放到电路上传输，汽车行驶相当于电路信号从一端传递到另一端，50个人被排队下车，就好比对端的解码过程了，然而到此还没有结束，当汽车抵达目的地之后，司机必须在返回出发点进行报信，这就好比TCP协议在收到数据之后发送给源端的ACK应答一样。可以司机空着车跑回去报信（单独发送ACK应答包），也可以在目的端捎带着一些回程客人返回去报信（TCP可以在反向流量中夹带ACK应答信息以提高效率）。但是在容灾系统中，数据总是从源端流向目的端的，或者在灾难回切的时候从目的端流向源端的，总之只有一个方向有实体数据流动，那么此时回程ACK都是独立的ACK应答包（独立ACK包很小所以其编解码所耗费的时间也忽略掉即可）。         另外，一辆汽车能承载的人数是有限的，也就是说，得一趟一趟的拉，这就好比TCP每次所发送的最大数据长度，也就是TCP的滑动窗口长度，TCP得分批把用户数据传送出去，每次的发送量必须小于TCP滑动窗口的长度，每次传输之后均需要对方发送一个ACK（这里不考虑ACK合并等特殊情况）。每批数据虽然到了底层可能被切分，比如TCP的MSS（Max Segment Size）切片，一般等于底层链路的MTU，底层链路再用MTU的值来切片，但是这些底层的切片在被传输到对端之后，并不需要对端底层协议的应答，只有对端的TCP在完整的收到TCP发送的一批数据之后，才会应答。         那么我们来算算在相隔1000千米的两点之间，每秒到底能够传送多少个来回：1000ms÷6.6ms=151个来回。如果按照TCP的典型滑动窗口即16KB来计算的话（每次发送16KB数据然后就等待应答，不考虑延迟应答或者合并应答等特殊情况），那么每秒吞吐量仅为151×16KB=2416KB，也就是2.4MB每秒。夸张么？ 当然，上述算式是忽略了编解码所耗费的时间以及整个链路上各种中继、转发或者协议转换设备所带来的处理延迟，如果算上这两者，则吞吐量会更低。更加准确的实际数据传输吞吐量计算公式为V=TCP Window Size÷2（TCP Window Size÷链路带宽+距离÷光速+链路设备处理延迟）。总之，距离越远，实际传输吞吐量就越低，在实际应用中一定要有底。 当距离很短时，可以忽略距离带来的延迟，此时显然谁带宽高谁传的就快；而距离很长时，此时带宽再高也无济于事，因为大头都被距离给耗掉了。另外，即便是底层链路的带宽相同，距离也相同的情况下，使用不同的协议进行传输，所带来的延迟也是不同的。但是设想一下，不管链路跨越了多长的距离，如果这条链路上永远都有数据在传着，那么发送方与接收方就可以以链路带宽的原生速率来收发信息，只不过有时延，就像卫星电视那样，此时传输速率并不会打折，如果做到这一点，那么对于一个容灾系统来讲是非常好的事情，充其量只会丢失几毫秒之内的数据。但是，事实却并非如此。超远距离传输，怕的就是数据流的卡壳，卡一次两次不要紧，频繁卡壳，那就根本无法利用起链路带宽了。这就好比磁盘寻道操作一样，本来磁头能以很高的速度读写盘片上的数据，但是没办法，必须换道，这一换道，外部速率骤降。碰巧的是，15K转每秒的SAS盘其平均寻道时间为5.5ms，而一千公里距离的传输时延为6.6ms，这两个值倒是接近而且还挺有意思。 传输协议无法避免“卡壳”，因为总要传一段歇一段来等待对方吱个声，看看收到没有。比如TCP，这样就平白无故的浪费了底层链路时隙；再加上长距离下的高传输延迟，一来一回更浪费了大量时间，所以会出现上文中的即便是千兆链路下，1000公里的距离每秒也只能传输2.4MB的理论值，实际值将会更低了。 另外，如果在长距离下使用诸如iSCSI等协议的话，那将更是一笔惊人的浪费。大家知道SCSI层本身就有传输保障机制，人家自己有ACK那一套，而底层TCP再来这一套显然就显得多此一举了。按理说有了SCSI层的传输保障机制，其下层协议栈就应该是个无状态的类似链路层协议了，应该直接将数据一股脑传过去，但是现实是它非得传一段，停一段，等待对方说个OK，然后再传再停，慢慢腾腾；不仅如此，再加上SCSI也要传传停停，那就是变本加厉。所以长距离上跑诸如FCP、iSCSI等这种SCSI协议与FC/TCPIP协议的合体协议，将会是个梦魇。 降低不必要的ACK数量，增加滑动窗口，这些都是广域网加速的技术，对传输速率会有一定程度的提高。但是最终解决办法，还是要尽量缩短两地距离，或者开发专用优化的协议了。        说到私有协议，这里就展开讲一下。上述所有场景，均建立在两点之间只有单TCP连接，即单流的场景下，此时的链路带宽当然无法被充分利用，而且也提过，如果底层链路一刻也不闲着，那么其有效带宽就可以更高的被利用，怎么办呢？显然，通过提高并发连接的数量，就可以充分利用起底层链路的时隙。关于这个思想，在磁盘阵列控制器如何充分利用起后端FCAL环路的带宽方面也是类似的，大家可以阅读附录1中的第5问。     大家知道iSCSI里有个Multi Connection Per Session的概念，使用Microsoft的软iSCSI Initiator的话，里面就可以进行设置，让Initiator端可以同时与iSCSI Target端建立多条并发的TCP连接，从而提高远距离传输时的效率，当然这个特性需要iSCSI Target端的支持配合。但是对于FCP来讲，就没有这种特殊考虑的并发连接设计了。经过考量设计的可并发连接的私有协议可以极大提高远程数据传输的效率。        既然说到了多流并发，那么索性就再展开一些。对于一个异步模式的数据容灾复制系统，最起码要保证的是灾备端数据的一致性，而数据一致性又有多个层面，最底层的一致性就是所谓“时序一致性”，灾备端起码要保证每个IO都按照其在源端被执行的顺序刷入灾备端数据集中。如果使用单流TCPIP则可以保证时序，但是传输效率很低；但是在多流并发的情况下，因为原本流与流之间是无关联的，可能在源端先执行的IO被传送到对端之后却被后执行了，此时就需要引入更复杂的逻辑来保证同步过去的数据被按照顺序执行。这里又有两种办法可以考虑，一种是保证RPO，在多个流之间维护强一致性，将多个流强制关联以保证收发顺序，此时灾备端可以立即将收到的IO数据刷入底层数据集；第二种则是牺牲RPO，主备站点之间之间采用端到端的一致性组技术，在数据批与数据批之间保证时序性，而不是每个IO之间。此时灾备端不能在收到数据后立即刷入，比如等待一批数据全部收到之后才可以刷入。这么做虽然可能导致丢失一批数据而不是几个IO，但是可以方便的保证数据一致性。本文节选自尚未出版的《大话存储2》，发出来让大家先睹为快。同时欢迎提出错误和建议，谢谢！

(2个打分， 平均：3.00 / 5) [td]

工具箱
本文链接 | 邮给朋友 | 打印此页 | 30条用户评论 »



雁过留声

“浅谈数据容灾系统中带宽、延迟、并发流、效率等（摘自《大话存储2》）”有30个回复

• hritian 于 2011-01-15 5:44 下午
  既然用到了TCP协议，那么传输速度就必然和网络状况有关，时延大没有丢包的网络环境下速度依然可以足够快的，就我的经历而言中国到美国间的网络，速度跑到20MB的速度也是很经常的事。
  另外，滑动窗口和拥塞窗口不是一个等同的概念。滑动窗口是拥塞窗口的上限，现在的linux系统,就算你不改配置，滑动窗口有4MB（3000个窗口）的水平。
  决定传输速率的其实还是拥塞窗口的大小，时延大，如果网络不丢包，拥塞窗口如果足够大的话，速度依然是足够的。
  从互联网设计的角度来说，连接的能够分享的带宽是不和所谓的”距离“（时延）有关系的，只是和瓶颈带宽有关系。现实情况下时延和传输速度确实是有反比的关系，学术界有个说法”RTT不公平性“。
• Solstice 于 2011-01-15 6:08 下午
  “光或者电信号的传输是有固定速度的，即近似每秒30万公里。” 这个说法只对真空或空气介质成立。在 1000 公里的距离上，通常用光纤或同轴电缆来传递信号，光速远没有那么快。光在光纤中的传播速度大约是 20 万公里每秒。同轴电缆依型号不同，其信号传播速度大约是 0.66 ~ 0.88 倍光速，可近似按 21 万公里每秒估算。
• 冬瓜头 于 2011-01-15 6:16 下午
  感谢hritian从TCP底层的分析，关于滑动窗口与拥塞窗口，鄙人再去学习一下，这方面确实不够深入。但是从后半段来看，老兄所描述的是不是从网络角度来看，因为在一个聚合流量的链路中，链路带宽是充分被利用的，一刻也不闲着。但是对于单tcp流来讲，远距离时延关系很大。不过老兄确实提醒了我，忽略掉一个问题，文章中都是假设单TCP流，如果用多流并发，那就可以充分利用带宽了
• 冬瓜头 于 2011-01-15 6:19 下午
  感谢Solstice的信息，敢问这些数据是否是算上了中继设备转发设备等延迟之后的等价速率，还是裸速率？
• kevin 于 2011-01-15 6:41 下午
  “传输协议无法避免“卡壳”，因为总要传一段歇一段来等待对方吱个声，看看收到没有。比如TCP，这样就平白无故的浪费了底层链路时隙；再加上长距离下的高传输延迟，一来一回更浪费了大量时间，所以会出现上文中的即便是千兆链路下，1000公里的距离每秒也只能传输2.4MB的理论值，实际值将会更低了。
  其实看完这段，我就很好奇了。。。哪个一千公里的千兆链路只传一条流。。。
  你的书还没印吧。呵呵
• 冬瓜头 于 2011-01-15 6:49 下午
  不好意思忽略多流了。
  所以还得看数据复制时候使用的协议，如果使用fcp，肯定是无法多流，iscsi可以多流。再就是私有协议了。但是大部分存储设备层的数据同步过程，都是使用的类scsi协议，在fc链路上复制数据，此时如果用fc转ip协转，是否他们的协议是经过修改的从而支持并发多流，这一点是需要继续调查的。
• hritian 于 2011-01-15 7:11 下午
  关于时延的影响，在网络拥塞的时候，时延大的连接能够分享的带宽就会少，对此我有一篇文章是用来介绍它的，你可以去看看http://blogold.chinaunix.net/u3/93004/showart_1826609.html。
  从单个连接的角度来说，互联网是best-effort架构的，是不会为连接提供带宽保证的，如果你所见过的链路都不堵，ok，你的连接速度是没有问题的。
  如果网络堵了，这个时候每个堵的链路+更大的时延+不合理的算法就会导致连接的速度上不去。
  所以说问题在于网络拥塞，连接不能从网络中分配到足够的带宽，而不是连接不能充分利用用户带宽。
  我觉得你所描述的现象是ok的，但是论据。。。。。。。
• locsic 于 2011-01-15 7:40 下午
  其实实际部署中，最头疼的是UDP和TCP并发的情况，多TCP还好
• Lucifer 于 2011-01-15 9:21 下午
  看到这段文字，我想起了《分布式操作系统》（Andrew S. Tanenbaum）的开头也有类似的阐述，不过说的是其他形式的网络
• 冬瓜头 于 2011-01-15 9:47 下午
  说道分布式系统，最近也在学习，强烈期待国内web2.0公司的牛人能够出一本通俗详细讲解分布式系统的书籍。nosql在2008年兴起，至今已经2年，但是市面上除了基本人云亦云的云计算方面书籍只外，好像并没有看到有人专门讲解这些分布式系统的。
• Lucifer 于 2011-01-15 9:53 下午
  国内有很多自己编撰的教材，但是我没有见过比我13年前买的第一版《分布式操作系统》更好的学术著作了
• 冬瓜头 于 2011-01-15 10:08 下午
  了解，曾经在当当等也搜索过，确实都很老。学术著作阅读起来是很费劲的，这也是我写《大话存储》的原因，让更多人来了解，降低门槛，这样这个行业才能得到更多的新鲜血液和根基，所以也希望看到其他领域的这类书籍。
• Matt 于 2011-01-16 12:27 上午
  Locsic说到“UDP和TCP并发”。。。TCP能剩多少？
  冬瓜头的科普还是造福人民的。建议先科普成熟的东西，最前沿的东东的科普，那不是拿个炸药奖就肯定能搞定的。
• 冬瓜头 于 2011-01-16 6:31 上午
  既然说到了多流并发，那么索性就再展开一些。对于一个异步模式的数据容灾复制系统，最起码要保证的是灾备端数据的一致性，而数据一致性又有多个层面，最底层的一致性就是所谓“时序一致性”，灾备端起码要保证每个IO都按照其在源端被执行的顺序刷入灾备端数据集中。如果使用单流TCPIP则可以保证时序，但是传输效率很低；但是在多流并发的情况下，因为原本流与流之间是无关联的，可能在源端先执行的IO被传送到对端之后却被后执行了，此时就需要引入更复杂的逻辑来保证同步过去的数据被按照顺序执行。这里又有两种办法可以考虑，一种是保证RPO，在多个流之间维护强一致性，将多个流强制关联以保证收发顺序，此时灾备端可以立即将收到的IO数据刷入底层数据集；第二种则是牺牲RPO，主备站点之间之间采用端到端的一致性组技术，在数据批与数据批之间保证时序性，而不是每个IO之间。此时灾备端不能在收到数据后立即刷入，比如等待一批数据全部收到之后才可以刷入。这么做虽然可能导致丢失一批数据而不是几个IO，但是可以方便的保证数据一致性。
• Hanx 于 2011-01-16 7:45 上午
  不太明白，为什么要保证多流的io时序，你指的是同一个应用的io写入通过tcp后变成乱序了？
  问题是这是文件系统和块设备驱动保证的问题呀，scsi本身也是并发的呀？
• Solstice 于 2011-01-16 7:48 上午
  20万公里每秒是裸速率，信号传播的最小延迟，用来算下限的。算上中间的路由器和交换机的话，延迟会更大。但由于跟网络拓扑有关，没有统一的估算办法，只能实测。物理距离近，延迟不一定小，这在跨国的网络中很常见。
• 冬瓜头 于 2011-01-16 5:15 下午
  To Hanx：
  如果把一批数据用一个tcp连接发送到对方，是不会乱序的，tcp不会对数据流进行定界，但是绝对不会乱序，本来是1234，传到对面依然是1234，对方只需要从头将数据流解析定界出一个个io然后刷入灾备端的存储介质就可以了。但是多流tcp的话，一批数据，并行切分由多个tcp连接发过去，此时多流之间的数据就乱掉了。
  文件系统和块设备驱动不会保证io的时序性，典型的比如linux下的io shceduler，他就是可以乱序io，为了优化，同样，底层磁盘的ncq、tcq，也是乱序io的。解决乱序io是上层应用需要考虑的，比如绝对不会在发起写请求而没收到OS内核返回信号之前再对同一个地址发起读请求，因为会造成过期读。但是这种由应用保障的方法是强实时性有状态的，而对于灾备端来讲，他的应用程序就是主站点的存储系统，而主站点存储系统是无法感知应用逻辑的，所以灾备端只能乖乖的按照顺序执行，否则恢复的时候会造成严重不一致，可能导致应用无法启动，甚至连卷、文件系统都无法被mount。
  关于读写一致性的问题，在《大话存储2》中详细论述了。另外，最近也在研究nosql分布式系统，其中的一致性保障机制也很有意思，比如nwr模型。
• 冬瓜头 于 2011-01-16 5:16 下午
  To Solstice：
  感谢提供的信息！
• Tech 于 2011-01-17 11:01 下午
  光在光纤按照20万公里每秒估算是合适的，长途传输的时延和物理距离息息相关，现网环境北京－南京－上海的时延是18ms，北京－南京－杭州－上海的时延是25ms。从美国本土到中国大陆的时延大家可以到AT&T的路由上试一试，看到你的机器是多少。这么远的距离，没有并发是不可能提高速度的，支持冬瓜头！谁有问题可以我的邮箱。
• Tech 于 2011-01-17 11:24 下午
  径路发错了补充一下：北京－南京－上海光缆距离约为1500km，北京－芜湖－杭州－上海光缆距离约为2000km，给大家一个大致的参考邮箱g3gogo@163.com
• xin 于 2011-01-17 11:54 下午
  “光在光纤按照20万公里每秒估算是合适的”，另外光纤实际长度会大于两点间物理距离。
  TCP的滑动窗口大小，默认是16位，最大64K，目前协议支持滑动窗口扩展。
• 黄岩 于 2011-01-21 7:01 上午
  无丢包（或者少丢包）的环境下，throughput <= rwin_size / RTT，而rwin_size是可以设置的，代码中用setsockopt(…SO_RCVBUF…)，也可以调整系统参数改变默认值，所以，在无丢包或者丢包很少的环境下，这篇文章前半部分的描述就是不正确的，主要是前提假设错了，前半部分机遇win_size不可变的假设展开讨论，最后得出: “1000公里的距离每秒也只能传输2.4MB的理论值”，是值得商榷的。
  在iSCSI应用情况下，我们可以把win_size设置为20MB，这对系统不会造成什么负面作用，因为iSCSI的TCP连接数很少，报文缓冲区占用内存也不多。
  但是在互联网服务器上，可能有10k个链接（前两年网管热衷讨论C10k问题），如果每个链接都需要20MB的接受缓冲区（不需要实际分配空间，但是可能会占用这么多内存），仅TCP协议就需要几百GB的空间，的确是问题。好在http服务器对每条链接不需要那么高的吞吐量。
  在丢包比较严重的环境下，throughput <= MSS / (RTT * sqrt(P_loss))。MSS是不可变的，就算是两台主机直连，启用Jumbo帧，MSS最大也只有9000Byte左右，通常情况下是1460。也就是说，在有丢包，且延时很大的网络上，想要让TCP的达到很高性能，是非常困难的。也就是说，在丢包比较严重的环境下，楼主的结论是正确的。
  所以，对于iSCSI协议的性能来说，最大的问题是丢包，而非时延。FCoE来说，丢包的问题就更严重。
  而对于IP和以太网来说，丢包是处理网络拥塞问题例行做法。在iSCSI之前，从没有那种应用对TCP吞吐量提出了这么高的要求。
  所以，Cisco交换机针对以太网做了一系列补丁，指望他能够解决数据中心的服务器与存储的链接问题。但是窃以为它选择FCoE方向不大对头。为了效率，丢掉TCP/IP协议栈，似乎得不偿失。
  就像当年的MIPS指令为了提高效率，搞了个延迟槽的概念，结果却只有那么少数两个型号的CPU从延迟槽得到了一些好处，而后面的所有MIPS体系结构的CPU不得不向前兼容这个历史包袱。
  http://en.wikipedia.org/wiki/TCP_tuning
• 理客 于 2011-01-21 3:22 下午
  黄岩兄很内行。
  实际网络中，一个刚性管道，就是构成管道的传输设备没有queue缓存做RED/WRED，而管道带宽又比业务带宽需求小很多的情况下，性能恶化很厉害。此时如果在管道的瓶颈位置增加支持RED/WRED的queue调度，那么性能有大幅提高。这是TCP/IP需要IP QOS的一个原因，IP QOS只在TCP/IP基本成熟才有的，可见终端和网络的解耦是TCP/IP协议设计的一个重要原则，所以设计之初是让TCP/IP终端自己通过TCP的QOS机制来解决网络拥塞问题，而后来在实际网络应用中，发现在刚性管道拥塞下TCP是有严重性能问题的，IP QOS的基本功能至少还是需要的，目前网络上所有的设备，基本都支持每端口4/8个队列，一般来讲，只要队列做得不是太差，TCP应该运行得还是可以的
• 冬瓜头 于 2011-01-22 2:31 上午
  非常感谢黄岩兄的解释，很给力，咱们一个公司的。确实值得再商榷。又想到额外的问题，如果将Win size设置为20MB，就算链路不丢包，而且就算延迟也很小，但是并不能保证tcp checksum error就会降低，一旦有checksum error，那么整个就要重传，此时更加得不偿失吧？我想这就是窗口太大的一个副作用啊，实际中一般还是不能设置太大的窗口么？
• 黄岩 于 2011-01-22 6:20 上午
  在弯曲，咱们是老乡哈：）
  俺理解，除非中间的路由器或交换机有Bug，或者两端主机软件有Bug，否则不会出现TCP Checksum，传输线路上的误码会被链路层的checksum检测出来，错误报文在链路层就丢掉了，TCP能感知到的只是丢包。所以TCP checksum error是非常小概率的事件，也不是影响TCP的性能的主要因素之一。
• 黄岩 于 2011-01-22 5:24 下午
  再补充一句，TCP checksum error也是丢包的一种原因之一。
  丢包有这么几种原因：
  1、网络带宽不足，网络发生拥塞。这个时候路由器交换机在收到报文并查表找出‘出接口’之后，发现该出接口队列长度超过限值，路由器交换机执行丢包策略。这是最经常发生的丢包，在Internet上，这种原因丢包是常态。
  2、报文在传输线路上发生误码，链路层收到报文的checksum错误，丢包。这种几率会第一种小很多。
  3、由于两端主机内存不够，总线带宽不够，CPU处理能力不足导致的丢包。
  3、TCP checksum error，这个就是Bug导致的丢包，几率很小。
• 冬瓜头 于 2011-01-22 9:17 下午
  谢谢。但是如果tcp checksum error属于bug的话，那么为何要千辛万苦的计算checksum，而且网卡还可以checksum offload，岂不是多此一举了么？
• 黄岩 于 2011-01-22 10:49 下午
  下面这篇文章对TCP checksum errors的发生概率和故障模式做了一些研究。
  http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.27.7611
  TCP checksum errors原因有一下几种：
  1、主机软件有Bug，发送端把TCP报文算错了；
  2、主机硬件有Bug，比如内存出错，总线出错等。发送端在网卡还没有计算CRC之前，报文数据就错了，或者接收端网卡校验了CRC之后，数据错了。
  3、路由器软件或者硬件有错误，把报文内容修改了。
  4、报文在传输线路上出错了，但是链路层的CRC协议没有检测到这个错误。
  按照文章里面的说法，TCP checksum errors的比率还是很高的，1/1100 – 1/32000之间。但是文章中数据的年代比较久远了，都是12 – 13年之前的事情了。很多数据都是在10Base2、10BaseT Hub上抓取的。
  俺估计，现在的情况应该好得多了，比率应该没有这么大了。
  虽然TCP checksum errors的发生几率很小，不是影响吞吐率的主要原因。但是TCP checksum errors是的确存在的，如果TCP层不计算checksum，那么传递到端数据出错的概率就会增加很多，我们平时下载的RedHat安装ISO，就会经常遇到不能安装的问题。
  TCP保留了checksum，并不影响光碟下载的速度，也避免了下载光碟不能安装的问题。
• bigrong 于 2011-01-24 9:03 下午
  没看完就觉得这篇文章写得特棒。不知道是哪位大侠的原著，最好报个真实姓名，在下要好好顶礼膜拜一下，在家里弄个排位放在首席边上，动不动点上三炷香，弄点酒肉供一供。以后闺女如果搞计算机通信，一定要先让她拜拜几位，知道学问做到什么程度就是大师了。真的透了（想起让子弹飞了）。
  这篇文章让我想起当年拜读jeff doly的tcp/ip routing……的原著了，大师手笔！
  赞一个！
  继续读！
• bigrong 于 2011-01-24 9:13 下午
  作者是张冬吗？
  joyo只有第一册，没有第二册。
  如果都是如此风格，倒是可以买一本作为我这个伪技术的睡前读本啊。
  不过，希望别太厚，现在的书很多都是卖zhi，不是卖zhishi。