ஒரு packet trace TCP ZeroWindow என்று காட்டுகிறது. kernel அமைப்பை மாற்றுவதற்கு முன், பூஜ்ஜியத்தை அறிவிக்கும் endpoint எது என்று கண்டறியுங்கள்.

அந்த endpoint அந்த TCP இணைப்பில் தனது பெறுதிறனை விவரிக்கிறது. முழு ப்ராக்சிக்கும் எவ்வளவு bandwidth உள்ளது என்று அது அறிவிக்கவில்லை. zero-window probe அறிவிக்கப்பட்ட திறன் மாறியதா என்பதை அனுப்புநர் அறிய உதவுகிறது; probe மட்டும் packet இழப்பையோ பழுதான ப்ராக்சியையோ நிரூபிக்காது.

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

இவை தனித்தனி TCP உரையாடல்கள். browser ஒரு பெரிய response-ஐ படிப்பதை நிறுத்தி A-வில் பூஜ்ஜியத்தை அறிவிக்கிறது என வைத்துக்கொள்ளுங்கள். ப்ராக்சியின் buffer நிரம்பும்போது அது B-இலிருந்து இழுப்பதை நிறுத்தலாம். பின்னர் B-இல் தோன்றும் zero window மெதுவான client-இன் விளைவாக இருக்கலாம், அசல் பிரச்சினையாக அல்ல.

பதிவேற்றத்தின்போது எதிர் நிலை ஏற்படலாம். இலக்கு பயன்பாடு தரவை நுகர்வதை நிறுத்தினால், B-இல் அதன் window மூடப்படலாம். அழுத்தம் பின்னர் ப்ராக்சியின் buffer வழியாக client-ஐ நோக்கித் திரும்பலாம்.

கவனிப்புகளை வரிசைப்படுத்துங்கள்

  1. இணைப்பின் இரு முனைகளையும் பாதிக்கப்பட்ட தரவுப் பரிமாற்றத்தின் திசையையும் பதிவு செய்யுங்கள்.
  2. சுருங்கும் அல்லது பூஜ்ஜியமான receive window-ஐ முதலில் அறிவித்த endpoint எது என்பதைக் கண்டறியுங்கள்.
  3. அதன் பயன்பாடு படித்துக்கொண்டிருந்ததா, வேறு செயலில் நிறுத்தப்பட்டதா, அல்லது வளங்களால் கட்டுப்படுத்தப்பட்டதா என்பதைச் சரிபாருங்கள்.
  4. அசல் காரணத்தை ஒதுக்குவதற்கு முன் ப்ராக்சியின் மற்ற இணைப்பில் உள்ள நேரத்துடன் ஒப்பிடுங்கள்.

Wireshark-இன் window பகுப்பாய்வு லேபிள்கள் capture-க்கான பயனுள்ள விளக்கங்கள், ஒவ்வொரு receive buffer-ஐயும் அதிகரிக்கும் அறிவுறுத்தல் அல்ல. window scaling-ஐயும் இணைப்பின் பேச்சுவார்த்தையுடன் சேர்த்தே புரிந்துகொள்ள வேண்டும்.

ப்ராக்சி பட்டியலில் இருந்து வேறு endpoint-ஐ முயற்சித்து பரிமாற்றம் மீள்வதைப் பார்ப்பது பாதை மாறியது என்பதற்கான பயனுள்ள ஆதாரம். அது ஒரு இயங்குதளத்தின் TCP செயலாக்கம் குறைபாடுடையது என்று தானாக நிரூபிக்காது. விளக்கத்தை பெறும் செயல்முறையையும் காத்திருப்பு தொடங்கிய இணைப்பையும் சார்ந்தே வைத்திருங்கள்.

தொடர்புடைய கட்டுரைகள்