HTTP請求/響應以及來自其他服務器的響應

Question

在HTTP請求/響應方案中，我猜對響應請求的客戶端來說無關緊要（無論如何，他會如何說）。

簡而言之，我想從這里開始：

Client
 ↓   ↑
 Nginx
  ↓   ↑
  ServerA
   ↓   ↑
   ServerB

對此：

Client
 ↓    ↑
 Nginx ↖
  ↓      ↖
  ServerA  ↖
   ↓      ↗
   ServerB

由於serverB已經有響應，並且不會進行其他處理，因此我想繞過serverA，但是如果可能的話，應該通過nginx（例如使用壓縮）。

具體來說，我想進一步了解：

• 必要的nginx配置（如果有）

• serverA和ServerB之間的協議交換是否必須特殊？

• 要發生這種情況必須傳遞的上下文？ 此外，如果他們使用不同的語言（在我的情況下為Clojure和Scala），會發生什么。

一個小示例示例將是非常受歡迎的（最好是Clojure，Scala，Java，Node.js-只要可讀的任何語言）。

Answer 1

我確定您的案例可以使用nginx-clojure實現 。 去年，有人用nginx-clojure做過類似但更復雜的事情。 與serverA和ServerB之間的協議交換無關。

1. 在nginx內容處理程序中，使用hijack! 要獲取NginxHttpServerChannel的ch ，將ch放入帶有密鑰的地圖req-uuid 。 因此，我們可以稍后使用ch發送響應數據。 將nginx url，req-uuid和其他數據發送到ServerA。
2. ServerA將nginx-url ， req-uuid和其他數據發送到ServerB。
3. ServerB通過與第一步不同的另一個URL發送req-uuid和響應給nginx，例如'/ asynNotfifyHandler'
4. 編寫另一個Nginx內容處理程序，以從ServerB接收位置“ / asynNotfifyHandler”的響應。 如果nginx worker進程只有一個，則在此處理程序中獲取NginxHttpServerChannel ch並使用它發送響應。 如果我們有多個nginx worker進程，我們需要使用broadcast! 播放回復事件並使用on-broadcast! 在擁有NginxHttpServerChannel ch的Nginx工作進程中獲取響應事件，並使用該事件將響應發送到原始客戶端。

這是有關channel sub / pub的示例。

順便說一句，我們也可以使用redis的sub / pub代替broadcast! 和on-broadcast! 來自nginx-clojure。 例如，在第一個內容處理程序中，我們為redis主題創建了子主題，然后服務器B將響應消息發布到redis的同一主題。 最后，使用NginxHttpServerChannel ch將響應發送到原始客戶端。

Answer 2

在HTTP請求/響應的情況下，我唯一能看到的就是通過某些HTTP服務器推送。 問題是，您至少將使用TCP連接進行客戶端/ Nignx通信。 我猜，您可以使用“即發即棄”的某些技術來做到這一點，但是您將需要能夠打開與客戶端的新連接以向其發送新數據。

在第一種情況下，每項服務都通過詢問請求並等待響應進行通信。

在第二種情況下，您可以做一些代理請求（不等待任何響應），但是要提供一些有關客戶端的信息，以便能夠在服務器B內與它聯系（打開連接）。

我不知道哪種技術最適合此用途，但這就是我要采取的方向。

Answer 3

如果所有這些連接都是HTTP請求，除非您自己在中間場景中實現某種操作，這對客戶端來說確實很重要。

基本上由於TCP連接的性質（HTTP協議使用該協議在網絡上傳輸數據），客戶端和服務器試圖確保將每個消息傳遞到它的預期目標並按順序傳遞。

您可以研究TCP協議以更好地了解其局限性。 該視頻似乎是一般概述的一個良好的開端。 視頻中的8:23比喻TCP有點像電話交談，這就是為什么在“對話”過程中很難更改服務器或客戶端的原因，因為它不是以這種方式設計的。

就像在電話中一樣，雖然您可以重定向請求，但也可以使用HTTP重定向來實現您所描述的期望效果。