Testing is not over-engineering.
AUF☝️

P.S. Change my mind.

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.

@boboshersnotes

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 🙂

@boboshersnotes

DB haqidagi postga comment:
— Backend engineer databaseni yaxshi bilishi qanchalik muhim?
Networking haqidagi postga comment:
— Bularni backend developer bilishi shartmi?
Languagening ichki komponentlari haqidagi postdan keyin:
— Bu ancha chuqur narsalar, bu backendchilarga kerakmi?
System design haqidagi postdan keyin:
— Bu savollar intervyularda so'raladimi?
...

O'rtog'lar, bular kerak bo'lmasa backend engineerning vazifasi nima o'zi?😅

"A Philosophy of Software Design" kitobi muallifi, Stanford universiteti professori John Ousterhout TCP datacenterlarda ishlatish uchun ancha noqulay, Homa protocolga o'tish kerak deb hisoblayapti.
E'tiborimni tortgan jihati, paperda TCPning faqat negativ tomonlari, Homaning faqat pozitiv tomonlariga urg'u berilgan. Balki menga shunday tuyuldi.

Qiziq, kompaniyalar rostdan ham datacenterlardagi communicationni Homaga o'tkazishga qaror qilsa kim birinchi bo'larkin?

Multithreading is just async, but implemented on a lower level.
Change my mind.

P.S. Discussion ochiq deb e'lon qilaman ))

Xususiy bankdan $1.5M o'g'irlandi va bu katta ehtimol bilan bizning sohamizdagilarning xatosi bilan sodir bo'ldi. Bu qolganlarga dars bo'lishi kerak.
Biz esa hamma kanalda anavi .NETchi yigitni muhokama qilayapmiz.

Nagle's algorithm + delayed acknowledgment = ❤️

Rostini aytganda, bu hazil edi (faqat biroz intellektual). "😁" emoji bosganlarning hammasi hazilni tushungan deb umid qilaman. JR aytganidek, endi postlarimga bunisi hazil, bunisi rost deb qo'shib ketaman.

***

Endi postning o'zi haqida.

Nagle's algorithm, TCP delayed ACK, bir-biridan vahimali nomlar juda murakkab tuyulayaptimi? Keling odam tushunadigan tilda gaplashamiz.

Tasavvur qiling 25 ta kursdosh Samarqandga taksida bormoqchisizlar. 6 ta taksiga 4 kishidan 24 kishi yo'lga chiqib ketdi, lekin yana bir kishi qoldi. U o'zi bitta taksiga chiqdi, lekin taksist hali haydamaydi. Nega? Sababi, u hali "to'lmadi". Yana 3 ta odam olsa, keyin yuradi. Faqat 1 kishi bilan haydash o'ziga qimmatga tushadi (metan qimmat). Oddiy mantiq. Xuddi shu narsaning network engineeringdagi nomi Nagle's algorithm deyiladi. Taksi bu TCP segment, talabalar - yuborilayotgan ma'lumot. Oxirgi, to'lmay qolgan segmentga yana data kelmagunicha yoki oldinroq yuborilgan segmentlar uchun ACK kelmagunicha (sheriklari biz Samarqandga yetib keldik demagunicha).
Foydali tomoni - resurslar tejaladi. Zararli tomoni - "kimdir" kech qoladi.

Delayed ACK esa xuddi shu voqeaning davomi, faqat Samarqandda.
Studentlar yetib borganidan keyin yetib keldim deb qolganlarga xabar berishi kerak, lekin xabar berish juda qimmat turadi, studentlar esa tejamkor.
Shunda bittasining aqli ishlab qoladi: hamma alohida-alohida telefon qilmaydi, bir kishi telefon qilib hamma kelganlarni aytib chiqadi (Karl, bizning studentlar tejash uchun nimalarni o'ylab topmagan). Lekin u qachon telefon qiladi? Endi telefonni o'chirganida yana bir kishi yetib kelsa u uchun yana alohida telefon qilish kerakku? Oddiy, yana yarim soat (bu bir misol uchun) kutamiz, hech kim kelmasa telefon qilamiz. Xuddi shu narsa networkingda TCP delayed ACK deyiladi. Studentlar segmentda yetib kelgan ma'lumot, telefon esa server tomonidan segment yetib kelgani haqida yuboriladigan ACK signali.
Foydali tomoni - resurslarni tejaydi. Zararli tomoni - "narigi taraf" segment yetib kelganini kechroq biladi.

Xo'sh, endi qiziq joyi: agar tepadagi ikkita holat bir vaqtda bo'lsa nima bo'ladi.
1 ta student haliyam taksida kutib o'tiribdi. Ketish uchun yo taksi to'lishi kerak, yo yetib borgan sheriklari telefon qilishi kerak. Aksiga olib, boshqa ketadigan odam yo'q, endi sheriklarni kutish kerak. Lekin sheriklar nega telefon qilmayapti? Qizig'i, Samarqandda sheriklari telefon qilmay, hozir sherigimiz kelsa hammamiz bittada telefon qilamiz deb buni kutib o'tiribdi. Bu taksida qolganlarni kutib o'tiribdi, qolganlar Samarqandda buni kutib o'tiribdi, bu nimanidir eslatmayaptimi? DEAD LOCK! Faqat farqi, Samarqanddagilar oxiri sabri tugab, "shuncha kutdik, kelmasang ayb bizdamas" deb telefon qiladi. Taksida o'tirgan talaba buni ko'rib, "4 kishiga to'layman, haydang" deb bir o'zi bitta taksida ketadi. Muammo hal bo'ldi, lekin juda ko'p vaqt bekorchi o'tib ketdi.

Xuddi shu narsa network engineeringda ham bo'lib turadi. Bu tarafda sender segment to'lishini kutadi, narigi tarafda reciever ACK yubormasdan qolgan segment kelishini kutadi, natijada connection UZOQ VAQT "qotib" qoladi.

P.S. Tepadagi postning ma'nosini tushungan bo'lsangiz, endi kulavering ))

