إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تتناول هذه المقالة تقنيات ضبط أداء TCP/IP الشائعة وبعض الأشياء التي يجب مراعاتها عندما تستخدمها للأجهزة الظاهرية التي تعمل على Azure. ويوفر نظرة عامة أساسية على التقنيات واستكشاف كيفية ضبط الأجهزة الظاهرية.
تقنيات ضبط TCP/IP الشائعة
وحدة MTU، والتجزئة، وإلغاء تحميل الإرسال الكبير
وحدة MTU
وحدة الإرسال القصوى (MTU) هي أكبر إطار حجم (حزمة بالإضافة إلى رؤوس الوصول إلى الشبكة) المحددة بالبايت التي يمكن إرسالها عبر واجهة شبكة. وحدة MTU هو إعداد قابل للتكوين. وحدة MTU الافتراضية المستخدمة على أجهزة Azure الظاهرية، والإعداد الافتراضي على معظم أجهزة الشبكات على مستوى العالم هو 1,500 بايت.
التجزئة
تحدث التجزئة عند إرسال حزمة تتجاوز وحدة MTU لواجهة شبكة. يقسم مكدس TCP/IP الحزمة إلى أجزاء أصغر (أجزاء) تتوافق مع MTU للواجهة. تحدث التجزئة عند طبقة IP وهي مستقل عن البروتوكول الأساسي (مثل TCP). عند إرسال حزمة 2000 بايت عبر واجهة شبكة مع MTU من 1500، يتم تقسيم الحزمة إلى حزمة واحدة 1500 بايت وحزمة واحدة 500 بايت.
يمكن لأجهزة الشبكة في المسار بين مصدر ووجهة إما إسقاط الحزم التي تتجاوز MTU أو تجزئة الحزمة إلى أجزاء أصغر.
بت "عدم التجزئة" في حزمة IP
بت عدم التجزئة (DF) هو علامة في عنوان بروتوكول IP. يشير بت DF إلى أن أجهزة الشبكة الموجودة على المسار بين المرسل والمستقبل يجب ألا تقوم بتجزئة الحزمة. يمكن تعيين هذا البت لأسباب كثيرة. (راجع قسم "اكتشاف وحدة MTU للمسار" من هذه المقالة للحصول على مثال واحد.) عندما يتلقى جهاز شبكة حزمة تحتوي على تعيين بت "عدم التجزئة"، وتتجاوز تلك الحزمة وحدة MTU لواجهة الجهاز، فإن السلوك القياسي هو أن يقوم الجهاز بإسقاط الحزمة. يرسل الجهاز رسالة "تجزئة ICMP مطلوبة" مرة أخرى إلى المصدر الأصلي للحزمة.
الآثار المترتبة على أداء التجزئة
يمكن أن تكون للتجزئة آثار سلبية على الأداء. أحد الأسباب الرئيسية للتأثير على الأداء هو تأثير وحدة المعالجة المركزية/الذاكرة لتجزئة الحزم وإعادة تجميعها. عندما يحتاج جهاز الشبكة إلى تجزئة حزمة، يجب عليه تخصيص موارد وحدة المعالجة المركزية/الذاكرة لإجراء التجزئة.
يحدث الشيء نفسه عند إعادة تجميع الحزمة. يجب أن يخزن جهاز الشبكة جميع الأجزاء حتى يتم استلامها حتى يتمكن من إعادة تجميعها في الحزمة الأصلية.
Azure والتجزئة
لا يعالج Azure الحزم المجزأة باستخدام الشبكات المتسارعة. عندما يتلقى الجهاز الظاهري حزمة مجزأة، يعالجها المسار غير المتباين. ونتيجة لذلك، تفوت الحزم المجزأة فوائد الشبكات المتسارعة، مثل زمن الانتقال المنخفض، وانخفاض التشويه، والحزم الأعلى في الثانية. لهذا السبب، نوصي بتجنب التجزئة إن أمكن.
يقوم Azure، بشكل افتراضي، بإسقاط الحزم المجزأة التي تصل إلى الجهاز الظاهري خارج الترتيب، ما يعني أن الحزم لا تتطابق مع تسلسل الإرسال من نقطة النهاية المصدر. يمكن أن تحدث هذه المشكلة عندما تنتقل الحزم عبر الإنترنت أو شبكات WAN الأخرى الكبيرة.
ضبط وحدة MTU
يمكنك تحسين معدل نقل الشبكة الظاهرية الداخلية عن طريق زيادة MTU لحركة مرور الجهاز الظاهري الخاص بك. ومع ذلك، إذا كان الجهاز الظاهري يتصل بوجهات خارج الشبكة الظاهرية التي تحتوي على MTU مختلف، فقد تحدث التجزئة وتقلل من الأداء.
لمزيد من المعلومات حول تعيين MTU على أجهزة Azure الظاهرية، راجع تكوين وحدة الإرسال القصوى (MTU) للأجهزة الظاهرية في Azure.
إلغاء تحميل الإرسال الكبير
يمكن أن يؤدي تفريغ الإرسال الكبير (LSO) إلى تحسين أداء الشبكة عن طريق إلغاء تحميل تجزئة الحزم إلى محول ethernet. عند تمكين LSO، ينشئ مكدس TCP/IP حزمة TCP كبيرة ويرسلها إلى محول ethernet للتجزئة قبل إعادة توجيهها. تحرر ميزة LSO وحدة المعالجة المركزية من تقسيم الحزم إلى أحجام تتوافق مع MTU وتفريغ تلك المعالجة إلى أجهزة واجهة ethernet. لمعرفة المزيد عن فوائد LSO، راجع دعم إلغاء تحميل الإرسال الكبير.
عند تمكين LSO، قد يلاحظ عملاء Azure أحجام إطارات كبيرة أثناء التقاط الحزمة. قد تتسبب أحجام الإطارات الكبيرة هذه في أن يفترض بعض العملاء حدوث التجزئة أو أنه يتم استخدام MTU كبير عندما لا يكون كذلك. باستخدام LSO، يمكن لمحول ethernet الإعلان عن حجم مقطع أقصى أكبر (MSS) إلى مكدس TCP/IP لإنشاء حزمة TCP أكبر. ثم يقسم محول ethernet هذا الإطار بأكمله غير المصنف إلى العديد من الإطارات الأصغر وفقا ل MTU الخاص به، والتي تكون مرئية في التقاط الحزمة التي يتم إجراؤها على الجهاز الظاهري.
تحجيم نافذة TCP MSS وPMTUD
الحد الأقصى لحجم مقطع TCP
الحد الأقصى لحجم مقطع (MSS) في TCP هو إعداد يحد من حجم مقاطع TCP، ما يتجنب تجزئة حزم TCP. تستخدم أنظمة التشغيل هذه الصيغة عادة لتعيين MSS:
MSS = MTU - (IP header size + TCP header size)
عنوان IP وعنوان TCP بحجم 20 بايت لكل منهما، أو بإجمالي 40 بايت. واجهة مع MTU من 1,500 لديه MSS من 1,460. 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 مطلوبة، يبقى المرسل غير مدرك للحاجة إلى خفض MSS وإعادة إرسال الحزمة بشكل متكرر. لهذا السبب، ننصح بعدم زيادة Azure VM MTU.
VPN ووحدة MTU
إذا كنت تستخدم الأجهزة الظاهرية التي تقوم بالتغليف (مثل IPsec VPNs)، فهناك بعض الاعتبارات الأخرى المتعلقة بحجم الحزمة وMTU. تضيف الشبكات الظاهرية الخاصة المزيد من الرؤوس إلى الحزم. تزيد الرؤوس المضافة من حجم الحزمة وتتطلب MSS أصغر.
بالنسبة إلى Azure، نوصي بتعيين تثبيت حجم MSS لبروتوكول TCP على 1,350 بايت ووحدة MTU لواجهة النفق على 1,400. لمزيد من المعلومات، راجع صفحة أجهزة VPN ومعلمات IPsec/IKE.
زمن الانتقال ووقت الرحلة ذهاباً وإياباً وتحجيم نافذة TCP
زمن الانتقال ووقت الرحلة ذهاباً وإياباً
تحدد سرعة الضوء زمن انتقال الشبكة عبر شبكة ألياف ضوئية. يتحكم وقت الرحلة ذهابا وإيابا (RTT) بين جهازي شبكة اتصال في معدل نقل شبكة TCP.
| المسار | مسافة | وقت الاتجاه الواحد | 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 قبل أن يحتاج المرسل إلى تلقي الإقرار من المتلقي. إذا تم تعيين TCP MSS إلى 1460 وتم تعيين حجم نافذة TCP إلى 65535، يمكن للمرسل إرسال 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 | 0.73 | 5.83 |
| 65535 | 120 | 0.55 | 4.37 |
إذا فقدت الحزم، يتم تقليل الحد الأقصى لمعدل نقل اتصال TCP بينما يعيد المرسل إرسال البيانات التي أرسلها.
تحجيم نافذة TCP
تحجيم نافذة TCP هو تقنية تزيد ديناميكيا من حجم نافذة TCP للسماح بإرسال المزيد من البيانات قبل الحاجة إلى الإقرار. في المثال السابق، سيتم إرسال 45 حزمة قبل طلب إقرار. إذا قمت بزيادة عدد الحزم التي يمكن إرسالها قبل الحاجة إلى الإقرار، فأنت تقلل عدد المرات التي ينتظر فيها المرسل الإقرار.
يوضح هذا الجدول تلك العلاقات:
| حجم نافذة 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.
اتصال الشبكات المتسارع واستقبال التحجيم الجانبي
شبكات مسرعة
تعد وظائف شبكة الجهاز الظاهري تاريخيا مكثفة لوحدة المعالجة المركزية على كل من الجهاز الظاهري الضيف وhypervisor/المضيف. تعالج وحدة المعالجة المركزية المضيفة في البرامج جميع الحزم التي تمر عبر المضيف، بما في ذلك جميع تغليف الشبكة الظاهرية وإلغاء تغليفها. كلما زادت نسبة استخدام الشبكة التي تمر عبر المضيف، زاد تحميل وحدة المعالجة المركزية. إذا كانت وحدة المعالجة المركزية المضيفة مشغولة بعمليات أخرى تؤثر على معدل نقل الشبكة وزمن الانتقال. يعالج Azure هذه المشكلة باتصال الشبكات المتسارع.
يوفر اتصال الشبكات المتسارع زمن انتقال ثابتاً على الشبكة منخفضاً للغاية عبر الأجهزة الداخلية القابلة للبرمجة من Azure وتقنيات مثل SR-IOV. يعمل اتصال الشبكات المتسارع على نقل الكثير من مكدس اتصال الشبكات المعرفة ببرامج Azure من وحدات المعالجة المركزية إلى شبكات SmartNIC المستندة إلى FPGA. يتيح هذا التغيير لتطبيقات المستخدم النهائي استعادة دورات الحوسبة التي تضع حملا أقل على الجهاز الظاهري لتقليل التشويه وعدم التناسق في زمن الانتقال. وبعبارة أخرى، يمكن أن يكون الأداء أكثر تحديداً.
يعمل اتصال الشبكات المتسارع على تحسين الأداء من خلال السماح للجهاز الظاهري الضيف بتجاوز المضيف وإنشاء مسار بيانات مباشرة باستخدام SmartNIC خاص بالمضيف. في ما يلي بعض فوائد اتصال الشبكات المتسارع:
زمن انتقال أقل / حزم في الثانية (pps) أعلى: تؤدي إزالة المفتاح الظاهري من مسار البيانات إلى التخلص من الوقت الذي تقضيه الحزم في المضيف لمعالجة النهج وزيادة عدد الحزم التي يمكن معالجتها في الجهاز الظاهري.
توتر أقل: تعتمد معالجة المعن الظاهري على مقدار السياسة التي يجب تطبيقها وحمل عمل وحدة المعالجة المركزية التي تقوم بالمعالجة. يؤدي إلغاء تحميل فرض السياسة على الأجهزة إلى إزالة ذلك التباين عن طريق تسليم الحزم مباشرة إلى الجهاز الظاهري، ما يلغي اتصال المضيف إلى الجهاز الظاهري وجميع مقاطعات البرامج وتبديلات السياق.
انخفاض استخدام وحدة المعالجة المركزية: يؤدي تجاوز الشبكة الظاهرية في المضيف إلى استخدام أقل لوحدة المعالجة المركزية لمعالجة نسبة استخدام الشبكة.
لاستخدام اتصال الشبكات المتسارع، تحتاج إلى تمكينه بشكل صريح على كل جهاز ظاهري قابل للتطبيق. راجع إنشاء جهاز Linux ظاهري مع تمكين اتصال الشبكات المتسارع للاطلاع على التعليمات.
تلقي التحجيم الجانبي
تحجيم جانب الاستقبال (RSS) هي تقنية برنامج تشغيل شبكة تقوم بتوزيع استقبال نسبة استخدام الشبكة بشكل أكثر كفاءة من خلال توزيع معالجة الاستقبال عبر وحدات معالجة مركزية متعددة في نظام متعدد المعالجات. بعبارات بسيطة، يسمح حجم RSS للنظام بمعالجة المزيد من نسبة استخدام الشبكة المستلمة لأنه يستخدم كل وحدات المعالجة المركزية المتاحة بدلاً من وحدة واحدة فقط. لمزيد من المناقشة الفنية عن حجم RSS، راجع مقدمة لتلقي التحجيم الجانبي.
للحصول على أفضل أداء عند تمكين اتصال الشبكات المتسارع على جهاز ظاهري، تحتاج إلى تمكين حجم RSS. يمكن أن يوفر حجم RSS أيضاً فوائد على الأجهزة الظاهرية التي لا تستخدم اتصال الشبكات المتسارع. للحصول على نظرة عامة عن كيفية تحديد ما إذا كان حجم RSS ممكّناً وكيفية تمكينه، راجع تحسين إنتاجية الشبكة لأجهزة Azure الظاهرية.
اغتيال TIME_WAIT TCP وTIME_WAIT
TIME_WAIT TCP هو إعداد شائع آخر يؤثر على أداء الشبكة والتطبيق. غالبا ما تفتح الأجهزة الظاهرية المشغولة العديد من مآخذ التوصيل وتغلقها، إما كعملاء أو خوادم. أثناء عمليات TCP العادية، غالبا ما يدخل مأخذ التوصيل في حالة 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). نظرا لأنه تتم استضافة الأجهزة الظاهرية على الأجهزة المشتركة، يجب مشاركة سعة الشبكة بشكل عادل بين الأجهزة الظاهرية باستخدام الأجهزة نفسها. يتم تخصيص نطاق ترددي أكبر للأجهزة الظاهرية الأكبر بالمقارنة مع الأجهزة الظاهرية الأصغر.
يتم قياس النطاق الترددي للشبكة المخصص لكل جهاز ظاهري على حركة الخروج (الصادرة) من الجهاز الظاهري. يتم حساب نسبة استخدام الشبكة التي تغادر الجهاز الظاهري كافة ضمن الحد المخصص، بصرف النظر عن الوجهة. إذا كان الجهاز الظاهري لديه حد 1000 ميجابت في الثانية، فإن هذا الحد ينطبق سواء كانت نسبة استخدام الشبكة الصادرة موجهة إلى جهاز ظاهري آخر في نفس الشبكة الظاهرية أو واحدة خارج Azure.
لا يتم قياس الدخول أو تقييده مباشرة. لكن هناك عوامل أخرى، مثل وحدة المعالجة المركزية وحدود التخزين، والتي يمكن أن تؤثر في قدرة الجهاز الظاهري على معالجة البيانات الواردة.
تم تصميم اتصال الشبكات المتسارع لتحسين أداء الشبكة، بما في ذلك زمن الانتقال ومعدل النقل واستخدام وحدة المعالجة المركزية. يمكن لاتصال الشبكات المتسارع تحسين إنتاجية الجهاز الظاهري، ولكن يمكنه القيام بذلك فقط حتى النطاق الترددي المخصص للجهاز الظاهري.
تحتوي أجهزة Azure الظاهرية على واجهة شبكة واحدة على الأقل متصلة بها. قد يكون لديهم عدة أجهزة. النطاق الترددي المخصص لجهاز ظاهري هو مجموع كل نسبة استخدام الشبكة الصادرة عبر كل واجهات الشبكة المرفقة بالجهاز. بمعنى آخر، يتم تخصيص النطاق الترددي على حسب كل جهاز ظاهري، بغض النظر عن عدد واجهات الشبكة المتصلة بالجهاز.
يتم تفصيل معدل النقل الصادر المتوقع وعدد واجهات الشبكة المعتمدة بواسطة حجم كل جهاز ظاهري في أحجام أجهزة Windows الظاهرية في Azure. للاطلاع على الحد الأقصى لمعدل النقل، حدد نوعاً، مثل الغرض العام، ثم ابحث عن القسم الخاص بسلسلة الحجم في الصفحة الناتجة (على سبيل المثال، "سلسلة Dv2"). لكل سلسلة، هناك جدول يوفر مواصفات اتصال الشبكات في العمود الأخير، والذي يحمل عنوان "الحد الأقصى لبطاقات واجهة الشبكة / النطاق الترددي المتوقع للشبكة (بالميغابت في الثانية)."
ينطبق حد معدل النقل على الجهاز الظاهري. لا يتأثر معدل النقل بهذه العوامل:
عدد واجهات الشبكة: حد النطاق الترددي يسري على مجموع كل نسبة استخدام الشبكة الصادرة بأكملها من الجهاز الظاهري.
شبكات مسرعة: على الرغم من أن هذه الميزة يمكن أن تكون مفيدة في تحقيق حد التوزيع، فإنها لا تغير الحد.
وجهة نسبة استخدام الشبكة: يتم احتساب جميع الوجهات نحو الحد الصادر.
البروتوكول: جميع نسبة استخدام الشبكة الصادرة عبر جميع البروتوكولات تحسب نحو الحد الأقصى.
لمزيد من المعلومات، راجع النطاق الترددي لشبكة الجهاز الظاهري.
تحسين أجهزة Linux الظاهرية (VMs)
تحتوي نواة Linux الحديثة على ميزات يمكن أن تساعد في تحقيق الاتساق والأداء، والتي تتطلبها أحيانا أحمال عمل معينة.
لمزيد من المعلومات، راجع تحسين النطاق الترددي للشبكة على أجهزة Azure الظاهرية
اعتبارات الأداء على الإنترنت
كما ورد في هذه المقالة، يمكن أن تؤثر العوامل الموجودة على الإنترنت والخارجة عن سيطرة 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 وفقدان الحزم. يظهر إخراج PING الحد الأدنى/الحد الأقصى/متوسط زمن الانتقال بين المصدر والوجهة. يظهر فقدان الحزمة. تستخدم أداة اختبار الاتصال بروتوكول ICMP بشكل افتراضي. يمكنك استخدام PsPing لاختبار وقت RTT على بروتوكول TCP. للاطلاع على مزيد من المعلومات، راجع PsPing.
لا تقيس عمليات اختبار اتصال ICMP وTCP مسار بيانات الشبكات المتسارع. لقياس مسار البيانات، اقرأ عن Latte وSockPerf في هذه المقالة.
قياس النطاق الترددي الفعلي لجهاز ظاهري
لقياس النطاق الترددي لأجهزة Azure الظاهرية بدقة، اتبع هذه الإرشادات.
لمزيد من المعلومات حول اختبار سيناريوهات أخرى، راجع هذه المقالات:
اكتشاف سلوكيات TCP غير الفعالة
في عمليات التقاط الحزم، قد يرى عملاء Azure حزم TCP بإشارات TCP (SACK وDUP ACK وRETRANSMIT وFAST RETRANSMIT) التي قد تشير إلى مشكلات في أداء الشبكة. تشير هذه الحزم على وجه التحديد إلى أوجه القصور في الشبكة الناتجة عن فقدان الحزم. لكن فقدان الحزم ليس بالضرورة ناتجاً عن مشاكل في أداء Azure. قد تكون مشكلات الأداء نتيجة للتطبيق أو نظام التشغيل أو مشاكل أخرى قد لا تكون مرتبطة مباشرة بالنظام الأساسي ل Azure.
ضع في اعتبارك أيضاً أن بعض عمليات إعادة الإرسال ونسخ ACKs طبيعية على الشبكة. تم تصميم بروتوكولات TCP لتكون محل ثقة. لا تشير أدلة حزم TCP هذه في التقاط حزمة بالضرورة إلى وجود مشكلة في الشبكة النظامية، ما لم تكن مفرطة.
ومع ذلك، فإن أنواع الحزم هذه هي مؤشرات على أن معدل نقل TCP لا يحقق أقصى أداء له، لأسباب تمت مناقشتها في أقسام أخرى من هذه المقالة.
الخطوات التالية
الآن بعد أن تعرفت على ضبط أداء TCP/IP لأجهزة Azure الظاهرية، فكر في استكشاف عوامل أخرى لتخطيط الشبكات الظاهرية. يمكنك أيضا معرفة المزيد حول توصيل الشبكات الظاهرية وتكوينها.