要求的處理方式

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

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

如果您的應用程式使用服務，則可以設定要求的位址，將要求傳送到特定服務或該服務的特定版本。如要進一步瞭解服務的定址功能，請參閱「要求的轉送方式」一文。

處理要求

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

App Engine 會執行應用程式的多個執行個體，每個執行個體都有自己專用的網路伺服器來處理要求。每個要求均有可能轉送至任何一個執行個體，因此來自同一個使用者的連續要求不一定會送到相同的執行個體。執行個體可以並行處理多個要求，而執行個體的數量能夠隨流量自動調整。您也可以在 app.yaml 檔案中設定 max_concurrent_requests 元素，或是在使用 App Engine 舊版套裝服務時設定 appengine-web.xml 檔案，藉此變更執行個體可以處理的並行要求數量。

配額與限制

App Engine 會在流量增加時自動分配資源給您的應用程式，然而這項作業會受到下列限制：

• App Engine 會針對低延遲時間 (回應要求的時間不到一秒) 的應用程式，保留自動調整資源配置的容量。

• 大幅受到 CPU 限制的應用程式可能也會產生一些額外的延遲時間，以便和相同伺服器上的其他應用程式有效率地共用資源。對靜態檔案的要求則不受這些延遲限制。

每個傳送至應用程式的要求均會計入「Requests」(要求) 限制，而回應要求所傳送的資料則會計入「Outgoing Bandwidth (billable)」(連出頻寬 (可計費)) 限制。

HTTP 及 HTTPS (加密連線) 要求均會計入「Requests」(要求)、「Incoming Bandwidth (billable)」(連入頻寬 (可計費)) 及「Outgoing Bandwidth (billable)」(連出頻寬 (可計費)) 的限制。Google Cloud 控制台的「Quota Details」(配額詳細資料) 頁面也會個別回報「Secure Requests」(安全性要求)、「Secure Incoming Bandwidth」(安全連入頻寬) 和「Secure Outgoing Bandwidth」(安全連出頻寬) 的值，以供參考之用。只有 HTTPS 要求會計入這些值。詳情請參閱「配額」頁面。

要求處理常式的使用配額還受到下列特別限制：

要求限制

所有 HTTP/2 要求在轉送至應用程式伺服器時都會被轉譯為 HTTP/1.1 要求。

回應限制

• 動態回應大小上限為 32 MB。如果指令碼處理常式產生大於此上限的回應，伺服器會傳回空白回應並顯示「500 Internal Server Error」(內部伺服器錯誤) 狀態碼。這項限制不適用於從 Cloud Storage 提供資料的回應，或是舊版 Blobstore API (如果在執行階段可用)。

• 第二代執行階段的回應標頭限制為 8 KB。回應標頭超出此限制時，系統會傳回 HTTP 502 錯誤，並在記錄中顯示 upstream sent too big header while reading response header from upstream。

要求標頭

傳入 HTTP 要求包含用戶端傳送的 HTTP 標頭。基於安全性考量，部分標頭在送達應用程式之前會由中繼 Proxy 進行處理或修改。

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

處理要求逾時

App Engine 已針對要求持續時間短暫的應用程式進行最佳化，尤其是回應要求只需耗費數百毫秒的應用程式。效率良好的應用程式能快速回應大部分的要求，至於回應速度不夠快的應用程式，則無法隨著 App Engine 的基礎架構妥善調度資源。為確保達到這一層級的效能，系統會設定 要求逾時上限，每個應用程式都必須在該時間內回應。

如果應用程式超出這個期限，App Engine 就會中斷要求處理常式。

回應

您產生的回應會受到大小限制的限制，而且在傳回用戶端前可能已經過修改。

詳情請參閱要求回應參考資料。

串流回應

若資料在要求處理過程中，以增量區塊的形式傳送至用戶端，那麼 App Engine 並不支援此類資料的串流回應。系統會依上述方式收集所有來自程式碼的資料，並做為單一 HTTP 回應傳送。

回應壓縮

針對程式碼傳回的回應，如果同時符合下列兩個條件，App Engine 就會壓縮回應中的資料：

• 要求包含 Accept-Encoding 標頭，其中包含 gzip 做為值。
• 回應包含 HTML、CSS 或 JavaScript 等文字資料。

如果回應是由 App Engine 靜態檔案或目錄處理常式傳回，則在下列所有條件皆成立的情況下，回應資料會經過壓縮：

• 要求包含 Accept-Encoding，其中 gzip 是其中一個值。
• 用戶端可以以壓縮格式接收回應資料。Google 前端會維護一份清單，列出已知有壓縮回應問題的用戶端。即使要求標頭包含 Accept-Encoding: gzip，這些用戶端也不會從應用程式中的靜態處理常式接收壓縮資料。
• 回應包含 HTML、CSS 或 JavaScript 等文字資料。

注意事項：

• 用戶端可以將 Accept-Encoding 和 User-Agent 要求標頭都設為 gzip，藉此強制壓縮文字型內容類型。

• 如果要求未在 Accept-Encoding 標頭中指定 gzip，App Engine 就不會壓縮回應資料。

• Google 前端會快取 App Engine 靜態檔案和目錄處理常式提供的回應。視各種因素而定，例如系統先快取哪種類型的回應資料、您在回應中指定的 Vary 標頭，以及要求中包含哪些標頭，客戶可能會要求壓縮資料，但收到未壓縮的資料，反之亦然。詳情請參閱「回應快取」。

回應快取

Google 前端 (以及可能的使用者瀏覽器和其他中介快取 Proxy 伺服器) 會根據您在回應中指定的標準快取標頭，快取應用程式的回應。您可以透過架構、直接在程式碼中，或透過 App Engine 靜態檔案和目錄處理常式指定這些回應標頭。

