第 15 章：TDLS（隧道直连建立）— 同一公司里抄条内线

Posted on Edited on In , Symbols count in article: 11k Reading time ≈ 10 mins.

"我们明明是同一家公司的同事，发份文件却要先送到前台、再由前台转给你。既然工位就在隔壁，何不拉条桌对桌的内线？"

本章导读

上一章的 Wi-Fi Direct，讲的是 "没有 AP 的直连 "——两台陌生设备临时组队，其中一台扮演 AP。但还有一类很常见的场景：两台设备本来就连在同一个 AP 上（比如同一间办公室、同一个家庭 Wi-Fi 里的笔记本和无线投影、手机和智能电视）。

这时它俩要互传数据，按传统 BSS 的规矩得经 AP 中转两跳：设备 A →（上行）AP →（下行）设备 B。哪怕 A、B 近在咫尺、AP 在另一个房间，数据也得先绕一圈。这显然浪费——既占了 AP 的空口时间，又凭空多了一跳延迟。

TDLS（Tunneled Direct Link Setup，隧道直连建立） 就是来解决这件事的：让两台关联在同一个 AP 上的设备，在彼此之间建立一条直连链路（direct link），数据直接点对点传，不再经 AP 中转。 关键在于——它俩仍然是这个 AP 的关联客户端，只是日常数据抄了条近路。

你可以把这件事想成：你和同事都是同一家公司的员工（都关联同一个 AP）。本来给他递文件要走前台收发室（AP）：你交给前台，前台再转交他。后来发现两人工位就在隔壁，于是拉了一条桌对桌的内线（TDLS direct link），文件直接递过去，不再麻烦前台。但注意：你俩还是这家公司的员工——工牌没退、前台还在，只是私下沟通抄了近路。甚至有意思的是，第一次要搭这条内线，还得先通过前台牵个线（建立信令经 AP 转发），这正是 "隧道（Tunneled）" 二字的由来。

这一章会沿着下面这条线索展开：

  • 为什么同一 AP 下的两台设备值得建直连：省一跳、提速、减 AP 负载
  • TDLS 与 P2P 的根本区别：仍关联 AP vs 彻底不要 AP
  • "隧道" 的含义：建立信令如何封装成普通数据帧、借道 AP 牵线
  • 发现与建立：Discovery 与 Setup 三帧握手（含 "能建几条"" 隐藏节点怎么办 "）
  • 安全：TPK（TDLS PeerKey）握手——其实就藏在 Setup 三帧里
  • 信道切换：直连如何切到比 AP 更空闲的信道提速
  • 省电：TPU 与 TDLS peer PSM

本章所有技术结论基于 80211-2024.pdf（IEEE Std 802.11-2024）的 Clause 11.20（Tunneled direct-link setup） 及 Clause 9（帧格式），并标注对应章节。TDLS 是 IEEE 802.11 标准内的机制（最初由 802.11z-2010 修正案引入，现已并入基准标准），不属于 Wi-Fi 联盟规范。

1 为什么要 TDLS — 同一个 AP 下，何必绕一圈

在传统的基础设施 BSS 里，所有非 AP STA 之间的通信都要经 AP 中转。两台 STA 即使物理上挨得很近，A 要发数据给 B，也必须：

1
A --(上行)--> AP --(下行)--> B     （两跳，占用两份空口时间）

这套规矩保证了 AP 对网络的集中管理，但代价明显：

  • 多一跳延迟：每帧都要在 AP 排队、转发一次。
  • 占用双倍空口：同一份数据在空中传了两遍（A→AP、AP→B）。
  • 受限于 AP 能力：AP 的工作信道、带宽、负载都成了 A↔B 之间的瓶颈。

TDLS 的思路很直接：A 和 B 之间直接建一条链路，数据走直连：

1
A <==(direct link, 一跳)==> B     （仍各自关联 AP）

TDLS 直连旁路 vs 经 AP 中转

