傳輸 (Transports)

傳輸 (Transports) 為從不同類型的連接讀取位元組與寫入位元組提供了統一的 API。在本 PEP 中，傳輸始終是有序、可靠、雙向、面向串流的雙端點連接。這可能是 TCP socket、SSL 連接、管道（具名或其他）、序列埠……它可能在 POSIX 平台上抽象化檔案描述符，在 Windows 上抽象化 Handle，或在特定平台上抽象化其他適當的資料結構。它封裝了使用該平台資料結構的所有具體實現細節，並為應用程式開發者呈現統一的介面。

傳輸與兩者進行對話：一方面是連接的另一端，另一方面是協議。它是特定底層傳輸機制與協議之間的橋樑。它的職責可以被描述為：讓協議只需發送和接收位元組，由傳輸負責處理最終透過線路發送位元組所需的所有魔法。

傳輸的主要功能是將位元組發送到協議，並從底層協議接收位元組。寫入傳輸是使用 write 和 write_sequence 方法完成的。後者是一種效能優化，旨在允許軟體利用某些傳輸機制中的特定功能。具體來說，這允許傳輸使用 writev 代替 write 或 send，即所謂的分散/集中式 IO (scatter/gather IO)。

傳輸可以被暫停和恢復。這會導致它緩衝來自協議的資料，並停止向協議發送接收到的資料。

傳輸也可以被關閉、半關閉和中止。關閉的傳輸將完成向底層機制寫入其佇列中所有資料，然後停止讀取或寫入資料。中止傳輸會立即停止它，關閉連接而不發送任何仍在佇列中的資料。

進一步的寫入操作將導致拋出異常。半關閉的傳輸可能不再被寫入，但仍會接受傳入的資料。

協定 (Protocols)

新用戶可能對協議 (Protocols) 更為熟悉。其術語與您對所謂「協議」的預期一致：大多數人首先想到的協議，如 HTTP、IRC、SMTP……都是將在協議中實現的例子。

協議最簡短實用的定義是：傳輸與其餘應用程式邏輯之間的（通常是雙向的）橋樑。協議從傳輸中接收位元組，並將該資訊轉化為某種行為，通常導致對某個物件的方法呼叫。同樣地，應用程式邏輯呼叫協議上的某些方法，協議將其轉化為位元組並傳達給傳輸。

最簡單的協議之一是基於行的協議，資料由 \r\n 分隔。協議將從傳輸中接收位元組並對其進行緩衝，直到至少有一整行。完成後，它將把這一行傳遞給某個物件。理想情況下，這應使用可呼叫物件或甚至由協議組成的完全獨立物件來完成，但也可以透過子類化來實現（如 Twisted 的 LineReceiver 情況）。對於另一個方向，協議可以有一個 write_line 方法，它會添加所需的 \r\n 並將新的位元組緩衝區傳遞給傳輸。

本 PEP 建議一種廣義的 LineReceiver，稱為 ChunkProtocol，其中「chunk」(區塊) 是串流中的一條訊息，由指定的分隔符分隔。實例接收分隔符和一個在接收到一塊資料時將被呼叫的可呼叫物件（與 Twisted 的子類化行為相反）。ChunkProtocol 還有一個與上述 write_line 方法類似的 write_chunk 方法。

為什麼要區分協議與傳輸？

協議與傳輸之間的這種分離往往讓初次接觸的人感到困惑。事實上，標準函式庫本身在許多情況下並沒有做出這種區分，特別是在其提供給使用者的 API 中。

儘管如此，這是一個非常實用的區分。在最壞的情況下，它透過明確的關注點分離簡化了實現。然而，它通常服務於更實用的目的：能夠在不同的傳輸中重複使用協議。

考慮一個簡單的 RPC 協議。相同的位元組可能透過許多不同的傳輸進行轉移，例如管道或 socket。為了協助這一點，我們將協議從傳輸中分離出來。協議只負責讀寫位元組，並不關心最終用於轉移這些位元組的機制。

這也允許協議被輕易地堆疊或嵌套，進一步提高代碼重用率。一個常見的例子是 JSON-RPC：根據規範，它可以同時用於 socket 和 HTTP [1]。在實踐中，它傾向於主要封裝在 HTTP 中。協議-傳輸抽象化讓我們能夠建立一個協議與傳輸的堆疊，讓您可以像使用傳輸一樣使用 HTTP。對於 JSON-RPC，您可能會得到類似這樣的堆疊

1. TCP socket 傳輸
2. HTTP 協議
3. 基於 HTTP 的傳輸
4. JSON-RPC 協議
5. 應用程式碼

消費者 (Consumers)

消費者 (Consumers) 消費由生產者 (Producers) 生產的位元組。透過與生產者的配合，使流量控制成為可能。

消費者在流量控制中主要扮演被動角色。每當生產者有可用資料時，它們就會被呼叫。接著它們處理資料，並通常將控制權交還給生產者。

消費者通常實現某種緩衝區。它們透過向生產者告知這些緩衝區的當前狀態，使流量控制成為可能。消費者可以指示生產者完全停止生產、暫時停止生產，或在之前被告知暫停的情況下恢復生產。

生產者透過 register 方法向消費者註冊。

生產者 (Producers)

消費者消費位元組，生產者生產位元組。

生產者模仿 Twisted 中的 IPushProducer 介面。雖然也有一個 IPullProducer，但總體而言它的趣味性低得多，因此可能超出了本 PEP 的範圍。

雖然生產者可以被告知完全停止生產，但它們擁有的兩個最重要的方法是 pause 與 resume。這些通常由消費者呼叫，以表示它是否準備好處理（「消費」）更多資料。消費者與生產者互相合作，使流量控制成為可能。

除了 Twisted 的 IPushProducer 介面之外，生產者還有一個 half_register 方法，當消費者試圖註冊該生產者時，會帶入該消費者參數來呼叫此方法。在大多數情況下，這只是設置 self.consumer = consumer 的情況，但某些生產者在註冊消費者時可能需要更複雜的前置條件或行為。終端使用者不應直接呼叫此方法。