Penamatan TLS atau Laluan Terus? Memilih Sempadan Proksi Terbalik Webship yang Betul

Memilih antara penamatan TLS dan laluan terus TLS bukanlah tetapan proksi kosmetik. Ia menentukan di mana penyulitan berakhir, sistem mana yang memegang kunci sesi, sama ada Webship boleh memeriksa HTTP, dan lapisan mana yang mesti menguatkuasakan keselamatan aplikasi.

Webship lalai kepada laluan terus. Itu mengekalkan teks biasa aplikasi dan kekunci sesi aktif di asal. Hidupkan penamatan hanya apabila tepi perlu memahami dan bertindak ke atas permintaan HTTP.

Keputusan dalam satu ayat

Gunakan pemindahan TLS apabila asal mesti memiliki sempadan TLS. Gunakan penamatan TLS apabila Webship mesti menghala, melindungi, mengubah, menyimpan sementara, atau memerhati trafik HTTP.

Tiada mod yang secara universal lebih selamat. Mod pass-through mengurangkan bahan sensitif yang dikendalikan oleh edge, tetapi menghapuskan kawalan keselamatan HTTP di edge. Terminasi menambah titik penguatkuasaan yang boleh diperiksa, tetapi menjadikan Webship sebahagian daripada sempadan TLS yang dipercayai.

| Kebimbangan | Penamatan TLS | Laluan terus TLS | | --- | --- | --- | | titik akhir TLS | Webship | Asal | | Teks biasa aplikasi di Webship | Ya | Tidak | | Kekunci sesi hilir aktif di Webship | Ya | Tidak | | Laluan mengikut laluan HTTP atau kaedah | Ya | Tidak | | WAF, Perisai API, dan had badan di Webship | Ya | Tidak | | Cache proksi, penulisan semula, dan pengepala penghantaran | Ya | Tidak | | Input penghalaan TCP | Kuasa dan polisi laluan HTTP | ClientHello SNI | | HTTP/3 penghalaan | Data permintaan HTTP | Satu asal UDP yang dikongsi | | Tanggungjawab asal | HTTP atau TLS hulu yang dikonfigurasikan secara berasingan | TLS penuh, ALPN, dan tumpukan HTTP |

Soalan yang penting oleh itu bukanlah “Suis mana yang lebih pantas?” Tetapi “Komponen mana yang mesti dibenarkan melihat dan mengawal permintaan?”

Apakah penamatan yang diberikan oleh Webship

Dengan tls_termination = true, Webship menyelesaikan TLS hilir dan memasukkan permintaan yang telah disahsulit ke dalam saluran proksi terbalik HTTP-nya. Itu membolehkan ciri-ciri berikut:

• laluan, hos, dan penghalaan yang menyedari kaedah;
• Pemeriksaan WAF dan Perisai API;
• had badan permintaan dan tamat polisi;
• penyimpanan sementara proksi dan pembatalan selamat penjanaan;
• pengurusan pengepala pemajuan dan medan log capaian HTTP;
• pengendalian QUERY yang sedar badan, cuba semula apabila selamat, dan polisi pemutus litar;
• terjemahan protokol antara sambungan berhadapan pelanggan dan sambungan huluan.

Mod ini juga mengubah tanggungjawab keselamatan. Hos Webship mesti melindungi kunci peribadi sijil, kunci sesi, data permintaan dan respons yang telah diterjemahkan, output kebolehamatan, dan sebarang representasi yang di-cache. Jika hop seterusnya mesti kekal disulitkan, konfigurasikan TLS huluan berjenis secara berasingan; jika tidak, huluan HTTP adalah teks jelas.

Penamatan adalah sempadan kanan apabila Webship dijangka berfungsi sebagai tepi yang menyedari aplikasi, bukan hanya sebagai perantara pengangkutan yang disulitkan.

Apa yang disimpan oleh pass-through

Dengan tls_termination = false—lalai—Webship menghantar trafik TLS atau QUIC yang disulitkan tanpa menyahsulit permintaan atau respons HTTP. Teks jelas aplikasi dan kunci sesi aktif kekal di asal.

Sempadan kepercayaan yang lebih kecil itu bernilai ketika sijil mesti kekal di lapisan aplikasi, polisi pematuhan melarang penyahsulitan di tepi, atau identiti TLS khusus asal mesti sampai ke klien tanpa berubah. Ia juga menghilangkan kerja penguraian HTTP dan polisi daripada laluan perantara.

