Internet va web qanday ishlaydi — client-server, HTTP/HTTPS, DNS (0.4-bob)

0-QISM — TAYYORGARLIK · 4-mavzu

1. Kirish va motivatsiya

Hozirgacha bitta kompyuterni o'rgandik: uning temirini 0.1-bob, operatsion tizimini 0.2-bob, terminalini 0.3-bob. Lekin zamonaviy dastur deyarli hech qachon yolg'iz ishlamaydi — u boshqa kompyuterlar bilan gaplashadi. Siz telefoningizda Instagram ochasiz — u Instagram serveri bilan gaplashadi. Sayt ochasiz — brauzer o'sha saytning serveri bilan gaplashadi.

Siz full-stack dasturchi bo'lasiz, ya'ni shu suhbatning ikkala tomonini ham yozasiz: frontend (so'rov yuboruvchi) va backend (javob qaytaruvchi). Ular orasidagi "til" — HTTP. Agar HTTP'ni tushunmasangiz, butun veb-dasturlash siz uchun "sehr" bo'lib qoladi.

Bu bobni o'qib bo'lgach, quyidagi savollarga aniq javob berasiz:

• google.com deb yozib Enter bosganimda, aniq nima sodir bo'ladi? (Bu — eng mashhur intervyu savoli.)
• GET, POST, PUT, DELETE nima farqi bor va qachon qaysi biri?
• 404, 500, 401, 403 — bu raqamlar nimani anglatadi?
• HTTP va HTTPS farqi nima — s harfi nega muhim?
• DNS nima va nega ba'zan "site topilmadi" deydi?

Bu — butun frontend va backend ishining poydevori. REST API 5.7-bob, fetch/axios (2.17–2.18), CORS 5.20-bob, deploy va SSL 10.7-bob — hammasi shu bobga tayanadi.

2. Nazariya — chuqur tushuntirish

2.1. Tarmoq (network) va Internet nima?

Tarmoq (network) — bir-biri bilan bog'langan, ma'lumot almasha oladigan kompyuterlar to'plami. Internet esa — "tarmoqlar tarmog'i" (network of networks): butun dunyodagi millionlab tarmoqlarni bog'laydigan ulkan tizim.

Internet orqali ma'lumot paket (packet) ko'rinishida yuboriladi. Katta fayl (masalan rasm) bir butun emas, balki kichik bo'laklarga bo'linib, har biri alohida yuboriladi va manzilda yana yig'iladi.

O'xshatish: katta kitobni pochta orqali yuborayotganingizni tasavvur qiling. Uni bitta katta quti qilib emas, balki har bir sahifani alohida konvertda, ustiga manzil yozib yuborasiz. Konvertlar turli yo'llardan borib, manzilda yana tartib bilan yig'iladi. Internet ham xuddi shunday — bu ishonchli va moslashuvchan.

2.2. IP manzil va port

Har bir tarmoqdagi kompyuterning manzili bo'lishi kerak — aks holda paketni qayerga yuborishni bilib bo'lmaydi. Bu — IP manzil (IP address):

• IPv4: 142.250.187.78 kabi (4 ta son, har biri 0–255 — ya'ni 1 bayt, 0.1-bobni eslang). Jami ~4.3 milliard manzil (2^32).
• IPv6: 2001:0db8:85a3::8a2e:0370:7334 kabi (ancha ko'p manzil, chunki IPv4 yetmay qoldi).

Port — bitta kompyuterda ko'p dastur ishlaydi (0.2: process'lar). Port — bu "qaysi dastur" degan xona raqami:

   142.250.187.78 : 443
   └──────┬──────┘  └┬┘
      IP (qaysi      port (o'sha kompyuterdagi
      kompyuter)      qaysi dastur/xizmat)

Mashhur portlar: 80 (HTTP), 443 (HTTPS), 22 (SSH — 0.3), 5432 (PostgreSQL), 27017 (MongoDB), 3000/8080 (dasturchilar lokal serveri).

O'xshatish: IP manzil — bu bino manzili (ko'cha, uy raqami). Port — o'sha binodagi kvartira raqami. Pochtachi to'g'ri kvartiraga yetkazishi uchun ikkalasi ham kerak.

2.3. Client–server modeli

Vebning asosiy modeli — client–server:

• Client (mijoz) — so'rov yuboradi. Masalan: brauzer, mobil ilova, yoki fetch chaqirgan kod.
• Server (xizmatchi) — so'rovni qabul qilib, javob qaytaradi. Bu — doim ishlab turadigan kompyuter (sizning backend kodingiz).

   ┌──────────┐   1. so'rov (request)   ┌──────────┐
   │  CLIENT   │ ──────────────────────▶ │  SERVER   │
   │ (brauzer) │                          │ (backend) │
   │           │ ◀────────────────────── │           │
   └──────────┘   2. javob (response)    └──────────┘

Bu — so'rov–javob (request–response) sxemasi. Doim mijoz boshlaydi, server faqat javob beradi (HTTP'da; real-time aloqa — WebSocket esa boshqacha, 5.13-bob).

2.4. URL — manzil tuzilishi

URL (Uniform Resource Locator) — internetdagi resursning to'liq manzili. Uni qismlarga ajratamiz:

  https://api.example.com:443/users/42?role=admin#profil
  └─┬─┘   └──────┬──────┘└┬┘└──┬───┘└────┬───┘└──┬──┘
 scheme       host       port  path     query   fragment
 (protokol)  (domen)          (yo'l)  (parametr)(sahifa ichi)

2.5. DNS — domenni IP'ga aylantirish

Inson google.com ni eslaydi, lekin kompyuter IP manzil bilan ishlaydi 2.2-bob. DNS (Domain Name System) — domen nomini IP manzilga aylantiruvchi "internetning telefon kitobi".

DNS — ierarxik va dunyo bo'ylab tarqalgan tizim (Cloudflare hujjatlariga ko'ra). www.example.com ni qidirish bosqichlari:

  Brauzer: "www.example.com ning IP'si nima?"
        │
        ▼
  1) RECURSIVE RESOLVER (odatda internet provayder yoki 8.8.8.8)
        │   "Bilmayman, so'rab beraman"
        ▼
  2) ROOT server (13 ta global klaster):
        │   ".com larni TLD serveridan so'ra" →
        ▼
  3) TLD server (.com uchun):
        │   "example.com ning authoritative serveri falon" →
        ▼
  4) AUTHORITATIVE server (example.com egasiniki):
        │   "Mana IP: 93.184.216.34" ✓
        ▼
  Resolver javobni brauzerga qaytaradi (va CACHE'laydi)

Caching (keshlash) — bu jarayon sekin bo'lgani uchun, javob har bosqichda vaqtincha saqlanadi (resolver, OS, brauzer). Shuning uchun ikkinchi marta google.com ochsangiz, DNS deyarli bir zumda ishlaydi (0.1-bobdagi caching falsafasi — sekin qatlamga kam murojaat).

O'xshatish: siz do'stingizning ismini (google.com) bilasiz, lekin telefon raqamini (IP) bilmaysiz. Ma'lumot byurosiga (resolver) qo'ng'iroq qilasiz; ular bilmasa, kattaroq idoralardan (root → TLD → authoritative) so'rab, raqamni topib beradi. Keyin raqamni daftaringizga yozib qo'yasiz (cache) — keyingi safar so'rab o'tirmaysiz.

2.5.1. DNS yozuv turlari (DNS Records), TTL va DoH

Authoritative DNS serverda sizning domeningiz haqidagi ma'lumotlar turli yozuvlar (records) ko'rinishida saqlanadi. Har bir web dasturchi va DevOps bilishi shart bo'lgan asosiy turlar:

• TTL (Time To Live — yashash vaqti): Har bir DNS yozuvida soniyalarda ko'rsatilgan TTL qiymati bo'ladi (masalan TTL = 3600 ya'ni 1 soat). Bu resolver va brauzerga: "Shu ma'lumotni 1 soat keshda saqla, 1 soatdan keyin yana qaytadan tekshir", degan buyruqdir. Serveringiz IP'sini almashtirmoqchi bo'lsangiz, avval TTL ni kamaytirib (masalan 300 soniya) qo'yish kerak, aks holda eski kesh tufayli yangilanish butun dunyoga 24-48 soatda tarqaladi.
• DoH (DNS over HTTPS): An'anaviy DNS so'rovlari shifrlanmagan ochiq UDP (53-port) orqali ketadi — ya'ni internet provayderingiz yoki umumiy Wi-Fi'dagi odamlar siz qaysi saytlarga kirayotganingizni bemalol ko'rib turadi. DoH bu so'rovlarni standart HTTPS (443-port) ichiga o'rab yuboradi, natijada tashqi kuzatuvchilardan qaysi domenni qidirayotganingiz to'liq yashiriladi.

2.6. So'rovning to'liq sayohati (URL'dan ekrangacha)

Endi hammasini birlashtiramiz. https://example.com yozib Enter bosganingizda:

  1. DNS:  example.com → 93.184.216.34  2.5-bob
  2. TCP:  serverning 443-porti bilan ulanish o'rnatiladi (qo'l berish — handshake)
  3. TLS:  HTTPS bo'lgani uchun shifrlangan kanal yaratiladi 2.9-bob
  4. HTTP: brauzer so'rov yuboradi:  GET / HTTP/1.1 ...
  5. SERVER: so'rovni qayta ishlaydi (kod, DB) va javob qaytaradi
  6. HTTP javob: status (200) + headerlar + HTML body
  7. BROWSER: HTML'ni o'qib, qo'shimcha resurslarni (CSS, JS, rasm)
              yana so'rab oladi va sahifani chizadi (0.5-bob)

Mana shu 7 qadam — har bir sayt ochilganda sodir bo'ladi. Buni tushunsangiz, "internetni tushundingiz".

2-qadamga chuqurroq — TCP 3 bosqichli qo'l berish (3-way handshake): HTTP'dan oldin client va server ishonchli ulanish o'rnatishlari kerak. Bu TCP (Transmission Control Protocol) orqali, uch xabar almashinuvi bilan boradi:

  Client                                  Server
    │ ──────────── SYN ──────────────────▶ │   "Ulanmoqchiman" (sinxronlash)
    │ ◀──────── SYN + ACK ──────────────── │   "Mayli, men ham tayyorman"
    │ ──────────── ACK ──────────────────▶ │   "Kelishdik" → ulanish ochiq ✓

SYN (synchronize) va ACK (acknowledge) — bu paketlardagi maxsus bayroqlar. Uch qadamdan keyingina haqiqiy ma'lumot (TLS, so'ng HTTP) yuborila boshlaydi. TCP har bir paketni tartiblaydi va yo'qolganini qayta yuboradi — shuning uchun u ishonchli (reliable). (Tezroq, lekin ishonchsizroq alternativa — UDP; u video/o'yinlarda ishlatiladi va HTTP/3 ham unga tayanadi — 2.10.)