和上一章的 Wi-Fi Direct 相比，TDLS 与它都实现 "设备直连"，但出发点截然不同——

  • Wi-Fi Direct（P2P）：没有 AP，其中一台设备临时扮演 AP（GO）。
  • TDLS：有 AP，而且双方继续关联着它——"STAs that set up a TDLS direct link remain associated with the AP and transmit frames directly to the other TDLS peer STA"（§4.3.21）。TDLS 只是在已有的 BSS 之上，给两台 STA 加开一条点对点捷径。

用前台的比喻说：P2P 是 "荒郊野外没有公司，两个自由职业者临时组个工作室"；TDLS 是 "同一家公司的两名在职员工，私下拉了条工位间的内线"。前者根本没有前台，后者前台一直都在。

2 角色与 "隧道" — 为什么直连的信令要借道 AP

2.1 两个角色

TDLS 链路由两台 STA 构成，按谁发起来区分角色（§11.20）：

角色全称说明
TDLS initiator STA发起方发送 TDLS Setup Request 帧或 TDLS Discovery Request 帧的一方
TDLS responder STA响应方接收并回应的一方

两者都必须是同一个 BSS 内、关联到同一个 AP 的非 AP STA。

2.2 "隧道" 二字的精髓：信令封装成数据帧，借道 AP

TDLS 最巧妙、也最容易被忽视的设计在这里：建立一条直连，靠的却是先经 AP 转发的信令。

TDLS 的控制信令（发现、建立、拆除等）并不是普通的 802.11 管理帧，而是被封装进一种特殊的数据帧——TDLS frame：它把一个 TDLS Action field 装进 MSDU，用专门的 EtherType 89-0d 标识（§11.20.2、Annex H）。

这样做的好处是：这些信令对 AP 而言就是普通的数据帧，AP 无需理解 TDLS 就能照常转发（AP 只中转数据帧，不会替两台 STA 中转 Action 管理帧——这也是信令非用数据帧不可的原因之一）。于是 TDLS 的建立信令可以沿着已有的 BSS 数据通路——经 AP 中转——送达对端。这就是 "Tunneled（隧道）" 的含义：直连建立的请求，像穿过一条隧道一样，借道 AP 这条现成的路先递过去。

这里先记住 "信令借道 AP" 这个形式；至于为什么非借 AP 不可（而不像发现阶段那样直连发），根子在密钥协商的安全要求——留到 §15.4 建立环节细讲。

由此引出 TDLS 里的两个关键路径概念：

路径英文含义
AP 路径AP path两台 TDLS peer STA 经 AP 中转的路径（§11.20.1 定义）
直连路径direct path两台 STA 建立直连后点对点直传的路径

回到工位内线的比喻：你想和隔壁同事拉内线，可第一次 "牵线" 的请求条子，还是得先交给前台（AP path）转交给他——因为你俩此刻还只认识 "通过前台联系" 这一条路。等内线接通了，以后说话才走直连（direct path）。所以 "隧道" 不是说数据走隧道，而是说搭线的信令借了 AP 这条隧道。

3 发现 — 对方支持 TDLS 吗？

建直连前，发起方得先确认对端也支持 TDLS。这通过 TDLS Discovery（发现） 完成（§11.20.2）：

帧路径说明
TDLS Discovery Request经 AP（AP path）发起方封装成数据帧，借道 AP 送给目标 STA
TDLS Discovery Response直连（不经 AP）响应方直接回给发起方，以此证明 "我能直连，且支持 TDLS"

注意这个精巧的不对称设计：请求经 AP 发出，响应却直接回。响应帧能否直达，本身就验证了两台 STA 之间确实存在可用的直连路径。

注意：TDLS Discovery Request / Response 帧都不可发往组地址（组播 / 广播），必须是单播（§11.20.2）。

此外，同 BSS 内还可以用 TDLS Capability ANQP-element（通过 GAS 查询）来发现对端是否支持 TDLS（§11.22）——这是一种可选的替代发现机制。

