Layer 4 – Transport layer

Va nihoyat butun OSI modelining yuragi bo’lgan transport layerga yetib keldik. Bu qavatda aslida juda ko’p narsa sodir bo’ladi, lekin ular asosan 2 ta muammoni yechishga yo’naltirilgan. Hozir shu ikki muammoni sabablari bilan ko’rib chiqishga harakat qilamiz.

1. Kompyuter qurilmalari rivojlanishi natijasida bitta komputerda bir vaqtda bir nechta dastur ishlashi imkoni tug’ildi. Bu esa networkingda yangi muammoni yuzaga chiqardi. Ma’lumotni tarmoqdagi qaysi qurilma yuborgani va qaysi qurilmaga yuborilayotganini ko’rsatish uchun biz IP addresslardan foydalangandik. Endi bu yetarli bo’lmay qoldi. Endi manzilda qurilmaning o’zini ko’rsatishdan tashqari shu qurilmadagi qaysi dastur yuborayotgani yoki qaysi dasturga yuborilayotganini ham ko’rsatish kerak bo’ldi. Sababi, bitta qurilmada bir vaqtda bir nechta dastur internetdan foydalanayotgan bo’lishi mumkin. Bu dasturlarga kelayotgan ma’lumotlar bir-biri bilan aralashib ketmasligi kerak, axir Telegramga kelishi kerak bo’lgan ma’lumotingiz Youtubega kelishini xohlamasangiz kerak?

Natijada portlar tushunchasi paydo bo’ldi. Portlar shunchaki bitta qurilmadagi har xil sonlar bilan belgilangan bir dunyo (aniqrog’i, 65536 ta) kirish eshiklari. Masalan, Telegram 8000 raqamli eshikdan ma’lumot yuboradi va qabul qiladi. Youtube esa 9000 raqamli eshikdan foydalanadi. Natijada, bitta komputerda ikkita dastur bir-biriga halaqit bermagan holatda internetdan foydalana oladi.

2. Network layer ma’lumotlarni yetkazib berishga xizmat qilsa ham u to’laqonli transport mexanizmi sifatida xizmat qila olmas edi, sababi uning imkoniyatlari juda kam edi. U xuddi g’ildirakka o’xshaydi. Bir o’zi to’la transport bo’la olmaydi, lekin transportlarning asosini tashkil qiladi. Mashina ham, mototsikl ham, avtobus ham g’ildiraklar ustida yuradi, lekin imkoniyatlari, narxi va vazifasiga ko’ra farq qiladi. Masalan, mashina qulay, ishonchli, lekin qimmat. Avtobus arzon lekin shu bilan birga noqulay va sekinroq. Mototsikl esa tez, nisbatan arzon lekin ishonchsiz.

@boboshersnotes

Xuddi shu jarayon internet bilan ham bo’ldi. Ba’zida yetkazish tezligidan ko’ra ishonchlilik muhim, ba’zida esa tezlik muhim bo’lib ishonchlilik ikkinchi o’ringa tushadi. Bunday har xil talablarni bitta transport mexanizmi orqali hal qilib bo’lmas edi. Shuning uchun ishlashi va ishlatilish o’rni bir-biridan farq qiladigan 2 ta alohida transport mexanizmi – transport qavatidagi protocollar ishlab chiqildi:

— UDP. Yetkazish tezligiga qaratilgan protocol. Lekin yetkazib berishni kafolatlamaydi. Stateless protocol, ya’ni yuboruvchi qurilmada tarmoqqa chiqqan datagram (UDP protocolidagi ma’lumot uzatish birligi) haqida ma’lumot bo’lmaydi. U kerakli joyga yetib bordimi yoki yo’lda adashib qoldimi yoki qayergadir tiqilib qoldimi bundan xabari yo’q. Ma’lumotni tarmoqqa chiqardi va bo’ldi, uning ishi tugadi. Tez, lekin ishonchsiz.

— TCP. Yetkazish sifatiga qaratilgan protocol. Ma’lumotni yetkazib berish kafolatlanadi, lekin UDPdan ko’ra ancha sekin ishlaydi. Stateful protocol, ya’ni yetkazuvchi qurilma tarmoqqa chiqib ketgan segment(TCP protocolidagi ma’lumot uzatish birligi)ning holatidan xabardor bo’lib turadi. TCP ma’lumot yetkazilishini ta’minlash uchun juda ehtiyotkor (xuddi viloyatdan Toshkentga ketgan farzandi yetib borgunicha 8 marta telefon qiladigan ota-onalarga o’xshaydi). Ma’lumot yuborishdan oldin yuboruvchi qabul qiluvchi bilan bog’lanib, ikkala tomon kelishib oladi (bu connection hisoblanadi). Keyin ma’lumotlarni yuborish davomida ham yuboruvchi qabul qiluvchidan tashqari o’rtadagi routerlardan ham hol-avhol so’rab turadi (router bir vaqtda ko’p ma’lumot olsa hazm qila olmay, mazasi qochib qolishi mumkin). Zarur bo’lsa, ma’lumot yuborish tezligini oshiradi yoki kamaytiradi. Har bir borgan ma’lumotni qabul qiluvchidan tasdiqlatib oladi. Agar ma’lumotning bir qismi qabul qiluvchiga yetib bormasa, qaytadan yuboradi. Qisqasi, TCP anchagina ish qiladi. Lekin bu asosiy mavzu bo’lmagani uchun batafsil to’xtalmaymiz.

Xullas, transport layerda ma’lumot yetkazish uchun har xil imkoniyatlarni beradigan transport protocollari ishlaydi. Bundan oldingi 3 ta qavatdan ajralib turadigan jihati, oldingi 3 ta qavat hamma uchun bir xil edi. Shu yerdan boshlab esa bitta qavatda sodir bo’ladigan ishlar tanlangan protocolga qarab farq qiladi. Shu yerdan boshlab bizda yana o’sha klassik tezlik yoki sifat tanlovi bor. Shuning uchun ham bu qavat OSI modelidagi eng asosiy qavat hisoblanadi. Albatta, yana portlar ham bor.

@boboshersnotes

Bugun Leetcodeda mana bu masalani yechib ko’rayotganda qiziqib, linear search ishlatib ko’rdim. Albatta, bu eng oddiy va effektivligi past yechim edi, lekin shu yechim orqali qanday natija olishni ko’rmoqchi edim.
Qizig’i, runtime 91% submissionlardan yaxshiroq chiqdi.
Menimcha, ko’pchilik fancy yechim qilaman deb aslida eng oddiy yechimdan ham yomon yechim qilib qo’ygan, yana bilmadim.

Wanna buy me a coffee? Here you go:
5614681916480936

P.S. Tirikchilik ))

Kechgi mutolaa uchun:
http://arthurchiao.art/blog/tcp-listen-a-tale-of-two-queues/

Bir muammoni yechishning ko'plab usullari bor. Ular tezlik va effektivlikdan tashqari muammoga yondoshuv jihatidan ham bir-biridan farq qiladi. Ba'zi yechimlar qo'pol, muammoni "tekislab" tashlaydigan bo'ladi. Ba'zilari esa nozik va chiroyli yechim bo'ladi.

Masalan, Floyd's cycle (yoki Tortoise and Hare) algorithmiga e'tibor bering. Boshida foydalanish uchun oson, lekin qanday ishlashi biroz abstrakt ko'rinadi. Lekin algorithmning ortidagi g'oyani tushunganingizdan keyin qoyil qolasiz. Oddiy matematika yordamida ishlangan san'at asari.

P.S. Afsuski ko'pchilikka muammoga qanday yondoshish emas, yechimdan qanday foydalanish qiziq.

There are only two hard things in Computer Science: cache invalidation and naming things.

© Phil Karlton

Agree?

Biz biladigan zamonaviy dasturlash yuzlab, minglab qavatlardan iborat abstraksiyalar ustiga qurilgan. Natijada, bizda kichikroq, kuchsizroq komponentlardan foydalangan holda minimal mehnat bilan katta dastur qurish imkoniyati bor.

Lekin buning bir "lekin"i bor. Har bir qavat ma'lum darajada resurs isrof qiladi. Bu asosan interface noto'g'ri ishlab chiqilganidan yoki noto'g'ri foydalanilgani uchun sodir bo'ladi (aslida yozib qo'yilgan to'g'ri usulning o'zi yo'q). Bundan tashqari, ko'pchilik low-level interfacelar multi-purpose qilib ishlab chiqiladi (albatta, kamroq mehnat uchun). Bu esa yana resurs yo'qotilishiga olib keladi.

Demak, dastur qancha yuqori darajali bo'lsa shuncha effektivligi past bo'ladi va hardwarening to'la potentsialini shuncha sindiradi. Hozir biz yozadigan dasturlar orqali kompyuterlarning to'la imkoniyatining o'ta kichkina qismidangina foydalanamiz xolos. Agar to'la potensialida ishlata olsangiz, Intel Pentium processori va 2 GB RAM orqali ham "ancha-muncha" ish qilsa bo'ladi (eslasangiz, 50 yil oldin 4 KB RAM bilan inson oyga uchgan).

Shuning uchun low-level tillar high-level tillardan ko'ra ancha tez va effektiv.

Demak, hardwarening imkoniyatlaridan kelib chiqadigan bo'lsak, zamonaviy dasturlarning effektivligi ancha past. Xo'sh, buni to'g'rilashning iloji bormi? Balki.

Bundan 10-15 yillar oldin avtomobil industriyasida xuddi shunga o'xshash holat bo'lgan. 5-6 litrli, 700-800 HPga ega dvigatellar ishlab chiqilgan. Lekin dvigatel effektivligi 30-35% atrofida bo'lgan, ya'ni energiyaning faqatgina uchdan bir qismidan foydalanilgan. Albatta, buni yaxshilash uchun har xil "trick"lar ishlab chiqildi (aerodinamik korpus, turbochargerlar va h.k.), lekin yuqori darajadagi o'zgarishlar juda kam natija berdi.

Keyin sahnaga elektrodvigatellar chiqdi (aniqrog'i, qaytdi). Bu fundamental o'zgarish dvigatel effektivligini 80-90% gacha oshirdi. Narxlar arzonlashdi, rekordlar yangilandi. Aslini olganda, electrocarlar yangilik emas, birinchi marta 19-asrda ishlab chiqilgan. Faqat o'sha vaqt ilm-fan va texnologiyasi elektrocarlar rivojlanishi uchun yetarli emas edi.

Balki, shunga o'xshash jarayon yaqin kelajakda komputerlar industriyasida ham sodir bo'lar? Balki analog komputerlar yana sahnaga qaytar?
Balki kvant komputerlarini general use uchun ishlatish imkoniyati paydo bo'lar?
Kuzatamiz...

Bugun statistics kursida R tili bilan ishlab ko'rdik. Statistics uchun maxsus ishlab chiqilgan til ekan. Shuning uchun computer sciencening qoidalariga tupurib qo'ygan.

Siz computer scientist bo'lsangiz, tilni ko'rib chiqishda ehtiyot bo'lishni maslahat beraman. Allergiya qo'zg'atishi mumkin ))

Bizning sohamizda texnologiya haqida hech narsa bilmaydigan managerdan ko'ra texnologiya haqida ozgina biladigan manager xavfliroq bo'lsa kerak. Sababi, texnologiyadan xabari yo'q manager muhim texnik qarorlarni ishini yaxshi biladiganlarga qo'yib beradi. Bu sohada ozgina, yuzaki bilimi bor manager esa odatda hamma narsani shu bilganlariga qarab o'lchaydi va noto'g'ri qarorlar qilishi mumkin.

Masalan, hozir bizda kerak joyda ham, keraksiz joyda ham microservices qurish "moda" bo'lgan. Bunga asosiy sabablardan biri (lekin yagona sabab emas) monolith bir tiyinga qimmat va microservices hamma muammoni hal qila oladi degan o'ta yuzaki fikrga yopishib olgan managerlar. Lekin bu arxitekturaning "lekin"larini yaxshi bilishmaydi. Natijada development team bosim bilan ishlaydi, mahsulot sifati tushadi va h.k. Lekin boshida shu muammolar chiqishini aytganingda quloq solishmaydi. Oxiri borib yana asosiy "aybdor" bechora engineer bo'lib chiqadi.

P.S. Bu yerda gap aynan bir kishi yoki tashkilotga qaratilmagan. Bu faqat o'nlab managerlar va yuzlab engineerlar bilan gaplashish natijasida olgan xulosalarim.

OOPning kelib chiqish sabablari va OOP falsafasi haqida O'zbek tilida yozilgan yaxshi maqola bormi?

Ok, unda @programming_everyone'dan shu mavzuda yaxshi maqola kutamiz ))

Yangilik!

Esingizda bo'lsa TypeScript va Angular bo'yicha pullik onlayn dars o'tgan edim. Shuning yozib olingan videolarini siz azizlarga tekinga ulashishga qaror qildim.

Darslar kimlar uchun ?
1. TypeScriptni o'rganayotganlar uchun.
2. Angularni o'rganayotganlar uchun.

Ushbu link orqali darslar turgan kanalga ulanishingiz va bemalol foydalanishingiz mumkin. Marhamat.
https://t.me/+M3Dy5G9I7A5kMzQy

Alloh manfaatli qilsin.

P.s: Ba'zi hollarni inobatga olib, darslarni yuklab olish va tarqatishni o'chirib qo'ydim. Bu uchun ma'zur tutasiz.

@JoshDeveloper

Good developers know how things work.
Great developers know why things work.

Steve Souders, Head Performance Engineer, Google, 2013

[Meme] Multithreading.
https://redd.it/yef44g

by @programmer_humor

Bir haftadan beri platformamizda database bilan bog'liq jiddiy bir muammoning sababini topa olmayapman.
Hal bo'lsa interviewlar uchun yaxshi story chiqadi lekin.

P.S. Self note.