— Lampochkani almashtirish uchun nechta JS developer kerak?
— 1 ta React developer, 1 ta NodeJS developer. Jami 11 ta.

— Lampochkani aylantirish uchun nechta dasturchi kerak?
— 2 ta. Bittasi lampochkani ushlab turadi, ikkinchisi dunyoni aylantiradi😎

— Lampochkani almashtirish uchun nechta dasturchi kerak?
— Open-close prinsipiga ko'ra lampochkani almashtirish mumkin emas. Yaxshisi, yoniga yana bitta lampochka qo'sh.

Qaysi manbaalardan ma'lumot olishni, qanday qilib o'rganishni, qanday qilib "zo'r" dasturchi bo'lishni so'rab tez-tez yozib turishadi. Odatda, faqat resurs beraman. Qanday qilib o'rganish, qanday qilib dasturlashni "his qilish" haqida esa iloji boricha maslahatlar (tips) bermaslikka harakat qilaman. Nega?

Well, men sizga bera olishim mumkin bo'lgan maslahatlar albatta, o'z tajribamdan o'tgan va qaysidir darajada foyda (yoki zarar) bergan caselardan chiqarilgan xulosalar to'plami. Ularni shartli ravishda 2 ta turga bo'la olaman:
1. Hamma uchun ishlaydigan "universal" tavsiyalar.
2. Menga bog'liq faktorlari mavjud bo'lgan tavsiyalar.

Keling, bu ikkalasini biroz analiz qilib ko'ramiz.
1. Hamma uchun ishlaydigan tavsiyalar. Masalan, ko'proq kitob o'qing, dissipliniya bilan o'rganing, dunyoqarashingizni kengaytiring yoki shunga o'xshash. Gap shundaki, bu gaplarning deyarli barchasi hamma (shu jumladan siz ham) biladigan, lekin ko'pchilik amal qilmaydigan gaplar. Siz allaqachon biladigan, lekin amal qilmaydigan gaplarni yana bir marta aytishdan nima foyda? Shuning uchun bunday tavsiyalarni bermayman (agarda kitob o'qish foydali ekanini bilmaysiz deb o'ylamasam).

2. Mening vaziyatimga bog'liq bo'lgan tavsiyalar. Masalan, men bilan bo'lganidek self-study qiling, top-down approachda o'rganing yoki PHPni emas Pythonni tanlang degan gaplarni aytishim mumkin. Sababi, men aynan shunday qilayapman. Lekin gap shundaki, bu tavsiyalar menda "ishlashi"ga ta'sir qilgan intellektual, iqtisodiy, diniy va hatto geografik faktorlar ham bor. Menga foyda bergan usullar sizga foyda bermasligi yoki umuman teskari natija berishi ham mumkin. Shu sababdan ham muvaffaqiyatga erishishning yagona qoidalar to'plami yo'q (aks holda hamma muvaffaqiyatli bo'lgan bo'lardi). Bu degani, agar siz butun hayotingiz davomida xuddi Elon Musk, Einstein yoki Al Xorazmiyga o'xshab yashasangiz ham ular kabi muvaffaqiyatli bo'lmasligingiz mumkin.

Xo'sh, "sizga maslahat bera olmayman" deyish uchun shuncha gapni yozdimmi? Albatta yo'q. Balki boshqalar yurgan yo'lni roadmap qilib olgandan ko'ra ulardan va o'zingizning shu vaqtgacha yurgan yo'lingizdan xulosalar chiqarib, o'zingiz uchun roadmap tuzing. "Muvaffaqiyat siri"ni izlagandan ko'ra bu yo'ldagi muammolaringizni analiz qilib, yechim toping. Masalan, ko'pchilik 10 minutdan ko'proq kitob yoki article o'qiy olmasligini aytib shikoyat qiladi. Lekin bu muammoning sababi boshqa muammo(lar). Masalan, attention span kamligi bo'lishi mumkin. Lekin nimani boshqa narsalarga chalg'imasdan 2-3 soat qila olasiz? Social media? Tabriklayman, siz ko'pchilik (men ham) chalingan, allaqachon bir nechta yechimlar topilgan, lekin juda kamchilik qutula oladigan "kasallik"ka chalinibsiz. Masalan, social media addictionga qarshi dopamine detox qilishingiz mumkin. Dopamine detox esa discipline talab qiladi. Sizda discipline yo'q bo'lsa avval bu muammoni hal qilishingiz kerak bo'ladi. Xullas, muammo/sabablardan iborat bu linked list hali ancha cho'zilishi mumkin. Muammolarni hal qilishni qancha chuqurroqdan boshlasangiz shuncha "solid" yechim qilgan bo'lasiz, faqat asosiy maqsaddan chalg'ib qolmang.

