HTTP/HTTPS: یہ کیا ہے، ڈیٹا منتقلی پروٹوکول اور TLS خفیہ کاری

HTTP اور HTTPS کیا ہیں؟

HTTP (HyperText Transfer Protocol) OSI ماڈل کی ایک ایپلیکیشن پرت پروٹوکول ہے جو ورلڈ وائڈ ویب پر ہائپر ٹیکسٹ دستاویزات اور دیگر ڈیٹا کی منتقلی کے لیے ڈیزائن کیا گیا ہے۔ ٹم برنرز لی نے 1989 میں تیار کیا، HTTP کئی ورژن سے گزرا ہے: 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 ایک اسٹیٹ لیس پروٹوکول ہے جو TCP/IP پر کام کرتا ہے۔ کلائنٹ سرور کے ساتھ TCP کنکشن قائم کرتا ہے (عام طور پر HTTP کے لیے پورٹ 80 یا HTTPS کے لیے 443)، HTTP درخواست بھیجتا ہے، HTTP جواب وصول کرتا ہے اور کنکشن بند کرتا ہے (HTTP/1.1 میں کنکشن دوبارہ استعمال کیا جا سکتا ہے)۔ کلائنٹ اور سرور کے درمیان ہر تعامل ایک درخواست اور جواب پر مشتمل ہوتا ہے۔ اسٹیٹ لیس ہونے کا مطلب ہے کہ سرور پچھلی کلائنٹ درخواستوں کے بارے میں معلومات ذخیرہ نہیں کرتا — ہر درخواست آزادانہ طور پر پروسیس کی جاتی ہے۔

HTTP تعامل کے عمل میں درج ذیل مراحل شامل ہیں:

• DNS حل — براؤزر یا کلائنٹ DNS کے ذریعے ڈومین نام کو IP پتے میں تبدیل کرتا ہے
• TCP مصافحہ — تین طرفہ مصافحہ (SYN, SYN-ACK, ACK) کے ذریعے TCP کنکشن قائم ہوتا ہے
• TLS مصافحہ — HTTPS کے لیے، اضافی طور پر خفیہ کردہ کنکشن قائم ہوتا ہے (سرٹیفکیٹ اور کلید کا تبادلہ)
• HTTP درخواست — کلائنٹ طریقہ، URL، ہیڈر اور اختیاری طور پر درخواست کا باڈی بھیجتا ہے
• HTTP جواب — سرور اسٹیٹس کوڈ، ہیڈر اور جواب کا باڈی واپس کرتا ہے

HTTP کی ایک اہم خصوصیت طریقہ کی idempotency ہے۔ GET, HEAD, PUT, DELETE اور OPTIONS idempotent ہیں: ایک ہی درخواست کو بار بار انجام دینے سے پہلی انجام دہی کے بعد سرور کی حالت تبدیل نہیں ہوتی۔ POST, PATCH اور CONNECT idempotent نہیں ہیں — ہر کال نیا وسائل بنا سکتی ہے یا حالت تبدیل کر سکتی ہے۔ موبائل ڈویلپمنٹ کے لیے، idempotency کو سمجھنا بہت ضروری ہے: نیٹ ورک کی غلطی کی وجہ سے درخواست دوبارہ بھیجتے وقت، کلائنٹ کو معلوم ہونا چاہیے کہ درخواست کو دہرانا محفوظ ہے یا نہیں۔

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 راؤنڈ ٹرپ سے کم کرکے 1 کر دیتا ہے، جو موبائل آلات پر لوڈنگ کو نمایاں طور پر تیز کرتا ہے۔

TLS مصافحہ کے عمل میں درج ذیل مراحل شامل ہیں:

• Client Hello — کلائنٹ معاون TLS ورژن اور سائفر سویٹس کی فہرست بھیجتا ہے
• Server Hello — سرور TLS ورژن اور سائفر سویٹ منتخب کرتا ہے، اپنا SSL/TLS سرٹیفکیٹ بھیجتا ہے
• سرٹیفکیٹ کی تصدیق — کلائنٹ روٹ CA تک اعتماد کی زنجیر کے ذریعے سرور کے سرٹیفکیٹ کی تصدیق کرتا ہے
• کلید کا تبادلہ — کلائنٹ اور سرور مشترکہ خفیہ کلید (سیشن کلید) بناتے ہیں
• سائفر سوئچ — دونوں فریق خفیہ کردہ مواصلات پر سوئچ کرنے کی تصدیق کرتے ہیں