3.1 能建几条直连？

一台设备能同时建立多条 TDLS 直连吗？能。 规范明说："A TDLS peer STA may be involved in direct links with multiple TDLS peer STAs at the same time."（§11.20.1）。也就是说，一台 STA 可以同时和好几个对端各拉一条直连——比如一台笔记本同时与无线投影、无线打印机、另一台电脑都建着直连。每条链路是独立的一对关系：各自有独立的 TPK 密钥、独立的发现/建立/拆除过程，互不影响。

接着用内线打比方：你工位上可以同时接好几条内线——一条通设计部、一条通测试部。每条线各有各的暗语（TPK），各拉各的、各拆各的，互不干扰。前提是你（和每个对端）都还是公司在职员工（仍关联同一 AP）。

注意：多条直连各自的信道选择受一些约束，例如一台 STA 不能让两条直连（或直连与 BSS）用相同的主 80 MHz 信道却配不同的次 80 MHz 信道（§11.20.1）。但 "能同时建多条" 这个结论是明确的。

3.2 隐藏节点怎么办？

如果两台设备互为隐藏节点（彼此收不到对方的信号），还会发起 TDLS 吗？这正是 §15.3 那个不对称设计要解决的问题。回顾一下：Discovery Request 经 AP 送达，但 Discovery Response 必须走直连直接回。两台互为隐藏节点的 STA，虽然都连着同一个 AP（各自和 AP 都通），但彼此之间没有可用的直连路径——

  • A 的 Discovery Request 能经 AP 转交给 B（这一步没问题，走的是各自与 AP 的链路）；
  • 但 B 的 Discovery Response 要求直连回 A，而 A、B 互相收不到，这个响应根本到不了 A。

于是 A 收不到 Discovery Response，就判定 "此路不通"，不会再去发起 Setup。换句话说：发现阶段那条 "必须直连回" 的响应，正是一次直连可达性的探针——隐藏节点之间天然过不了这一关，TDLS 自然不会建起来。这也解释了为什么响应非要走直连而不经 AP：若响应也经 AP，就会误判 "能直连"，结果建了一条根本传不了数据的死链路。

即便侥幸建成后两台又移出了彼此射程，规范也有兜底：一方发现对端在直连上不可达时，会改用 经 AP 发送 TDLS Teardown，并带原因码 TDLS_TEARDOWN_PEER_UNREACHABLE 把这条死链路拆掉（§11.20.5）。

内线这个比喻还能解释隐藏节点：你想跟另一栋楼的人拉内线，先托前台把 "想接线" 的条子转过去了（Request 经 AP 没问题）。但接线规矩是——对方得直接拉一条线回你来确认（Response 走直连）。结果两栋楼之间根本没法直接布线，这条回线接不通，你就知道 "内线建不成"，老老实实继续走前台（经 AP 中转）。

4 建立 — 三帧握手

确认对端支持后，发起方启动 TDLS direct link 建立（§11.20.4）。这是一个三帧握手，且三帧都经 AP 转发（仍是 AP path）：

TDLS 直连建立时序

帧方向作用
TDLS Setup Requestinitiator → responder发起建立，携带能力信息（支持的速率、信道、HT/VHT/HE 能力、安全要求等）
TDLS Setup Responseresponder → initiator回应能力与状态（Status=0 表示接受）
TDLS Setup Confirminitiator → responder确认最终参数，握手完成，直连可用

三帧交换成功后，A、B 之间的 direct link 即告建立，此后双方的数据帧就走直连路径、不再经 AP。

4.1 为什么这三帧非得经 AP？根子在密钥

这是个很容易答错的问题（包括 "因为直连还没建成" 这种似是而非的说法——其实发现阶段的 Discovery Response 已经直连发过帧了，物理上明明通）。真正的主因是安全：加密 TDLS 的密钥协商，要求保护好这三帧里的 nonce。

