•  untoreh الضوء

TCSplitter

نفق لتقسيم اتصال TCP أو UDP عبر اتصالات TCP متعددة

هدف

متى تريد تقسيم اتصال TCP واحد إلى عدة اتصالات؟ عادة ما تستخدم ملف نفق ليحقق العكس تماما . كانت حالة الاستخدام الخاصة بي هي التحايل على قيود النطاق الترددي في شبكة الهاتف المحمول ، لذلك تم إجراء الاختبارات باستخدام بطاقة sim مع عدم وجود المزيد من البيانات المتبقية في خطتها[1].

كيف يعمل

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

في البداية كان هناك "flings" و "lassos" ، لتقسيم عدد الاتصالات الصادرة (المنبثقة) والواردة (lassoed) ، ولكن كان هذا تجريدًا لا داعي له لأنه من الأفضل تمييز الحزم بوجهتها ، على الرغم من أن الهدف الرئيسي كان لتقديم حدود معدل مختلفة للاتصالات الصادرة والواردة ، لذلك يبدو أن الفصل بين أعلى / أسفل أمر عملي.

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

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

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

لماذا يعمل

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

ثم تحتاج إلى على الاكثر استلامpacket . لست متأكدًا مما إذا كان هذا هو ما يحدث بالفعل ، أو أن سبب عمل النفق الخاص بي هو سبب آخر. ربما من الممكن تمامًا التحقق حتى من الحزمة الأولى ، ولكن من منظور التصميم ، هذا يعني أنه سيتعين عليك التحقق كل اتصال واحد ، مما يجعل النظام أضعف من هجمات DOS ، ونعم ، يمكن بسهولة استخدام النفق الخاص بي كأداة DOS / Stress فعالة ، حيث يمكنك تقسيم البيانات إلى حزم صغيرة جدًا (مما يعني أن اتصالات TCP سيكون لها ضغط إعادة تدوير مرتفع ) ولديها مجموعة من الاتصالات كبيرة كما تريد.

أظهر الاختبار عبر منافذ مختلفة أيضًا أنه كان ممكنًا فقط بعض الموانئ ، وأن الحد كان يختلف باستمرار بين المنافذ ، مع443 تعطي إحدى النوافذ العليا ، حولها20kb ، التخمين بسببTLS تتطلب المصافحة مزيدًا من البيانات ، وأن حدود المعدل هذه ستتغير بناءً على الوقت من اليوم[2].

نتائج

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

اتضح أنه كان مجرد حد معدل لعدد اتصالات TCP التي يمكن للعميل إرسالها عبر الشبكة ، لذلك مجرد حماية DOS لا يمكنني فعل أي شيء حيالها. بعد X كميات من الاتصالات أيSYN محاولات التوقف عن تلقي مستحقاتهاACK ، وملء الأعمال المتراكمة ، وفي النهاية توقف النفق. أظهرت التجربة والخطأ أنه كان من الممكن بين4-8[3] اتصالات مفتوحة في أي وقت ، ومع MTU من500-1000 بايت يمكنك الاحتفاظ بتدفق مستمر حولها على الأقل128kbps ، إذا لم يكن البث الثابت متطلبًا ، فيمكنك تحقيق سرعات أعلى خلال فترة زمنية أقصر بحلول انفجار العديد من الاتصالات عند الطلب.

في المقابل ، (صحيح)DNS النفق يمكن أن يدفع بالكاد56kbps ويمكن أن يتم خنقها بسرعة لأنني أعتقد أن عددًا كبيرًا من طلبات DNS تبدو مشبوهة أكثر من طلبات TCP. علينا تحديد أن أtrue يقوم نفق DNS بترميز البيانات (الصادرة) عبر المجالات الفرعية الزائفة وفك تشفير البيانات (الواردة) المستلمة عن طريق الاستعلام عن سجلات DNS ، بينما في بعض الأحيان يمكن أن يُعتقد أن نفق DNS هو اتصال UDP خام عبر منفذ DNS ، والذي ربما يكون في وقت ما في الماضي ، خوادم DNS مسموح به وإعادة توجيهه بشكل صحيح.

الاستنتاجات

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

[1]عادةً عندما لا تحتوي بطاقة sim على المزيد من البيانات لتصفح الويب ، فإن طلبات الويب تعيد التوجيه إلى بوابة الالتقاط (لإخبارك بشراء المزيد من البيانات)
[2]يمكن أن توفر خطط بيانات الجوال اتصالاً أفضل خلال ساعات الليل
[3]هذا الرقم ، الذي يتماشى إلى حد ما مع التهم الأساسية المشتركة ، قد يدفعك إلى الشك في أن النواة تحد من الاتصالات بطريقة ما ، ومن المؤكد أن سيناريو الاتصالات المفتوحة لنفقنا غير عادي ، لكن ضبط مقابض لينكس لم يعط نتائج أفضل من طرفي.

نشر العلامات: