分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow

也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！

在TCP選項欄位中為TCP預留有時間戳功能，不管在網路層面還是應用層面，TCP時間戳往往被大家認為是一個系統行為，並忽略其存在。其實在某些環境下，TCP時間戳同樣可以成為大家在時延問題troubleshooting定位時的一個利器。

首先，讓我們先來回顧一下TCP時間戳的理論知識。

1） TCP時間戳位於TCP選項中，kind=8；lenth=10；data由timestamp和timestamp echo兩個值組成，各4個位元組的長度。

2） TCP時間戳理論作用有3個：序列號迴繞，亂序的時間判斷依據，避免確認二義性，以及計算RTT。

3） TCP時間戳工作方式：雙方各自維護自己的時間戳，時間戳的值隨時間單調遞增（規定為1ms-1s/次，常見值為1ms、10ms）。本端傳送timesstamp值，對方收到後在後續的ACK的timestamp echo迴應本端的值，並在timestamp中傳送自己的時間戳。TCP記錄傳送時間戳和收到迴應的時間, 從而獲得RTT。

如圖，裝置A發出首個請求為a2時刻，然後裝置B回覆ACK將a2放入時間戳回顯中，裝置A在收到這個回顯後結合當前自己的時間戳就可以計算出RTT。

回顧完理論概念後，我們來例項看下TCP時間戳在定位中所起的作用。

某使用者系統出現數據庫響應資料延遲較高的問題，在該使用者環境中伺服器和資料庫間存在幾個帶FW模組的網路裝置，但由於資源及流程問題，使用者只部署了一個捕獲點。

鏈路如下：Server——6509-1——6509-2——DB，使用者在65上span了一份資料。

首先，先從報文中確認延遲包取樣的位置。

我們取樣第19號包，延遲為0.45秒，顯然也不是應用響應延遲（這是連續的響應資料的第二個包）。產生問題的可能性有兩種，一是伺服器的TCPIP協議棧問題，二是網路導致的問題。從單點的問題來看暫時無法判斷，我們可以選擇再部署一個新的捕獲點或移動捕獲點到伺服器側來確認這樣的問題。

在這個報文我們發現是具有TCP時間戳選項的，這是一個非常有利的要素，這表示我們未必需要再部署新捕獲點了。

在獲得時間戳前，我們先來確認兩點。

一是真實的網路延遲情況，可以通過三次握手時間得到，根據三次握手，可以看到網路時間延遲在1ms級別左右，非常小。

二是伺服器方TCP時間戳增加一次的大致時間，通過5、6兩個包的間隔為110ms，而5號包TCP時間戳為8209278，6號包為8209289，可以得到應該為10ms。

接下來，通過sniffer、dali、wireshark等工具我們可以輕鬆地獲取前後的TCP時間戳，我們可以用下表來展示。

下面，我們來解讀下這些資料。

1） 根據時間戳回顯來看，在資料庫發出第19號包時，還沒有收到第18號ACK。而實際19和17號包到達捕獲點的間隔時間遠大於三次握手時得到的RTT。

2） 看20、21號包的時間戳回顯結果。結合捕獲點獲得的延遲間隔。顯然19號包在到達捕獲點後，很快就被伺服器接收到。

3） 回到17號和19號間的發包間隔時間。兩者的時間戳數值相隔為（8209341-8209289）=52。而根據捕獲點獲得的delta延遲2個包的間隔為（0.039+0.476）s=515ms。 根據之前得到的10ms/次的時間戳遞增速度，可以得到網路上所看到的延遲，和實際在資料庫發出資料包時就已經體現在時間戳上的基本一致，這樣我們就可以排除網路延遲的可能性。

這樣就可以避免再布點的麻煩，以提高問題點位置的定位效率。

最後，介紹下常見系統的TCP時間戳開關。

1）centos（Linux）

檢視預設值的方法：[[email protected] ~]# cat /proc/sys/net/ipv4/tcp_timestamps

0表示關閉，1表示開啟。

修改該值的方法：vim /etc/sysctl.conf 新增 net.ipv4.tcp_timestamps=0 or 1

2）Windows 修改登錄檔，查詢 “Tcp1323Opts”

(HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\Tcpip\Parameters下)

Tcp1323Opts

說明：該引數控制 RFC 1323 時間戳與視窗縮放選項。預設情況下，啟用時間戳與視窗縮放，但是可以使用標誌位進行控制。0 位控制視窗縮放，1 位控制時間戳。

值為0（禁用 RFC 1323 選項）

值為1（僅啟用視窗縮放）

值為2（僅啟用時間戳）

值為3（兩個選項均啟用）

給我老師的人工智慧教程打call！http://blog.csdn.net/jiangjunshow