Serach in the Google

1. مرورگر

در مرحله اول مرورگر کش یا TTL اگر تموم نشده باشد آدرس IP رو از همونجا میگیره وسایت نمایش داده میشه اما اگر آدرسی نبود میریم مرحله بعد

2. سیستم عامل (چک کردن DNS Cache سیستم)

ویندوز/مک Cache خودشون رو چک میکنن اگر IP پیدا بشه میده به مرورگر و اگر اگر پیدا نشه DNS Serber شبکه رو صدا میزنه

3. روتر یا DNS Server

معمولاً DNSی که استفاده می‌کنی یکی از ایناست:

• DNS شرکت ارائه‌دهنده اینترنتت (ISP)
• 8.8.8.8 (Google DNS)
• 1.1.1.1 (Cloudflare)
• 9.9.9.9 (Quad9)

سیستم‌عامل درخواست می‌فرسته:

مثلا google.com چه IP هستش؟ اگر DNS بدونه یا IP رو داشته باشه که میده اگه نداشته باشه میریم DNS Lookup

4. DNS Lookup

DNS حالا شروع می‌کنه دنبالش گشتن:

A: Root DNS

این‌ها بزرگ‌فامیل‌های دنیای اینترنتن

میگه:

من IPشو ندارم

ولی می‌تونم بهت بگم باید بری سراغ .comها

B: TLD Server (.com)

این‌ها مسئول نگهداری آدرس دامنه‌های .com هستن

میگه:

برو از Name Server اصلی Google بپرس

C: Authoritative Name Server (مثلاً ns1.google.com)

اینجا دیگه رئیس بزرگ میگه:

آدرسش اینه!

مثلاً:

142.250.190.78

و حالا DNS این رو می‌گیره و برمی‌گردونه به سیستم‌عامل → مرورگر

5. مرورگر بالاخره IP رو میگره

حالا مرورگر میدونه google.com = یه عدد مثل اینه :

142.250.190.78

حالا وقت ارتباطه…

6. TCP Handshake — دست دادن مودبانه

مرورگر میگه:

SYN (سلام)

سرور میگه:

SYN-ACK (سلام، خوش اومدی)

مرورگر میگه:

ACK (بزن بریم)

اتصال TCP برقرار شد.

7. TLS/SSL Handshake — رمزنگاری

برای https://

مرورگر میگه:

«گواهی‌تو بده ببینم معتبره؟»

سرور گواهی SSL میده

مرورگر بررسی می‌کنه:

آیا expired نشده؟ آیا از CA معتبره؟ آیا برای google.com صادر شده؟ اگه درست باشه:

رمزنگاری برقرار → امنیت کامل

8. مرورگر درخواست HTTP می‌فرسته

GET / HTTP/1.1
Host: google.com

9. سرور گوگل جواب میده

حالا گوگل یک عالمه HTML, CSS, JS و منابع static می‌فرسته:

• layout موتور جستجو
• لوگو
• جاوااسکریپت‌ها
• فونت‌ها
• APIهایی برای autocomplete

10. مرورگر فایل‌ها رو رندر می‌کنه

مراحل :

• parse HTML
• ساخت DOM
• parse CSS → ساخت CSSOM
• اجرا و parse JS
• ساخت Render Tree
• layout
• paint (نقاشی پیکسل‌ها)
• composite لایه‌ها

و تمام! تو فکر می‌کردی Enter زدی و صفحه اومد؛ ولی

اینترنت:

«رفیق، اینجا یه لشکر از پروتکل‌ها جون کندن!» 😂🔥

به طور خلاصه

وقتی google.com رو می‌نویسی، مرورگر اول از طریق DNS می‌فهمه این آدرس چه IPیی داره. بعد با سرور گوگل یک اتصال امن (TCP + TLS) برقرار می‌کنه و درخواست HTTP می‌فرسته. سرور هم جواب HTML/CSS/JS رو برمی‌گردونه و مرورگر صفحه رو رندر می‌کنه. همین!

Http Vs WebSocket

HTTP :

• ارتباط یک‌طرفه، درخواست–پاسخ، اتصال کوتاه‌مدت

WebSocket :

• ارتباط دوطرفه، دائمی، real‑time

HTTP

• Request → Response
• یک‌طرفه از سمت کلاینت
• stateless (هیچی یادش نمی‌مونه)
• هر درخواست یه اتصال جدا باز و بسته می‌کنه

تو هر بار می‌خوای از مغازه‌دار چیزی بخری، باید:

• در بزنی
• سلام کنی
• درخواست بدی
• جواب بگیری
• در رو ببندی
• حتی اگه هر ۳ ثانیه یه چیزی بخوای

