Muammolar takrorlanadi

Avvallari 1 ta komputerda 1 ta processgina run bo'la olgan. Keyinroq 1 ta CPU coreda bir nechta "virtual process"(bizga tanish software process)larni qisqa interval bilan navbatma-navbat run qilish orqali CPU coredan effektivroq foydalanish imkoniyati paydo bo'ldi va multiprocessing deb nomlandi.

Ba'zida qisqa vaqt ichida tez-tez yangi process ochib-yopish, bir processdan boshqasiga ma'lumot yuborish kerak bo'ladi. Processlar og'irligi va o'zaro ma'lumot almashish qiyinligi sabab bitta processning o'zida ham bir nechta "tipa process" – thread yaratishga ehtiyoj tug'ildi.

Dizayn jihatdan hammasi yaxshi edi, lekin implementatsiyaga kelganda boshqa bir qancha jiddiy savollar (process forking, signal handling, ...) bilan birga yana bir qiziq savol paydo bo'ldi: threadlarni kernel levelda implement qilish kerakmi yoki user leveldami?
Kernel levelda implement qilish threadga qo'yilgan asosiy talab – yengillik va tezlikni ta'minlab bera olmaydi. User levelda implement qilishda esa scheduling bilan jiddiy muammo chiqadi: agar biror thread I/O call qilsa OS faqat o'sha threadning o'zini emas, butun processni (ya'ni o'sha processdagi hamma threadlarni) bloklaydi. Sababi, kernelda joylashgan scheduler user spacedagi thread nimaligini ham bilmaydi.

Muammoni hal qilish uchun esa user spaceda ishlaydigan va muhimi har bitta threadni alohida schedule qilish imkonini beradigan yechim kerak bo'ldi va qaysidir darajada topildi ham.

***

Qizig'i, xuddi shunga o'xshash jarayon dasturlashning umuman boshqa bir yo'nalishi – network engineeringda ham sodir bo'lgan.

HTTP 1.0 protocolida bir vaqtda faqatgina bitta connection ochish mumkin edi. Bir vaqtda bir nechta resurslarni olishga ehtiyoj tug'ilgani sabab HTTP 1.1 versiyasida bir vaqtda 6 tagacha har biri alohida TCP connection ustiga qurilgan HTTP connection ochish mumkin bo'ldi. Bu yechim ancha omadli chiqqan bo'lsa-da bir qancha sabablar (connectionlarni ochish/yopish og'irligi, asinxron ishlashning imkoni yo'qligi) tufayli yana yangi nimadir o'ylab topish kerak bo'ldi.

HTTP 2.0 bitta TCP connection ustiga ko'plab yengil HTTP connectionlar ochish imkoniyatini taqdim etdi. Endi connectionlar sonini dinamik qilish va asinxron ishlash mumkin bo'ldi. Lekin kutilmaganda bir muammo chiqdi: birorta HTTP connection tarkibidagi birorta paket yetib kelmasa retransmission uchun butun TCP connection (demakki qolgan HTTP connectionlar ham) bloklanadi. Sababi, TCP transport layerda joylashgan va application layerdagi connection nimaligini bilmaydi. Bu muammo HOL Blocking deyiladi.

Bu muammoni hal qilish uchun application leyer va transport layerdagi connectionlar bir-birini "taniydigan" yangi mexanizm – QUIC va HTTP 3 ishlab chiqildi.

@boboshersnotes