Xullas, "muvaffaqiyat formulasi"ni boshqalardan qidirmang. Izlaning, xato qiling, analiz qiling va davom eting. Bollar, biz yutamiz.

Bugun Pythonda bir narsani test qilayotganda qiziq holatga duch keldim.
Men bilishimcha Python thread bu OS thread ustiga qurilgan instance va bitta CPU coreda ishlaydi.
Lekin AYNAN bitta coreda turib, faqat shu coreda ishlaydimi yoki bir vaqtda QAYSIDIR bir coreda ishlab, birozdan keyin boshqa coreda ishlashi mumkinmi shuni topa olmadim.

Buni tekshirish uchun sistemadagi loadni minimallashtirib, CPU-intensive threadlar va processlarni bir nechta kombinatsiyada run qilgan holda CPU loadni kuzatdim. Natijalar meni hayron qoldirdi:

a) Single thread, single process. Bir vaqtda 1 ta CPU corega load tushdi, lekin o’sha load tushgan core almashib turdi. Masalan, hozir 1-coreda load bo’lsa birozdan keyin 2-corega load tushdi. Demak, OS thread ishlash davomida u ishlayotgan CPU coreni almashtirdi deb xulosa qilish mumkin.

b) Multiple thread, single process. (2, 3 va 4 ta threadda sinab ko’rdim). Bir vaqtda 1 ta corega load tushdi, lekin qizig’i load tushgan core o’zgarmadi. Ya’ni process boshidan oxirigacha aynan bitta coreda ishladi.

c) Multiple thread, multiple process (har birida 1 tadan thread bo’lgan 2-4 ta processda sinadim). Bir vaqtda bir nechta corega load tushdi va active corelar o’zgarib turdi. Masalan, hozir 1, 2, 3 corelar ishlayotgan bo’lsa, birozdan keyin 2, 4, 5 corelar ishlayapti.

Bu tajribadan keyin menda 3 ta savol tug’ildi:
1. Process ishlash davomida 1 ta coredan boshqasiga o’tadimi va agar shunday bo’lsa nega? Agar shunday bo’lsa, bu kim tomonidan bajariladi? Application, OS yoki undan ham pastroqdami?
2. Agar process ishlayotgan core OS tomonidan almashtirib turilsa unda resourcelar (RAM va balki CPU cache ham) qanday qilib share qilinadi?
3. Agar shunday bo’lsa nega multi thread, single process holatda (b) core o’zgarmadi?

Agar shu narsalar haqida ko’proq ma’lumot yoki resurs bilsangiz, kommentlarda qoldirsangiz xursand bo’lardim.

Bugun volatile memory haqida juda qiziq ta'rif o'qib qoldim:

No money – no honey,
No power – no memory.

© Manbaa

Pythonda yozilgan bu kodda juda chiroyli xatolik bor. Uni topa olasizmi?

P.S. Pythonda yozilgani xatolik emas ))

1990-yillar, internetni faqat ma'lum tashkilotlar orasidagina emas, butun dunyo bo'ylab ishlatish g'oyasi bilan chiqqan WWW endi tug'ilgan vaqtlar. IP, TCP, OSI kabi internetning "building block"lari allaqachon ishlab chiqilgan, lekin WWW uchun standartlar kerak edi. Ma'lumotni foydalanuvchiga yetkazish tili sifatida HTML ishlab chiqildi (va bu tildagi ma'lumotni render qilib, UIda ko'rsatish uchun browser ishlab chiqildi).
Networking uchun TCP va UDP kabi transport layer protocollar ishlab chiqilgan bo'lsa ham, tez, yengil, ishonchli va asosiysi, application layerda ishlaydigan protocol ishlab chiqishga ehtiyoj tug'ildi.

Shunday qilib HTTP ishlab chiqildi. Dastlabki versiya o'ta sodda va imkoniyatlari kam edi. Path orqali murojaat qilib, serverda turgan faylni yuklab olish mumkin edi xolos (faqatgina GET methodi bor edi). Keyinchalik bu versiyani boshqalardan farqlash uchun HTTP/0.9 deb nomlandi.

