OkHttp — এটি কী, বৈশিষ্ট্য এবং HTTP ক্লায়েন্টের আর্কিটেকচার

OkHttp কী?

OkHttp হল Java, Android এবং Kotlin-এর জন্য একটি দক্ষ HTTP ক্লায়েন্ট, যা Square কোম্পানি তৈরি করেছে। লাইব্রেরিটি HTTP/2, SPDY, WebSocket এবং নেটওয়ার্ক ব্যর্থতায় স্বয়ংক্রিয় সংযোগ পুনরুদ্ধারের সমর্থন সহ HTTP অনুরোধ সম্পাদনের জন্য নিম্ন-স্তরের API প্রদান করে।

OkHttp 2013 সালে একটি নির্ভরযোগ্য HTTP ক্লায়েন্টের প্রয়োজনীয়তার প্রতিক্রিয়া হিসেবে আবির্ভূত হয় যা HttpURLConnection-এর সমস্যাগুলি সমাধান করত — কানেকশন পুলের অভাব, দুর্বল HTTP/2 সমর্থন এবং অসুবিধাজনক API। 2025 সালের মধ্যে, OkHttp Android API সিস্টেম স্তরে ব্যবহৃত হয়: Android 4.4 (API 19) থেকে OkHttp HttpURLConnection বাস্তবায়নে এম্বেড করা হয়েছে।

Google I/O 2024-এর তথ্য অনুসারে, OkHttp Android ইকোসিস্টেমে সমস্ত HTTP অনুরোধের 70% এর বেশি প্রক্রিয়া করে। এটি সম্ভব কারণ OkHttp Retrofit, Apollo GraphQL, Firebase এবং আরও অনেক লাইব্রেরির জন্য ট্রান্সপোর্ট লেয়ার হিসেবে কাজ করে। ডেভেলপাররা স্পষ্টভাবে এটি যুক্ত না করেই স্বয়ংক্রিয়ভাবে OkHttp কার্যকারিতা পান।

OkHttp কীভাবে কাজ করে

OkHttp আর্কিটেকচার ইন্টারসেপ্টর চেইনের উপর নির্মিত। প্রতিটি অনুরোধ ইন্টারসেপ্টরের একটি ক্রমের মধ্য দিয়ে যায় যা অনুরোধ, প্রতিক্রিয়া পরিবর্তন করতে বা নির্বাহ বন্ধ করতে পারে। এই আর্কিটেকচারটি Chain of Responsibility প্যাটার্নের মতো এবং নমনীয় সম্প্রসারণযোগ্যতা সক্ষম করে।

যখন একটি অ্যাপ্লিকেশন অনুরোধ পাঠায়, OkHttp নিম্নলিখিত ধাপগুলি সম্পাদন করে: DNS সমাধান করে, পুল থেকে একটি সংযোগ নির্বাচন করে (বা নতুন তৈরি করে), TLS হ্যান্ডশেক খোলে (যদি HTTPS হয়), HTTP অনুরোধ পাঠায়, প্রতিক্রিয়া গ্রহণ করে এবং এটি অ্যাপ্লিকেশনে ফেরত দেয়। RealCall হল অভ্যন্তরীণ ক্লাস যা তৈরি থেকে সম্পূর্ণ পর্যন্ত অনুরোধের সম্পূর্ণ জীবনচক্র পরিচালনা করে।

OkHttp স্বয়ংক্রিয়ভাবে রিডাইরেক্ট (302, 301) পরিচালনা করে, নেটওয়ার্ক ব্যর্থতায় অনুরোধ পুনরায় চেষ্টা করে, keep-alive প্রোটোকল অনুসরণ করে এবং স্বচ্ছ gzip কম্প্রেশন সমর্থন করে। ডেভেলপারকে এই অপারেশনগুলির জন্য কোড লিখতে হয় না — OkHttp সেগুলি সার্ভার হেডারের ভিত্তিতে স্বয়ংক্রিয়ভাবে করে।

HTTP/2 সমর্থন এবং মাল্টিপ্লেক্সিং

