Capstone: google.com ওপেন করলে কী ঘটে

এই Lesson শেষে তুমি পারবে

• google.com-এ Enter চাপা থেকে Page দেখা পর্যন্ত যা যা ঘটে তা ধাপে ধাপে বর্ণনা করতে, প্রতিটি অংশগ্রহণকারীর নামসহ: Browser, Operating System, Router, ISP, Resolver, Google-এর Edge ও Backend।
• কোনো Packet বেরোনোর আগেই Address Bar কী ঠিক করে তা ব্যাখ্যা করতে (Search নাকি ঠিকানা, HSTS, URL-এর অংশ)।
• একটি Packet-কে NAT ও Internet পেরিয়ে যাওয়া-আসা অনুসরণ করতে, এবং প্রতিটি Hop-এ কোন Header Field বদলায় তা বলতে।
• Google-এর Edge বর্ণনা করতে: কাছের Front End, GFE-তে TLS Termination, এবং Backend Service-এ Routing।
• Critical Rendering Path ব্যাখ্যা করতে (DOM, CSSOM, Render আটকানো CSS, Blocking বনাম async/defer Script, Layout, Paint, Compositing), এবং আবার ভিজিট কেন দ্রুত তা বলতে (Connection পুনর্ব্যবহার, HTTP Cache, 304)।
• আনুমানিক Millisecond-সহ একটি Network Waterfall পড়তে, এবং কোথায় সময় নষ্ট হয় ও কী দিয়ে সারানো যায় তা দেখাতে।
• Network-কে কেন ভরসার অযোগ্য ধরে নিতে হয় (Loss, ওঠানামা করা দেরি, Partial Failure, Partition) আর প্রতিটি সমস্যার জবাবে Design-এর কোন হাতিয়ার আছে, তা ব্যাখ্যা করতে।

#পুরো যাত্রা এক ছবিতে

এটি Networking Module-এর সমাপনী Lesson। আগের প্রতিটি Lesson একটি অংশের ভেতরে ঢুকেছে; এখানে আমরা সেগুলো ক্রম অনুযায়ী জোড়া দেব, Internet-এর সবচেয়ে সাধারণ কাজটির জন্য: google.com লিখে Enter চাপা।

সংক্ষেপে, মুখস্থ রাখার মতো:

Client → DNS → IP Address → Connection → Packet Routing / NAT → Google Server → HTTP Response → Browser Rendering

গভীরে যেতে চাইলে প্রতিটি অংশের আলাদা Lesson আছে: Client–Server, Layer ও Encapsulation, IP ও MAC Addressing, Routing ও NAT, DNS, TCP, UDP ও TLS, Network Device, Firewall, Proxy ও VPN এবং Diagnostics। এই Lesson দেখায় ওই অংশগুলোর মাঝখানে কী ঘটে, আর এমন অংশ যা অন্য কোনোটি দেখায় না: Address Bar, Google-এর Edge, Rendering, Caching ও সময়রেখা।

#Acronym-এর তালিকা

#শুরু থেকে শেষ, চোখের সামনে

এই হলো পুরো যাত্রা, প্রত্যেক অংশগ্রহণকারী ধরে। প্রথম ভিজিট চালাও, তারপর তুলনা করো আবার ভিজিট, HTTP/3 ও দুটি ব্যর্থতার সঙ্গে। Lesson-এর বাকি অংশ প্রতিটি ধাপ বিস্তারিত ব্যাখ্যা করে।

#ধাপ ১: Address Bar-এ URL Parsing

Chrome-এর Address Bar-এ (“Omnibox”) লিখে Enter চাপলে Browser প্রথমে ঠিক করে: এটি Search Query, নাকি Website Address?

