要求的處理方式

區域 ID

REGION_ID 是 Google 根據您在建立應用程式時選取的地區所指派的簡寫代碼。雖然某些區域 ID 可能看起來與常用的國家/地區代碼相似,但此代碼並非對應國家/地區或省份。如果是 2020 年 2 月後建立的應用程式,App Engine 網址會包含 REGION_ID.r。如果是在此日期之前建立的現有應用程式,網址中則可選擇加入地區 ID。

進一步瞭解區域 ID

本文件說明 App Engine 應用程式如何接收要求及傳送回應。

詳情請參閱要求標頭和回應參考資料

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

處理要求

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

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

伺服器會比對要求的網址和應用程式 app.yaml 設定檔中的網址模式,判斷要執行哪個 PHP 處理常式指令碼,接著執行填入要求資料的指令碼。伺服器會將要求資料置於環境變數和標準的輸入串流中。指令碼會根據要求執行適當的動作,然後準備回應,並將此回應放入標準輸出串流中。

以下範例是 PHP 指令碼,會使用「Hello World!」訊息回應任何 HTTP 要求。

<?php

echo 'Hello, World!';

配額與限制

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 要求會計入這些值。詳情請參閱「配額」頁面。

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

限制 大小
要求大小 32 MB
回應大小 32 MB
要求逾時 取決於應用程式使用的調度類型
檔案總數量的上限 (應用程式檔案和靜態檔案) 總計 10,000 個
每個目錄 1,000 個
應用程式檔案的大小上限 32 MB
靜態檔案的大小上限 32 MB
所有應用程式和靜態檔案的總大小上限 前 1 GB 免費
前 1 GB 過後,每個月每 GB$ 0.026 美元
待處理的要求逾時 10 秒
單一要求標頭欄位的大小上限 在標準環境中,第二代執行階段的大小為 8 千位元組。針對這些執行階段發出的標頭欄位超過 8 千位元組的要求,會傳回 HTTP 400 錯誤。

要求限制

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

回應限制

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

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

要求標頭

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

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

處理要求逾時

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

如果 PHP 指令碼超過這個期限,系統就會設定連線狀態位元欄位的 TIMEOUT 位元。指令碼接著有很短的第二次到期時間來清除任何長時間執行的工作,並向使用者傳回回應。

如果指令碼未在第二個期限內傳回回應,處理常式就會停止,並傳回預設錯誤回應。

回應

App Engine 會呼叫已填入 $_REQUEST 陣列的指令碼,將指令碼的任何輸出進行緩衝處理,並在指令碼執行完成後,將緩衝處理的輸出傳送給使用者。

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

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

串流回應

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

回應壓縮

App Engine 會盡可能向支援壓縮內容的用戶端提供壓縮 (gzip) 內容。為了判斷是否應壓縮內容,App Engine 會在收到要求時執行下列操作:

  1. 確認用戶端是否能穩定接收壓縮過的回應,方法是查看要求中的 Accept-EncodingUser-Agent 標頭。這種方法可避免熱門瀏覽器中一些常在 gzip 格式的壓縮內容上發生的問題。

  2. 查看您為回應處理常式設定Content-Type 標頭,確認是否適合壓縮內容。一般來說,壓縮功能適合用於文字內容類型,但不適用於二進位內容類型。

注意事項:

  • 用戶端可以將 Accept-EncodingUser-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 privateno-store 指令,否則 Google 前端也可能會快取內容。如果您未在 app.yaml 中設定這個標頭,App Engine 會自動為靜態檔案或目錄處理常式處理的所有回應新增這個標頭。詳情請參閱「新增或取代標頭」。

  • Vary:如要讓快取根據在要求中傳送的標頭,為網址傳回不同的回應,請在 Vary 回應標頭中設定一或多個以下值:AcceptAccept-EncodingOriginX-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-ControlExpires HTTP 回應標頭。

應用程式快取

PHP 執行階段環境包含 OPcache,能夠快取 PHP 中介碼,並且顯著改善應用程式回應時間。您可以在應用程式的 php.ini 檔案中設定 opcache.enabled = "0",藉此停用 OPcache 快取功能。

記錄

App Engine 網路伺服器會擷取處理常式指令碼寫入標準輸出串流的所有內容,以回應網路要求。還會擷取處理常式指令碼寫入標準錯誤串流的所有內容,並儲存為記錄資料。您可以在Google Cloud 主控台中使用 Cloud Logging 查看應用程式的記錄資料。

App Engine PHP 執行階段環境支援使用 PHP 內建 syslog() 函式記錄應用程式中的任意訊息,這項函式會叫用 Logs API

環境

強制 HTTPS 連線

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

Strict-Transport-Security: max-age=31536000; includeSubDomains
如要為應用程式提供的任何靜態內容設定這個標頭,請將標頭新增至應用程式的靜態檔案和目錄處理常式

處理非同步背景工作

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

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