谁知道为什么我Rust新版进一个服务器的时候一直在载入中……CALCULATINGcoms checksum bad?

tstc's Blog
字号:大 中 小
&偶在使用omnipeek分析数据的时候,发现本机发送出去的TCP数据报在专家诊断中都提示TCP校验和错误,经过分析,从服务器返回来的数据确认,说明服务器还是收到了这个TCP校验和错误的数据报(正常情况下,如果产生TCP校验和错误,目的主机应该是不能收到的),因此判断应该是omnipeek软件的问题,但是问题出在那里呢?遂发帖请教高手,找到如下解答,遂明了.
&Ethereal抓包时发现TCP校验和错误& Q: 在Windows平台上用Ethereal抓包时发现TCP校验和错误,但应用层的反应告诉我,这个报文的TCP校验和没问题。& A: 网卡配置-&高级-&Rx Checksum Offload/Tx Checksum Offload,很可能你的这两处设置是Enable,将之调整成Disable即可,代价是网络性能降低。& 一般由操作系统的TCP/IP协议栈完成TCP/UDP/IP校验和的计算工作,这两处设置成Enable之后,协议栈不再进行校验和的计算,而是由网卡自己完成。如果在前述位置没有发现Rx Checksum Offload/Tx Checksum Offload项,有两种可能,一种是网卡本身不支持这种功能,另一种是网卡驱动未提供配置项,后一种情形居多。事实上该问题与使用何种Sniffer软件无关。
 If you see the checksum of all local packets showed as invalid, it could be the checksum offload feature. When this feature enabled, an adapter performs the cycle-intensive process of calculating CRC, the Windows TCP/IP stack does not calculate the IP and TCP checksums but leaves them as 0x0000.  To fix this issue, you need to disable the adapter's Offload Transmit IP Checksum and Offload Transmit TCP Checksum feature in the advanced setting dialog.
使用鲨鱼抓包,发现自己发送的TCP包几乎全是有Checksum错误的,问题原因:
 Checksum Offload
  On the send side, the network adapter that supports this offload will calculate checksums that are needed and for which it has indicated the capability of performing. For the TCP checksum, the Microsoft transport will calculate the TCP pseudo header checksum and place this value in the checksum field, so that the network adapter can calculate the correct TCP checksum without touching the IP header.
  在发送端,支持offload功能的网卡会计算必要的校验和并以此显示其性能。对于TCP校验和来说,微软传输层会计算TCP伪头校验和然后把它放到校验和字段中,这样网卡就可以计算出正确的校验和而不需要打开IP头。
  On the receive side, the network adapter will fill in a NDIS_TCP_IP_CHECKSUM_PACKET_INFO structure and set the appropriate bits. If for any reason the network adapter cannot perform the checksum, it will not set any bits and indicate the packet. TCP/IP will then look at this and calculate the appropriate checksum itself.
  在接收端,网卡会填充一个NDIS_TCP_IP_CHECKSUM_PACKET_INFO结构体并置相应的比特,如果因为任何原因网卡无法计算校验和,它不会置任何比特并且标出这个包。TCP/IP会发现这个包并且自行计算出相应的校验和。
  参考资料:
  以上内容提到了TCP伪头的概念,TCP和UDP协议都可以有伪头。我的理解是,TCP/UDP伪头是专门为校验和而存在的一个结构,UDP可以不用校验和,而TCP则必须进行校验。它并不是真实存在于TCP/UDP头部的,根据《TCP/IP详解,卷一:协议》中11.3节的描述,这个伪头是存在于传输层协议前面,是IP头的一部分。
  回想IPv4首部的结构,在32位源ip和32位目的ip字段之后就是选项字段,而这个伪头就恰好包含了源和目的地址,而且多加了32位的协议和传输层数据长度字段。
function open_phone(e) {
var context = document.title.replace(/%/g, '%');
var url = document.location.
open("/ishare.do?m=t&u=" + encodeURIComponent(url) + "&t=" + encodeURIComponent(context) + "&sid=70cd6ed4a0");
!觉得精彩就顶一下,顶的多了,文章将出现在更重要的位置上。
大 名:&&[]&&[注册成为和讯用户]
(不填写则显示为匿名者)
(您的网址,可以不填)
请根据下图中的字符输入验证码:
(您的评论将有可能审核后才能发表)
已成功添加“”到
请不要超过6个字

我要回帖

更多关于 calculating 的文章

 

随机推荐