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 की एक महत्वपूर्ण विशेषता विधि आइडेम्पोटेंसी है। GET, HEAD, PUT, DELETE और OPTIONS आइडेम्पोटेंट हैं: एक ही अनुरोध को बार-बार निष्पादित करने से पहले निष्पादन के बाद सर्वर की स्थिति नहीं बदलती। POST, PATCH और CONNECT आइडेम्पोटेंट नहीं हैं — प्रत्येक कॉल नया संसाधन बना सकता है या स्थिति बदल सकता है। मोबाइल डेवलपमेंट के लिए, आइडेम्पोटेंसी को समझना महत्वपूर्ण है: नेटवर्क त्रुटि के कारण अनुरोध पुनः भेजते समय, क्लाइंट को पता होना चाहिए कि अनुरोध को दोहराना सुरक्षित है या नहीं।

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 हमलों को रोकता है। हालाँकि, pinning में सावधानी आवश्यक है: जब प्रमाणपत्र बदलता है, तो एप्लिकेशन को पहले से अपडेट किया जाना चाहिए।

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 कोड को संभालना विशेष रूप से महत्वपूर्ण है। यह कोड प्राप्त करने पर, क्लाइंट को Refresh Token के माध्यम से एक्सेस टोकन को ताज़ा करने और मूल अनुरोध को पुनः प्रयास करने का प्रयास करना चाहिए। यदि टोकन ताज़ा करने पर भी 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 प्रमाणपत्र स्थापित करने की आवश्यकता होती है। प्रोडक्शन बिल्ड में, डीबगिंग क्षमताओं को अक्षम किया जाना चाहिए और Certificate Pinning के सही ढंग से कॉन्फ़िगर होने की पुष्टि की जानी चाहिए। Android पर इसके CertificatePinner के साथ OkHttp या iOS पर SecTrustEvaluate के साथ TrustManager का उपयोग करना pinning को कार्यान्वित करने के मानक दृष्टिकोण हैं।

मोबाइल डेवलपमेंट में HTTPS का एक महत्वपूर्ण सुरक्षा पहलू SSL Pinning है। Pinning के बिना, एप्लिकेशन किसी भी ज्ञात CA द्वारा हस्ताक्षरित प्रमाणपत्र पर भरोसा करता है। यदि CA से समझौता किया जाता है, तो एक हमलावर एप्लिकेशन के ट्रैफ़िक को इंटरसेप्ट कर सकता है। Pinning एप्लिकेशन को किसी विशिष्ट सर्वर प्रमाणपत्र या सार्वजनिक कुंजी से बांधता है। जब सर्वर प्रमाणपत्र बदलता है, तो एप्लिकेशन अपडेट जारी किया जाना चाहिए, इसलिए pinning की योजना मार्जिन के साथ बनाई जाती है — अपस्ट्रीम CA प्रमाणपत्र से बंधन या कई बैकअप कुंजियों का उपयोग करना।