RTS/CTS 交握
/ request-to-send / clear-to-send /
RTS/CTS 是 Wi-Fi 在送出一大塊資料前可以採用的一個「先問再說」的有禮小儀式，目的是讓兩台彼此隱藏的站台不會把接收端打成一團糟。想像一場吵雜的會議，有些人隔著桌子聽不到對方。在開始長篇發言前，你說「我想要發言權」；主席宣布「卡爾擁有發言權兩分鐘」——現在所有人，連聽不到卡爾的人，都知道要保持安靜。這正是這個招數。
機制一步一步來：有資料要送的站台先傳出一個簡短的 RTS（Request To Send，請求傳送）訊框，說明它需要佔用通道多久。存取點以一個 CTS（Clear To Send，允許傳送）訊框回覆，覆述那段時長。因為 CTS 來自 AP，AP 範圍內的每個人都聽得到——包含聽不到原始發送端的那些站台（也就是隱藏節點）。那些站台讀到宣告的時長，設定一個網路配置向量（network allocation vector），在這段倒數期間克制不傳送。要等這個預約完成，真正的資料訊框才送出，後面再跟著 AP 的確認。這有時被稱為虛擬載波偵測：站台是根據「聽到的宣告」而非僅僅「偵測到能量」來退讓。
為什麼重要：RTS/CTS 直接對付隱藏節點問題，而這是單純的 CSMA/CA 無法完全解決的。但它不是免費的——現在每次交換都多花兩個小訊框，所以在沒有隱藏節點時，它反而降低吞吐量。因此 Wi-Fi 通常選擇性地套用它：只對大於某個可設定門檻的訊框，或在偵測到隱藏節點時才用。一個常見誤解是 RTS/CTS 能讓碰撞變成不可能；它只是讓碰撞變得不太可能，而且即使真的發生，代價也小得多（撞掉的是一個小小的 RTS，而不是一個大資料訊框）。
站台 A 和站台 C 在倉庫的兩端、彼此聽不到，但兩者都連得到 AP。開啟 RTS/CTS 後，A 送出 RTS、AP 廣播 CTS，C 聽到了就等待——於是 A 的大資料訊框完好抵達 AP，而不會和 C 的撞在一起。
AP 的 CTS 連對隱藏站台都能預約住空中時間。
在多數 Wi-Fi 上，RTS/CTS 預設是關閉或設了門檻限制，正是因為在沒有隱藏節點時，它的額外負擔弊大於利。它是針對特定問題的對症工具，不是一個永遠開著就更好的功能。