Pertukaran adalah ketat: Webship tidak dapat memeriksa apa yang tidak dapat ia nyahsulitkan. Ia tidak dapat menerapkan peraturan WAF HTTP, menghala berdasarkan laluan, menulis semula tajuk, menguatkuasakan polisi API yang menyedari badan, atau mengisi log akses medan HTTP. Asal perlu menyediakan semua kawalan tersebut sendiri.

Pass-through oleh itu bukanlah “penamatan dengan ciri yang lebih sedikit.” Ia adalah seni bina yang berbeza dengan pemilik keselamatan yang berbeza.

Had khusus protokol adalah penting

Untuk TLS HTTP/1.1 dan TLS HTTP/2, Webship memeriksa ClientHello hanya sejauh yang diperlukan untuk memilih destinasi TCP yang dikonfigurasi melalui SNI. Setiap domain laluan terus memerlukan laluan path_prefix = "/" tangkapan semua kerana laluan permintaan sebenar kekal disulitkan. Pelanggan tanpa SNI diterima hanya apabila konfigurasi mempunyai satu domain.

Asal mesti merundingkan ALPN klien dan menyokong protokol yang dipilih. Webship tidak dapat menukar klien HTTP/2 kepada asal HTTP/1.1 sementara sesi TLS diteruskan tanpa berubah.

HTTP/3 menggunakan QUIC melalui UDP dan mempunyai sempadan yang lebih ketat. Laluan terus tidak boleh menghala dengan selamat mengikut kuasa HTTP yang disulitkan, jadi setiap laluan HTTP/3 yang dikonfigurasikan mesti diselesaikan kepada asal UDP IP-socket yang sama. Webship menolak soket Unix dan pelbagai asal laluan terus HTTP/3 semasa pengesahan konfigurasi dan bukannya menghala secara diam-diam dengan tidak jelas.

Cleartext HTTP/1.1 dan h2c tidak terjejas oleh reverse_proxy.tls_termination. Tetapan ini mengawal HTTP/1.1 TLS huluan, HTTP/2 TLS, dan HTTP/3 TLS sahaja.

Kapasiti permintaan yang diukur

Penanda aras kapasiti Webship 1.3.1 Debian mengukur kedua-dua mod proksi terbalik terenkripsi secara berasingan. Setiap sampel yang diterima memerlukan tiada ralat HTTP, soket, protokol, proksi, kesalahan halaman utama, dan kehilangan paket HTTP/3.

| Mod ejen terbalik | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Penamatan TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | Penyaluran TLS | 203,950 RPS | 266,845 RPS | 167,010 RPS |

Laluan pass-through tindak balas kecil mempunyai kerja aplikasi yang lebih sedikit untuk dilakukan: ia menghantar data pengangkutan yang disulitkan dan bukannya menamatkan TLS, mengurai HTTP, menilai polisi, dan menghasilkan aliran TLS hiliran yang baru. Kadar permintaan pass-through yang lebih tinggi mencerminkan kerja yang lebih sempit itu.

Baris-baris ini tidak mewakili set ciri yang sama, dan ia tidak seharusnya digunakan untuk mendakwa bahawa satu seni bina keselamatan adalah lebih baik secara menyeluruh. Penamatan membayar untuk keupayaan yang menyedari HTTP yang tidak dapat disediakan oleh laluan langsung secara sengaja.

Penstriman pukal mengubah hasil

Penanda aras yang sama menggunakan badan respons 99,943,778 bait yang tepat untuk matriks penstriman 100 MB. Di sini, penamatan TLS menghasilkan kadar keluaran muatan median yang lebih tinggi untuk ketiga-tiga protokol:

| Mod proksi terbalik | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Penamatan TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | Laluan TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

Mengapa arah berubah? Dalam mod penamatan, origin penanda aras menghantar HTTP teks jelas ke Webship, dan Webship memiliki laluan pukal hiliran yang dioptimumkan. Respons besar HTTP/1.1 dan HTTP/2 boleh menggunakan Linux kTLS adaptif dan penampan terikat khusus pengangkutan. HTTP/3 menggunakan pengawalan QUIC, DPLPMTUD, dan pembungkusan per-reaktor dan bukannya kTLS.

Dalam mod laluan terus, asal memiliki TLS hiliran dan Webship menyampaikan semula aliran terenkripsi atau paket QUIC yang terhasil. Itu mengekalkan sempadan TLS asal, tetapi ia tidak boleh menggunakan laluan respons pukal yang sedar HTTP Webship.