• Scheme আছে (https://…) বা Host Name-এর মতো দেখায় (Space নেই, শেষে .com বা .bd-এর মতো আসল Top-level Domain, কিংবা IP Address বা localhost): এটি ঠিকানা।
• Space আছে বা বৈধ Host নেই: এটি Search, তোমার Default Search Engine-এ https://www.google.com/search?q=… হিসেবে যায়।
• একটি মাত্র শব্দ, যেমন printer: Search হিসেবে ধরা হয়, কিন্তু Browser চুপচাপ DNS যাচাই করে এবং “Did you mean http://printer/?” দেখাতে পারে।

তারপর সে Scheme বাছে। তুমি https:// লেখোনি, তবুও Browser HTTPS ব্যবহার করবে:

• HSTS (HTTP Strict Transport Security) হলো সাইটের নির্দেশ “আমার সঙ্গে শুধু HTTPS-এ যোগাযোগ করো”। প্রথম ভিজিটের পর Browser এটি মনে রাখে, আর ভেতরেই একটি Preload List নিয়ে আসে, যেসব সাইট প্রথম ভিজিট থেকেই শুধু HTTPS; অনেক Google Domain এতে আছে। এদের জন্য http://google.com-ও Browser-এর ভেতরেই https:// হয়ে যায় (Internal Redirect), তাই কোনো Plain-text Request তোমার কম্পিউটার থেকে বেরোয়ই না।
• HSTS ছাড়াও আধুনিক Browser টাইপ করা ঠিকানার জন্য আগে HTTPS চেষ্টা করে।

শেষে সে URL (Uniform Resource Locator)-কে অংশে ভাগ করে:

https://www.google.com:443/search?q=dns#results
└─┬─┘   └──────┬─────┘└┬┘└──┬──┘└──┬──┘└──┬───┘
scheme       host    port  path  query  fragment (never sent to the server)

Port সাধারণত লেখা হয় না: https-এর Default 443, http-এর 80।

Browser হলো সেই Software যা Request পাঠায় ও Response দেখায়; OS (Operating System, যেমন Windows) Browser যে Network Hardware ও System Resource-এর ওপর নির্ভর করে তা পরিচালনা করে। এসবের আগেই, তুমি টাইপ করতে থাকার সময়ই Browser হয়তো google.com আগেভাগে Resolve করে ফেলেছে, এমনকি Connection-ও খুলে রেখেছে, কারণ সে অনুমান করেছিল তুমি Enter চাপবে।

#ধাপ ২: DNS Lookup

কম্পিউটার নাম দিয়ে Routing করে না; তার গন্তব্যের IP Address লাগে। Lookup ক্রমানুসারে দেখে Browser-এর DNS Cache, OS Cache ও hosts File, তারপর জিজ্ঞেস করে Recursive DNS Resolver-কে (তোমার ISP-এর, বা 8.8.8.8 বা 1.1.1.1-এর মতো Public Resolver)। Resolver-এর Cache-এ কিছু না থাকলে সে Tree ধরে হাঁটে:

• Root DNS Server: “.com TLD Server-কে জিজ্ঞেস করো”।
• TLD DNS Server (.com): “Google-এর Authoritative Name Server হলো ns1–ns4.google.com”।
• Authoritative DNS Server (Google-এর): “www.google.com-এর Address এটি, ৩০০ সেকেন্ড Cache করো”।
• Recursive Resolver: উত্তর Cache করে এবং তোমার কম্পিউটারে IP ফেরত দেয়।

উদাহরণ: google.com → DNS Resolution → IP Address। কোনো Cache-এ বৈধ উত্তর থাকলে Root, TLD ও Authoritative Server-এ যেতেই হয় না, আর Google-এর মতো জনপ্রিয় নামের ক্ষেত্রে এটাই স্বাভাবিক। DoH চালু থাকলে Browser DNS Query HTTPS-এর ভেতরে পাঠায়, ফলে Network তা পড়তে পারে না।

এই যাত্রার জন্য দুটি গুরুত্বপূর্ণ খুঁটিনাটি:

• উত্তর নির্ভর করে তুমি কোথা থেকে জিজ্ঞেস করছ তার ওপর। Google-এর Name Server Resolver-এর অবস্থান (বা Client-subnet ইঙ্গিত) দেখে তোমার কাছের একটি Front End-এর Address দেয়। ঢাকার ও লন্ডনের ব্যবহারকারী একই নামের জন্য ভিন্ন IP পায়।
• TTL ছোট (৩০০ সেকেন্ড), যাতে Google দ্রুত এক জায়গা থেকে আরেক জায়গায় Traffic সরাতে পারে।

পূর্ণ বিবরণ, Record Type, Caching স্তর ও ব্যর্থতা আছে DNS Lesson-এ।

#ধাপ ৩: Connection Establishment

IP হাতে পেলে Browser একটি Transport Connection তৈরি করে, অথবা আগে থেকে খোলা একটি পুনরায় ব্যবহার করে।

TCP-ভিত্তিক HTTPS হলে:

1. SYN (Synchronize): Client Connection শুরু করে।
2. SYN-ACK: Server স্বীকার করে উত্তর দেয়।
3. ACK (Acknowledgment): Client নিশ্চিত করে।

এটিই TCP Three-Way Handshake: একটি Round Trip। এরপর TLS Handshake Encryption প্রস্তুত করে। TLS 1.3-এ লাগে আরও একটি Round Trip: Client পাঠায় তার সমর্থিত Cipher, একটি Key Share, Server-এর নাম (SNI) ও যে Protocol সে বলে (ALPN, HTTP/2-এর জন্য “h2”); Server উত্তর দেয় তার Key Share ও Google-এর Certificate দিয়ে, যা Browser যাচাই করে (সঠিক নাম, বৈধ তারিখ, বিশ্বস্ত কর্তৃপক্ষের Signature)। TCP নির্ভরযোগ্য ও ক্রমানুসারী Delivery দেয়; TLS এনক্রিপ্ট করে এবং Server-এর পরিচয় প্রমাণ করে।

ব্যতিক্রম: HTTP/3 TCP ব্যবহার করে না। এটি চলে UDP-র ওপর QUIC-এ, যা Transport ও TLS Handshake একত্র করে একটি Round Trip-এ সারে (কিছু আবার ভিজিটে শূন্য)। তাই সব HTTPS Connection-এ TCP Three-Way Handshake বাধ্যতামূলক নয়। Google যে HTTP/3 সমর্থন করে তা Browser জানে আগের কোনো Response-এর alt-svc Header থেকে (বা DNS-এর HTTPS Record থেকে), আর UDP Block থাকলে TCP-তে ফিরে যায়।

Connection পুনর্ব্যবহার। Handshake-এ Round Trip খরচ হয়, তাই Page লোডের পর Browser Connection খোলা রাখে এবং একই Server-এ পরের Request-এর জন্য তা পুনরায় ব্যবহার করে, আর একটি HTTP/2 বা HTTP/3 Connection একসঙ্গে অনেক Request বহন করে। শিগগিরই লাগবে এমন অন্য Host-এর জন্য Page আগেভাগে প্রস্তুতিও চাইতে পারে <link rel="preconnect"> দিয়ে (আগে থেকেই DNS + TCP + TLS) বা <link rel="dns-prefetch"> দিয়ে (শুধু DNS)। TCP, UDP ও TLS Lesson প্রতিটি Handshake Packet ধরে ধরে দেখায়।

#ধাপ ৪: HTTP Request পাঠানো

নিরাপদ Connection দিয়ে Browser Page চায়:

GET / HTTP/2
Host: www.google.com
Accept: text/html
Accept-Language: bn-BD,en;q=0.9
Accept-Encoding: gzip, br
Cookie: …

এটি শুধু বোঝানোর জন্য সরলীকৃত, পড়ার উপযোগী রূপ। বাস্তব HTTP/2-তে Header এভাবে Text হিসেবে যায় না: সেগুলো Compress হয়ে Binary Frame-এ যায় (আর HTTP/2-তে Host যায় :authority নামের একটি Pseudo-header হিসেবে)।

• HTTP (Hypertext Transfer Protocol) ঠিক করে Web Request ও Response দেখতে কেমন হবে; HTTPS হলো TLS-এর ভেতরে HTTP।
• GET হলো Resource আনার Method; Path / মানে Home Page।
• Header অতিরিক্ত তথ্য বহন করে: কোন ভাষা ও Compression Format তুমি গ্রহণ করো, তোমার Sign in করা Session চেনানোর Cookie, ইত্যাদি।

#খামের ভেতরে Request

তোমার কম্পিউটার থেকে বেরোনোর আগে Request স্তরে স্তরে মোড়ানো হয়: HTTP Data একটি TLS Record-এর ভেতরে, তা একটি TCP Segment-এর (Port) ভেতরে, তা একটি IP Packet-এর (Address) ভেতরে, তা একটি Wi-Fi বা Ethernet Frame-এর (এই একটি Link-এর MAC Address) ভেতরে। এটাই Encapsulation; প্রতিটি Router শুধু বাইরের খাম খোলে, সব খাম খোলে শুধু Google-এর Edge। পেছনের Model দেখতে Layer ও Encapsulation দেখো।

#ধাপ ৫: Router, ISP ও Internet Routing

এবার Google-এর IP-তে পৌঁছাতে Packet-কে কয়েকটি Network পার হতে হবে।

• Default Gateway: Google-এর IP তোমার Local Network-এ নেই, তাই কম্পিউটার Frame পাঠায় Default Gateway-তে, অর্থাৎ বাসার Router-এ (তার MAC Address ARP দিয়ে খুঁজে নিয়ে)।
• NAT: তোমার Laptop-এর Private Address (192.168.1.10) Internet-এ অর্থহীন। Router Source বদলে নিজের Public IP ও একটি Port (203.0.113.25:62001) বসায়, এবং NAT Table-এ Mapping লিখে রাখে যাতে উত্তর তোমার কাছে ফেরত পাঠাতে পারে। তোমার ISP Carrier-grade NAT (CGNAT) ব্যবহার করলে ISP-এর ভেতরে এটি আরেকবার ঘটে।
• Router: প্রতিটি Router Destination IP দেখে, Routing Table মিলিয়ে Packet-কে Next Hop-এ পাঠায়। কোনো Router পুরো End-to-End পথ জানে না। Network-গুলোর মধ্যে BGP ঠিক করে কোন প্রতিবেশী Network-কে Packet দিতে হবে।
• ISP: তোমার Internet Service Provider Packet-কে বৃহত্তর Internet-এ নিয়ে যায়। বড় ISP-গুলো Exchange Point-এ সরাসরি Google-এর সঙ্গে যুক্ত (Peering), তাই পথ প্রায়ই মাত্র কয়েকটি Hop।
• ফেরার পথ Request-এর পথ থেকে আলাদা হতে পারে, কারণ প্রতিটি Network নিজের Forwarding সিদ্ধান্ত নেয়।

প্রতিটি Hop-এ কোন Header Field বদলায় খেয়াল করো: MAC Address প্রতিটি Link-এ বদলায়, প্রতিটি Router-এ TTL এক কমে, Source IP ও Port NAT-এ একবার বদলায়, আর Destination IP কখনো বদলায় না।

Routing Table, Default Gateway ও NAT সম্পর্কে আরও আছে Routing ও NAT-এ।

#ধাপ ৬: Google-এর দিক ও HTTP Response

Packet-গুলো তোমার কাছের একটি Google Edge Location-এ (Point of Presence, বা PoP) পৌঁছায়। Google-এর দিকটি স্তরে স্তরে সাজানো:

1. তোমাকে কাছের Edge-এ আনা। Google-এর DNS কাছের Front-end Address দিয়ে উত্তর দেয়, আর Google-এর অনেক Address Anycast: একই IP অনেক জায়গা থেকে BGP দিয়ে ঘোষণা করা হয়, তাই Internet Routing তোমাকে সবচেয়ে কাছেরটিতে পৌঁছে দেয়। কোনো Location ব্যর্থ হলে তার Route প্রত্যাহার হয় আর Traffic পরেরটিতে যায়।
2. GFE (Google Front End) হলো Google-এর Reverse Proxy-র বহর। সে তোমার কাছেই TLS Terminate করে (Handshake-এর জন্য ছোট Round Trip), বন্যা ও অপব্যবহার থেকে রক্ষা করে, এবং কোন Backend Service ও Data Centre Request সামলাবে তা ঠিক করে।
3. Backend। GFE Request-টি Google-এর Private Backbone দিয়ে (পাবলিক Internet দিয়ে নয়) আগে থেকে খোলা Connection ব্যবহার করে পাঠায়। Search Frontend একসঙ্গে অন্য Service-গুলোকে Call করে (তোমার Account, আজকের Doodle ইত্যাদি) এবং HTML তৈরি করে।
4. Response GFE দিয়ে ফেরে, GFE তা Compress ও এনক্রিপ্ট করে তোমার কাছে Stream করে।

একটি সরলীকৃত Response দেখতে এমন:

HTTP/2 200
content-type: text/html; charset=UTF-8
content-encoding: br
cache-control: private, max-age=0
alt-svc: h3=":443"

• HTTP Response: Server-এর পাঠানো উত্তর: একটি Status Code, Header ও Body।
• Response Body: HTML (বা অন্য Content)।

এই যাত্রায় যেসব Status Code দেখবে:

HTML পাওয়া মানেই শেষ নয়: Browser-কে সাধারণত CSS, JavaScript, Image ও Font-এর জন্য আরও Request পাঠাতে হয়।

#আরও Request: CSS, JavaScript, Image ও Font

HTML Stream হয়ে আসতে থাকলে Parser (এবং আগে আগে পড়া একটি Preload Scanner) Page-এর দরকারি অন্য File খুঁজে পায়। সেগুলো আনা হয় সমান্তরালে:

• HTTP/2 বা HTTP/3-এ একই Host-এর সব Request একটি Connection ভাগ করে, আলাদা Stream হিসেবে, অগ্রাধিকারসহ (CSS আগে, কারণ এটি Rendering আটকায়)। নতুন Handshake নেই।
• পুরনো HTTP/1.1-এ একটি Connection একবারে একটি Request বহন করে, তাই Browser প্রতি Host-এ ৬টি পর্যন্ত Connection খোলে, প্রত্যেকটির নিজস্ব Handshake।
• অন্য Origin-এর File (ভিন্ন Host, যেমন Font Server) নিজস্ব DNS Lookup ও Handshake চায়, যদি না preconnect ইঙ্গিত সেগুলো আগেভাগে শুরু করে।
• অনেক File সরাসরি Edge-এর Cache থেকে আসে, দীর্ঘ Cache মেয়াদসহ, তাই পরের ভিজিটে Network একদমই লাগে না।

#ধাপ ৭: Browser Rendering

Browser এবার HTML, CSS ও JavaScript-কে Pixel-এ রূপান্তর করে। এই ধারাবাহিকতাকে বলে Critical Rendering Path:

1. HTML → DOM। Byte থেকে Character, Token, তারপর DOM (Document Object Model)-এর Node তৈরি হয়: প্রতিটি Element-এর একটি Tree, যা JavaScript পড়তে ও বদলাতে পারে। এটি Page-এর Structure বা কাঠামো তৈরি করে।
2. CSS → CSSOM। Stylesheet Parse হয়ে CSSOM (CSS Object Model) হয়: Style, Color, Size ও Layout-এর নিয়ম। CSS Render আটকায়: Style-ছাড়া Content-এর ঝলক এড়াতে CSSOM প্রস্তুত না হওয়া পর্যন্ত Browser আঁকে না।
3. JavaScript Execution। Interaction, Event ও Dynamic Content পরিচালনা করে। সাধারণ <script src> Parser আটকায়: Download হয়ে চলা পর্যন্ত Parse থেমে থাকে। defer Script সমান্তরালে Download হয় এবং Parse-এর পর চলে (DOMContentLoaded-এর আগে); async Script পৌঁছানো মাত্র চলে, যেকোনো ক্রমে।
4. Render Tree। DOM + CSSOM মিলে দৃশ্যমান Element-গুলোর Tree, তাদের হিসাব করা Style-সহ।
5. Layout (Reflow)। বর্তমান স্ক্রিনের প্রস্থ অনুযায়ী প্রতিটি Box-এর সঠিক আকার ও অবস্থান হিসাব হয়।
6. Paint। Box-গুলো আঁকার নির্দেশে পরিণত হয় (Text, রং, Border, Image), প্রায়ই কয়েকটি Layer-এ।
7. Composite → Display। Layer-গুলো Pixel-এ Rasterise হয়, আর Compositor, বেশিরভাগ GPU-তে, সেগুলো স্ক্রিনে সাজায়।

এই ধাপগুলো সব সময় সম্পূর্ণ আলাদাভাবে একটির পর একটি ঘটে না। Browser Download চলার সময়ই HTML Parse করে, CSS ও Image সমান্তরালে আনে, এবং নিচের অংশ আসার আগেই Page-এর ওপরের অংশ আঁকতে পারে।

Page লোড হওয়ার পর পরিবর্তন যত কম ধাপ ছোঁয় তত সস্তা: জ্যামিতি (প্রস্থ, Flow-এ অবস্থান) বদলালে আবার Layout, Paint ও Composite; রং বদলালে Paint ও Composite; নিজস্ব Layer-এ transform বা opacity বদলালে শুধু Composite। এজন্যই মসৃণ Animation transform ও opacity ব্যবহার করে।

#আবার ভিজিট: Caching

এক মিনিট পর আবার Google খুললে প্রায় সবকিছুই বাদ পড়ে:

• DNS: IP এখনো Browser ও OS Cache-এ (TTL ৩০০ s)।
• Connection: HTTP/2 Connection হয়তো এখনো খোলা; না থাকলে TLS Session Resumption (বা QUIC 0-RTT) নতুন Handshake সস্তা করে।
• HTTP Cache: Cache-Control: max-age=… দিয়ে রাখা File Fresh থাকা পর্যন্ত কোনো Request ছাড়াই Memory বা Disk থেকে পুনরায় ব্যবহার হয়। বড় সাইটগুলো File-এর নামে Content-এর Hash রাখে (app.3f9a1c.js) এবং এক বছরের জন্য Cache করে: নতুন Version মানে শুধু নতুন নাম।
• যাচাই (Revalidation): ETag (Version Tag)-সহ একটি Stale File একটি শর্তসাপেক্ষ Request (If-None-Match) দিয়ে যাচাই হয়। অপরিবর্তিত হলে Server Body ছাড়া 304 Not Modified দেয়।
• ব্যক্তিগত Page private চিহ্নিত থাকে (Proxy বা CDN-এর মতো Shared Cache নয়) এবং প্রায়ই no-cache বা max-age=0, তাই HTML সবসময় নতুন করে আনা হয়। Google-এর Home Page এমনই একটি।

#সময়রেখা: Millisecond কোথায় যায়

সবকিছু একটি সময়-অক্ষে বসালে পাওয়া যায় Waterfall, যা Browser-এর Developer Tools-এ দেখা যায়। নিচের সংখ্যাগুলো আনুমানিক, ভালো Broadband-এর জন্য, যেখানে Google-এর কাছের Edge পর্যন্ত Round Trip প্রায় ৩০ ms:

পরিস্থিতিগুলো যা দেখায়:

• Bandwidth নয়, Round Trip-ই প্রধান। ৩০০ ms-এর Mobile সংযোগে একই Page-এ প্রায় ৩ সেকেন্ড লাগে, প্রায় পুরোটাই Round Trip-এর অপেক্ষা। এজন্যই Google ব্যবহারকারীর কাছে Edge রাখে, HTTP/3 পছন্দ করে, Preconnect ব্যবহার করে এবং Critical CSS Inline করে।
• আবার ভিজিট অনেক দ্রুত, DNS Caching, Connection পুনর্ব্যবহার ও HTTP Cache-এর কারণে।
• Performance Team-গুলো নজর রাখে TTFB (Time to First Byte), প্রথম Paint ও LCP (Largest Contentful Paint: কখন প্রধান Content দৃশ্যমান হয়) এর ওপর।

#কিছু ভুল হলে

ধাপগুলো এটাও বলে দেয়, Page না খুললে কোথায় দেখতে হবে। প্রতিটি Error একটি ধাপের দিকে ইঙ্গিত করে:

প্রতিটি ধাপ যাচাইয়ের Tool (ping, traceroute, nslookup, curl) দেখায় Diagnostics Lesson।

#Network ভরসার যোগ্য নয়

ওপরের সবকিছু ছিল সব-ঠিক-থাকার পথ। অথচ প্রতিটি ধাপ পার হয়েছে এমন Link, Router আর Machine দিয়ে, যেগুলো যেকোনো সময় বিকল হতে পারে। Google-এর মাপে, বা যেকোনো ব্যস্ত System-এ, কোথাও না কোথাও সবসময় কিছু একটা নষ্ট থাকে। যে System টিকে থাকে, সে ব্যর্থতাকে স্বাভাবিক ঘটনা ধরে নিয়েই বানানো, হঠাৎ আসা বিপদ হিসেবে নয়।

#আসলে কী কী ভুল হয়

• Packet Loss। Queue উপচে পড়ে, Wi-Fi-এর Frame ধাক্কা খায়, Cable কাটা পড়ে। TCP আর QUIC আবার পাঠিয়ে Loss ঢেকে দেয়, কিন্তু প্রতিটি Loss-এ অন্তত আরেকটি Round Trip খরচ হয়, আর একটি SYN হারালে খরচ পুরো এক সেকেন্ড। ব্যবহারকারীর চোখে Loss দেখায় ধীরগতি হিসেবে, বিশেষ করে সবচেয়ে ধীর Request-গুলোতে (p99), Error হিসেবে নয়।
• ওঠানামা করা দেরি। একই Request কখনো ৩০ ms নেয়, কখনো ৩০০ ms, পথের Queue-গুলোর ওপর নির্ভর করে। বাইরে থেকে “ধীর” আর “মৃত” হুবহু এক রকম দেখায়, যতক্ষণ না তুমি অপেক্ষা থামানোর সিদ্ধান্ত নাও।
• Partial Failure। এক Computer-এ একটা Program হয় চলে, নয় Crash করে। Network-এ কিছু অংশ চলে আর কিছু অংশ ব্যর্থ হয়, আর উত্তর না এলে তুমি জানতেই পারো না কেন: Request হারিয়েছে, Server ধীর, কাজের আগেই Server Crash করেছে, নাকি কাজ হয়ে গেছে কিন্তু উত্তরটা হারিয়েছে।
• Partition। একটি Link কাটা পড়লে Machine-গুলো কয়েকটা দলে ভাগ হয়ে যেতে পারে: সবাই চলছে, কিন্তু এক দল আরেক দলের নাগাল পায় না। প্রতিটি দল ভাবতে পারে অন্যরা মরে গেছে, আর একাই কাজ চালিয়ে যায়।

#এর জন্য Design করা

যে Google যাত্রা তুমি এইমাত্র দেখলে, সেটা ঠিক এভাবেই বানানো: DNS-এর উত্তর আসে Cache আর একাধিক Name Server থেকে, তোমার Operating System-এর একটি দ্বিতীয় Resolver আছে, TCP হারানো Segment আবার পাঠায়, UDP Block থাকলে Browser QUIC ছেড়ে TCP-তে ফেরে, কোনো Edge Location বিকল হলে Anycast সেটা সরিয়ে ব্যবহারকারীকে পরেরটায় পাঠায়, আর GFE একটি Request অন্য Backend-এ আবার চেষ্টা করে।

যখন Chapter 18-এ (CAP, PACELC আর Consistency) আর Chapter 28-এ (Timeout, Retry, Idempotency, Circuit Breaker আর Load Shedding) পৌঁছাবে, মনে রেখো সবকিছুর শুরু কোথায়: একটি Packet, যা পৌঁছাতেও পারে, না-ও পারে।

#এক নজরে সম্পূর্ণ প্রক্রিয়া

1. URL Parsing: Browser ঠিকানা বোঝে।
2. DNS Resolution: প্রয়োজন হলে Domain-এর IP খোঁজা হয়।
3. Connection: TCP + TLS অথবা QUIC + UDP।
4. Packet Encapsulation: HTTP Data Transport, IP ও Link Header-এর মধ্যে বহন হয়।
5. Routing + NAT: Router Packet Forward করে; প্রয়োজন হলে Address Translation করে।
6. Google Server: Frontend ও প্রাসঙ্গিক Backend Request Process করে।
7. HTTP Response: Server-এর উত্তর Client-এর দিকে ফিরে আসে।
8. Browser Rendering: HTML, CSS ও JavaScript থেকে Page তৈরি হয়।

পরীক্ষার ও বাস্তব কাজের জন্য সবচেয়ে গুরুত্বপূর্ণ পার্থক্য:

• DNS বলে দেয় Domain-এর জন্য কোন IP Address ব্যবহার করতে হবে।
• Router Destination IP অনুযায়ী পরবর্তী Hop বেছে নেয়।
• NAT প্রয়োজন হলে IP Address ও Port-এর Mapping পরিবর্তন করে।
• TCP/UDP Transport Layer-এ Data বহন করে; TCP নির্ভরযোগ্য Delivery দেয়, UDP নিজে সেই নিশ্চয়তা দেয় না।
• TLS HTTPS Communication-কে সুরক্ষিত করে।
• HTTP Web Request ও Response-এর নিয়ম নির্ধারণ করে।
• Google Server Request Process করে Response পাঠায়।
• Browser Response থেকে Web Page তৈরি করে স্ক্রিনে দেখায়।

সবচেয়ে সহজে মনে রাখার সূত্র:

Client → DNS → IP Address → Connection → Packet Routing/NAT → Google Server → HTTP Response → Browser Rendering

#নিজে করে দেখো

# Time each phase of a real request (Windows: use curl.exe in PowerShell)
curl -o /dev/null -s -w "dns  %{time_namelookup}s\ntcp  %{time_connect}s\ntls  %{time_appconnect}s\nttfb %{time_starttransfer}s\ntotal %{time_total}s\n" https://www.google.com/

# See the redirect, the status code and the headers
curl -sI https://google.com | head -n 5
curl -sI https://www.google.com | grep -iE "^HTTP|cache-control|alt-svc|content-type"

# Which IP does Google give you? (compare with a friend in another city)
nslookup www.google.com

# The hops between you and Google's edge
tracert www.google.com        # Windows
traceroute www.google.com     # macOS / Linux

# The certificate the GFE presents
openssl s_client -connect www.google.com:443 -servername www.google.com </dev/null | head -n 20

Chrome-এ Developer Tools খোলো (F12), Network Tab-এ যাও, “Disable cache”-এ টিক দাও, এবং google.com লোড করো। Column Header-এ Right-click করে Protocol যোগ করো (h2 বা h3 দেখবে), কোনো সারির ওপর Mouse রেখে তার সময়ের ভাগ দেখো (DNS, Initial Connection, SSL, Server Response-এর অপেক্ষা, Content Download), তারপর “Disable cache” ছাড়া আরেকবার লোড করে তুলনা করো। chrome://net-internals/#hsts দিয়ে কোনো Domain-এর HSTS অবস্থা জানা যায়।

#সারসংক্ষেপ

মূল শিক্ষা

• যাত্রা: Client → DNS → IP → Connection → Routing/NAT → Google Server → HTTP Response → Rendering, বাস্তবে প্রচুর Overlap ও Caching-সহ।
• কোনো Packet-এর আগে: Address Bar ঠিক করে Search নাকি ঠিকানা, HTTPS বাধ্য করতে HSTS প্রয়োগ করে, এবং URL-কে Scheme, Host, Port ও Path-এ ভাগ করে।
• DNS ছোট TTL-সহ একটি কাছের Google Front-end IP দেয়; সাধারণত Cache থেকে।
• Connection: TCP (১ Round Trip) + TLS 1.3 (১ Round Trip), অথবা UDP-র ওপর QUIC (১, কখনো ০)। Browser Connection পুনরায় ব্যবহার করে এবং Preconnect করতে পারে।
• পথে: Request Encapsulate হয়; তোমার Router NAT করে; Router-গুলো Destination IP দেখে Hop by Hop Forward করে; প্রতি Link-এ MAC বদলায়, প্রতি Hop-এ TTL কমে; ফেরার পথ আলাদা হতে পারে।
• Google-এর Edge: Anycast/DNS তোমাকে কাছের PoP-এ আনে; GFE TLS Terminate করে, অপব্যবহার Filter করে এবং Google-এর Backbone দিয়ে Backend Service-এ Route করে। CDN ≠ GFE।
• Rendering: HTML → DOM, CSS → CSSOM (Render আটকায়), Script (Blocking বনাম defer/async), Render Tree → Layout → Paint → Composite। Subresource HTTP/2-তে সমান্তরালে লোড হয়।
• আবার ভিজিটে DNS, Handshake ও বেশিরভাগ Download বাদ পড়ে (HTTP Cache, 304)। Waterfall-এ সবচেয়ে বেশি সময় খায় Round Trip।
• Network ভরসার যোগ্য নয়: Loss দেখা দেয় দেরি হিসেবে, উত্তর না এলে বোঝা যায় না কাজটা হয়েছে কি না (Partial Failure), আর Partition চালু Machine-গুলোকে ভাগ করে ফেলে। এর জবাব: Timeout, Backoff-সহ Retry, Idempotency Key, Graceful Degradation, আর Chapter 18 ও 28-এর Trade-off।

নিজেকে যাচাই করো: google.com খুললে কী ঘটে৩০টি প্রশ্ন