問題是一個java應用上的問題，因為這里是網路通信板塊，所以只描述具體的TCP問題，關于整個問題的描述及說明，參見java板塊的貼子：http://bbs.csdn.net/topics/392160230
問題：業務層請求呼叫緩慢，正常情況下毫秒級可以完成的呼叫在發生問題時幾分鐘可能都完不成
如下是有問題的報文，10.XX.XX.85代表服務端，10.XX.XX.55代表客戶端，一個是固定IP，一個是浮動IP，實際上是同一臺機器
針對該報文有以下現象或結論：
1.服務端的滑動視窗大小大小為16389（環境使用lo回路，MTU為16436，16436=16389+7+40）
2.客戶端向服務端下發了一個長度為16396的報文，但由于對方滑動視窗的限制被拆分為16389和7兩個報文。但從時間上看，每兩個16396報文之間間隔200MS左右。
如下是正常期間抓取的報文，從該報文中可以看出以下現象：
1.服務端的滑動視窗大小為16396，剛好同問題發生時報文未拆解大小一致（16389+7）
2.整個報文中長度大于10000的報文非常少，而在問題的報文中，非常多的16389報文
3.報文中沒有出現兩條報文間隔200MS的情況
咨詢：
1.如上分析200MS是導致請求延時的原因，分析是否正確
2.如果正確，哪些因素可能造成200MS的延時
uj5u.com熱心網友回復：
問題1:可以在發送端與接收端的程式代碼里輸出發送前與接收后的時間, 兩者相減看是否與200毫秒接近.問題2:可以發一個10000長度的報文, 看是否間隔時間變100毫秒,從而判斷延時是否與報文長度有關.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/118269.html
標籤：網絡協議與配置
上一篇：如何提高通信設備的自動化測驗
下一篇：H3C 實驗拓撲