要求的處理方式

本文件說明您的 App Engine 應用程式如何接收要求及傳送回應。詳情請參閱要求標頭參考資料一文。

如果您的應用程式使用這些服務,可以將要求轉送給指定服務或該服務的指定版本。如需進一步瞭解服務的轉送功能,請參閱要求的轉送方式一文。

處理要求

您的應用程式負責啟動網路伺服器和處理要求。您可以使用任何適用於您的開發語言的網路架構。

App Engine 會執行應用程式中的多個執行個體,每個執行個體都有專屬用來處理要求的網路伺服器。每個要求都能轉送給任何執行個體,因此來自同一個使用者的連續要求不一定會送到相同的執行個體。一個執行個體可以同時處理多個要求。執行個體的數量可隨著流量自動調整。您也可以透過在 app.yaml 檔案中設定 max_concurrent_requests,以變更一個執行個體可以處理的並行要求數量。

下列範例是相當基本的單一檔案 Sinatra 應用程式,會透過顯示「Hello, world!」 訊息來回應網路用戶端到「/」根路徑的所有 GET 要求。

require "sinatra"

get "/" do
  "Hello world!"
end

配額與限制

App Engine 會在流量增加時自動分配資源到您的應用程式,不過這項作業會受到下列限制的約束:

  • 針對延遲時間短的應用程式,亦即回應要求時間不到一秒者,App Engine 會保留自動調整資源配置的容量。而具有高延遲時間 (例如對於多個要求中的每次回應平均超過一秒) 及高總處理量的應用程式,則需要白銀級、爍金級或白金級的支援。具有此類等級支援的客戶,可以透過聯絡他們的支援代表,要求較高的總處理量上限。

  • 大幅受到 CPU 限制的應用程式可能會引發部分額外延遲,以便和相同伺服器上的其他應用程式有效率地共用資源。對靜態檔案的要求,則不受這些延遲限制的規範。

每個傳送至應用程式的傳入要求也會算入要求限制。為了回應要求所傳出的資料也會算入連出頻寬 (可計費) 限制。

HTTP 及 HTTPS (安全連線) 要求也會算入要求連入頻寬 (可計費)連出頻寬 (可計費) 的限制。GCP 主控台配額詳情頁面也會將安全性要求安全連入頻寬安全連出頻寬回報為獨立的值,以做為參考之用。只有 HTTPS 要求會算入這些值之中。詳情請參閱配額頁面。

下列限制僅適用於使用要求處理常式:

要求限制

  • 僅接受上限為 15KB 的要求標頭。
  • 要求的大小總計不能超過 32MB。
  • 每個 HTTP/2 要求在轉送至應用程式伺服器時將翻譯為 HTTP/1.1 要求。
  • SSL 連線會在負載平衡器上終止。來自負載平衡器的流量會透過加密通道傳送至執行個體,然後透過 HTTP 傳送到應用程式伺服器。X-Forwarded-Proto 標頭會讓您知道原始要求為一個或是數個 HTTP 要求。

回應限制

  • 回應會以 64k 區塊進行緩衝。
  • 回應大小無限制。
  • 回應時間限於一小時內。

不支援的 HTTP 要求

App Engine 彈性環境並未支援下列功能:

  • 轉送至後端服務的 HTTP/2 流量
  • WebSocket
  • 可直接存取執行個體的 HTTP 要求

要求標頭

連入 HTTP 要求包含用戶端所傳送的 HTTP 標頭。基於安全性考量,部分標頭在傳送至應用程式之前會被中繼 Proxy 清除或修改。

詳情請參閱要求標頭參考資料一文。

要求回應

您所產生的回應會受到一些限制,並且在傳回用戶端前可能已經過修改。

停用緩衝

所有來自 App Engine 的回應,依照預設會在 64k 區塊中緩衝。在某些情況下,您可以停用緩衝,直接將位元組串流至用戶端。當在使用等待 GET 或伺服器推送事件 (SSE) 時一般偏好這種作法。如要停用緩衝,您可以將 X-Accel-Buffering 回應標頭設定為 no

X-Accel-Buffering: no

強制 HTTPS 連線

基於安全性考量,所有應用程式應該要鼓勵用戶端透過 https 來連線。您可以使用嚴格傳輸安全性標頭指示瀏覽器,對於指定網頁或整個網域採用 https 而非 http,例如:

Strict-Transport-Security: max-age=31536000; includeSubDomains
本頁內容對您是否有任何幫助?請提供意見:

傳送您對下列選項的寶貴意見...

這個網頁
Ruby 適用的 App Engine 彈性環境文件