時間戳選項發送方在每個報文段中放置一個時間戳值。接收方在確認中返回這個數值，從而允許發送方為每一個收到的ACK計算RTT（我們必須說“每一個收到的ACK”而不是“每一個收到的報文段”，是因為TCP通常用一個ACK來確認多個報文段）。我們提到過目前很多實現為每個窗口值計算一個RTT，對於包含8個報文段的窗口而言這是正確的。然而，較大的窗口大小則需要進行更好的RTT計算；
時間戳是一個單調遞增的值。由於接收方只需要回顯收到的內容，因此不需要關注時間戳單元是什么。這個選項不需要再兩個主機之間進行任何形式的時鍾同步。RFC1323推薦在1毫秒和1秒之間將時間戳的值增加1；
在連接建立階段，對於這個選項的規定與擴大窗口選項類似。主動發起連接的一方在它的SYN選項中指定選項。只有在從另一方的SYN中收到這個選項后，該選項才會在以后的報文段中進行設置；
接收方TCP不需要對每個包含數據的報文段進行確認，許多實現每兩個報文段發送一個ACK。如果接收方發送了一個確認了兩個報文段的ACK，那么哪一個收到的時間戳應當放入回顯應答字段中發回去呢？
為了減少任異端所維持的狀態數量，對於每個連接只保持一個時間戳的數值，選擇何時更新這個數值的算法非常簡單：
(1) TCP跟蹤下一個ACK中將要發送的時間戳值(tsrecent變量)以及最后發送的ACK中的確認序號(lastack變量)。這個序號就是接收方期望的序號；
(2) 當一個包含字節號lastack的報文段到達時，該報文段中的時間戳被保存在tsrecent中。
(3) 無論何時發送一個時間戳選項，tsrecent就作為時間戳回顯應答字段被發送，而序號字段被保存在lastack中；
這個算法能夠處理下面兩種情況：
(1) 如果ACK被接收方延遲，則作為回顯值的時間戳值應該對應於最早被確認的報文段。
例如：如果兩個包含1-1024和1025-2048的的報文段到達，每一個都帶有一個時間戳選項，接收方產生一個ACK2049來對它們進行確認。此時，ACK中的時間戳應該是包含字節1-1024的第一個報文段的時間戳。這種處理是正確的，因為發送方在進行重傳超時時間的計算時，必須將延遲的ACK也考慮在內；
(2) 如果一個收到的報文段雖然在窗口范圍內但同時又是失序，這就表明前面的報文段已經丟失。那個丟失的報文段到達時，它的時間戳(而不是失序的報文段的時間戳)將被回顯。
例如：假定有3個各包含1024字節的報文段，按如下順序接收：1-1024的報文段1，2049-3072的報文段2，1025-2048的報文段2。返回ACK應該是帶有報文段1時間戳的ACK1025（一個正常期望的對數據的ACK），帶有報文段1的時間戳的ACK1025（一個重復的，響應位於窗口內但卻是失序的報文段的ACK），然后是帶有報文段2的時間戳的ACK3037（不是報文段3中的時間戳）。這與當報文段丟失時的對RTT估算過高具有同樣的效果，但這比估計過低要好些。而且，如果最后的ACK含有來自報文段3的時間戳，它可以包括重復的ACK返回和報文段2被重傳所需的時間，或者可以包括發送方的報文段2的重傳定時器到期時間。無論哪一種情況下，回顯報文段3的時間戳都將引起發送方的RTT計算出現偏差；
時間戳除了能夠更好的計算RTT，還為發送發提供了一種方法，以避免接收到舊的報文段，錯誤的以為它們是現在數據的一部分；
文章來自: <TCP/IP詳解>