把因果链摆开（§12.7.8）：

  1. 加密的直连要先协商出专用密钥 TPK，而 TPK 是用两端交换的 nonce（SNonce / ANonce） 推导出来的——这对 nonce 就明文装在 Setup 三帧里。
  2. 安全假设（§12.7.8.3）要求：这对 nonce 必须在一条已经加密的通道上交换，否则旁人抓到 nonce 就能自己算出同一个 TPK，直连加密形同虚设。
  3. 建立前，两端之间唯一已经加密好的通道，就是它们各自与 AP 的链路（关联时 四次握手得到的密钥）。让 Setup 帧经 AP 走，A→AP 段、AP→B 段分别被各自与 AP 的密钥罩着，nonce 全程在密文里，旁人抓不到。
  4. 而要借这条 AP 链路，信令就必须做成数据帧——因为 AP 只在两个 STA 之间中转数据帧，不中转 Action 管理帧（这也正是 §15.2.2 说的 "封装成数据帧" 的由来）。

所以 "经 AP + 数据帧" 不是图省事，是密钥协商的安全模型逼出来的。 顺带两个常被误当主因的因素，其实只是附带好处：① 对端可能正对 AP 休眠，AP 能缓存等它醒（可达性加成）；② 用数据帧让 AP 无脑转发，不挑 AP、老路由器都能用（部署性加成）。但根上不可绕过的那条，是 nonce 必须躲在已加密的 AP 链路里走。

那为什么 Discovery Response 能直连发？因为它是管理帧、且只是 "我醒着、单向证明一下直连通"，不涉及任何要保密的密钥材料——没有 nonce 要保护，自然不必借 AP 的加密。一旦轮到要协商 TPK 的 Setup，就绕不开 AP 了。

用内线的比喻串起来：搭内线要走三步——你递条子 "想接内线"（Setup Request），他回 "行，参数如下"（Setup Response），你再确认 "成交"（Setup Confirm）。这三句为什么非得托前台带？因为里头夹着用来定通话暗语的关键数字（nonce），当众喊出来就泄密了；而你和前台、他和前台之间各有一条已经保密的专线，托前台带就能让这串数字全程不外泄。等暗语定好、内线接通，以后才直接通话。

5 安全 — TPK 握手

直连链路上的数据也需要保护。TDLS 用一套独立于 AP 的密钥机制：TPK（TDLS PeerKey）握手（§11.20）。

  • TPK 握手在两台 peer STA 之间协商出一对临时密钥，提供数据机密性与消息完整性 / 认证——"TDLS allows STAs to use the TDLS PeerKey (TPK) handshake to provide data confidentiality and message authentication"（§4.3.21）。
  • 算出来的密钥与 STA 各自和 AP 之间的 RSNA 无关：直连是 A↔B 之间的私密通道，TPK 只有 A、B 知道；AP 虽经手 nonce、技术上能推 TPK，但规范假设它不偷用（§12.7.8.3 专门假设 AP 不会拿 nonce 去推 TPK）。
  • 但协商这把密钥的过程，恰恰要借 AP 链路的加密来保护——这点别和上一条搞混：结果（TPK）独立于 AP，过程（交换 nonce 的那三帧）却必须躲在两端各自与 AP 的加密链路里走，否则 nonce 一泄，TPK 就被旁人算走了。这正是 §15.4 讲的 "三帧为何经 AP" 的根。所以前提是双方都已与 AP 建立 RSNA（§12.7.8.1：STA-AP 链路加密时，TDLS 直连强制先跑 TPK；§11.20.1：安全仅在两端都与 BSS 有 RSNA 时可用）。
  • 它不是独立的 "第四步"：TPK 握手的三条消息 M1 / M2 / M3，分别搭在上一节的 Setup Request / Response / Confirm 三帧里一起发（§12.7.8.2）。所以 "建立" 和 "安全" 其实是同一次三帧握手完成的——把它单列一节，只是为了讲清密钥从哪来。