2.7. HTTP — vebning tili

HTTP (HyperText Transfer Protocol) — client va server o'rtasidagi so'rov–javob qoidalar to'plami (protokol). Uning ikki muhim xususiyati:

1. Matnga asoslangan (human-readable) — so'rov va javob, asosan, oddiy matn (0.1: matn ham baytlar).
2. Stateless (holatsiz) — har bir so'rov mustaqil; server oldingi so'rovni "eslamaydi". Shuning uchun "kim kirgani"ni eslab qolish uchun maxsus mexanizmlar kerak — cookie, token (5.15-bob).

So'rov (request) tuzilishi (MDN hujjatlariga ko'ra — start-line + headerlar + bo'sh qator + body):

  GET /users/42 HTTP/1.1          ← start-line: metod + path + versiya
  Host: api.example.com           ┐
  Accept: application/json        │ headerlar (metadata)
  Authorization: Bearer eyJ...    ┘
                                  ← bo'sh qator (header tugadi)
  (body — GET'da odatda bo'sh)    ← body (POST/PUT'da ma'lumot bo'ladi)

Javob (response) tuzilishi:

  HTTP/1.1 200 OK                 ← status-line: versiya + status kod + matn
  Content-Type: application/json  ┐
  Content-Length: 51              ┘ headerlar
                                  ← bo'sh qator
  {"id":42,"name":"Ali"}          ← body (ma'lumot)

2.7.1. Muhim HTTP sarlavhalari (headers) va Kesh mexanizmi (HTTP Caching)

HTTP sarlavhalari (headers) — so'rov va javob haqidagi muhim metama'lumotlarni uzatuvchi kalit-qiymat juftliklaridir:

Kesh mexanizmi: Cache-Control va ETag

Saytlarning tez ishlashi va serverga tushadigan yuklamani 80-90% gacha kamaytirishning kaliti — HTTP Caching:

1. Cache-Control sarlavhasi — server brauzerga resursni qanday keshlashtirishni buyuradi:

   • max-age=86400 — resursni 86400 sekund (1 kun) davomida keshda saqla va serverga murojaat qilmasdan darhol keshdan ko'rsat.
   • no-cache — fayl keshda tursin, lekin har safar ishlatishdan oldin serverdan "bu fayl eskirganmi?" deb tekshirib oling (validation).
   • no-store — bu ma'lumotni aslo keshga yozma (bank hisoblari, pasport ma'lumotlari, bir martalik kodlar).

2. Shartli so'rovlar (Conditional Requests) — ETag va 304 Not Modified:

   • Server resurs yuborayotganda uning barmoq izini (hash) sarlavhaga qo'shadi: ETag: "hash-4f8a1b".
   • Keyingi safar brauzer o'sha resursni so'raganda keshdagi xeshni taqqoslash uchun yuboradi: If-None-Match: "hash-4f8a1b".
   • Agar resurs o'zgarmagan bo'lsa, server katta hajmdagi faylni qaytadan yubormaydi; u atigi 1 ta bo'sh qatorli 304 Not Modified statusini qaytaradi. Brauzer esa o'z keshidagi faylni ishlatadi. Natijada megabaytlab trafik va sekundlar tejaladi!

Same-Origin Policy (SOP) va CORS nima?

Ko'p boshlovchilar CORS'ni backend xatosi deb o'ylaydi, ammo u — brauzerning asosiy xavfsizlik qalqonidir:

• Origin nima? Uchlik birligi: protokol + domen + port. Masalan, https://sayt.uz:443 va http://sayt.uz:80 (har xil protokol), yoki https://sayt.uz va https://api.sayt.uz (har xil subdomen) — boshqa origin hisoblanadi.
• SOP (Same-Origin Policy): Brauzer begona veb-saytdagi skriptga siz kirgan boshqa saytning ma'lumotlarini (masalan bank.uz/api/balans) o'qishni butunlay taqiqlaydi.
• CORS (Cross-Origin Resource Sharing): Agar server boshqa origin'dagi frontend ilovasiga ma'lumot berishni xohlasa, javob sarlavhasida aniq ruxsat beradi: Access-Control-Allow-Origin: https://mening-frontend.uz. Shunda brauzer so'rov natijasini JavaScript'ga o'qishga ruxsat etadi.

2.8. HTTP metodlari va status kodlari

Metod (HTTP verb) — so'rovning maqsadini bildiradi:

Idempotentlik (idempotent): metodni bir marta yoki yuz marta chaqirish — natija (server holati) bir xil bo'lsa, u idempotent. GET, PUT, DELETE — idempotent (o'sha postni 5 marta o'chirsangiz ham, oxiri "yo'q"). POST esa idempotent emas — har chaqiruv yangi yozuv yaratadi (shuning uchun to'lov tugmasini ikki marta bossangiz — ikki marta yechilishi mumkin). Bu tushuncha REST API dizaynida 5.7-bob markaziy.

Status kod — javobning natijasini bildiradi. 5 ta sinfga bo'linadi:

Eslab qolish kaliti: 4xx — "siz xato qildingiz" (mijoz: noto'g'ri so'rov, ruxsat yo'q, topilmadi). 5xx — "men (server) xato qildim" (serverda kod buzildi). Bu farq debug qilishda hayotingizni saqlaydi: 4xx bo'lsa — frontend/so'rovni tekshiring; 5xx bo'lsa — backend log'ini tekshiring.

2.9. HTTPS va TLS — xavfsiz aloqa

Oddiy HTTP — ma'lumot ochiq matn (plaintext) tarzida yuboriladi. Ya'ni orada turgan har kim (provayder, hacker) sizning parolingizni o'qiy oladi. HTTPS = HTTP + TLS (Transport Layer Security) shifrlash. URL'dagi s va qulf belgisi — shuni bildiradi.

TLS qanday ishlaydi (Cloudflare hujjatlariga ko'ra — TLS handshake)? Asosiy g'oya — ikki bosqichli shifrlash:

1. Asimmetrik shifrlash (sekin, lekin ishonchli) bilan boshlaydi — public key va private key juftligi. Public key bilan shifrlangan narsani faqat private key ochadi.
2. Server o'zining sertifikatini (ichida public key + ishonchli CA imzosi) yuboradi. Client uni tekshiradi: "Bu haqiqatan example.com mi? Ishonchli markaz (CA) tasdiqlaganmi? Muddati o'tmaganmi?"
3. Shu himoyalangan kanal orqali ikki tomon umumiy maxfiy kalit (session key) kelishadi.
4. Keyin butun suhbat simmetrik shifrlash bilan (tez) o'sha session key orqali boradi.

  Client                                    Server
    │ ── "Salom" (qo'llab-quvvatlanadigan ──▶ │
    │     shifrlash usullari, random)          │
    │ ◀── Sertifikat (public key + CA imzo) ── │
    │     + "Salom" (server random)            │
    │ ── premaster secret (public key bilan ─▶ │
    │     shifrlangan) ────────────────────    │
    │                                          │
    │ ═══ Endi ikkalasi session key yasadi ═══ │
    │ ═══ Butun suhbat SHIFRLANGAN boradi ════ │

O'xshatish: ikki notanish odam ochiq maydonda maxfiy gaplashmoqchi. Avval pasportlarini ko'rsatib (sertifikat + CA), bir-biriga ishonadi. Keyin faqat ikkisi biladigan "maxfiy til" (session key) ni kelishib oladi va undan keyin shu tilda gaplashadi — atrofdagilar eshitsa ham, tushunmaydi.

2.10. HTTP versiyalari: HTTP/1.1, HTTP/2, HTTP/3

HTTP — bir joyda qotib qolmagan; yillar davomida tezlashtirildi. Protokol bir xil ma'noni saqlaydi (metod, status, header), lekin "simdan" qanday o'tishi o'zgardi:

Multiplexing — HTTP/1.1'da brauzer bir vaqtda atigi bir nechta ulanish ochib, so'rovlarni navbat bilan yuborardi. HTTP/2 esa bitta ulanishda o'nlab so'rovni bir vaqtda, aralash bo'laklar (stream) sifatida yuboradi — sahifa sezilarli tezroq yuklanadi.

HTTP/3 va QUIC — eng yangi qadam. TCP'ning kamchiligi: paket yo'qolsa, hatto mustaqil so'rovlar ham kutib qoladi (transport darajasidagi head-of-line blocking). QUIC protokoli UDP ustiga qurilgan bo'lib, har bir stream'ni mustaqil boshqaradi va TLS shifrlashni o'z ichiga oladi — ulanish o'rnatish tezroq. Bugun Google, Cloudflare kabi yirik servislar HTTP/3'ni qo'llab-quvvatlaydi.

Amaliyotda: versiyani odatda brauzer va server avtomatik kelishadi (ALPN orqali TLS handshake paytida) — siz kod yozayotganda bevosita tanlamaysiz. DevTools'ning Network tab'ida har so'rovning Protocol ustunida h2, h3 yoki http/1.1 ko'rinadi.

2.11. Real-time ma'lumot almashinuvi: Polling vs SSE vs WebSocket

Standart HTTP faqat "Mijoz so'raydi → Server javob beradi" qoidasi bilan ishlaydi. Lekin real vaqt rejimida (chat, birja narxlari, jonli bildirishnomalar) server o'z tashabbusi bilan ma'lumot yuborishi kerak. Bunga 3 xil usul bor:

2.12. CDN (Content Delivery Network) va Cloudflare — internetning tezlatkichi

Agar serveringiz Toshkentda joylashgan bo'lsa, Amerikadagi foydalanuvchi saytingizni ochganda har bir rasm va JS fayl okean ortidan 200ms kechikish bilan boradi. Buning yechimi — CDN:

1. Global kesh: Dunyo bo'ylab yuzlab oraliq serverlar (Edge server) o'rnatilgan.
2. Eng yaqin nuqta: O'quvchi saytingizga kirganda statik fayllar (rasm, CSS, JS) unga eng yaqin turgan shahardagi CDN serveridan uzatiladi.
3. DDoS va xavfsizlik: Cloudflare kabi yirik CDN provayderlari botlar, xakerlik hujumlari va millionlab soxta so'rovlarni o'zida yutib yuborib, sizning asosiy serveringizni himoya qiladi.

3. Sintaksis va asosiy belgilanishlar

Status kod oralig'ini yodlash:

2xx → ✅ bo'ldi          (200 OK, 201 Created)
3xx → ↪️ boshqa joyga    (301, 302, 304)
4xx → ❌ SIZ xato qildingiz (400, 401, 403, 404, 429)
5xx → 🔥 SERVER yiqildi   (500, 502, 503)

Xom HTTP so'rovi (raw) ko'rinishi:

POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json

{"email":"ali@mail.uz","password":"123"}

Javob:

HTTP/1.1 200 OK
Content-Type: application/json

{"token":"eyJhbGciOi..."}

4. Batafsil kod namunalari

So'rovlarni terminaldan (curl — 0.3) va JavaScript'dan (fetch) yuborib ko'ramiz.

Misol 1 — curl bilan so'rov (terminal)

# Oddiy GET — javob bodysini ko'rsatadi
curl https://api.github.com/users/torvalds

# -i: javob HEADERLARINI ham ko'rsatadi (status kod, Content-Type...)
curl -i https://api.github.com

# -X bilan metodni, -H bilan header, -d bilan body yuborish (POST)
curl -X POST https://example.com/api/login \
  -H "Content-Type: application/json" \
  -d '{"email":"ali@mail.uz","password":"123"}'

# -v: "verbose" — DNS, TLS, so'rov/javob — butun sayohatni ko'rsatadi (2.6!)
curl -v https://example.com

Misol 2 — fetch bilan GET (JavaScript)

// fetch — brauzer va zamonaviy Node'da mavjud so'rov yuborish API'si.
// U Promise qaytaradi (2.11-bobda chuqur), shuning uchun await ishlatamiz.
async function userOl() {
  // 1) so'rov yuboramiz va javobni (response obyekti) kutamiz
  const response = await fetch("https://api.github.com/users/torvalds");

  // 2) status kodni tekshiramiz 2.8-bob — fetch 404/500'da ham "muvaffaqiyat"
  //    deb hisoblaydi, shuning uchun QO'LDA tekshirish SHART!
  if (!response.ok) {
    // response.ok — status 200–299 oralig'ida bo'lsa true
    throw new Error(`Server xatosi: ${response.status}`);
  }

  // 3) javob bodysini JSON sifatida o'qiymiz (bu ham Promise)
  const data = await response.json();
  console.log(data.name); // "Linus Torvalds"
}

userOl();

Misol 3 — fetch bilan POST (ma'lumot yuborish)

async function login(email, password) {
  const response = await fetch("https://example.com/api/login", {
    method: "POST",                          // metod (2.8)
    headers: {
      "Content-Type": "application/json",    // body turi — JSON yuboryapmiz
    },
    body: JSON.stringify({ email, password }), // obyektni JSON MATNGA o'giramiz
  });

  if (!response.ok) {
    // 401 bo'lsa — parol noto'g'ri; 400 — so'rov noto'g'ri (2.8)
    throw new Error(`Kirish muvaffaqiyatsiz: ${response.status}`);
  }

  const { token } = await response.json(); // javobdan token'ni olamiz
  return token;
}

Misol 4 — URL'ni qismlarga ajratish (URL API)

// URL obyekti — URL'ni avtomatik qismlarga ajratadi (2.4)
const url = new URL("https://api.example.com:443/users/42?role=admin#top");

console.log(url.protocol);  // "https:"
console.log(url.hostname);  // "api.example.com"
console.log(url.pathname);  // "/users/42"
console.log(url.searchParams.get("role")); // "admin"  ← query parametri
console.log(url.hash);      // "#top"  ← fragment

Misol 5 — Terminaldan API sinash: curl va httpie

Dasturchi har doim brauzer ochib o'tirmaydi; backend va API'larni to'g'ridan-to'g'ri terminaldan tekshiradi:

# 1. curl bilan oddiy GET so'rov (0.3 terminal)
curl -i https://jsonplaceholder.typicode.com/posts/1
# -i flagi HTTP status va barcha sarlavhalarni (headers) ham ko'rsatadi

# 2. curl bilan JSON POST so'rovi yuborish:
curl -X POST https://api.example.com/login \
  -H "Content-Type: application/json" \
  -d '{"email":"ali@mail.uz","password":"secret"}'

# 3. HTTPie (juda qulay va rangli zamonaviy muqobil — pip install httpie):
http GET https://api.example.com/users Authorization:"Bearer my-token"
http POST https://api.example.com/products title="Noutbuk" price:=1200

5. To'g'ri va noto'g'ri holatlar

1) fetch da status kodni tekshirmaslik

// ❌ NOTO'G'RI — fetch 404/500'da ham xato TASHLAMAYDI
const res = await fetch("/api/user");
const data = await res.json(); // 404 bo'lsa, bu yerda kutilmagan xato

// ✅ TO'G'RI — avval response.ok ni tekshiring (2.8)
const res2 = await fetch("/api/user");
if (!res2.ok) throw new Error(`HTTP ${res2.status}`);
const data2 = await res2.json();

2) Metodni noto'g'ri tanlash

❌ GET so'rovi bilan ma'lumot o'chirish (GET — faqat o'qish bo'lishi kerak)
❌ POST bilan shunchaki ma'lumot olish
✅ Olish→GET, Yaratish→POST, Almashtirish→PUT, Qisman→PATCH, O'chirish→DELETE

Nega: GET idempotent va xavfsiz bo'lishi kerak (qayta-qayta chaqirsa ham hech narsani o'zgartirmaydi). Brauzer/proxy GET'larni keshlaydi — agar GET o'chirib yuborsa, falokat bo'ladi.