HTTP/2 একটি একক TCP সংযোগের মাধ্যমে একসাথে একাধিক অনুরোধ পাঠানোর অনুমতি দেয়, হেড-অফ-লাইন ব্লকিং (HTTP/1.1-এর বৈশিষ্ট্য) ছাড়াই। OkHttp স্বয়ংক্রিয়ভাবে HTTP/2 ব্যবহার করে যদি সার্ভার এটি সমর্থন করে, এবং প্রয়োজন হলে স্বচ্ছভাবে HTTP/1.1-এ ফিরে আসে।

HTTP/2 মাল্টিপ্লেক্সিং মোবাইল অ্যাপ্লিকেশনের জন্য বিশেষভাবে গুরুত্বপূর্ণ, যেখানে সংযোগ স্থাপনের লেটেন্সি (TCP + TLS) 100–300 ms হতে পারে। 10টি ক্রমিক সংযোগের পরিবর্তে, OkHttp একটি ব্যবহার করে, অস্থির সংযোগযুক্ত সাধারণ Android ডিভাইসে মোট লেটেন্সি 40–60% কমিয়ে দেয়।

OkHttp ইন্টারসেপ্টর: Interceptor এবং NetworkInterceptor

Interceptor হল একটি একক পদ্ধতি intercept(Chain) সহ একটি ইন্টারফেস, যা একটি অনুরোধ গ্রহণ করে, কাজ সম্পাদন করে এবং একটি প্রতিক্রিয়া ফেরত দেয়। দুটি ধরণের ইন্টারসেপ্টর রয়েছে: অ্যাপ্লিকেশন ইন্টারসেপ্টর (addInterceptor-এর মাধ্যমে যুক্ত) এবং নেটওয়ার্ক ইন্টারসেপ্টর (addNetworkInterceptor)।

অ্যাপ্লিকেশন ইন্টারসেপ্টর HTTP অনুরোধ গঠনের আগে সক্রিয় হয় — তারা মূল অনুরোধ এবং সমস্ত রূপান্তরের পরে চূড়ান্ত প্রতিক্রিয়া দেখে। নেটওয়ার্ক ইন্টারসেপ্টর নেটওয়ার্ক স্তরে সক্রিয় হয়: তারা gzip কম্প্রেশন, Content-Length হেডার যোগ, রিডাইরেক্ট এবং পুনরায় চেষ্টার পরে অনুরোধ দেখে। নেটওয়ার্ক ইন্টারসেপ্টর কল করা হয় না যদি প্রতিক্রিয়া ক্যাশ থেকে আসে।

ইন্টারসেপ্টরের ব্যবহারিক প্রয়োগ

বাস্তবে, OkHttp ইন্টারসেপ্টর তিনটি প্রধান কাজ সমাধান করে: প্রমাণীকরণ (Authorization হেডার যোগ করা), লগিং (ডিবাগিংয়ের জন্য HttpLoggingInterceptor), এবং পুনরায় চেষ্টা (নেটওয়ার্ক ব্যর্থতায় স্বয়ংক্রিয় অনুরোধ পুনরাবৃত্তি)। একাধিক ইন্টারসেপ্টর একত্রিত করে, অ্যাপ্লিকেশনের প্রতিটি HTTP কলের কোড না ডুপ্লিকেট করেই একটি সম্পূর্ণ অনুরোধ প্রক্রিয়াকরণ পাইপলাইন তৈরি করা যায়।

ইন্টারসেপ্টর যোগ করার ক্রম গুরুত্বপূর্ণ: প্রথম যোগ করা Interceptor প্রবেশের সময় প্রথম এবং প্রস্থানের সময় শেষ কার্যকর হয়। NetworkInterceptor-এর জন্য, ক্রম নেটওয়ার্ক স্ট্যাক দ্বারা নির্ধারিত হয়। প্রস্তাবিত ক্রম: AuthInterceptor (টোকেন যোগ করে), LoggingInterceptor (অনুরোধ লগ করে), RetryInterceptor (ব্যর্থতায় পুনরায় চেষ্টা করে)।

HttpLoggingInterceptor-এর মাধ্যমে লগিং

