برنامه نویسی

پروتکل HTTP: چگونه کار می کند و چرا از این طریق طراحی شده است – Community Dev

ek3nk4r 2025-02-15

0 1 خواندن این مطلب 15 دقیقه زمان میبرد

پروتکل HTTP: چگونه کار می کند و چرا از این طریق طراحی شده است – Community Dev

پیشنهاد ویژه

خرید فالوور واقعی خرید لایک اینستاگرام خرید ویو اینستاگرام خرید فالوور اینستاگرام

شرح تصویر

Leapcell: The Next – Gen Serverless Server برای میزبانی وب ، کارهای Async و Redis

شرح تصویر

در دنیای اینترنت ، پروتکل HTTP بدون شک یک پروتکل اساسی و دانش اساسی در زمینه توسعه وب است. به طور خاص ، آخرین نسخه آن ، HTTP/2 ، توجه گسترده ای را به خود جلب کرده و به یک کانون فناوری تبدیل شده است. این مقاله به تکامل تاریخی و مفاهیم طراحی پروتکل HTTP می پردازد و به خوانندگان کمک می کند تا درک کاملی از این فناوری مهم کسب کنند.

فهرست مطالب

I. http/0.9: شکل جنینی ارتباطات اینترنتی

HTTP یک پروتکل کاربردی – لایه بر اساس پروتکل TCP/IP است. این برنامه بر مشخص کردن قالب ارتباطی بین مشتری و سرورها تمرکز دارد و شامل انتقال بسته های داده نمی شود. برای استفاده از پورت 80 به طور پیش فرض است. نسخه HTTP/0.9 که در سال 1991 منتشر شد ، اولین نسخه پروتکل HTTP است. طراحی آن بسیار ساده است و تنها با یک دستور دریافت می شود.

GET /index.html

معنی دستور فوق این است که پس از برقراری اتصال TCP ، مشتری از فهرست صفحه وب درخواست می کند. html از سرور. با توجه به پروتکل ، سرور فقط می تواند با یک رشته HTML – فرمت شده پاسخ دهد و نمی تواند در قالب های دیگر پاسخ دهد. به عنوان مثال:


  Hello World

پس از اتمام ارسال سرور ، بلافاصله اتصال TCP را می بندد. اگرچه این نسخه ساده است ، اما پایه و اساس توسعه بعدی پروتکل HTTP را ایجاد کرده و ایجاد یک حالت ارتباطی ساده بین مشتری و سرور را مشخص کرده است.

ii. HTTP/1.0: گسترش اولیه توابع

در ماه مه 1996 ، نسخه HTTP/1.0 منتشر شد. در مقایسه با HTTP/0.9 ، محتوای آن به میزان قابل توجهی افزایش یافته و تغییرات مهمی در توسعه اینترنت به همراه دارد.

2.1 مقدمه

تنوع فرمت های محتوا: HTTP/1.0 امکان ارسال محتوا در هر قالب را فراهم می کند. این امر باعث می شود اینترنت دیگر محدود به انتقال متن نباشد و انواع مختلفی از داده ها مانند تصاویر ، فیلم ها و پرونده های باینری را می توان از طریق شبکه منتقل کرد و پایه ای محکم برای توسعه متنوع اینترنت ایجاد کرد.
دستورات تعاملی غنی: علاوه بر دستور GET ، فرمان پست و فرمان سر معرفی شدند. از دستور پست اغلب برای ارسال داده ها به سرور استفاده می شود ، مانند اطلاعات ارسال شده در هنگام ثبت نام کاربر و ورود. فرمان سر عمدتا برای به دست آوردن متا – اطلاعات منابع بدون بازگشت محتوای منبع واقعی استفاده می شود. افزودن این دستورات روشهای تعامل بین مرورگرها و سرورها را بسیار غنی کرده است.
تغییر در قالب های درخواست و پاسخ: در هر ارتباط ، علاوه بر قسمت داده ها ، اطلاعات عنوان (هدر HTTP) باید درج شود که برای توصیف برخی ابرداده ها مانند منبع درخواست ، نوع مشتری و قالب های داده قابل قبول استفاده می شود. علاوه بر این ، توابع مانند کدهای وضعیت (کد وضعیت) ، پشتیبانی چندگانه ، ارسال چند بخشی (نوع چند قسمت) ، مجوز ، حافظه پنهان و رمزگذاری محتوا اضافه شد. از کد وضعیت برای نشان دادن نتیجه پردازش سرور برای درخواست استفاده می شود. به عنوان مثال ، 200 نشانگر درخواست موفقیت آمیز است و 404 نشان می دهد که این منبع پیدا نشده است. پشتیبانی چندگانه – نمایشگر نمایش صحیح محتوا به زبانهای مختلف در اینترنت را امکان پذیر می کند. عملکرد حافظه نهان می تواند درخواست های مکرر را کاهش داده و سرعت دسترسی را بهبود بخشد.