Keyingi versiyalarga to'xtishdan oldin HTTPning o'zi haqida biroz:
HTTP application layerda ishlaydigan, TCP protocoli ustiga qurilgan (h3 gacha), client-server modelini support qiladigan stateless protocol.
Nega stateless? Sababi protocol yengil va tez bo'lishi kerak edi. Stateful bo'lish esa protocolni og'irlashtirish va sekinlashtirishga olib keladi. Qiziq, unda nega stateful network protocol (TCP)ning ustiga qurildi? Sababi, protocol ishonchli bo'lishi kerak edi. TCP state orqali data to'liq yetkazilishini ta'minlaydi. Davom etamiz.

Tim Berners-Lee va uning jamoasining ko'p mehnatlaridan so'ng va nihoyat 1996-yil HTTP/1.0 rasman standart bo'ldi va RFC 1945 sifatida kiritildi.
Xo'sh bu versiyaga asosan nimalar kiritildi?
1. Status kodlari. Bu orqali browser request success bo'lgan yoki bo'lmaganini aniqlash imkoni tug'ildi.
2. POST va HEAD methodlari.
3. Request headerlar. Bu juda ko'plab yangi imkoniyatlar eshigini ochdi, masalan, hypertextdan boshqa content typelar bilan ishlash).
Jamoa esa tajriba qilishda davom etdi.

1 yildan keyinoq HTTP/1.1 ishlab chiqildi va RFC 2068 sifatida taqdim etildi. O'zgarishlar:
1. Bitta TCP connectionni keyingi request uchun qayta ishlatish imkoniyati. Sababi, TCP connection ochish ancha "qimmat"ha tushadi va bitta connectionni uzoqroq ishlatish kerak.
2. Yangi request methodlari.
3. Content haqida ko'proq metadata.
4. Katta hajmli responseni bo'laklab yuborish imkoniyati.
Keyingi yillar davomida WWW ancha takomillashdi, protocolga qo'yilgan talablar oshdi va natijada HTTPga yana ko'plab o'zgarishlar qo'shib borildi. Bir muammo borgan sari jiddiylashib bordi: bir nechta request yuborish uchun avvalgi requestga response kelishini kutib, undan keyingina keyingi requestni yuborish mumkin edi. Natijada client resurslarni olish uchun juda ko'p vaqt sarflashga majbur edi. Buni hal qilish uchun bir vaqtning o'zida 6 tagacha parallel connection ochib, request yuborish imkoniyati qo'shildi. Bu HTTP/1.1 ning 1.0 ga qaraganda eng ustun jihatlaridan biri bo'ldi. TLSni support qilish orqali protocol HTTPS deb atala boshlandi va shunga o'xshash bir nechta juda muhim yangilanishlar bo'ldi. 1.1 juda omadli chiqdi: tez, yengil va muhimi, moslashuvchan. Lekin shu bilan birga ba'zi jiddiy muammolari ham bor edi...

2015-yil, 1.1 versiya yaratilganidan 18 yil o'tib avvalgisidan ancha farq qiladigan zamonaviy protocol – HTTP/2 ishlab chiqildi (RFC 7540).
1.1 ko'plab requestlarni 6 ta parallel connection orqali hal qilgandi, lekin bu endi ancha samarasiz bo'lib qoldi. H2 da bu juda chiroyli usulda yechildi: bitta TCP connectionda bir vaqtda ko'plab request yuborish imkoniyati (bu narsa multiplexing deyiladi) bor va muhimi avvalgi requestga response kelishini kutib o'tirish shart emas! Shunchaki o'nlab request yuborasiz va server birin-ketin javob beraveradi. Responselar aralashib ketmasligi uchun har bir requestga ma'lum ID beriladi va server shu ID bilan response qaytaradi. Ha, bu "game changer" feature bo'ldi. Bundan tashqari juda ko'plab o'zgarishlar bor, qolganini o'zingiz topib o'qiysiz.

