往返時間（round-trip time）
如果你對著峽谷大喊，並計時到聽見自己回音為止，你就量到了一次往返：你的聲音傳出去、反射再傳回來所花的時間。在網路上，往返時間（round-trip time，RTT）是從傳送端發出一個封包，到它收到那個封包的確認為止的時間——一份資料與其回覆的去而復返延遲。
RTT 由好幾部分相加而成：傳播延遲（訊號實際走完這段距離要多久，受光速所限）、傳輸時間（把位元逐一打上線路要多久），以及沿途每個路由器、兩個方向上的佇列延遲與處理延遲。關鍵是，RTT 並非固定——當路由器變忙、緩衝區塞滿時，佇列延遲增加，RTT 便上升。TCP 藉由替自己的確認計時來持續量測 RTT，並保有一個平滑的滾動估計值（以及一個它變動多大的量度），因為它太多行為都是由 RTT 來決定節奏的。
RTT 重要，是因為它是 TCP 的心跳。吞吐量大約是壅塞視窗除以 RTT，所以對給定的視窗而言，長 RTT 直接限制了連線能跑多快。RTT 也決定了 TCP 反應的快慢：每次對壅塞視窗的調整都是每個往返一次，所以一條到地球另一端、RTT 200 毫秒的路徑，反應速度比 RTT 20 毫秒的本地路徑慢上十倍。而上升的 RTT 本身就是一種壅塞信號——這是 BBR 與 Vegas 這類延遲式控制器的基礎，它們在感覺到佇列（也因此 RTT）正在增長時就放慢，甚至在任何封包遺失之前。
從倫敦對雪梨一台伺服器做 ping，回報的 RTT 可能在 280 毫秒左右——其中大部分是純粹的傳播延遲，因為光在光纖中就是無法更快地橫越半個地球。對同一座城市裡的伺服器做 ping，可能回報 5 毫秒。替任一條連結增加頻寬都不會縮短那個 RTT；論距離，你贏不了光速。
RTT 主要由距離（傳播延遲）加上任何佇列所主導；更多頻寬並不會減少它。
一個常見的混淆：頻寬與 RTT 是互相獨立的。一條粗管子仍可能有很長的 RTT（衛星連結頻寬高但延遲極高），而增加頻寬永遠不會降低傳播延遲。TCP 的反應速度與其每視窗的尖峰吞吐量，都受 RTT 所節制，而非受管子有多寬所節制。