การสิ้นสุด TLS หรือการผ่านตรง? การเลือกขอบเขต Reverse-Proxy Webship ที่ถูกต้อง

การเลือกระหว่างการสิ้นสุด TLS (TLS termination) และการส่งผ่าน TLS (TLS pass-through) ไม่ใช่การตั้งค่าพร็อกซีเพียงผิวเผิน มันตัดสินว่าการเข้ารหัสสิ้นสุดที่ไหน ระบบใดถือกุญแจเซสชัน Webship สามารถตรวจสอบ HTTP ได้หรือไม่ และชั้นใดต้องบังคับใช้ความปลอดภัยของแอปพลิเคชัน

Webship ตั้งค่าเริ่มต้นเป็น pass-through ซึ่งช่วยให้แอปพลิเคชันข้อความธรรมดาและกุญแจเซสชันที่ใช้งานอยู่ยังคงอยู่ที่ต้นทาง เปิดใช้งานการสิ้นสุดการเชื่อมต่อก็ต่อเมื่อ edge ต้องเข้าใจและดำเนินการตามคำขอ HTTP เท่านั้น

คำตัดสินในหนึ่งประโยค

ใช้ TLS pass-through เมื่อแหล่งที่มาต้องเป็นเจ้าของขอบเขต TLS ใช้ TLS termination เมื่อ Webship ต้องกำหนดเส้นทาง ป้องกัน แปลง แคช หรือสังเกตการจราจร HTTP

ไม่มีโหมดใดที่ปลอดภัยมากกว่าโดยทั่วไป โหมดผ่านตรงช่วยลดข้อมูลที่ละเอียดอ่อนที่ขอบจัดการ แต่จะลบการควบคุมความปลอดภัย HTTP ของขอบไป การสิ้นสุดการเชื่อมต่อเพิ่มจุดบังคับใช้ที่สามารถตรวจสอบได้ แต่ทำให้ Webship เป็นส่วนหนึ่งของขอบเขต TLS ที่เชื่อถือได้

| ข้อกังวล | การสิ้นสุด TLS | การส่งต่อ TLS | | --- | --- | --- | | จุดสิ้นสุด TLS | Webship | ต้นทาง | | แอปพลิเคชันข้อความธรรมดาที่ Webship | ใช่ | ไม่ใช่ | | คีย์เซสชันดาวน์สตรีมที่ใช้งานอยู่ที่ Webship | ใช่ | ไม่ใช่ | | เส้นทางตามเส้นทาง HTTP หรือวิธี | ใช่ | ไม่ | | WAF, API Shield, และขีดจำกัดของเนื้อหาที่ Webship | ใช่ | ไม่ใช่ | | แคชพร็อกซี, การเขียนใหม่, และการส่งต่อหัวข้อ | ใช่ | ไม่ใช่ | | การกำหนดเส้นทาง TCP เข้าข้อมูล | นโยบายเส้นทางและอำนาจ HTTP | ClientHello SNI | | HTTP/3 การกำหนดเส้นทาง | ข้อมูลคำขอ HTTP | ต้นกำเนิด UDP ร่วมหนึ่ง | ความรับผิดชอบต้นทาง | HTTP หรือการกำหนดค่า TLS ของอัปสตรีมแยกต่างหาก | TLS แบบเต็ม, ALPN, และสแตก HTTP |

ดังนั้นคำถามที่สำคัญจึงไม่ใช่ 'สวิตช์ตัวไหนเร็วกว่ากัน?' แต่คือ 'ส่วนประกอบตัวไหนต้องได้รับอนุญาตให้เห็นและควบคุมคำขอ?'

การสิ้นสุดแบบใดที่ให้ Webship

ด้วย tls_termination = true Webship จะทำการ TLS ด้านปลายน้ำให้เสร็จสมบูรณ์และส่งคำขอที่ถอดรหัสแล้วเข้าสู่กระบวนการ HTTP reverse-proxy ของมัน ซึ่งทำให้คุณสมบัติดังต่อไปนี้เป็นไปได้:

• การกำหนดเส้นทางที่รับรู้เส้นทาง โฮสต์ และวิธี
• การตรวจสอบ WAF และ API Shield;
• ข้อจำกัดของร่างคำขอและเวลาหมดอายุของนโยบาย;
• การแคชพร็อกซี่และการยกเลิกที่ปลอดภัยสำหรับการสร้าง
• การจัดการหัวเรื่องการส่งต่อและฟิลด์บันทึกการเข้าถึง HTTP;
• การจัดการคำค้นที่รับรู้ร่างกาย การลองใหม่ในจุดที่ปลอดภัย และนโยบายเบรกเกอร์วงจร;
• การแปลโปรโตคอลระหว่างการเชื่อมต่อด้านลูกค้ากับการเชื่อมต่อด้านต้นน้ำ

โหมดนี้ยังเปลี่ยนความรับผิดชอบด้านความปลอดภัยด้วย โฮสต์ Webship ต้องปกป้องกุญแจส่วนตัวของใบรับรอง กุญแจเซสชัน ข้อมูลคำขอและคำตอบที่ถอดรหัสแล้ว ผลลัพธ์การสังเกตการณ์ และการแสดงผลที่แคชไว้ใด ๆ หากจุดต่อไปต้องคงการเข้ารหัส ให้กำหนดค่า TLS แบบพิมพ์เฉพาะของ upstream แยกต่างหาก มิฉะนั้น HTTP upstream จะเป็นข้อความชัดเจน

การยุติเป็นขอบเขตด้านขวาเมื่อ Webship คาดว่าจะทำงานในฐานะขอบที่รับรู้แอปพลิเคชัน ไม่ใช่เพียงแค่เป็นตัวส่งข้อมูลเข้ารหัส

สิ่งที่การผ่านตรงรักษาไว้

ด้วย tls_termination = false—ค่าเริ่มต้น—Webship ส่งต่อการรับส่งข้อมูล TLS หรือ QUIC ที่เข้ารหัสโดยไม่ถอดรหัสคำขอหรือการตอบกลับ HTTP ข้อมูลต้นฉบับของแอปพลิเคชันและคีย์เซสชันที่ใช้งานยังคงอยู่ที่ต้นทาง

ขอบเขตความน่าเชื่อถือน้อยกว่านี้มีคุณค่าเมื่อใบรับรองต้องอยู่บนชั้นแอปพลิเคชัน นโยบายการปฏิบัติตามห้ามการถอดรหัสที่ขอบเครือข่าย หรือเอกลักษณ์ TLS เฉพาะต้นทางต้องไปถึงไคลเอนต์โดยไม่ถูกเปลี่ยนแปลง นอกจากนี้ยังช่วยลดการประมวลผลการแยกวิเคราะห์ HTTP และงานด้านนโยบายจากช่องทางการส่งต่อ

ข้อแลกเปลี่ยนมีความเข้มงวด: Webship ไม่สามารถตรวจสอบสิ่งที่ไม่สามารถถอดรหัสได้ มันไม่สามารถใช้กฎ HTTP WAF, การกำหนดเส้นทางตามพาธ, การเขียนหัวข้อใหม่, การบังคับใช้นโยบาย API ที่รับรู้ร่างกาย หรือสร้างบันทึกการเข้าถึงฟิลด์ HTTP ได้ แหล่งกำเนิดต้องจัดหาการควบคุมทั้งหมดเหล่านั้นด้วยตัวเอง

ดังนั้น การผ่านจึงไม่ใช่ 'การยุติการใช้งานพร้อมฟีเจอร์น้อยลง' มันคือสถาปัตยกรรมที่แตกต่างออกไปพร้อมเจ้าของความปลอดภัยที่แตกต่างกัน

ขอบเขตเฉพาะโปรโตคอลมีความสำคัญ

สำหรับ HTTP/1.1 TLS และ HTTP/2 TLS, Webship จะตรวจสอบ ClientHello เพียงพอที่จะเลือกปลายทาง TCP ที่ตั้งค่าโดย SNI เท่านั้น โดเมนแต่ละโดเมนที่ผ่านช่องทางต้องมีเส้นทาง path_prefix = "/" แบบ catch-all เพราะเส้นทางคำขอจริงยังคงเข้ารหัสอยู่ ลูกค้าที่ไม่มี SNI จะถูกยอมรับก็ต่อเมื่อการตั้งค่ามีเพียงหนึ่งโดเมน