SSL/TLS سرٹیفکیٹ کی تصدیق سیکیورٹی کے لیے ایک اہم مرحلہ ہے۔ کلائنٹ چیک کرتا ہے کہ سرٹیفکیٹ: ختم نہیں ہوا، قابل اعتماد سرٹیفکیٹ اتھارٹی (CA) کے ذریعے دستخط شدہ ہے، URL میں ڈومین سے مطابقت رکھتا ہے، اور منسوخ نہیں کیا گیا (CRL یا OCSP کے ذریعے)۔ موبائل ایپلیکیشنز میں، سرٹیفکیٹ پننگ (Certificate Pinning) استعمال کرنے کی سفارش کی جاتی ہے — کسی مخصوص سرور سرٹیفکیٹ یا عوامی کلید سے بائنڈ کرنا۔ یہ CA سے سمجھوتہ ہونے کی صورت میں بھی MITM حملوں کو روکتا ہے۔ تاہم، پننگ میں احتیاط کی ضرورت ہے: جب سرٹیفکیٹ تبدیل ہوتا ہے تو ایپلیکیشن کو پہلے سے اپ ڈیٹ کرنا ضروری ہے۔

HTTP درخواست اور جواب کی ساخت

ایک HTTP درخواست تین حصوں پر مشتمل ہوتی ہے: درخواست کی لائن، ہیڈر، اور ایک اختیاری باڈی۔ درخواست کی لائن میں HTTP طریقہ، درخواست کا URL، اور HTTP ورژن ہوتا ہے۔ ہیڈر میٹا معلومات منتقل کرتے ہیں: مواد کی قسم، تصدیقی ٹوکن، کیشے کی ترتیبات۔ باڈی صرف ان طریقوں میں موجود ہوتا ہے جو ڈیٹا منتقل کرتے ہیں (POST, PUT, PATCH) اور GET اور DELETE میں غائب ہوتا ہے۔

