Memilih antara terminasi TLS dan penerusan TLS bukanlah pengaturan proxy kosmetik. Ini menentukan di mana enkripsi berakhir, sistem mana yang memegang kunci sesi, apakah Webship dapat memeriksa HTTP, dan lapisan mana yang harus menegakkan keamanan aplikasi.
Webship default-nya adalah pass-through. Itu menjaga aplikasi tetap dalam bentuk teks biasa dan kunci sesi aktif di asal. Aktifkan terminasi hanya ketika edge harus memahami dan menindaklanjuti permintaan HTTP.
Keputusan dalam satu kalimat
Gunakan TLS pass-through ketika asal harus memiliki batas TLS. Gunakan TLS termination ketika Webship harus mengarahkan, melindungi, mengubah, menyimpan, atau mengamati lalu lintas HTTP.
Tidak ada mode yang secara universal lebih aman. Pass-through mengurangi material sensitif yang ditangani oleh edge, tetapi menghilangkan kontrol keamanan HTTP edge. Termination menambahkan titik penegakan yang dapat diperiksa, tetapi membuat Webship menjadi bagian dari batas TLS yang tepercaya.
| Kekhawatiran | Terminasi TLS | Lolos TLS | | --- | --- | --- | | Titik akhir TLS | Webship | Asal | | Teks aplikasi di Webship | Ya | Tidak | | Kunci sesi downstream aktif di Webship | Ya | Tidak | | Rute berdasarkan jalur atau metode HTTP | Ya | Tidak | | WAF, API Shield, dan batas tubuh di Webship | Ya | Tidak | | Cache proxy, penulisan ulang, dan penerusan header | Ya | Tidak | | Input routing TCP | Otoritas dan kebijakan rute HTTP | SNI ClientHello | | HTTP/3 routing | Data permintaan HTTP | Satu asal UDP yang dibagi | | Tanggung jawab asal | TLS upstream yang dikonfigurasi secara HTTP atau terpisah | TLS penuh, ALPN, dan stack HTTP |
Pertanyaan penting oleh karena itu bukanlah “Sakelar mana yang lebih cepat?” Melainkan “Komponen mana yang harus diizinkan untuk melihat dan mengontrol permintaan?”
Pemutusan apa yang diberikan Webship
Dengan tls_termination = true, Webship menyelesaikan TLS hilir dan memasukkan permintaan yang telah didekripsi ke dalam jalur balik HTTP-nya. Hal ini memungkinkan fitur-fitur berikut:
- routing yang sadar jalur, host, dan metode;
- Inspeksi WAF dan API Shield;
- batas-batas request-body dan batas waktu kebijakan;
- caching proxy dan invalidasi aman-generasi;
- manajemen header penerusan dan bidang log akses HTTP;
- penanganan QUERY yang sadar tubuh, percobaan ulang jika aman, dan kebijakan pemutus sirkuit;
- terjemahan protokol antara koneksi yang menghadap klien dan koneksi hulu.
Mode ini juga mengubah tanggung jawab keamanan. Host Webship harus melindungi kunci pribadi sertifikat, kunci sesi, data permintaan dan respons yang didekripsi, output observabilitas, dan setiap representasi yang di-cache. Jika hop berikutnya harus tetap terenkripsi, konfigurasikan TLS upstream bertipe secara terpisah; jika tidak, upstream HTTP bersifat teks jelas.
Terminasi adalah batas kanan ketika Webship diharapkan berperilaku sebagai edge yang sadar aplikasi, bukan hanya sebagai relay transportasi terenkripsi.
Apa yang dipertahankan melalui
Dengan tls_termination = false—default—Webship meneruskan lalu lintas TLS atau QUIC terenkripsi tanpa mendekripsi permintaan atau respons HTTP. Teks biasa aplikasi dan kunci sesi aktif tetap berada di sumber.
Batas kepercayaan yang lebih kecil itu berharga ketika sertifikat harus tetap berada di tingkat aplikasi, kebijakan kepatuhan melarang dekripsi di tepi, atau identitas TLS spesifik asal harus sampai ke klien tanpa perubahan. Ini juga menghilangkan pekerjaan parsing HTTP dan kebijakan dari jalur relay.
Komprominya bersifat ketat: Webship tidak dapat memeriksa apa yang tidak dapat didekripsinya. Itu tidak dapat menerapkan aturan WAF HTTP, mengarahkan berdasarkan jalur, menulis ulang header, menerapkan kebijakan API yang menyadari isi, atau mengisi log akses bidang HTTP. Origin harus menyediakan semua kontrol tersebut sendiri.
Pass-through oleh karena itu bukanlah 'terminasi dengan fitur yang lebih sedikit.' Ini adalah arsitektur yang berbeda dengan pemilik keamanan yang berbeda.
Batas spesifik protokol penting
Untuk HTTP/1.1 TLS dan HTTP/2 TLS, Webship memeriksa ClientHello hanya sejauh yang diperlukan untuk memilih tujuan TCP yang dikonfigurasi berdasarkan SNI. Setiap domain pass-through memerlukan rute path_prefix = "/" catch-all karena jalur permintaan yang sebenarnya tetap terenkripsi. Klien tanpa SNI hanya diterima ketika konfigurasi memiliki satu domain.
Asal harus menegosiasikan ALPN klien dan mendukung protokol yang dipilih. Webship tidak dapat mengubah klien HTTP/2 menjadi asal HTTP/1.1 sementara sesi TLS melewati tanpa berubah.
HTTP/3 menggunakan QUIC melalui UDP dan memiliki batas yang lebih ketat. Pass-through tidak dapat dengan aman merutekan berdasarkan otoritas HTTP yang terenkripsi, jadi setiap rute HTTP/3 yang dikonfigurasi harus mengarah ke asal UDP IP-socket yang sama. Webship menolak socket Unix dan beberapa asal pass-through HTTP/3 selama validasi konfigurasi daripada merutekan secara ambigu secara diam-diam.
Cleartext HTTP/1.1 dan h2c tidak terpengaruh oleh reverse_proxy.tls_termination. Pengaturan ini hanya mengontrol TLS HTTP/1.1, TLS HTTP/2, dan TLS HTTP/3 di sisi hilir.
Kapasitas permintaan yang diukur
Tolok ukur kapasitas Webship 1.3.1 Debian mengukur dua mode reverse-proxy terenkripsi secara terpisah. Setiap sampel yang diterima membutuhkan nol kesalahan HTTP, soket, protokol, proxy, major-page-fault, dan HTTP/3 packet-loss.
| Mode reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminasi TLS | 123.344 RPS | 124.957 RPS | 131.529 RPS | | Lolos TLS | 203.950 RPS | 266.845 RPS | 167.010 RPS |
Pass-through respons kecil memiliki pekerjaan aplikasi yang lebih sedikit: ia meneruskan data transport terenkripsi alih-alih mengakhiri TLS, mengurai HTTP, mengevaluasi kebijakan, dan menghasilkan aliran TLS hilir baru. Tingkat permintaan pass-through yang lebih tinggi mencerminkan pekerjaan yang lebih sempit tersebut.
Baris-baris ini tidak mewakili set fitur yang identik, dan mereka tidak boleh digunakan untuk mengklaim bahwa satu arsitektur keamanan lebih baik secara universal. Terminasi membayar untuk kemampuan yang sadar HTTP yang tidak dapat disediakan oleh pass-through secara sengaja.
Streaming massal mengubah hasil
Tolok ukur yang sama menggunakan badan respons tepat 99.943.778 byte untuk matriks streaming 100 MB. Di sini, terminasi TLS menghasilkan throughput muatan median yang lebih tinggi untuk ketiga protokol:
| Mode reverse-proxy | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | Terminasi TLS | 3.585,7 MiB/dtk | 3.355,0 MiB/dtk | 1.938,6 MiB/dtk | | TLS pass-through | 2.783,2 MiB/dtk | 2.135,0 MiB/dtk | 1.748,5 MiB/dtk |
Mengapa arah berubah? Dalam mode terminasi, asal tolok ukur mengirim HTTP dalam teks jelas ke Webship, dan Webship memiliki jalur bulk downstream yang dioptimalkan. Respon besar HTTP/1.1 dan HTTP/2 dapat menggunakan Linux kTLS adaptif dan buffering spesifik transport yang terbatas. HTTP/3 menggunakan pacing QUIC, DPLPMTUD, dan batching per-reaktor alih-alih kTLS.
Dalam mode pass-through, origin memiliki TLS hilir dan Webship meneruskan aliran terenkripsi atau paket QUIC yang dihasilkan. Itu mempertahankan batas TLS origin, tetapi tidak dapat menggunakan jalur respons massal yang sadar HTTP dari Webship.
Kualifikasi tujuh-sampel HTTP/3 juga memeriksa stabilitas. Streaming yang dihentikan mencapai median 1.938,6 MiB/s dengan koefisien variasi 2,12%; pass-through mencapai 1.748,5 MiB/s dengan koefisien variasi 1,65%. Keduanya menghasilkan body yang sama persis tanpa kesalahan klien, protokol, dan kehilangan paket.
Konfigurasikan pass-through dengan sengaja
Konfigurasi pass-through minimal menjaga identitas TLS tetap disiapkan sehingga operator dapat mengaktifkan terminasi nanti tanpa mengubah jalur sertifikat:
[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 = 30000Sertifikat Webship yang dipentaskan telah divalidasi tetapi tidak digunakan oleh sesi pass-through aktif. Origin di 10.0.0.20:443 harus mengakhiri TLS dan mendukung protokol yang dinegosiasikan oleh klien.
Aktifkan terminasi ketika edge membutuhkan HTTP
Untuk edge yang menyadari aplikasi, aktifkan terminasi dan kirimkan lalu lintas HTTP yang dihasilkan ke origin 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 = 30000Konfigurasi ini dapat mengarahkan dan memeriksa HTTP. Tambahkan TLS hulu ketika jaringan antara Webship dan origin belum dipercaya atau terisolasi.
Ganti mode tanpa memulai ulang Webship
Webship dapat mengubah tls_termination melalui pemuatan ulang file konfigurasi atau alat webship.reverse_proxy.apply_config MCP yang telah diperiksa versinya. Baca objek dan versi saat ini dengan webship.reverse_proxy.get_config, ubah hanya bidang yang dimaksud dalam objek lengkap yang dikembalikan, dan kirimkan dengan expected_version_id yang sesuai.
Koneksi TCP baru menggunakan mode baru. Klien HTTP/3 menyambung kembali ke transport UDP yang diganti. Perubahan jalur sertifikat dan kunci tetap terkait proses dan memerlukan restart, jadi simpan identitas terminasi yang valid sebelum melakukan pergantian secara langsung.
Pemeriksaan versi mencegah satu operator menimpa perubahan konfigurasi yang sedang berjalan secara bersamaan. Pembaruan yang ditolak membuat runtime aktif dan konfigurasi yang disimpan tetap tidak berubah.
Daftar periksa seleksi yang praktis
Pilih pass-through ketika semua ini benar:
- Asal harus mempertahankan batas sertifikat dan kunci sesi.
- Routing TCP tingkat SNI—atau satu asal UDP HTTP/3 yang dibagikan—sudah cukup.
- Asal menyediakan WAF, otorisasi, pencatatan, batasan tubuh, dan kontrol penyalahgunaan yang diperlukan.
- Tidak diperlukan cache tepi, penulisan ulang jalur, kebijakan header penerusan, atau terjemahan protokol HTTP.
Pilih penghentian saat salah satu dari ini diperlukan di Webship:
- Rute berdasarkan host, jalur, atau metode.
- Periksa permintaan dengan WAF atau API Shield.
- Terapkan batasan badan, batas waktu HTTP, atau otentikasi tepi.
- Simpan respons di cache atau tulis ulang header HTTP.
- Terjemahkan antara protokol HTTP hilir dan hulu.
- Amati bidang HTTP di batas proxy.
Mode mana pun yang Anda pilih, uji SNI, ALPN, identitas sertifikat, pembatalan klien, setengah-tutup hulu, dan integritas respons yang tepat. Ukur kapasitas permintaan dan throughput streaming secara terpisah: mode tercepat untuk respons kecil tidak selalu merupakan mode tercepat untuk body 100 MB.
Webship membuat pass-through menjadi default karena sebuah proxy tidak boleh diam-diam memperluas batas kepercayaannya. Terminasi tetap menjadi pilihan operasional langsung dan eksplisit ketika perilaku edge yang sadar HTTP sepadan dengan tanggung jawab tersebut.
Baca seluruh [dokumentasi reverse-proxy](/docs/1.3.1), bandingkan [matriks tolok ukur](/benchmarks) yang diterima, atau unduh Webship dari [Unduhan](/downloads).
Metode sumber dan konten
Nilai kinerja adalah median yang diterima dari tolok ukur kapasitas Debian terpadu Webship 1.3.1 tanggal 11 September 2026; gerbang penerimaannya memerlukan nol kesalahan klien, HTTP, soket, protokol, proxy, major-page-fault, dan HTTP/3 kehilangan paket.