1. پیدایش در سال 1989

HTTP اولین بار توسط تیم برنرز لی (Tim Berners-Lee)، خالق شبکه جهانی وب، در سال 1989 مطرح شد. او که در مرکز پژوهش‌های هسته‌ای اروپا (CERN) مشغول به کار بود، در تلاش بود راهی برای به اشتراک‌گذاری اسناد و اطلاعات علمی بین پژوهشگران بیابد. این ایده به توسعه نخستین نسخه از پروتکل HTTP منجر شد. در ابتدا، هدف اصلی HTTP فراهم کردن بستری برای درخواست و ارسال فایل‌های ساده بود.

2. نسخه HTTP/0.9 (1991)

اولین نسخه رسمی HTTP در سال 1991 معرفی شد و به نام HTTP/0.9 شناخته می‌شود. این نسخه بسیار ساده بود و تنها از یک دستور GET پشتیبانی می‌کرد که به مرورگر اجازه می‌داد یک فایل را از سرور درخواست کند. این فایل معمولاً یک صفحه HTML ساده بود و پاسخ‌ها فقط شامل محتوای فایل درخواست‌شده بودند. در این نسخه، هیچ ساختار پیچیده‌ای برای متادیتا (اطلاعات درباره اطلاعات) وجود نداشت.

3. نسخه HTTP/1.0 (1996)

با رشد سریع وب، نیاز به یک پروتکل پیچیده‌تر احساس شد. در سال 1996، نسخه HTTP/1.0 معرفی شد که ویژگی‌های جدیدی مانند هدرها (Headers) برای انتقال اطلاعات متادیتا، وضعیت (Status Codes)، و پشتیبانی از روش‌های مختلفی همچون POST و HEAD را اضافه کرد. HTTP/1.0 اولین نسخه‌ای بود که استانداردهای اولیه اینترنت را پذیرفت.

4. نسخه HTTP/1.1 (1997)

در سال 1997، نسخه HTTP/1.1 منتشر شد که تا دهه‌ها به عنوان استاندارد اصلی وب باقی ماند. HTTP/1.1 دارای بهبودهای عمده‌ای بود که شامل موارد زیر می‌شود:

• پایدارسازی ارتباط: در HTTP/1.0، هر درخواست HTTP نیاز به یک اتصال جدید داشت. HTTP/1.1 امکان اتصال پایدار (Persistent Connections) را فراهم کرد، یعنی چندین درخواست می‌توانستند از طریق یک اتصال واحد ارسال شوند.
• پشتیبانی از کش: HTTP/1.1 مکانیزم‌های کش (Cache) بهینه‌تری را معرفی کرد که به مرورگرها و سرورها امکان ذخیره و بازیابی نسخه‌های قدیمی صفحات وب را می‌داد.
• پشتیبانی بهتر از پروکسی‌ها و آدرس‌های IP نسخه 6 (IPv6): این نسخه تغییرات و بهبودهایی در مورد نحوه ارسال درخواست‌ها از طریق پروکسی سرورها داشت.

5. نسخه HTTP/2 (2015)

نسخه HTTP/2 در سال 2015 توسط IETF (گروه مهندسی اینترنت) معرفی شد. این نسخه بهبودهای زیادی در سرعت و کارایی انتقال داده‌ها ارائه کرد، از جمله:

• مولتی‌پلکسینگ (Multiplexing): در HTTP/1.1 هر درخواست باید منتظر پاسخ می‌ماند تا درخواست بعدی ارسال شود. HTTP/2 این محدودیت را برطرف کرد و امکان ارسال همزمان چندین درخواست را فراهم نمود.
• فشرده‌سازی هدرها: هدرهای HTTP در HTTP/2 فشرده‌سازی شدند تا حجم داده‌های ارسال‌شده کاهش یابد.
• سرور پوش (Server Push): سرورها می‌توانستند منابعی که فکر می‌کردند مرورگر نیاز دارد را پیش از درخواست مرورگر ارسال کنند.

6. نسخه HTTP/3 (2020)

جدیدترین نسخه پروتکل HTTP یعنی HTTP/3 در سال 2020 معرفی شد. این نسخه از پروتکل QUIC (که بر پایه UDP است) به جای TCP برای انتقال داده‌ها استفاده می‌کند که به بهبود سرعت و امنیت ارتباطات منجر می‌شود. ویژگی‌های کلیدی HTTP/3 شامل:

• کاهش تأخیر: با استفاده از پروتکل QUIC، اتصالات سریع‌تر برقرار می‌شوند.
• امنیت پیش‌فرض: HTTP/3 به طور پیش‌فرض از رمزگذاری TLS 1.3 استفاده می‌کند.
• مولتی‌پلکسینگ بهبودیافته: ارسال همزمان چندین درخواست بهینه‌تر از نسخه‌های قبلی است.

کاربران HTTP

پروتکل HTTP در طیف گسترده‌ای از کاربرها مورد استفاده قرار می‌گیرد. برخی از مهم‌ترین کاربران HTTP شامل موارد زیر هستند:

1. مرورگرهای وب

مرورگرهای وب، مهم‌ترین و رایج‌ترین کاربران HTTP هستند. این مرورگرها مانند گوگل کروم، فایرفاکس، سافاری و مایکروسافت اج از HTTP برای دریافت و نمایش صفحات وب استفاده می‌کنند.

2. سرورها

سرورهای وب مانند آپاچی، NGINX و IIS نیز کاربران اصلی HTTP هستند. این سرورها به درخواست‌های مرورگرها پاسخ داده و محتوای مورد نیاز کاربران را ارائه می‌دهند.

3. APIها و خدمات وب

پروتکل HTTP به عنوان یک پروتکل استاندارد برای بسیاری از APIها و خدمات وب نیز استفاده می‌شود. RESTful APIها، که امروزه به عنوان یکی از رایج‌ترین روش‌های ارتباط بین سرویس‌ها شناخته می‌شوند، بر پایه HTTP بنا شده‌اند.

4. تلفن‌های هوشمند و اپلیکیشن‌ها

بسیاری از اپلیکیشن‌های موبایل و دستگاه‌های هوشمند نیز از HTTP برای ارتباط با سرورها و دریافت اطلاعات استفاده می‌کنند.

پروتکل HTTP چگونه کار می‌کند؟

پروتکل HTTP (Hypertext Transfer Protocol) یک پروتکل لایه‌ی کاربرد است که برای تبادل اطلاعات بین کلاینت (معمولاً مرورگر وب) و سرور وب طراحی شده است. HTTP یک پروتکل درخواست/پاسخ است، به این معنا که کلاینت (مثلاً مرورگر) درخواستی را به سرور ارسال می‌کند و سرور پاسخی به این درخواست می‌دهد. در این مقاله، به تفصیل نحوه کارکرد HTTP را توضیح می‌دهیم.

1. مدل درخواست-پاسخ HTTP

HTTP بر اساس مدل درخواست-پاسخ عمل می‌کند:

• کلاینت (مثلاً مرورگر) درخواست خود را به سمت سرور ارسال می‌کند.
• سرور درخواست کلاینت را پردازش کرده و یک پاسخ به کلاینت برمی‌گرداند.

هر درخواست HTTP شامل چندین مؤلفه است که به طور کامل در بخش بعدی توضیح داده خواهد شد.

2. اجزای یک درخواست HTTP

یک درخواست HTTP شامل چندین قسمت اصلی است که به سرور ارسال می‌شود:

a. خط درخواست (Request Line)

این بخش شامل اطلاعات زیر است:

• روش HTTP (HTTP Method): نوع عملیاتی که کلاینت می‌خواهد انجام دهد. برخی از رایج‌ترین روش‌های HTTP عبارت‌اند از:
  • GET: برای درخواست یک منبع (مثلاً یک صفحه وب یا یک تصویر).
  • POST: برای ارسال داده به سرور (مثلاً ارسال اطلاعات فرم).
  • PUT: برای بارگذاری (آپلود) یا به‌روزرسانی یک منبع موجود.
  • DELETE: برای حذف یک منبع.
  • HEAD: مشابه GET، اما فقط هدرهای پاسخ را دریافت می‌کند، بدون دریافت بدنه‌ی پاسخ.
• URI (Uniform Resource Identifier): آدرس منبعی که کلاینت درخواست می‌کند.
• نسخه HTTP: نسخه پروتکل HTTP که توسط کلاینت استفاده می‌شود. معمولاً نسخه‌های HTTP/1.1، HTTP/2 یا HTTP/3.

b. هدرها (Headers)

هدرهای HTTP شامل اطلاعات اضافی درباره درخواست است. برخی از هدرهای رایج در درخواست HTTP شامل:

• Host: نام دامنه یا IP سرور.
• User-Agent: اطلاعاتی درباره مرورگر یا برنامه کلاینت.
• Accept: نوع محتوایی که کلاینت قادر به پردازش آن است (مثلاً text/html برای صفحات وب).
• Content-Type: نوع داده‌های ارسال‌شده در درخواست (معمولاً در درخواست‌های POST یا PUT).

c. بدنه درخواست (Request Body)

این بخش از درخواست معمولاً در درخواست‌های POST و PUT وجود دارد و شامل داده‌هایی است که کلاینت به سرور ارسال می‌کند (مثلاً اطلاعات فرم‌ها یا فایل‌ها).

3. اجزای یک پاسخ HTTP

پس از دریافت درخواست از کلاینت، سرور پاسخ مناسبی را ارسال می‌کند. پاسخ HTTP نیز شامل بخش‌های مختلفی است:

a. خط وضعیت (Status Line)

این خط شامل سه قسمت است:

• نسخه HTTP: نسخه HTTP که سرور از آن استفاده می‌کند.
• کد وضعیت (Status Code): یک عدد سه‌رقمی که نشان‌دهنده وضعیت پاسخ است. برخی از کدهای رایج:
  • 200 OK: درخواست موفقیت‌آمیز بوده است.
  • 404 Not Found: منبع مورد نظر پیدا نشد.
  • 500 Internal Server Error: خطای داخلی سرور.
• پیام وضعیت (Status Message): توضیحی کوتاه درباره کد وضعیت.

b. هدرها (Headers)

هدرهای HTTP در پاسخ نیز مشابه درخواست شامل اطلاعاتی اضافی است. برخی از هدرهای مهم پاسخ HTTP:

• Content-Type: نوع محتوای ارسالی در بدنه پاسخ (مثلاً text/html برای صفحات وب).
• Content-Length: طول بدنه پاسخ، به بایت.
• Set-Cookie: هدرهایی که به مرورگرها می‌گویند کوکی‌های خاصی را ذخیره کنند.

c. بدنه پاسخ (Response Body)

این قسمت حاوی محتوای واقعی است که سرور به کلاینت ارسال می‌کند. این محتوا می‌تواند شامل HTML، تصاویر، فایل‌های CSS، جاوا اسکریپت یا داده‌های JSON باشد.

4. روش‌های HTTP (HTTP Methods)

پروتکل HTTP از چندین روش (Method) برای تعریف نوع عملیات که کلاینت می‌خواهد انجام دهد استفاده می‌کند. برخی از رایج‌ترین این روش‌ها عبارت‌اند از:

 GET

• رایج‌ترین روش HTTP است.
• برای درخواست دریافت یک منبع از سرور استفاده می‌شود (مثلاً یک صفحه HTML یا تصویر).
• در درخواست GET، داده‌ای در بدنه درخواست ارسال نمی‌شود.

  POST

• برای ارسال داده به سرور استفاده می‌شود.
• معمولاً برای ارسال داده‌های فرم یا آپلود فایل استفاده می‌شود.
• داده‌ها در بدنه درخواست قرار می‌گیرند.

  PUT

• برای بارگذاری یا به‌روزرسانی یک منبع استفاده می‌شود.
• در PUT، کل منبع جایگزین می‌شود، در حالی که POST برای ایجاد داده‌های جدید در سرور استفاده می‌شود.

  DELETE

• برای حذف یک منبع از سرور استفاده می‌شود.

 HEAD

• مشابه GET است، اما تنها هدرهای پاسخ را بازمی‌گرداند و بدنه‌ای ارسال نمی‌شود.
• اغلب برای بررسی وضعیت یک منبع یا اندازه محتوا استفاده می‌شود.

5. مکانیزم‌های اتصال و قطع اتصال

پروتکل HTTP به‌طور پیش‌فرض بی‌حالت (Stateless) است، به این معنی که سرور بعد از پاسخ دادن به هر درخواست، هیچ اطلاعاتی درباره وضعیت یا درخواست‌های قبلی کلاینت نگه نمی‌دارد. هر درخواست HTTP مستقل از دیگری است. برای حفظ وضعیت بین درخواست‌ها (مثلاً برای مدیریت نشست‌ها (Sessions))، از تکنیک‌هایی مانند کوکی‌ها (Cookies) و توکن‌ها (Tokens) استفاده می‌شود.

6. اتصالات پایدار (Persistent Connections)

