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 সার্টিফিকেটে বাঁধাই বা একাধিক ব্যাকআপ কী ব্যবহার করা।