2026-06-02

تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال

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

غالبًا ما تختبئ حالات فشل WebSocket خلف رسائل المتصفح أو التطبيق العامة: "فشل اتصال WebSocket"، أو "رمز استجابة غير متوقع"، أو "تم إغلاق الاتصال قبل تلقي استجابة المصافحة"، أو "101 بروتوكول تبديل مفقود"، أو "تم قطع اتصال المقبس". يبحث المستخدمون عن "فشل ترقية WebSocket pcap"، و"لم يتم إرجاع بروتوكولات التبديل 101"، و"رؤوس وكيل nginx websocket"، و"إعادة تعيين اتصال WebSocket" عندما يبدو أن HTTP يعمل ولكن حركة المرور في الوقت الفعلي لا تعمل." يمكن أن يُظهر التقاط الحزمة ما إذا كان قد تم إرسال طلب ترقية HTTP، وما إذا كان الخادم قد قام بإرجاع "101 Switching Protocols"، وما إذا كان الوكيل قد أزال الرؤوس المطلوبة، وما إذا كان TLS قد نجح، وما إذا كان الاتصال قد انقطع بعد الترقية.

تعد جراحة PCAP مفيدة لأن تتبعات WebSocket غالبًا ما تحتاج إلى كل من تأكيد اتصال HTTP والمخطط الزمني لـ TCP بعد الترقية.

كيف تبدو ترقية WebSocket الصحية

يرسل العميل طلب HTTP مع رؤوس الترقية:

GET /socket HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13

The server replies:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: ...

بعد ذلك، لم يعد الاتصال عبارة عن حركة مرور طلب/استجابة HTTP عادية. يحمل إطارات WebSocket.

فشل الترقية الشائعة

تشمل الأسباب الشائعة ما يلي:

شرائط الوكيل رأس "الترقية".
يقوم الوكيل بإزالة أو إعادة كتابة "الاتصال: الترقية".
مسار الواجهة الخلفية لا يدعم WebSocket.
يرسل إنهاء TLS طلبًا إلى المنبع الخاطئ.
تم تكوين سلوك ترقية HTTP/2 إلى HTTP/1.1 بشكل خاطئ.
تتم إعادة توجيه المصادقة بدلاً من 101.
تقوم الواجهة الخلفية بإرجاع 400 أو 403 أو 404 أو 426 أو 502 أو 504.
تتم إعادة تعيين الاتصال بعد الترقية.
تؤدي مهلة الخمول إلى إغلاق WebSocket الهادئ.

رمز الحالة والعناوين مهمان.

مشاكل رأس الوكيل

يجب على الوكلاء العكسيين إعادة توجيه رؤوس ترقية WebSocket بشكل صحيح. إذا لم تتمكن الواجهة الخلفية من رؤية Upgrade: websocket مطلقًا، فقد تتعامل مع الطلب على أنه HTTP عادي.

أدلة الحزمة:

يتضمن طلب العميل إلى الوكيل رؤوس الترقية.
طلب الوكيل إلى الواجهة الخلفية يفتقر إليها.
تقوم الواجهة الخلفية بإرجاع استجابة HTTP العادية بدلاً من 101.

هذه مشكلة في تكوين الوكيل، وليست خطأ عميل WebSocket.

TLS وSNI

