مقال من فئة "الملاحظات الهامشية".
في أحد المشاريع ، بعد تغيير بعض منطق الواجهة الخلفية الداخلية ، بدأت في ملاحظة رمز استجابة غريب في السجلات ، أي 0. في السجلات ، يبدو الأمر كما يلي:
{ "timestamp": "2020-01-17T08:41:51+00:00", "remote_addr": "zzz.zzz.zzz.zzz", "request_time": 0, "upstream_response_time": "", "upstream_header_time": "", "http_accept_language": "-language", "response_status": 0, "request": "", "host": "example.com", "upstream_addr": "", "http_referrer": "", "request_length": 5854, "bytes_sent": 0, "http_user_agent": "" }
قراءة الوثائق وغوغل حول هذا الموضوع أعطى شيئا على الإطلاق - لأن يقال أن هذا السلوك يحدث عندما أغلق العميل الاتصال دون تمرير الرؤوس. حسنًا ، أنواع غريبة مختلفة بحجم المخزن المؤقت لـ wsgi_ ، والتي في حالتنا لم تتناسب مع كلمة "لا مفر منها".
بشكل عام ، قرروا أن المشكلة ليست مشكلة ، نظرًا لحقيقة أنها ليست حرجة على الإطلاق.
بالضبط حتى أذهلتني المشكلة التالية: في بعض الحالات ، تفتح الروابط دون مشاكل عبر http ، لكن ترفض تمامًا العمل عبر https ، مما يعطي رائعة: اتصال # 0 لاستضافة example.com بقي على حاله
حليقة: (52) رد فارغ من الخادم
كان من الممكن تتبع هذا الشيء في سجلات فقط عن طريق IP - لم يكن هناك طلب أو أي بيانات أخرى ، كما يتضح من المثال أعلاه. فقط الحالة سيئة السمعة 0 ، لكنني أعرف أنني لم يقطع الطلب! بدأت في اختيار ما يمكن أن يحدث خطأ. واتضح أن كل شيء بسيط للغاية:
استمع 443 ss http2 backlog = 8192؛حسنًا ، إذا كنت تستخدم http2 لاتصالات ssl ، فلا يكفي فقط لتهيئة مخازن الطلب المؤقتة ، بل يجب عليك أيضًا تكوينها في ngx_http_v2_module ، وهي:
: http2_max_field_size ; : http2_max_field_size 4k; : http, server
يحدد الحد الأقصى لحجم رأس الطلب مضغوطًا باستخدام HPACK. ينطبق القيد بالتساوي على كل من الاسم والقيمة. إذا تم استخدام ترميز Huffman ، فقد يكون الحجم الفعلي للسلاسل غير المحزمة من الاسم والقيمة أكبر. القيد الافتراضي مناسب لمعظم الاستعلامات.بشكل عام ، هذا هو عليه. ولماذا؟ لأن طول الرابط كان طويلاً - أكثر من نفس 4K.
وضعه في ، على سبيل المثال ، 8 كيلو بايت (أو بقدر ما يكفي) - نحل المشكلة.
مثل هذه الأشياء.