در نسخه‌های اولیه HTTP (مانند HTTP/1.0)، بعد از هر درخواست، اتصال بین کلاینت و سرور قطع می‌شد. اما در HTTP/1.1 و نسخه‌های بعدی، از اتصالات پایدار استفاده می‌شود که به کلاینت و سرور اجازه می‌دهد چندین درخواست و پاسخ را از طریق یک اتصال واحد ارسال کنند. این کار کارایی را افزایش می‌دهد و تأخیر را کاهش می‌دهد.

7. کش (Cache)

HTTP از مکانیزم‌هایی برای کش (Cache) کردن استفاده می‌کند تا منابعی که به‌تازگی درخواست شده‌اند را ذخیره کند و برای درخواست‌های بعدی از نسخه ذخیره‌شده استفاده کند. این امر به بهبود سرعت بارگذاری صفحات وب کمک می‌کند. برخی از هدرهای مرتبط با کش عبارت‌اند از:

• Cache-Control: این هدر مدت زمانی که یک منبع باید در کش نگه داشته شود را مشخص می‌کند.
• ETag: یک تگ منحصر به فرد که تغییرات یک منبع را شناسایی می‌کند. اگر منبع تغییر نکرده باشد، از نسخه کش‌شده استفاده می‌شود.

کدهای وضعیت HTTP

کدهای وضعیت HTTP نشان‌دهنده وضعیت پاسخ یک سرور به یک درخواست است. این کدها معمولاً به پنج دسته اصلی تقسیم می‌شوند:

کدهای 1xx - اطلاع‌رسانی (Informational)

کدهایی که با 100 شروع می‌شوند، نشان‌دهنده این هستند که درخواست دریافت شده و پردازش آن ادامه دارد. این کدها معمولاً زمانی استفاده می‌شوند که سرور می‌خواهد به کلاینت اطلاع دهد که پردازش ادامه دارد، ولی هنوز پاسخ نهایی آماده نیست.

• مثال: 100 Continue یعنی سرور آماده دریافت بخش بعدی درخواست است.

کدهای 2xx - موفقیت (Success)

کدهایی که با 200 شروع می‌شوند، نشان‌دهنده این هستند که درخواست مشتری به‌درستی دریافت، درک و پردازش شده است و نتیجه موفقیت‌آمیز بوده است.

• مثال: 200 OK یعنی درخواست با موفقیت پردازش و پاسخ داده شده است.

کدهای 3xx - تغییر مسیر (Redirection)

کدهایی که با 300 شروع می‌شوند، نشان‌دهنده این هستند که برای تکمیل درخواست، نیاز به اقدام دیگری مانند تغییر مسیر است. این کدها به مشتری می‌گویند که منبع درخواست‌شده به آدرس دیگری منتقل شده یا باید به URL جدیدی هدایت شود.

• مثال: 301 Moved Permanently یعنی منبع دائماً به آدرس جدیدی منتقل شده است.

کدهای 4xx - خطای مشتری (Client Error)

کدهایی که با 400 شروع می‌شوند، نشان‌دهنده این هستند که اشتباهی در درخواست مشتری وجود دارد. این خطاها معمولاً به دلیل نادرستی یا ناقص بودن درخواست رخ می‌دهند.

• مثال: 404 Not Found یعنی منبع درخواست‌شده پیدا نشد.

کدهای 5xx - خطای سرور (Server Error)

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

• مثال: 500 Internal Server Error یعنی سرور به دلیل خطای داخلی نمی‌تواند درخواست را پردازش کند.

لیست کامل کدهای وضعیت HTTP

1xx - Informational (اطلاع‌رسانی)

• 100 Continue: سرور درخواست اولیه را دریافت کرده و مشتری می‌تواند به ارسال ادامه دهد.
• 101 Switching Protocols: سرور درخواست مشتری برای تغییر پروتکل را پذیرفته است.
• 102 Processing: سرور درخواست را دریافت کرده و در حال پردازش است، اما هنوز پاسخی ارائه نشده.
• 103 Early Hints به این معنا است که سرور در حال ارسال اطلاعات اولیه برای کمک به مرورگر است تا بتواند منابع مانند CSS و JavaScript را قبل از دریافت پاسخ کامل درخواست کند. این کد اغلب برای بهبود عملکرد بارگذاری صفحات وب استفاده می‌شود.

2xx - Success (موفقیت)

