情況 現在 src tcp協議 時間 .cn 關系 1.0 繼續

上次 提到的Nagle算法特性有可能是dubbo調用”網絡耗時高“的始作俑者，後來又仔細看了下dubbo的代碼，發現dubbo在consumer端已經將tcp設置成非延遲（即關閉Nagle特性）了，代碼片段如下：

order模塊中調用量最高的接口是查詢未完成訂單，調用量達到每10秒18000，如下：

但該接口在order這邊的平均耗時特別低（尖刺是由發布引起的，這裏忽略），才1毫秒：

該接口直接由kop來調用，我們看kop這邊的平均耗時：

可以看出，在低峰期，kop這邊的耗時和order的耗時是匹配的，1-2毫秒，但在高峰期，kop這邊的平均耗時高達13毫秒！

是否因為單TCP吞吐達到瓶頸？
[email protected]，在order這邊將該接口的TCP連接數設置成3（這裏需要註意，connections不能設置成1，設置成1還將繼續共用1條tcp連接，至少需要2或2以上），如下：
<dubbo:service interface="PassService"
ref="passService" connections="3"version="1.0.0" />
上線後的效果如下：

可以看出，在設置成3個單獨tcp連接後，網絡耗時再也不受高峰期影響，一直很平穩！！

如果不是Nagle算法導致的問題，那麽還有可能是其他什麽原因呢？

為了達到當前網絡條件下的最大吞吐量，TCP協議設計成自適應的（可以參看：https://segmentfault.com/a/1190000008803687），就是說如果網絡質量高的情況下，理論上單條TCP連接都能“占滿”整個帶寬。但tcp是基於可靠到達+順序保證的，所以每個發生著在發送tcp數據段後都需要收到接收者的ack後才認為數據已經發送成功，否則將定時重發一定次數。而為了增加吞吐量，tcp這邊提出了窗口的概念，窗口內的tcp數據段會一次性發送，而不需要等前一個段ack再發送另一個段，而tcp會根據網絡質量來逐漸增大窗口。

所以tcp發送數據的吞吐量可能如下幾個因素都有關（這裏只是分析，歡迎大夥一起糾正和補充）：
網絡帶寬。在我們線上機器是萬兆網卡，而且我們用dubbo做rpc都是小數據高頻傳輸，所以不存在帶寬被打滿的情況。
mss大小。每個分段中能發送的最大TCP數據量。
平均窗口大小。一旦網絡質量高，tcp的窗口將變得很大，否則窗口將縮小，直至達到當前網絡的合理值，當然窗口一直在不斷變化。
TCP緩沖區大小。緩沖區滿了發送將一定程度的阻塞。
平均重發次數。這也直接和網絡質量有關系。
不論是什麽原因，可以知道的是帶寬不是瓶頸，網絡質量也是靠譜的，所以瓶頸應該和TCP本身的設計相關，既然多條TCP連接能解決問題，現在所要做的就是如何發現業務中網絡耗時高的調用了。

於是我們對taxi-rpc和taxi-dubbo進行了升級（後面會單獨發郵件推廣），用來統計網絡耗時，計算公式：網絡耗時 = consumer處理耗時 – provider處理耗時，這裏先忽略服務器時間同步的影響。order和cos已經進行了升級，所以cos調用order的網絡耗時如下：

後期如果發現某些接口網絡耗時特別高，就很有可能是單個公共的tcp連接不夠用了，屆時可以對tcp連接的數量進行優化！

穩定性 耗時 監控原因分析-- dubbo rpc 框架 的線程池,io 連接模型. 客戶端,服務端