Cara menangani permintaan

ID region

REGION_ID adalah kode singkat yang ditetapkan Google berdasarkan region yang Anda pilih saat membuat aplikasi. Kode ini tidak sesuai dengan negara atau provinsi, meskipun beberapa ID region mungkin tampak mirip dengan kode negara dan provinsi yang umum digunakan. Untuk aplikasi yang dibuat setelah Februari 2020, REGION_ID.r disertakan dalam URL App Engine. Untuk aplikasi lama yang dibuat sebelum tanggal tersebut, ID region bersifat opsional dalam URL.

Pelajari ID region lebih lanjut.

Oke

Go Java Node.js PHP Python Ruby .NET Kustom

Dokumen ini menjelaskan cara aplikasi App Engine Anda menerima permintaan dan mengirim respons. Untuk detail selengkapnya, lihat Referensi Header Permintaan.

Jika aplikasi Anda menggunakan layanan, Anda dapat mengajukan permintaan ke layanan tertentu atau versi tertentu dari layanan tersebut. Untuk mengetahui informasi selengkapnya tentang cara respons layanan, lihat Cara Permintaan Dirutekan.

Menangani permintaan

Aplikasi Anda bertanggung jawab memulai server web dan menangani permintaan. Anda dapat menggunakan framework web apa pun yang tersedia untuk bahasa pengembangan Anda.

App Engine menjalankan beberapa instance aplikasi Anda, dan setiap instance memiliki server web sendiri untuk menangani permintaan. Setiap permintaan dapat dirutekan ke instance mana saja, sehingga permintaan berturut-turut dari pengguna yang sama belum tentu dikirim ke instance yang sama. Satu instance dapat menangani beberapa permintaan secara serentak. Jumlah instance dapat disesuaikan secara otomatis saat traffic berubah.

Kuota dan batas

App Engine otomatis mengalokasikan resource ke aplikasi Anda saat traffic meningkat. Namun, ini terikat oleh pembatasan berikut:

• App Engine mencadangkan kapasitas penskalaan otomatis untuk aplikasi dengan latensi rendah, saat aplikasi merespons permintaan dalam waktu kurang dari satu detik.

• Aplikasi yang sangat terikat dengan CPU juga dapat menimbulkan beberapa latensi tambahan untuk berbagi resource secara efisien dengan aplikasi lain di server yang sama. Permintaan untuk file statis dikecualikan dari batas latensi ini.

Setiap permintaan yang masuk ke aplikasi akan dihitung dalam batas Permintaan. Data yang dikirim sebagai respons terhadap permintaan akan dihitung dalam batas Bandwidth Keluar (dapat ditagih).

Permintaan HTTP dan HTTPS (aman) diperhitungkan dalam batas Permintaan, Bandwidth Masuk (dapat ditagih), dan Bandwidth Keluar (dapat ditagih). Halaman Detail Kuota konsol Google Cloud juga melaporkan Permintaan Aman, Bandwidth Masuk Aman, dan Bandwidth Keluar Aman sebagai nilai terpisah untuk tujuan informasi. Hanya permintaan HTTPS yang diperhitungkan dalam nilai ini. Untuk mengetahui informasi selengkapnya, lihat halaman Kuota.

Batas berikut berlaku khusus untuk penggunaan pengendali permintaan:

Batas permintaan

• Mengizinkan maksimum ~15 KB dalam header permintaan.
• Ukuran total permintaan dibatasi hingga ~32 MB.
• Semua permintaan HTTP/2 akan diterjemahkan menjadi permintaan HTTP/1.1 saat diteruskan ke server aplikasi.
• Koneksi SSL berakhir di load balancer. Traffic dari load balancing dikirim ke instance melalui saluran terenkripsi, lalu diteruskan ke server aplikasi melalui HTTP. Header X-Forwarded-Proto memungkinkan Anda memahami apakah permintaan origin adalah HTTP atau HTTPS.

Batas respons

• Respons di-buffer oleh blok 64k.
• Ukuran respons tidak terbatas.
• Batas waktu respons adalah satu jam.
• Batas header respons adalah 64 KB. Header respons yang melebihi batas ini akan menampilkan error HTTP 502, dengan log yang menampilkan upstream sent too big header while reading response header from upstream.

Permintaan HTTP yang tidak didukung

Fitur berikut tidak didukung oleh lingkungan fleksibel App Engine:

• Traffic HTTP/2 ke layanan backend.
• Permintaan HTTP yang langsung mengakses instance.

Header permintaan

Permintaan HTTP masuk menyertakan header HTTP yang dikirim oleh klien. Untuk tujuan keamanan, beberapa header dibersihkan atau diubah oleh proxy perantara sebelum mencapai aplikasi.

Untuk informasi selengkapnya, lihat Referensi header permintaan.

Menonaktifkan buffering

Secara default, semua respons dari App Engine di-buffer dalam blok 64k. Dalam beberapa kasus, sebaiknya nonaktifkan buffering dan langsung streaming byte ke klien. Opsi ini umumnya lebih disarankan saat menggunakan GET atau Server Terkirim Event (SSE) yang menggantung. Untuk menonaktifkan buffering, Anda dapat menetapkan header respons X-Accel-Buffering ke no.

Memaksa koneksi HTTPS

Untuk alasan keamanan, semua aplikasi harus mendorong klien untuk terhubung melalui https. Untuk menginstruksikan browser agar lebih memilih https daripada http untuk halaman tertentu atau seluruh domain, tetapkan header Strict-Transport-Security dalam respons Anda. Contoh:

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

Perhatian: Klien yang telah menerima header sebelumnya akan menolak untuk terhubung jika https menjadi tidak berfungsi atau dinonaktifkan karena alasan apa pun. Untuk mempelajari lebih lanjut, baca Tips Praktis tentang HTTP Strict Transport Security.

Menangani pekerjaan latar belakang asinkron

Pekerjaan latar belakang adalah pekerjaan apa pun yang dilakukan aplikasi untuk sebuah permintaan setelah Anda mengirimkan respons HTTP. Hindari melakukan pekerjaan latar belakang di aplikasi Anda, dan tinjau kode untuk memastikan semua operasi asinkron selesai sebelum Anda mengirimkan respons.

Untuk tugas yang berjalan lama, sebaiknya gunakan Cloud Tasks. Dengan Cloud Tasks, permintaan HTTP berumur panjang dan menampilkan respons hanya setelah pekerjaan asinkron berakhir.

Peringatan: Menjalankan tugas latar belakang asinkron dapat mengakibatkan penagihan yang lebih tinggi. App Engine mungkin meningkatkan skala instance tambahan karena beban CPU yang tinggi, meskipun tidak ada permintaan aktif. Pengguna juga mungkin mengalami peningkatan latensi karena permintaan yang menunggu dalam antrean tertunda untuk instance yang tersedia.