VOL81: HTTP Versions Explained
أهلًا وسهلا بكم في العدد الواحد والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
لا تنسوا أهلنا من صالح الدعاء,اللهم إنّا استودعناك اياهم، اللهم كُن عوناً لهم، اللهم انصرهم واحفظهم. 🇵🇸
أهلًا وسهلا بكم في العدد الواحد والثمانين من النشرة الأسبوعية لاقرأ-تِك 🚀
سواء كنت مهندس برمجيات مبتدئ أو محترف، فنشرتنا هدفها انها تثري المحتوى التقني العربي سعيا للتطوير من جودة المحتوى باللغة العربية، من خلال تقديم أحدث المستجدات والتطورات في عالم البرمجيات، بالإضافة إلى أفضل الممارسات والنصائح القيمة، ونشر أحدث المقالات وترشيحات الكتب ومحتوى ورقة وقلم اللي بينزلوا بشكل مستمر في موقع اقرأ-تِك.
في الإصدار ده الفهرس هيكون كالآتي:
HTTP Versions as Easy as possible
Deadlock vs. Starvation
Cross-Tab Communication with Broadcast Channel API
إصدارات - الإصدار الأول من مدونات فطين في تصميم النظم
HTTP Versions as Easy as possible
النهارده هنقارن إصدارات الـ HTTP اللي مسؤولين عن توصيل الويب لينا كما نعرفه اليوم بأسهل طريقة هتشوفوها حول الانترنت, كوب الشاي ويلا بينا ^^
تشبيه من العالم الحقيقي
خلونا نفكر شوية في شركات التوصيل والبريد
Network الطرق والكباري وعربيات التوصيل
Client (المتصفح) الشخص اللي بيطلب أو يبعت الطرد
Server (الخادم) الشركة أو المستودع اللي بيستقبل ويعالج الطلب
HTTP Protocol القوانين اللي بتحكم طريقة كتابة العنوان، نوع الطرد، طريقة الرد
TCP/UDP وسيلة النقل اللي بتوصل الطرود
Data Packets الطرود نفسها اللي فيها أجزاء من البيانات
Router / Switch مراكز البريد اللي بتنقل الطرود من منطقة للتانية
فلما نتكلم عن الـ HTTP ما هو إلا قوانين تنظم طريقة إرسال واستلام البريد أو الطرود و الإصدارات المختلفة ما هي إلا تحسينات على الطريقة دي عشان نخليها أكفأ وأسهل وأسرع.
HTTP/1.1 “ساعي البريد التقليدي”
تخيل شركة التوصيل عندها ساعي بريد واحد (Connection واحد فقط). كل مرة يروح يسلم طرد، هيضطر يعمل رحلة كاملة وما يقدرش يشيل أكثر من طرد في الرحلة الواحدة. فلو عندك 10 طرود (requests)، لازم يعمل 10 رحلات ورا بعض ( يعني كل Request يتبعت ونستنى ال Response وبعدين نبعت اللي بعده وهكذا) أو يجيب سعاة كتير (multiple TCP connections).
المميزات
بسيط وسهل الفهم.
مدعوم في كل الأنظمة والمتصفحات.
مثالي للتطبيقات الصغيرة أو legacy.
العيوب
Head-of-Line Blocking: لو طلب اتأخر، باقي الطلبات تستنى.
No Multiplexing: اتصال واحد = طلب واحد في المرة.
Overhead عالي على الشبكة لأن ال Headers بتتكرر كل مرة.
تحميل الصفحات الكبيرة بطيء خصوصًا لما يكون فيها ملفات كتير
HTTP/2 “شاحنة التوصيل (Multiplexing)”
الشركة قررت تحدث النظام وبقت تستخدم عربية واحدة (Connection واحد)، لكن جواها رفوف كثيرة (Streams).
يعني تقدر تبعت:
طرد فيه /index.html
طرد فيه /styles.css
طرد فيه /script.js كلهم في نفس الرحلة لكن في أرفف منفصلة جوه نفس العربية.
بس فيه مشكلة صغيرة: لو طرد في أول العربية اتكسر أو اتأخر في التوصيل (TCP packet lost). باقي الطرود في العربية ممكن يتأخروا كمان. (وده اللي بنسميه Head-of-Line Blocking على مستوى TCP.)
Deadlock vs. Starvation
فيه مصطلحين مهمين جدًا في نظم التشغيل لازم نفهمهم كويس وهما Deadlock و Starvation. وعلى الرغم من إنهم بيبدوا مشابهين لبعض، إلا إن كل واحد فيهم ليه سبب مختلف ونتيجة مختلفة تمامًا عن التاني. فورقة وقلم وتعالوا نشوف الفرق بينهم.
Deadlock
قبل ما نشوف ايه هي الـ Deadlock من الناحية الـ Technical تعالوا نفهمها سوا بشكل بسيط من خلال المثال ده:
دلوقتي ولنفترض ان عندنا اوضتين وكل اوضة ليها باب ومفتاح خاص بيها , فعندنا محمود دخل الاوضة بتاعته والباب اتقفل عليه بالقفل , وعندنا يوسف دخل الاوضة التانية والباب اتقفل عليه كذلك بالقفل , طب ايه رأيكم لو محمود كان معاه مفتاح اوضة يوسف بالخطأ ويوسف معاها مفتاح اوضة محمود ؟
كل واحد فيهم عاوز يخرج من الاوضة اللي هو فيها ولكن كل واحد مش هيعرف يفتح اوضته لان المفتاح اللي عاوزه مع التاني فبالتالي بنقول ان حصل هنا Deadlock.
طب كـ Technical باه الكلام ده بيحصل ازاي او بنترجمه لايه ؟
Cross-Tab Communication with Broadcast Channel API
في عالم تطوير الويب، غالبًا بنحتاج ننقل بيانات أو نرسل رسائل بين تبويبات المتصفح المختلفة. على سبيل المثال، لو عندك تطبيق ويب مفتوح في أكثر من تبويب، وعايز التحديثات اللي تحصل في تبويب معين تنعكس على باقي التبويبات تلقائيًا، فأنت محتاج تستخدم الـ Broadcast Channel API، اللي بيسمحلك تعمل تواصل سهل وفعال بين التبويبات المختلفة لنفس المتصفح طالما كلها مفتوحة على نفس الصفحة أو صفحات مختلفة على نفس الـ domain حتى لو كانت مفتوحة على نوافذ مختلفة ولكن بشرط تكون لنفس المتصفح.
ملحوظة: نافذة المتصفح قد تحتوى على تبويب واحد أو أكثر، كل تبويب منهم مسئول عن عرض صفحة واحدة فقط، نافذة المتصفح هي ما تحصل عليه عند فتح المتصفح، وفتح المتصفح عدة مرات يؤدى إلى إنشاء عدة نوافذ.
ليه محتاج تبعت بيانات بين التبويبات المختلفة ؟
لنفترض أننا محتاجين نزور أحد مواقع بيع الكتب ونتصفح الموقع بحثا عن مجموعة من الكتب المفيدة بالنسبة لنا عشان نشتريهم مثلا، فبدأنا رحلتنا من الصفحة الرئيسية للموقع وقابلنا كتاب بيتكلم عن JavaScript ففتحناه في علامة تبويب جديدة عشان نقدر نكمل تصفح في الصفحة الرئيسية ونبقى نشوف تفاصيل الكتاب بعدين (يمكن نلاقى كتب تانية فنشتريها بالمرة)، واستمرينا في التصفح لغاية ما لقينا كتاب تاني بيتكلم عن CSS وكالمعتاد فتحناه في علامة تبويب جديدة.
بعدها قررنا نزور علامات التبويب اللى فتحناها عشان نشوف تفاصيل كل كتاب منهم، وبالفعل الكتاب الأول نال اعجابنا وضيفناه لسلة المشتريات، ولاحظنا ظهور رقم 1 أعلى أيقونة سلة المشتريات للتعبير عن وجود منتج واحد بالسلة، بعدها فتحنا علامة التبويت التانية عشان نشوف الكتاب التاني وهنا لاحظنا إن الرقم 1 مش موجود لأن علامة التبويب دى مش عندها أى علم بأن في كتاب تم إضافته للسلة، ودا سبب لنا نوع من القلق عن إذا كان الكتاب الأول انضاف فعلا ولا لا، فرجعنا نبص عليه ولقيناه موجود فى السلة فعلا.
واستمرينا في رحلتنا بإضافة الكتاب التاني إلى السلة، وجات لحظة شراء الكتب اللى احتاجت مننا تسجيل الدخول للموقع، وبعد عملية تسجيل الدخول لاحظنا إن الصفحة اتعرفت علينا وبتعرض لنا اسم المستخدم في الـ navbar ولكن باقي الصفحات لسا مجالهاش خبر بأننا سجلنا دخول في الموقع فاضطرينا نعمل لهم ريفريش عشان يتحدثو بحيث ميحصلش اى مشكلة غير متوقعة، وبعدها تمت عملية الشراء بنجاح رغم إن بعض الصفحات لازالت مقتنعة إننا لسا مشتريناش الكتب، بل بعدها لما عملنا تسجيل خروج من الموقع لاحظنا إن بعض الصفحات لازالت بتعرض بيانات المستخدم!
التجربة دى غير لطيفة لبعض المستخدمين وممكن تخلى المستخدم يبعت Request من علامة تبويب بشراء منتجات هو حذفها أصلاً من علامة تبويب تانية، بس وقتها هو مش هيكون فاهم ليه الموقع بيقول له إن مفيش منتجات في السلة رغم إنه شايف الموقع بيعرض المنتجات قدامه، ومش هيفهم ليه الصفحة بتطلب تسجيل دخول رغم إنه سجل بالفعل ولكن من صفحة تانية، فعشان تحذف العبء دا من على دماغ المستخدم وتوفر له تجربة أفضل خلال رحلته أنت محتاج تخلى كل علامات التبويب متوافقين مع بعض وبيتحدثو باستمرار لو حصل تغيير بيستدعى دا ولكن في علامة تبويب مختلفة.
ودا بنقدر ننفذه من خلال الـ Broadcast Channel API اللى بيسمح لنا بارسال واستقبال البيانات بين علامات التبويب المختلفة.
طريقة استخدام الـ Broadcast Channel API
عملية التواصل بين علامات التبويب المختلفة محتاجة مننا 3 خطوات فرعية
الخطوة الأولى هي إنشاء قناة للتواصل
الخطوة التانية هى التجهيز لاستقبال الرسائل
أما الخطوة التالتة والأخيرة هي ارسال البيانات على هيئة رسائل
الخطوة الأولى: إنشاء قناة للتواصل
يمكن إنشاء قناة للتواصل بين علامات التبويب المختلفة عن طريق الـ constructor الخاص بالـ BroadcastChannel وبواسطة الـ new keyword، كالمثال التالي:
بحيث my-channel هو اسم القناة ويمكن استبداله بأى اسم مناسب للهدف اللى تم إنشاء القناة من أجله، مثلا cart-channel أو auth-channel أو غيرهم.
خصم 50% على جميع خطط الاشتراك السنوية لفترة محدودة، تقدروا دلوقتي تشتركوا في اقرأ-تِك وتستمتعوا بكافة المقالات في كل ما يخص هندسة البرمجيات باللغة العربية والمحتوى المميز من ورقة وقلم ومدونات فطين اللي بيتميزوا بتصاميم ذات جودة عالية وكل ده بحرية كاملة وكمان مفاجآت اقرأ-تِك الجاية 🚀
وبرضو متاح الاشتراك من خلال InstaPay و VodafoneCash 🎁
مدونات فطين في تصميم النظم - الإصدار الأول 🚀
كتابة هذا الكتاب لم تكن قرارًا مخططًا... بل كانت نتيجة لتراكمات من الحيرة، الإحباط، والدهشة اللي بيواجهوا أغلب الشباب حاليًا خصوصًا في رحلة البحث عن تعلم مهارات تصميم النظم واللي أصبحت من المهارات الأساسية في الانترفيوهات بالإضافة لكونها مهمة فعلًا على جميع المستويات.
على مدار سنوات من العمل داخل شركات تكنولوجية متعددة، وجدت نفسي مرارًا أواجه بعض الأسئلة زي:
لماذا صُمّم هذا النظام بهذه الطريقة؟
لماذا لم نرَ المشكلة إلا بعد فوات الأوان؟
هل كان يمكن أن نصمم الأمر بشكل أبسط؟
الإجابات كانت دائمًا معقدة، وتعود لأبعاد تقنية وتنظيمية ونفسية أيضًا.
هذا الكتاب ليس دليلًا أكاديميًا، بل هو مجموعة من التجارب والخبرات العملية كتبتها بعين المهندس الذي يراقب، يسأل، ويُخطئ ثم يتعلّم. المجموعة دي لم يتم ترجمتها للعربية من مدونات الشركات العالمية .. بل تم اعادة شرحها وتبسيطها باللغة العربية بأسلوب مختلف حتى تتسم بالبساطة بالإضافة لتميزها بالرسوم التوضيحية الجذابة.
اخترت اسم "فَطين" لأنه الشخصية التي تمنيت لو كانت موجودة معي منذ البداية— يسأل الأسئلة الصحيحة، ويفكّر بصوت عالٍ، ويحكي لك الدروس المستفادة.
إن كنت مهندسًا في بداية الطريق، أو تعمل منذ سنين ولديك خبرة متوسطة أو متقدمة في تصميم وبناء النظم فهذا الكتاب كتبته لك ليكون مرجعًا عمليًا لك يساعدك في تطوير مهاراتك التحليلية والفكرية في بناء وتطوير النظم الضخمة.
يتناول الكتاب ما يعادل من 15 تجربة عملية مميزة من داخل الشركات العالمية في تصميم النظم الضخمة بأكتر من 160 صفحة ويضم الآتي :
Introduction Into System Design
How Uber Serves Over 40 Million Reads Per Second
How Discord Stores Trillions of Messages
Dropbox's Chrono: Scalable, Consistent and Metadata Caching Solution
Unlocking Notion's Power - The Data Model Explained
How Shopify Mitigates Deadlocks in High Concurrency Environments
How LinkedIn Improves Microservices Performance With Protobuf
How Figma Secures Internal Web Applications
How GitHub Improves Reliability of Code Push Processing
How Meta Leverages AI For Efficient Incident Response
How Stripe Architected Massive Scale Observability Solution on AWS
Change Data Capture at Pinterest
How Canva Built Scalable and Reliable Content Usage Counting Service
How Netflix Migrates Critical Traffic at Scale With No Downtime
How Slack Handles Billions of Tasks in Milliseconds
How YouTube Supports Billions of Users With MySQL
System Design Comprehensive Guide
تقدروا تشوفوا النسخة كاملة من هنا كـ E-Book ، وحاولنا نخليها بسعر رمزي يناسب الجميع 👇
وكمان وفرناه على Kindle عشان الناس اللي بتحب تجربة القراءة على الـ Kindle منحرمهاش من التجربة الممتعة دي 🎉
بفضل الله أصبح متاح حاليا دعمنا من خلال الرعاة والشراكات وفعلنا الـ Sponsorship واحنا بنرحب بجميع الشراكات مع المؤسسات والشركات وأصحاب الأعمال لبناء مجتمع عربي يشجع على القراءة والتعلم ومشاركة التجارب والخبرات العملية في هندسة البرمجيات.
دورك كشريك أو راعي هيكون محوري في دعم المحتوى وتوسيع نطاق تأثيره. فانضم لرحلتنا وكن جزءًا من صناعة مستقبل التكنولوجيا في المنطقة 🚀
تقدروا تشوفوا التفاصيل كاملة من هنا والـ Analytics بتاعتنا من خلال اقرأ-تِك والنشرة الأسبوعية 👇
رؤيتنا هي إثراء المحتوى التقني العربي وجعل التعلم من خلال القراءة أمتع، وذلك من خلال إثراء المحتوى التقني باللغة العربية وتشجيع المبرمجين على القراءة بلغتهم الأم والتفكير أيضًا بها.
لذلك اتحنا الفرصة أمام الجميع للمساهمة ومساعدتنا في نشر واثراء المحتوى التقني باللغة العربية, من خلال كتابة المقالات التقنية في مختلف مجالات هندسة البرمجيات.
وجب التنويه أنه لن يتم نشر كافة الأعمال التي تصل إلينا، وإنما سيتم الانتقاء منها ما يحقق هدفنا بإثراء المحتوى التقني العربي، ولذلك قد تُطلب بعض التعديلات من الكاتب قبل النشر.
لمعرفة المزيد بخصوص :
💬 المعايير العامة لكتابة ونشر المقالات
⚡️ كيفية الإرسال
🔥 التزامات اقرأ-تِك تجاه الكتاب
يمكنكم قراءة كافة التفاصيل من هنا 👇
نشرة بريدية مميزة كالعادة. عندي بعض الأسئلة لو سمحت
انا عملت deploy ل laravel app لاستخدام ك API ولكن لما بستخدم HTTPS في ال request بياخد وقت طويل جدًا 4 ثواني زيادة عن لما استخدم HTTP فقط
فهل السبب من Postman ال كنت بجرب عليه ولا مشكلة في SSL Ciretifacte أو السيرفر؟ ازاي ممكن اتتبع المشكلة دي؟
السؤال التاني بالنسبة ل Broadcast Channel API
هل لو عاملنا revalidate لل requests ال في الصفحة ال بتعرض الداتا ال بيحصلها update هنوصل لنفس النتيجة لما نبدل بين ال tabs ? لأن ال revalidte بينادي على ال request تاني لما نعمل focus تاني على الصفحة لما نبدل ال tabs؟
شكرًا لمجهودك