Postdan olingan 2 ta xulosa:
1. Taksistlar siyosat tugul dasturlashni ham "qoyillatib" qo'yadi.
2. Talabalar pul tejash uchun har baloni o'ylab topadi.

RDBMS, umuman DBMSlar haqida 20 ta savol.
Qolganlaridan qiyinroq savollar * bilan belgilangan.


1. ACID xususiyatlaridan biri bo'lgan atomicity nimani bildiradi?

2. RDBMSlarda qaysi holatlarda denormalizatsiya qilish foydali hisoblanadi?

3. Database cursor nima? Server-side cursorning client-side cursordan ustun tomoni qaysi?

4. Database engine nima?

5. Read committed va repeatable read izolyatsiya darajalarining orasidagi asosiy farq nimada?

6. Pessimistic Concurrency control nima? Uning qanday kamchiliklari bor?

7*. Transaction snapshot nima?

8*. Serialization anomaliyalaridan biri bo'lgan rw-conflict qachon sodir bo'ladi?

9. Connection pool haqida ma'lumot bering.

10. Clustered index bilan non-clustered indexning farqi nimada?

11*. B-tree va B+tree orasidagi farq nimada?

12. Master va slave replicalar orasida to'liq consistencyni qanday ta'minlash mumkin?

13. Database sharding nima?

14*. Row-based storage nima? U nima uchun OLAP operatsiyalari uchun yaxshi tanlov emas?

15*. WAL nima?

16. PostgreSQLda vacuuming nima?

17. PostgreSQLda index scan va index-only scan bir-biridan qanday farq qiladi?

18. PostreSQLda view nima?

19. PostgreSQLda ANALYZE buyrug'i nima vazifani bajaradi?

20*. PostgreSQLda SELECT FOR UPDATE komandasi nima vazifani bajaradi?


P.S. Bu savollardan ba'zilari backend developer uchun texnik intervyularda tushishi mumkin.

P.S.2. Agar to'g'ri javoblaringiz soni 20 dan kam bo'lsa tabriklayman, o'rganish uchun sizga yangi mavzu topildi.

The feeling of power when you correct someone smarter than you ))

Siz ham menga o'xshab bir vaqtda Pythonning bir nechta versiyalari bilan bir vaqtda ishlashingizga to'g'ri kelsa va versiyalar orasida oson almashish yo'lini izlayotgan bo'lsangiz, pyenv ni ishlatib ko'rishni tavsiya qilaman.
Yengil va foydalanishga oson.

EuroPython 2021 da Sebastian Witowskining shu haqidagi talkini ko'rganimdan beri pyenv ishlataman.
Hozircha biror marta pand bermadi.

Nima?
Nega?
Qanday?

O'rganish uchun men biladigan (va qo'llaydigan) eng yaxshi ketma-ketliklardan biri.
Top-down approach. Kimgadir yoqmasligi mumkin, lekin menga yoqadi.

O'rtog'lar, bu kanalga faqat ilhom kelganida post yoza olaman.
Havotir olib, so'raganlarga rahmat.
Kimdir keyingi postni kutayotganidan xursandman.
Bollar, biz yutamiz 🙂

Ungacha bir ikkita eski postlarni repost qilib turaman.
Yoqsa like bosing, yoqmasa...yam like bosib qo'yavering ))