ਪੈਕਟ ਟਰੇਸ TCP ZeroWindow ਦਿਖਾਉਂਦਾ ਹੈ। ਕਰਨਲ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਅੰਤ ਬਿੰਦੂ ਪਛਾਣੋ ਜੋ ਜ਼ੀਰੋ ਦਾ ਐਲਾਨ ਕਰ ਰਿਹਾ ਹੈ।

ਉਹ ਅੰਤ ਬਿੰਦੂ ਉਸ TCP ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਆਪਣੀ ਪ੍ਰਾਪਤੀ ਸਮਰੱਥਾ ਦੱਸ ਰਿਹਾ ਹੈ। ਇਹ ਨਹੀਂ ਦੱਸ ਰਿਹਾ ਕਿ ਪੂਰੀ ਪ੍ਰੌਕਸੀ ਕੋਲ ਕਿੰਨੀ ਬੈਂਡਵਿਡਥ ਹੈ। ਜ਼ੀਰੋ-ਵਿੰਡੋ ਪ੍ਰੋਬ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਦੱਸਣ ਦਿੰਦਾ ਹੈ ਕਿ ਐਲਾਨੀ ਸਮਰੱਥਾ ਬਦਲੀ ਹੈ ਜਾਂ ਨਹੀਂ; ਸਿਰਫ਼ ਪ੍ਰੋਬ ਪੈਕਟ ਨੁਕਸਾਨ ਜਾਂ ਖਰਾਬ ਪ੍ਰੌਕਸੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੇ।

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

ਇਹ ਵੱਖਰੀਆਂ TCP ਗੱਲਬਾਤਾਂ ਹਨ। ਮੰਨ ਲਓ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਵੱਡਾ ਜਵਾਬ ਪੜ੍ਹਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ A ਉੱਤੇ ਜ਼ੀਰੋ ਐਲਾਨਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਆਪਣੇ ਬਫਰ ਭਰਨ ਨਾਲ ਅਖੀਰ B ਨੂੰ ਖਾਲੀ ਕਰਨਾ ਬੰਦ ਕਰ ਸਕਦੀ ਹੈ। B ਉੱਤੇ ਬਾਅਦ ਵਿੱਚ ਦਿਖਣ ਵਾਲੀ ਜ਼ੀਰੋ ਵਿੰਡੋ ਮੂਲ ਸਮੱਸਿਆ ਨਹੀਂ, ਹੌਲੀ ਕਲਾਇੰਟ ਦਾ ਨਤੀਜਾ ਹੋ ਸਕਦੀ ਹੈ।

ਅੱਪਲੋਡ ਦੌਰਾਨ ਉਲਟ ਸਥਿਤੀ ਸੰਭਵ ਹੈ। ਜੇ ਮੰਜ਼ਿਲ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਵਰਤਣਾ ਬੰਦ ਕਰ ਦੇਵੇ, ਤਾਂ B ਉੱਤੇ ਇਸ ਦੀ ਵਿੰਡੋ ਬੰਦ ਹੋ ਸਕਦੀ ਹੈ। ਫਿਰ ਦਬਾਅ ਪ੍ਰੌਕਸੀ ਦੇ ਬਫਰ ਰਾਹੀਂ ਕਲਾਇੰਟ ਵੱਲ ਵਾਪਸ ਜਾ ਸਕਦਾ ਹੈ।

ਨਿਰੀਖਣਾਂ ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਰੱਖੋ

  1. ਕਨੈਕਸ਼ਨ ਦੇ ਦੋਵੇਂ ਸਿਰੇ ਅਤੇ ਪ੍ਰਭਾਵਿਤ ਡੇਟਾ ਤਬਾਦਲੇ ਦੀ ਦਿਸ਼ਾ ਦਰਜ ਕਰੋ।
  2. ਪਛਾਣੋ ਕਿ ਕਿਹੜੇ ਸਿਰੇ ਨੇ ਪਹਿਲਾਂ ਸੁੰਗੜਦੀ ਜਾਂ ਜ਼ੀਰੋ ਪ੍ਰਾਪਤੀ ਵਿੰਡੋ ਦਾ ਐਲਾਨ ਕੀਤਾ।
  3. ਜਾਂਚੋ ਕਿ ਇਸ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਪੜ੍ਹ ਰਹੀ ਸੀ, ਕਿਸੇ ਹੋਰ ਕੰਮ ਉੱਤੇ ਰੁਕੀ ਸੀ, ਜਾਂ ਸਰੋਤਾਂ ਨਾਲ ਸੀਮਿਤ ਸੀ।
  4. ਮੂਲ ਕਾਰਨ ਨਿਰਧਾਰਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰੌਕਸੀ ਦੇ ਦੂਜੇ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

Wireshark ਦੇ ਵਿੰਡੋ ਵਿਸ਼ਲੇਸ਼ਣ ਲੇਬਲ ਕੈਪਚਰ ਦੀ ਲਾਹੇਵੰਦ ਵਿਆਖਿਆ ਹਨ, ਹਰ ਪ੍ਰਾਪਤੀ ਬਫਰ ਵਧਾਉਣ ਦਾ ਨਿਰਦੇਸ਼ ਨਹੀਂ। ਵਿੰਡੋ ਸਕੇਲਿੰਗ ਨੂੰ ਵੀ ਕਨੈਕਸ਼ਨ ਦੀ ਗੱਲਬਾਤ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪ੍ਰੌਕਸੀ ਸੂਚੀ ਤੋਂ ਦੂਜਾ ਅੰਤ ਬਿੰਦੂ ਅਜ਼ਮਾ ਕੇ ਤਬਾਦਲੇ ਦਾ ਸੁਧਰਨਾ ਇਸ ਗੱਲ ਦਾ ਲਾਹੇਵੰਦ ਸਬੂਤ ਹੈ ਕਿ ਰਾਹ ਬਦਲਿਆ। ਪਰ ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਿਸੇ ਆਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦਾ TCP ਕਾਰਜਾਨਵਿਤਨ ਖਰਾਬ ਸੀ। ਵਿਆਖਿਆ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਉਸ ਕਨੈਕਸ਼ਨ ਨਾਲ ਜੋੜੀ ਰੱਖੋ ਜਿੱਥੇ ਉਡੀਕ ਸ਼ੁਰੂ ਹੋਈ ਸੀ।

ਸੰਬੰਧਿਤ ਲੇਖ