同行交流（PEX）為 swarms（節點群）提供了一種替代的節點發現機制，節點通過 DHT 或 Tracker announces 等其他機制引導完成。
它提供了比大多數其他來源更為實時的 swarm 視圖，並且還減少了頻繁查詢其他來源的必要性。
與規範節點優先級結合使用時，它提供了一種快速隨機化 swarm 連接圖的方法。
協議擴展#
PEX 通過擴展協議引入新消息 ut_pex。
在握手中協商添加的消息：
{
m: {
ut_pex: <implementation-dependent local message ID (positive integer)>,
...
},
...
}
擴展消息本身由 BitTorrent / 擴展消息頭和隨後的 bencoded 編碼載荷組成：
{
added: <one or more contacts in IPv4 compact format (string)>
added.f: <optional, bit-flags, 1 byte per added IPv4 peer (string)>
added6: <one or more contacts IPv6 compact format (string)>,
added6.f: <optional, bit-flags, 1 byte per added IPv6 peer (string)>,
dropped: <one or more contacts in IPv6 compact format (string)>,
dropped6: <one or more contacts in IPv6 compact format (string)>
}
標誌定義如下：
| Bit | when set |
|---|---|
| 0x01 | 首選加密，如分機握手中的 e 字段所示 |
| 0x02 | 做種 / 僅上傳 |
| 0x04 | 支持 uTP |
| 0x08 | 節點指示 ut_holepunch 支持分機握手 |
| 0x10 | 傳出連接，節點可訪問 |
一個節點只有在成功建立連接後才能被包含在 “added” 字段中，當它斷開連接後則需要被包含在 “dropped” 字段中。一旦一個節點已經被添加，客戶端必須確保在適當的時候發送相應的 “dropped” 事件。僅僅向其他節點發出 “added” 信號而從未對其進行 “dropped” 的操作是不符合規範的行為。
原因一：PEX 旨在反映客戶端當前連接的節點，這確保了 PEX 提供比其他節點發現機制更好的實時信息。原因二：僅傳播經過驗證的節點可減少攻擊者濫用 BitTorrent swarms 進行分佈式拒絕服務攻擊的機會。
相互通信的客戶端應將其批量更新頻率限制為每分鐘一次 6。
不需要在握手後立即發送 PEX 消息，例如，在 torrent 啟動期間，客戶端可能會等到它建立足夠的連接以使發送的 PEX 消息變得有價值。
添加或刪除的聯繫人不得包含重複項。
只要不影響正確性，就可以在更新消息之間省略暫時性連接 - 斷開連接或斷開連接 - 重新連接事件。
實現說明：對於每個已連接的節點，一種簡單的方法是將其尚未發送的連接 / 斷開連接事件排隊，並在生成消息時忽略重複和瞬時連接。另外一種更加節省內存的方法是為每個 torrent 記錄連接 / 斷開連接事件的時間軸，並為每個節點存儲一個指針，指向已經發送的事件的時間點。在創建 PEX 消息時，只需推進指針，注意消除重複項並省略短暫連接即可。
在同一條消息中不應刪除已添加的聯繫人
除初始 PEX 消息外，添加的 ipv4/ipv6 聯繫人的總和不應超過 50 個項目。這同樣適用於刪除的項目。
消息必須包含以下至少一個字段：added, added6, dropped, dropped6。
客戶端可能會斷開嚴重違反這些約束的節點。
填充未充分利用的列表
含以下組合
- 應滿足的網絡連接要求
- 節點在做種時斷開與其他對等節點的連接
- 基於在 IPv4 和 IPv6 之間的相同節點 ID 斷開重複節點的連接
可能導致 added 或 added6 列表未充分利用。使用 PEX 協議可能會導致種子列表中出現過少的連接節點。如果一個種子節點沒有可以傳播的連接節點，而其他節點只有能夠傳播給其他種子節點的連接節點，那麼 PEX 的效果會被大幅降低，從而導致種子列表中的連接節點數量過少。在 IPv4 占主導地位的種子群中，也會遇到類似的問題，即獲取 IPv6 連接節點比較困難，因為 IPv6 連接節點會被視為已經建立的 IPv4 連接的重複，從而阻止它們通過 PEX 進行傳播。
為了解決這個問題，BitTorrent 協議指定了一個 “活動要求”，用於確定何時將連接視為非活動狀態並應終止。但是，在某些情況下，如果客戶端連接到特定地址系列（例如 IPv4 或 IPv6）的客戶端少於 25 個，則此活動性要求會放寬。相反，客戶端可以為該地址系列保留最多 25 個最近建立和完全握手的連接的列表，並記錄任何斷開連接的原因。這些原因將使遠程聯繫人有資格包含在 “added” 或 “added6” 列表中。這些列表可能是指給定地址系列的受信任或允許的遠程主機的列表。通過維護最近連接的列表並記錄斷開連接原因，客戶端可以更好地管理其連接，並確保它與網絡中可靠穩定的節點保持連接：
- 同一節點 ID 已在不同的地址系列下連接
- 兩個對等節點無法或不願意相互建立連接以交換共享文件片段的情況
- 本地資源限制，例如全局連接數已超過限制
PEX 消息在包含最近斷開連接的聯繫人時需要從 “最近已看到的列表” 中清除該聯繫人，以使其不會在下一條消息中再次發送。當列表通過短暫的連接 - 斷開事件重新填充時，如果所有必要條件都滿足，這些事件可能會包含在下一條消息中。換句話說，在從 “最近已看到的列表” 中填充初始 PEX 消息的同時，客戶端還可以跳過某些連接 - 斷開事件，這樣就能更有效地構建 PEX 消息。簡單來說，當一個節點與其他對等節點斷開連接後，它將被刪除並不再包括在該節點發送的下一條 PEX 消息中。但是，如果該節點重新連接到網絡並符合一定的條件，那麼它可能會再次出現在該節點的 PEX 消息中。此外，客戶端還可以跳過不必要的連接和斷開事件，以更有效地構建 PEX 消息。
最近看到的聯繫人並不一定是當前正在進行的連接，所以它們需要在下一條 PEX 消息中被刪除
在同一條 PEX 消息中不能同時添加和刪除相同地址的限制仍必須保留。
選擇少於 25 個活動連接和不超過 25 個最近看到的聯繫人的要求，為了確保最多只能累積兩條可丟棄聯繫人的 PEX 消息，並且只有在沒有足夠的活動聯繫人可以填充 PEX 消息時才會發送舊版信息。
請注意，這個豁免規則可以分別應用於 IPv4 和 IPv6。即使有足夠的 IPv4 活動連接，但如果 IPv6 相關的列表數量不足，客戶端仍可以在 PEX 消息中包含最近看到的 IPv6 聯繫人，反之亦然。
安全注意事項#
接收到的 PEX 消息應被視為不受信任且可能是惡意的 8
攻擊者可能會嘗試通過與其他節點協作向 swarm 發起虛假信息洪泛攻擊 9 等方式來破壞它。
PEX 還可以通過誘導 BitTorrent 客戶端對受害者 IP 範圍進行連接嘗試用於發起分佈式拒絕服務攻擊（DDoS），從而使這些 IP 地址的網絡流量骤增，造成網絡擁塞和服務不可用。
為了緩解這些問題，客戶端應該避免從單個 PEX 源獲取所有連接候選者。重複的 IP 地址（例如具有不同端口的 IP 地址）應該被忽略 10。此外，規範節點優先級可以幫助將連接嘗試分散在許多子網上，從而降低對任何潛在受害者子網的影響。
總結#
PEX 是一種用於 BitTorrent 協議的擴展。它通過允許 BitTorrent 客戶端交換各自所知道的其他用戶的 IP 地址和端口信息，來擴展節點列表並增強網絡連接。
PEX 允許客戶端直接與其他客戶端進行通信並交換節點信息。通過這種方式可以更快地發現和連接其他節點，加快下載速度，並減輕 tracker 的負擔，同時也提高了網絡的可靠性和及時性。
需要注意的是，PEX 功能可以被禁用或限制，因為它不受 BitTorrent 協議規範的約束，並且可能會導致某些問題，如假節點攻擊、隱私洩露等。因此，在使用 PEX 時，應該考慮安全和隱私的問題，並根據具體情況進行配置和調整。