• 200 OK: درخواست با موفقیت انجام شده و پاسخ مناسب برگردانده شده است.
• 201 Created: درخواست با موفقیت انجام شده و یک منبع جدید ایجاد شده است.
• 202 Accepted: درخواست پذیرفته شده ولی هنوز پردازش نشده است.
• 203 Non-Authoritative Information: پاسخ از یک منبع دیگر گرفته شده و سرور اصلی اطلاعات را تأیید نمی‌کند.
• 204 No Content: درخواست موفقیت‌آمیز بوده ولی نیازی به ارسال محتوای جدید نیست.
• 205 Reset Content: درخواست موفقیت‌آمیز بوده و نیاز به ریست کردن محتوا در سمت مشتری وجود دارد.
• 206 Partial Content: سرور بخشی از محتوای درخواست‌شده را به دلیل محدوده مشخص‌شده ارسال کرده است.

3xx - Redirection (تغییر مسیر)

• 300 Multiple Choices: چندین گزینه برای درخواست موجود است و مشتری باید یکی را انتخاب کند.
• 301 Moved Permanently: منبع به آدرس جدیدی منتقل شده و باید از آدرس جدید استفاده شود.
• 302 Found: منبع به طور موقت به آدرس دیگری منتقل شده است.
• 303 See Other: درخواست باید از طریق آدرس دیگری پیگیری شود.
• 304 Not Modified: محتوای منبع تغییری نکرده و می‌توان از نسخه کش‌شده استفاده کرد.
• 305 Use Proxy: منبع فقط از طریق پروکسی قابل دسترسی است.
• 307 Temporary Redirect: منبع موقتاً به آدرس دیگری منتقل شده است ولی درخواست باید از روش فعلی استفاده شود.
• 308 Permanent Redirect: مشابه 301، ولی روش درخواست نباید تغییر کند.

4xx - Client Error (خطای سمت کاربر)

• 400 Bad Request: درخواست نادرست یا ناقص بوده و سرور نمی‌تواند آن را پردازش کند.
• 401 Unauthorized: درخواست نیاز به احراز هویت دارد.
• 402 Payment Required: برای استفاده از منبع، نیاز به پرداخت هزینه است (غالباً برای آینده رزرو شده است).
• 403 Forbidden: سرور درخواست را متوجه شده ولی از ارائه آن خودداری می‌کند.
• 404 Not Found: منبع درخواست‌شده پیدا نشد.
• 405 Method Not Allowed: روش استفاده‌شده برای درخواست، مجاز نیست.
• 406 Not Acceptable: محتوا با مشخصات درخواست مطابقت ندارد.
• 407 Proxy Authentication Required: مشتری باید از طریق پروکسی احراز هویت شود.
• 408 Request Timeout: درخواست مشتری در زمان مشخص به سرور نرسیده است.
• 409 Conflict: تضادی در درخواست وجود دارد، مانند تداخل منابع.
• 410 Gone: منبع دیگر در دسترس نیست و حذف شده است.
• 411 Length Required: درخواست باید حاوی طول مشخص‌شده باشد.
• 412 Precondition Failed: یکی از شروط قبلی درخواست نقض شده است.
• 413 Payload Too Large: درخواست خیلی بزرگ است و سرور نمی‌تواند آن را پردازش کند.
• 414 URI Too Long: آدرس درخواست‌شده خیلی طولانی است و سرور نمی‌تواند آن را پردازش کند.
• 415 Unsupported Media Type: فرمت درخواست‌شده پشتیبانی نمی‌شود.
• 416 Range Not Satisfiable: محدوده درخواست‌شده معتبر نیست.
• 417 Expectation Failed: یکی از انتظارات درخواست برآورده نشده است.
• 418 I'm a Teapot: این کد برای طنز است و به معنای عدم توانایی سرور برای تهیه قهوه است.
• 421 Misdirected Request: درخواست به سرور اشتباهی هدایت شده است.
• 422 Unprocessable Entity: سرور نمی‌تواند درخواست را به دلیل اشتباهات معنایی پردازش کند.
• 423 Locked: منبع قفل شده است و دسترسی به آن امکان‌پذیر نیست.
• 424 Failed Dependency: یکی از وابستگی‌های درخواست شکست خورده است.
• 425 Too Early: درخواست خیلی زود ارسال شده است و ممکن است مشکلاتی را به وجود بیاورد.
• 426 Upgrade Required: مشتری باید پروتکل خود را به نسخه جدیدتر ارتقاء دهد.
• 428 Precondition Required: درخواست باید شامل شرایط قبلی باشد.
• 429 Too Many Requests: مشتری درخواست‌های زیادی در زمان کوتاهی ارسال کرده است.
• 431 Request Header Fields Too Large: فیلدهای سرصفحه درخواست خیلی بزرگ هستند.
• 451 Unavailable For Legal Reasons: منبع به دلایل قانونی در دسترس نیست.

