WhatsApp qanday ishlaydi

Bu darsda nima o‘rganasiz

Slack darsida biz server qanday qilib mijozga o‘zi gapirishini o‘rgandik. U yerda bitta jimgina faraz bor edi: mijoz ulangan. Noutbuk ish kuni davomida ochiq turadi, Wi-Fi barqaror, batareya muammo emas.

WhatsApp bu farazni buzadi. Uning mijozi — telefon, va telefon ko‘p vaqt oflayn: cho‘ntakda, metroda, samolyotda, batareyani tejash rejimida, operatsion tizim ilovani fonda o‘ldirgan holatda. Xabar yuborilgan paytda qabul qiluvchi deyarli hech qachon “shu yerda” emas. Demak savol o‘zgaradi: xabarni u yetib bora olmaydigan odamga qanday yetkazasiz?

Ikkinchi, undan ham chuqurroq o‘zgarish: WhatsApp serveri xabarni o‘qiy olmaydi. Uchidan-uchiga shifrlash (E2EE) tufayli server faqat shifrlangan baytlarni tashiydi. Bu bitta qaror arxitekturaning deyarli hamma qismiga ta’sir qiladi: guruhlar, ko‘p qurilma, push bildirishnomalar, zaxira nusxa, spam bilan kurash, hatto kuzatuv — hammasi “server hech narsani bilmaydi” degan cheklov ichida qurilishi kerak.

Yo‘l shunday: avval shifrlashning o‘zini noldan — kichik sonlar bilan qo‘lda hisoblab — tushunamiz. Keyin nega qabul qiluvchi oflayn bo‘lganda oddiy kalit almashinuvi ishlamasligini va Signal protokoli buni qanday hal qilishini ko‘ramiz. So‘ng “saqla va uzat” (store-and-forward) navbati, uch xil belgi (✓, ✓✓, ko‘k ✓✓), guruhlardagi kvadratik tuzoq, ko‘p qurilma, va nihoyat iqtisod: nega WhatsApp tarixan juda kichik jamoa bilan juda katta tizimni boshqara olgan.

Dars Slack darsidan keyin o‘qish uchun mo‘ljallangan — doimiy ulanish, jitter va quvib yetish u yerda tushuntirilgan va bu yerda faqat eslatiladi. Kriptografiya bo‘yicha oldindan bilim shart emas: hamma narsa maktab matematikasidan boshlanadi.

1. Muammo: aslida nimani qurmoqchimiz?

1.1 Funksional talablar

Bu jadvalda Slack’da bo‘lgan ikki narsa yo‘q: serverdagi qidiruv va serverdagi tarix. Bu tasodif emas. Server xabarni o‘qiy olmasa, uni indekslay olmaydi; server xabarni yetkazib bo‘lgach o‘chirsa, tarix faqat telefonda qoladi. Demak E2EE talabi funksiyalar ro‘yxatini ham qisqartiradi — va 12-bo‘limda ko‘ramizki, aynan shu qisqarish WhatsApp’ni juda arzon qiladi.

1.2 Nofunksional talablar

To‘rtinchi qatorni qayta o‘qing, chunki u butun darsning eng qat’iy talabi: “serverdan to‘liq ma’lumot sizib chiqsa ham”. Bu odatiy xavfsizlik talabidan tubdan farq qiladi. Odatda biz “serverni buzib bo‘lmasin” deymiz; bu yerda esa “server buzilgan deb faraz qilamiz, va baribir mazmun xavfsiz”. Bu talab kalitlar faqat qurilmalarda yashashini majburlaydi.

Oxirgi ikki qator ham e’tiborga loyiq: ular Slack’da umuman bo‘lmagan. WhatsApp’ning asosiy auditoriyasi — rivojlanayotgan mamlakatlar, arzon telefonlar, qimmat va sekin mobil internet. Har bir bayt va har bir uyg‘onish (radio yoqilishi) mahsulot talabi, optimallashtirish emas.

1.3 Konvert orqasidagi hisob

Bu hisobning xulosasi kutilmagan: xabarlarning o‘zi trafikning kichik qismi. Asosiy yuk — belgilar, ya’ni “yetib keldi” va “o‘qildi” degan kichkina signallar. Guruhlarda bu ayniqsa keskin: bitta xabar 58 ta hodisa yaratadi va ulardan 38 tasi faqat yuboruvchiga “kim ko‘rdi” degan ma’lumotni qaytaradi.

Bu Slack darsidagi presence xulosasining qarindoshi: mahsulotning eng kichik ko‘rinadigan qismi eng katta trafikni yaratadi. 5-bo‘limda belgilarni qanday arzonlashtirishni ko‘ramiz (guruhlash, kechiktirish, kattalashtirish) va 7-bo‘limda guruhlar uchun bu nega hal qiluvchi.

2. Nol nuqta: server o‘qiy olmaydigan xabar

Bu bo‘lim darsning poydevori va eng uzuni. Arxitektura haqida gapirishdan oldin bitta savolga to‘liq javob kerak: ikki telefon qanday qilib umumiy sirni kelishib oladi, agar ular orasidagi har bir baytni (jumladan, kelishuvning o‘zini) server ko‘rib tursa?

2.1 Simmetrik shifrlash: kalit bor, lekin uni qanday uzatasiz

Eng oddiy shifrlash — simmetrik: bitta kalit bilan shifrlanadi, xuddi shu kalit bilan ochiladi. AES shunday ishlaydi. U juda tez (zamonaviy protsessorda sekundiga gigabaytlar) va juda ishonchli.

Anvar:  shifr = AES(kalit, "salom")      -> 3f9a1c...
Server: 3f9a1c...  (o'qiy olmaydi — kalit yo'q)
Bekzod: AES_ochish(kalit, 3f9a1c...)     -> "salom"

Muammo bitta, va u butun sohaning markaziy muammosi: kalitni Bekzodga qanday yetkazasiz? Agar uni server orqali yuborsangiz, server kalitni ko‘radi va hamma narsani o‘qiydi. Agar uni oldindan kelishib olsangiz (uchrashib, qog‘ozda) — 2 milliard foydalanuvchi uchun bu imkonsiz.

Bu muammo 1976-yilgacha yechimsiz deb hisoblangan. Yechim ajoyib darajada sodda matematikaga asoslangan.

2.2 Diffie–Hellman: ochiq kanalda umumiy sir

G‘oya: ikki tomon ochiq sonlarni almashadi, lekin har biri o‘zining yashirin soni bilan ularni shunday qayta ishlaydiki, natijada ikkalasida bir xil son chiqadi — kuzatuvchida esa chiqmaydi.

Kichik sonlar bilan, qo‘lda:

Nega ikkalasida bir xil chiqdi? Chunki (g^b)^a = g^(ab) = (g^a)^b. Daraja ko‘paytmasi tartibga bog‘liq emas. Anvar a ni, Bekzod b ni biladi, va har biri boshqasining ochiq sonini o‘z yashirin darajasiga ko‘taradi.

Nega server topa olmaydi? Chunki 8 dan 6 ni topish — ya’ni “5 ni nechanchi darajaga ko‘tarsam, 23 ga bo‘lgandagi qoldiq 8 bo‘ladi” degan savol — kichik sonlar uchun oson (22 ta variantni sinab ko‘rasiz), lekin katta sonlar uchun ma’lum usullarning hech biri amaliy vaqtda yecha olmaydi.

Mana shu ikki Calc — shifrlashning butun g‘oyasi. Qolgan hamma narsa (X3DH, Double Ratchet, Sender Keys) shu bitta almashinuvni turli cheklovlar ostida — oflayn qabul qiluvchi, ko‘p qurilma, guruh — qanday qo‘llash haqida.

