إنهاء TLS أم التمرير المباشر؟ اختيار الحد المناسب لوكيل عكسي Webship

اختيار بين إنهاء TLS وتمرير TLS ليس إعداد واجهة تجميلية للوكيل. إنه يحدد أين تنتهي التشفير، وأي نظام يحتفظ بمفاتيح الجلسة، وما إذا كانWebship يمكن فحص HTTP، وأي طبقة يجب أن تفرض أمان التطبيق.

Webship يعود إلى الوضع الافتراضي للتجاوز. هذا يحافظ على نص التطبيق والمفاتيح الفعّالة للجلسة في المصدر. قم بتمكين الإنهاء فقط عندما يجب على الطرف النهائي فهم طلب HTTP والتصرف بناءً عليه.

القرار في جملة واحدة

استخدم تمرير TLS عندما يجب أن يكون المصدر هو مالك حدود TLS. استخدم إنهاء TLS عندماWebship يجب توجيه أو حماية أو تحويل أو تخزين أو مراقبة حركة مرور HTTP.

لا توجد طريقة أكثر أمانًا عالميًا. يقلل تمرير البيانات من المواد الحساسة التي يتم التعامل معها عند الطرف، لكنه يزيل ضوابط الأمان الخاصة بـ HTTP عند الطرف. الإنهاء يضيف نقطة تنفيذ قابلة للفحص، لكنه يجعلWebship جزء من حدود TLS الموثوقة.

| القلق | إنهاء TLS | تمرير TLS | | --- | --- | --- | | نقطة نهاية TLS |Webship | الأصل | | نص التطبيق عند Webship | نعم | لا | | مفاتيح الجلسة النشطة للجهاز التابع عند Webship | نعم | لا | | الطريق حسب مسار HTTP أو الطريقة | نعم | لا | | الجدار الناري لتطبيقات الويب، درع API، وحدود الجسم عند Webship | نعم | لا | | ذاكرة التخزين المؤقت للوكيل، وإعادة الكتابة، وإعادة توجيه الرؤوس | نعم | لا | | إدخال توجيه TCP | سلطة HTTP وسياسة المسار | ClientHello SNI | | HTTP/3 التوجيه | بيانات طلب HTTP | أصل UDP مشترك واحد | | مسؤولية المصدر | HTTP أو تكوين TLS المسبق بشكل منفصل | TLS كامل، وALPN، ومكدس HTTP |

لذلك، السؤال المهم ليس 'أي مفتاح أسرع؟' بل 'أي مكوّن يجب السماح له برؤية الطلب والتحكم فيه؟'

ما النوع الذي يعطيWebship

معtls_termination = true, Webship يُكمل TLS في الجانب الآخر ويُدخل الطلب المفكَّك التشفير في خط أنابيب البروكسي العكسي الخاص بـ HTTP. ذلك يجعل الميزات التالية ممكنة:

• توجيه مدرك للمسار والمضيف والطريقة؛
• فحص WAF ودرع API;
• حدود جهة الطلب ومهلة السياسات؛
• تخزين البروكسي المؤقت وإبطال الأمان عند التوليد
• إدارة رأس إعادة التوجيه وحقول سجل وصول HTTP؛
• معالجة الاستعلام الواعية للجسم، وإعادة المحاولة حيثما كان آمنًا، وسياسة قاطع الدائرة؛
• ترجمة البروتوكول بين الاتصالات المواجهة للعميل والاتصالات الصاعدة.

يغير هذا الوضع أيضًا مسؤولية الأمان. الWebship يجب على المضيف حماية مفتاح الشهادة الخاص ومفاتيح الجلسة وبيانات الطلبات والاستجابات المفكوكة ونتائج الرصد وأي تمثيل مخزن مؤقتًا. إذا كان يجب أن يظل القفز التالي مشفرًا، فقم بتكوين TLS الصاعد من النوع بشكل منفصل؛ وإلا فإن الصاعد HTTP يكون نصًا واضحًا.

الإنهاء هو الحد الأيمن عندماWebship من المتوقع أن يتصرف كحافة واعية بالتطبيق، وليس فقط كوسيط نقل مشفر.

ما يحتفظ به المرور