ต้นทางต้องต่อรอง ALPN ของลูกค้าและสนับสนุนโปรโตคอลที่เลือก Webship ไม่สามารถแปลงลูกค้า HTTP/2 เป็นต้นทาง HTTP/1.1 ขณะที่เซสชัน TLS ผ่านไปโดยไม่เปลี่ยนแปลง

HTTP/3 ใช้ QUIC ผ่าน UDP และมีขอบเขตที่เข้มงวด การส่งผ่านไม่สามารถกำหนดเส้นทางอย่างปลอดภัยตาม HTTP authority ที่เข้ารหัสได้ ดังนั้นเส้นทาง HTTP/3 ที่ตั้งค่าทุกเส้นทางต้องแก้ไขไปยังต้นทาง IP-socket UDP เดียวกัน Webship จะปฏิเสธ Unix sockets และต้นทาง HTTP/3 หลายตัวในระหว่างการตรวจสอบความถูกต้องของการกำหนดค่า แทนที่จะกำหนดเส้นทางแบบไม่ชัดเจนอย่างเงียบ ๆ.

ข้อความชัด HTTP/1.1 และ h2c ไม่ได้รับผลกระทบจาก reverse_proxy.tls_termination การตั้งค่านี้ควบคุม TLS HTTP/1.1 ที่ downstream, TLS HTTP/2, และ TLS HTTP/3 เท่านั้น

ความจุการร้องขอที่วัดได้

เกณฑ์มาตรฐานความสามารถของ Debian 1.3.1 Webship วัดโหมดรีเวิร์สพร็อกซีที่เข้ารหัสทั้งสองแบบแยกกัน ตัวอย่างที่ยอมรับแต่ละตัวต้องไม่มีข้อผิดพลาด HTTP, ซ็อกเก็ต, โปรโตคอล, พร็อกซี, การเกิดข้อผิดพลาดหน้าใหญ่ และแพ็กเก็ตสูญหาย HTTP/3

| โหมดรีเวิร์สพร็อกซี | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | การยุติ TLS | 123,344 RPS | 124,957 RPS | 131,529 RPS | | การส่งผ่าน TLS | 203,950 RPS | 266,845 RPS | 167,010 RPS |

การส่งต่อแบบตอบสนองขนาดเล็กมีงานแอปพลิเคชันน้อยลงที่จะต้องทำ: มันถ่ายทอดข้อมูลขนส่งที่เข้ารหัสแทนที่จะสิ้นสุด TLS, แยกวิเคราะห์ HTTP, ประเมินนโยบาย, และสร้างสตรีม TLS ใหม่ในฝั่งล่าง อัตราการร้องขอผ่านสูงที่มากขึ้นสะท้อนถึงงานที่แคบลงนั้น

แถวเหล่านี้ไม่ได้แสดงชุดคุณสมบัติที่เหมือนกัน และไม่ควรใช้เพื่ออ้างว่าสถาปัตยกรรมความปลอดภัยใด ๆ ดีกว่าโดยทั่วไป การสิ้นสุดการเชื่อมต่อจ่ายสำหรับความสามารถที่รับรู้ HTTP ซึ่งการส่งผ่านโดยตั้งใจไม่สามารถให้ได้

การสตรีมแบบจำนวนมากเปลี่ยนผลลัพธ์

เกณฑ์มาตรฐานเดียวกันใช้ตัวเนื้อหาการตอบสนองขนาด 99,943,778 ไบต์ที่แน่นอนสำหรับเมทริกซ์สตรีมมิ่งขนาด 100 MB ที่นี่ การยุติ TLS ทำให้เกิดอัตราการส่งข้อมูลสูงสุดกลางที่มากขึ้นสำหรับทั้งสามโปรโตคอล:

| โหมดรีเวิร์สพร็อกซี | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | การสิ้นสุด TLS | 3,585.7 MiB/วินาที | 3,355.0 MiB/วินาที | 1,938.6 MiB/วินาที | | ผ่าน TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

