HTTP/HTTPS: چیست، پروتکل‌های انتقال داده و رمزنگاری TLS

HTTP و HTTPS چیست؟

HTTP (HyperText Transfer Protocol) — پروتکل لایه کاربردی مدل OSI است که برای انتقال اسناد ابرمتنی و سایر داده‌ها در وب جهانی طراحی شده است. HTTP که توسط تیم برنرز-لی در سال 1989 توسعه یافت، چندین نسخه را پشت سر گذاشته است: از HTTP/0.9 (فقط درخواست‌های GET و پاسخ‌های HTML) تا HTTP/2 و HTTP/3 مدرن. پروتکل بر اساس طرح درخواست-پاسخ کار می‌کند: کلاینت درخواستی به سرور ارسال می‌کند، سرور آن را پردازش کرده و پاسخ را برمی‌گرداند.

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

تفاوت کلیدی بین HTTP و HTTPS امنیت است. HTTP داده‌ها را به صورت متن باز منتقل می‌کند: هر گره شبکه بین کلاینت و سرور می‌تواند محتوای درخواست یا پاسخ را بخواند. HTTPS تمام محتوا از جمله URL، هدرها و بدنه درخواست را رمزنگاری می‌کند و فقط آدرس IP سرور و پورت اتصال را قابل مشاهده می‌گذارد. برای برنامه‌های موبایل که از طریق شبکه‌های Wi-Fi عمومی کار می‌کنند، HTTPS یک الزام امنیتی اجباری است.

HTTP چگونه کار می‌کند

HTTP — پروتکل بدون حالت (stateless) است که روی TCP/IP کار می‌کند. کلاینت یک اتصال TCP با سرور برقرار می‌کند (معمولاً روی پورت 80 برای HTTP یا 443 برای HTTPS)، درخواست HTTP ارسال می‌کند، پاسخ HTTP دریافت می‌کند و اتصال را می‌بندد (در HTTP/1.1 اتصال می‌تواند دوباره استفاده شود). هر تعامل بین کلاینت و سرور شامل یک درخواست و پاسخ است. بدون حالت بودن به این معنی است که سرور اطلاعاتی درباره درخواست‌های قبلی کلاینت ذخیره نمی‌کند — هر درخواست به طور مستقل پردازش می‌شود.

فرآیند تعامل HTTP شامل مراحل زیر است:

• حل DNS — مرورگر یا کلاینت نام دامنه را از طریق DNS به آدرس IP تبدیل می‌کند
• دست دادن TCP — اتصال TCP از طریق دست دادن سه مرحله‌ای (SYN، SYN-ACK، ACK) برقرار می‌شود
• دست دادن TLS — برای HTTPS یک اتصال رمزنگاری شده اضافی برقرار می‌شود (تبادل گواهی‌ها و کلیدها)
• درخواست HTTP — کلاینت متد، URL، هدرها و به صورت اختیاری بدنه درخواست را ارسال می‌کند
• پاسخ HTTP — سرور کد وضعیت، هدرها و بدنه پاسخ را برمی‌گرداند

یک ویژگی مهم HTTP idempotent بودن متدها است. GET، HEAD، PUT، DELETE و OPTIONS idempotent هستند: اجرای مکرر همان درخواست وضعیت سرور را پس از اولین اجرا تغییر نمی‌دهد. POST، PATCH و CONNECT idempotent نیستند — هر فراخوانی می‌تواند منبع جدیدی ایجاد کند یا وضعیت را تغییر دهد. برای توسعه موبایل درک idempotent بودن حیاتی است: هنگام ارسال مجدد درخواست به دلیل خطای شبکه، کلاینت باید بداند که آیا تکرار درخواست ایمن است یا خیر.

HTTPS و رمزنگاری TLS

HTTPS از پروتکل رمزنگاری TLS (Transport Layer Security) برای محافظت از داده‌های ارسالی استفاده می‌کند. TLS — جانشین SSL (Secure Sockets Layer) است که توسط شرکت Netscape در سال 1995 توسعه یافت. نسخه‌های SSL 2.0 و 3.0 قدیمی و ناامن محسوب می‌شوند؛ نسخه‌های مدرن TLS 1.2 (منتشر شده در 2008) و TLS 1.3 (منتشر شده در 2018) به طور گسترده استفاده می‌شوند. TLS 1.3 به ویژه زمان برقراری اتصال را از 2 round-trips به 1 کاهش می‌دهد که بارگذاری را در دستگاه‌های موبایل به طور قابل توجهی سرعت می‌بخشد.

فرآیند دست دادن TLS (handshake) شامل مراحل زیر است:

• Client Hello — کلاینت لیست نسخه‌های TLS و مجموعه رمزهای پشتیبانی شده را ارسال می‌کند
• Server Hello — سرور نسخه TLS و مجموعه رمز را انتخاب می‌کند، گواهی SSL/TLS خود را ارسال می‌کند
• بررسی گواهی — کلاینت گواهی سرور را از طریق زنجیره اعتماد تا CA ریشه بررسی می‌کند
• تبادل کلید — کلاینت و سرور یک کلید مخفی مشترک (کلید جلسه) تولید می‌کنند
• Switch Cipher — هر دو طرف انتقال به اتصال رمزنگاری شده را تأیید می‌کنند

بررسی گواهی SSL/TLS — مرحله حیاتی برای امنیت است. کلاینت بررسی می‌کند که گواهی: منقضی نشده باشد، توسط مرکز صدور گواهی معتبر (CA) امضا شده باشد، با دامنه در URL مطابقت داشته باشد و لغو نشده باشد (از طریق CRL یا OCSP). در برنامه‌های موبایل توصیه می‌شود از Certificate Pinning — اتصال به گواهی خاص یا کلید عمومی سرور استفاده کنید. این کار از حملات MITM حتی در صورت به خطر افتادن CA جلوگیری می‌کند. با این حال pinning نیاز به احتیاط دارد: هنگام تغییر گواهی، برنامه باید از قبل به‌روزرسانی شود.

ساختار درخواست و پاسخ HTTP

درخواست HTTP از سه بخش تشکیل شده است: خط شروع (request line)، هدرها (headers) و بدنه اختیاری (body). خط شروع شامل متد HTTP، URL درخواست و نسخه HTTP است. هدرها ابرداده را منتقل می‌کنند: نوع محتوا، توکن‌های احراز هویت، تنظیمات کش. بدنه فقط در متدهایی که داده ارسال می‌کنند (POST، PUT، PATCH) وجود دارد و در GET و DELETE وجود ندارد.

مثال درخواست HTTP به REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "آنا",
    "email": "anna@example.com"
}

پاسخ HTTP ساختار مشابهی دارد: خط شروع با نسخه HTTP و کد وضعیت، هدرها و بدنه. کد وضعیت — عددی سه رقمی که نتیجه پردازش درخواست را تعیین می‌کند. هدرهای پاسخ شامل Content-Type، Content-Length، Cache-Control، Set-Cookie و موارد دیگر هستند. بدنه پاسخ شامل داده‌های درخواست شده در قالبی است که در Content-Type مشخص شده (معمولاً JSON برای API، HTML برای صفحات وب، تصاویر برای محتوای رسانه‌ای).

هدرها نقش حیاتی در کار HTTP دارند. Content-Type و Accept فرمت داده را مدیریت می‌کنند. Authorization توکن‌های دسترسی را منتقل می‌کند. Cache-Control کش را مدیریت می‌کند. هدرهای CORS (Access-Control-Allow-Origin) دسترسی از دامنه‌های دیگر را در مرورگرها کنترل می‌کنند. User-Agent برنامه کلاینت را شناسایی می‌کند. برای برنامه‌های موبایل هدرهای مدیریت کش اهمیت ویژه‌ای دارند — آنها به کاهش حجم داده‌های منتقل شده و بهبود عملکرد در سیگنال ضعیف کمک می‌کنند.

کدهای وضعیت HTTP

کدهای وضعیت HTTP به پنج کلاس تقسیم می‌شوند که با رقم اول مشخص می‌شوند: 1xx (اطلاعاتی)، 2xx (موفقیت)، 3xx (تغییر مسیر)، 4xx (خطای کلاینت)، 5xx (خطای سرور). درک این کدها برای پردازش صحیح پاسخ‌ها در برنامه موبایل ضروری است: 2xx به معنای موفقیت است و داده‌ها قابل نمایش هستند، 4xx نشان‌دهنده مشکل در درخواست است (باید خطا به کاربر نشان داده شود)، 5xx — مشکل در سرور است (باید درخواست بعداً تکرار شود).

برای برنامه‌های موبایل مدیریت کد 401 Unauthorized اهمیت ویژه‌ای دارد. پس از دریافت این کد، کلاینت باید سعی کند توکن دسترسی را از طریق Refresh Token به‌روز کند و درخواست اصلی را تکرار کند. اگر به‌روزرسانی توکن نیز 401 برگرداند، کاربر باید به صفحه ورود هدایت شود. این منطق معمولاً در Interceptor (OkHttp) یا لایه middleware کلاینت شبکه پیاده‌سازی می‌شود.

