HTTPS hangat berbanding VPN hangat: bandingkan laluan permintaan yang sama

Anda mungkin pernah membaca bahawa HTTPS membuka sambungan TCP baharu dan handshake TLS baharu untuk setiap permintaan API, jadi terowong yang kekal hidup selama sejam kelihatan lebih murah. Separuh pertama kenyataan itu biasanya palsu. Klien yang disokong menggunakan semula sambungan yang telah terbentuk untuk banyak pertukaran, dan penanda aras yang membina klien baharu bagi setiap panggilan mengukur kitaran hayat dan bukan perlindungan. Selebihnya halaman ini membincangkan apa yang patut diukur sebaliknya.

Apa yang sebenarnya dituntut oleh penggunaan semula

Kegigihan ialah sebahagian daripada model HTTP dan bukan helah: satu sambungan membawa beberapa pertukaran permintaan dan respons. Sambungan berakhir apabila mana-mana pihak menutupnya, apabila pelayan membuang sambungan yang melahu atau terlebih beban, atau apabila pengepala atau peraturan protokol menyatakan sambungan itu tidak boleh digunakan semula. HTTPS meletakkan perbualan itu di dalam TLS tanpa menuntut handshake baharu bagi setiap pertukaran. Jadi permintaan kedua tidak mengulangi handshake permintaan pertama melainkan sesuatu telah menamatkan sambungan itu di antaranya.

Penggunaan semula juga mempunyai satu syarat yang mudah dilanggar oleh aplikasi. Klien yang berhasrat menggunakan semula sambungan mesti membaca seluruh badan respons, dan respons yang ditinggalkan di tengah jalan ialah cara biasa kumpulan sambungan hilang tanpa sesiapa menyedarinya.

Semak klien yang disokong dan kitaran hayat kumpulan sambungan pustaka itu, bukan menganggap pengumpulan dihidupkan atau dimatikan. Catat juga versi HTTP yang dirundingkan, kerana HTTP/2 dan HTTP/3 mengendalikan penggunaan semula sambungan secara berbeza daripada HTTP/1.1. Anggap versi yang dirundingkan sebagai sebahagian daripada pengukuran, bukan nota kaki.

Mengapa perbandingan mengukur kitaran hayat

Mencipta klien baharu bagi setiap operasi dan membandingkannya dengan terowong yang telah bersambung selama sejam membandingkan penyediaan sambungan dengan keadaan mantap. Itu penanda aras yang sah, dan ia bukan HTTPS berbanding VPN. Dua larian dengan konfigurasi klien yang sama menggambarkan tingkah laku dengan lebih baik daripada satu, terutamanya apabila larian pertama memanaskan penyelesai atau cache sambungan.

Kekalkan operasi API, pelayan, akaun dan data secara malar, jika tidak perbandingan membawa lebih daripada satu pemboleh ubah. Tentukan lebih awal di mana anda meletakkan pemasa, kerana penyediaan, rundingan TLS, pelaksanaan aplikasi dan penghantaran respons menyumbang secara berbeza kepada jumlah. Satu pemasa permintaan pertama mencirikan penyediaan dan tidak mengatakan apa-apa tentang trafik mantap yang sebenarnya anda jalankan. Tuliskan sempadan pemasa di sebelah nombor-nombor itu.

Asingkan penyediaan sejuk daripada permintaan hangat

Ukur permintaan pertama secara berasingan daripada permintaan berikutnya. Kemudian tambahkan apa yang benar-benar dilihat oleh perkhidmatan: tempoh melahu, lonjakan, keserempakan, saiz respons dan penyambungan semula.

Biarkan pengesahan sijil dan HTTPS dihidupkan pada kedua-dua laluan, kerana menanggalkannya mengukur reka bentuk keselamatan yang berbeza dan bukan yang lebih pantas. Jika terowong menukar laluan atau lokasi get laluan, laporkan perbezaan itu secara berasingan dan bukan mengaitkan setiap perubahan masa dengan penyulitan, kerana laluan, kehilangan dan baris gilir boleh menguasai permintaan kecil. Jalankan setiap laluan dua kali melalui laluan yang sama sebelum membuat kesimpulan. Catat protokol yang dirundingkan dan sempadan pemasa dengan kedua-dua larian.

Rancang untuk sambungan yang tertutup

Kegigihan tidak bermakna kekal selama-lamanya. Pelayan, proksi atau perubahan rangkaian boleh menutup sambungan semasa tempoh melahu, dan klien mesti pulih melalui tingkah laku yang disokong oleh pustakanya. Pemulihan itu mempunyai mesin keadaan: permintaan mungkin telah selesai pada pelayan, atau ia mungkin gagal sebelum pelayan membacanya, dan soket yang tertutup tidak memberitahu pemanggil mana yang berlaku. Operasi tidak idempoten dalam kedudukan itu tidak boleh dimainkan semula begitu sahaja, kerana mainan semula mengubah hasil yang tidak diketahui menjadi tulisan berganda. Di sinilah terowong hangat dan sambungan hangat berkelakuan sama, kerana kedua-duanya boleh gagal pada saat kerja sedang berjalan.

Gunakan mekanisme cubaan semula atau idempotensi perkhidmatan yang didokumenkan dan bukan gelung yang membuka semula soket. Uji pemulihan secara jelas dengan menutup sambungan melahu dan memerhati apa yang klien lakukan seterusnya. Membuka semula soket tidak menjadikan pengulangan panggilan yang mengubah keadaan itu selamat.

Pilih sempadan dahulu, kemudian selaraskan

Pilih sempadan rangkaian daripada keperluan akses dan kepercayaan sebelum mengoptimumkan apa-apa. VPN melindungi segmen antara rakan-rakannya, manakala titik akhir aplikasi dan mana-mana segmen teks jelas di luar terowong masih penting. Kemudian selaraskan kitaran hayat sambungan di dalam sempadan itu. Kesimpulan terowong lebih murah hanya berpunca daripada kepercayaan bahawa setiap permintaan mengulangi handshake, dan kepercayaan itulah yang diuji di sini.

Bahagian kegigihan RFC 9112 ialah rujukan bagi apa yang sebenarnya dijanjikan oleh penggunaan semula, termasuk syarat yang menamatkan sambungan. Bacalah sekali sebelum mempercayai penanda aras yang mengabaikannya.