还拿内线打比方：你和同事的内线通话，用的是你俩之间约定的暗语，跟你各自向前台报到时用的口令是两码事——内线是私密专线，理应有自己的密码。

5.1 TPK 是怎么生成的？

规范（§12.7.8.2）把 TPK 的生成定义得很干净：两端各扔一个随机数 → 揉成种子 → 派生出密钥 → 切成两半各司其职。

输入：两个 nonce。 握手三帧里，两端各自甩出一个 256-bit 随机数（nonce）：

nonce由谁生成装在哪帧
SNonceinitiator（发起方）Setup Request（M1）
ANonceresponder（响应方）Setup Response（M2）；M1 里置 0

第一步：把两个 nonce 揉成密钥种子。

1
TPK-Key-Input = Hash( min(SNonce, ANonce) ‖ max(SNonce, ANonce) )

Hash 是随 AKM（认证套件）而定的哈希（如 SHA-256）。这里的 min/max 排序是点睛之笔：无论谁是发起方，两端都把两个 nonce 按大小排序后再拼接，保证 A 端和 B 端算出来的种子完全一致——否则一个算 S‖A、另一个算 A‖S，结果就对不上了。

第二步：用 KDF 派生出 TPK。

1
2
TPK = KDF-Hash-Length( TPK-Key-Input, "TDLS PMK",
                       min(MAC_I, MAC_R) ‖ max(MAC_I, MAC_R) ‖ BSSID )

KDF 是标准密钥派生函数，把种子拉伸到所需长度；标签固定为 "TDLS PMK"。上下文里绑了两端的 MAC 地址（同样 min/max 排序）和 BSSID——把密钥钉死在 "这两台设备、在这个 AP 下"：换个 AP 或换台设备，算出来就不是同一把了。

第三步：把 TPK 切成两半，各司其职。

组件取 TPK 的用途
TPK-KCK（Key Confirmation Key）前 128 bit给 Setup Response / Confirm 帧算 MIC，做消息来源认证（证明帧确来自持密钥的对端、没被篡改）
TPK-TK（Temporal Key）剩余 bit真正用来加密直连数据帧（机密性）

为什么这套设计安全： ① 新鲜性——每次握手都重新随机生成 nonce，每条直连的 TPK 都不同，挡重放；② 双方共决——TPK 同时由 S、A 两个 nonce 决定，谁也单方说了不算、谁也预测不了；③ 绑上下文——MAC + BSSID 进了派生，密钥锁死在 "这俩设备 + 这个 AP"。

这也正好回收了 §15.4 的命门：TPK 完全由那两个 nonce 推出，而 nonce 是明文装在 Setup 三帧里的——谁抓到这两个 nonce，就能照着上面的公式算出一模一样的 TPK。所以这三帧必须借两端各自与 AP 的加密链路（经 AP）来走，把 nonce 罩在密文里（§12.7.8.3）。"为什么经 AP" 的答案，就埋在这条推导公式里。

用内线比喻来理解这套派生：定暗语的办法是——你和同事各报一个随机数字，然后都按 "小的在前、大的在后" 拼起来（min/max 排序，保证两人拼出的一样），再混进你俩的工牌号和公司编号（MAC + BSSID）一起搅成最终暗语。这暗语只认你俩、只在这家公司有效。但关键是：那两个随机数字本身是明着报的，所以报数字这一步必须走保密专线（经 AP），否则旁人听了去，也能拼出同一套暗语。

6 信道切换 — 抄近路还能换条更快的道

这是 TDLS 一个容易被低估的增强能力：off-channel TDLS（离信道直连）。

