Нулявое вакно TCP праз проксі: вызначце атрымальніка

Знайдзіце кіраванне патокам TCP на баку кліента або сервера проксі, перш чым прыпісваць прыпыненае спампоўванне маштабаванню вокнаў або памеру буфера.

Траса пакетаў паказвае TCP ZeroWindow. Перш чым змяняць параметр ядра, вызначце канчатковы пункт, які абвяшчае нуль.

Гэты пункт апісвае сваю здольнасць прыёму ў гэтым злучэнні TCP. Ён не абвяшчае, колькі прапускной здольнасці мае ўвесь проксі. Праверка нулявога вакна дазваляе адпраўніку даведацца, ці змянілася абвешчаная здольнасць; адна праверка не даказвае страты пакетаў або зламанага проксі.

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

Гэта розныя размовы TCP. Выкажам здагадку, што браўзер перастаў чытаць вялікі адказ і абвясціў нуль на A. Проксі з цягам часу можа перастаць асушваць B, калі яго ўласныя буферы запоўняцца. Пазнейшае нулявое вакно на B можа быць вынікам павольнага кліента, а не першапачатковай праблемай.

Адваротная сітуацыя магчымая падчас загрузкі. Калі прыкладанне-атрымальнік перастае спажываць даныя, яго вакно на B можа зачыніцца. Тады ціск можа вярнуцца да кліента праз буферы проксі.

Упарадкуйце назіранні

  1. Запішыце канчатковыя пункты злучэння і кірунак закранутай перадачы даных.
  2. Вызначце, які пункт першым абвясціў паменшанае або нулявое вакно прыёму.
  3. Праверце, ці чытала яго прыкладанне, ці спынілася на іншай аперацыі, ці было абмежавана рэсурсамі.
  4. Параўнайце час на іншым злучэнні проксі, перш чым прызначаць першапачатковую прычыну.

Меткі аналізу вокнаў Wireshark — гэта карысныя інтэрпрэтацыі запісу, а не ўказанне павялічваць кожны буфер прыёму. Маштабаванне вокнаў таксама трэба тлумачыць з улікам перамоў злучэння.

Спроба іншага пункта з спісу проксі і назіранне аднаўлення перадачы — карысны доказ, што шлях змяніўся. Але сам па сабе ён не даказвае, што рэалізацыя TCP у пэўнай аперацыйнай сістэме была дэфектнай. Трымайце тлумачэнне прывязаным да працэсу прыёму і злучэння, дзе пачалося чаканне.

Падобныя артыкулы