- مرحبا. أنا ساشا ، أعمل في Yandex ، على مدار السنوات الثلاث الماضية ، كنت أطور موازن تحميل L7. سأخبرك عن طريقة سريعة وسهلة لتسريع شبكتك. سنبدأ من المستوى السابع ، HTTP ، وننتقل إلى المستوى الرابع ، TCP. اليوم سنتحدث فقط عن هذين المستويين وسنتناولهما ببعض التفصيل.
في السنوات الثماني الماضية ، كنت أقوم بمزيد من التطوير للخلفية ، وعلى الأرجح بقيت معرفتي على مستوى AngularJS في الإصدارات الأولى. ربما تعرف أفضل مني كيف يعمل كل شيء. لقد قمت بالفعل بتحسين كل شيء ، وضغط كل شيء ، وهنا لا يمكنني أن أنصحك بأي شيء.
لكن يمكنني أن أنصحك بكيفية تسريع شبكتك من خلال تحسين الخادم نفسه ، نظام التشغيل نفسه.
لتسريع شيء ما ، تحتاج إلى مقاييس. في هذه الحالة ، استخدمنا ما يلي: يوضح لنا متوسط الوقت حتى البايت الأول مدى سرعة طبقة TCP ، والقياس الثاني هو وقت تلقي HTML من البايت الأول. لقد جربنا وقياس مقاييسنا ، وبعد تشغيل BBR ، كان تسارعنا حوالي عشرة بالمائة.
لفهم ما هي عشرة بالمائة ، ننتقل إلى القيمة المطلقة ، وهي 66 مللي ثانية. إذا ذهبت إلى لعبتك المفضلة متعددة اللاعبين عبر الإنترنت ، فستكون Ping إلى خوادم أوروبا الغربية حوالي 60-70 مللي ثانية.
كيف تفعل ذلك بسرعة
تتم إدارة جميع خوادمنا باستخدام بروتوكولات التحكم عن بعد ، في هذه الحالة SSH. إذا لم تصادف SSH حتى الآن ، يمكنك أن تطلب من مسؤول النظام لديك تهيئة الخادم الخاص بك. سأخبرك كيف تقنعه بفعل هذا.
ما هو BBR؟ هذه إحدى الخوارزميات التي تسمح لنا بالتحكم في كيفية انتقال الحزم إلى الشبكة. ويتم تكوينه باستخدام المعلمتين التاليتين. الأول هو ضبط جدولة الحزم على FQ ، ثم سأخبرك لماذا يجب عليك استخدام FQ. والثاني هو إدراج التحكم في الازدحام نفسه ، أي BBR نفسه.
يبدو أن هذا هو المكان الذي يمكن أن ننتهي فيه. ولكن في الواقع ، هناك العديد من المزالق ، وعلى الأرجح لن يقوم مسؤول النظام لديك فقط بتمكين BBR على الخادم. لذلك ، سوف نذهب أبعد من ذلك.
HTTP / 2 وتعدد الإرسال
سنبدأ من المستوى 7 ، وهو HTTP ، ونعمل ببطء في طريقنا لمراجعة البروتوكولات الخاصة بنا.
سنبدأ بمتصفحاتنا التي نتفاعل معها كل يوم. نرى وحدة تحكم مطور الويب. وحدة التحكم لديها مجال مثير للاهتمام بالنسبة لنا - البروتوكول.
في حالتنا ، البروتوكولات هي HTTP / 1 و HTTP / 2. يوجد أيضًا بروتوكول HTTP / 3 ، والذي يعتمد على بروتوكول QUIC من Google. لكننا اليوم لن نعود إليها لأنها قيد التطوير ولم تتم الموافقة عليها بالكامل بعد. دعنا نعود إلى HTTP / 1.
على الشريحة ، نرى الأداة المساعدة Wireshark ، والتي تسمح لنا بتحليل الحزم الخاصة بنا ، والطريقة التي نتفاعل بها مع الشبكة. نرى أن أحد الحقول مظلل باللون الأخضر. هذا هو طلب HTTP الخاص بنا. أدناه يمكننا أن نرى البايتات ، وكيف سيتم تقديمها على الشبكة.
كيف يبدو HTTP / 1 في الحياة الواقعية؟ هذا بروتوكول بسيط إلى حد ما. إنه مستند إلى النص تمامًا ، أي أننا نكتب النص ونرسله إلى الشبكة. يتم ترميز شخصياتنا بقيم سداسية عشرية خاصة. على اليمين يوجد جدول ASCII ، قطعة صغيرة حتى تتمكن من التنقل.
لدينا الجزء الأول على شكل رؤوس مفصولة بالأحرف "\ r \ n \ r \ n" من جسمنا. نحن فقط نطلب موردًا عاديًا هنا باستخدام طريقة GET ، لذلك لن يكون لهذا الطلب نص. ونلاحظ أن البايتات تقريبًا مشابهة لما هو موجود في جدول ASCII. نحن نطلب نوعًا من JS ، نوعًا من الموارد. يوجد أيضًا رأس مضيف يشير إلى المجال الذي نعمل معه حاليًا. و - مجموعة إضافية من الرؤوس. يمكن أن تكون مخصصة ، يمكنك استخدام أي منها.
HTTP / 2 هو بروتوكول أكثر تعقيدًا. إنه ثنائي ، وأصغر وحدة لتبادل المعلومات هي الإطارات. هناك العديد من الحالات الخاصة ، أنواع خاصة من هذه الإطارات. يمكنك أن ترى على الشريحة أنه تم تمييزها.
يمكننا أيضًا أن نلاحظ في السطر الأول أنه يمكن وضع إطارين في حزمة واحدة في وقت واحد. لن نتطرق إلى الإطارات الموجودة ، فهناك عدد غير قليل منها. في هذه الحالة ، سنكون مهتمين بإطار الرؤوس ، لأنه يسمح لنا فقط بطلب الموارد. لقد شاركت قليلاً في تطوير Wireshark ، مما ساعد في تحسينه في هذا المجال.
نرى أن هناك طلبًا للحصول عليها. نرى أنه يوجد في المنتصف تمثيل نصي لطلب الحصول هذا. لكن في العمود الأيمن نرى بايتًا واحدًا مخصصًا فقط ، وستكون طريقة get هذه. بعد ذلك ، سأشرح سبب حدوث ذلك.
بعد ذلك ، لدينا رأس المسار ، الذي يشير إلى المسار إلى المورد ، إلى JS الخاص بنا ، والذي سنطلبه. وهناك مجموعة من بعض العناوين الإضافية التي ستكون موجودة أيضًا في طلبنا.
فلماذا لا تتطابق وحدات البايت الخاصة بنا على الشبكة مع كيفية رسم كل هذا في صورتنا؟ الحقيقة هي أن Wireshark أظهر لنا النتيجة النهائية ، وكيف قام بفك تشفيرها كلها. وعلى الشبكة ، سيتم ضغط هذه البايتات ، هذه الرؤوس ، بتنسيق HPACK خاص. من الأفضل التعرف على مزيد من التفاصيل على الإنترنت. ابحث عن المعلومات ، فهي موثقة جيدًا.
دعنا نعود إلى لدغاتنا. هناك حقل خاص - معرف المحتوى. يشير إلى المورد الذي تعمل معه هذه الإطارات حاليًا. في هذه الحالة ، أرسلنا الإطار الأول ، البيانات المستلمة. عندما يعطينا الخادم وحدات بايت المحتوى نفسها ، فسيتم استخدام إطار البيانات بالفعل.
تختلف بروتوكولات HTTP / 1 و HTTP / 2 كثيرًا. لقد تحدثنا بالفعل عن حقيقة أن HTTP / 1 هو بروتوكول نصي ، و HTTP / 2 هو بروتوكول ثنائي ، أي أنه يعمل باستخدام الإطارات.
HTTP / 1 في حالة طلب في شكل اتصال واحد سيعيد نتيجة غير معروفة ، اعتمادًا على طريقة تنفيذ مطوري خادم الويب لكتابتها. أي ، إذا قدمنا طلبين في اتصال واحد ، على الأرجح ، سيتم إرجاع إما استجابة للطلب الأول أو الثاني. للقيام بذلك ، من أجل تحميل الموارد بالتوازي ، ينشئ المتصفح عدة اتصالات ، عادة حوالي ستة منها ، ويحمل الموارد بالتوازي.
يستخدم HTTP / 2 بدوره اتصالاً واحدًا. أي أنه يحدد الاتصال ، وداخله يقوم بتحميل جميع البيانات الضرورية من خلال الإطارات. تسمى تقنية تجميع موارد متعددة في اتصال واحد تعدد الإرسال.
يتضح من كيفية عمل اتصالاتنا: في حالة فقد الحزمة في إحدى الاتصالات ، سيعمل HTTP / 1 بشكل أفضل. على الأرجح ، لن نتطرق إلى الاتصالات الأخرى ، وسوف يستمرون في التحميل بنفس السرعة. وفي حالة HTTP / 2 ، إذا فقدت الحزمة الخاصة بنا ، يبدأ تحميل جميع الموارد في التباطؤ.
يبدو أن HTTP / 2 أسوأ ، كما أنه حساس لفقدان الحزم. في الواقع ، عندما نقوم بإنشاء كل من هذه الاتصالات الستة ، فإننا نقوم بالعملية التالية.
يقوم العميل والخادم بإنشاء اتصال موثوق به ، اتصال TCP. نقوم بإرسال حزمتين من العميل إلى الخادم ، ويتم إرسال حزمة واحدة من جانب الخادم إلى العميل. وبالتالي ، يبدو أننا نقول إننا مستعدون لنقل البيانات. هذا ، بالطبع ، يخلق موارد عامة ، يمكننا القيام بذلك لفترة طويلة.
يوجد أيضًا تشفير. إذا نظرت إلى متصفحك الآن ، فسترى على الأرجح رمز القفل. كثير من الناس يسمونه SSL ، لكنه ليس SSL حقًا. هذا هو TLS. لطالما كان بروتوكول SSL قديمًا ، ولم يعد مدعومًا عمليًا ، ويجب التخلي عنه.
TLS لديها أيضا تبادل الحزم. وهذا يعني أننا ، تمامًا كما في حالة مصافحة TCP ، نضع حالة معينة ، وبعد ذلك يمكننا مواصلة العمل. في هذه المرحلة ، يمكننا أيضًا إجراء التحسين ، لكن المتصفحات لا تدعم حتى الآن الأشياء التي قمنا بتمكينها بالفعل من جانب الخادم. سننتظر حتى يقوم الجميع بتشغيله.
ذات مرة ، حاول HTTP / 1 حل مشكلة التحميل المتزامن للموارد. RFC لديه ذلك. وذات مرة ، تم تنفيذ خطوط الأنابيب. نظرًا لتعقيد التنفيذ ، لا يدعمه Internet Explorer ، بينما يدعمه Firefox و Chrome ، ولكن الدعم قد انخفض بمرور الوقت.
في الواقع ، لن يتم إغلاق كل من اتصالاتنا الستة التي أنشأناها بالفعل. أي أنهم سيستمرون في العمل بنفس الطريقة كما كان من قبل. لهذا ، يتم استخدام تقنية مثل Keep-Alive. أي أننا ننشئ اتصالاً موثوقًا بخادم معين ونواصل العمل.
على مستوى HTTP ، يتم التحكم في هذا بواسطة الرأس. في هذه الحالة ، يكون الاتصال. وعلى مستوى TCP ، سنستخدم بالفعل نظام التشغيل نفسه ، وسيقرر لنا ما يجب القيام به.
هناك مشاكل أخرى مع HTTP / 2 أيضًا. في HTTP / 2 ، يمكننا تحديد أولويات الحزم وإرسال المزيد من البيانات المطلوبة بشكل أسرع. في هذه الحالة ، عندما نحاول إرسال الكثير من البيانات في وقت واحد ، قد يتجاوز المخزن المؤقت على الخادم. بعد ذلك ، ستبطئ الحزم ذات الأولوية الأعلى ببساطة وتوضع في نهاية قائمة الانتظار.
لوحظ فقدان الحزمة. إنها تبطئ التحميل لدينا ، وهذا المنع يسمى منع رأس الخط.
كيف يحل TCP مشاكل فقدان الحزم
الآن سنتحدث عن TCP ، أي الطبقة الرابعة. في الدقائق العشر القادمة ، سأغطي كيفية عمل بروتوكول TCP.
عندما نزور ، نطلب من شخص ما تمرير الملح. عندما يعطينا شخص الملح ، نؤكد أن الملح قد وصل إلينا. في هذه الحالة ، نأخذ أيضًا مقطعًا ونرسله وننتظر التأكيد. نرسل مرة أخرى. وإذا كانت هناك خسارة ، فإننا نعيد توجيه هذا الجزء ونتيجة لذلك يتم تسليمه إلينا. هذه التقنية لإرسال مقطع واحد تسمى Stop and wait.
لكن شبكاتنا تسارعت بشكل كبير خلال الثلاثين عامًا الماضية. ربما يتذكر البعض منكم الطلب الهاتفي ، الإنترنت بالميغابايت. الآن ، قد تكون قادرًا بالفعل على توصيل إنترنت جيجابت في المنزل.
أيضًا ، في هذه الحالة ، يمكننا البدء في إرسال عدة حزم في وقت واحد. في مثالنا ، هناك ثلاثة منهم. نرسل النافذة في شكل ثلاث حزم وننتظر تأكيدها جميعًا.
في حالة فقدان الحزمة ، يمكننا البدء في إعادة توجيه جميع الحزم ، بدءًا من الخسارة الأولى. تسمى هذه التقنية Go-Back N. وإلا ، يمكننا البدء في تتبع جميع الحزم وإعادة توجيه الحزم المفقودة فقط. هذه التقنية تسمى التكرار الانتقائي. إنه أكثر تكلفة من جانب الخادم. عندما كنا نعد الشرائح ، استغرق الأمر وقتًا طويلاً لمعرفة كيفية تقديمها. لقد ارتبكت في ذلك ، وبالتالي توصلت إلى مثل هذا التشبيه.
هناك أنابيب معروفة لنا جميعًا تتدفق من خلالها المياه. الأنابيب لها أقطار مختلفة ، في مكان ما يمكن أن تكون أرق ، وفي هذه الحالة ستكون أضيق نقطة فقط مع أقصى إنتاجية. لن نكون قادرين على صب المزيد من الماء أكثر مما يسمح به هذا الاختناق.
سنحاول تسديد الكرات من اليسار إلى اليمين. على الجانب الأيمن ، سيتم التأكيد على أن الكرات قد طارت. لقد بدأنا في إرسال مجموعة من الكرات. دعونا نلقي نظرة على قصته. الآن الكرات تطير في اتجاه واحد ، يتم تأكيدها ، وعدد الكرات لدينا ينمو بشكل كبير. في مرحلة ما ، يصبح حجم الكرات كبيرًا جدًا بحيث تتباطأ وتبدأ الخسائر. بعد الخسارة ، نبطئ قليلاً ، ونقلص النافذة بمقدار النصف. ثم نحاول أن نفهم ما حدث لنا. تسمى المرحلة الأولى بداية بطيئة لـ TCP.
عندما نغلق النافذة مرتين ، يمكننا استعادة الاتصال ومطالبة اللاعبين بإرسال كراتنا مرة أخرى. يصرخون لنا أننا بحاجة إلى إرسال الكرات ، ونجيب عليها - ها هي كراتك. تسمى هذه المرحلة الاسترداد السريع وإعادة الإرسال السريع.
عندما أدركنا أن كل شيء على ما يرام معنا ، بدأنا في زيادة عدد الكرات المرسلة تدريجيًا ، بدءًا من تلك النافذة المنهارة. هذه المرحلة تسمى تجنب الازدحام. أي أننا نحاول تجنب فقد حزمنا.
تسمى المرحلة التي تنهار فيها نافذتنا مرتين بالنقص المضاعف. وتسمى المرحلة البطيئة لزيادة عدد الكرات بالزيادة المضافة.
عندما يفقد برنامج Congestion Avoidance الحزم مرة أخرى ، يمكننا القيام بالخطوة التالية. لكن في الوقت الحالي ، نحن مهتمون أكثر بصورة هذا الرسم البياني. نرى مثل هذا المنشار ، وسيكون هذا المنشار مفيدًا لنا عدة مرات. تذكر كيف تبدو.
سنعود إلى مشاكل بروتوكولات TCP التقليدية. قياسا على الأنبوب ، نصب الأكياس. نظرًا لوجود مستخدمين آخرين على الإنترنت بجانبنا ، فقد بدأوا أيضًا في صب الحزم في الأنبوب. في مرحلة ما ، يمكن للمخازن المؤقتة للموجهات الخاصة بنا أن تفيض وتخلق مشاكل لنا عند إرسال الحزم.
توجد أيضًا مشكلة في فقد الحزمة على الشبكات اللاسلكية. على الأرجح ، لا يحتوي الكمبيوتر المحمول الخاص بك على منفذ Ethernet وأنت تشاهد محادثة عبر Wi-Fi. لا ينتج فقدان الحزمة في شبكات Wi-Fi وشبكات الهاتف المحمول عن جهاز التوجيه نفسه ، ولكن بسبب تداخل الراديو. لن يكون هذا المقياس مفيدًا جدًا بالنسبة لنا.
اختلاف TCP BBR عن الخوارزميات الأخرى
هنا نأتي إلى BBR. إنه يرمز إلى Bottleneck Bandwidth و Round Trip Time ، هذه مقاييس للنطاق الترددي عندما لا نسد قناتنا تمامًا ، ووقت انتقال الحزمة منا إلى الخادم والعودة.
عندما نرسل البيانات ، فإن الحالة المثالية التي تكون فيها الحزم في حالة مستقرة ، وتطير ولم يتم التعرف عليها بعد تسمى منتج Bandwidth-delay. يمكننا زيادة BDP باستخدام المخازن المؤقتة لأجهزة الشبكة. عندما يتم تجاوز هذا المخزن المؤقت ، تبدأ الخسائر.
وتعمل خوارزميات TCP العادية فقط على الجانب الأيمن من الرسم البياني ، أي حيث تحدث الخسائر - نسكب الكثير من الحزم بحيث لا مفر من الخسائر. تتباطأ الحزم ونبدأ في انهيار النافذة.
تعمل BBR ، بدورها ، على مبدأ مختلف ، بالقرب من أنبوبنا. نحن فقط نسكب أكبر عدد ممكن من الأكياس يمكننا تخطيه. في مرحلة البداية ، أي في البداية ، نسكب الأكياس حتى يبدأ الازدحام.
وأحيانًا يكون فقد الحزمة ممكنًا. لكن BBR تحاول تجنب هذه اللحظة. عندما نملأ أنبوبنا ، نبدأ في التراجع. هذه المرحلة تسمى استنزاف.
سنعود إلى اتصالنا المستقر ، حيث سيتم ملؤه بالكامل ، لكن في نفس الوقت لن نستخدم مخازن إضافية ، وخزانات إضافية. من هذا الموقف ، تواصل BBR العمل.
من وقت لآخر سنلقي نظرة على ما يحدث لشبكتنا. نحن نتتبع كل طرد يتم إرجاعه إلينا تقريبًا. عندما عادت الحزم إلينا ، نبدأ في محاولة تسريع عدد الحزم قليلاً ، وتسريع الحزم نفسها عن طريق إرسالها إلى الشبكة.
وإذا لم تكن لدينا أي مشاكل ، فيمكننا البقاء على هذه القيمة. أي أن نواصل العمل بالسرعة التي تناسبنا. ومع ذلك ، إذا كانت هناك خسائر ، فيمكننا التراجع.
عندما تلقينا تأكيدًا ، رأينا أن السرعة قد تحسنت ، يمكننا الانتظار قليلاً ، وإلقاء نظرة على فترة عشر ثوانٍ. وإذا رأينا خلال هذه الفترة أن سرعة إرسال الحزم تزداد وتأكدت الحزم بشكل أسرع ، فيمكننا الدخول إلى مرحلة RTT الخاصة بالمسبار والتحقق مما إذا كان كل شيء قد أصبح أفضل.
تتناوب هذه المراحل ، أي أننا سنتحقق باستمرار مما لدينا مع الشبكة.
لم تعد خوارزمية BBR تعتمد على فقدان الحزمة ، ولكن على عرض القناة ووقت انتقال الحزمة.
في الواقع ، إنه محصن ضد فقدان الحزم. إنه عمليا لا يتفاعل معهم ، ولهذا لدينا بعض المشاكل. وعدت Google بأنه سيتم إصلاح هذه المشكلات في BBR v2.
لقد فحصنا مراحلنا ، وأمامنا مرة أخرى المشط ، الذي أظهرته بالفعل. يتم تمييز بروتوكولات TCP العادية باللون الأحمر. لذلك ، يلتقط ، يلتقط ، يبطئ ، ويفقد الطرود مرة أخرى. ويحدد BBR السرعة التي يحتاجها ، والتي سيعمل بها طوال الوقت ، ويتحقق باستمرار من شبكتنا لمعرفة ما إذا كانت قد أصبحت أفضل قليلاً. وقد تكون متسارعة.
يتم تحديث مقاييسنا باستمرار ، ونتتبع كل تأكيد من جانب العميل ونتحقق مما إذا كانت شبكتنا قد تسارعت أم لا.
كيف يتم التحكم في معدل إرسال الحزم؟ نحن نتحكم في وتيرة الإرسال باستخدام تقنية السرعة. يتم تنفيذه في المجدول الذي ذكرته سابقًا. هذا هو جدولة FQ. يتم تطبيقه أيضًا في النواة نفسها ، لكنني سأتحدث عن هذا لاحقًا.
نحاول ، كما هو الحال في الأنبوب ، ضخ المزيد من البيانات ، وفي نفس الوقت لا نبطئ ولا نفقد حزمنا. لكن BBR ليس بهذه البساطة. على الأرجح ، أنت تعيش في حاويات أو تستخدم خوادم متعددة لقواعد البيانات - ربما للصور.
وتتفاعل كل هذه الخوادم مع بعضها البعض. هناك بروتوكول TCP عادي ممكّن ، وليس BBR. وعندما يكون لديك المنشار ، الذي رأيناه بالفعل ، عندما تبدأ النافذة في الانهيار ، فربما يبدأ BBR في التحسس من انهيار النافذة وزيادة معدل إرسال الحزم. وبالتالي ، فإنه سيتم طرد TCP العادي من شبكتنا ، وتهيمن.
إذا كانت الشبكة سيئة للغاية ، فمن المحتمل حدوث مشكلات أخرى. لن يعمل بروتوكول TCP العادي على الإطلاق ، وبما أن BBR غير حساس عمليًا لفقدان الحزم ، فإنه سيستمر في العمل بمعدل معين.
يمكننا حل هذه المشكلة مع مراكز البيانات باستخدام خيار TCP_CONGESTION. إنه مكشوف لكل مقبس ولكل اتصال. الآن ، على حد علمي ، لم يتم تنفيذ هذا الخيار في أي خادم ويب تقريبًا. ويدعمه موازن L7. لكن عد إلى خطوتنا. إذا كنت تعمل مع نواة أقدم ، فهذا يعني وجود خطأ في تنفيذ سرعة النوى في kernels قبل الإصدار 4.20. في هذه الحالة ، يجدر استخدام جدولة FQ.
الآن بعد أن عرفت كيفية عمل TCP ، يمكنك الذهاب إلى مسؤول النظام وإخباره لماذا يجب عليك تمكين BBR.
لنعد إلى عشرة بالمائة. من أين يأتون؟ أصبحت شبكات المشغلين الآن كبيرة جدًا. الأمر كله متعلق بالمال. يمكنك بناء قنوات بسعة 100 و 200 تيرابايت وتخطي كمية هائلة من مقاطع الفيديو بدقة 4K على سبيل المثال. لكن عميلك سيظل في نقطة النهاية.
وعلى الأرجح ، سيكون هذا الميل الأخير للعميل مصدر المشكلات. ستفقد جميع حزمتي Wi-Fi و LTE. سنرى تباطؤًا عند استخدام بروتوكول TCP العادي. BBR يحل هذه المشكلة. يمكنك تشغيله باستخدام الأمرين اللذين أشرت إليهما فقط. شكرا للجميع.