默认情况下，TDLS 直连工作在 AP 的当前信道（base channel）上。但 AP 的信道可能很拥挤（一堆设备都挂在上面），或带宽受限。TDLS Channel Switching（§11.20.6）允许已建立直连的两台 STA，协商切换到另一个对它俩更优的信道——比如一个更空闲的 5 GHz 信道、或更宽的带宽——从而获得远高于 base channel 的吞吐。

  • STA 通过 Extended Capabilities 里的 TDLS Channel Switching 位声明支持此能力（对应 MIB dot11TDLSChannelSwitchingActivated，§9 / §11.20.6）。
  • 协商本身走直连：想切换的一方发 TDLS Channel Switch Request，指明目标信道与工作类别；对端回 TDLS Channel Switch Response，带 SUCCESS 或 REQUEST_DECLINED 状态码。发 Request 或带 SUCCESS 的 Response 前，该 STA 须先与 AP 进入 PS 模式、且不处于 active SP（§11.20.6）。双方均可发起切换；若同意，双方须在 SwitchTime 之前切到目标信道。若 SwitchTimeout 内新信道无成功交互，则自动退回 base channel（§11.20.6）。
  • 切换是临时的、可回切的：两台 STA 在约定的时段切到 off-channel 直传，需要时再切回 base channel 与 AP 保持联系。

切到目标信道后，每台 peer STA 先要在新信道上做一段 CCA，直到收到一个能据此设置 NAV 的帧、或 dot11TDLSNavSync 计时结束——规范把这段静默监听叫作 ProbeTime（§11.20.6）。三个计时器先后是：SwitchTime 是切到新信道的截止时刻，切完先过 ProbeTime 静默监听，退避后发首帧（不得早于 SwitchTime 结束），SwitchTimeout 则是新信道迟迟无成功交互时回退 base channel 的上限（§11.20.6）。这跟 (I) BSS 信道切换（§11.8.8） 是两码事：后者由 AP 单方拍板、用 Channel Switch Announcement 广播给整个 BSS 一起搬家；TDLS 则只是两台 peer 私下协商，只挪它俩的直连，AP 和 BSS 都原地不动。另外，想切到的 off-channel 若是需雷达检测（DFS）的信道，发起方还须先按法规测过该信道无雷达，才能发 Switch Request（§11.20.6.2）。

内线比喻同样覆盖这里：内线接通后，你俩发现公司公共线路（AP 信道）太吵，于是临时约好 "咱换到顶楼那间没人用的安静会议室（off-channel）聊"，效率更高；聊完再回到工位，免得错过前台的通知。

7 省电 — 直连两端怎么打盹

直连建好后，两台 peer STA 之间也需要省电机制（总不能为了一条直连一直满功率守着）。TDLS 提供两套（§11.20 / §4.3.21）：

机制全称思路
TPUTDLS peer U-APSD（TDLS peer unscheduled automatic power save delivery）复用 U-APSD 的 "非调度" 思路：有数据要发时再触发对端投递，平时可休眠
TDLS peer PSMTDLS peer power save mode基于周期性调度的服务期（SP，Service Period）：双方约定固定的醒来时段收发，其余时间睡觉

两者都让直连的两端不必一直清醒，从而省电。

内线比喻同样适用：内线两头不必 24 小时都守着听筒——要么 "有事才响铃、响了才接"（TPU），要么 "约定每天几点准时通话、其余时间各自挂机休息"（peer PSM）。

8 拆除与完整流程串讲

当不再需要直连（数据传完、一方要离开、或链路质量太差），任一方可发送 TDLS Teardown 帧拆除直连。拆除后，两台 STA 依旧关联在 AP 上，只是回到 "数据经 AP 中转" 的老路——内线撤了，前台还在。

把全章串起来，同一 Wi-Fi 下两台设备建直连传数据的逐帧过程如下图——这也是用 Wireshark 实际抓包会看到的序列：

TDLS 完整帧交互