2.3 Oflayn qabul qiluvchi: nega oddiy DH ishlamaydi

Diffie–Hellman ikki tomonning ham qatnashishini talab qiladi: Anvar A ni yuboradi, Bekzod B ni qaytaradi, shundan keyingina umumiy sir paydo bo‘ladi. Bu bir aylanma (round trip).

WhatsApp’da esa Anvar birinchi xabarini yozayotganda Bekzodning telefoni o‘chiq. Bekzod B ni qaytara olmaydi. Anvar esa kutib o‘tirmasligi kerak: u “salom” yozadi va darhol ✓ ni ko‘rishni xohlaydi.

Yechim — oldindan tayyorlangan kalitlar (prekeys). Bekzod ro‘yxatdan o‘tganda (yoki ilova ochilganda) o‘zining ochiq DH yarimlaridan bir to‘plamini oldindan serverga yuklab qo‘yadi. Anvar Bekzodga yozmoqchi bo‘lganda serverdan shulardan birini oladi va Bekzodsiz DH ning o‘z qismini bajaradi.

Bekzod ro'yxatdan o'tganda serverga yuklaydi:
  IK_B       — identifikatsiya kaliti (doimiy, ochiq qismi)
  SPK_B      — imzolangan prekey (haftada bir almashadi) + IK_B bilan imzo
  OPK_B[1..100] — bir martalik prekey'lar (har biri bir marta ishlatiladi)

Anvar birinchi xabarni yuborganda:
  1. Serverdan so'raydi: "Bekzodning kalit to'plamini ber"
  2. Server beradi: IK_B, SPK_B, imzo, OPK_B[37]  (va 37-ni o'chiradi)
  3. Anvar imzoni tekshiradi (SPK_B haqiqatan Bekzodnikimi?)
  4. Anvar vaqtinchalik kalit yaratadi: EK_A
  5. Anvar 3-4 ta DH hisoblaydi (X3DH) -> umumiy sir SK
  6. SK dan xabar kaliti chiqaradi, "salom" ni shifrlaydi
  7. Serverga yuboradi: [IK_A, EK_A, "37-prekey ishlatildi", shifr]

Bekzod ertasi kuni telefonini yoqqanda:
  8. Xabarni oladi, o'zining yashirin kalitlari bilan xuddi shu DH'larni
     hisoblaydi -> xuddi shu SK -> xabarni ochadi
  9. OPK_B[37] ning yashirin qismini O'CHIRADI

Bu sxemaning nomi — X3DH (Extended Triple Diffie–Hellman). “Uchlik”, chunki kamida uchta DH hisoblanadi, va har biri boshqa kafolatni beradi.

Jadvaldan asosiy xulosa: har bir DH juftligi bitta xavfni yopadi, va ulardan birortasini olib tashlash bitta aniq hujumni ochadi. Birinchi ikkitasi autentifikatsiya (kim bilan gaplashyapman), qolgan ikkitasi kelajak va o‘tmishni himoya qilish. To‘rtinchisi esa ixtiyoriy — agar Bekzodning bir martalik kalitlari tugab qolsa, X3DH usiz ham ishlaydi, faqat biroz kuchsizroq kafolat bilan. 5-bo‘limning 6-qadamida bu “tugab qolish” qanchalik tez bo‘lishini hisoblaymiz.

2.4 Double Ratchet: har bir xabar — yangi kalit

X3DH bitta umumiy sir beradi. Endi savol: barcha keyingi xabarlarni shu bitta kalit bilan shifrlaymizmi?

Yo‘q, va sababi — telefon o‘g‘irlanishi. Agar bitta kalit butun suhbatni ochsa, o‘g‘ri telefondan kalitni olib, serverda (yoki tarmoqni yozib olgan kishida) saqlangan barcha eski shifrlangan xabarlarni ochadi. Buni oldini olish uchun kalit har xabarda o‘zgarishi va eski kalitlar o‘chirilishi kerak.

Double Ratchet (“ikki tomonlama tishli g‘ildirak”) buni ikki mexanizm bilan bajaradi:

1) SIMMETRIK G'ILDIRAK (har bir xabarda):
   zanjir_kaliti[n+1] = HMAC(zanjir_kaliti[n], 0x02)
   xabar_kaliti[n]    = HMAC(zanjir_kaliti[n], 0x01)
   -> xabar shifrlanadi, xabar_kaliti[n] va zanjir_kaliti[n] O'CHIRILADI

   HMAC bir tomonlama: [n+1] dan [n] ni tiklab bo'lmaydi.
   Demak bugungi kalitni o'g'irlagan odam kechagi xabarni ocholmaydi.

2) DH G'ILDIRAGI (har javobda):
   Har safar tomon almashganda (Anvar yozdi -> Bekzod javob berdi)
   javob beruvchi YANGI vaqtinchalik DH kalit yaratadi va uni xabarga qo'shadi.
   Yangi DH natijasi zanjirga aralashtiriladi.

   Demak hujumchi hozirgi holatni o'g'irlasa ham, keyingi
   DH almashinuvidan keyin u yana "ko'r" bo'lib qoladi.

Bu ikki kafolat bir-birining teskarisi: biri o‘tmishni, ikkinchisi kelajakni himoya qiladi. Ular birgalikda “kalit o‘g‘irlanishining zarari vaqt bo‘yicha cheklangan” degan xossani beradi — hujumchi faqat o‘g‘irlik va keyingi DH almashinuvi orasidagi oynani o‘qiy oladi.

Xulosa: kriptografiya arzon. Kuniga 10 millisekund CPU va bir yarim kilobayt trafik — bu ekranni bir marta yoqishdan ham kam. Shuning uchun E2EE ning narxi hisoblashda emas, arxitekturada: server endi yordamchi bo‘la olmaydi, va har bir funksiya shu cheklov bilan qayta o‘ylanishi kerak.

3. v0: eng sodda ishlaydigan yechim

Shifrlashsiz, bitta server, oddiy jadval. Bu — WhatsApp’ning ilk versiyalariga yaqin model (u paytda XMPP protokoli asosida qurilgan edi) va u haqiqatan ishlaydi.

# Xabar navbati — yetkazilmaguncha shu yerda yotadi
# CREATE TABLE inbox (to_user, msg_id, from_user, body, created_at)

def send(from_user, to_user, body):
    msg_id = uuid4()
    db.insert("inbox", to_user, msg_id, from_user, body, now())
    if to_user in online:
        online[to_user].push({"id": msg_id, "from": from_user, "body": body})
    return {"ok": True}

def on_connect(user):
    online[user] = connection
    for m in db.select("inbox", to_user=user, order="created_at"):
        connection.push(m)

def on_ack(user, msg_id):
    db.delete("inbox", to_user=user, msg_id=msg_id)   # yetkazildi -> o'chirildi

Uchta muhim xususiyatga e’tibor bering, chunki ular oxirigacha saqlanadi.

Birinchi — server tarix saqlamaydi. Xabar yetkazilgan zahoti o‘chiriladi. Server — pochta qutisi emas, pochtachi. Bu Slack’dan tubdan farq qiladi: u yerda tarix haqiqat manbai edi (Slack, 5.3-qadam), bu yerda haqiqat manbai — telefonlar.

Ikkinchi — navbat qabul qiluvchi bo‘yicha. Slack darsida biz “foydalanuvchi bo‘yicha navbat — antinaqsh” degan edik (Slack, 14-bo‘lim). Bu yerda esa u to‘g‘ri yechim, chunki tarix yo‘q: quvib yetadigan kanal tarixi mavjud emas, demak navbat — xabarning yagona joyi.