在 Google 前端中，快取鍵是要求的完整網址。

快取靜態內容

為確保客戶一有更新的靜態內容發布，就立即收到更新內容，建議您從有版本號碼的目錄 (例如 css/v1/styles.css) 提供靜態內容。快取內容到期前，Google 前端不會驗證快取 (檢查更新內容)。即使快取已到期，除非要求網址的內容有所變更，否則快取不會更新。

您可以在 app.yaml 中設定下列回應標頭，影響 Google 前端快取內容的方式和時間：

• Cache-Control 應設為 public，讓 Google 前端快取內容；除非您指定 Cache-Control private 或 no-store 指令，否則 Google 前端也可能會快取內容。如果您未在 app.yaml 中設定這個標頭，App Engine 會自動為所有由靜態檔案或目錄處理常式處理的回應新增此標頭。詳情請參閱「新增或取代標頭」。

• Vary：如要讓快取根據在要求中傳送的標頭，為網址傳回不同的回應，請在 Vary 回應標頭中設定一或多個以下值：Accept、Accept-Encoding、Origin 或 X-Origin

  由於基數可能很高，因此系統不會為其他 Vary 值快取資料。

  例如：

  1. 您可以指定下列回應標頭：

     Vary: Accept-Encoding

  2. 應用程式會收到含有 Accept-Encoding: gzip 標頭的要求。App Engine 會傳回壓縮的回應，而 Google 前端會快取壓縮版的回應資料。對於包含 Accept-Encoding: gzip 標頭的這個網址，後續所有要求都會從快取接收經過 GZIP 壓縮的資料，直到快取失效 (因為內容在快取過期後會變更) 為止。

  3. 您的應用程式收到的請求不含 Accept-Encoding 標頭。App Engine 會傳回未壓縮的回應，而 Google 前端會快取回應資料的未壓縮版本。此網址的所有後續要求 (不含 Accept-Encoding 標頭) 都會從快取中接收壓縮資料，直到快取失效為止。

  如果您未指定 Vary 回應標頭，Google 前端會為網址建立單一快取項目，並且會在所有要求中使用該項目，不論要求中的標頭為何。例如：

  1. 您未指定 Vary: Accept-Encoding 回應標頭。
  2. 要求包含 Accept-Encoding: gzip 標頭，回應資料的 GZIP 版本會快取。
  3. 第二個要求不含 Accept-Encoding: gzip 標頭。不過，由於快取包含已壓縮的回應資料，因此即使用戶端要求未壓縮的資料，回應也會經過壓縮。

要求中的標頭也會影響快取：

• 如果要求包含 Authorization 標頭，Google 前端就不會快取內容。

快取到期

根據預設，App Engine 靜態檔案和目錄處理常式在回應中新增的快取標頭會指示用戶端和 Google 前端等網路 Proxy，在 10 分鐘後讓快取內容過期。

擁有指定到期時間的檔案在傳輸之後，通常就無法從網路 Proxy 快取中清除，就算使用者清除了自己的瀏覽器快取也沒辦法。重新部署應用程式的新版本「不會」重設任何快取。因此，如果您打算修改靜態檔案，請為其設定較短的效期 (不超過一小時)。在大多數情況下，預設的 10 分鐘效期即為適當的設定。

您可以在 app.yaml 檔案中指定 default_expiration 元素，藉此變更所有靜態檔案和目錄處理常式的預設到期日。如要為個別處理常式設定特定到期時間，請在 app.yaml 檔案的處理常式元素中指定 expiration 元素。

您在到期元素時間中指定的值，會用於設定 Cache-Control 和 Expires HTTP 回應標頭。

強制 HTTPS 連線

基於安全性考量，所有應用程式皆應鼓勵用戶端透過 https 連線。如要指示瀏覽器針對特定網頁或整個網域採用 https 而非 http，請在回應中設定 Strict-Transport-Security 標頭。例如：

Strict-Transport-Security: max-age=31536000; includeSubDomains

如要為應用程式提供的任何靜態內容設定這個標頭，請將標頭新增至應用程式的靜態檔案和目錄處理常式。

處理非同步背景工作

背景工作是指應用程式在您傳送 HTTP 回應後，為要求執行的任何工作。請避免在應用程式中執行背景工作，並查看程式碼，確認在您傳送回應之前，所有非同步作業皆已完成。

對於長時間執行的工作，建議您使用 Cloud Tasks。在 Cloud Tasks 中，HTTP 要求會保留一段時間，且只會在任何非同步工作結束後傳回回應。

App Engine 待處理佇列優先順序

在流量繁忙期間，App Engine 可能會將要求放入待處理佇列，並等待可用的執行個體，並依下列優先順序處理：

• App Engine 會優先處理其他排隊要求，而非 Task queue 中的待處理排隊要求。基於相容性考量，App Engine Cloud Tasks 的要求也會共用此待處理佇列優先順序行為。

• 在待處理佇列中，App Engine 會將 HTTP 目標 Cloud Tasks 的請求視為一般 HTTP 流量。HTTP 目標要求的優先順序並未降低。

• 當服務同時以大量標準 HTTP 流量和極少的 Task 佇列或 Cloud Tasks 流量提供服務時，會對 Task 佇列或 Cloud Tasks 流量的延遲時間造成不成比例的影響。建議您將流量類型分割為個別版本，或使用 HTTP 目標工作，以免優先排入佇列。您也應考慮使用專屬的主要版本或服務，為 Cloud Tasks 提供延遲敏感型要求。