2.2 قالب درخواست

شرح تصویر

GET / HTTP/1.0
User - Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

در مقایسه با نسخه HTTP/0.9 ، قالب درخواست نسخه 1.0 به طور قابل توجهی تغییر کرده است. خط اول دستور درخواست است و نسخه پروتکل (HTTP/1.0) باید در پایان اضافه شود. موارد زیر چندین خط از اطلاعات هدر است که برای توصیف وضعیت مشتری استفاده می شود. قسمت کاربر – عامل نوع و نسخه مشتری را مشخص می کند و قسمت پذیرش قالب های داده ای را که مشتری می تواند بپذیرد اعلام می کند.

2.3 قالب پاسخ

شرح تصویر

HTTP/1.0 200 OK 
Content - Type: text/plain
Content - Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last - Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84


  Hello World

قالب پاسخ سرور “اطلاعات هدر + یک خط خالی (\ r \ n) + داده” است. در میان آنها ، خط اول “نسخه پروتکل + کد وضعیت (کد وضعیت) + توضیحات وضعیت” است. کد وضعیت 200 یک درخواست موفق را نشان می دهد ، و توضیحات وضعیت خوب است. قسمت محتوا – نوع نوع داده ها را نشان می دهد ، قسمت محتوا – طول طول داده ها را نشان می دهد ، قسمت منقضی شده زمان انقضا منبع را مشخص می کند ، قسمت آخر – اصلاح شده نشان دهنده آخرین زمان اصلاح منبع و منابع است. قسمت سرور نوع و نسخه سرور را مشخص می کند.

2.4 محتوا – زمینه را تایپ کنید

در نسخه HTTP/1.0 ، اطلاعات هدر باید در کد ASCII باشد و داده های بعدی می توانند در هر قالب باشند. بنابراین ، هنگامی که سرور پاسخ می دهد ، باید فرمت داده ها را از طریق قسمت محتوا – نوع داده به مشتری بگوید. مقادیر مشترک محتوا – نوع شامل موارد زیر است:

انواع متن: متن/ساده (متن ساده) ، متن/HTML (سند HTML) ، متن/CSS (برگه سبک CSS).
انواع تصویر: Image/JPEG (Image JPEG) ، Image/PNG (تصویر PNG) ، Image/SVG + XML (گرافیک بردار SVG).
انواع صوتی و تصویری: AUDIO/MP4 (MP4 Audio) ، Video/MP4 (MP4 Video).
انواع برنامه: برنامه/JavaScript (اسکریپت JavaScript) ، Application/PDF (سند PDF) ، برنامه/ZIP (پرونده فشرده شده ZIP) ، برنامه/ATOM + XML (سند ATOM XML).