নেটওয়ার্ক অনুরোধ ডিবাগ করার জন্য, HttpLoggingInterceptor ব্যবহার করা হয় — Square-এর একটি তৈরি ইন্টারসেপ্টর। এটি পদ্ধতি, URL, হেডার এবং অনুরোধ/প্রতিক্রিয়া বডি লগ করে। লগিং স্তর: BASIC (পদ্ধতি + URL + কোড), HEADERS (হেডার সহ), এবং BODY (সম্পূর্ণ অনুরোধ এবং প্রতিক্রিয়া)। BODY ডেভেলপমেন্টের সময় উপযোগী কিন্তু নিরাপত্তা এবং কর্মক্ষমতার কারণে প্রোডাকশনে এটি নিষ্ক্রিয় করা হয়।

Kotlin-এ OkHttp কোড উদাহরণ

OkHttp ব্যবহার করে একটি মৌলিক GET অনুরোধ দেখি। প্রথমে, OkHttpClient তৈরি করা হয় — একটি ভারী অবজেক্ট যা একবার তৈরি হয় এবং পুনরায় ব্যবহার করা হয়। তারপর URL সহ একটি অনুরোধ তৈরি করা হয়, এবং অনুরোধটি execute-এর মাধ্যমে সিঙ্ক্রোনাসভাবে বা enqueue-এর মাধ্যমে অ্যাসিঙ্ক্রোনাসভাবে কার্যকর করা হয়।

val client = OkHttpClient.Builder()
    .connectTimeout(15, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .build()

val request = Request.Builder()
    .url("https://api.github.com/users/octocat")
    .header("Accept", "application/vnd.github.v3+json")
    .build()

val response = client.newCall(request).execute()
println(response.body()?.string())

অ্যাসিঙ্ক্রোনাস নির্বাহের জন্য, enqueue পদ্ধতি ব্যবহার করা হয়, যা একটি Callback গ্রহণ করে। OkHttp ব্যাকগ্রাউন্ড থ্রেডে অনুরোধ কার্যকর করে এবং একই থ্রেডে কলব্যাকে ফলাফল ফেরত দেয়। Android প্রধান থ্রেডে স্যুইচ করতে, Handler বা করুটিন ব্যবহার করুন।

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(
        call: Call, e: IOException
    ) {
        println("অনুরোধ ব্যর্থ হয়েছে: ${e.message}")
    }

    override fun onResponse(
        call: Call, response: Response
    ) {
        println(response.body()?.string())
    }
})

প্রমাণীকরণের জন্য ইন্টারসেপ্টর যোগ করা

একটি কাস্টম Interceptor প্রতিটি অনুরোধে Bearer টোকেন যোগ করে। ইন্টারসেপ্টর Authorization হেডারের উপস্থিতি পরীক্ষা করে, এবং যদি টোকেন এখনও সেট না থাকে, তবে এটি স্টোরেজ থেকে যোগ করে। 401 প্রতিক্রিয়ায়, ইন্টারসেপ্টর Authenticator-এর মাধ্যমে টোকেন রিফ্রেশ করতে পারে।

class AuthInterceptor(
    private val tokenProvider: () -> String?
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val token = tokenProvider.invoke()
        val request = originalRequest.newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        return chain.proceed(request)
    }
}

OkHttp-এ কানেকশন পুল এবং ক্যাশিং

কানেকশন পুল (ConnectionPool) হল OkHttp-এর একটি মূল অপ্টিমাইজেশন যা একাধিক অনুরোধের জন্য TCP সংযোগ পুনর্ব্যবহার করতে দেয়। প্রতিটি অনুরোধের জন্য নতুন সকেট তৈরি করার পরিবর্তে, OkHttp ডিফল্টরূপে 5 মিনিটের জন্য 5টি নিষ্ক্রিয় সংযোগ সংরক্ষণ করে, যা একই হোস্টে পুনরাবৃত্ত অনুরোধে লেটেন্সি 30–70% কমায়।