HTTP/3 yoki xayr TCP.
Request multiplexing juda ajoyib yechim edi, faqat bitta jiddiy muammosi bor ekan. TCP stateful protocol va uni agar dataning bir qismi yetib kelmasa, ma'lum vaqtdan keyin qayta uzatiladi va bu oraliqda yetib kelgan ma'lumot ham bloklanib turadi. Bu narsa OSIda 4-qavatda sodir bo'ladi, HTTP esa 7-qavatda. Demak, biz yuborgan 10 ta HTTP request TCP uchun shunchaki bir butun data, u request nimaligini ham bilmaydi. Natijada o'sha 10 ta requestdan birortasi qisman yetib kelmasa ham TCP hamma requestlarni bloklaydi. Bu HOL blocking deyiladi.
Bu muammoni hal qilish uchun h3 (RFC 9114) TCPdan voz kechib, UDP ustiga qurilgan QUIC protocolidan foydalanadi. UDPning o'zida retransmission yo'q. QUIC bu narsani o'zi ishlab chiqdi va buning TCPdagi retransmissiondan farqli jihati, QUIC bitta connection ichidagi HTTP requestlarni bir-biridan ajrata oladi. Sababi, QUICning o'zida multiplexing xususiyati bor va u retransmission bilan bitta layerda joylashgan. Natijada request to'liq yetib kelmasa butun boshli connection emas, faqat o'sha request bloklanadi.

Xo'sh, shu bilan muammolar tugadimi? Albatta yo'q. Muammolarni yechishda davom etamiz...
Bu maqolani yozishdan maqsad HTTPning evolutsiyasi haqida qisqacha ma'lumot berish va sizni bu borada yana izlanishga undash. Xato va kamchiliklarni aytib, feedback qoldirsangiz, xursand bo'laman.

Foydalanilgan manbaalar:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://en.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol
https://datatracker.ietf.org

P.S. Tanishlarga share qilinoradi 🙂

Anchadan beri chuqur texnik mavzularda post yozmadim.
Qaysi texnik mavzularda yangi maqola kutayapsiz?

Most of the time, it is not a good idea to use UUIDs in a centralized(single node) databases until it’s really needed.

@boboshersnotes

IP vs MAC
Yoxud birga ishlashga nima yetsin

Taxminan 50 yillar oldin bitta tarmoq orqali 2 tadan ortiq qurilmalar orasida ma’lumot almashish usuli o’ylab topildi. Lekin ma’lumotni aynan kerakli qurilmaga yuborish uchun har bir qurilma uchun unikal bo’lgan address kerak edi. Shu sababdan MAC address ishlab chiqildi. Agar device A device B ga ma’lumot yubormoqchi bo’lsa, ma’lumotni frame deb atalgan “quticha”ga soladi va “Bu ma’lumot device B uchun” deb belgilab, device B ning MAC addressini qo’shib yuboradi. Qizig’i, bu frameni networkdagi hamma device oladi. Lekin ochishdan oldin u yerda ko’rsatilgan MAC addressni o’ziniki bilan solishtirib ko’radi. Masalan, device C frameni qabul qiladi, lekin bu device B uchun ekanini bilganidan keyin ochmasdan, tashlab yuboradi. Natijada, faqat device B unga yuborilgan ma’lumotni o’qiydi.

MAC address orqali ma’lumot almashish yaxshi g’oya edi, lekin tarmoq hajmi kattalashgan sari bu usul samarasiz bo’lib boradi. Sababi, agar tarmoqda minglab device bo’lsa har bir device tarmoqda yuborilgan har bir frameni qabul qilishiga va tekshirishiga to’g’ri keladi. Bu esa juda ineffektiv.

Tarmoqdagi devicelar soni millionlab bo’lganida esa faqat MAC address orqali ma’lumot almashish ilojsiz bo’lib qoladi. Endigi vazifa katta, tekis tarmoqni bir necha qavatlardan iborat “tree” shaklida kichik qismlarga bo’lib tashlash va shu orqali ma’lumotni butun tarmoqqa emas, aynan kerakli device joylashgan qismga yuborish. Buning uchun IP address ishlab chiqildi. IP addressning MACdan asosiy ustun jihati u MAC kabi shunchaki tasodifiy raqamlar ketma-ketligi emas, ma’lumotni qayerga yuborishni ko’rsatuvchi address edi. Masalan, menga USdan “O’zbekiston, Toshkent shahri, falon ko’chasiga” deb pochta yuborilsa, pochta tizimi bu address orqali meni qayerda topish mumkinligini biladi, ular meni Berlindan yoki Samarqanddan izlashmaydi. IP address ham xuddi shunga o’xshash, u orqali reciever taxminan qaysi kontinentda turgani, qaysi internet providerdan foydalanayotgani aniqlanadi va ma’lumot hammaga emas, aynan kerakli joyga yuboradi. Lekin faqat IP addresslardan foydalanib internetni qurib bo’lmas edi. Hozirgi internet esa ikkalasini qo’shib ishlatadi: global tarmoq uchun IP address orqali, lokal tarmoqda MAC address orqali yuboriladi. ARP protocoli esa IP va MAC addresslar orasida “tarjimon” vazifasini bajaradi.