REST API کو HTTP درخواست کی مثال:

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 میں متعین کردہ فارمیٹ (عام طور پر API کے لیے JSON، ویب صفحات کے لیے 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 کوڈ کو ہینڈل کرنا خاص طور پر اہم ہے۔ یہ کوڈ موصول ہونے پر، کلائنٹ کو ریفریش ٹوکن کے ذریعے رسائی ٹوکن ریفریش کرنے اور اصل درخواست دہرانے کی کوشش کرنی چاہیے۔ اگر ٹوکن ریفریش بھی 401 لوٹاتا ہے، تو صارف کو لاگ ان اسکرین پر ری ڈائریکٹ کیا جانا چاہیے۔ یہ منطق عام طور پر انٹرسیپٹر (OkHttp) یا نیٹ ورک کلائنٹ کی مڈل ویئر پرت میں لاگو کی جاتی ہے۔

HTTP/1.1, HTTP/2 اور HTTP/3

HTTP/1.1، 1999 میں شائع ہوا، اب بھی پروٹوکول کا وسیع پیمانے پر استعمال ہونے والا ورژن ہے۔ اس کی اہم خامی ہیڈ آف لائن بلاکنگ ہے: ایک ہی سرور کو درخواستیں ترتیب وار انجام دی جاتی ہیں، ہر ایک پچھلی کے مکمل ہونے کا انتظار کرتی ہے۔ اس حد سے بچنے کے لیے، براؤزر ایک ہی ڈومین پر 6-8 متوازی TCP کنکشن کھولتے ہیں، جس سے سرور کا بوجھ اور میموری کی کھپت بڑھ جاتی ہے۔ HTTP/1.1 ہیڈر کو سادہ متن میں بھی منتقل کرتا ہے اور سرور پش کو سپورٹ نہیں کرتا۔

HTTP/2 (2015) ملٹی پلیکسنگ کے ذریعے بلاکنگ کے مسئلے کو حل کرتا ہے — متعدد ڈیٹا اسٹریمز ایک ہی TCP کنکشن پر بیک وقت منتقل ہوتے ہیں۔ سرور کلائنٹ کی درخواست کرنے سے پہلے وسائل بھیج سکتا ہے (سرور پش)۔ HTTP/2 HPACK کے ذریعے ہیڈر کو بھی کمپریس کرتا ہے، جو منتقل کردہ ڈیٹا کی مقدار کو کم کرتا ہے۔ موبائل ایپلیکیشنز کے لیے، HTTP/2 خاص طور پر مفید ہے: ایک کنکشن کئی کنکشنز کی جگہ لے لیتا ہے، TLS مصافحہ کا وقت اور بیٹری کی کھپت کم کرتا ہے۔

HTTP/3 (2022) پروٹوکول کا تازہ ترین ورژن ہے، جو TCP کی بجائے QUIC (Quick UDP Internet Connections) استعمال کرتا ہے۔ QUIC UDP پر کام کرتا ہے، ٹرانسپورٹ پروٹوکول کی سطح پر ہیڈ آف لائن بلاکنگ کے مسئلے کو ختم کرتا ہے۔ HTTP/3 کنکشن قائم کرنے کے وقت کو بہترین صورت میں 0 راؤنڈ ٹرپ (دوبارہ کنکشن پر) اور پہلے کنکشن پر 1 راؤنڈ ٹرپ تک کم کر دیتا ہے، جو 2-3 راؤنڈ ٹرپ والے HTTP/2 سے نمایاں طور پر تیز ہے۔ موبائل آلات کے لیے، 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 پر حساس ڈیٹا منتقل کرنے والی ایپلیکیشنز کو مسترد کرتے ہیں، جس میں پاس ورڈ، ٹوکن اور ذاتی ڈیٹا شامل ہیں۔

Android موبائل ایپلیکیشن میں HTTPS کنفیگریشن میں شامل ہے:

<!-- 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 پر، اسی طرح کی کنفیگریشن NSAppTransportSecurity کلید کے ساتھ Info.plist کے ذریعے کی جاتی ہے۔ موبائل ایپلیکیشنز میں HTTPS ٹریفک کو ڈیبگ کرنے کے لیے پراکسی ٹولز استعمال کیے جاتے ہیں: Charles Proxy, Proxyman یا mitmproxy۔ ان کے لیے ڈیوائس پر قابل اعتماد SSL سرٹیفکیٹ انسٹال کرنا ضروری ہے۔ پروڈکشن بلڈز میں، ڈیبگنگ کی صلاحیتوں کو غیر فعال کرنا چاہیے اور سرٹیفکیٹ پننگ کی تصدیق کرنی چاہیے کہ یہ درست طریقے سے کنفیگر ہے۔ Android پر اس کے CertificatePinner کے ساتھ OkHttp یا iOS پر SecTrustEvaluate کے ساتھ TrustManager کا استعمال پننگ کو لاگو کرنے کے معیاری طریقے ہیں۔

موبائل ڈویلپمنٹ میں HTTPS کا ایک اہم سیکیورٹی پہلو SSL پننگ ہے۔ پننگ کے بغیر، ایپلیکیشن کسی بھی معروف CA کے دستخط شدہ سرٹیفکیٹ پر بھروسہ کرتی ہے۔ اگر CA سے سمجھوتہ ہو جائے تو حملہ آور ایپلیکیشن کے ٹریفک کو روک سکتا ہے۔ پننگ ایپلیکیشن کو کسی مخصوص سرور سرٹیفکیٹ یا عوامی کلید سے باندھتی ہے۔ جب سرور سرٹیفکیٹ تبدیل ہوتا ہے، تو ایپلیکیشن اپ ڈیٹ جاری کرنا ضروری ہوتا ہے، لہٰذا پننگ مارجن کے ساتھ منصوبہ بندی کی جاتی ہے — اوپر والے CA سرٹیفکیٹ سے بائنڈنگ یا متعدد بیک اپ کلیدوں کا استعمال۔