প্রতিক্রিয়া ক্যাশিং Cache ক্লাসের মাধ্যমে বাস্তবায়িত হয়। ক্যাশিং সক্ষম করতে, OkHttpClient.Builder-এ ডিরেক্টরি এবং সর্বোচ্চ আকার নির্দিষ্ট করুন। OkHttp স্বয়ংক্রিয়ভাবে Cache-Control, Expires এবং ETag হেডার অনুসারে GET প্রতিক্রিয়া ক্যাশ করে, যদি সেগুলি পুরানো না হয় তবে নেটওয়ার্ক অনুরোধ ছাড়াই ক্যাশকৃত ডেটা ফেরত দেয়।

val cacheDir = File(context.cacheDir, "http-cache")
val cache = Cache(cacheDir, 10L * 1024 * 1024)

val client = OkHttpClient.Builder()
    .cache(cache)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

পুল এবং ক্যাশের সঠিক কনফিগারেশন বিশেষভাবে ঘন ঘন অনুরোধ করা অ্যাপ্লিকেশন — নিউজ ফিড, চ্যাট, ডেটা আপডেট — এর জন্য গুরুত্বপূর্ণ। পুল ছাড়া, প্রতিটি TCP সংযোগের জন্য তিনমুখী হ্যান্ডশেক (SYN, SYN-ACK, ACK) এবং সম্ভাব্য TLS হ্যান্ডশেক (2–3 রাউন্ড ট্রিপ) প্রয়োজন, যা প্রতিটি অনুরোধে 100–500 ms যোগ করে।

OkHttp RealWebSocket ক্লাসের মাধ্যমে WebSocket-ও সমর্থন করে। একটি WebSocket সংযোগ HTTP হ্যান্ডশেকের (101 Switching Protocols) মাধ্যমে প্রতিষ্ঠিত হয় এবং তারপর দ্বিমুখী প্রোটোকলে সুইচ করে। OkHttp সংযোগ সক্রিয় রাখতে স্বয়ংক্রিয়ভাবে ping ফ্রেম পাঠায় এবং সংযোগ বিচ্ছিন্ন হলে পুনরায় সংযোগ করে। OkHttp-এর WebSocket wss://echo.websocket.org-এর মতো স্ট্যান্ডার্ড এন্ডপয়েন্টের সাথে সামঞ্জস্যপূর্ণ।

OkHttp নিয়ে কাজ করার সময় সাধারণ ভুল

প্রতিটি অনুরোধের জন্য OkHttpClient তৈরি করা সবচেয়ে সাধারণ ভুল। OkHttpClient-এ কানেকশন পুল, ক্যাশ এবং থ্রেড পুল রয়েছে। প্রতিটি অনুরোধের জন্য নতুন ইনস্ট্যান্স তৈরি করা কেবল মেমরি অপচয়ই নয়, সংযোগ পুনর্ব্যবহারের সুবিধাও হারায়। OkHttpClient-কে DI কন্টেইনারের মাধ্যমে সিঙ্গলটন হওয়া উচিত।

Response.body() বন্ধ করতে অবহেলা রিসোর্স লিকের কারণ হয়। ResponseBody-তে একটি InputStream থাকে যা পড়ার পরে বন্ধ করতে হবে। body().string() বা body().bytes() ব্যবহার করলে, OkHttp স্বয়ংক্রিয়ভাবে স্ট্রিম বন্ধ করে, কিন্তু body().byteStream() বা body().charStream() পড়ার সময় finally ব্লকে স্পষ্ট close() কল প্রয়োজন।

টাইমআউট হ্যান্ডলিং-এর অভাব আরেকটি সমস্যা। ডিফল্টরূপে, OkHttp-এ connectTimeout 10 সেকেন্ড, readTimeout 10 সেকেন্ড এবং writeTimeout 10 সেকেন্ড। অস্থির সংযোগযুক্ত মোবাইল অ্যাপ্লিকেশনের জন্য, connectTimeout 15–30 সেকেন্ড এবং readTimeout 15–30 সেকেন্ড সেট করার পরামর্শ দেওয়া হয়, অন্যথায় ব্যবহারকারী দুর্বল সিগন্যালে খুব বেশি সময় অপেক্ষা করবে।