إصلاح اتصال TCP

يعد ترحيل حاوية قيد التشغيل من مضيف فعلي إلى آخر مهمة صعبة على العديد من المستويات. تزداد الأمور صعوبة إذا كان للحاوية ، كما هو مرجح ، اتصالات شبكة نشطة لعمليات خارج تلك الحاوية. Il est naturel de vouloir que ces connexions suivent le conteneur vers son nouvel hôte, de préférence sans même que l'extrémité distante remarque que quelque chose a changé, mais la pile réseau Linux n'a pas été écrite avec ce genre de mouvement à l 'روح. ومع ذلك ، يبدو أنه سيتم دعم نقل اتصال الشبكة الشفاف ، في شكل تصحيحات إصلاح اتصال TCP الخاصة بـ Pavel Emelyanov ، في kernel 3.5.

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

مع تصحيح Pavel ، يتوفر هذا الدعم للعمليات ذات الامتيازات المناسبة. للبحث في طرق عمل اتصال الشبكة النشط ، يجب على مساحة المستخدمين وضع المقبس المرتبط في "وضع الإصلاح" الجديد. يتم ذلك باستخدام استدعاء نظام setsockopt () ، باستخدام خيار TCP_REPAIR الجديد. تغيير حالة وضع الإصلاح لعملية يتطلب القدرة CAP_NET_ADMIN؛ يجب أيضًا أن يكون المقبس مغلقًا أو في حالة "ثابتة". بمجرد أن يكون المقبس في وضع الإصلاح ، يمكن معالجته بعدة طرق.

أحدهما هو قراءة محتويات قوائم انتظار الإرسال والاستلام. تحتوي قائمة انتظار الإرسال على بيانات لم يتم إرسالها بنجاح إلى الطرف البعيد ؛ أن البيانات يجب أن تتحرك مع الاتصال حتى يمكن نقلها من الموقع الجديد. قائمة انتظار الاستلام ، بدلاً من ذلك ، تحتوي على البيانات المستلمة من الطرف البعيد والتي لم يستهلكها التطبيق المنقول بعد ؛ يجب أيضًا نقل هذه البيانات بحيث تنتظر المضيف الجديد عندما يبدأ التطبيق في قراءتها. الحصول على محتويات قوائم الانتظار هذه هو عملية من خطوتين: (1) استدعاء setsockopt (TCP_REPAIR_QUEUE) باستخدام TCP_RECV_QUEUE أو TCP_SEND_QUEUE ، ثم (2) استدعاء recvmesg () لقراءة محتويات قائمة الانتظار المحددة.

اتضح أن هناك جزءًا واحدًا آخر من المعلومات المهمة التي لا يمكن الحصول عليها بالفعل من مساحة المستخدم: الحد الأقصى لقيمة MSS (الحد الأقصى لحجم المقطع) الذي تم التفاوض عليه بين نقطتي النهاية في وقت إنشاء الاتصال. لإتاحة هذه القيمة ، يغير تصحيح Pavel دلالات خيار مأخذ TCP_MAXSEG (لـ getockopt ()) عندما يكون الاتصال في وضع الإصلاح: يُرجع قيمة MSS القصوى "clamp" بدلاً من القيمة النشطة حاليًا.

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

ثم هناك مسألة إنشاء الاتصال على المضيف الجديد. يتم ذلك عن طريق إنشاء مقبس جديد ووضعه على الفور في وضع الإصلاح. يمكن بعد ذلك ربط المقبس برقم المنفذ الصحيح ؛ يتم تعليق عدد من عمليات التحقق من رقم المنفذ العادي أثناء وجود المقبس في وضع الإصلاح. يتم تشغيل استدعاء setockopt () TCP_REPAIR_QUEUE مرة أخرى ، ولكن هذه المرة يتم استخدام sendmsg () لاستعادة محتويات قوائم انتظار الإرسال والاستلام.

مهمة أخرى مهمة هي استعادة أرقام التسلسل للإرسال والاستلام. عادة ما يتم إنشاء هذه الأرقام بشكل عشوائي عند إنشاء الاتصال ، ولكن لا يمكن القيام بذلك عند نقل الاتصال. يمكن تعيين هذه الأرقام باستدعاء آخر لـ setsockopt () ، هذه المرة باستخدام خيار TCP_QUEUE_SEQ. تنطبق هذه العملية على قائمة الانتظار المحددة مسبقًا باستخدام TCP_REPAIR_QUEUE ، لذلك من الأفضل أن يتم تجديد محتويات قائمة الانتظار وتعيين رقم تسلسلها في نفس الوقت.

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

بمجرد استعادة المقبس إلى حالة تقارب تلك التي كانت موجودة على المضيف القديم ، فقد حان الوقت لاستخدامه. عند الاتصال () هو ج ...