請求-回應模式（request-reply pattern）

大多數的網路對話都遵循「一問一答」的節奏：一方發問，另一方回應，雙方輪流。你向館員問一個問題，等到回覆再問下一個。這種一來一往就是請求-回應模式（request-reply pattern），是應用協定最常見的構成方式——一方送出一個請求，然後等到一個相對應的回覆才往下走。

HTTP 是教科書般的例子：用戶端送出一個請求、收回恰好一個回應，然後才能送下一個。SMTP、FTP 命令與 DNS 查詢也都遵循這種輪流的形態。它的決定性特徵是配對——每個回覆都屬於某個特定的請求，而發問者通常會阻塞（等待）直到回覆抵達。這使這個模型易於推理：在任何時刻你都確切知道自己正在回答哪個問題。它也讓失敗處理變清楚——如果在逾時內沒有回覆到來，發問者就知道出了狀況，可以重試或放棄。

請求-回應並非唯一的風格，認清它的極限很重要。它的弱點是負載下的延遲：如果每個請求都必須完成才輪到下一個回覆，一個慢操作就會卡住進展（這正是 HTTP/1.1 持久連線所遇上的行頭問題）。替代方案是串流（streaming），其中資料持續流動、沒有一問一答的節奏——一段直播影片、一條股價推送，或一條聊天連線，會推送源源不絕的訊息，而任一方都可以隨時開口。第三種風格是發布-訂閱（publish-subscribe，MQTT 與類似系統採用），其中傳送者發布訊息，任意數量有興趣的訂閱者都會收到，根本沒有直接的回覆。選擇請求-回應、串流還是發布-訂閱，是設計一個應用協定時最早、也最關鍵的決定之一。