P.S. Yuqorida yozilganlar bu narsalar aslida ishlashidan ko’ra minglab marta sodda tushuntirilgan va shu sabab ba’zi qismlari haqiqatdan biroz farq qiladi.

@boboshersnotes

OSI modeli haqida

Open Systems Interconnection (OSI) modeli 1984-yilda ISO tomonidan standartlashtirilgan model bo’lib, qurilmalar orasidagi communikatsiya(ya’ni aloqa) qanday bo’lishini belgilab beruvchi konseptlardan (ha, konseptlar, qandaydir dastur emas) tashkil topgan. Shoshmang, avval yaxshilab tushunib oling: qurilmalar orasidagi aloqani ta’minlash. Masalan, men komputerim orqali biror saytga kirishim uchun mening komputerim va o’sha sayt serveri ma’lumot almashishi, ya’ni “gaplashishi” kerak. OSI esa shu ma’lumot uzatish jarayonini bir qancha bosqichlarga ajratib, har bir bosqichning vazifasini va ma’lumot qanday ko’rinishda bo’lishi kerakligini belgilaydi. Demak, bugun biz ko’p hollarda “shunchaki” ishlaydi deb hisoblagan jarayonlardan biri - qurilmalar orasida ma’lumot almashishni network engineer sifatida emas, dasturchi sifatida software tomondan batafsilroq ko’rib chiqishga harakat qilamiz.

OSI modeli ma’lumot uzatishning eng pastdagi ko’rinishi - networkda (havoda, internet kabelda va h.k) suzib yurgan ikkilik ma’lumotdan eng yuqoridagi (siz oladigan “odam tushunadigan” tildagi) ma’lumotni qabul qilishgacha bo’lgan yo’lni 7 ta qavatga ajratadi. Umumiy jarayon quyidagicha: Ma’lumot yuborayotgan qurilmada ma’lumot 7-qavatdan 1-qavatgacha tushib, shu holida network orqali qabul qiluvchi qurilmaga boradi. U esa ma’lumotni 1-qavatdan qaytarib yana 7-qavatgacha olib chiqadi va ma’lumotni o’qiydi.

Har bir qavat haqida gaplashishdan oldin bu qavatlar va umuman, OSI modeli nega ishlab chiqilgan degan savolga javob topishga harakat qilamiz (axir hech narsa sababsiz ishlab chiqilmaydi, shunday emasmi?):

1. Qavatlarga ajratish natijasida yangi abstraksiyalar paydo bo’ladi. Biz ma’lum bir qavatda ishlagan vaqtda qolgan qavatlar biz uchun “shunchaki” ishlaydi. Natijada ma’lum ishni bajarish uchun butun boshli tizimni to’liq tushunish talab qilinmaydi, faqat kerakli qismni bilish yetarli bo’ladi. Masalan, TCP protocoli uchun ma’lumot kabel orqali yoki wi-fi orqali yuborilayotgani qiziq emas.

2. Butun boshli jarayonni bir-biridan mustaqil kichik qismlarga ajratish natijasida tizimning ma’lum bir qismigni modifikatsiya qilish uchun minimal o’zgartirishlar yetarli bo’ladi. Masalan, kelajakda ma’lumot uzatishning yorug’lik, elektromagnit to’lqinlariga o’xshash yangi yo’li paydo bo’lsa, bu usulni standartlash uchun faqat shu vazifaga javob beradigan qavatni o’zgartirish yetarli bo’ladi. Yoki TCP protokoliga o’zgartirish kiritilsa bu o’zgarish faqat TCP ishlaydigan qavatda bo’ladi, qolgan qavatlar har doimgidek ishlayveradi.

@boboshersnotes

Layer 1 - Physical layer

