五千年(敝帚自珍)

主题:【求助】不灵了,请弟兄们帮忙 -- 萨苏

共:💬152 🌺15
分页树展主题 · 全看首页 上页
/ 11
下页 末页
      • 家园 最新进展

        Sniffer 的截取分析显示了奇怪的东西。

        当Office2(Server)向Office1(Host)发送传送请求时,得到Host的ACK MSG,注明Window Size 32K,此后传送正常。而当Office1(Host)向Office2(Server)发送传送请求的时候,得到的Server的ACK MSG,里面的Window Size却在不断变化,从16K到0.3K。。。我想这是原因了,但是Server为什么会给出不断变化的Window Size呢?还在继续调查中。


        本帖一共被 1 帖 引用 (帖内工具实现)
        • 家园 几种可能

          TCP ACK里的窗口大小描述的是接受端缓存还剩多少空间。有几个原因可以造成这个尺寸变小。

          一是丢包,也就是说如果一个包丢了,后续收到的包要存在缓存里面,直到收到丢的包(重发)后才一起传给应用程序。这样的ACK包里,一般序列数字不变,只是窗口变小。不过这样的窗口尺寸变化应该很快,一两个回程时间之后就会恢复。如果又有丢包,也可以从窗口尺寸变化的大小和快慢分析出来。仔细分析一个波峰周期内的ACK内容就可以看出来丢包情况。

          还有一个可能就是接受端(win2000server)应用程序从网络内核取数据太慢,跟不上网卡接收速度。有的机器上网络接收扫描之类的保护也可能造成类似问题。换台机器,关掉网络保护试试。

          另外有的vpn路由可能会篡改客户tcp窗口尺寸,不过这种可能性不太大。

        • 家园 哈哈, 老萨阿

          Windows size不断变化就是终端在响应中间路由器或者对方要求降低传输速度的要求阿.

          在TCP协议中, 中间路由器或者对方在发现流量过大, 需要降低的时候, 往往就会采取一些方法, 比如将某些packet drop 掉, 这样发送方没有收到ACK 就会减小窗口大小, 当窗口变小, 发送方发现传送的东西又都得到顺利的 Ack的时候, 就又会增加窗口大小, 这就是TCP基本的动态流量控制手段.

          你用的不是专线, 中间的路由器就把你的Package 当作和其他人的数据一个级别的东西, 当某个方向上流量大的时候, 自然就可能会drop掉你的一些数据宝, 这样就启动发送方的流量控制机制, 所以你看到的流量也是锯齿形.

          TCP本身是为Best effort Traffic 设计的, 因为这个原因, TCP是不适合用来进行图像, 话音等需 Constant Bit Rate 的实时通信的.

          恐怕问题的根本原因还是中间路由器过于拥赛.

          • 家园 精彩!

            典型的理论指导实践,知其然,知其所以然,子衿真高手也!

          • 家园 谢谢,这个思路非常精彩

            如此说来是接收数据的Server发出ACK后,得不到所等待的数据,因此再次发出Window Size减半的ACK?周一上班后会和负责的工程师谈一下这个思路。

            • 家园 Good luck

              应该是发送数据的office1发出数据包之后,在TIMEOUT期间内没有接到由office2返回的ACK包(可能是由于中间某路由器由于拥塞-buffer满-将数据包丢弃了),于是发送端将自己的传输窗口减半以进行流量控制。虽然说数据包丢失或者ACK包丢失都可能造成这种情况,一般由于ACK包占用流量很小,应该是由于数据包被丢弃造成了。

              以前溜过一眼TCP记得好像是这样的,具体描述可见http://www.faqs.org/rfcs/rfc2581.html(主要是3.1部分)。Good luck!!

        • 家园 是不是于TCP的拥塞控制机制有关

          记得TCP的拥塞控制机制里当拥塞发生(包被丢弃)的时候,传输窗口减半,拥塞停止就一点点增加到最大窗口限制。不过如果来回路由的TCP连接数,路由长短等条件一样的话流量应该不会相差这么大吧。会不会是Office1向Office2的路由上有拥塞?

          • 家园 谢谢

            也就是说office1发送请求后,发现拥塞因此重新发window size减半的请求,而office2的Server的ACK便也相应出现Window Size的变化,被我们的Sniffer观察到,这样判断是否正确呢?

      • 家园 谢谢

        刚才我们在Office2的服务器和Sky-X之间设置了Sniffer,好像有了一点儿影子,接着分析。

        (工程师装Sniffer和测试的功夫,我写水鬼去了)

    • 家园 提醒所有河友们注意,加班时间太长会被burn out,俗称被轧干。

      我们公司一个同事出差,在新加坡坐出租,的哥原来也是干半导体的,才40就被burn out了,具体一点就是不是脑子不好使了,而是心不在这上了,不想动脑子想本行中的问题了。无独有偶,我们公司西班牙分公司被卖关门的时候,大部分工程师打算不干了这行了,加班时间太长,很多人处在被burn out的边缘。他们欧洲人的可选择性也比较广泛,跑堂,作保姆,开出租都不是给祖宗丢人的事。总之大家作鸟兽散,新老板接手时竟无人可用。

      可见加班对人的摧残。大家一定注意啊!

      实在要加班了,也要劳逸结合,每干一个小时就到亲亲宝贝看看照片,还是很解乏的。或者去清音画苑,边看边听,别有情趣。别去青史,越去越闹心。

      早点回家吧。

    • 家园 感觉问题的根儿应该还是在那家ISP上。

      它要是不给你提供内部测试数据,你就只好按Highway讲的办法一点点试了。

      结果可能还是一样:被那ISP讹一笔。老大准备掏钱吧。要不就在Office1 和Office2之间

      自己扯根专用线。看看哪笔帐更划算。

      最后,身体才是革命的本钱!

      • 家园 谢谢

        专线那玩意儿不用想了,要命阿。不行就走我们公司的内部网到那边落地,然后再找辙吧。刚才去打了个盹,从Sniffer上面看出一点儿端倪来,但还需要通过再次测试证实,一个小时以后再说吧。谢谢关心。

        • 谢谢
          家园 还有,在那个数据源头上想想办法。首次可能大些,后面可否用差分?
    • 家园 据分析,该兵部尚书乃户部尚书
分页树展主题 · 全看首页 上页
/ 11
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河