HTTP/1.1، HTTP/2 و HTTP/3

HTTP/1.1، منتشر شده در سال 1999، هنوز هم نسخه پرکاربرد پروتکل است. عیب اصلی آن — head-of-line blocking: درخواست‌ها به یک سرور به صورت ترتیبی انجام می‌شوند، هر کدام منتظر اتمام قبلی است. برای دور زدن این محدودیت، مرورگرها 6–8 اتصال TCP موازی به یک دامنه باز می‌کنند که بار سرور و مصرف حافظه را افزایش می‌دهد. HTTP/1.1 همچنین هدرها را به صورت رمزنگاری نشده منتقل می‌کند و از server push پشتیبانی نمی‌کند.

HTTP/2 (2015) مشکل مسدودسازی را از طریق مالتی‌پلکسینگ حل می‌کند — چندین جریان داده به طور هم‌زمان از طریق یک اتصال TCP منتقل می‌شوند. سرور می‌تواند منابع را قبل از درخواست کلاینت ارسال کند (server push). HTTP/2 همچنین هدرها را از طریق HPACK فشرده می‌کند که حجم داده‌های منتقل شده را کاهش می‌دهد. برای برنامه‌های موبایل HTTP/2 بسیار مفید است: یک اتصال جایگزین چندین اتصال می‌شود و زمان دست دادن TLS و مصرف باتری را کاهش می‌دهد.

HTTP/3 (2022) — آخرین نسخه پروتکل است که به جای TCP از QUIC (Quick UDP Internet Connections) استفاده می‌کند. QUIC روی UDP کار می‌کند و مشکل head-of-line blocking را در سطح پروتکل حمل و نقل از بین می‌برد. HTTP/3 زمان برقراری اتصال را در بهترین حالت به 0 round-trips (در اتصالات مجدد) و در اولین اتصال به 1 round-trip کاهش می‌دهد که بسیار سریع‌تر از HTTP/2 با 2–3 round-trips است. برای دستگاه‌های موبایل HTTP/3 هنگام جابجایی بین Wi-Fi و شبکه همراه بسیار مؤثر است – اتصال قطع نمی‌شود زیرا QUIC از شناسه اتصال به جای آدرس IP استفاده می‌کند.

HTTPS در توسعه موبایل

استفاده از HTTPS در برنامه‌های موبایل — یک توصیه نیست، بلکه الزامی اجباری است. از Android 9 (API 28) و iOS 9 (ATS — App Transport Security) به بعد، تمام درخواست‌های شبکه به طور پیش‌فرض باید از HTTPS استفاده کنند. درخواست‌های HTTP توسط سیستم مسدود می‌شوند و برای مجاز کردن آنها نیاز به استثنای صریح در تنظیمات برنامه است. Google Play Store و App Store برنامه‌هایی را که داده‌های محرمانه از جمله رمز عبور، توکن‌ها و اطلاعات شخصی را از طریق HTTP منتقل می‌کنند، رد می‌کنند.

تنظیمات HTTPS در برنامه موبایل در Android شامل موارد زیر است:

<!-- AndroidManifest.xml — مجوز درخواست‌های شبکه -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — پیکربندی HTTPS -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

در iOS تنظیمات مشابه از طریق Info.plist با کلید NSAppTransportSecurity انجام می‌شود. برای اشکال‌زدایی ترافیک HTTPS در برنامه‌های موبایل از ابزارهای پروکسی استفاده می‌شود: Charles Proxy، Proxyman یا mitmproxy. آنها نیاز به نصب گواهی SSL معتبر روی دستگاه دارند. در بیلدهای تولیدی باید امکان اشکال‌زدایی غیرفعال شود و Certificate Pinning به درستی پیکربندی شده باشد. استفاده از OkHttp در Android با CertificatePinner یا TrustManager در iOS با SecTrustEvaluate — رویکردهای استاندارد برای پیاده‌سازی pinning هستند.

یک جنبه مهم امنیت HTTPS در توسعه موبایل — SSL Pinning است. بدون pinning برنامه به هر گواهی امضا شده توسط CA شناخته شده اعتماد می‌کند. اگر CA به خطر بیفتد، مهاجم می‌تواند ترافیک برنامه را رهگیری کند. Pinning برنامه را به گواهی خاص یا کلید عمومی سرور متصل می‌کند. هنگام تغییر گواهی در سرور باید به‌روزرسانی برنامه منتشر شود، بنابراین pinning با احتیاط برنامه‌ریزی می‌شود — به گواهی CA بالادست متصل می‌شوند یا از چندین کلید یدکی استفاده می‌کنند.