Kelayakan HTTP/3 tujuh-sampel juga memeriksa kestabilan. Penstriman yang dihentikan mencapai median 1,938.6 MiB/s dengan pekali variasi 2.12%; laluan terus mencapai 1,748.5 MiB/s dengan pekali variasi 1.65%. Kedua-duanya menyampaikan badan yang tepat tanpa sebarang ralat klien, protokol, dan kehilangan paket.

Konfigurasikan laluan terus dengan sengaja

Konfigurasi laluan minimum mengekalkan identiti TLS dalam tahap persediaan supaya operator boleh mengaktifkan penamatan kemudian tanpa menukar laluan sijil:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Sijil Webship yang dipentaskan disahkan tetapi tidak digunakan oleh sesi pass-through aktif. Asal di 10.0.0.20:443 mesti menamatkan TLS dan menyokong protokol yang dinegosiasikan oleh klien.

Dayakan penamatan apabila tepi memerlukan HTTP

Untuk tepi yang menyedari aplikasi, aktifkan penamatan dan hantar trafik HTTP yang terhasil ke asal yang dipilih:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Konfigurasi ini boleh menghala dan memeriksa HTTP. Tambahkan TLS hulu apabila rangkaian antara Webship dan asalnya tidak dipercayai atau terasing.

Tukar mod tanpa memulakan semula Webship

Webship boleh menukar tls_termination melalui muat semula fail konfigurasi atau alat webship.reverse_proxy.apply_config MCP yang disemak versi. Baca objek dan versi semasa dengan webship.reverse_proxy.get_config, tukar hanya medan yang dimaksudkan dalam objek lengkap yang dikembalikan, dan hantar ia dengan expected_version_id yang sepadan.

Sambungan TCP baru menggunakan mod baharu. Pelanggan HTTP/3 menyambung semula ke pengangkutan UDP yang diganti. Perubahan laluan sijil dan kunci kekal terikat pada proses dan memerlukan but semula, jadi pastikan identiti penamatan yang sah disediakan sebelum penukaran langsung.

Pemeriksaan versi menghalang seorang pengendali daripada menulis ganti perubahan konfigurasi serentak. Kemaskini yang ditolak akan meninggalkan runtime aktif dan konfigurasi yang disimpan tidak berubah.

Senarai semak pemilihan yang praktikal

Pilih laluan terus apabila semua ini benar:

1. Asal mesti mengekalkan sempadan sijil dan kunci sesi.
2. Penghalaan TCP tahap SNI—atau satu asal UDP HTTP/3 yang dikongsi—adalah mencukupi.
3. Asal menyediakan WAF, kebenaran, pencatatan, had badan, dan kawalan penyalahgunaan yang diperlukan.
4. Tidak diperlukan cache tepi, penulisan semula laluan, polisi pengepala penghantaran, atau terjemahan protokol HTTP.

Pilih penamatan apabila mana-mana daripada ini diperlukan di Webship:

1. Rute mengikut hos, laluan, atau kaedah.
2. Memeriksa permintaan dengan WAF atau API Shield.
3. Kuatkuasakan had badan, masa tamat HTTP, atau pengesahan tepi.
4. Simpan jawapan dalam cache atau tulis semula header HTTP.
5. Terjemahkan antara protokol HTTP hilir dan hulu.
6. Perhatikan medan HTTP di sempadan proksi.

Mana-mana mod yang anda pilih, uji SNI, ALPN, identiti sijil, pembatalan klien, penutupan separuh huluan, dan integriti respons yang tepat. Ukur kapasiti permintaan dan aliran data secara berasingan: mod terpantas untuk respons kecil tidak semestinya mod terpantas untuk badan 100 MB.

Webship menjadikan laluan terus sebagai lalai kerana proksi tidak sepatutnya secara senyap meluaskan sempadan kepercayaannya. Penamatan kekal sebagai pilihan operasi yang hidup dan jelas apabila tingkah laku tepi yang menyedari HTTP berbaloi dengan tanggungjawab itu.

Baca keseluruhan [dokumentasi reverse-proxy](/docs/1.3.1), bandingkan [matriks penanda aras](/benchmarks) yang diterima, atau muat turun Webship dari [Muat Turun](/downloads).

Kaedah sumber dan kandungan

Nilai prestasi diterima sebagai median dari penanda aras kapasiti Debian bersatu Webship 1.3.1 bertarikh 11 September 2026; pintu penerimaannya memerlukan sifar ralat klien, HTTP, soket, protokol, proksi, major-page-fault, dan kehilangan paket HTTP/3.