Request Lifecycle: browser থেকে Laravel-এর যাত্রা
Request Lifecycle
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- URL থেকে response পর্যন্ত flow
- Laravel middleware ও controller-এর ভূমিকা
- Boundary অনুযায়ী failure খোঁজা
সমস্যা দিয়ে শুরু
User বলেন, “সাইট কাজ করছে না।” Browser-এ DNS error হলে controller পরিবর্তন করে লাভ নেই। আবার TLS connection ঠিক হলেও database query আটকে যেতে পারে। Request-এর পুরো যাত্রা বোঝা মানে কোন স্তরে সমস্যা হচ্ছে তা নির্দিষ্ট করতে পারা।
সহজ করে বুঝি
একটি সাধারণ HTTPS request-এ browser hostname resolve করে, connection তৈরি করে, TLS negotiation করে এবং HTTP message পাঠায়। Reverse proxy request PHP runtime-এ দেয়। Laravel application bootstrap করে, middleware stack, router ও controller চালায়। Response middleware পেরিয়ে client-এ ফিরে যায়।
সব request-এ সব ধাপ নতুন করে হয় না। DNS cache, persistent connection, browser cache বা CDN origin পর্যন্ত যাওয়ার প্রয়োজন কমাতে পারে। HTTP/3-এ transport-এর mechanism TCP-ভিত্তিক HTTPS-এর চেয়ে আলাদা। এখানে মূলত TCP/TLS-এর একটি সরল model দেখানো হয়েছে।
পরিচিত একটি উপমা
একটি parcel প্রথমে সঠিক ঠিকানা খুঁজে, sorting center পেরিয়ে স্থানীয় delivery desk-এ পৌঁছায়। Desk recipient যাচাই করে parcel তুলে দেয়। ভুল address আর recipient-এর permission সমস্যা আলাদা জায়গায় ঘটে; software request-এও failure layer আলাদা।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart TD A[Browser] --> B[DNS lookup] B --> C[TCP and TLS] C --> D[Reverse Proxy] D --> E[PHP and Laravel bootstrap] E --> F[Middleware and Router] F --> G[Controller and Database] G --> H[Response middleware] H --> A
DNS ঠিকানা দেয়, TLS connection-এ encryption ও server identity যাচাইয়ের ব্যবস্থা করে। Proxy app-এ traffic পাঠায়। Middleware authentication বা request ID যোগ করতে পারে। Controller business operation শুরু করে; database durable state পড়ে বা লেখে। পুরো flow-এ একটি correlation ID থাকলে logs মিলিয়ে দেখা সহজ হয়।
PHP ও Laravel-এ প্রয়োগ
Laravel middleware-এর handle method-এর একটি fragment। User-এর arbitrary request ID log না করে server-generated UUID ব্যবহার করছি। পূর্ণ class-এ Request, Closure ও Response import লাগবে এবং middleware application-এ register করতে হবে। এটি queue wait বা DNS time মাপে না।
public function handle($request, \Closure $next)
{
$requestId = (string) \Illuminate\Support\Str::uuid();
$start = hrtime(true);
$response = $next($request);
$response->headers->set('X-Request-ID', $requestId);
\Illuminate\Support\Facades\Log::info('http.completed', [
'request_id' => $requestId,
'status' => $response->getStatusCode(),
'duration_ms' => (hrtime(true) - $start) / 1_000_000,
]);
return $response;
}সুবিধা, সীমাবদ্ধতা ও trade-off
Middleware shared concern এক জায়গায় রাখে। অতিরিক্ত synchronous logging বা remote permission check প্রতিটি request ধীর করতে পারে। Request body, cookie বা authorization header log করা privacy ও security ঝুঁকি তৈরি করে। Error path-এর visibility exception handling-এর সঙ্গেও যুক্ত করতে হবে।
সাধারণ ভুল
- সব delay-কে Laravel execution time বলা।
- DNS resolve হলেই HTTPS কাজ করবে মনে করা।
- Middleware-এর আগে failure হলে তার log থাকবে ধরে নেওয়া।
- Trace-এ sensitive payment বা credential data সংরক্ষণ করা।
আরও একটু গভীরে
Traditional PHP-FPM এবং দীর্ঘজীবী Laravel Octane process-এর lifecycle এক নয়। Long-lived worker-এ static property বা singleton-এ request-specific data রেখে দিলে পরের request-এ leak হতে পারে। Runtime বদলালে lifecycle ও memory ownership আবার বুঝে নিন।
মনে রাখুন
- Failure খুঁজতে request-এর layer আলাদা করুন।
- Caching ও connection reuse কিছু ধাপ এড়াতে পারে।
- Application timing পুরো user-perceived latency নয়।
নিজে চেষ্টা করুন
একটি failed request-এর জন্য DNS, TLS, proxy, application ও database—এই পাঁচ স্তরে কোন প্রমাণ দেখবেন লিখুন। Application log না থাকলে কোথা থেকে তদন্ত শুরু করবেন?
নিজের বোঝা যাচাই করুন
1. প্রতিবার DNS lookup হয়?
না। Browser, OS ও resolver cache থেকে উত্তর মিলতে পারে।
2. Middleware কী করে?
Request/response-এর shared concern যেমন authentication, tracing বা rate limiting সামলায়।
3. PHP timing-এ network handshake থাকে?
সাধারণত app-level timer শুরু হওয়ার আগেই handshake শেষ হয়েছে।
4. Correlation ID কেন?
এক request-এর বিভিন্ন component-এর log ও trace মিলিয়ে দেখতে।
5. Octane-এ কী বিশেষ সতর্কতা?
Long-lived process-এ request-specific state ভুল করে ধরে রাখলে পরের request-এ মিশে যেতে পারে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।