این انواع داده ها در مجموع انواع MIME نامیده می شوند. هر مقدار شامل یک نوع اولیه و یک نوع ثانویه است که با یک برش جدا می شود. علاوه بر انواع از پیش تعریف شده ، تولید کنندگان همچنین می توانند انواع سفارشی مانند مواردی را تعریف کنند application/vnd.debian.binary - package، نشان می دهد که داده های ارسال شده یک بسته داده باینری از سیستم Debian است. انواع MIME همچنین می توانند در انتها با استفاده از یک قسمت اصلی پارامترهایی اضافه کنند. به عنوان مثال ، Content - Type: text/html; charset=utf - 8 نشان می دهد که داده های ارسال شده یک صفحه وب است و رمزگذاری UTF – 8 است. Accept: */* نشان می دهد که مشتری می تواند هر فرمت داده را بپذیرد. انواع MIME نه تنها در پروتکل HTTP مورد استفاده قرار می گیرند بلکه در زمینه های دیگر نیز به طور گسترده استفاده می شوند. به عنوان مثال ، در یک صفحه وب HTML ، نوع رمزگذاری و محتوای صفحه را می توان از طریق مشخص کرد یا بشر

2.5 محتوا – زمینه رمزگذاری

از آنجا که داده های ارسال شده می توانند در هر قالب ، برای بهبود راندمان انتقال باشند ، داده ها را می توان قبل از ارسال فشرده کرد. از قسمت رمزگذاری محتوا برای نشان دادن روش فشرده سازی داده ها استفاده می شود. مقادیر مشترک هستند gzipبا compressبا deflateبشر هنگامی که مشتری درخواست می کند ، از قسمت پذیرش – رمزگذاری استفاده می کند تا روشهای فشرده سازی را که می تواند بپذیرد ، مانند Accept - Encoding: gzip, deflateبشر

2.6 مضرات

نقطه ضعف اصلی نسخه HTTP/1.0 این است که هر اتصال TCP فقط می تواند یک درخواست ارسال کند. پس از ارسال داده ها ، اتصال بسته می شود. در صورت درخواست منابع دیگر ، باید ارتباط جدیدی برقرار شود. هزینه ایجاد یک اتصال TCP جدید نسبتاً زیاد است ، زیرا مشتری و سرور نیاز به انجام یک دست سه راه دارند و میزان انتقال اولیه آهسته است (شروع آهسته) و در نتیجه عملکرد ضعیف نسخه HTTP 1.0 است. هرچه بیشتر و بیشتر منابع خارجی در صفحات وب بارگیری می شوند ، این مشکل برجسته تر شده است. برای حل این مشکل ، برخی از مرورگرها در درخواست از یک قسمت اتصال غیر استاندارد استفاده کردند:

Connection: keep - alive

این قسمت به سرور نیاز دارد تا اتصال TCP را ببندد تا از سایر درخواست ها استفاده شود. اگر سرور نیز با این قسمت پاسخ دهد ، می توان اتصال TCP قابل استفاده مجدد را ایجاد کرد تا زمانی که مشتری یا سرور به طور فعال اتصال را ببندند. با این حال ، این یک زمینه استاندارد نیست و رفتار پیاده سازی های مختلف ممکن است متفاوت باشد ، بنابراین یک راه حل اساسی نیست.

iii HTTP/1.1: یک نسخه کلاسیک که به طور گسترده استفاده می شود

در ژانویه 1997 ، نسخه HTTP/1.1 منتشر شد ، تنها نیم سال بعد از نسخه 1.0. این پروتکل HTTP را بیشتر بهبود بخشید و به نسخه ای تبدیل شد که هنوز هم امروزه مورد استفاده قرار می گیرد.

3.1 اتصال مداوم

بزرگترین تغییر در نسخه HTTP/1.1 ، معرفی اتصال مداوم است ، یعنی اتصال TCP به طور پیش فرض بسته نمی شود و بدون نیاز به اعلام می تواند با درخواست های متعدد مورد استفاده مجدد قرار گیرد Connection: keep - aliveبشر مشتری و سرور می توانند به طور فعال اتصال را ببندند وقتی متوجه می شوند که طرف مقابل مدتی غیرفعال بوده است. با این حال ، روش استاندارد این است که مشتری ارسال می کند Connection: close در آخرین درخواست ، صریحاً از سرور بخواهید اتصال TCP را ببندد. در حال حاضر ، بیشتر مرورگرها اجازه می دهند تا 6 اتصال مداوم برای همان نام دامنه ایجاد کنند که این امر باعث افزایش کارایی پروتکل HTTP می شود.

3.2 لوله کشی

نسخه HTTP/1.1 همچنین مکانیسم لوله کشی را معرفی کرد. در همان اتصال TCP ، مشتری می تواند چندین درخواست را همزمان ارسال کند. به عنوان مثال ، اگر مشتری نیاز به درخواست دو منبع دارد ، رویکرد قبلی ارسال درخواست اول در همان اتصال TCP بود ، سپس منتظر پاسخ سرور باشید و پس از دریافت پاسخ ، درخواست B را ارسال کنید. مکانیسم لوله کشی به مرورگر اجازه می دهد تا همزمان درخواست A و درخواست B را ارسال کند. اگرچه سرور هنوز به درخواست اول به صورت توالی پاسخ می دهد و سپس پس از اتمام به درخواست B پاسخ می دهد ، این روش بیشتر باعث افزایش کارایی پروتکل HTTP می شود.

3.3 محتوا – قسمت طول

در نسخه HTTP/1.1 ، یک اتصال TCP می تواند چندین پاسخ را منتقل کند. بنابراین ، مکانیسم لازم است تا تشخیص دهد که یک بسته داده به کدام پاسخ تعلق دارد. عملکرد قسمت محتوا – طول اعلام طول داده ها در این پاسخ است. به عنوان مثال:

Content - Length: 3495

این خط کد به مرورگر می گوید که طول این پاسخ 3495 بایت است و بایت های بعدی متعلق به پاسخ بعدی است. در نسخه 1.0 ، قسمت محتوا – طول لازم نبود زیرا مرورگر می دانست که تمام بسته های داده هنگام تشخیص اینکه سرور اتصال TCP را بسته است ، دریافت شده است. در نسخه 1.1 ، از آنجا که می توان از اتصال TCP استفاده مجدد کرد ، برای تشخیص پاسخ های مختلف لازم است طول داده ها را روشن کنید.

رمزگذاری نقل و انتقالات 3.4 قطعه قطعه شده

فرضیه استفاده از قسمت محتوا – طول این است که سرور باید قبل از ارسال پاسخ ، طول داده های پاسخ را بداند. برای مدتی – مصرف عملیات پویا ، این بدان معنی است که سرور باید منتظر بماند تا تمام عملیات قبل از ارسال داده ها به اتمام برسد و در نتیجه راندمان کم باشد. برای حل این مشکل ، نسخه HTTP/1.1 تصریح می کند که می توان از قسمت محتوا – طول استفاده کرد و به جای آن می توان از “رمزگذاری انتقال خرد شده” استفاده کرد. تا زمانی که هدر درخواست یا پاسخ دارای یک قسمت انتقال – رمزگذاری باشد ، نشان می دهد که این پاسخ از تعداد مشخصی از بخش های داده تشکیل شده است. به عنوان مثال:

Transfer - Encoding: chunked

قبل از هر قطعه داده غیر خالی ، یک مقدار شش ضلعی وجود خواهد داشت که طول این تکه را نشان می دهد. سرانجام ، تکه ای از اندازه 0 نشان می دهد که داده های موجود در این پاسخ به طور کامل ارسال شده است. موارد زیر به عنوان مثال است:

HTTP/1.1 200 OK
Content - Type: text/plain
Transfer - Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con

8
sequence

0

این روش به سرور اجازه می دهد تا به محض تولید ، داده ها را ارسال کند و جایگزین “حالت بافر” با “حالت جریان” شود و کارایی انتقال داده را بهبود بخشد.

3.5 عملکرد دیگر

نسخه HTTP/1.1 همچنین بسیاری از روشهای فعل ، مانند PUT (برای به روزرسانی منابع) ، پچ (استفاده شده برای به روزرسانی جزئی منابع) ، سر (مشابه GET ، اما فقط اطلاعات هدر را برمی گرداند ، نه محتوای منبع) ، گزینه ها را اضافه کرد. برای به دست آوردن اطلاعاتی از قبیل روش های درخواست پشتیبانی شده توسط سرور استفاده می شود) ، حذف (برای حذف منابع استفاده می شود). علاوه بر این ، هدر درخواست مشتری – جانبی یک قسمت میزبان را اضافه کرد که برای مشخص کردن نام دامنه سرور استفاده می شود. به عنوان مثال:

Host: www.example.com

با استفاده از قسمت میزبان ، درخواست ها می توانند به وب سایت های مختلف در همان سرور ارسال شوند و پایه و اساس ظهور میزبان های مجازی را فراهم می کنند. از طریق قسمت میزبان ، سرور می تواند خدمات مختلفی را با توجه به نام دامنه های مختلف ، دستیابی به اشتراک منابع و انزوا ارائه دهد.

3.6 مضرات

اگرچه نسخه HTTP/1.1 امکان استفاده مجدد از اتصالات TCP را فراهم می کند ، در همان اتصال TCP ، تمام ارتباطات داده به ترتیب انجام می شود. سرور فقط پس از تکمیل یک پاسخ ، پاسخ بعدی را پردازش می کند. اگر پاسخ قبلی به خصوص آهسته باشد ، بسیاری از درخواست ها صف می روند و منتظر می مانند ، که به آن “سر مسدود کردن خط” گفته می شود. برای جلوگیری از این مشکل ، در حال حاضر فقط دو روش وجود دارد: یکی کاهش تعداد درخواست ها و دیگری باز کردن چندین اتصالات مداوم به طور همزمان است. این امر منجر به ظهور بسیاری از تکنیک های بهینه سازی صفحه وب ، مانند ادغام اسکریپت ها و برگه های سبک ، تعبیه تصاویر در کد CSS و Sharding دامنه شده است. با این حال ، اگر پروتکل HTTP بهتر طراحی شده باشد ، می توان از این تلاش های اضافی جلوگیری کرد.

IV پروتکل SPDY: پیشرو HTTP/2

در سال 2009 ، Google پروتکل SPDY خود را به طور عمومی منتشر کرد ، که عمدتاً با هدف حل مشکل کارایی پایین HTTP/1.1 انجام شد. پس از اثبات عملی در مرورگر Chrome ، از پروتکل SPDY به عنوان پایه ای برای HTTP/2 استفاده شد و ویژگی های اصلی آن در HTTP/2 به ارث رسیده است. پروتکل SPDY از طریق بهینه سازی پروتکل HTTP ، مانند فشرده سازی اطلاعات هدر و چند برابر شدن ، ارائه تجربه و پایه و اساس فنی برای توسعه HTTP/2 ، بهره وری از انتقال داده ها را از طریق بهینه سازی پروتکل HTTP بهبود بخشید.

V. HTTP/2: پروتکل نسل بعدی کارآمد

در سال 2015 ، HTTP/2 منتشر شد. به آن HTTP/2.0 گفته نمی شود زیرا کمیته استاندارد قصد ندارد نسخه های فرعی را منتشر کند. نسخه جدید بعدی HTTP/3 خواهد بود. HTTP/2 در تاریخ توسعه پروتکل HTTP از اهمیت زیادی برخوردار است و یک سری پیشرفت های چشمگیر را به همراه آورده است.

5.1 پروتکل باینری

اطلاعات هدر موجود در نسخه HTTP/1.1 متن (ASCII – رمزگذاری شده) است و بدنه داده می تواند متن یا باینری باشد. با این حال ، HTTP/2 یک پروتکل کاملاً باینری است. هر دو اطلاعات هدر و بدنه داده باینری هستند و در مجموع “فریم” نامیده می شوند ، از جمله قاب های هدر و فریم های داده. مزیت پروتکل باینری این است که می توان فریم های اضافی را تعریف کرد. HTTP/2 تقریباً ده فریم را تعریف کرده است ، و پایه خوبی برای برنامه های پیشرفته آینده دارد. اگر این توابع با استفاده از متن اجرا شوند ، تجزیه داده ها بسیار مشکل ساز خواهد بود ، در حالی که تجزیه باینری بسیار راحت تر است. پروتکل باینری می تواند داده ها را با کارآمدتر انتقال و پردازش کند و عملکرد و انعطاف پذیری پروتکل را بهبود بخشد.

5.2 چند برابر کردن

HTTP/2 اتصال TCP را دوباره استفاده می کند. در یک اتصال ، هم مشتری و هم مرورگر می توانند چندین درخواست یا پاسخ را به طور همزمان ارسال کنند ، و نیازی به مطابقت با یک – به – یک به ترتیب ندارند ، بنابراین از “مسدود کردن سر – خط” جلوگیری می کنند. به عنوان مثال ، در یک اتصال TCP ، سرور درخواست A و درخواست B را همزمان دریافت می کند. بنابراین ابتدا به درخواست A. پاسخ می دهد. اگر متوجه شود که فرآیند پردازش بسیار زمان است – مصرف ، بخشی از درخواست A را که پردازش شده است ارسال می کند ، پس از اتمام به درخواست B. پاسخ دهید. پس از اتمام ، قسمت باقی مانده را ارسال می کند درخواست A. این ارتباط دو طرفه و واقعی – زمان چند برابر نامیده می شود. فناوری چند برابر HTTP/2 را قادر می سازد تا چندین درخواست و پاسخ ها را به طور همزمان در همان اتصال انجام دهند و باعث افزایش کارایی انتقال می شوند.

5.3 جریان داده

از آنجا که بسته های داده در HTTP/2 به صورت خارج از خانه ارسال می شوند ، بسته های داده متوالی در همان اتصال ممکن است متعلق به پاسخ های مختلف باشد. بنابراین ، لازم است که بسته های داده را علامت گذاری کنید تا نشان دهند که به کدام پاسخ تعلق دارند. HTTP/2 تمام بسته های داده هر درخواست را فراخوانی می کند یا به یک جریان داده پاسخ می دهد. هر جریان داده دارای یک شماره منحصر به فرد است. هنگام ارسال بسته های داده ، شناسه جریان داده باید مشخص شود تا مشخص شود که جریان داده متعلق به آن است. علاوه بر این ، تصریح شده است که جریان داده های ارسال شده توسط مشتری دارای شناسه های عجیب و غریب و شماره گذاری شده است ، و موارد ارسال شده توسط سرور دارای شناسه های شماره ای هستند. هنگامی که یک جریان داده در نیمه راه ارسال می شود ، هم مشتری و هم سرور می توانند سیگنال (فریم RST_STREAM) را برای لغو این جریان داده ارسال کنند. در نسخه HTTP/1.1 ، تنها راه لغو جریان داده بستن اتصال TCP است. با این حال ، در HTTP/2 ، می توان درخواست خاصی را لغو کرد و اطمینان حاصل کرد که اتصال TCP هنوز باز است و توسط سایر درخواست ها قابل استفاده است. مشتری همچنین می تواند اولویت جریان داده را مشخص کند. هرچه اولویت بالاتر باشد ، زودتر سرور پاسخ می دهد. از طریق مفهوم جریان داده ها و مکانیسم های مرتبط ، HTTP/2 به انتقال و مدیریت داده انعطاف پذیر و کارآمدتر می رسد.

5.4 فشرده سازی هدر

پروتکل HTTP بی تاب است و کلیه اطلاعات باید به هر درخواست وصل شود. بنابراین ، بسیاری از زمینه های درخواست تکرار می شوند ، مانند کوکی و کاربر – عامل. همان محتوا باید به هر درخواست متصل شود ، که پهنای باند زیادی را هدر می دهد و بر سرعت تأثیر می گذارد. HTTP/2 با معرفی مکانیسم فشرده سازی هدر ، این موضوع را بهینه کرده است. از یک طرف ، اطلاعات هدر قبل از ارسال با استفاده از GZIP یا کمپرس فشرده می شود. از طرف دیگر ، هر دو مشتری و سرور جدول اطلاعات هدر را حفظ می کنند. همه زمینه ها در این جدول ذخیره می شوند و یک شماره شاخص ایجاد می کنند. در آینده ، همان قسمت دوباره ارسال نمی شود ، فقط شماره شاخص ارسال می شود ، بنابراین سرعت را بهبود می بخشد. مکانیسم فشرده سازی هدر به طور موثری میزان انتقال داده ها را کاهش داده و راندمان انتقال را بهبود می بخشد.

5.5 فشار سرور

HTTP/2 به سرور اجازه می دهد تا بدون درخواست ، منابع را به طور فعال به مشتری ارسال کند ، که به آن فشار سرور گفته می شود. سناریوی مشترک زمانی است که مشتری درخواست یک صفحه وب را می دهد که حاوی منابع استاتیک بسیاری است. در شرایط عادی ، مشتری باید صفحه وب را دریافت کند ، کد منبع HTML را تجزیه کند ، منابع استاتیک را کشف کند و سپس درخواست هایی را برای منابع استاتیک ارسال کند. با این حال ، سرور می تواند پیش بینی کند که پس از درخواست مشتری از صفحه وب ، به احتمال زیاد از منابع استاتیک درخواست می کند ، بنابراین به طور فعال این منابع استاتیک را به همراه صفحه وب به مشتری ارسال می کند. فناوری فشار سرور تعداد درخواست های مشتری را کاهش داده و تجربه کاربر را بهبود می بخشد.

تاریخ توسعه پروتکل HTTP فرایندی از تکامل مداوم و بهینه سازی است. از HTTP/0.9 در ابتدا ساده تا ویژگی – Rich HTTP/1.1 و سپس به HTTP/2 کارآمد ، هر نسخه به مشکلات نسخه قبلی و عملکرد و عملکرد پیشرفته پرداخته است. با توسعه مداوم فناوری ، HTTP/3 آینده نیز ارزش آن را دارد که به دنبال آن باشید ، زیرا همچنان به پیشرفت فناوری ارتباطات اینترنتی ادامه خواهد داد.

سرانجام ، من می خواهم یک بستر مناسب برای استقرار خدمات وب را توصیه کنم: جهش

شرح تصویر