Insoniyat ming yillar davomida ma’lumot saqlashning ko’plab usullarini o’ylab topgan. Rasmlar, iyerogliflar, harflar sistemasi, raqamlar sistemasi va hokazo. Lekin bizga standart, saqlash, tashish va qayta ishlash oson bo’lgan usul kerak edi. Har qanday ma’lumotni sanoq sistemasiga o’tkaza olishimiz ma’lum bo’lganidan keyin sanoq sistemasidagi belgilarni saqlash va tashish oson bo’lgan fiziologik obyektlarning har xil holatiga o’girish g’oyasi keldi. Masalan, ikkilik sanoq sistemasida 1 va 0 raqamlari bor. Bu ikki raqamni har xil usullarda represent qilishimiz mumkin: chiroq yoniq - chiroq o’chgan, ovoz bor - ovoz yo’q, tok bor - tok yo’q va hokazo. Natijada, biz ma’lumotlarni saqlash va yuborish uchun bitta standartga ega bo’ldik. Endi biz ma’lumotni qog’ozga yozib, qog’ozni kaptar orqali yuborishimiz shart emas. Ma’lumotni raqamli ko’rinishda tasvirlash mumkin bo’lgan istalgan ko’rinishda saqlaymiz va yubora olamiz: elektr, ovoz to’lqini, yorug’lik va hokazo. Muhimi, endi bizda raqamli standart bor.

OSI modelining eng pastdagi – 1-qavati biz aytgan ma’lumotni bir turdan boshqa o’tkazish uchun ishlaydi. Bu qavat yuborilayotgan ma’lumotning qurilmadagi ko’rinishi va yuborish uchun o’tkaziladigan ko’rinishi orasida ko’prik vazifasini bajaradi. Masalan, ma’lumot wi-fi orqali yuborilsa bo’lsa radioto’lqinlarga, ethernet orqali bo’lsa elektromagnetik to’lqinlarga, optik tola orqali yuborilsa yorug’lik signallari va h.k. o’tkaziladi. Yoki aksincha, shunday ko’rinishda kelayotgan ma’lumotni komputer tushunadigan ko’rinishga o’tkaziladi. Bu jarayonlarning hammasi Network Interface Card (NIC) tomonidan bajariladi.

Bu qavat ishlab chiqilishi natijasida ma’lumotlarni tarmoqqa chiqarish va qabul qilish biz - dasturchilar uchun abstrakt bo’ldi. Shu sabab endi biz har bitta dasturda ma’lumotni networkka chiqarish uchun ma’lumotni har xil ko’rinishga (elektromagnit signal, radiosignal va h.k) o’tkazish haqida o’ylamasak ham bo’ladi. Bu allaqachon yozib qo’yilgan va biz uchun “shunchaki” ishlaydi. Kelajakda ma’lumot yuborishning boshqa usullari o’ylab topilsa, o’sha usuldan foydalana olish uchun faqat shu qavatni o’zgartirish yetarli bo’ladi. Qolgan qismlar hech qanday modifikatsiya talab qilmaydi.

@boboshersnotes

Layer 2 – Data link layer

Bu qavatda aslida IP address va router tushunchasi bo’lmasa ham, yaxshiroq tushunish uchun IP addresslar haqida ham gaplashamiz.

Avvalroq kelishganimizdek IP va MAC address bir-biri bilan inoq, birga ishlaydi. Global networkda biz faqat IP address va portlar haqida gaplashsak ham, internet ishlashi uchun biz haliyam MAC addresslarga muhtojmiz. Aslida, global tarmoq orqali ma’lum qurilmaga ma’lumot yuborish uchun IP address yetarli bo’lsa ham, lokal tarmoqdagi qurilmalar bilan ma’lumot almashish uchun MAC address kerak. Biz esa iloji boricha ikki xil standartlardan qochishga harakat qilamiz. Natijada biz aslida zarur bo’lmagan holatda ham MAC address ishlatishga majbur bo’lamiz.

Endigina tandirdan uzilgan physical layerdan kelgan binary data 2-qavatda frame deb ataladigan bo’laklarga bo’lib chiqiladi. Frame bu shunchaki network orqali bir bo’lak sifatida yuborilgan ma’lumot. Hajmi odatda, 1500 byte bo’ladi, lekin tarmoq xususiyatlariga qarab o’zgaradi. Har bir frameda esa asosiy kontentdan tashqari ikkita MAC address bo’ladi: yuboruvchining MAC addressi va qabul qiluvchining MAC addressi. Ikkinchisi biz uchun juda qiziq. Sababi, kelishganimizdek MAC addresslar bilan ishlaganda biz frame faqat qabul qiluvchiga emas, balki tarmoqdagi hammaga yuboriladi. Bizning vazifamiz esa qabul qiluvchining va o’zimnizning MAC addresslarni solishtirib ko’rish orqali bu frame biz uchunmi yoki yo’q, shuni aniqlash.