ทำไมทิศทางถึงเปลี่ยน? ในโหมดการสิ้นสุด แหล่งมาตรฐานส่ง HTTP แบบข้อความชัดเจนไปยัง Webship และ Webship เป็นเจ้าของเส้นทางข้อมูลจำนวนมากที่ปรับแต่งแล้วทาง downstream การตอบกลับขนาดใหญ่ของ HTTP/1.1 และ HTTP/2 สามารถใช้ kTLS แบบปรับได้ของ Linux และการบัฟเฟอร์เฉพาะการขนส่งที่จำกัด HTTP/3 ใช้การจัดจังหวะ QUIC, DPLPMTUD และการจัดกลุ่มต่อ reactor แทน kTLS

ในโหมดผ่าน Origin เป็นเจ้าของ TLS ด้านล่าง และ Webship จะส่งต่อสตรีมที่เข้ารหัสหรือแพ็กเก็ต QUIC ที่เกิดขึ้น ซึ่งช่วยรักษาขอบเขต TLS ของ Origin แต่ไม่สามารถใช้เส้นทางการตอบสนองจำนวนมากที่รู้จัก HTTP ของ Webship ได้

คุณสมบัติ HTTP/3 ของตัวอย่างเจ็ดชิ้นยังตรวจสอบความเสถียร การสตรีมที่สิ้นสุดไปถึงค่าเฉลี่ย 1,938.6 MiB/s โดยมีสัมประสิทธิ์การแปรปรวน 2.12%; การผ่านตรงไปถึง 1,748.5 MiB/s โดยมีสัมประสิทธิ์การแปรปรวน 1.65% ทั้งสองส่งมอบข้อมูลตัวเดียวกันโดยไม่มีข้อผิดพลาดของลูกค้า โปรโตคอล และแพ็กเก็ตสูญหายเลย

กำหนดค่าการส่งผ่านอย่างรอบคอบ

การกำหนดค่าผ่านแบบขั้นต่ำจะเก็บตัวตน TLS ไว้ในสถานะเตรียมการเพื่อให้ผู้ปฏิบัติงานสามารถเปิดใช้งานการยุติได้ภายหลังก็โดยไม่ต้องเปลี่ยนเส้นทางใบรับรอง:

[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

ใบรับรอง Webship ที่จัดเตรียมไว้ถูกตรวจสอบแล้ว แต่ไม่ได้ใช้โดยเซสชันผ่านตรงที่กำลังทำงาน ต้นทางที่ 10.0.0.20:443 ต้องยุติ TLS และรองรับโปรโตคอลที่ลูกค้าตกลงกัน

เปิดใช้งานการยุติเมื่อเอจต้องการ HTTP

สำหรับเอดจ์ที่รับรู้แอปพลิเคชัน ให้เปิดการยุติการเชื่อมต่อและส่งทราฟฟิก HTTP ที่เกิดขึ้นไปยังต้นทางที่เลือก:

[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

การกำหนดค่านี้สามารถจัดเส้นทางและตรวจสอบ HTTP ได้ เพิ่ม TLS บนเซิร์ฟเวอร์ต้นทางเมื่อเครือข่ายระหว่าง Webship และต้นทางยังไม่ได้รับความไว้วางใจหรือไม่ได้แยกออก

สลับโหมดโดยไม่ต้องรีสตาร์ท Webship

Webship สามารถเปลี่ยน tls_termination ผ่านการโหลดไฟล์การตั้งค่าหรือเครื่องมือ webship.reverse_proxy.apply_config MCP ที่ตรวจสอบเวอร์ชัน อ่านวัตถุปัจจุบันและเวอร์ชันด้วย webship.reverse_proxy.get_config เปลี่ยนเฉพาะฟิลด์ที่ตั้งใจในวัตถุที่ส่งกลับทั้งหมด และส่งด้วย expected_version_id ที่ตรงกัน

การเชื่อมต่อ TCP ใหม่จะใช้โหมดใหม่ HTTP/3 ลูกค้าจะเชื่อมต่อใหม่กับการขนส่ง UDP ที่ถูกแทนที่ การเปลี่ยนแปลงเส้นทางใบรับรองและกุญแจยังคงถูกจำกัดในกระบวนการและต้องรีสตาร์ท ดังนั้นควรเก็บตัวตนการสิ้นสุดที่ถูกต้องไว้ล่วงหน้าก่อนการสลับใช้งานจริง

การตรวจสอบเวอร์ชันป้องกันไม่ให้ผู้ปฏิบัติงานคนหนึ่งเขียนทับการเปลี่ยนแปลงการกำหนดค่าที่เกิดขึ้นพร้อมกัน การอัปเดตที่ถูกปฏิเสธจะทำให้การทำงานในปัจจุบันและการกำหนดค่าที่เก็บคงเดิมไม่เปลี่ยนแปลง

รายการตรวจสอบการเลือกที่ใช้ได้จริง

เลือกผ่านเมื่อทั้งหมดนี้เป็นจริง:

1. ต้นกำเนิดต้องเก็บขอบเขตของใบรับรองและคีย์ของเซสชันไว้
2. การกำหนดเส้นทาง TCP ระดับ SNI—หรือแหล่ง UDP HTTP/3 ที่ใช้ร่วมกันหนึ่งแห่ง—ก็เพียงพอแล้ว
3. ต้นทางให้ WAF การอนุญาต การบันทึก ขีดจำกัดเนื้อหา และการควบคุมการละเมิดที่จำเป็น
4. ไม่จำเป็นต้องมีแคชขอบ, การเขียนเส้นทางใหม่, นโยบายหัวข้อส่งต่อ, หรือการแปลงโปรโตคอล HTTP

เลือกการยกเลิกเมื่อมีความจำเป็นใด ๆ เหล่านี้ที่ Webship:

1. กำหนดเส้นทางตามโฮสต์, เส้นทาง, หรือวิธีการ
2. ตรวจสอบคำขอด้วย WAF หรือ API Shield
3. บังคับใช้ขีดจำกัดของร่างกาย เวลา HTTP หมดอายุ หรือการตรวจสอบสิทธิ์ที่ขอบ
4. เก็บผลลัพธ์ลงแคชหรือตั้งค่า HTTP headers ใหม่
5. แปลระหว่างโปรโตคอล HTTP แบบดาวน์สตรีมและอัพสตรีม
6. สังเกตฟิลด์ HTTP ที่ขอบเขตพร็อกซี

ไม่ว่าคุณจะเลือกโหมดใด ให้ทดสอบ SNI, ALPN, ความถูกต้องของใบรับรอง, การยกเลิกของไคลเอนต์, การปิดครึ่งทางของอัปสตรีม, และความสมบูรณ์ของการตอบสนองอย่างแม่นยำ วัดความสามารถในการส่งคำขอและความเร็วในการสตรีมแยกกัน: โหมดที่เร็วที่สุดสำหรับการตอบสนองขนาดเล็กอาจไม่ใช่โหมดที่เร็วที่สุดสำหรับข้อมูลขนาด 100 MB

Webship ตั้งค่าให้การส่งผ่านเป็นค่าเริ่มต้นเพราะพร็อกซีไม่ควรขยายขอบเขตความเชื่อถือของมันโดยไม่แจ้งให้ทราบ การยุติการเชื่อมต่อยังคงเป็นตัวเลือกการดำเนินงานที่เปิดอยู่และชัดเจนเมื่อพฤติกรรมของ edge ที่รองรับ HTTP คุ้มค่ากับความรับผิดชอบนั้น

อ่านเอกสาร [reverse-proxy](/docs/1.3.1) ฉบับเต็ม เปรียบเทียบ [benchmark matrix](/benchmarks) ที่ได้รับการยอมรับ หรือติดตั้ง Webship จาก [ดาวน์โหลด](/downloads)

แหล่งข้อมูลและวิธีการเนื้อหา

ค่าประสิทธิภาพเป็นค่ามัธยฐานที่ได้รับการยอมรับจากการทดสอบความสามารถแบบรวมเดียวของ Debian รุ่น 1.3.1 Webship ซึ่งมีวันที่ 11 กันยายน 2026; ประตูการยอมรับของมันกำหนดให้ไม่มีข้อผิดพลาดของไคลเอนต์ HTTP ซ็อกเก็ต โปรโตคอลพร็อกซี่ หน้าหลัก major-page-fault และการสูญหายของแพ็กเก็ต HTTP/3