Anda mungkin pernah membaca bahwa HTTPS membuka koneksi TCP baru dan handshake TLS baru untuk setiap permintaan API, sehingga terowongan yang tetap menyala selama satu jam tampak lebih murah. Paruh pertama pernyataan itu biasanya keliru. Klien yang didukung menggunakan kembali koneksi yang sudah terbentuk untuk banyak pertukaran, dan tolok ukur yang membuat klien baru pada setiap panggilan mengukur siklus hidup, bukan perlindungan. Sisa halaman ini membahas apa yang seharusnya diukur.

Apa yang sebenarnya dituntut penggunaan kembali

Persistensi adalah bagian dari model HTTP, bukan trik: satu koneksi membawa beberapa pertukaran permintaan dan respons. Koneksi berakhir ketika salah satu pihak menutupnya, ketika server menghentikan koneksi yang menganggur atau kelebihan beban, atau ketika header atau aturan protokol menyatakan koneksi tidak dapat digunakan kembali. HTTPS menempatkan percakapan itu di dalam TLS tanpa menuntut handshake baru untuk setiap pertukaran. Jadi permintaan kedua tidak mengulang handshake permintaan pertama kecuali ada sesuatu yang mengakhiri koneksi di antaranya.

Penggunaan kembali juga punya satu syarat yang mudah dilanggar aplikasi. Klien yang berniat menggunakan kembali koneksi harus membaca seluruh isi respons, dan respons yang ditinggalkan di tengah jalan adalah cara biasa kumpulan koneksi menghilang tanpa ada yang menyadarinya.

Periksa klien yang didukung dan siklus hidup kumpulan koneksi pustaka, bukan menganggap pengumpulan aktif atau tidak. Catat juga versi HTTP yang dinegosiasikan, karena HTTP/2 dan HTTP/3 menangani penggunaan kembali koneksi berbeda dari HTTP/1.1. Perlakukan versi yang dinegosiasikan sebagai bagian dari pengukuran, bukan catatan kaki.

Mengapa perbandingan mengukur siklus hidup

Membuat klien baru untuk setiap operasi dan membandingkannya dengan terowongan yang sudah terhubung selama satu jam membandingkan penyiapan koneksi dengan kondisi mapan. Itu tolok ukur yang sah, dan itu bukan HTTPS versus VPN. Dua eksekusi dengan konfigurasi klien yang sama menggambarkan perilaku lebih baik daripada satu, terutama ketika eksekusi pertama menghangatkan resolver atau cache koneksi.

Jaga operasi API, server, akun, dan data tetap konstan, atau perbandingan membawa lebih dari satu variabel. Putuskan lebih dulu di mana Anda meletakkan pengukur waktu, karena penyiapan, negosiasi TLS, eksekusi aplikasi, dan pengiriman respons memberi kontribusi berbeda pada total. Satu pengukur waktu permintaan pertama mencirikan penyiapan dan tidak mengatakan apa pun tentang lalu lintas mapan yang sebenarnya Anda jalankan. Tuliskan batas pengukur waktu di samping angka-angkanya.

Pisahkan penyiapan dingin dari permintaan hangat

Ukur permintaan pertama secara terpisah dari permintaan berikutnya. Lalu tambahkan apa yang benar-benar dilihat layanan: periode menganggur, lonjakan, konkurensi, ukuran respons, dan penyambungan ulang.

Biarkan validasi sertifikat dan HTTPS tetap aktif di kedua jalur, karena menghapusnya mengukur desain keamanan yang lain, bukan yang lebih cepat. Jika terowongan mengubah rute atau lokasi gateway, laporkan perbedaan itu secara terpisah alih-alih mengaitkan setiap perubahan waktu dengan enkripsi, karena jalur, kehilangan paket, dan antrean dapat mendominasi permintaan kecil. Jalankan setiap jalur dua kali pada rute yang sama sebelum menarik kesimpulan. Catat protokol yang dinegosiasikan dan batas pengukur waktu pada kedua eksekusi.

Bersiap untuk koneksi yang tertutup

Persisten bukan berarti permanen. Server, proxy, atau perubahan jaringan dapat menutup koneksi selama periode menganggur, dan klien harus pulih melalui perilaku yang didukung pustakanya. Pemulihan itu memiliki mesin status: permintaan mungkin sudah selesai di server, atau gagal sebelum server membacanya, dan soket yang tertutup tidak memberi tahu pemanggil mana yang terjadi. Operasi yang tidak idempoten dalam posisi itu tidak bisa begitu saja diputar ulang, karena pengulangan mengubah hasil tak diketahui menjadi penulisan ganda. Di sinilah terowongan hangat dan koneksi hangat berperilaku sama, karena keduanya dapat gagal pada saat pekerjaan sedang berjalan.

Gunakan mekanisme percobaan ulang atau idempotensi terdokumentasi dari layanan alih-alih perulangan yang membuka ulang soket. Uji pemulihan secara eksplisit dengan menutup koneksi menganggur dan mengamati apa yang dilakukan klien berikutnya. Membuka ulang soket tidak membuat pengulangan panggilan yang mengubah status menjadi aman.

Pilih batas dulu, baru setel

Pilih batas jaringan dari persyaratan akses dan kepercayaan sebelum mengoptimalkan apa pun. VPN melindungi segmen di antara rekan-rekannya, sedangkan titik akhir aplikasi dan segmen teks polos apa pun di luar terowongan tetap penting. Lalu setel siklus hidup koneksi di dalam batas itu. Kesimpulan terowongan lebih murah hanya mengikuti keyakinan bahwa setiap permintaan mengulang handshake, dan keyakinan itulah yang diuji di sini.

Bagian persistensi RFC 9112 adalah rujukan untuk apa yang sebenarnya dijanjikan penggunaan kembali, termasuk syarat yang mengakhiri koneksi. Bacalah sekali sebelum memercayai tolok ukur yang mengabaikannya.

Artikel terkait