تحليل HTTP/2 GOAWAY وRST_STREAM PCAP: تصحيح أخطاء إعادة تعيين التدفقات وحدود الوكيل وفشل gRPC

قد يكون من الصعب تشخيص حالات فشل HTTP/2 لأن اتصال TCP واحد يمكنه حمل العديد من التدفقات. قد يفشل طلب واحد مع RST_STREAM، أو قد يتلقى الاتصال بالكامل GOAWAY، أو قد يُبلغ عميل gRPC عن UNAVAILABLE، أو INTERNAL، أو CANCELLED، أو إعادة تعيين الدفق. يبحث المستخدمون عن "HTTP2 GOAWAY pcap"، و"تحليل RST_STREAM"، و"التقاط حزم إعادة تعيين دفق gRPC"، و"إعادة تعيين وكيل HTTP/2"، و"استكشاف أخطاء ALPN HTTP2 وإصلاحها" عندما لا توضح السجلات ما إذا كان العميل أو الوكيل أو موازن التحميل أو الخادم قد أنهى الدفق.

تعد جراحة PCAP مفيدة لأن أدلة HTTP/2 يجب أن تحافظ على TLS وALPN وتوقيت الاتصال وإعادة تعيين الدفق وسلوك إغلاق TCP. إذا تم تشفير TLS وكانت المفاتيح غير متوفرة، فإن عمليات التقاط الحزم ستظل تعرض التوقيت، وإعادة تعيين TCP، وإعادة استخدام الاتصال، وأحيانًا فك تشفير HTTP/2 فقط في البيئات الخاضعة للرقابة.

اتصال HTTP/2 مقابل الدفق

يقوم HTTP/2 بمضاعفة تدفقات متعددة عبر اتصال واحد. إعادة تعيين الدفق ليست هي نفس إعادة تعيين اتصال TCP.

• RST_STREAM: تم إلغاء أو فشل تدفق واحد.
• GOAWAY: نقطة النهاية تغلق أو تستنزف اتصال HTTP/2.
• TCP FIN/RST: يتم إغلاق الاتصال الأساسي أو إحباطه.

غالبًا ما تقوم التطبيقات بدمج هذه الأخطاء في خطأ واحد. يجب أن تفصل أدلة الحزم والسجلات بينها.

مفاوضات ALPN

يعتمد HTTP/2 عبر TLS عادةً على ALPN. تتفاوض مصافحة TLS على "h2" أو بروتوكول آخر. إذا لم تتفاوض ALPN مع HTTP/2، فقد يتراجع العميل والخادم أو يفشلان.

يحفظ:

• ملحق ClientHello ALPN.
• ALPN المحدد بواسطة الخادم حيث يكون مرئيًا.
• تنبيهات TLS.
• تتم إعادة تعيين TCP أثناء المصافحة.

إذا لم يتم التفاوض على HTTP/2 مطلقًا، فلا تقم بتصحيح أخطاء RST_STREAM حتى الآن.

GOAWAY

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

أسئلة مهمة:

• من أرسل جوواي؟
• ما هو معرف البث الأخير؟
• هل فشلت التدفقات النشطة؟
• هل قام العميل بإعادة المحاولة على اتصال جديد؟
• هل يحدث GOAWAY في عمر الاتصال الثابت؟

RST_STREAM

ينهي RST_STREAM دفق HTTP/2 واحدًا. تشمل الأسباب ما يلي:

• إلغاء العميل.
• الخادم يرفض الطلب
• مهلة الوكيل.
• مشكلة التحكم في التدفق.
• الحد الأقصى للتدفق.
• تم تجاوز الموعد النهائي لـ gRPC.
• تمت ترجمة إعادة تعيين الواجهة الخلفية بواسطة الوكيل.

معرف الدفق والتوقيت مهمان. وبدونها، تكون قصة الحزمة غير مكتملة.

لا تزال طبقة TCP مهمة

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

ربط:

• وقت إعادة تعيين الدفق.
• إعادة إرسال TCP قبل إعادة التعيين.
• مرسل FIN/RST
• الفاصل الزمني الخمول.
• TLS Close_notify إذا كان مرئيًا.

Checklist

استخدم سير العمل هذا:

1. الحفاظ على مصافحة DNS وTCP وTLS.
2. تأكد من تفاوض ALPN على HTTP/2.
3. تحديد ما إذا كان الفشل على مستوى الدفق أو على مستوى الاتصال.
4. ابحث عن توقيت GOAWAY والمرسل.
5. ابحث عن توقيت RST_STREAM ومعرف الدفق في التتبعات أو السجلات التي تم فك تشفيرها.
6. ارتبط بسجلات الوكيل/موازن التحميل.
7. تحقق من إعادة إرسال TCP، والنافذة الصفرية، وFIN، وRST.
8. تحقق مما إذا كان العميل يعيد المحاولة بشكل صحيح.
9. الحفاظ على توقيت الحزمة عند التشذيب.
10. قم بدمج دليل pcap مع سجلات تصحيح HTTP/2 عند التشفير.

التشخيص النهائي

أخطاء HTTP/2 GOAWAY وRST_STREAM ليست حالات فشل عامة في الشبكة. إنها إشارات التحكم في التدفق والاتصال التي يجب أن ترتبط بـ ALPN وسلوك الوكيل والمواعيد النهائية لـ gRPC وصحة TCP وإعادة استخدام الاتصال.

تساعد جراحة PCAP في الحفاظ على المخطط الزمني بحيث يمكن تقليل حالات فشل HTTP/2 وgRPC إلى الطبقة الصحيحة: تفاوض TLS، أو إعادة تعيين الدفق، أو استنزاف الاتصال، أو انتهاء مهلة الوكيل، أو فشل نقل TCP.