读图要点：信令分两种路径——蓝 / 靛色帧经 AP 转发（AP path，封装在 EtherType 89-0d 的数据帧里，RA=BSSID），红色帧走直连（direct path，RA = 对端 MAC）。注意 Discovery Request 经 AP、Discovery Response 却直连回：响应能直达，本身就验证了直连可用。TPK 握手不是独立的一步，它的 M1/M2/M3 分别搭车在 Setup Request/Response/Confirm 三帧里（§12.7.8）。全程 A、B 始终是 AP 的关联客户端。

上面的时序图是抓包视角的逐帧全貌；把它按阶段压缩成一条主线，就是下面这五步——每一行对应前面某一节讲过的机制，对照着读能快速锁定 "这一步到底在做什么"：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
0. 前提     A 和 B 都已关联到同一个 AP（各自跑过与 AP 的关联+四次握手）
                  |
1. 发现     A 发 TDLS Discovery Request（经 AP 转发给 B）
            B 直接回 TDLS Discovery Response（不经 AP）
            -> 证明 A、B 之间可直连，且都支持 TDLS
                  |
2. 建立     三帧握手（都经 AP）：
            Setup Request -> Setup Response -> Setup Confirm
            若需加密，TPK 握手 M1/M2/M3 就分别搭在这三帧里
            -> direct link 建成、专用密钥(TPK)就位
                  |
3. (可选)切信道  若 base channel 拥挤，协商切到更空闲的 off-channel
                  |
4. 传数据   A、B 数据走直连（direct path），一跳直达，不再经 AP
            空闲时用 TPU / peer PSM 省电
                  |
5. 拆除     TDLS Teardown 撤销直连；A、B 仍关联 AP，回到经 AP 中转

这五步走完，一条 TDLS 直连就完成了 "发现 → 建立 → 使用 → 拆除" 的完整生命周期——全程两台设备始终没退出 BSS，这也是它和 P2P 最本质的分野。下面这张总结表把每个机制与它的内线比喻一一对号，方便随时回来速查。

9 本章总结

机制作用内线比喻
仍关联 AP + 建直连同一 BSS 内两 STA 点对点直传，省一跳、减 AP 负载还是公司员工，私拉一条工位内线
TDLS frame（EtherType 89-0d）信令封装成数据帧，AP 无需懂 TDLS 即可转发牵线的条子先托前台带
AP path / direct path建立期借道 AP / 建成后走直连先经前台 / 后走内线
Discovery（Req 经 AP，Resp 直连）确认对端支持且可直连；隐藏节点因 Resp 回不来而天然过不了关递条子问，对方直接回话验证
Setup 三帧握手Request → Response → Confirm 建直连想接内线 / 行 / 成交
TPK 握手（搭在 Setup 三帧里）直连专用密钥，独立于与 AP 的 RSNA；非独立第四步内线专属暗语
可同时建多条直连一台 STA 可与多个对端各建独立直连工位上同时接好几条内线
off-channel 信道切换切到比 AP 更空闲的信道提速换去安静会议室聊
TPU / peer PSM直连两端省电有事才接 / 约定时段通话
Teardown拆直连，回到经 AP 中转撤内线，前台还在

TDLS 的精髓是：在一个已有的 AP 网络之上，给两台关联客户端临时加开一条点对点直连捷径——数据走直连省掉了绕 AP 的那一跳，而建立这条捷径的信令，又巧妙地借道 AP 完成。 它和上一章的 Wi-Fi Direct 一起，构成了 "设备直连" 的两种思路：P2P 彻底抛开 AP，TDLS 则在 AP 之内抄近路。 也正因如此，下一章的 Miracast 投屏，既可以跑在 P2P 上，也可以跑在 TDLS 上。

下一章将讲述：有了设备直连（P2P 或 TDLS）这条 "无线的路"，手机投屏到电视的画面和声音是怎么协商、怎么传、怎么控的？Miracast 如何在直连之上搭起 "无线 HDMI"？RTSP 的 M1–M16 消息序列在协商什么？为什么能在大屏上反控手机（UIBC）？