Shu o’rinda savol tug’iladI: Yuboruvchi qabul qiluvchining MAC addressini qanday oldi? Yaxshi savol! Buning uchun ARP protocoli ishlab chiqilgan. Yuboruvchi frameni yuborishdan oldin ARP protocoli orqali ma’lum IP addressi egasining MAC addressi oladi va framega destination address sifatida qo’yadi. Umuman olganda, ko’p hollarda bu aynan qabul qiluvchi qurilmaning emas, shu qurilma uchun global tarmoqdagi interface sifatida ishlayotgan routerning MAC addressi bo’ladi. Router esa frameni qabul qilib olganidan keyin Local networkda ARP qilish orqali haqiqiy qabul qiluvchi qurilmaning MAC addressini topadi va framedagi destination addressni o’zgartirib, frameni local tarmoqqa tarqatadi. Natijada, qabul qiluvchi ma’lumotni oladi.

Qisqacha aytganda, OSI layer 2 ning vazifasi MAC addresslar bilan ishlash. Bu qavat natijasida biz IP yoki MAC address ishlatadigan ikki xil standartdan qochib, IP + MAC address ko’rinishidagi bitta standartga ega bo’ldik.

P.S IP address va routerlar haqida keyinroq batafsil gaplashamiz.

@boboshersnotes

IP qanday ishlaydi?

Yoxud “Mail service: ko’chirmachilar”

Tasavvur qiling, yer yuzida faqatgina 100 kishi yashaydi. Deylik, Amerikalik bir kishi O’zimizning Eshmatov Toshmat akaga pochta yubordi, sizning vazifangiz esa uni egasiga yetkazish. Xo’sh nima qilasiz?

Eng sodda usuli, 100 kishining har biridan birma-bir ismini so’rab chiqib Toshmat akani topish. Yaxshi g’oya, MAC addresslar aynan shu g’oya ustiga qurilgan. Bu usulning kamchiligi, bir kishiga pochta yetkazib berish jarayonida faqat Toshmat aka emas, hamma qatnashishi kerak. Lekin yerda faqat 100 kishi emas, 8 milliard kishi yashasa Eshmat akani topish uchun hammadan birma-bir ismini so’rab chiqish imkonsiz.

Katta hajmli ma’lumot orasidan kerakli ma’lumotni izlashning eng yaxshi usullaridan biri qidiruv doirasini iloji boricha toraytirishga harakat qilish. Pochta tizimlarida address “Eshmatov Toshmatga” emas, “O’zbekiston res. Toshkent shahri, Chilonzor tumani falon ko’chada turadigan Eshmatov Toshmatga” deb yoziladi.
Bunday darajalangan addresslar natijasida addressni izlash davomida qidiruv doirasi torayib boradi.
— Pochta avval Amerikadan O’zbekistonga yuboriladi. Addressda shu davlat yozilgani uchun Toshmat akani Xitoy yoki Kanadadan qidirish shart emas. Shu yerning o’zida qidiriv doirasi 8 milliarddan 35 milliongacha kamaydi.
— Pochta O’zbekistonga kelganidan keyin uni Toshmat akaga yuborish uchun Qashqadaryo yoki Sirdaryoga yuborilmaydi, Sababi Toshmat aka Toshkentda turishini bilamiz. Natijada qidiruv doirasi yana toraydi. Xuddi shunday bir-ikki bosqichdan keyin pochta egasiga yetib boradi.

IP addresslar xuddi shu g’oya asosida ishlaydi. Router packetning IP addressiga qarab qabul qiluvchining internet provideri va joylashgan xududi haqida ma’lumot oladi (joylashuv haqidagi ma’lumot ishonchli emas). Masalan, men USda joylashgan serverga ma’lumot yubormoqchi bo’lsam men yuborgan IP packetni (bu haqida keyinroq) o’qigan router aynan qaysi server ekanini bilmasa ham, paket taxminan qaysi tomonga ketishini biladi va Rossiyaning providerlari tomondagi emas, USning providerlari joylashgan tomondagi routerlarga yuboradi.

P.S. Albatta, IP packet routing bundan ko’ra juda murakkab ishlaydi, lekin asosiy g’oyashi shunga o’xshash.

@boboshersnotes

Layer 3 – Network Layer

Internet tarmog’ida ma’lumotlarni almashish uchun IP addresslar ishlatilishini biroz darajada bo’lsa-da o’rgandik. Aslini olganda, bu jarayon shunchalik murakkab-ki, uni amalga oshirish uchun butun boshli IP protocoli ishlab chiqilgan. IP protocolida ma’lumotlar IP packet deb nomlangan alohida bo’laklarda, qismlarga bo’lib yuboriliadi. IP packet ham xuddi 2-qavatdagi framega o’xshash tushuncha, faqat IP protocoli bilan ishlash uchun ishlab chiqilgan.

Router - IP packetlarni qabul qilib, boshqa routerlarga yoki qabul qiluvchi qurilmalarga yuboradigan qurilma. Marshrutkada orqada o'tirganlarning yo’lkirasini haydovchiga uzatib yuboradiganlar borku, xuddi o’shalar. Teoritik jihatdan “toza” layer 3 qurilma, lekin aslida bundan yuqori qavatlarga ham chiqadi.

IP packetlarning tezligi muhim omil bo’lgani uchun IP stateless protocol sifatida ishlab chiqildi. Lekin murakkab yetkazish jarayonida packetni nazorat qila olish ham muhim edi. Buning uchun esa ma’lum darajada state saqlanishi kerak edi. Shunda ikkala talabni ham qondira oladigan chiroyli yechim paydo bo’ldi: Packet yuboruvchi state saqlamaydi, lekin packetning o’zida metadata saqlanadi. Routerlar esa bu metadata orqali packetni nazorat qila olish imkoniyatiga ega bo’ladi. Lekin baribir ba’zida routerlar bir-biriga yoki paket yuboruvchisiga to’g’ridan to’g’ri qisqa va avvaldan kelishilgan tartibdagi ma’lumotlarni yuborishi kerak bo’ladi. Buni bajarish uchun esa ICMP protocoli ishlab chiqildi.

IP packetlarni yo’naltirish hardware tomondan ham software tomondan ham ancha murakkab jarayon. Buni tasavvur qilishingiz uchun IP protocolining software tomondagi bir nechta xususiyatlarini sanab o’taman:
— IP versiyasiga qarab yo'naltirish. Hozirda IP addresslarning ikki xil versiyasi bor. Ba'zi routerlar ikkita versiyadan faqat bittasini support qiladi.
— IP packet qancha vaqt “yashashi”ni nazorat qilish. Bu orqali agar networkdagi packet kerakli manzilni topa olmasa, tarmoqda to’xtovsiz suzib yurib, routerlardan resurs olishining oldi olinadi. Buning uchun packet headerlari ichida TTL (Time To Live) deb nomlanga header bor. Router packetni qabul qilgan vaqtda shu headerga qaraydi va agar packetning vaqti-soati yetgan belgilangan vaqti tugagan bo’lsa, uni chopadi tashlab yuboradi va uni yuborgan qurilmaga “Packet aytilgan joyga yetib bora olmadi” degan ma’noda ICMP message yuboradi.
— Bitta IP packet bitta framega sig’masa, uni bo’laklash(fragmentation). Framelardagi fragmentlardan qayta yana bitta packet tuzib olish esa ancha ish talab qiladi.

Tepada aytilganlarning hammasi ma’lumotni IP addresslar orqali internetda kerakli joyga yuborish uchun kerak. Boshqa jarayonlar bilan networkda chalkashlik kelib chiqmasligi uchun bularning hammasini OSI modelida alohida qavatga joylandi va bu qavat Network layer deb nomlandi. Natijada, tepada ko’rsatilgan murakkabliklarning hammasi abstraksiya orqasiga yashirildi va qolganlar uchun ma’lumot berilgan IP addressga “shunchaki” yetib boradi deb o’ylash imkoni paydo bo’ldi.

@boboshersnotes

Odatda, OSI protocoli eng yuqoridan boshlab o’rganiladi. Sababi, shunda butun jarayonni tasavvur qilish oson bo’ladi. Chunki masalan, 4-qavat haqida o’rganilayotganda undan pastdagi qavatlar abstrakt bo’ladi. Men esa bu safar top-down emas, bottom-up approachda yozib chiqishga harakat qilayapman. Maqsad esa internetning rivojlanish evolutsiyasini analiz qilish orqali har bir qavatning ahamiyatni o’rganish va ishlab chiqilishi uchun sabablarni ko’rib chiqish.

Agar OSI modeli haqida avval eshitmagan bo’lsangiz bu usulda sizga biroz tushunarsiz bo’lishi mumkin, lekin inshaallah oxirigacha yetib, recap qilganimizda hammasi tushunarli bo’lishni boshlaydi deb umid qilaman. Ana shundan keyin yana boshidan bir marta o’qib chiqsangiz nur ustiga a’lo nur.

@boboshersnotes