Փաթեթների հետքը ցույց է տալիս TCP ZeroWindow։ Մինչ միջուկի կարգավորումը փոխելը, նույնականացրե՛ք այն ծայրակետը, որը հայտարարում է զրոն։

Այդ ծայրակետը նկարագրում է իր ընդունման հնարավորությունը տվյալ TCP կապում։ Այն չի հայտարարում, թե որքան թողունակություն ունի ամբողջ պրոքսին։ Զրոյական պատուհանի փորձարկումը թույլ է տալիս ուղարկողին իմանալ՝ փոխվե՞լ է հայտարարված հնարավորությունը. փորձարկումներն ինքնին չեն ապացուցում փաթեթների կորուստ կամ խափանված պրոքսի։

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

Սրանք առանձին TCP զրույցներ են։ Ենթադրենք՝ զննարկիչը դադարում է կարդալ մեծ պատասխան և A-ի վրա հայտարարում զրո։ Պրոքսին ի վերջո կարող է դադարել դատարկել B-ն, երբ լցվեն իր բուֆերները։ B-ի վրա ավելի ուշ երևացող զրոյական պատուհանը կարող է դանդաղ սպասարկողի հետևանք լինել, ոչ թե սկզբնական խնդիրը։

Հակառակ իրավիճակը հնարավոր է վերբեռնման ժամանակ։ Եթե նպատակակետ ծրագիրը դադարում է սպառել տվյալները, B-ի վրա նրա պատուհանը կարող է փակվել։ Ճնշումն այնուհետև կարող է վերադառնալ սպասարկողի կողմ պրոքսիի բուֆերներով։

Դասավորե՛ք դիտարկումները

  1. Գրանցե՛ք կապի ծայրակետերը և տուժած տվյալների փոխանցման ուղղությունը։
  2. Որոշե՛ք, թե որ ծայրակետն առաջինը հայտարարեց նվազող կամ զրոյական ընդունման պատուհան։
  3. Ստուգե՛ք՝ դրա ծրագիրը կարդո՞ւմ էր, կանգնե՞լ էր այլ գործողության վրա, թե՞ սահմանափակված էր ռեսուրսներով։
  4. Համեմատե՛ք ժամանակագրությունը պրոքսիի մյուս կապում, նախքան սկզբնական պատճառը նշելը։

Wireshark-ի պատուհանի վերլուծության պիտակները գրառման օգտակար մեկնաբանություններ են, ոչ թե հրահանգ՝ մեծացնել բոլոր ընդունման բուֆերները։ Պատուհանի մասշտաբը նույնպես պետք է մեկնաբանվի՝ հաշվի առնելով կապի բանակցությունը։

Պրոքսիների ցանկից այլ ծայրակետ փորձելը և փոխանցման վերականգնումը տեսնելը օգտակար ապացույց է, որ ուղին փոխվել է։ Սակայն դա ինքնին չի ապացուցում, որ որևէ օպերացիոն համակարգի TCP իրականացումը թերի է եղել։ Բացատրությունը պահե՛ք կապված ընդունող գործընթացի և այն կապի հետ, որտեղ սկսվել է սպասումը։

Առնչվող հոդվածներ