معtls_termination = false—الافتراضي—Webship يقوم بتمرير حركة مرور TLS أو QUIC المشفرة دون فك تشفير طلب HTTP أو الاستجابة. تبقى البيانات النصية للتطبيق ومفاتيح الجلسة النشطة في المصدر.

حدود الثقة الأصغر تلك ذات قيمة عندما يجب أن تظل الشهادات في طبقة التطبيق، أو تمنع سياسة الامتثال فك التشفير على الحافة، أو يجب أن تصل هوية TLS الخاصة بالأصل إلى العميل دون تغيير. كما أنها تزيل معالجة HTTP والعمل على السياسات من مسار الترحيل.

المقابل صارم:Webship لا يمكن فحص ما لا يمكن فك تشفيره. لا يمكنه تطبيق قواعد WAF الخاصة بـ HTTP، أو التوجيه حسب المسار، أو إعادة كتابة الرؤوس، أو فرض سياسة API الواعية بالمحتوى، أو ملء سجلات الوصول لحقول HTTP. يجب على المصدر توفير كل هذه الضوابط بنفسه.

لذلك، فإن مرور البيانات ليس "إنهاء مع ميزات أقل." إنه بنية مختلفة مع مالك أمني مختلف.

حدود محددة للبروتوكول مهمة

لـHTTP/1.1 TLS وHTTP/2 TLS، Webship يفحص ClientHello فقط بما يكفي لاختيار وجهة TCP المكونة بواسطة SNI. كل نطاق تمرير مباشر يحتاج إلى نطاق شاملpath_prefix = "/" المسار لأنه تبقى مسار الطلب الفعلي مشفرًا. يتم قبول العميل بدون SNI فقط عندما يحتوي التكوين على مجال واحد.

يجب على المصدر التفاوض على ALPN الخاص بالعميل ودعم البروتوكول المحدد.Webship لا يمكن تحويل HTTP/2 العميل إلىHTTP/1.1 الأصل بينما تمر جلسة TLS دون تغيير.

HTTP/3 يستخدم QUIC عبر UDP وله حدود أكثر صرامة. لا يمكن لتمرير البيانات التوجيه بأمان حسب سلطة HTTP المشفرة، لذا كل تكوينHTTP/3 يجب أن تحل المسار على نفس مقبس IP-UDP الأصلي.Webship يرفض مقابس يونكس والمتعددHTTP/3 تمرير الأصول أثناء التحقق من صحة التكوين بدلاً من توجيهها بصمت بشكل غامض.

نص واضحHTTP/1.1 و h2c غير متأثرة بـreverse_proxy.tls_termination. الإعداد يتحكم في التيار السفليHTTP/1.1 TLS، HTTP/2 TLS، وHTTP/3 TLS فقط.

سعة الطلب المقاسة

الWebship 1.3.1 قياس سعة ديبيان قام بقياس وضعيّ الوكيل العكسي المشفّر بشكل منفصل. كل عينة مقبولة تطلبت صفر HTTP، وصفر مقبس، وصفر بروتوكول، وصفر وكيل، وصفر خطأ صفحة رئيسي، وHTTP/3 أخطاء فقدان الحزم.

| وضع البروكسي العكسي |HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | إنهاء TLS | 123,344 طلب في الثانية | 124,957 طلب في الثانية | 131,529 طلب في الثانية | | تمرير TLS | 203,950 طلب في الثانية | 266,845 طلب في الثانية | 167,010 طلب في الثانية |

تمرير الاستجابة الصغيرة يتطلب عملًا أقل من جانب التطبيق: فهو ينقل بيانات النقل المشفرة بدلاً من إنهاء TLS، أو تحليل HTTP، أو تقييم السياسة، أو إنتاج поток TLS جديد للأسفل. تعكس معدلات طلبات التمرير الأعلى تلك المهمة الأضيق.

هذه الصفوف لا تمثل مجموعات ميزات متطابقة، ولا يجب استخدامها للادعاء بأن بنية أمان واحدة أفضل بشكل شامل. يوفر الإنهاء ميزات تعتمد على HTTP التي لا يمكن أن توفرها خاصية العبور عن قصد.

البث الجماعي يغير النتيجة

