This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Sunday, 28 December 2025
HTTTTP لم يتطور. قـر قـرن للتغير عن طريق الفيزياء، والتأخير، وإساءة الاستخدام.
كل نسخة موجودة لأن النسخة السابقة ضغطت على قيد صعب. إذا كنت تفهم هذه القيود، فأنت تفهم لماذا يعمل الويب بالطريقة التي يعمل بها - ولماذا العديد من "أفضل الممارسات" هي في الواقع
لقد كنت أبني تطبيقات الويب منذ 1997 لقد قمت بتنقية HTTP / 1.00 عواصف الاتصال، شاهدت المتصفحات تفتح ستة وصلات لكل مضيف كـ "مهارة"، ملعونة في HTTP/2 رئيس الخط الرئيسي TCP على الشبكات المتنقلة، وأخيرا رأيت HTTP/3 يعترف بما نعرفه طوال الوقت: الشبكة هي المشكلة.
هذه ليست بروتكولاً تعليمياً إنها قصة كيف وصلنا إلى هنا
HTTTP/ 1.0 تم تصميمها في عام 1996 لعالم لم يعد موجوداً. لفهم سبب نجاحها، تحتاج إلى فهم ما تعنيه "الويب" في عام 1996:
في هذا العالم، الزجاجة كانت النطاق التردديصفحة 50 كيلو بايت استغرقت 15 ثانية لتحميلها عند الطلب من يهتم بمصافحة 200 متر إضافية؟
ما هو HTTTP/ land أفضل ما يلي:
GET /index.html HTTP/1.0
Host: example.com
HTTP/1.0 200 OK
Content-Type: text/html
<html>...
بسيط، ذكي، مثالي لعام 1996، وغير قابل للاستخدام تماماً لأي شيء أبعد من استرجاع الوثائق.
ثم تغيرت الشبكة بسرعة
وبحلول عام 1998، لم تكن الصفحات مجرد وثائق. كان لديهم أوراق نمطية، ودفاتر جافاسكربت، وصور متعددة. صفحة واحدة قد تحتاج إلى 20-30 موارد منفصلة.
كل طلب واحد يتطلب ما يلي:
أي صفحة بـ 20 مورداً يعني 20 مصافحة لـ TCCP. على اتصال 200 ms contradition (ما زال شائعاً)، هذا يعني 4 ثوان من مـا يمـايـد مـن تمـايـد قبل نقل أي محتوى.
الافتراض الأساسي للHTTTP/1-0:
الوقت كان رخيصاً
في عام 1996، كانت كذلك في عام 1996، وكان باندويدث هو عنق الزجاجة. وبحلول عام 1999، كان عرض العرض يتحسن ولكن التأخير في المواني لم يكن - وفجأة تلك الرحلات الدوارة كانت مهمة
تم تصميم HTTTP / 1.0 من أجل الوثائق. لقد أصبحت الشبكة منصة تطبيق. شيء ما كان يجب أن يعطي.
وصل HTTTP/1.1 في عام 1997، تماما كما ان الوب كان ينفجر. بدأ ازدهار دوتكوم. كل عمل يحتاج إلى موقع على الإنترنت. صفحات الويب كانت تحصل على جداول معقدة للتصميم، جافاسكربت للتفاعل، الصور في كل مكان.
كان الضغط واضحاً: كان أداء الأداء في مجال القتللكن إعادة تصميم HTTP بالكامل لم يكن خياراً، الكثير من البنية التحتية تعتمد عليه بالفعل، الحل يجب أن يكون متوافقاً مع الوراء
ما الذي تغيّر:
Connection: keep-alive - إعادة استخدام وصلة TCPCache-Control, ETag(الطلبات المشروطة)ما الذي لم يتغير:
GET /page.html HTTP/1.1
Host: example.com
Connection: keep-alive
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: max-age=3600
...
HTTTP/1.1 لم تحل في الواقع مشكلة الأداء. فقط حركتها حولها.
كانت عملية التناصف فاشلة. المواصفات المسموح بها لإرسال طلبات متعددة على اتصال واحد، ولكن:
لذا فإن المتصفحين غشوا. بدلاً من إصلاح البروتوكول، عملوا حوله:
static1.example.com, static2.example.com) على نحو مضروب لوصلاتولم يكن أي من هذا البروتوكول يعمل كما هو مصمم، بل كان النظام الإيكولوجي بأكمله يعوض الحد الأساسي للHTTTP/1.1.
HTTTP/Impleed by الغش، وليس عن طريق تحديد النموذج.
HTTTT/ 1 يعمل مـن جـيـف جـيـف جـيـف جـيـف جـيـف لخمسة عشر عاماً، ليس لأنها كانت جيدة، ولكن لأن البيئة عوضت:
كان البروتوكول لا يزال معطلاً كنا محظوظين أن العالم يخبئه
تلك الوصلات الست لكل مضيف لم تكن مجانية:
أصبحت الشبكة أسرع في عصر HTTTP/1.1. ولكن ليس بسبب HTTP/1.1. أصبحت أسرع لأن:
كنّا نبني منصة تطبيق على بروتوكول إسترجاع الوثائق، البروتوكول كان يخسر، لم نشعر به بعد.
وبحلول عام 2010، كان أداء الشبكة العالمية معركة مستمرة ضد HTTP نفسها.
"أفضل الممارسات" في هذه الحقبة تروي القصة:
كل واحدة من هذه هي حل عملي لـ "HTTTP/1.1، لا يمكن التعامل مع العديد من الطلبات بكفاءة."
بنيت العديد من هذه الأدوات الصغيرة مثل المولدات العطرية، ضاغطات CSS، بدأنا باستخدام ضغط الاستجابة...
المتصفحات لم تكن أسرع لأن HTTTTP تحسنت. كانت أسرع لأنها العمل حول HTTP.
ستة إتصالات لكل مضيف ليست ميزة، إنه إختراق، تشقق المجال ليس أفضل ممارسة، إنه إقرار بالفشل
لقد قضيت سنوات في تعليم المطورين تجميع الأصول، والصور، والموارد الحيوية. لا شيء من ذلك كان "البنيان الجيد". (أ) (أ) )).
أسطورة "HTTTP بسيطة" استمرت لأن التعقيد كان مخفيا في:
HTTTTTT/ 1 1 يعمل لأن كل شيء + عملت بشكل إضافي للتعويض.
إذا رأيت رسماً بيانياً من HTTP لا يظهر الميعاد أو الخسارة أو أنماط الفشل، فإنه يكذب عليك. البروتوكول بسيط. الواقع ليس كذلك.
بحلول عام 2010، تحول الويب مرة أخرى. تحولان هائلان غيرا كل شيء:
1 - حدث النقل. بدأ تشغيل الآي فون عام 2007 وبحلول عام 2012، انفجرت حركة الشبكة المحمولة. فجأة لم يكن المستخدمون على النطاق العريض السلكي - كانوا على 3G، ثم 4G، مع تغير التأخير وفقدان الحزم المتكررة. والافتراضات التي جعلت HTTP/1.1 قابلة للتقبل كانت تنهار.
2 - استعيض عن صفحات الإنترنت بالتطبيقات الشبكية. Gmail. Gogle Maps. فيسبوك. تويتر. هذه لم تكن وثائق مع روابط. كانت تطبيقات تحتاج إلى العشرات أو المئات من الموارد، تحديثات آنية، واستجابة فورية. الإختراق "ستة وصلات لكل مضيف" كان يظهر عمره.
شعر جوجل بهذا الألم بشكل حاد. كان لديهم نطاق ضخم، المهندسين المهووسين بالأداء، والبيانات لإثبات HTTP/1.1 كانت عنق الزجاجة. في عام 2009، بدأوا SPDY - بروتوكول تجريبي من شأنه أن يصبح HTTP/2.
ما الذي تغيّر:
┌──────────────────────────────────────────┐
│ Single TCP Connection │
├──────────────────────────────────────────┤
│ Stream 1: GET /page.html │
│ Stream 3: GET /style.css │
│ Stream 5: GET /app.js │
│ Stream 7: GET /logo.png │
│ (all interleaved, no ordering required) │
└──────────────────────────────────────────┘
هذا ما كان يجب أن يكون HTTTP/ 1.1. السلاسل مستقلة. استجابة بطيئة واحدة لا تمنع الآخرين. الترويسات مضغوطة. البروتوكول يطابق أخيراً كيف نستخدم الوب فعلياً.
HTTTP/2 كان الكمالية لشبكة الإنترنت العريضةوفي عام 2015، عندما تم توحيده، كان النطاق العريض في كل مكان في العالم المتقدم.
ما هي التحسينات:
بالنسبة للمستخدمين على الاتصالات السلكية مع فقدان حزمة منخفضة، HTTP/2 كان تحسن حقيقي. المقاييس بدت كبيرة. القياسات تحسنت. جوجل أعلنت النصر.
ولكن العالم قد انتقل بالفعل. أما الآن فقد أصبحت شركة موبيل (Mobile) غالبية حركة المرور على شبكة الإنترنت.
ولشبكات الهواتف النقالة خاصية أساسية لا يملكها النطاق العريض: الخسارة التي كانت ثابتة.
(ج) ضمانات في طلب التسليموإذا فُقدت الحزمة 47، فإن الحزم 48-100 تنتظر إلى أن يعاد إرسال 47 - حتى وإن كانت تنتمي إلى تيارات HTTP/2 المستقلة تماماً.
┌──────────────────────────────────────────┐
│ TCP Receive Buffer │
├──────────────────────────────────────────┤
│ [pkt 45][pkt 46][ ? ][pkt 48][pkt 49] │
│ ↑ │
│ Waiting for packet 47 │
│ │
│ Stream 1 data: BLOCKED │
│ Stream 3 data: BLOCKED │
│ Stream 5 data: BLOCKED (has pkt 48-49) │
│ Stream 7 data: BLOCKED │
└──────────────────────────────────────────┘
وقام HTTTP/2 بحل سد رأس الخط عند طبقة التطبيق، ثم أعاده TCP إلى طبقة النقل.
واحد خسر حزمة كل الجداول. على اتصال سلكي نظيف، فإن خسارة الحزم نادرة. على شبكات الهاتف النقال، أو WiFi المفقودة، أو الوصلات المزدحمة؟ خسارة العبوة ثابتة. ولأن HTTP/2 يستخدم a. واحد (بالربط (حسب التصميم)) واحد مفقود حزمة الآن " كل شيء " بدلاً من مجرد واحد من ستة ملامسات.
أداء HTTTTP/2:
المفارقة: HTTTP/2 كانت مصممة للتنقل، ولكن ضمانات TCP جعلتها أسوأ على الهاتف المحمول من البروتوكول الذي استبدلته.
أظهرت عمليات نشر HTTTP/2 الأولية تحسينات حقيقية:
لكن التأخير في كتابة قصّة مختلفة. المتوسط لقد أصبحت أفضل، الـ (بي 99) أصبحت أسوأ
رأيت هذا مباشرة: عميل مكّن HTTTP/2 عبر CDN وشاهد المتنقل P99 الزيادة(أ) 40%. أظهرت لوحات العرض تحسناً على سطح المكتب. جاءت تذاكر الدعم من مستخدمي الهواتف المحمولة. قضينا أسبوعاً في معرفة أن "تحسين" HTTP/2 كان يزيد الأمور سوءاً بالنسبة لغالبية حركة مرورهم.
عندما يعمل HTTTP/2، فإنه يعمل بشكل جميل. عندما تسقط حزمة على اتصال جوال في أسوأ لحظة، فإن كل شيء يتجمد. ويجمد المستخدمون إشعارات أكثر مما يلاحظون متوسطات سريعة.
المشكلة الأساسية:
إفترض HTTTP/2 أن TCP كانت جيدة بما فيه الكفاية.
بالنسبة للنطاق العريض، كان كذلك. بالنسبة للهاتف المحمول، لم يكن كذلك. وبحلول الوقت الذي تم توحيد HTTP/2، كان الهاتف المحمول قد فاز بالفعل. كنا قد دفعنا بقدر ما يمكن أن يأخذنا TCP.
وبحلول عام 2015، كانت الأدلة واضحة: كان هذا هو المشكلة.
كان جوجل يعمل على تشغيل QUIC تجريبياً منذ عام 2012. كان لديهم البيانات. على شبكات الهواتف النقالة، والواي فاي الخاسرة، والاتصالات عالية السرعة، HTTP/2 على TCP كان يفشل بطرق لا يمكن إصلاحها بدون تغيير طبقة النقل.
لكن لا يمكنك أن "تثبت TCP" فقط. إنه ينفذ في نوافذ نظام التشغيل. إنه مُحَصَّل إلى كل جهاز توجيه، جدار ناري، و صندوق وسط على الإنترنت. تغيير TCP يعني انتظار عقود من أجل تطوير البنية التحتية للإنترنت بالكامل.
إذاً فقد فعل جوجل شيئاً مُجحفاً: قاموا ببناء بروتوكول نقل جديد على رأس UDP.
UDP هو "dumb" بالتصميم - إنه فقط يرسل حزماً بدون ضمانات. لكن هذا بالضبط ما تحتاجه إذا كنت تريد تنفيذ لـكـلـكككـل إعادة تنفيذ ضمانات TCP (التي يمكن التعويل عليها، والتسليم بأمر التسليم) ولكنها تفعل ذلك )١ بدلاً من الوصلة.
HTTTP/3 (2022) هو HTTP / QUIC. هو الاعتراف أننا بحاجة إلى الذهاب تحت HTTP لإصلاح HTTP.
ما الذي تغيّر:
┌──────────────────────────────────────────┐
│ QUIC Connection │
├──────────────────────────────────────────┤
│ Stream 1: [pkt][pkt][pkt] ← flowing │
│ Stream 3: [pkt][ ? ][pkt] ← waiting │
│ Stream 5: [pkt][pkt][pkt] ← flowing │
│ Stream 7: [pkt][pkt] ← flowing │
│ │
│ Lost packet only affects Stream 3 │
└──────────────────────────────────────────┘
ما بقي على حاله:
HTTTP/3 لم يغير HTTP. غير كيف أن HTTP ينجو من الواقع.
تنفيذ ضمانات ضمانات موثوقية شركة TCP )١هذه هي البصيرة الرئيسية
وعد TCP: "كل بايت يصل بالترتيب" وعد quilic's quilic' s الوعد: "كل جزء من كل في هذا الشكل في النظام ".
هذا التمييز هو السبب في أن HTTP/3 لا ينهار على الشبكات الخاسرة.
(أ) خصائص ثاني أكسيد الكربون التي تسبب مشاكل طويلة الأمد:
الاتصال::
Phone on WiFi → walks out of range → switches to cellular
TCP: Connection dies. Restart everything.
QUIC: Connection ID maintained. Streams continue.
هذا مهم لأن مستخدمي الهاتف النقال (تابع) أخرجوا من منزلكم، وافقدوا الواي فاي، وحوّلوا إلى الهاتف الخلوي، مع TCP، كل اتصال يموت، مع QUIC، تواصل الاتصال.
الاستئناف:
First connection: Full handshake (1-RTT)
Returning user: Send data immediately (0-RTT)
التشفير في كل مكان:
TCP + TLS: Handshake, then encrypted tunnel
QUIC: Encryption is the handshake (TLS 1.3 integrated)
HTTTP/3 مصممة للعالم الذي نعيش فيه فعلياً:
وأخيراً يطابق البروتوكول واقع الشبكة. فبعد ثلاثين عاماً من افتراض HTTP/1.0 اتصالات سلكية موثوقة، يعترف HTTP/3 بأن الموثوقية هي الاستثناء وليس القاعدة.
HTTTP/3 ليس حرّاً:
ولكن بالنسبة للتطبيقات الأولى المتنقلة، والشبكات غير الموثوقة، والخدمات الحساسة للتأخر، HTTP/3 هي النسخة الأولى التي تطابق كيفية تصرف الشبكات في الواقع.
كل تغيير في نسخة HTTTTTP حدث بسبب تغير البيئة أسرع من البروتوكول.
□ الإصدار □ أَرْ □ البيئة □ لِمَ تُفَكِّر □ □ |---------|-----|-------------|------------|--------------| □ HTTTP/ 1.0 ° 1996 □ Dialup، الوثائق □ Bandwidth هي الاختناق القنينة HTTTTP/1.1 JIU 1999-2015 owldward, Web Polities o Low Lo Low Lot Translated by conference systems TM HTTTP/ 1. HTTTP/2 JIU 2015-2022 o 2015-2022 ° ذروة النطاق العريض، الإرتفاع المتنقل TMCP هو موثوق به بما فيه الكفاية HTTTP/3 o 2022+ o Mobile-First، عالمي لا شيء يمكن التعويل عليه
والنمط واضح:
البروتوكول يستمر في الحصول على دفع أكثر قربا إلى الشبكة. كل عملية تجريدية بدت كافية حصلت على قشرة مرة أخرى عندما طلبتها البيئة.
ملاحظات أخرى:
هنا الجزء غير المريح على الرغم من ثلاثين سنة من تطور البروتوكول
الطلبات لا تزال فاشلة. تحطّم الخوادم، توقّف، توقّفات يحدث، شفّرتك لا تزال بحاجة إلى منطق إعادة التّجربة.
الشبكات لا تزال موجودة. % 200 لا يعني أن الرد صحيح. الاتصال المغلق لا يعني أن الطلب لم ينجح. التوقيت لا يعني أن الخادم لم يجهز طلبك.
الشوكولاتة لا تزال تخدم البيانات القديمة.
Cache-Control الوكلاء يفعلون ما يريدون. إبطال الـ CDN هو في نهاية المطاف في أحسن الأحوال.
العملاء مازالوا في حالة سيئة. نقرات مستخدم زر لا شيء يحدث انقرات مرّة أخرى الآن لديك طلبان
ولا يزال المطورون يسيئون فهم القدرة القصوى. يجب أن يكون آمنًا، يجب أن يكون (بوت) قادرًا على فعل ذلك، الوظيفة هي الغرب المتوحش، معظم الـ(آي بي آي) يخطئون في فهم هذا.
// This is still your problem, regardless of HTTP version
public async Task<Result> CreateOrderAsync(Order order)
{
// What happens if this times out?
// Did the server receive it?
// Did it process it?
// Will the client retry?
// Will you create duplicate orders?
// HTTP/3 doesn't save you here.
// Idempotency keys do.
}
إذا كنت لا تفهم هذه، HTTP/3 لن ينقذك.
بعد بناء تطبيقات الويب عبر كل هذه النسخ البروتوكولية، إليكم ما هو المعلق:
1 - البروتوكول ليس طبقتك الموثوقة.
HTTP يعطيك الطلب/الاستجابة الدلالات. هذا لا يضمن التسليم، الدقة، أو المعالجة بالضبط. هذا هو عملك.
2 - أن تكون الاستقامة هي العدو وليس عرض النطاق الترددي.
فمعظم مشاكل الأداء ملزمة بالرحلة ذهابا وإيابا وليست ملزمة بالناتج، أما خفض الطلبات فيهم أكثر من الحمولات المضغوطة.
3 - لكل "ممارسة فضلى" تاريخ انتهاء.
كان تجليد المجال أساسياً لـ HTTTP/1.1. هو ضار لـ HTTP/2. في وضع الـ CSS كان ذكياً. الآن لدينا خادم دفع (الذي فشل أيضاً) وتلميحات مبكرة. التكتيكات تتغير. الهدف (الرفع المتأخر) يبقى نفسه.
4- قياس الشبكات الحقيقية.
المعايير على المضيف المحلي لا تثبت شيئاً، مستخدموكم على شبكات الهواتف المحمولة، والواي فاي الفندقية، وروابط المقهى المشبعة، اختبروا هناك.
والأجزاء المملّة هي الأكثر أهمية.
فترات ، فترات ، فترات ، فترات ، فواصل ، فواصل الدوائر ، عدم قدرة ، تجمّع الإتصال ، تجمّع ، هذه التفاصيل غير المتوافقة تحدّد ما إذا كان نظامك يعمل تحت الحمولة.
HTTTTP لم يصبح أسرع لأنه أصبح أكثر ذكاءً. أصبح أسرع لأننا أخيراً اعترفنا الشبكة كانت المشكلة.
وكانت كل نسخة مناسبة لوقتها:
فالخطأ هو الاعتقاد بأن أياً من هذه الحلول هي حلول دائمة، وكلها استجابات لضغوط بيئية محددة، وعندما تتغير البيئة، يتعين على البروتوكول أن يتبعه.
إصدارات HTTP ليست تحديثات بالمعنى الاستهلاكي، بل هي مقايضات مفضلة لمختلف توزيعات الفشل.
ومع ذلك، بعد كل ذلك، تبقى الأساسيات:
تطور البروتوكول، المشاكل لم تختفي، لقد تحركوا للتو
بناء الأنظمة التي تنجو من الفشل. اختبار على الشبكات الحقيقية. فهم أن كل نسخة HTTP هي مقايضة على شكل عصرها، وليس ترقية التي عفا عليها الزمن ما جاء من قبل.
هذه ثلاثون سنة من HTTP. هذه هي الشبكة التي بنيناها. وفي عقد آخر، افتراضات HTTP/3 على الأرجح ستبدو مؤرخة كما يفعل HTTP/1.0 الآن.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.