تحليل معمّق: كيف تعمل شبكات البروكسي السكنية؟ البنية التقنية موضّحة

هذا سؤال يطرحه كثيرون في صناعة البروكسي. فيما يلي شرح للبنية التقريبية الكامنة وراء كل شبكة بروكسي سكنية.

للبدء، دعنا نعرّف ما هي الشبكة السكنية: شبكة من النظراء القادرين على توجيه الحزم إلى الوجهات.

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

1. SDK

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

2. الطلبات القياسية مقابل الطلبات الموجهة عبر البروكسي

إليك كيفية توجيه طلب HTTPS قياسي (من L4 إلى L7). تُحسب قيم RTT أدناه بشكل تراكمي؛ تضيف كل طبقة إلى الإجمالي الجاري، وتفترض اتصالاً جديداً:

TCP Handshake (الخطوة: 1 RTT | التراكمي: 1 RTT)

1. يرسل المستخدم SYN إلى الوجهة

2. ترسل الوجهة SYN-ACK إلى المستخدم

3. يرسل المستخدم ACK إلى الوجهة (يمكن للبيانات أن تُرسل في هذا الجزء الأخير)

تكلفة الخطوة: 1 RTT، مما يرفع الإجمالي التراكمي الجاري إلى 1 RTT. RFC 9293.

L5/L6: (الخطوة: 1 RTT لـ TLS 1.3 / 2 RTT لـ TLS 1.2 | التراكمي: 2 RTT مع TLS 1.3 / 3 RTT مع TLS 1.2)

1. يرسل المستخدم ClientHello إلى الوجهة

2. ترسل الوجهة ServerHello وEncryptedExtensions والشهادة وCertificateVerify وFinished إلى المستخدم

تكلفة الخطوة: 1 RTT لـ TLS 1.3 الحديث (التراكمي: 2 RTT)، أو 2 RTT لـ TLS 1.2 القديم (التراكمي: 3 RTT)

منفرداً، TLS 1.3 هو مصافحة 1-RTT، وTLS 1.2 هو 2-RTT؛ الإجماليات هنا تراكمية وتشمل جولة TCP، لذلك يضيف TLS 1.2 RTT إضافياً كاملاً (3 RTT إجمالياً). يمكن لـ TLS 1.3 أيضاً إجراء 0-RTT resumption على الاتصالات المتكررة، مع مقايضة إعادة التشغيل المعروفة.

L7: طبقة التطبيق (الخطوة: 1 RTT | التراكمي: 3 RTT مع TLS 1.3 / 4 RTT مع TLS 1.2)

1. يرسل المستخدم الطلب والترويسات إلى الوجهة

2. ترسل الوجهة الرد والترويسات إلى المستخدم

تكلفة الخطوة: 1 RTT، مما يرفع الوقت النهائي لأول بايت بيانات إلى 3 RTT مع TLS 1.3 أو 4 RTT مع TLS 1.2

بمجرد إضافة بروكسي، فإنه يضيف دائماً قفزة واحدة على الأقل وبعض الكمون: المسار أطول (المستخدم → بروكسي → وجهة، والعودة)، ويضيف البروكسي وقت معالجته الخاص. ما إذا كان يضيف أيضاً جولات إضافية يعتمد على نوع البروكسي.

البروكسي المُنهي (بروكسي HTTP forward باستخدام CONNECT، أو بوابة سكنية تفتح اتصالها الخاص للأعلى) يضيف تلك الجولات: يقوم العميل بالمصافحة مع البروكسي أولاً، وبالنسبة لـ HTTPS، فإن طلب CONNECT وردّه «200 Connection Established» يشكّلان جولة بحد ذاتهما قبل أن تبدأ مصافحة TLS الشاملة من طرف إلى طرف، ثم يواصل البروكسي المصافحة صعوداً إلى الوجهة.

أما الموجّه الشفاف على L3/L4 الذي لا ينهي الاتصال فيترك المصافحات من طرف إلى طرف ولا يضيف جولات إضافية، بل فقط مسار أطول. في كلتا الحالتين، يعني المزيد من المسافة والمزيد من الوسطاء مزيداً من الكمون، وهو بالضبط ما تتناول بقية هذه المقالة تقليله.

3. مشكلة «الاختناق المروري»

الشبكات السكنية بالغة التعقيد لأن هناك فروقاً دقيقة كثيرة في توجيه الطلبات بذكاء دون إبطاء الشبكة.

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

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

4. تحسينات جانب المزود

4a. DNS ومراكز البيانات

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

4b. تحسين الطبقة 4 الداخلي

عبر عقد بوابات مراكز البيانات، يجب على الشبكة استخدام المسارات المباشرة وتوزيع البوابات عالمياً لتحقيق تغطية جيدة. وبين البوابات والنظراء، يجب على كل بوابة الحفاظ على اتصالات TCP مُسخَّنة مسبقاً واستخدام تشفير TLS المتبادل لتأمين الجهاز والبوابة معاً.

4c. تحسين الطبقة 4 الخارجي

يمكن لـ SDK الحفاظ على اتصالات TCP مُسخَّنة مسبقاً للوجهات الشهيرة لتوفير 1 RTT بين النظير والوجهة، إذ يمكن دائماً إعادة بناء طبقة التطبيق فوق اتصال TCP قائم.

