Muduo 網(wǎng)絡(luò)編程示例之五： 測量兩臺機器的網(wǎng)絡(luò)延遲
陳碩 (giantchen_AT_gmail)
Blog.csdn.net/Solstice t.sina.com.cn/giantchen
這是《Muduo 網(wǎng)絡(luò)編程示例》系列的第五篇文章。
Muduo 全系列文章列表： http://blog.csdn.net/Solstice/category/779646.aspx
本文介紹一個簡單的網(wǎng)絡(luò)程序 roundtrip，用于測量兩臺機器之間的網(wǎng)絡(luò)延遲，即“往返時間 / round trip time / RTT”。這篇文章主要考察定長 TCP 消息的分包，TCP_NODELAY 的作用。
本文的代碼見 http://code.google.com/p/muduo/source/browse/trunk/examples/roundtrip/roundtrip.cc
測量 RTT 的辦法很簡單：
- host A 發(fā)一條消息給 host B，其中包含 host A 發(fā)送消息的本地時間
- host B 收到之后立刻把消息 echo 回 host A
- host A 收到消息之后，用當(dāng)前時間減去消息中的時間就得到了 RTT。
NTP 協(xié)議的工作原理與之類似，不過，除了測量 RTT，NTP 還需要知道兩臺機器之間的時間差 (clock offset)，這樣才能校準(zhǔn)時間。
以上是 NTP 協(xié)議收發(fā)消息的協(xié)議，RTT = (T4-T1) – (T3-T2)，時間差 = ((T4+T1)-(T2+T3))/2。NTP 的要求是往返路徑上的單程延遲要盡量相等，這樣才能減少系統(tǒng)誤差。偶然誤差由單程延遲的不確定性決定。
在我設(shè)計的 roundtrip 示例程序中，協(xié)議有所簡化：
簡化之后的協(xié)議少取一次時間，因為 server 收到消息之后立刻發(fā)送回 client，耗時很少（若干微秒），基本不影響最終結(jié)果。
我設(shè)計的消息格式是 16 字節(jié)定長消息：
T1 和 T2 都是 muduo::Timestamp，一個 int64_t，表示從 Epoch 到現(xiàn)在的微秒數(shù)。
為了讓消息的單程往返時間接近，server 和 client 發(fā)送的消息都是 16 bytes，這樣做到對稱。
由于是定長消息，可以不必使用 codec，在 message callback 中直接用
while (buffer->readableBytes() >= frameLen) { ... } 就能 decode。
請讀者思考，如果把 while 換成 if 會有什么后果？
client 程序以 200ms 為間隔發(fā)送消息，在收到消息之后打印 RTT 和 clock offset。一次運作實例如下：
這個例子中，client 和 server 的時鐘不是完全對準(zhǔn)的，server 的時間快了 850 us，用 roundtrip 程序能測量出這個時間差。有了這個時間差就能校正分布式系統(tǒng)中測量得到的消息延遲。
比方說以上圖為例，server 在它本地 1.235000 時刻發(fā)送了一條消息，client 在它本地 1.234300 收到這條消息，直接計算的話延遲是 –700us。這個結(jié)果肯定是錯的，因為 server 和 client 不在一個時鐘域（這是數(shù)字電路中的概念），它們的時間直接相減無意義。如果我們已經(jīng)測量得到 server 比 client 快 850us，那么做用這個數(shù)據(jù)一次校正： -700+850 = 150us，這個結(jié)果就比較符合實際了。當(dāng)然，在實際應(yīng)用中，clock offset 要經(jīng)過一個低通濾波才能使用，不然偶然性太大。
請讀者思考，為什么不能直接以 RTT/2 作為兩天機器之間收發(fā)消息的單程延遲？
這個程序在局域網(wǎng)中使用沒有問題，如果在廣域網(wǎng)上使用，而且 RTT 大于 200ms，那么受 Nagle 算法影響，測量結(jié)果是錯誤的（具體分析留作練習(xí)，這能測試對 Nagle 的理解），這時候我們需要設(shè)置 TCP_NODELAY 參數(shù)，讓程序在廣域網(wǎng)上也能正常工作。