ضبط أداء TCP/IP لأجهزة Azure الظاهرية
تتناول هذه المقالة تقنيات ضبط أداء TCP/IP الشائعة وبعض الأشياء التي يجب مراعاتها عندما تستخدمها للأجهزة الظاهرية التي تعمل على Azure. وسيوفر لمحة عامة أساسية عن التقنيات ويستكشف كيف يمكن ضبطها.
تقنيات ضبط TCP/IP الشائعة
وحدة MTU، والتجزئة، وإلغاء تحميل الإرسال الكبير
وحدة MTU
وحدة الإرسال القصوى (MTU) هي أكبر إطار (حزمة) حجم بالبايت، يمكن إرساله عبر واجهة شبكة. وحدة MTU هو إعداد قابل للتكوين. وحدة MTU الافتراضية المستخدمة على أجهزة Azure الظاهرية، والإعداد الافتراضي على معظم أجهزة الشبكات على مستوى العالم هو 1,500 بايت.
التجزئة
تحدث التجزئة عند إرسال حزمة تتجاوز وحدة MTU لواجهة شبكة. سيقوم مكدس TCP/IP بتقسيم الحزمة إلى قطع (أجزاء) أصغر تتوافق مع وحدة MTU للواجهة. تحدث التجزئة عند طبقة IP وهي مستقل عن البروتوكول الأساسي (مثل TCP). عندما يتم إرسال حزمة 2,000 بايت عبر واجهة شبكة مع وحدة MTU من 1,500، سيتم تقسيم الحزمة إلى حزمة واحدة 1,500 بايت وحزمة واحدة 500 بايت.
يمكن لأجهزة الشبكة في المسار بين مصدر ووجهة إما إسقاط الحزم التي تتجاوز MTU أو تجزئة الحزمة إلى أجزاء أصغر.
بت "عدم التجزئة" في حزمة IP
بت عدم التجزئة (DF) هو علامة في عنوان بروتوكول IP. يشير بت DF إلى أن أجهزة الشبكة الموجودة على المسار بين المرسل والمستقبل يجب ألا تقوم بتجزئة الحزمة. يمكن تعيين هذا البت لأسباب كثيرة. (راجع قسم "اكتشاف وحدة MTU للمسار" من هذه المقالة للحصول على مثال واحد.) عندما يتلقى جهاز شبكة حزمة تحتوي على تعيين بت "عدم التجزئة"، وتتجاوز تلك الحزمة وحدة MTU لواجهة الجهاز، فإن السلوك القياسي هو أن يقوم الجهاز بإسقاط الحزمة. يرسل الجهاز رسالة "تجزئة ICMP مطلوبة" مرة أخرى إلى المصدر الأصلي للحزمة.
الآثار المترتبة على أداء التجزئة
يمكن أن تكون للتجزئة آثار سلبية على الأداء. أحد الأسباب الرئيسية للتأثير على الأداء هو تأثير وحدة المعالجة المركزية/الذاكرة على تجزئة الحزم وإعادة تجميعها. عندما يحتاج جهاز شبكة إلى تجزئة حزمة، سيتعين عليه تخصيص موارد وحدة المعالجة المركزية/الذاكرة لإجراء التجزئة.
يحدث الشيء نفسه عند إعادة تجميع الحزمة. يجب أن يخزن جهاز الشبكة جميع الأجزاء حتى يتم استلامها حتى يتمكن من إعادة تجميعها في الحزمة الأصلية.
Azure والتجزئة
لا تتم معالجة الحزم المجزأة في Azure بواسطة الشبكات المتسارعة. عندما يتلقى الجهاز الظاهري حزمة مجزأة، ستتم معالجتها عبر المسار غير المتسارع. وهذا يعني أن الحزم المجزأة لن تحصل على فوائد الشبكات المتسارعة (زمن انتقال أقل، وتشويه منخفض، وحزم أعلى في الثانية). لهذا السبب، نوصي بتجنب التجزئة إن أمكن.
بشكل افتراضي، سيسقط Azure من أجزاء الطلب، أي الحزم المجزأة التي لا تصل إلى الجهاز الظاهري بالترتيب الذي تم إرسالها من نقطة نهاية المصدر. قد يحدث هذا عندما يتم إرسال الحزم عبر الإنترنت أو شبكات WAN الأخرى الكبيرة. يمكن تمكين إعادة ترتيب أجزاء خارج الترتيب في بعض الحالات. إذا تطلب أحد التطبيقات ذلك، فافتح حالة دعم.
ضبط وحدة MTU
لا نوصي العملاء بزيادة MTU على NIC VM. إذا احتاج الجهاز الظاهري إلى الاتصال بالوجهات غير الموجودة في الشبكة الظاهرية التي تحتوي على مجموعة MTU مماثلة، من المحتمل أن تحدث التجزئة التي ستخفض الأداء.
إلغاء تحميل الإرسال الكبير
يمكن لإلغاء تحميل الإرسال الكبير (LSO) أن يؤدي إلى تحسين أداء الشبكة عن طريق إلغاء تحميل تجزئة الحزم إلى معن Ethernet. عند تمكين LSO، يقوم مكدس TCP/IP بإنشاء حزمة TCP كبيرة وإرسالها إلى معن Ethernet لتقسيمها قبل إعادة توجيهها. تتمثل فائدة LSO في أنه يمكنه تحرير وحدة المعالجة المركزية من تقسيم الحزم إلى أحجام تتوافق مع وحدة MTU وإلغاء تحميل تلك المعالجة إلى واجهة Ethernet حيث يتم تنفيذها في الأجهزة. لمعرفة المزيد عن فوائد LSO، راجع دعم إلغاء تحميل الإرسال الكبير.
عند تمكين LSO، قد يرى عملاء Azure أحجام إطارات كبيرة عند إجرائهم لعمليات التقاط الحزم. قد تؤدي أحجام الإطارات الكبيرة هذه ببعض العملاء إلى الاعتقاد بأن التجزئة تحدث أو أنه يتم استخدام وحدة MTU كبيرة عند عدم استخدامها. باستخدام LSO، يمكن لمعن Ethernet الإعلان عن حجم شريحة أقصى (MSS) أكبر إلى مكدس TCP/IP لإنشاء حزمة TCP أكبر. ثم تتم إعادة توجيه هذا الإطار غير المجزأ بالكامل إلى معن Ethernet وسيظهر في التقاط حزمة يتم إجراؤه على الجهاز الظاهري. ولكن سيتم تقسيم الحزمة إلى العديد من الإطارات الأصغر بواسطة محول Ethernet، وفقا لمحول Ethernet MTU.
تحجيم نافذة TCP MSS وPMTUD
الحد الأقصى لحجم مقطع TCP
الحد الأقصى لحجم مقطع (MSS) في TCP هو إعداد يحد من حجم مقاطع TCP، ما يتجنب تجزئة حزم TCP. ستستخدم أنظمة التشغيل عادةً هذه الصيغة لتعيين MSS:
MSS = MTU - (IP header size + TCP header size)
عنوان IP وعنوان TCP بحجم 20 بايت لكل منهما، أو بإجمالي 40 بايت. لذلك، فإن واجهة مع MTU من 1500 سيكون MSS من 1460. لكن حجم MSS قابل للتكوين.
يتم الاتفاق على هذا الإعداد في تأكيد الاتصال الثلاثي لبروتوكول TCP عند إعداد جلسة TCP بين مصدر ووجهة. يرسل كلا الجانبين قيمة MSS، ويتم استخدام الجزء الأقل من الاثنين في اتصال TCP.
ضع في اعتبارك أن وحدات MTU الخاصة بالمصدر والوجهة ليست هي العوامل الوحيدة التي تحدد قيمة MSS. يمكن لأجهزة الشبكة الوسيطة، مثل بوابات VPN، بما في ذلك بوابة Azure VPN، ضبط وحدة MTU بشكل مستقل عن المصدر والوجهة لضمان الأداء الأمثل للشبكة.
اكتشاف وحدة MTU للمسار
يتم التفاوض على حجم MSS، ولكنه قد لا يشير إلى حجم MSS الفعلي الذي يمكن استخدامه. وذلك لأن أجهزة الشبكة الأخرى في المسار بين المصدر والوجهة قد تكون لها قيمة MTU أقل من المصدر والوجهة. في هذه الحالة، سيقوم الجهاز الذي تكون وحدة MTU فيه أصغر من الحزمة بقطع الحزمة. سيرسل الجهاز رسالة "تجزئة ICMP مطلوبة" (النوع 3، الرمز 4) التي تحتوي على وحدة MTU الخاصة به. تسمح رسالة ICMP هذه للمضيف المصدر باختصار وحدة MTU لمسارها بشكل مناسب. تسمى العملية اكتشاف وحدة MTU للمسار (PMTUD).
عملية PMTUD لا تتمتع بالكفاءة وتؤثر على أداء الشبكة. عندما يتم إرسال الحزم التي تتجاوز وحدة MTU لمسار الشبكة، تحتاج الحزم إلى إعادة إرسالها باستخدام حجم MSS أقل. إذا لم يتلق المرسل رسالة "تجزئة ICMP مطلوبة"، ربما بسبب جدار لحماية الشبكة في المسار (يُشار إليه عادة باسم الثقب الأسود في عملية PMTUD)، فإن المرسل لا يعرف أنه يحتاج إلى خفض حجم MSS وسيقوم بإعادة إرسال الحزمة باستمرار. هذا هو السبب في أننا لا نوصي بزيادة وحدة MTU لجهاز Azure الظاهري.
VPN ووحدة MTU
إذا كنت تستخدم الأجهزة الظاهرية التي تقوم بالتغليف (مثل شبكات IPsec الافتراضية الخاصة)، فهناك بعض الاعتبارات الإضافية المتعلقة بحجم الحزمة ووحدة MTU. تضيف الشبكات الافتراضية الخاصة المزيد من العناوين إلى الحزم، ما يزيد من حجم الحزمة ويتطلب حجم MSS أصغر.
بالنسبة إلى Azure، نوصي بتعيين تثبيت حجم MSS لبروتوكول TCP على 1,350 بايت ووحدة MTU لواجهة النفق على 1,400. لمزيد من المعلومات، راجع صفحة أجهزة الشبكة الافتراضية الخاصة ومعلمات IPSec/IKE.
زمن الانتقال ووقت الرحلة ذهاباً وإياباً وتحجيم نافذة TCP
زمن الانتقال ووقت الرحلة ذهاباً وإياباً
يخضع زمن انتقال الشبكة لسرعة الضوء عبر شبكة ألياف بصرية. كما تخضع إنتاجية شبكة TCP بشكل فعال لوقت الرحلة ذهاباً وإياباً (RTT) بين جهازي شبكة.
| المسار | مسافة | وقت الاتجاه الواحد | RTT |
|---|---|---|---|
| نيويورك إلى سان فرانسيسكو | 4148 كم | 21 م/ث | 42 م/ث |
| نيويورك إلى لندن | 5585 كم | 28 م/ث | 56 م/ث |
| نيويورك إلى سيدني | 15993 كم | 80 م/ث | 160 م/ث |
يوضح هذا الجدول مسافة الخط المستقيم بين موقعين. في الشبكات، تكون المسافة عادة أطول من مسافة الخط المستقيم. في ما يلي صيغة بسيطة لحساب الحد الأدنى من RTT كما تحكمه سرعة الضوء:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
يمكنك استخدام 200 لسرعة الانتشار. هذه هي المسافة التي يقطعها الضوء في 1 ملي ثانية بالكيلومترات.
لنأخذ نيويورك إلى سان فرانسيسكو كمثال. مسافة الخط المستقيم تبلغ 4,148 كم. بإدخال تلك القيمة في المعادلة، نحصل على ما يلي:
Minimum RTT = 2 * (4,148 / 200)
تظهر نتيجة المعادلة بالملي ثانية.
إذا كنت ترغب في الحصول على أفضل أداء للشبكة، فإن الخيار المنطقي هو تحديد الوجهات ذات المسافة الأقصر بينها. ينبغي عليك أيضاً تصميم شبكتك الافتراضية لتحسين مسار نسبة استخدام الشبكة وتقليل زمن الانتقال. لمزيد من المعلومات، راجع قسم "اعتبارات تصميم الشبكة" في هذه المقالة.
تأثيرات زمن الانتقال ووقت الرحلة ذهاباً وإياباً على TCP
وقت الرحلة ذهاباً وإياباً له تأثير مباشر على الحد الأقصى لإنتاجية TCP. في بروتوكول TCP، يكون حجم النافذة هو الحد الأقصى لمقدار نسبة استخدام الشبكة التي يمكن إرسالها عبر اتصال TCP قبل أن يحتاج المرسل إلى تلقي إقرار من المستلم. إذا تم تعيين حجم MSS على بروتوكول TCP على 1,460 وتم تعيين حجم نافذة TCP على 65,535، يمكن للمرسل إرسال 45 حزمة قبل أن يضطر إلى تلقي إقرار من المستلم. إذا لم يحصل المرسل على إقرار، فسيعيد إرسال البيانات. إليك الصيغة.
TCP window size / TCP MSS = packets sent
في هذا المثال، يتم تقريب 65,535 / 1,460 إلى 45.
حالة "في انتظار الإقرار" هذه، وهي آلية لضمان التسليم الموثوق للبيانات، هي التي تجعل RTT يؤثر على إنتاجية TCP. كلما طال انتظار المرسل للإقرار، احتاج إلى الانتظار لفترة أطول قبل إرسال المزيد من البيانات.
في ما يلي صيغة لحساب الحد الأقصى للإنتاجية لاتصال TCP واحد:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
يوضح هذا الجدول الحد الأقصى للإنتاجية بالميغابايت/في الثانية لاتصال TCP واحد. (لسهولة القراءة، يتم استخدام وحدات الميغابايت لوحدة القياس.)
| حجم نافذة TCP (بالبايت) | زمن انتقال RTT (بالملي ثانية) | الحد الأقصى للإنتاجية بالميغابايت/ثانية | الحد الأقصى للإنتاجية بالميغابت/ثانية |
|---|---|---|---|
| 65535 | 1 | 65.54 | 524.29 |
| 65535 | 30 | 2.18 | 17.48 |
| 65535 | 60 | 1.09 | 8.74 |
| 65535 | 90 | .73 | 5.83 |
| 65535 | 120 | .55 | 4.37 |
في حال فقدان الحزم، سيتم تقليل الحد الأقصى لإنتاجية اتصال TCP أثناء قيام المرسل بإعادة إرسال البيانات التي أرسلها بالفعل.
تحجيم نافذة TCP
تحجيم نافذة TCP هو تقنية ترفع بشكل ديناميكي من حجم نافذة TCP للسماح بإرسال المزيد من البيانات قبل الحاجة إلى إقرار. في المثال السابق، سترسل 45 حزمة قبل المطالبة بإقرار. إذا قمت بزيادة عدد الحزم التي يمكن إرسالها قبل الحاجة إلى إقرار، فهذا يعني أنك تقلل من عدد المرات التي ينتظر فيها المرسل الإقرار، ما يزيد من الحد الأقصى لإنتاجية TCP.
يوضح هذا الجدول تلك العلاقات:
| حجم نافذة TCP (بالبايت) | زمن انتقال RTT (بالملي ثانية) | الحد الأقصى للإنتاجية بالميغابايت/ثانية | الحد الأقصى للإنتاجية بالميغابت/ثانية |
|---|---|---|---|
| 65535 | 30 | 2.18 | 17.48 |
| 131070 | 30 | 4.37 | 34.95 |
| 262140 | 30 | 8.74 | 69.91 |
| 524280 | 30 | 17.48 | 139.81 |
ولكن قيمة عنوان TCP لحجم نافذة TCP هي 2 بايت فقط، ما يعني أن القيمة القصوى لنافذة استلام هي 65,535. لزيادة الحد الأقصى لحجم النافذة، تم إدخال عامل مقياس نافذة TCP.
عامل المقياس هو أيضاً إعداد يمكنك تكوينه في نظام تشغيل. فيما يلي صيغة حساب حجم نافذة TCP باستخدام عوامل المقياس:
TCP window size = TCP window size in bytes * (2^scale factor)
في ما يلي حساب عامل مقياس نافذة يبلغ 3 وحجم نافذة يبلغ 65,535:
65,535 * (2^3) = 524,280 bytes
ينتج عن عامل مقياس يبلغ 14 حجم نافذة TCP يبلغ 14 (الحد الأقصى للإزاحة المسموح بها). حجم نافذة TCP سيكون 1,073,725,440 بايت (8.5 غيغابايت).
دعم تحجيم نافذة TCP
يمكن لنظام Windows تعيين عوامل تحجيم مختلفة لأنواع الاتصال المختلفة. (تتضمن فئات الاتصالات مركز البيانات والإنترنت وما إلى ذلك.) يمكنك استخدام أمر PowerShell Get-NetTCPConnection لعرض نوع اتصال تحجيم النافذة:
Get-NetTCPConnection
يمكنك استخدام أمر PowerShell Get-NetTCPSetting لعرض قيم كل فئة:
Get-NetTCPSetting
يمكنك تعيين حجم نافذة TCP الأولي وعامل تحجيم TCP في Windows باستخدام أمر PowerShell Set-NetTCPSetting. لمزيد من المعلومات راجع Set-NetTCPSetting.
Set-NetTCPSetting
هذه هي إعدادات TCP الفعالة لـAutoTuningLevel:
| AutoTuningLevel | عامل التحجيم | مضاعف التحجيم | صيغة من أجل حساب الحد الأقصى لحجم النافذة |
|---|---|---|---|
| مُعطل | بلا | بلا | حجم النافذة |
| مقيد | 4 | 2^4 | حجم النافذة * (2^4) |
| مقيد للغاية | 2 | 2^2 | حجم النافذة * (2^2) |
| عادية | 8 | 2^8 | حجم النافذة * (2^8) |
| التجريبية | 14 | 2^14 | حجم النافذة * (2^14) |
من المرجح أن تؤثر هذه الإعدادات على أداء TCP، ولكن ضع في اعتبارك أن العديد من العوامل الأخرى عبر الإنترنت، الخارجة عن سيطرة Azure، يمكن أن تؤثر أيضاً على أداء TCP.
اتصال الشبكات المتسارع واستقبال التحجيم الجانبي
شبكات مسرعة
كانت وظائف شبكة الجهاز الظاهري تاريخياً كثيفة في استهلاك وحدة المعالجة المركزية على كل من الجهاز الظاهري الضيف ومراقب الأجهزة الافتراضية/المضيف. تتم معالجة كل حزمة تمر عبر المضيف في برنامج بواسطة وحدة المعالجة المركزية المضيفة، بما في ذلك كل عمليات تغليف الشبكة الظاهرية وإزالة التغليف. لذلك كلما زاد عدد الزيارات التي تمر عبر المضيف، زاد الحمل على وحدة المعالجة المركزية. وإذا كانت وحدة المعالجة المركزية للمضيف مشغولة بعمليات أخرى، فسيؤثر ذلك أيضاً على إنتاجية الشبكة وزمن انتقالها. يعالج Azure هذه المشكلة باتصال الشبكات المتسارع.
يوفر اتصال الشبكات المتسارع زمن انتقال ثابتاً على الشبكة منخفضاً للغاية عبر الأجهزة الداخلية القابلة للبرمجة من Azure وتقنيات مثل SR-IOV. يعمل اتصال الشبكات المتسارع على نقل الكثير من مكدس اتصال الشبكات المعرفة ببرامج Azure من وحدات المعالجة المركزية إلى شبكات SmartNIC المستندة إلى FPGA. يمكّن هذا التغيير تطبيقات المستخدمين النهائيين من استعادة دورات الحوسبة، ما يضع حملاً أقل على الجهاز الظاهري، ما يقلل من التوتر وعدم الاتساق في زمن الانتقال. وبعبارة أخرى، يمكن أن يكون الأداء أكثر تحديداً.
يعمل اتصال الشبكات المتسارع على تحسين الأداء من خلال السماح للجهاز الظاهري الضيف بتجاوز المضيف وإنشاء مسار بيانات مباشرة باستخدام SmartNIC خاص بالمضيف. في ما يلي بعض فوائد اتصال الشبكات المتسارع:
زمن انتقال أقل / حزم في الثانية (pps) أعلى: تؤدي إزالة المفتاح الظاهري من مسار البيانات إلى التخلص من الوقت الذي تقضيه الحزم في المضيف لمعالجة النهج وزيادة عدد الحزم التي يمكن معالجتها في الجهاز الظاهري.
توتر أقل: تعتمد معالجة المعن الظاهري على مقدار السياسة التي يجب تطبيقها وحمل عمل وحدة المعالجة المركزية التي تقوم بالمعالجة. يؤدي إلغاء تحميل فرض السياسة على الأجهزة إلى إزالة ذلك التباين عن طريق تسليم الحزم مباشرة إلى الجهاز الظاهري، ما يلغي اتصال المضيف إلى الجهاز الظاهري وجميع مقاطعات البرامج وتبديلات السياق.
انخفاض استخدام وحدة المعالجة المركزية: يؤدي تجاوز الشبكة الظاهرية في المضيف إلى استخدام أقل لوحدة المعالجة المركزية لمعالجة نسبة استخدام الشبكة.
لاستخدام اتصال الشبكات المتسارع، تحتاج إلى تمكينه بشكل صريح على كل جهاز ظاهري قابل للتطبيق. راجع إنشاء جهاز Linux ظاهري مع تمكين اتصال الشبكات المتسارع للاطلاع على التعليمات.
تلقي التحجيم الجانبي
تحجيم جانب الاستقبال (RSS) هي تقنية برنامج تشغيل شبكة تقوم بتوزيع استقبال نسبة استخدام الشبكة بشكل أكثر كفاءة من خلال توزيع معالجة الاستقبال عبر وحدات معالجة مركزية متعددة في نظام متعدد المعالجات. بعبارات بسيطة، يسمح حجم RSS للنظام بمعالجة المزيد من نسبة استخدام الشبكة المستلمة لأنه يستخدم كل وحدات المعالجة المركزية المتاحة بدلاً من وحدة واحدة فقط. لمزيد من المناقشة الفنية عن حجم RSS، راجع مقدمة لتلقي التحجيم الجانبي.
للحصول على أفضل أداء عند تمكين اتصال الشبكات المتسارع على جهاز ظاهري، تحتاج إلى تمكين حجم RSS. يمكن أن يوفر حجم RSS أيضاً فوائد على الأجهزة الظاهرية التي لا تستخدم اتصال الشبكات المتسارع. للحصول على نظرة عامة عن كيفية تحديد ما إذا كان حجم RSS ممكّناً وكيفية تمكينه، راجع تحسين إنتاجية الشبكة لأجهزة Azure الظاهرية.
اغتيال TIME_WAIT TCP وTIME_WAIT
يعد TCP TIME_WAIT إعداداً شائعاً آخر يؤثر على أداء الشبكة والتطبيق. في الأجهزة الظاهرية المشغولة التي تقوم بفتح العديد من المقابس وإغلاقها، إما كعملاء أو كخوادم (IP المصدر: المنفذ المصدر + IP الوجهة: منفذ الوجهة)، أثناء التشغيل العادي لبروتوكول TCP، يمكن أن ينتهي الأمر بمقبس معين في حالة TIME_WAIT لفترة طويلة. تهدف حالة TIME_WAIT إلى السماح بتسليم أي بيانات إضافية على مأخذ توصيل قبل إغلاقه. لذلك تمنع مكدسات TCP/IP بشكل عام إعادة استخدام مأخذ توصيل عن طريق قطع حزمة TCP SYN الخاصة بالعميل.
مقدار الوقت الذي يكون فيه مأخذ توصيل في TIME_WAIT قابلاً للتكوين. يمكن أن يتراوح من 30 ثانية إلى 240 ثانية. مآخذ التوصيل هي مورد محدود، وعدد مآخذ التوصيل التي يمكن استخدامها في أي وقت قابل للتكوين. (يبلغ عدد مآخذ التوصيل المتاحة عادة حوالي 30,000.) إذا تم استهلاك مآخذ التوصيل المتوفرة، أو إذا كان لدى العملاء والخوادم إعدادات TIME_WAIT غير متطابقة، وحاول جهاز ظاهري إعادة استخدام مأخذ توصيل في حالة TIME_WAIT، فستفشل الاتصالات الجديدة حيث يتم قطع حزم TCP SYN بصمت.
عادة ما تكون قيمة نطاق المنفذ لمآخذ التوصيل الصادرة قابلة للتكوين داخل مكدس TCP/IP لنظام تشغيل. وينطبق الشيء نفسه على إعدادات TCP TIME_WAIT وإعادة استخدام مأخذ التوصيل. يمكن أن يؤدي تغيير هذه الأرقام إلى تحسين قابلية التوسع. ولكن، اعتماداً على الموقف، يمكن أن تسبب هذه التغييرات مشاكل في إمكانية التشغيل التفاعلي. ينبغي أن تكون حذراً إذا غيرت هذه القيم.
يمكنك استخدام اغتيال TIME_WAIT للتعامل مع هذا القيد على التحجيم. يسمح اغتيال TIME_WAIT بإعادة استخدام مأخذ توصيل في مواقف معينة، مثل عندما يتجاوز رقم التسلسل في حزمة IP الخاصة بالاتصال الجديد رقم تسلسل الحزمة الأخيرة من الاتصال السابق. في هذه الحالة، سيسمح نظام التشغيل بإنشاء الاتصال الجديد (سيقبل SYN/ACK الجديد) ويفرض إغلاق الاتصال السابق الذي كان في حالة TIME_WAIT. يتم دعم هذه الإمكانية على أجهزة Windows الظاهرية في Azure. للتعرف على الدعم في الأجهزة الظاهرية الأخرى، راجع مورد نظام التشغيل.
للتعرف على كيفية تكوين إعدادات TCP TIME_WAIT ونطاق منفذ المصدر، راجع الإعدادات التي يمكن تعديلها لتحسين أداء الشبكة.
عوامل الشبكات الافتراضية التي يمكن أن تؤثر على الأداء
الحد الأقصى للإنتاجية الصادرة من الجهاز الظاهري
يوفر Azure مجموعة متنوعة من أحجام الأجهزة الظاهرية وأنواعها، ولكل منها مزيج مختلف من إمكانات الأداء. إحدى هذه القدرات هي إنتاجية الشبكة (أو عرض نطاقها الترددي)، والتي يتم قياسها بالميغابت في الثانية (Mbps). نظرا لأنه تتم استضافة الأجهزة الظاهرية على الأجهزة المشتركة، يجب مشاركة سعة الشبكة بشكل عادل بين الأجهزة الظاهرية باستخدام الأجهزة نفسها. يتم تخصيص نطاق ترددي أكبر للأجهزة الظاهرية الأكبر بالمقارنة مع الأجهزة الظاهرية الأصغر.
يتم قياس عرض النطاق الترددي للشبكة المخصص لكل جهاز ظاهري على نسبة استخدام الشبكة الخارجة (الصادرة) من الجهاز الظاهري. يتم حساب نسبة استخدام الشبكة التي تغادر الجهاز الظاهري كافة ضمن الحد المخصص، بصرف النظر عن الوجهة. على سبيل المثال، إذا كان للجهاز الظاهري حد يقدر بـ1,000 ميغابت في الثانية، فسيتم تطبيق هذا الحد سواء كانت نسبة استخدام الشبكة الصادرة موجهة لجهاز ظاهري آخر في الشبكة الظاهرية نفسها، أو جهاز خارج Azure.
لا يتم قياس الدخول أو تقييده بشكل مباشر. لكن هناك عوامل أخرى، مثل وحدة المعالجة المركزية وحدود التخزين، والتي يمكن أن تؤثر في قدرة الجهاز الظاهري على معالجة البيانات الواردة.
تم تصميم اتصال الشبكات المتسارع لتحسين أداء الشبكة، بما في ذلك زمن الانتقال ومعدل النقل واستخدام وحدة المعالجة المركزية. يمكن لاتصال الشبكات المتسارع تحسين إنتاجية الجهاز الظاهري، ولكن يمكنه القيام بذلك فقط حتى النطاق الترددي المخصص للجهاز الظاهري.
تحتوي أجهزة Azure الظاهرية على واجهة شبكة واحدة على الأقل متصلة بها. قد يكون لديهم عدة أجهزة. النطاق الترددي المخصص لجهاز ظاهري هو مجموع كل نسبة استخدام الشبكة الصادرة عبر كل واجهات الشبكة المرفقة بالجهاز. بمعنى آخر، يتم تخصيص النطاق الترددي على حسب كل جهاز ظاهري، بغض النظر عن عدد واجهات الشبكة المتصلة بالجهاز.
يتم تفصيل معدل النقل الصادر المتوقع وعدد واجهات الشبكة المعتمدة بواسطة حجم كل جهاز ظاهري في أحجام أجهزة Windows الظاهرية في Azure. للاطلاع على الحد الأقصى لمعدل النقل، حدد نوعاً، مثل الغرض العام، ثم ابحث عن القسم الخاص بسلسلة الحجم في الصفحة الناتجة (على سبيل المثال، "سلسلة Dv2"). لكل سلسلة، هناك جدول يوفر مواصفات اتصال الشبكات في العمود الأخير، والذي يحمل عنوان "الحد الأقصى لبطاقات واجهة الشبكة / النطاق الترددي المتوقع للشبكة (بالميغابت في الثانية)."
ينطبق حد معدل النقل على الجهاز الظاهري. لا يتأثر معدل النقل بهذه العوامل:
عدد واجهات الشبكة: حد النطاق الترددي يسري على مجموع كل نسبة استخدام الشبكة الصادرة بأكملها من الجهاز الظاهري.
شبكات مسرعة: على الرغم من أن هذه الميزة يمكن أن تكون مفيدة في تحقيق حد التوزيع، فإنها لا تغير الحد.
وجهة نسبة استخدام الشبكة: يتم احتساب جميع الوجهات نحو الحد الصادر.
البروتوكول: جميع نسبة استخدام الشبكة الصادرة عبر جميع البروتوكولات تحسب نحو الحد الأقصى.
لمزيد من المعلومات، راجع النطاق الترددي لشبكة الجهاز الظاهري.
اعتبارات الأداء على الإنترنت
كما ورد في هذه المقالة، يمكن أن تؤثر العوامل الموجودة على الإنترنت والخارجة عن سيطرة Azure على أداء الشبكة. في ما يلي بعض تلك العوامل:
زمن الانتقال: يمكن أن يتأثر وقت الرحلة ذهاباً وإياباً بين وجهتين بالمشكلات على الشبكات الوسيطة، ونسبة استخدام الشبكة التي لا تأخذ مسار المسافة "الأقصر"، ومسارات التناظر دون المستوى الأمثل.
فقدان الحزم: يمكن أن يحدث فقدان الحزم بسبب ازدحام الشبكة ومشكلات المسار الفعلي وأجهزة الشبكة ذات الأداء الضعيف.
حجم / تجزئة وحدة MTU: يمكن أن تؤدي التجزئة على طول المسار إلى تأخير في وصول البيانات أو في الحزم التي تصل من دون ترتيب، ما قد يؤثر على تسليم الحزم.
تُعد Traceroute أداة جيدة لقياس خصائص أداء الشبكة (مثل فقدان الحزم وزمن الانتقال) على طول كل مسار شبكة بين جهاز مصدر وجهاز وجهة.
اعتبارات تصميم الشبكات
جنباً إلى جنب مع الاعتبارات التي نوقشت سابقاً في هذه المقالة، يمكن أن تؤثر طوبولوجيا الشبكة الظاهرية على أداء الشبكة. على سبيل المثال، سيؤدي التصميم المحوري الذي ينقل نسبة استخدام الشبكة عالمياً إلى شبكة ظاهرية أحادية المحور إلى توفير زمن انتقال الشبكة، ما سيؤثر على الأداء العام للشبكة.
يمكن أن يؤثر عدد أجهزة الشبكة التي تمر بها نسبة استخدام الشبكة أيضاً على زمن الانتقال الإجمالي. على سبيل المثال، في التصميم المحوري، إذا مرت نسبة استخدام الشبكة عبر جهاز ظاهري للشبكة المحورية وجهاز ظاهري محوري قبل العبور إلى الإنترنت، يمكن للأجهزة الظاهرية للشبكة إدخال زمن انتقال.
مناطق Azure والشبكات الظاهرية وزمن الانتقال
تتكون مساحات Azure من مراكز بيانات متعددة موجودة داخل مساحة جغرافية عامة. قد لا تكون مراكز البيانات هذه بجوار بعضها فعلياً. في بعض الحالات تفصلها مسافة تصل إلى 10 كيلومترات. الشبكة الظاهرية عبارة عن تراكب منطقي فوق شبكة مركز بيانات Azure الفعلي. لا تعني الشبكة الظاهرية أي مخطط محدد داخل مركز البيانات.
على سبيل المثال، قد يكون جهازان ظاهريان موجودين في الشبكة الظاهرية نفسها وقد تكون الشبكة الفرعية في رفوف أو صفوف أو حتى مراكز بيانات مختلفة. يمكن فصلها بأقدام من كابل ألياف بصرية أو بكيلومترات من كابل ألياف بصرية. يمكن أن يؤدي هذا التباين إلى زمن انتقال متغير (بفارق عدد من وحدات الملي ثانية) بين الأجهزة الظاهرية المختلفة.
يمكن أن يتأثر الموقع الجغرافي للأجهزة الظاهرية، وزمن الانتقال المحتمل الناتج بين جهازين ظاهريين، بتكوين مجموعات توافر الخدمات ومناطق توافر الخدمات. لكن المسافة بين مراكز البيانات في منطقة ما تكون خاصة بالمنطقة وتتأثر في المقام الأول بطوبولوجيا مراكز البيانات في المنطقة.
استنفاد منفذ NAT المصدر
يمكن لتوزيع في Azure أن يتواصل مع نقاط النهاية خارج Azure على الإنترنت العام و/أو في مساحة IP العامة. عندما يبدأ مثيل ما اتصالاً صادراً، يقوم Azure بتعيين عنوان IP الخاص ديناميكياً إلى عنوان IP عام. بعد أن يقوم Azure بإنشاء هذا التعيين، فإن نسبة استخدام الشبكة الراجعة في التدفق الناشئ الصادر يمكن أن تصل أيضاً إلى عنوان IP الخاص الذي نشأ منه التدفق.
لكل اتصال صادر، يحتاج موازن تحميل Azure إلى الحفاظ على هذا التعيين لفترة من الزمن. بفضل طبيعة Azure متعددة المستأجرين، يمكن أن يكون الحفاظ على هذا التعيين لكل تدفق صادر لكل جهاز ظاهري كثيف الاستخدام للموارد. لذلك هناك حدود يتم تعيينها وتستند إلى تكوين شبكة Azure الظاهرية. أو بتعبير أدق، يمكن لجهاز Azure الظاهري إجراء عدد معين فقط من الاتصالات الصادرة في وقت معين. عند الوصول إلى هذه الحدود، لن يتمكن الجهاز الظاهري من إجراء المزيد من الاتصالات الصادرة.
لكن هذا السلوك قابل للتكوين. لمزيد من المعلومات عن SNAT واستنفاد منفذ SNAT، راجع هذه المقالة.
قياس أداء الشبكة على Azure
يرتبط عدد من الحدود القصوى للأداء في هذه المقالة بزمن انتقال الشبكة/وقت الرحلة ذهاباً وإياباً (RTT) بين جهازين ظاهريين. يوفر هذا القسم بعض الاقتراحات عن كيفية اختبار زمن الانتقال/RTT وكيفية اختبار أداء TCP وأداء شبكة الجهاز الظاهري. يمكنك ضبط قيم TCP/IP والشبكة التي تمت مناقشتها سابقاً واختبار أدائها باستخدام التقنيات الموضحة في هذا القسم. يمكنك توصيل قيم زمن الوصول ووحدة MTU وحجم MSS وحجم النافذة بالحسابات المقدمة سابقاً ومقارنة الحدود القصوى النظرية بالقيم الفعلية التي تلاحظها أثناء الاختبار.
قياس وقت الرحلة ذهاباً وإياباً وفقدان الحزم
يعتمد أداء TCP بشكل كبير على وقت RTT وفقدان الحزم. توفر أداة اختبار الاتصال المساعدة المتوفرة في Windows وLinux أسهل طريقة لقياس وقت RTT وفقدان الحزم. سيبين ناتج أداة اختبار الاتصال الحد الأدنى/الحد الأقصى/متوسط زمن الانتقال بين المصدر والوجهة. وسيبين أيضاً فقدان الحزم. تستخدم أداة اختبار الاتصال بروتوكول ICMP بشكل افتراضي. يمكنك استخدام PsPing لاختبار وقت RTT على بروتوكول TCP. للاطلاع على مزيد من المعلومات، راجع PsPing.
قياس النطاق الترددي الفعلي لجهاز ظاهري
لقياس النطاق الترددي لأجهزة Azure الظاهرية بدقة، اتبع هذه الإرشادات.
لمزيد من التفاصيل حول اختبار سيناريوهات أخرى، راجع هذه المقالات:
اكتشاف سلوكيات TCP غير الفعالة
في عمليات التقاط الحزم، قد يرى عملاء Azure حزم TCP بإشارات TCP (SACK وDUP ACK وRETRANSMIT وFAST RETRANSMIT) التي قد تشير إلى مشكلات في أداء الشبكة. تشير هذه الحزم على وجه التحديد إلى أوجه القصور في الشبكة الناتجة عن فقدان الحزم. لكن فقدان الحزم ليس بالضرورة ناتجاً عن مشاكل في أداء Azure. قد تكون مشكلات الأداء ناتجة عن مشكلات في التطبيق أو مشكلات في نظام التشغيل أو مشكلات أخرى قد لا تكون مرتبطة مباشرة بنظام Azure الأساسي.
ضع في اعتبارك أيضاً أن بعض عمليات إعادة الإرسال ونسخ ACKs طبيعية على الشبكة. تم تصميم بروتوكولات TCP لتكون محل ثقة. لا تشير أدلة حزم TCP هذه في التقاط حزمة بالضرورة إلى وجود مشكلة في الشبكة النظامية، ما لم تكن مفرطة.
ومع ذلك، فإن أنواع الحزم هذه هي مؤشرات على أن معدل نقل TCP لا يحقق أقصى أداء له، لأسباب تمت مناقشتها في أقسام أخرى من هذه المقالة.
الخطوات التالية
الآن بعد أن تعرفت على ضبط أداء TCP/IP لأجهزة Azure الظاهرية، قد ترغب في القراءة عن اعتبارات أخرى لتخطيط الشبكات الظاهرية أو معرفة المزيد عن توصيل الشبكات الظاهرية وتكوينها.