欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

上周在公司里遇到一個(gè)問(wèn)題，用wireshark抓系統給網(wǎng)管上報的數據發(fā)現里面有好多報文被標識為“TCP segment of a reassembled PDU”，并且每一段報文都是180Byte，當時(shí)看到這樣的標識，覺(jué)得是IP報文分片，以為系統的接口MTU值為設置小了，通過(guò)命令查詢(xún)發(fā)現是1500，沒(méi)有被重設過(guò)，當時(shí)有點(diǎn)想不通。

    回來(lái)查了一下，發(fā)現自己的理解是錯的，“TCP segment of a reassembled PDU”指的不是IP層的分片，IP分片在wireshark里用“Fragmented IP protocol”來(lái)標識。詳細查了一下，發(fā)現“TCP segment of a reassembled PDU”指TCP層收到上層大塊報文后分解成段后發(fā)出去。于是有個(gè)疑問(wèn)，TCP層完全可以把大段報文丟給IP層，讓IP層完成分段，為什么要在TCP層分呢？ 其實(shí)這個(gè)是由TCP的MSS(Maximum Segment Size，最大報文段長(cháng)度)決定的，TCP在發(fā)起連接的第一個(gè)報文的TCP頭里通過(guò)MSS這個(gè)可選項告知對方本端能夠接收的最大報文（當然，這個(gè)大小是TCP凈荷的大?。?，以太網(wǎng)上這個(gè)值一般設置成1460，因為1460Byte凈荷+20Byte TCP頭+20Byte IP頭 ＝ 1500字節，正好符合鏈路層最大報文的要求。

    至于收到一個(gè)報文后如何確定它是一個(gè)"TCP segment"？如果有幾個(gè)報文的ACK序號都一樣，并且這些報文的Sequence Number都不一樣，并且后一個(gè)Sequence Number為前一個(gè)Sequence Number加上前一個(gè)報文大小再加上1的話(huà)，肯定是TCP segment了，對于沒(méi)有ACK標志時(shí)，則無(wú)法判斷。

    既然收到的TCP報文都是180Byte的segment，那么應該是協(xié)商的時(shí)候PC端告知了MSS為180Byte，至于為什么這樣，只能等抓包后確認是MSS的問(wèn)題再排查了。另外，有一種情況也可能導致這個(gè)問(wèn)題：被測系統因為MTU為220Byte而設置MSS為180Byte，但是這種情況現在可以排除，因為前面講過(guò)，已經(jīng)查詢(xún)過(guò)MTU值為1500。

今天利用windows查找功能對網(wǎng)絡(luò )上的一個(gè)共享文件夾里的內容進(jìn)行查找，發(fā)現查找網(wǎng)絡(luò )文件時(shí)流量巨大。好奇用wireshark抓包發(fā)現wireshark Info欄里有很多“TCP segment of a reassembled PDU”提示信息。不解百度了一下發(fā)現大家都在詢(xún)問(wèn)這個(gè)問(wèn)題網(wǎng)上并沒(méi)有很好的解答。想到“TCP segment of a reassembled PDU”只是wireshark的提示信息，那么在sniffer pro里會(huì )給出什么樣的提示呢，用sniffer打開(kāi)同樣的trace 發(fā)現里面提示“Continuation of missing frame”和"Continuation of frame xx"現在大概知道“TCP segment of a reassembled PDU”是什么意思，其實(shí)主機響應一個(gè)查詢(xún)或者命令時(shí)如果要回應很多數據（信息）而這些數據超出了TCP的最大MSS時(shí)，主機會(huì )通過(guò)發(fā)送多個(gè)數據包來(lái)傳送這些數據（注意：這些包并未被分片）。對wireshark來(lái)說(shuō)這些對相應同一個(gè)查詢(xún)命令的數據包被標記了“TCP segment of a reassembled PDU”

問(wèn)題，wireshark如何識別多個(gè)數據包是對同一個(gè)查詢(xún)數據包的響應? wireshark是根據sequence number來(lái)識別，這些數據包ACK number是相同的，當然number的數值與查詢(xún)數據包中的next sequence number也是一樣的。

CIFS/SMB協(xié)議對待文件查詢(xún)效率多么的低下！對待一個(gè)文件名的查詢(xún)要用兩個(gè)幀長(cháng)1514字節和一個(gè)1294字節的幀長(cháng)來(lái)響應。

關(guān)于TCP/UDP與IP最大報文長(cháng)度的區別請見(jiàn)此文 

http://blog.163.com/hlz_2599/blog/static/142378474201341601129121/

本文來(lái)自CSDN博客，轉載請標明出處：http://blog.csdn.net/rossini23/archive/2010/03/28/5424850.aspx