Read timeout — ulanish o‘rnatilgandan keyin mijozning serverdan ma’lumot kelishini kutishiga qo‘yilgan vaqt chegarasidir. Belgilangan oraliqda kerakli baytlar olinmasa, o‘qish amali bekor qilinadi va dastur timeout xatosini oladi. Bu tushuncha connect timeoutdan farq qiladi: birinchisi javob oqimini, ikkinchisi esa aloqa kanalini yaratishni nazorat qiladi.
Hisoblash usullari
Kutubxona va protokolga qarab read timeout turli ma’noga ega bo‘lishi mumkin. Eng ko‘p uchraydigan talqinda u ketma-ket ikki o‘qish orasidagi harakatsizlik muddatidir. Server vaqti-vaqti bilan kichik ma’lumot yuborsa, umumiy javob juda uzoq davom etsa ham timeout yuz bermaydi. Boshqa amalga oshirishlarda muddat butun javobni olish uchun beriladi. Shu sababli konfiguratsiyada “idle timeout”, “response timeout” va “request timeout” atamalarini aniq ajratish kerak.
Oqimli video, katta fayl yoki server-sent events kabi uzoq yashovchi javoblarda harakatsizlik muddati foydaliroq. Oddiy API chaqirig‘ida esa umumiy deadline ham kerak, aks holda sekin oqim resursni cheksiz band qilishi mumkin. Javob sarlavhalarini kutish va javob tanasini o‘qish uchun alohida chegaralar qo‘yadigan mijozlar ham mavjud.
Sabablar va ta’sir
Read timeout serverning sekin hisoblashidan, ma’lumotlar bazasidagi blokirovkadan, tarmoq paketlari yo‘qolishidan yoki javobning oraliq proksi tomonidan ushlab turilishidan kelib chiqishi mumkin. Timeout mijoz tomonda ko‘rinsa-da, asosiy sabab bog‘liqlik zanjirining boshqa nuqtasida bo‘lishi ehtimol. Mijoz amalni to‘xtatganidan keyin server ishni davom ettirishi ham mumkin; bekor qilish signali server va quyi xizmatlarga uzatilmasa, behuda hisoblash saqlanib qoladi.
Qisman javob olingan bo‘lsa, uni to‘liq natija sifatida ishlatish xavfli. Protokol kadr chegaralari, Content-Length yoki nazorat summasi orqali javobning tugallanganini aniqlashi mumkin. Fayl yuklashda vaqtinchalik fayl va atomik nom almashtirish yarim yozilgan ma’lumotni haqiqiy nusxa deb qabul qilishning oldini oladi.
Qayta urinish va xavfsizlik
O‘qish tugamaganida so‘rov serverga yetib borgan-bormagani noma’lum bo‘lishi mumkin. GET kabi o‘zgartirmaydigan amalni qayta bajarish ko‘pincha xavfsiz, ammo to‘lov yoki buyurtma yaratish kabi amal takroriy ta’sir keltirib chiqaradi. Bunday operatsiyalarda idempotency key, tranzaksiya identifikatori yoki natijani tekshirish mexanizmi qo‘llanadi. Qayta urinishlar soni va umumiy deadline cheklanishi lozim.
Mos qiymat xizmatning normal kechikish taqsimoti va biznes talabiga qarab belgilanadi. P50 bilan birga P95 va P99 ko‘rsatkichlari kuzatiladi. Read timeoutlarni endpoint, bog‘liqlik va javob bosqichi bo‘yicha ajratish sekinlik manbasini topishni osonlashtiradi. Haddan tashqari ko‘p timeout server quvvatini oshirishdan oldin so‘rovlar navbati, indekslar, blokirovkalar va tarmoq sifatini tekshirishni talab qiladi.
Server va proksi chegaralari
Mijoz read timeoutidan tashqari reverse proxy, load balancer va serverning o‘z response timeouti bo‘lishi mumkin. Eng tashqi qatlam ertaroq uzilsa, ichki xizmatning uzoq muddat ishlashi natija bermaydi. Chegaralar odatda ichkariga qarab biroz qisqarib, har qatlamga xatoni qayta ishlash va javob yuborish uchun vaqt qoldiradi. Heartbeat oqimni faol ko‘rsatishi mumkin, ammo u haqiqiy foydali progressni kafolatlamaydi; katta ishda progress belgisi va umumiy deadline birga qo‘llanadi. Timeout konfiguratsiyasi deploydan keyin endpointlar kesimida kuzatilib, normal sekin so‘rovlar bilan nosozliklar farqlanadi.
Server javob yozishni boshlashidan oldin sarlavha yuborib timeoutni aldab o‘tmasligi kerak. Protokol va monitoring foydali natija qachon boshlanganini alohida o‘lchaydi.
Bog‘liq tushunchalar
Connect timeout, Deadline, HTTP, Streaming, Idempotency, Retry, Cancellation