Paket izi TCP ZeroWindow ni ko'rsatadi. Kernel sozlamasini o'zgartirishdan oldin nolni e'lon qilayotgan endpointni aniqlang.

Bu endpoint o'sha TCP ulanishdagi qabul qilish quvvatini tavsiflaydi. U butun proxy qancha bandwidthga ega ekanini e'lon qilmaydi. Zero-window probe yuboruvchiga e'lon qilingan quvvat o'zgargan-o'zgarmaganini bilish imkonini beradi; probening o'zi paket yo'qolishini ham, buzuq proxy'ni ham isbotlamaydi.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

Bular ikki alohida TCP suhbati. Brauzer katta javobni o'qishni to'xtatib, A da nolni e'lon qildi deb faraz qiling. Proxy o'z bufferlari to'lganda B dan tortishni oxir-oqibat to'xtatishi mumkin. Keyinchalik B da ko'rilgan zero window sekin mijozning natijasi bo'lishi mumkin, asl muammo emas.

Yuklash paytida teskari holat ham bo'lishi mumkin. Agar manzil dasturi ma'lumotni iste'mol qilishni to'xtatsa, uning B dagi oynasi yopilishi mumkin. Bosim keyin proxy bufferlari orqali mijozga qaytishi mumkin.

Kuzatishlarni tartibga soling

  1. Ulanishning ikki uchini va ta'sirlangan ma'lumot uzatish yo'nalishini qayd eting.
  2. Qaysi endpoint qisqaruvchi yoki nolga tushgan receive window ni birinchi bo'lib e'lon qilganini aniqlang.
  3. Uning dasturi o'qiyotganini, boshqa amalda to'xtab qolganini yoki resurslar bilan cheklanganini tekshiring.
  4. Asl sababni belgilashdan oldin proxy'ning boshqa ulanishidagi vaqtni solishtiring.

Wireshark oynalar tahlili yorliqlari capture uchun foydali talqinlar, har bir receive buffer ni kattalashtirish ko'rsatmasi emas. Window scaling ham ulanishning kelishuvi bilan birga tushunilishi kerak.

Proxy ro'yxatidan boshqa endpointni sinab, uzatishning tiklanishini ko'rish yo'l o'zgarganiga foydali dalildir. Bu o'z-o'zidan bir operatsion tizimning TCP amalga oshirilishi nuqsonli ekanini isbotlamaydi. Tushuntirishni qabul qiluvchi jarayon va kutish boshlangan ulanishga bog'lab turing.

O'xshash maqolalar