استخدم نفس المعيار جسد استجابة بحجم 99,943,778 بايت بالضبط لمصفوفة البث البالغ حجمها 100 ميغابايت. هنا، أدى إنهاء TLS إلى إنتاج معدل نقل حمولة أعلى بالنص المتوسط لجميع البروتوكولات الثلاثة:

| وضع البروكسي العكسي |HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | إنهاء TLS | 3,585.7 ميبي/ث | 3,355.0 ميبي/ث | 1,938.6 ميبي/ث | | تمرير TLS | 2,783.2 ميبي/ث | 2,135.0 ميبي/ث | 1,748.5 ميبي/ث |

لماذا يتغير الاتجاه؟ في وضع الإنهاء، يرسل مصدر المعيار HTTP نص واضح إلىWebship، وWebship يمتلك مسار التدفق الجماعي المحسّن للأسفل. كبيرHTTP/1.1 وHTTP/2 يمكن للاستجابات استخدام kTLS لينكس التكيفية وتخزين مؤقت محدد النقل.HTTP/3 يستخدم التدرج الزمني في QUIC، وDPLPMTUD، وتجميع لكل مفاعل بدلاً من kTLS.

في وضع التمرير، يمتلك المصدر TLS الموجه للأسفل وWebship يقوم بإيصال التدفق المشفر الناتج أو حزم QUIC. هذا يحافظ على الحد الأصلي لـ TLS، لكنه لا يمكنه استخدامWebshipمسار الاستجابة الجماعية الواعي ببروتوكول HTTP الخاص به.

العينة السبعHTTP/3 تم التحقق من الاستقرار أيضًا في التأهيل. وصلت البث المنتهي إلى متوسط 1,938.6 ميبيبايت/ثانية مع معامل تباين 2.12٪؛ وصل المرور المباشر إلى 1,748.5 ميبيبايت/ثانية مع معامل تباين 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—أو واحد مشتركHTTP/3 أصل UDP — يكفي.
3. المصدر يوفر جدار الحماية لتطبيقات الويب (WAF) الضروري، والتفويض، وتسجيل الأحداث، وحدود حجم المحتوى، وضوابط إساءة الاستخدام.
4. لا حاجة لذاكرة تخزين الحافة أو إعادة كتابة المسار أو سياسة ترويسة التوجيه أو ترجمة بروتوكول HTTP.

اختر الإنهاء عندما يكون أي من هذه مطلوبًا فيWebship:

1. التوجيه حسب المضيف أو المسار أو الطريقة.
2. فحص الطلبات باستخدام جدار حماية التطبيقات أو درع API.
3. فرض حدود الجسم، أو مهلات HTTP، أو المصادقة عند الحافة.
4. تخزين الردود مؤقتًا أو إعادة كتابة رؤوس HTTP.
5. الترجمة بين بروتوكولات HTTP الهابطة والصاعدة.
6. راقب حقول HTTP عند حدود الوكيل.

أيًا كانت الوضعية التي تختارها، اختبر SNI و ALPN وهوية الشهادة وإلغاء العميل والإغلاق النصفي للأعلى وسلامة الاستجابة الدقيقة. قس سعة الطلبات ومعدل نقل البيانات المتدفقة بشكل منفصل: الوضع الأسرع للاستجابة الصغيرة ليس بالضرورة هو الأسرع لكتلة بحجم 100 ميجابايت.

Webship يجعل التمرير هو الافتراضي لأن الوكيل لا ينبغي أن يوسع حدود الثقة بصمت. يبقى الإنهاء خيارا تشغيليا صريحا وحيا عندما يكون سلوك الحافة الواع ب HTTP يستحق هذه المسؤولية.

اقرأ المستندات الكاملة لـ [الوكيل العكسي](/docs/1.3.1)، قارن [مصفوفة المعايير](/benchmarks) المقبولة، أو قم بالتنزيل Webship من [التنزيلات](/downloads).

المصادر وطريقة المحتوى

قيم الأداء هي الوسيطات المقبولة من Webship 1.3.1 معيار سعة ديبيان الموحد بتاريخ 11 سبتمبر 2026؛ تتطلب بواباته للموافقة عدم وجود عميل، HTTP، مقبس، بروتوكول، وكيل، خطأ في الصفحة الرئيسية، وHTTP/3 أخطاء فقدان الحزم.