Uchinchi — o‘chirish tasdiqqa bog‘langan (on_ack). Xabar faqat telefon “oldim” degandan keyin o‘chiriladi. Bu “kamida bir marta yetkazish” ning eng sodda amalga oshirilishi.

Nima yetishmaydi — keyingi bo‘lim.

4. Nima sindi

4.1 Server hamma narsani o‘qiydi

v0 da xabar serverda ochiq matn sifatida yotadi — yetkazilguncha. Bu qancha xabar?

Bu raqamdagi muhim so‘z — “istalgan paytda”. Server tarix saqlamasa ham, u doim milliardlab xabarni ushlab turadi, chunki odamlar doim oflayn. Va agar xabar ochiq bo‘lsa, bitta xato (noto‘g‘ri sozlangan zaxira, ichki xodim, hukumat so‘rovi) milliardlab shaxsiy yozishmani ochadi.

“Tarix saqlamaymiz” degan va’da maxfiylik uchun yetarli emas. Faqat shifrlash yetarli.

4.2 Matnli protokol 2G uchun juda og‘ir

XMPP — XML asosidagi protokol. Bitta xabar shunday ko‘rinadi:

<message to="998901234567@s.whatsapp.net" id="3EB0C4A1F2" type="chat"
         from="998907654321@s.whatsapp.net" t="1700000000">
  <body>salom</body>
</message>

4.3 Doimiy ulanish batareyani yeydi

Slack’da ulanishni ping bilan tirik saqlash arzon edi: noutbuk rozetkada. Telefonda esa har bir paket radioni uyg‘otadi, va radio uyg‘ongandan keyin darhol uxlamaydi.

Bu hisob WhatsApp dizaynining eng muhim tashqi cheklovini tushuntiradi: telefonda ilova o‘z ulanishini fonda ushlab tura olmaydi. Operatsion tizimlar (iOS va Android) buni aynan shu sababli taqiqlaydi yoki qattiq cheklaydi, va o‘rniga bitta umumiy ulanish taklif qiladi — push bildirishnomalar xizmati. Barcha ilovalar uchun bitta ping, bitta dum. 6-bo‘limda bu qarorning butun arxitekturaga ta’sirini ko‘ramiz.

4.4 “Yetkazildi” — lekin kimga, qachon?

v0 da yuboruvchi bitta narsani biladi: {"ok": True}, ya’ni server xabarni qabul qildi. Qabul qiluvchi oldimi? O‘qidimi? Noma’lum.

Va yana bir muammo: agar yuboruvchi javob olmasa (tarmoq uzildi) va xabarni qayta yuborsa, send yangi msg_id yaratadi — qabul qiluvchi ikki marta “salom” oladi.

Ikkala muammo ham bir joydan kelib chiqadi: xabar identifikatorini server yaratyapti. Yuboruvchi qayta uringanda o‘zining oldingi urinishini tanitib bera olmaydi. Slack darsidagi client_msg_id bilan bir xil yechim kerak (Slack, 5.6-qadam), va bu yerda u yanada muhim, chunki mobil tarmoqda qayta urinish — odatiy holat, istisno emas.

4.5 Navbat — eng qimmat ma’lumotlar bazasi yuki

inbox jadvali oddiy ko‘rinadi, lekin uning ish rejimi ma’lumotlar bazasi uchun eng yomon rejimlardan biri.

Bu bo‘limning xulosasi: navbat ma’lumotlar bazasi emas. Uning ish rejimi — deyarli hamma narsa qisqa umr ko‘radi, lekin ba’zilari juda uzoq — umumiy maqsadli bazalar uchun qulay emas. 5-bo‘limning 10-qadamida navbatni ikki qatlamga bo‘lamiz: tez (xotirada, millisekundlik umr uchun) va bardoshli (diskda, soatlik va kunlik kutish uchun).

5. Evolyutsiya: o‘n to‘rt qadam

Lug'at (ikkala tomonda ham, ilova bilan birga keladi):
  0x13 = "message"   0x2A = "to"   0x1F = "from"
  0x44 = "s.whatsapp.net"   0x51 = "chat"   ...

XML (~190 bayt):
  <message to="998901234567@s.whatsapp.net" id="3EB0C4A1F2" type="chat" ...>

Ikkilik (~30 bayt):
  [0x13] [0x2A][JID: 998901234567 raqam sifatida, 5 bayt][0x44]
  [id: 5 bayt] [0x51] ...

Yuboruvchi                Server                     Qabul qiluvchi
    |  send(id=abc) ---->   |                              |
    |                       | navbatga YOZDI (diskka)      |
    | <---- ack(abc)  ✓     |                              |
    |                       | ---- deliver(abc) ---------> |
    |                       |                              | saqladi (telefonda)
    |                       | <--- ack(abc) -------------- |
    |                       | navbatdan O'CHIRDI           |
    | <---- receipt ✓✓      |                              |