4d. تكوينات المعاملات

يمكن ضبط معاملات TCP في الوقت الفعلي لجعل نقل الحزم أكثر كفاءة وتقليل استهلاك وحدة المعالجة المركزية والذاكرة بواسطة SDK. يُعدّ تقليل استهلاك الموارد أمراً بالغ الأهمية؛ فإذا أوجد SDK تجربة سلبية على جهاز النظير، ألغى الناشرون عقد SDK.

4e. خوارزمية التوجيه الذكي (القائمة على الأداء)

هذا هو التحسين الأصعب، لكن الأكثر فعالية. تحافظ الشبكة على قاعدة بيانات في الذاكرة في الوقت الفعلي عبر جميع البوابات، يمكن الاستعلام عنها فوراً للإجابة على: «أي جهاز هو الأنسب لتوجيه هذا الطلب؟»

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

4f. خوارزمية IP Capping (القائمة على السمعة)

تهتم الشبكات السكنية بالحفاظ على سمعة IP لكل وجهة. إذا كان ثلث المجموعة محظوراً من الوجهات A وB وC، فإن المستخدمين المستهدفين لتلك الوجهات يواجهون معدل خطأ بنسبة ⁦33%⁩. بتوجيه الطلبات فقط عبر الـ ⁦67%⁩ المتبقية ووضع عناوين IP المحظورة في فترة توقف، توفر الشبكة تجربة عملاء أفضل بكثير.

خوارزميات IP Capping معقدة في البناء والصيانة، لكنها تحقق تحسينات كبيرة في جودة الشبكة حين تُطبَّق بشكل صحيح.

5. تحسينات جانب العميل

5a. مراكز البيانات

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

5b. DNS

مرّر اسم المجال نفسه عوضاً عن عنوان IP المُحلَّل الخاص به. يتيح ذلك للنظير إجراء حل DNS، مما قد يؤدي إلى توجيه أكثر كفاءة. احرص دائماً على تضمين المجال في حقل SNI لضمان نجاح مصافحة TLS.

5c. الاستهداف الجغرافي

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

5d. تحسينات L4 والجلسة اللاصقة

وفقاً لمعيار الصناعة، يتم تمرير المصادقة عبر ترويسة Proxy-Authorization مشفَّرة بـ Base64، جنباً إلى جنب مع معاملات الطلب كالجلسة اللاصقة والاستهداف الجغرافي. بمجرد وصول الطلبات إلى البوابة، يتم فك تشفير هذه المعاملات وتطبيقها.

يحافظ مستخدم البروكسي الاحترافي على اتصال واحد لكل IP، ويراقب عنوان IP الخارج كل 10 إلى 20 ثانية للتأكد من أن النظير لا يزال نشطاً، ويوازن الحمل عبر النظراء بناءً على الأداء. على سبيل المثال، إذا قيّد الهدف المعدل بعد 50 طلباً، فتراجع عند 25 إلى 30، أو قم بالتدوير فور الوصول إلى الحد.

المبدأ الأساسي: حين لا يتوفر عدد كافٍ من النظراء، عظّم قدرة كل نظير من حيث حدود المعدل وسرعة الشبكة وإدارة الاختناق.

نُشر بقلم Alon Levi، الرئيس التنفيذي في FlashProxy

حول المؤلف: Alon Levi هو الرئيس التنفيذي لـ FlashProxy ولديه خبرة واسعة في البنية التحتية للبروكسي وهندسة الشبكات وتقنيات توجيه IP على نطاق واسع.  

تواصل على LinkedIn  ·  للتواصل: [email protected]

الأسئلة الشائعة

لماذا تكون البروكسيات السكنية أبطأ من بروكسيات مراكز البيانات؟

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

ما هي الجلسة اللاصقة في البروكسيات؟

تحافظ الجلسة اللاصقة على توجيه الطلبات عبر نفس عنوان IP لمدة محددة. وهي مفيدة للمهام التي تتطلب استمرارية الجلسة، كالحفاظ على حالة تسجيل الدخول أو الاحتفاظ بسلة التسوق.

لماذا يتم إدراج عناوين IP الخاصة بالبروكسيات السكنية في القائمة السوداء؟

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

ما هو نظير البروكسي؟

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

المصادر والمراجع

• IETF RFC 9293، بروتوكول التحكم في الإرسال: https://datatracker.ietf.org/doc/html/rfc9293

• IETF RFC 8446، TLS 1.3 (مصافحة 1-RTT؛ 0-RTT resumption): https://datatracker.ietf.org/doc/html/rfc8446

• IETF RFC 5246، TLS 1.2 (مصافحة 2-RTT): https://datatracker.ietf.org/doc/html/rfc5246

• IETF RFC 9110، HTTP Semantics (طريقة CONNECT): https://datatracker.ietf.org/doc/html/rfc9110

• IETF RFC 6066، TLS Server Name Indication (SNI): https://datatracker.ietf.org/doc/html/rfc6066

• IETF RFC 7235، HTTP/1.1 Authentication (Proxy-Authorization): https://datatracker.ietf.org/doc/html/rfc7235

• MDN Web Docs، HTTP CONNECT method: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT

• Cloudflare، forward-proxy latency: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/

• Cloudflare Learning Center، What is SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/

• Ilya Grigorik، High Performance Browser Networking: https://hpbn.co/