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

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.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.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.

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

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
 OlishGET, YaratishPOST, AlmashtirishPUT, QismanPATCH, O'chirishDELETE

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)
 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'zing 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: 2xxok, 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