3) Maxfiy ma'lumotni URL query'da yuborish

❌ https://site.com/login?password=123    (URL log'larga, tarixga yoziladi!)
✅ Parolni POST so'rovining BODY qismida (va HTTPS orqali) yuborish

4) HTTP (s'siz) orqali parol/token yuborish

❌ http://site.com/login   — ochiq matn, har kim o'qiydi 2.9-bob
✅ https://site.com/login  — TLS bilan shifrlangan

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — 404 Not Found

Sababi: so'ralgan resurs (URL/endpoint) serverda yo'q. Ko'pincha — noto'g'ri path yoki imlo xatosi. Yechimi: URL'ni va backend route'ini solishtiring; /users mi /user mi.

Xato 2 — 500 Internal Server Error

Sababi: server kodida xato yuz berdi (4xx emas, 5xx — bu sizniki!). Yechimi: frontend'ni emas, server log'ini o'qing (5.12 Logger). Eng ko'p sabab — backend'da ushlanmagan exception 5.10-bob.

Xato 3 — CORS xatosi

Access to fetch at 'https://api.x.com' from origin 'https://site.com'
has been blocked by CORS policy

Sababi: brauzer xavfsizlik qoidasi — bir domendan boshqa domen API'siga so'rov, agar server ruxsat bermasa, bloklanadi. Yechimi: server tomonida CORS sozlash (Access-Control-Allow-Origin header). Bu — 5.20 va 14-boblarda chuqur. (Diqqat: bu server muammosi, frontend hiylasi bilan hal qilinmaydi.)

Xato 4 — ERR_NAME_NOT_RESOLVED / DNS_PROBE_FINISHED_NXDOMAIN

Sababi: DNS domenni IP'ga aylantira olmadi 2.5-bob — domen xato, yoki ro'yxatdan o'tmagan, yoki DNS muammosi. Yechimi: domen imlosini tekshiring; nslookup domen.com yoki ping domen.com bilan DNS ishlayotganini sinang.

Xato 5 — ERR_CONNECTION_REFUSED

Sababi: server o'sha portda ishlamayapti 2.2-bob. Lokal'da eng ko'p — localhost:3000 ga so'rov, lekin server ishga tushmagan. Yechimi: server ishga tushganini va to'g'ri portda ekanini tekshiring (0.2: EADDRINUSE ni ham eslang).

Xato 6 — Mixed Content

Sababi: HTTPS sahifa ichidan HTTP (s'siz) resurs yuklanmoqchi — brauzer bloklaydi. Yechimi: barcha resurslarni https:// orqali yuklang.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

• HTTP server & Express (5.5, 5.6): backend — aslida HTTP so'rovlarni qabul qilib, javob qaytaradigan dastur.
• REST API dizayni 5.7-bob: metodlar 2.8-bob va status kodlarni to'g'ri ishlatish — REST'ning o'zagi.
• fetch / Axios (2.17, 2.18): frontend so'rov yuborishning amaliy vositalari.
• Autentifikatsiya 5.15-bob: stateless HTTP 2.7-bob tufayli cookie/JWT kerak; Authorization header.
• CORS, helmet, rate limiting (5.20, 14.4): brauzer xavfsizlik qoidalari va himoya.
• HTTPS / SSL, Nginx, deploy (10.2, 10.7): TLS sertifikat 2.9-bob o'rnatish, domen sozlash.
• DNS 10.7-bob: domeningizni serveringizga ulash — aynan 2.5-dagi tizim.
• Brauzer rendering 0.5-bob: 2.6-dagi 7-qadam (HTML'ni chizish) — keyingi bob.
• GraphQL, WebSocket (8.17, 5.13): HTTP ustiga qurilgan yoki uning alternativalari.

8. Eng yaxshi amaliyotlar (best practices)

• To'g'ri metod va status kodni ishlating. GET o'qiydi, POST yaratadi; 201 yaratilganda, 204 bo'sh javobda, 400/401/403/404 aniq xato sababida.
• Doim HTTPS. Hech qachon parol/token'ni HTTP orqali yubormang.
• fetch da response.ok ni doim tekshiring. U xato status'da o'zi tashlanmaydi.
• Maxfiy ma'lumotni body'da (va header'da), URL query'da emas. URL — log'larga tushadi.
• 4xx/5xx farqini debug'da ishlating. 4xx → so'rovni; 5xx → server log'ini tekshiring.
• DevTools'ning Network tab'idan foydalaning. Har bir so'rov, status, header, vaqtni ko'rsatadi — eng kuchli o'rganish vositasi (0.5-bobda).
• API'ngizni stateless dizaynlang. Har so'rov o'zini-o'zi ta'minlasin (token bilan).
• Status kodlarni qo'lda yodlamang — MDN'ni ochib qarang (15.6 hujjat o'qish ko'nikmasi).

9. Amaliy loyiha: "HTTP Detektivi"

So'rov–javob mexanizmini o'z ko'zingiz bilan ko'rish loyihasi. Kod kam, kuzatuv ko'p — maqsad nazariyani real hayotga bog'lash.

Maqsad

Brauzer DevTools va curl yordamida real saytlarning HTTP "suhbatlarini" tekshirish va hujjatlash; so'ng kichik bir "so'rov tahlilchi" yozish.

Talablar (requirements)

A — kuzatuv (DevTools + curl):

1. Brauzerda istalgan sayt oching → F12 → Network tab → sahifani yangilang. Birinchi (HTML) so'rovni toping va yozing: status kod, metod, Content-Type, javob hajmi.
2. O'sha sahifa nechta so'rov yuborganini sanang (CSS, JS, rasm — 2.6-dagi 7-qadam). Eng katta 3 resursni yozing.
3. Terminalda curl -v https://example.com ishlating va chiqishdan DNS, TLS handshake va so'rov/javob qismlarini ajratib ko'rsating (2.6, 2.9).
4. Bir nechta saytdan turli status kodlar topib hujjatlang: 200, 301/302, 404. (curl -i <url> qulay.)

B — kichik kod (so'rov tahlilchi): 5. fetch bilan ochiq API'dan (masalan https://api.github.com/users/<ism>) ma'lumot oling. 6. response.ok va response.status ni tekshiring; xato bo'lsa tushunarli xabar chiqaring (5-bo'lim). 7. Foydalanuvchining name, public_repos, followers ni chiroyli chiqaring. 8. (Bonus) Mavjud bo'lmagan foydalanuvchi (/users/bunaqaodamyoq123) so'rab, 404 ni qanday ushlashni ko'rsating.

Maslahatlar (hint)

• DevTools Network'da har so'rovga bossangiz — Headers, Response, Timing'ni ko'rasiz.
• curl -v da * bilan boshlangan qatorlar — ulanish/TLS; > — sizning so'rovingiz; < — server javobi.
• fetch Promise qaytaradi → async/await ishlating (2.11-bobda to'liq, hozir misol 2 yetarli).
• Status kod oralig'iga qarab xabar bering: 2xx→ok, 4xx→"so'rov xato", 5xx→"server xato".

"Tayyor" mezonlari (acceptance criteria)

• Bitta sahifa uchun: status, metod, Content-Type, so'rovlar soni hujjatlangan.
• curl -v chiqishida DNS/TLS/so'rov/javob qismlari ajratib ko'rsatilgan.
• Kamida 200, 3xx, 404 status kodlari real misolda topilgan.
• fetch kodi ishlaydi va response.ok ni tekshiradi.
• Mavjud bo'lmagan foydalanuvchida 404 to'g'ri ushlanadi, dastur qulamaydi.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda kompyuterlar bir-biri bilan qanday gaplashishini o'rgandik:

• Internet — tarmoqlar tarmog'i; ma'lumot paketlarda yuboriladi. Har kompyuterning IP manzili, har xizmatning porti bor.
• Client–server: mijoz so'rov yuboradi, server javob qaytaradi. URL — resurs manzili (scheme, host, port, path, query).
• DNS domen nomini IP'ga aylantiradi (root → TLD → authoritative, + caching).
• TCP — ishonchli ulanish; 3 bosqichli qo'l berish (SYN → SYN+ACK → ACK) bilan boshlanadi.
• HTTP — stateless so'rov–javob protokoli. So'rov/javob = start-line + headerlar + body. Metodlar (GET/POST/PUT/PATCH/DELETE/OPTIONS) maqsadni, status kodlar (2xx, 3xx↪, 4xxsiz, 5xxserver) natijani bildiradi. GET/PUT/DELETE — idempotent, POST — yo'q.
• HTTPS = HTTP + TLS — asimmetrik bilan kelishib, simmetrik bilan shifrlangan xavfsiz kanal; sertifikat server haqiqiyligini isbotlaydi.
• HTTP versiyalari: 1.1 (navbat) → 2 (multiplexing) → 3 (QUIC/UDP) — bir xil ma'no, tobora tez transport.

Keyingi bob — 0.5-bob: Brauzer qanday ishlaydi (rendering, JS engine). Server javob qaytardi (2.6-dagi 6-qadam); endi brauzer o'sha HTML/CSS/JS'ni qanday qilib chiroyli sahifaga aylantiradi (7-qadam) — buni ochamiz. Bu — frontend (11-QISM) va performance 11.11-bob uchun zarur poydevor.

Foydalanilgan rasmiy/ishonchli manbalar

• MDN Web Docs — HTTP messages, methods, status codes
• Cloudflare Learning Center — DNS server turlari, TLS handshake
• IETF RFC 9110/9112 (HTTP semantikasi) — protokol asoslari