نتیجه:

خب HTTP برای مواردی مثل:

• دانلود صفحه
• و API معمولی
• گرفتن دیتاهای غیر real-time
• فرم‌ها

فوق‌العاده‌ست.

WebSocket

اینو می‌تونی یه نسخهٔ تکامل‌یافتهٔ ارتباط شبکه بدونی.

ویژگی‌هاش:

• ارتباط دوطرفه (full-duplex)
• اتصال پایدار و دائمی
• سرعت بالا
• بدون نیاز به درخواست‌های مکرر
• و real-time واقعی

به زبون سادهWebSocket یعنی تو و مغازه‌دار یه خط مستقیم تلفن دارید

نه نیاز به در زدن، نه باز و بسته کردن اتصال.

هم تو می‌تونی حرف بزنی، هم اون می‌تونه هر وقت خواست جواب بده.

مناسب برای چه سناریوهایی؟

HTTP:

• گرفتن API معمولی
• صفحات وب
• عملیات CRUD
• انتقال فایل
• و Form submit

WebSocket:

• چت آنلاین
• بازی آنلاین
• مانیتورینگ سرور
• و real-time notification
• استریم کردن داده‌های زنده (نمودار ارز، قیمت لحظه‌ای، حسگرها)

const socket = new WebSocket("ws://localhost:3000");

socket.onopen = () => {
  console.log("Connected!");
  socket.send("Hello Server!");
};

socket.onmessage = event => {
  console.log("Message from server:", event.data);
};

تفاوت PUT و PATCH در HTTP

خیلی خلاصه اگر بخوام بگم:

• PUT = جایگزینی کامل (Replace)
• PATCH = تغییر جزئی (Partial Update)

PUT — Full Replacement

وقتی PUT می‌فرستی، داری می‌گی:

“این ریسورس رو کامل با این چیزی که فرستادم جایگزین کن.”

یعنی کل آبجکت باید فرستاده بشه.

اگه فیلدی نفرستی، ممکنه حذف بشه یا null بشه (بسته به implementation بک‌اند).

PATCH — Partial Update

PATCH یعنی:

فقط همین قسمت‌ها رو تغییر بده، بقیه رو دست نزن

فرض کن داری فرم پروفایل رو ادیت می‌کنی:

✅ وقتی کل فرم submit میشه: از PUT استفاده کن.

✅ وقتی inline edit داری (مثلاً فقط name تغییر می‌کنه): PATCH منطقی‌تره.

localStorage Vs Cookie

Cookie :

• حجم کم : معمولاً حدود 4KB.
• ارسال خودکار با هر درخواست HTTP: این بزرگترین فرقشه! هر وقت صفحه رو رفرش می‌کنی یا به سرور درخواست می‌دی، کوکی‌ها اتوماتیک ارسال می‌شن.
• مناسب برای: ذخیره اطلاعات احراز هویت (Authentication Tokens)، تنظیمات سفارشی کاربر که باید با سرور همگام بشه.
• انقضا: می‌تونن تاریخ انقضا داشته باشن (مثلاً برای لاگین تا X روز).
• دسترسی: هم سمت سرور (Node.js, Python, etc.) و هم سمت کلاینت (JavaScript) قابل دسترس و تغییر هستن.

localStorage :

• حجم زیاد: تا 5MB یا بیشتر (بسته به مرورگر).
• ذخیره‌سازی سمت کلاینت: فقط در مرورگر کاربر ذخیره می‌شه و هیچ‌وقت اتوماتیک سمت سرور ارسال نمی‌شه.
• مناسب برای: ذخیره داده‌های UI، تنظیمات آفلاین، کش کردن داده‌ها برای استفادهٔ سریع‌تر در مرورگر.
• انقضا: نداره، تا زمانی که کاربر دستی پاکش نکنه یا مرورگر رو کلاً پاک نکنه، باقی می‌مونه.
• دسترسی: فقط سمت کلاینت (JavaScript) قابل دسترس و تغییر هست.

IndexedDB

خب IndexedDB یک دیتابیس NoSQL داخل مرورگر هست که اجازه میده داده‌های حجیم و ساختاریافته رو سمت کلاینت ذخیره کنیم.

برخلاف localStorage:

• خب async هست
• محدودیت حجم بسیار کمتره
• برای ذخیره‌سازی داده‌های پیچیده‌تر (object, blob, file) استفاده میشه
• امکان indexing و transaction داره

معمولاً برای اپلیکیشن‌های offline-first، PWAها، و ذخیره داده‌های سنگین مثل chat history یا cached API responses کاربرد داره