1. Bekzodga xabar keldi, u oflayn
2. Server -> APNs/FCM: "Bekzodning qurilmasini uyg'ot" (+ minimal ma'lumot)
3. APNs/FCM -> telefon (umumiy ulanish orqali)
4. OT ilovani qisqa muddatga (~30 s) uyg'otadi
5. Ilova WhatsApp serveriga ulanadi, navbatni oladi, ack beradi
6. Ilova xabarni SHIFRDAN OCHADI va bildirishnoma ko'rsatadi
7. Ilova yana uxlaydi

1. Tasodifiy 32 baytlik media_kalit yaratadi
2. Faylni shu kalit bilan shifrlaydi (AES-256 + HMAC)
3. Shifrlangan blobni CDN'ga yuklaydi -> URL oladi
4. Oddiy E2EE xabar yuboradi: {url, media_kalit, sha256, o'lcham}
5. Qabul qiluvchi: xabarni ochadi -> URL'dan yuklaydi -> kalit bilan ochadi

forward_count = 0      -> oddiy xabar
forward_count >= 1     -> "Yo'naltirilgan" belgisi
forward_count >= 5     -> "Ko'p marta yo'naltirilgan" belgisi,
                          bir vaqtda faqat 1 ta suhbatga yo'naltirish mumkin

6. Oflayn telefon: navbat, push va uyg‘onish

Bu bo‘lim WhatsApp’ni Slack’dan ajratib turadigan asosiy farqga bag‘ishlangan: qabul qiluvchi odatda yo‘q.

6.1 Navbat hajmi: dumi hamma narsani belgilaydi

4.1-bo‘limda Little qonunidan foydalandik: navbatdagi elementlar = kirish tezligi × o‘rtacha kutish. Endi uni to‘g‘riroq qo‘llaymiz, chunki “o‘rtacha kutish” juda aldamchi son.

4.1-bo‘limda biz xuddi shu navbatni 1.7 milliard deb hisoblagan edik — bitta “o‘rtacha 2 soat” bilan. Haqiqiy javob 7 barobar katta, va farqning hammasi dumdan keladi. Bu ataylab qoldirilgan: birinchi hisob tipik xatoni, ikkinchisi uning tuzatilishini ko‘rsatadi.

Bu raqam sig‘im rejalashtirishning eng muhim saboqlaridan birini ko‘rsatadi: navbat hajmini o‘rtacha kutish emas, kutish taqsimotining dumi belgilaydi. Xabarlarning 99% i navbatdan soatlar ichida o‘tib ketadi, lekin qolgan 1% — telefoni buzilgan yoki sayohatdagi odamlar — navbatning deyarli hammasini egallaydi.

Bundan ikkita amaliy qaror chiqadi. Birinchisi — 30 kunlik chegara iqtisodiy qaror: 60 kun qilsangiz, C guruhining kutishi deyarli ikki barobar oshadi va navbat hajmi ham shunga yaqin o‘sadi. Ikkinchisi — navbatni ikki qatlamga bo‘lish (5-bo‘lim, 10-qadam) aynan shu taqsimotdan kelib chiqadi: tezkor qatlam A guruhini, bardoshli qatlam B va C ni ushlaydi.

1-usul: vaqt bo'yicha
  Yuza = (o'rtacha navbat hajmi L) x (kuzatish vaqti T)

2-usul: elementlar bo'yicha
  Har bir element navbatda W_i vaqt turdi -> u yuzaga W_i "qo'shdi"
  Yuza = W_1 + W_2 + ... + W_N = N x (o'rtacha W)

Ikkalasi bir xil yuza:
  L x T = N x W
  L = (N / T) x W = lambda x W

6.2 Push: uyg‘otish, lekin matnsiz

5-bo‘limning 4-qadamida push faqat “uyg‘on” deydi, dedik. Endi bu mexanizmning cheklovlarini aniq ko‘ramiz, chunki ular butun oflayn tajribani belgilaydi.

Jadvalning ikkinchi qatori eng muhimi: push kafolatlanmagan. Shuning uchun push hech qachon ma’lumot tashuvchi emas, faqat ishora. Haqiqiy ma’lumot doim navbatda turadi, va telefon keyingi safar ulanganda (push kelsa ham, kelmasa ham) uni oladi.

Uchinchi qator esa arxitektura qarori: server har bir xabar uchun push yubormaydi. Agar Bekzod oflayn bo‘lsa va unga 10 soniyada 50 ta xabar kelsa, bitta push yetarli — telefon uyg‘onib, hammasini oladi.

Ikki ustun ikki turli kafolat sinfini ko‘rsatadi, va arxitekturaning butun ishonchliligi ularni aralashtirmaslikka bog‘liq. Push’ni ishonchli qilishga urinish (qayta yuborish, tasdiqlash) keraksiz murakkablik: u baribir uchinchi tomon kanali. Navbatni esa “eng yaxshi urinish” qilish — xabarlarni yo‘qotish.

Bu hisobda men soddalashtirishga majbur bo‘ldim (“o‘rtacha 15 xabar bitta push’ga”) va buni ochiq aytaman: haqiqiy koeffitsient suhbat naqshiga juda bog‘liq va uni faqat o‘lchash mumkin. Lekin tartib to‘g‘ri, va xulosa o‘zgarmaydi: birlashtirish — push tizimining asosiy optimallashtirishi, va u server, push xizmati va batareyani bir vaqtda tejaydi.

6.3 Uyg‘onish byudjeti: 30 soniyada nimaga ulgurasiz

Telefon push olgach, operatsion tizim ilovani qisqa muddatga uyg‘otadi. Shu vaqt ichida ilova hamma ishni bajarishi kerak.

Bu raqam 1.2-bo‘limdagi “2G’da ham ishlasin” talabining haqiqiy qiyinchiligini ko‘rsatadi. Yechim — partiyalab olish va har partiyadan keyin tasdiqlash:

while navbatda_xabar_bor and vaqt_qoldi(> 5 s):
    partiya = server.fetch(limit=50)       # 50 KB
    for m in partiya:
        saqla(ochish(m))                   # AVVAL saqla
    server.ack(oxirgi_id(partiya))         # KEYIN tasdiqla
    bildirishnomani_yangila()              # "Anvar: 12 ta yangi xabar"

Ilova to‘xtatilsa ham, tasdiqlangan partiyalar navbatdan o‘chirilgan va telefonda saqlangan; tasdiqlanmagani esa navbatda qoladi va keyingi uyg‘onishda keladi. Hech narsa yo‘qolmaydi, hech narsa takrorlanmaydi — faqat ko‘rinish kechikadi.

Qaysi tartibda olish kerak? Mantiqan — yangilardan eskilarga emas, eskilardan yangilarga (Double Ratchet zanjiri tartibni afzal ko‘radi, 2.4-dagi Deep), lekin foydalanuvchiga eng oxirgi xabar muhimroq. Amaliy murosasi: ketma-ket olish, lekin bildirishnomada eng oxirgisini ko‘rsatish.

1. Push keladi, belgisi: "mutable-content: 1" (o'zgartirish mumkin)
   ichida: shifrlangan xabar (agar sig'sa) yoki faqat "xabar bor"
2. iOS kengaytmani ishga tushiradi:
     vaqt: ~30 soniya
     xotira: juda kam (o'nlab MB atrofida)
3. Kengaytma:
     - Keychain'dan (umumiy xavfsiz ombor) sessiya kalitini oladi
     - xabarni ochadi
     - bildirishnoma matnini "Anvar: salom" ga almashtiradi
4. iOS o'zgartirilgan bildirishnomani ko'rsatadi

7. Guruhlar: Sender Keys va kvadratik tuzoq

7.1 Juftlik shifrlash va yuboruvchi kaliti

Ikki ustunning to‘rtinchi qatori — butun bo‘limning mavzusi. Sender Keys har bir xabarni arzonlashtiradi, lekin har bir a’zolik o‘zgarishini qimmatlashtiradi. Bu — yuklamani doimiy yo‘ldan kamdan-kam yo‘lga ko‘chirish: xabarlar kuniga minglab, a’zo chiqishi esa haftada bir necha marta. Odatda bu juda yaxshi savdo. Lekin “odatda” so‘zi 7.2-da sinovdan o‘tadi.

Qanday ishlaydi, qadamlar bilan:

Anvar guruhga birinchi marta yozmoqchi:
  1. Tasodifiy "zanjir kaliti" CK va imzo kalit juftligi yaratadi
  2. {CK, imzo_ochiq_kaliti} ni har bir a'zoga JUFTLIK sessiyasi
     orqali yuboradi  (bu N ta xabar — lekin faqat BIR MARTA)
  3. Keyin har bir guruh xabari uchun:
       xabar_kaliti = HMAC(CK, 1);  CK = HMAC(CK, 2)   (simmetrik g'ildirak)
       shifr = AES(xabar_kaliti, matn);  imzo = Sign(shifr)
       serverga BITTA nusxa yuboradi
  4. Server bitta nusxani N ta a'zoga tarqatadi

Hisob muhim nuqtani ta’kidlaydi: Sender Keys server yukini kamaytirmaydi — server baribir 1 023 ta yetkazish qiladi. U yuboruvchining mobil yuklashini kamaytiradi, va bu tizimdagi eng tor bo‘g‘in. Optimallashtirishni har doim eng sekin resursga qarating, eng ko‘rinadigan resursga emas.

7.2 A’zo chiqib ketganda: kvadratik qayta kalitlash

Sender Keys’ning narxi shu yerda. Bekzod guruhdan chiqarildi. Uning qo‘lida barcha a’zolarning yuboruvchi kalitlari bor. Agar hech narsa qilinmasa, u server orqali o‘tadigan barcha kelajakdagi xabarlarni ocha oladi (masalan, serverdagi biror tanishi orqali yoki tarmoqni kuzatib).

Demak qolgan har bir a’zo yangi yuboruvchi kaliti yaratib, uni qolgan barcha a’zolarga juftlik sessiyasi orqali tarqatishi kerak.

Kvadratik o‘sish yana paydo bo‘ldi — Slack darsidagi presence va boshlang‘ich holat kabi. Va xuddi o‘shandagidek: kichik guruhda u ko‘rinmaydi (72 ta xabar), katta guruhda esa har bir a’zolik o‘zgarishi gigabaytlik hodisaga aylanadi.

Amaliy yumshatish — dangasa qayta kalitlash: a’zo chiqqanda hech kim darhol hech narsa yubormaydi. Har bir a’zo o‘zining keyingi guruh xabarini yuborishdan oldin yangi kalit yaratib tarqatadi. Guruhdagi 1 023 kishidan kunlik 50 tasi yozadi — demak qayta kalitlash 1 023 x 1 022 emas, 50 x 1 022 = ~51 000. Qolganlari hech qachon yozmasa — hech qachon kalitlamaydi.

7.3 Guruhdagi belgilar

1.3-bo‘limda bitta guruh xabari 58 ta hodisa yaratishini hisobladik. Katta guruhda bu yanada keskin.

Bu raqam — guruhlarda belgilarni guruhlash nega majburiy ekanining isboti. Yechim: qabul qiluvchi telefoni o‘qildi belgilarini bir necha soniya to‘playdi va “shu xabargacha hammasi o‘qildi” degan bitta signal yuboradi; server esa yuboruvchiga ularni birlashtirib, “987 kishi o‘qidi” degan agregat ko‘rinishda yetkazadi. Batafsil ro‘yxat (kim, qachon) esa faqat foydalanuvchi “Ma’lumot” ekranini ochganda so‘raladi — Slack darsidagi chekka kesh bilan bir xil g‘oya: kerak bo‘lganda so‘ra, oldindan itarma.

8. Ko‘p qurilma: har qurilma — alohida ishtirokchi

8.1 Model

2021-yilgacha WhatsApp Web telefonning aks-sadosi edi: noutbuk telefon bilan gaplashardi, telefon serverga. Telefon o‘chsa — hamma narsa to‘xtardi. Sababi oddiy: kalitlar faqat telefonda edi.

Yangi modelda har bir qurilma o‘zining identifikatsiya kaliti va o‘zining Double Ratchet sessiyalariga ega. “Foydalanuvchi” endi bitta kalit emas, qurilmalar ro‘yxati.

Bekzod (akkaunt):
  qurilma 0: telefon    IK_B0   (asosiy — ro'yxatni imzolaydi)
  qurilma 1: noutbuk    IK_B1
  qurilma 2: planshet   IK_B2

Anvar Bekzodga "salom" yozadi:
  shifr_0 = DoubleRatchet(Anvar_tel <-> B0, "salom")
  shifr_1 = DoubleRatchet(Anvar_tel <-> B1, "salom")
  shifr_2 = DoubleRatchet(Anvar_tel <-> B2, "salom")
  + Anvarning O'Z boshqa qurilmalari uchun ham (noutbuki A1):
  shifr_3 = DoubleRatchet(Anvar_tel <-> A1, "salom")

  Serverga: 4 ta shifr, har biri o'z qurilmasiga

Bu yondashuv — mijoz tomonda tarqatish (client fan-out): server xabarni nusxalamaydi, chunki u har bir qurilma uchun boshqa kalit bilan shifrlangan. Yuboruvchi hammasini o‘zi tayyorlaydi.

Oxirgi qator — ko‘p qurilmaning yashirin narxi. Yangi noutbuk bog‘langan kuni u yuzlab yangi sessiya ochadi, va har biri bir martalik prekey sarflaydi. Shuning uchun yangi qurilma prekey’larni odatdagidan ko‘p va tez-tez to‘ldirishi kerak.

8.2 Qurilmalar ro‘yxati: kim ishonchli?

Mijoz tomonda tarqatishning xavfsizlik savoli: Anvar Bekzodning qurilmalar ro‘yxatini qayerdan oladi? Serverdan. Server esa bizning tahdid modelimizda ishonchsiz. Server ro‘yxatga o‘z qurilmasini qo‘shsa, Anvar unga ham shifrlaydi — va server hamma narsani o‘qiydi.

Yechim — imzolangan ro‘yxat. Bekzodning asosiy qurilmasi (telefoni) ro‘yxatni o‘z identifikatsiya kaliti bilan imzolaydi. Yangi qurilma faqat telefon QR kodni skanerlab, ro‘yxatni qayta imzolagandan keyin qo‘shiladi. Anvar ro‘yxatni serverdan oladi, lekin imzoni Bekzodning IK kaliti bilan tekshiradi — va o‘sha kalit xavfsizlik kodiga bog‘langan (5-bo‘lim, 12-qadam).

10:00  Bekzod yangi noutbuk bog'ladi (qurilma 3). Ro'yxat versiyasi 7.
10:01  Anvar Bekzodga yozadi. Anvarning keshidagi ro'yxat: versiya 6
       (qurilma 0, 1, 2). Noutbuk uchun shifr YO'Q.
10:01  Server xabarni oladi: 3 ta shifr, lekin Bekzodda 4 ta qurilma.

1. Telefon QR kodni skanerlaydi -> yangi qurilma bilan
   to'g'ridan-to'g'ri E2EE sessiya o'rnatiladi
2. Telefon oxirgi N oy tarixini to'playdi, siqadi
3. Tasodifiy kalit bilan shifrlaydi, blob sifatida yuklaydi
   (xuddi media kabi — 5-bo'lim, 8-qadam)
4. Kalitni yangi qurilmaga E2EE xabar sifatida yuboradi
5. Yangi qurilma blobni yuklab, ochib, o'z bazasiga yozadi

9. Bugungi arxitektura

Diagrammani Slack darsidagi bilan solishtiring va farqni toping: bu yerda “Saqlash” qatlami deyarli yo‘q. Slack’da xabarlar bazasi, qidiruv indeksi, kanal tarixi — hammasi serverda. Bu yerda server faqat vaqtincha ushlaydi: yetkazilmagan xabarlar (navbat), prekey’lar (ishlatilguncha) va media (muddat tugaguncha). Doimiy ma’lumot faqat telefonlarda.

Bu — arxitekturaning eng muhim xususiyati va 12-bo‘limdagi iqtisodning asosiy sababi.

9.1 Yetkazish kechikishi byudjeti

Byudjetning 80% i — ikki mobil “oxirgi mil”. Serverdagi butun ish 10 ms dan kam. Slack darsida ham xuddi shunday edi (u yerda 93 ms dan 50 ms tarmoq), lekin bu yerda nisbat yanada keskin, chunki mobil tarmoq Wi-Fi’dan sekinroq va o‘zgaruvchan.

Oxirgi qator esa eng muhimi: radio uyg‘onishi. Ekrani o‘chiq telefonga xabar kelganda mobil radio past quvvat holatidan faol holatga o‘tishi kerak, va bu yuzlab millisekunddan ikki soniyagacha oladi. Bu kechikishni server hech qanday optimallashtirish bilan kamaytira olmaydi — u tarmoq operatorining sozlamasi. Mahsulot darajasidagi javob: foydalanuvchi ko‘radigan narsa (✓ ning tez paydo bo‘lishi) serverga bog‘liq qilinadi, qabul qiluvchiga bog‘liq narsa (✓✓) esa kechikishi mumkin — va foydalanuvchilar buni tabiiy qabul qiladi.

10. Ishonchlilik

10.1 Nosozliklar taksonomiyasi

Jadvaldan ko‘rinadigan naqsh: deyarli har qatorda javob “kechikish”, “yo‘qotish” emas. Bu — 5-bo‘limning 2-qadamidagi ikki bosqichli tasdiq va 10-qadamdagi replikatsiyalangan jurnal natijasi. Server ✓ bergan xabar faqat ikkala replika bir vaqtda yo‘qolganda yo‘qoladi.

Istisno — to‘rtinchi qator, va u WhatsApp foydalanuvchilariga eng tanish xato xabari. Uni alohida ko‘ramiz, chunki u E2EE ning eng og‘riqli operatsion jihatini ko‘rsatadi.

10.2 “Bu xabarni kutyapmiz”: sessiya sinxronligi buzilganda

Double Ratchet ikki tomonning aynan bir xil holatda bo‘lishini talab qiladi. Agar Bekzod ilovani qayta o‘rnatsa, yangi identifikatsiya kaliti yaratiladi va eski sessiyalar yo‘qoladi. Lekin Anvarning telefoni buni hali bilmaydi va xabarni eski sessiya bilan shifrlaydi.

1. Anvar eski sessiya bilan shifrlaydi -> yuboradi
2. Bekzod (yangi o'rnatilgan) xabarni oladi -> OCHA OLMAYDI
   Ekranda: "Bu xabarni kutyapmiz. Biroz vaqt olishi mumkin."
3. Bekzod telefoni -> Anvarga: "qayta urinish" belgisi (retry receipt)
   + o'zining yangi kalit to'plami
4. Anvar telefoni: eski sessiyani tashlaydi, yangi X3DH qiladi,
   xuddi shu xabarni QAYTA shifrlaydi -> yuboradi
5. Bekzod ochadi. Ekrandagi yozuv haqiqiy xabarga almashadi.

Bu mexanizmning muhim sharti: Anvarning telefoni onlayn bo‘lishi kerak. Server qayta shifrlay olmaydi — u matnni bilmaydi. Agar Anvar xabarni yuborib, telefonini o‘chirib qo‘ygan bo‘lsa, Bekzod “kutyapmiz” yozuvini u qaytgunicha ko‘radi.

0.1% kichik ko‘rinadi, lekin mutlaq son — kuniga 10 million odam. Shuning uchun bu “kutyapmiz” xabari WhatsApp’ning eng ko‘p muhokama qilinadigan xatolaridan biri. Bu xato emas, dizayn: E2EE bilan server tomonida tiklash imkonsiz, va tizim buni halol ko‘rsatadi. Muqobil — xabarni jimgina yo‘qotish — ancha yomon bo‘lardi.

YOMON TARTIB:
  1. Xabarni ochish: zanjir kalitini oldinga siljitish, xabar kalitini olish
  2. Yangi zanjir holatini diskka yozish, xabar kalitini O'CHIRISH
  3. <--- telefon batareyasi tugadi --->
  4. (xabar matnini bazaga yozish amalga oshmadi)

  Natija: kalit o'chirilgan, matn saqlanmagan. Xabar ABADIY yo'q.
  Serverdan qayta so'rash ham yordam bermaydi — shifr bir xil,
  kalit esa yo'q. Faqat qayta shifrlash so'rovi (10.2) qutqaradi.

TO'G'RI TARTIB (bitta tranzaksiyada):
  BEGIN
    xabar matnini yozish
    yangi zanjir holatini yozish
    xabar kalitini o'chirish
  COMMIT
  keyin serverga ack (✓✓)

10.3 Degradatsiya tartibi

Tartibning mantig‘i Slack’dagi bilan bir xil — o‘tkinchi narsalar birinchi, asosiy funksiya oxirgi — lekin bitta muhim farq bor: bu yerda 4-bosqich media. Slack’da media CDN’da alohida edi va yuklamaga kam ta’sir qilardi. WhatsApp’da esa media — trafik va saqlashning asosiy qismi (12-bo‘lim), shuning uchun uni sekinlashtirish eng katta yengillik beradi.

11. Xavfsizlik: mazmun himoyalangan, metama’lumot — yo‘q

E2EE juda kuchli va’da beradi, va aynan shuning uchun uning chegaralarini aniq bilish kerak. Eng keng tarqalgan noto‘g‘ri tushuncha: “uchidan-uchiga shifrlangan, demak server hech narsa bilmaydi”.

11.1 Server nimani biladi

Jadval ikkiga bo‘linadi: birinchi qator — mazmun, qolgan hammasi — metama’lumot. Va metama’lumot ko‘p narsani aytadi. Ikki kishi har kuni kechasi soat 2 da yozishadi; kimdir har dushanba ertalab bir xil advokat bilan gaplashadi; guruh a’zolari ro‘yxati siyosiy tashkilotni ko‘rsatadi. Matnni o‘qimasdan ham ko‘p narsani bilish mumkin.

Bu jadvaldan chiqadigan qaror: E2EE — mazmun uchun zarur, lekin maxfiylik uchun yetarli emas. Metama’lumotni kamaytirish alohida muhandislik ishi: qisqa saqlash muddatlari, jurnallarni agregatlash, va ba’zi tizimlarda (masalan, Signal’ning “muhrlangan yuboruvchi” — sealed sender — g‘oyasi) yuboruvchini serverdan ham yashirish. Har bir bunday qadam narxga ega, chunki server metama’lumotni ishlashi uchun ishlatadi.

ODDIY:
  konvert: { kimdan: Anvar, kimga: Bekzod, shifr: ... }
  Server Anvarni autentifikatsiya qiladi (ulanish orqali) va konvertni o'qiydi.

MUHRLANGAN YUBORUVCHI:
  konvert: { kimga: Bekzod, muhrlangan: Enc_Bekzod( kimdan: Anvar + sertifikat, shifr ) }
  Anvar serverga AUTENTIFIKATSIYASIZ ulanadi (anonim yuborish).
  "Kimdan" maydoni Bekzodning kaliti bilan shifrlangan — faqat u ochadi.

11.2 Spam bilan kurash: matnni o‘qimasdan

Server xabar matnini ko‘ra olmasa, spam va firibgarlikni qanday aniqlaydi? Faqat xatti-harakat orqali — va 11.1-dagi metama’lumot aynan shu yerda foydali.

Oxirgi paragraf — E2EE va moderatsiya muammosining eng nafis yechimi: qabul qiluvchi o‘zi olgan narsani ko‘rsatishi mumkin. Shifrlash yuboruvchini serverdan himoya qiladi, lekin qabul qiluvchidan emas — qabul qiluvchi baribir matnni ko‘radi va uni istalgan kishiga (jumladan, shikoyat orqali platformaga) ko‘rsatishi mumkin.

Bu yondashuvning chegarasi: u faqat kimdir shikoyat qilganda ishlaydi. Yopiq guruhda hamma rozi bo‘lgan zararli kontent (hech kim shikoyat qilmaydi) ko‘rinmaydi. Bu — E2EE ning ma’lum va ochiq tan olingan narxi, va uni “hal qilish” uchun taklif qilinadigan ko‘p g‘oyalar (masalan, telefonda avtomatik skanerlash) E2EE va’dasining o‘zini buzadi.

11.3 Havolaning oldindan ko‘rinishi: kichik funksiya, katta sizib chiqish

Xabarga havola qo‘shsangiz, sarlavha va rasm bilan kichik kartochka chiqadi. Oddiy tizimda buni server yaratadi: havolani oladi, sahifani yuklaydi, sarlavhani chiqaradi. E2EE tizimida bu mumkin emas — server havolani ko‘rmaydi. Agar ko‘rsa, u shifrlash qatlamidan sizib chiqqan bo‘ladi.

Yechim — yuboruvchi telefoni kartochkani yaratadi: havolani o‘zi ochadi, sarlavha va kichik rasmni oladi, va ularni xabarning shifrlangan qismiga qo‘shadi. Qabul qiluvchi esa hech narsa yuklamaydi.

Nega qabul qiluvchi yuklamaydi? Chunki unda hujumchi sizga havola yuborib, sizning telefoningizni o‘z serveriga murojaat qildirishi — ya’ni IP manzilingizni va onlayn ekaningizni bilishi mumkin edi. Bu kichik funksiya ham xavfsizlik modelini aniq tushunishni talab qiladi: kim tarmoqqa murojaat qilsa, u o‘zini oshkor qiladi, va bu faqat o‘z xohishi bilan yuborgan odam bo‘lishi kerak.

12. Iqtisod: nega WhatsApp arzon

WhatsApp tarixi iqtisod haqidagi eng mashhur hikoyalardan biri: keng tarqalgan ma’lumotlarga ko‘ra, 2014-yilda 450 milliondan ortiq foydalanuvchiga taxminan 50 nafar muhandis xizmat ko‘rsatgan. Bu raqam ko‘pincha “ular juda aqlli edi” deb tushuntiriladi. Aqlli bo‘lgani to‘g‘ri, lekin asosiy sabab arxitekturada: server qiladigan ish juda kam.

Bu hisob WhatsApp iqtisodining butun siri: ish mijozga ko‘chirilgan. Har bir telefon — kichik server: u o‘z tarixini saqlaydi, o‘z qidiruvini bajaradi, o‘z mediasini siqadi. 2 milliard telefon — 2 milliard bepul hisoblash tuguni. Server esa faqat pochtachi.

Raqamlar illyustratsiya — haqiqiy narxlar, siqish darajasi va saqlash muddati noma’lum va ancha farq qilishi mumkin. Lekin tuzilma ishonchli: xarajatning taxminan 80% i media, matn xabarlari esa deyarli bepul.

Jadvaldan uchta mahsulot qarori chiqadi, va ularning hammasi media haqida.

Birinchi: siqish telefonda bajariladi va u eng katta iqtisodiy tutqich. Telefon kamerasi 3–4 MB rasm oladi; WhatsApp uni yuborishdan oldin ~100–200 KB gacha siqadi. Bu 20 barobar. Agar siqish serverda bo‘lsa, server 20 barobar ko‘p qabul qilib, keyin siqishi kerak edi — va E2EE bilan bu umuman imkonsiz, chunki server rasmni ko‘rmaydi.

Ikkinchi: “yuqori sifatda yuborish” — pullik funksiyaga o‘xshaydi. Siqilmagan rasm yuborish imkoni media xarajatini shu xabar uchun 20 barobar oshiradi. Shuning uchun u standart emas, alohida tanlov.

Uchinchi: yo‘naltirishda URL qayta ishlatish (5-bo‘lim, 8-qadam) — viral kontentda 1 000 barobardan ortiq tejash. Bu optimallashtirish bo‘lmaganda viral video har yo‘naltirishda qayta yuklanardi.

1) O'LCHAMNI KICHRAYTIRISH (piksellar soni)
   Telefon kamerasi:   4032 x 3024 = 12.2 M piksel
   Messenjer uchun:    1600 x 1200 =  1.9 M piksel
   Nisbat: 12.2 / 1.9 = ~6.4 barobar kam piksel

   Telefon ekrani odatda ~1080-1440 piksel eni —
   1600 dan kattasini foydalanuvchi baribir ko'rmaydi.

2) JPEG SIFATI (piksel boshiga bayt)
   Kamera JPEG sifati ~90-95:  ~2.4 bit/piksel  -> 12.2 M x 2.4 / 8 = ~3.7 MB
   Messenjer sifati ~70-75:    ~0.7 bit/piksel  ->  1.9 M x 0.7 / 8 = ~170 KB
   Piksel boshiga nisbat: 2.4 / 0.7 = ~3.4 barobar

JAMI: 6.4 x 3.4 = ~22 barobar  (3.7 MB -> ~170 KB)

13. Sig‘im rejalashtirish

Slack’da sig‘imni ikki o‘q belgilagan edi: ulanishlar soni va eng katta ish maydoni. WhatsApp’da ham ikki o‘q bor, lekin boshqalari: uyg‘onish tezligi (sekundiga qancha telefon ulanib, navbatni oladi) va vaqt mintaqalari bo‘yicha sinxron hodisalar (hamma bir vaqtda uyg‘onadi yoki bir vaqtda yozadi).

Jadvaldagi signallarning ikkitasi Slack’da umuman bo‘lmagan turdagi: “ertalabki uyg‘onish” (B) va “yangi yil kechasi” (E). Ikkalasi ham kalendar va soat bilan bog‘liq sinxron hodisalar. Slack’ning foydalanuvchilari ish vaqtida tekis taqsimlangan; WhatsApp foydalanuvchilari esa bir mamlakat ichida bir vaqtda uyg‘onadi, bir vaqtda bayram qiladi va bir vaqtda “Yangi yilingiz bilan!” yozadi.

Bu hisobning muhim xulosasi: o‘rtacha yuklama bo‘yicha rejalashtirilgan navbat har kuni ertalab yiqiladi. Va bu “kamdan-kam cho‘qqi” emas — bu har kungi hodisa, va har bir yirik vaqt mintaqasida qayta takrorlanadi. Sig‘im bu yerda sutkalik maksimum bo‘yicha emas, mintaqaviy ertalabki maksimum bo‘yicha rejalashtiriladi.

To‘lqinning haqiqiy yo‘li — yirik bozorlar bo‘yicha, UTC vaqtida:

Timeline’dagi eng xavfli joy — Hindiston va O‘zbekiston orasidagi 30 daqiqa. Agar Hindiston to‘lqinining navbati (13-bo‘limdagi ~1.4 M xabar/s, 10 daqiqa) 30 daqiqada to‘liq tiklanmasa, keyingi to‘lqin qisman bo‘shagan navbat ustiga tushadi. Umumiy qoida: sig‘imni alohida cho‘qqilar bo‘yicha emas, cho‘qqilar orasidagi tiklanish vaqti bo‘yicha ham tekshiring.

Yangi yil kechasi WhatsApp uchun eng yaxshi haqiqiy yuk testi. U oldindan ma’lum (sanasi, soati, mintaqa tartibi), uni rejalashtirish mumkin, va u tizimning har bir qismini — navbat, belgilar, push, media — bir vaqtda sinaydi. Shuning uchun E bosqichining signali aynan shu kechaga bog‘langan: agar navbat 5 daqiqadan ko‘proq vaqtda tiklansa, keyingi yilga sig‘im yetmaydi.

14. Kuzatuv: xabarlarni o‘qimasdan tizimni ko‘rish

Oddiy tizimda muammo bo‘lsa, muhandis jurnalga qaraydi: qaysi so‘rov, qanday ma’lumot, qayerda xato. WhatsApp’da jurnalda xabar mazmuni yo‘q — faqat shifrlangan baytlar. Demak kuzatuv faqat metama’lumot va telefonlardan keladigan anonim telemetriya asosida quriladi.

14.1 Server tomon metrikalari

Jadvaldagi ikkinchi qator — tizimning eng qimmatli metrikasi, va u bepul: har bir ✓✓ belgisi xabar qabul qiluvchi telefonga qachon yetganini aytadi. Server ✓ va ✓✓ vaqtlari orasidagi farqni o‘lchab, uchidan-uchiga yetkazish kechikishini har bir xabar uchun biladi — mazmunga qaramasdan. Bu Slack darsidagi catchup_gap_size bilan bir xil g‘oya: mahsulot mexanizmining o‘zi o‘lchov asbobiga aylanadi.

Beshinchi qator esa 6.2-bo‘limdagi Android muammosini ko‘rsatadi: wake_to_connect qurilma modeli bo‘yicha bo‘linsa, “batareyani optimallashtirish” agressiv bo‘lgan modellar darhol ajralib chiqadi. Umumiy o‘rtacha buni hech qachon ko‘rsatmaydi — bitta model 3% ulush bilan o‘rtachani sezilarli o‘zgartirmaydi, lekin o‘sha modeldagi foydalanuvchilar uchun xabarlar daqiqalab kechikadi.

14.2 Telefon tomon telemetriyasi

Ba’zi muammolarni server umuman ko‘ra olmaydi, chunki ular shifrlash qatlamining ichida. Masalan, xabar yetib keldi (✓✓), lekin telefon uni ocha olmadi. Server uchun hammasi muvaffaqiyatli.

Bu metrikalar bitta muhim tamoyil asosida quriladi: ular hech qachon mazmun yoki identifikator tashimaydi — faqat hisoblagich va taqsimotlar, qurilma modeli va ilova versiyasi bo‘yicha guruhlangan. Aks holda telemetriya kanali E2EE ni aylanib o‘tadigan ikkinchi yo‘lga aylanadi.

Bu hisob bosqichma-bosqich chiqarish va versiya bo‘yicha bo‘lishning nega birgalikda ishlashi kerakligini ko‘rsatadi. 10% ga chiqarilganda xato umumiy metrikada ko‘rinmaydi (0.10% → 0.13%), lekin versiya bo‘yicha bo‘lganda 4 barobar farq aniq. Mobil ilovada bu ayniqsa muhim, chunki chiqarilgan versiyani qaytarib olib bo‘lmaydi — foydalanuvchilar uni allaqachon o‘rnatgan.

15. Antinaqshlar

Birinchi qator eng keng tarqalgan xato, chunki u juda qulay. Push ichida matn bo‘lsa, bildirishnoma ilovani uyg‘otmasdan darhol ko‘rinadi — 6.3-dagi 30 soniyalik oyna, iOS kengaytmasi, Keychain sinxronligi, hech biri kerak emas. Bir qator kod o‘rniga yuzlab qator murakkab mantiq tejaladi. Muammo — bu qulaylik E2EE ni butunlay bekor qiladi: push serveringizdan, keyin Apple yoki Google serverlaridan ochiq holda o‘tadi. Va bu xato ko‘pincha “vaqtinchalik” deb qilinadi va hech qachon tuzatilmaydi.

Ikkinchi qator jozibali, chunki 8.2-dagi jadval haqiqatan og‘riqli: yangi noutbukka bir yillik tarix 3G’da yarim soat ko‘chiriladi. Serverda tarix bo‘lsa — bir necha soniya. Lekin serverdagi tarix — qo‘shimcha shifrlangan nusxa emas, bu yangi hujum yuzasi: agar tarix serverda server ochadigan kalit bilan saqlansa, E2EE faqat tarmoqdagi yo‘lni himoya qiladi, eng qimmatli narsani — tarixni — esa yo‘q.

Uchinchi qator jozibali, chunki push ko‘pincha ishlaydi. Testda 100 ta push yuborsangiz, 100 tasi yetib boradi. Muammo faqat miqyosda va maxsus holatlarda ko‘rinadi: telefon uzoq oflayn bo‘lsa, push xizmati eski push’larni tashlaydi; agressiv batareya rejimi; tarmoq almashishi. 0.5% yo‘qotish testda ko‘rinmaydi, lekin kuniga 100 mlrd xabarda bu 500 million yo‘qolgan xabar.

To‘rtinchi qator jozibali, chunki u to‘g‘ri — juftlik shifrlash haqiqatan kuchliroq (7.3-dagi Deep). Kichik guruhda (5–10 a’zo) bu yaxshi tanlov ham bo‘lishi mumkin. Xato — uni hajmga qaramasdan qo‘llash. Bu Slack darsidagi presence eshittirishi bilan bir xil naqsh: kichik hajmda eng yaxshi, katta hajmda imkonsiz.

Beshinchi qator eng xavfli, chunki u ko‘rinmaydi. Tizim to‘liq ishlaydi, shifrlash haqiqiy, hamma testlar o‘tadi. Faqat bitta narsa yo‘q — va u server halol ekanini faraz qiladi. E2EE ning butun ma’nosi esa aynan shu farazdan voz kechish.

16. Trade-off‘lar

Jadvalni juftliklar bo‘yicha o‘qing. Birinchi uchta qator — bitta qarorning uch tomoni: server hech narsani bilmasin. Birinchisi mazmunni, ikkinchisi vaqtni (tarix), uchinchisi yetkazish kanalini (push) serverdan yashiradi. Har biri serverni soddalashtiradi va mijozni murakkablashtiradi.

To‘rtinchi va beshinchi qator esa ko‘paytma haqida: guruh a’zolari va qurilmalar. Ikkalasi ham shifrlashni N ga ko‘paytiradi, va ikkalasi ham uni qayerga ko‘chirishni hal qiladi: Sender Keys — xabardan a’zolik o‘zgarishiga; mijoz tarqatishi — serverdan telefonga.

Oltinchi qator yolg‘iz va eng “kam kriptografik”, lekin 12-bo‘limda ko‘rganimizdek, iqtisodiy jihatdan eng muhimi.

17. Intervyu savollari

17.1 Mexanizm

17.2 Miqyos

17.3 Tajriba

18. Amaliyot

To‘rt daraja. Birinchi va ikkinchi daraja uchun docs/amaliyot/whatsapp/ da tayyor kod bor: dh_demo.py to‘liq ishlaydi, relay.py va phone.py esa TODO bilan skelet — simulyatsiya va o‘lchov (bench.py) tayyor, hech qanday baza yoki server kerak emas.

19. Lug‘at

20. Raqamlar manbasi

Foydalanuvchilar soni (2 mlrd), kunlik xabarlar (100 mlrd), onlayn/oflayn ulushlar, kutish taqsimoti (80/19/1), media ulushi va hajmi, narxlar, radio quvvati va “dum” vaqti, 2014-yilgi jamoa hajmi — illyustratsiya uchun taxminiy raqamlar. Ular e’lon qilingan yoki keng tarqalgan ma’lumotlar tartibida, lekin aniq emas. Kriptografik va protokol raqamlari esa tekshirilishi mumkin — ularning manbasi yuqorida.

21. Manbalar

• WhatsApp, “WhatsApp Encryption Overview” (texnik hujjat) — X3DH, Double Ratchet, Sender Keys, media va transport shifrlashining rasmiy tavsifi
• Moxie Marlinspike, Trevor Perrin, “The X3DH Key Agreement Protocol” va “The Double Ratchet Algorithm” — Signal spetsifikatsiyalari
• Whitfield Diffie, Martin Hellman (1976), “New Directions in Cryptography”
• RFC 7748 — X25519 va X448 elliptik egri chiziqlari
• Trevor Perrin, “The Noise Protocol Framework”
• RFC 9420 — Messaging Layer Security (MLS): katta guruhlar uchun daraxt asosidagi kalit almashinuvi
• WhatsApp muhandislik blogi (2012), bitta serverda 2 milliondan ortiq ulanish haqida
• Meta muhandislik blogi (2021), ko‘p qurilma arxitekturasi haqida
• John D. C. Little (1961), “A Proof for the Queuing Formula L = λW”