5xx - Server Error (خطای سمت سرور)

• 500 Internal Server Error: سرور دچار خطای داخلی شده و نمی‌تواند درخواست را پردازش کند.
• 501 Not Implemented: سرور توانایی پردازش روش درخواست‌شده را ندارد.
• 502 Bad Gateway: سرور به عنوان یک درگاه، پاسخ نامعتبری از سرور دیگر دریافت کرده است.
• 503 Service Unavailable: سرویس موقتاً در دسترس نیست.
• 504 Gateway Timeout: سرور به عنوان یک درگاه، پاسخی از سرور دیگر در زمان مشخص دریافت نکرده است.
• 505 HTTP Version Not Supported: نسخه پروتکل HTTP پشتیبانی نمی‌شود.
• 506 Variant Also Negotiates: سرور نتوانسته است یک انتخاب مناسب از محتوا انجام دهد.
• 507 Insufficient Storage: سرور فضای کافی برای ذخیره‌سازی ندارد.
• 508 Loop Detected: سرور یک حلقه بی‌پایان در درخواست پیدا کرده است.
• 510 Not Extended: درخواست نیاز به گسترش دارد تا پردازش شود.
• 511 Network Authentication Required: مشتری باید احراز هویت شبکه‌ای را انجام دهد.

آیا پروتکل HTTP  ایمن است ؟

پروتکل HTTP به خودی خود امن نیست. در واقع، یکی از نقاط ضعف اصلی HTTP این است که داده‌ها را به صورت متن ساده (Plain Text) انتقال می‌دهد. این بدان معناست که اگر داده‌ها در مسیر بین کلاینت (کاربر) و سرور توسط شخص ثالثی (مانند یک هکر) رهگیری شوند، آن فرد می‌تواند به راحتی محتوای این داده‌ها را مشاهده کند. این مشکل خصوصاً در مواردی که اطلاعات حساس مثل رمزهای عبور، اطلاعات کارت اعتباری یا داده‌های شخصی منتقل می‌شوند، نگران‌کننده است.

برای رفع این مشکل، پروتکل HTTPS (Hypertext Transfer Protocol Secure) معرفی شده است که نسخه امن پروتکل HTTP به شمار می‌رود. HTTPS از پروتکل SSL/TLS برای رمزگذاری داده‌های ارسال‌شده استفاده می‌کند، به طوری که حتی اگر داده‌ها در مسیر انتقال توسط هکرها رهگیری شوند، به دلیل رمزنگاری‌شده بودن، قابل خواندن نخواهند بود. توجه داشته باشید اگر  HTTPS در دسترس نبود برای ایمنی خود از  VPN امن برای ارتباط HTTP خود استفاده کنید.

تفاوت‌های HTTP و HTTPS

1. رمزنگاری

HTTP به‌طور پیش‌فرض داده‌ها را بدون رمزگذاری ارسال می‌کند، در حالی که HTTPS با استفاده از TLS (Transport Layer Security) یا SSL (Secure Sockets Layer) داده‌ها را رمزگذاری می‌کند. این رمزنگاری از مشاهده و دسترسی غیرمجاز به داده‌ها جلوگیری می‌کند.

2. گواهی‌های SSL/TLS

برای استفاده از HTTPS، وب‌سایت‌ها نیاز به گواهی SSL یا TLS دارند که از سوی یک مرجع صدور گواهی (CA - Certificate Authority) صادر می‌شود. این گواهی‌ها تضمین می‌کنند که ارتباطات بین کاربر و سرور امن است و اعتبار وب‌سایت نیز تأیید شده است.

3. تأیید هویت

HTTPS از مکانیسم‌هایی استفاده می‌کند که هویت سرور را تأیید کرده و اطمینان می‌دهد که کاربر واقعاً به سرور صحیح متصل شده است. این امر از حملاتی مانند حمله مرد میانی (Man-in-the-Middle) جلوگیری می‌کند.

4. یکپارچگی داده‌ها

در HTTPS، علاوه بر رمزنگاری، تضمین می‌شود که داده‌ها در مسیر انتقال تغییر نکرده‌اند. اگر داده‌ها در حین انتقال تغییر کنند، اتصال شکسته می‌شود و خطا رخ می‌دهد.