بالنسبة إلى WebSocket الآمن (wss://)، يحدث TLS قبل ترقية HTTP. إذا فشل TLS، فلن تبدأ مصافحة WebSocket أبدًا. احتفظ بـ DNS وTCP وTLS ClientHello وSNI وأي تنبيه أو إعادة تعيين لـ TLS.

لا تقم بتشخيص رؤوس الترقية حتى يتم إثبات مسار TLS.

ينقطع الاتصال بعد 101

في بعض الأحيان تنجح الترقية، ثم يتم إغلاق الاتصال. وهذا فشل مختلف.

بحث:

مرسل FIN أو RST.
مدة مهلة الخمول.
نشاط WebSocket بينج/بونج.
مهلة قراءة الوكيل.
إعادة إرسال TCP.
نافذة صفر.
إعادة تشغيل عملية الواجهة الخلفية.

إذا حدث الانخفاض في فترة زمنية محددة، فمن المرجح أن تكون سياسة المهلة.

Checklist

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

الحفاظ على اتصال DNS وTCP.
تحقق من مصافحة TLS لـ wss://.
فحص رؤوس طلب ترقية العميل.
فحص حالة استجابة الخادم.
قم بتأكيد "101 Switching Protocols" إذا كان متوقعًا.
قارن طلبات العميل بالوكيل والوكيل بالواجهة الخلفية.
ابحث عن عمليات إعادة التوجيه أو ردود المصادقة.
إذا نجحت الترقية، فافحص FIN/RST/مهلة ما بعد الترقية.
احتفظ بتوقيت WebSocket ping/pong إذا كان مرئيًا.
لا تقليم إلا بعد الحفاظ على المصافحة الكاملة.

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

عادةً ما تكون حالات فشل ترقية WebSocket عبارة عن مشكلات مصافحة HTTP أو إعادة توجيه الوكيل حتى يتم إثبات "101 Switching Protocols". بعد الترقية، تصبح حالات الفشل مشكلة انتهاء مهلة TCP أو إعادة تعيينها أو بروتوكول التطبيق لفترة طويلة.

تساعد جراحة PCAP في الحفاظ على كلتا المرحلتين بحيث يمكن تتبع خطأ WebSocket الغامض إلى الرؤوس أو سلوك الوكيل أو TLS أو استجابة الواجهة الخلفية أو عمر الاتصال.

إجابة مبنية على الحزم لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال»

الإجابة المباشرة هي أن label في أداة التحليل أو رسالة التطبيق لا تكفي لتحديد السبب. ابدأ بنقطة الالتقاط واتجاه التدفق، ثم أثبت آخر حد بروتوكول نجح وأول حد فشل. في «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال» يجب أن يستطيع مراجع آخر العثور على packet أو gap أو interval الذي يدعم الجملة، وأن يعرف ما الذي يمكن أن ينفيها.

ضع الالتقاط على خريطة المسار

سجّل client وserver وأي proxy أو load balancer أو NAT أو firewall بينهما. اكتب interface ومكان الالتقاط والساعة ونظام التشغيل وهل ترى الاتجاهين. capture قرب client يثبت ما وصل إلى client، لكنه لا يثبت أن server لم يرسل شيئًا. capture قرب server يثبت الإرسال عند تلك النقطة، لكنه لا يثبت عبور المسار. إذا اختلف ملفان من نقطتين، صحّح clock offset وطابق flow tuple وTCP sequence أو معرف المعاملة قبل مقارنة الزمن.

تحقق من سلامة القياس: snap length، dropped packets، offload، capture filter،حدود ring buffer ووقت البدء. checksum غير الصحيح في capture على host قد يكون offload artifact. segment كبير قد يكون نتيجة GRO/TSO وليس packet واحدًا على السلك. packet غائب من ملف محدود لا يصبح network loss قبل إثبات أن نقطة القياس كان يجب أن تراه.

اقرأ الحدود بالترتيب

الحد	دليل النجاح	دليل الفشل المفيد
Link وIP	الاتجاه والعناوين والمسار متسقة	ARP/NDP مفقود، ICMP، MTU أو asymmetry
TCP	SYN وSYN-ACK وACK مع sequence صحيح	retransmission أو RST أو zero window أو timeout
TLS	ClientHello وServerHello وتقدم handshake	alert أو SNI/ALPN/certificate boundary
التطبيق	request كامل ورد مرتبط به	status أو gap أو إغلاق قبل الرد
تجربة المستخدم	زمن الاستجابة أو failure window	stall مرتبط بحد مثبت

توقف عند أول حد بلا دليل نجاح. إذا لم يكتمل TCP، لا تبدأ بتفسير HTTP. إذا وصل request إلى proxy ولم يظهر على upstream، فالحد يقع داخل proxy أو مساره. إذا وصل إلى upstream ولم يظهر response قبل policy timeout، افصل application delay عن فقد network بالنظر إلى ACK والتقدم في bytes.

افصل الملاحظة عن الفرضية

الملاحظة قابلة للإشارة: «أرسل client bytes حتى sequence محدد، ثم كرر المرسل segment ثلاث مرات ولم يصل ACK متقدم عند نقطة الرصد». الفرضية هي «المسار أسقط segment». قد تنفيها capture أخرى ترى ACK أو تظهر أن نقطة الالتقاط فقدت records. اكتب لكل فرضية دليلًا مؤيدًا ودليلًا يمكن أن يرفضها.

لا تجعل كلمة retransmission أو duplicate ACK حكمًا على المالك. reordering وloss وcapture artifact وreceiver delay قد تنتج علامات متشابهة. اربط direction وsequence وACK وSACK وRTT وwindow ووقت التطبيق. وفي DNS أو DHCP اربط transaction ID والعناوين والمحاولات، وفي HTTP اربط request/response، وفي TLS اربط اتجاه handshake بدل الاعتماد على لون packet.

حافظ على الأصل قبل التحرير

احسب checksum للملف الأصلي واجعله read-only في القضية. أنشئ working copy للتصفية والقص وإخفاء البيانات. سجّل كل عملية: المدخل، نوع التحويل، وقت التنفيذ، packet count قبل وبعد، checksum الناتج وسبب التغيير. إذا عدّلت timestamp أو حذفت packet، اذكر أن النسخة لم تعد مناسبة لقياس بعض التوقيت أو التسلسل.

عند إخفاء البيانات، استبدل addresses وidentifiers بصورة ثابتة حتى يبقى نفس endpoint قابلًا للتتبع. لا تحذف ports أو directions أو lengths إذا كانت ضرورية للحكم. افصل secret mapping عن التقرير المشترك. استخدم نطاق الالتقاط والتصدير لمراجعة حدود الملف، ونظرة PCAP Surgery العامة لتسليم نسخة مشتقة مع سجل قابل للتدقيق.

QA قبل نشر الإجابة

اسأل: هل العنوان والجواب يتناولان flow نفسه؟ هل كل زمن يذكر الساعة المستخدمة ونقطتي القياس؟ هل أول failure boundary محدد؟ هل alternative explanation مكتوبة؟ هل يمكن إعادة الاختبار بتغيير واحد؟ هل الأصل محفوظ؟ الإجابة الجيدة تحدد أيضًا حدودها: «يثبت هذا الملف سلوكًا قرب client خلال interval محدد؛ لا يثبت ما حدث داخل server».

كلمات Semrush لا تُوزع آليًا على المقالات. العبارة العامة الموثقة PCAP analyzer يملكها مسار المنتج وحده؛ هذه الصفحة تبقى على سؤالها التقني ولا تدعي volume أو KD غير موجود.

إجابة مباشرة وحدود القبول

الإجابة المختصرة عن «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال» هي: كيفية استكشاف أخطاء فشل ترقية WebSocket وإصلاحها باستخدام عمليات التقاط الحزم، بما في ذلك HTTP 101 ورؤوس الترقية ورؤوس الاتصال وتجريد الوكيل وTLS وإعادة التعيين ومهلات الخمول. تعامل مع هذه العبارة كنتيجة يجب التحقق منها، لا كوعد ينطبق على كل إدخال أو جهاز أو مشروع أو بيئة. النتيجة المكتملة تسجل الحالة الأولية والإجراء الدقيق والمخرج المرئي والشرط الذي يثبت اكتمال المهمة في PCAP Surgery.

إجراء يبدأ من الأدلة

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

نقطة التحقق 1: تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع ا

تعامل مع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال» كبوابة قبول مستقلة لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 2: كيفية استكشاف أخطاء فشل ترقية WebSocket وإصلاحها باستخدام عمليات التقاط الحزم، بما في ذلك

حوّل «كيفية استكشاف أخطاء فشل ترقية WebSocket وإصلاحها باستخدام عمليات التقاط الحزم، بما في ذلك HTTP 101 ورؤوس الترقية ورؤوس الاتصال وتجريد الوكيل وTLS وإعا» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 3: كيف تبدو ترقية WebSocket الصحية

تعامل مع «كيف تبدو ترقية WebSocket الصحية» كبوابة قبول مستقلة لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 4: فشل الترقية الشائعة

حوّل «فشل الترقية الشائعة» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 5: مشاكل رأس الوكيل

تعامل مع «مشاكل رأس الوكيل» كبوابة قبول مستقلة لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 6: TLS وSNI

حوّل «TLS وSNI» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 7: ينقطع الاتصال بعد 101

تعامل مع «ينقطع الاتصال بعد 101» كبوابة قبول مستقلة لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 8: Checklist

حوّل «Checklist» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 9: التشخيص النهائي

تعامل مع «التشخيص النهائي» كبوابة قبول مستقلة لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال». سجل الحالة قبل الإجراء وأول تغير ظاهر والحالة النهائية. إذا اختلفت النتيجة عن الهدف الموصوف، فارجع إلى آخر نقطة مؤكدة بدل الاستمرار اعتمادًا على افتراضات.

نقطة التحقق 10: إجابة مبنية على الحزم لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس

حوّل «إجابة مبنية على الحزم لموضوع «تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال»» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

مصفوفة القبول

النقطة	الدليل الواجب حفظه	شرط النجاح
تحليل PCAP لفشل ترقية WebSocket: 101 بروتوكولات تبديل، ورؤوس الوكيل، وTLS، وحالات انقطاع الاتصال	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
كيفية استكشاف أخطاء فشل ترقية WebSocket وإصلاحها باستخدام عمليات التقاط الحزم، بما في ذلك HTTP 101 ورؤوس الترقية ورؤوس ا	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
كيف تبدو ترقية WebSocket الصحية	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
فشل الترقية الشائعة	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
مشاكل رأس الوكيل	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة
TLS وSNI	الحالة الأولية وإجراء واحد والحالة الناتجة	يستطيع مشغل ثان تكرار النتيجة

عزل الفشل والاستعادة والتسليم

توقف عند أول حد يفشل. احتفظ بالمصدر أو المشروع أو الجلسة أو الالتقاط، وأنشئ نسخة قبل التحرير المدمر، وغيّر متغيرًا واحدًا في كل تجربة. إعادة سير واسع بعد عدة تغييرات قد تعطي نتيجة مختلفة من دون تفسير السبب.

افصل غياب الدليل عن دليل الغياب. قد تعني الشاشة الفارغة إدخالًا أو نطاقًا أو مرشحًا أو صلاحية أو جهازًا أو فترة أو حالة مشروع خاطئة. أثبت مسار الالتقاط أو الاستيراد قبل تفسير decoder أو المحرر أو التقرير أو التصدير.

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

أسئلة وأجوبة

ما أسرع بداية موثوقة؟

استخدم أصغر حالة ممثلة، واكتب النتيجة المتوقعة، وغيّر متغيرًا واحدًا. أثبت المسار الأساسي قبل إضافة المرشحات أو التأثيرات أو التعديلات أو الأتمتة أو مصدر أكبر.

ما الأدلة التي ينبغي حفظها؟

احتفظ بهوية الإدخال والإصدار والمنصة والإعدادات والإجراء الدقيق وأول انتقال غير متوقع والمخرج النهائي. أغلق المشروع أو الجلسة أو التقرير أو التصدير وأعد فتحه.

متى يجب تكرار الإجراء؟

كرره بعد تغيير مؤثر في التطبيق أو النظام أو driver أو firmware أو النموذج أو المصدر أو سير العمل. احتفظ بالحالة المقبولة السابقة كأساس مقارنة دون تعديل.

متى تصبح المهمة جاهزة للتسليم؟

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

أدلة مرتبطة

تغطي الصفحات التالية باللغة نفسها المراحل المجاورة من دون تغيير المالك القانوني لهذا الموضوع: