ಎಂಟು ಬೈಟ್ ಓದಿ, ನಂತರ SOCKS4 ಸುರಂಗವನ್ನು ಒಪ್ಪಿಸಿ
SOCKS4 ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ಥಿರ ಗಡಿಯನ್ನು ವಿಶ್ಲೇಷಿಸಿ ಗಮ್ಯಸ್ಥಾನದ ಅಭಿವಾದನೆಯನ್ನು ನುಂಗುವುದನ್ನು ಅಥವಾ ಇಲ್ಲದ ಬೈಟ್‌ಗಳಿಗೆ ಕಾಯುವುದನ್ನು ತಪ್ಪಿಸಿ.
SOCKS4 ಸಂಪರ್ಕ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸರ್ವರ್‌ನ ಆರಂಭಿಕ ಅಭಿವಾದನೆಯನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ. ನೋಡಬೇಕಾದ ಒಂದು ಸ್ಥಳ ಕನೆಕ್ಟರ್‌ನ ಮೊದಲ ಓದು. ಹದಿನಾರು ಬೈಟ್‌ಗಳ ಓದು ಎಂಟು ಬೈಟ್‌ನ SOCKS4 ಪ್ರತಿಕ್ರಿಯೆಗೆ ತುಂಬಾ ದೊಡ್ಡದು.
| ಪ್ರತಿಕ್ರಿಯೆ ಕ್ಷೇತ್ರ | ಬೈಟ್‌ಗಳು |
|---|---|
| ಪ್ರತಿಕ್ರಿಯೆ ಆವೃತ್ತಿ ಕ್ಷೇತ್ರ | 1 |
| ಫಲಿತಾಂಶ ಸಂಕೇತ | 1 |
| ಪೋರ್ಟ್ ಕ್ಷೇತ್ರ | 2 |
| ವಿಳಾಸ ಕ್ಷೇತ್ರ | 4 |
ಫಲಿತಾಂಶ ಸಂಕೇತ 0x5a ವಿನಂತಿ ಅನುಮೋದಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. SOCKS4a ವಿನಂತಿ ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ಹೇಗೆ ಒಯ್ಯುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ; ಅದು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹದಿನಾರು ಬೈಟ್ ಮಾಡುವುದಿಲ್ಲ.
ಪ್ರತಿಕ್ರಿಯೆಯ ನಂತರ ಅದೇ TCP ಸ್ಟ್ರೀಮ್ ಗಮ್ಯಸ್ಥಾನದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಒಯ್ಯುತ್ತದೆ. ಮೇಲ್ ಸರ್ವರ್ ತನ್ನ ಅಭಿವಾದನೆಯನ್ನು ತಕ್ಷಣ ಕಳುಹಿಸಬಹುದು. ಆದ್ದರಿಂದ ಹದಿನಾರು ಲಭ್ಯವಿರುವ ಬೈಟ್‌ಗಳನ್ನು ಬಳಸುವ ಓದು ಪೂರ್ಣ ಪ್ರಾಕ್ಸಿ ಪ್ರತಿಕ್ರಿಯೆಯ ಜೊತೆಗೆ ಆ ಅಭಿವಾದನೆಯ ಮೊದಲ ಎಂಟು ಬೈಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು. ಇನ್ನೂ ಏನೂ ಬಾರದಿದ್ದರೆ, ತುಂಬಾ ದೊಡ್ಡ ಬ್ಲಾಕಿಂಗ್ ಓದು ಬದಲಿಗೆ ಅನಗತ್ಯ ಕಾಯುವಿಕೆಯನ್ನು ಸೇರಿಸಬಹುದು.
ನಿಖರ ಉದ್ದ ಪಾರ್ಸರ್‌ನ ಜವಾಬ್ದಾರಿ
ಒಮ್ಮೆ ಎಂಟು ಬೈಟ್ ಕೇಳುವುದು ಎಂಟು ಬೈಟ್ ಬಂದಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕಷ್ಟು ಸಾಕ್ಷ್ಯವಲ್ಲ. ಸ್ಟ್ರೀಮ್ ಓದುಗಳು ಕಡಿಮೆ ಹಿಂತಿರುಗಿಸಬಹುದು. ಗಡುವಿನೊಳಗೆ ಪ್ರತಿಕ್ರಿಯೆಯ ಉದ್ದವನ್ನು ನಿಖರವಾಗಿ ಸಂಗ್ರಹಿಸಿ, ಮುಚ್ಚಿದ ಅಥವಾ ವಿಫಲ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮುಂದಿನ ಬೈಟ್‌ಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಬಿಡಿ.
ಕನೆಕ್ಟರ್ ದೊಡ್ಡ ಬಫರ್ ಓದನ್ನು ಬಳಸಿದರೆ, ಗಡಿಯ ನಂತರದ ಎಲ್ಲವನ್ನೂ ಉಳಿಸಿ ಮುಂದಿನ ಗ್ರಾಹಕರಿಗೆ ರವಾನಿಸಿ. ಹೆಚ್ಚುವರಿಯನ್ನು ಎಸೆಯುವುದು ಬೇರೆ ಓದಿನ ಗಾತ್ರದೊಂದಿಗೆ ಅದೇ ದತ್ತಾಂಶ ನಷ್ಟ.
SOCKS5 ಗೆ ಅದರ ಸ್ವಂತ ಪಾರ್ಸರ್ ಬೇಕು. ಅದರ ಪ್ರತಿಕ್ರಿಯೆ ವಿಳಾಸದ ಉದ್ದ ವಿಳಾಸ ಪ್ರಕಾರದಂತೆ ಬೇರೆಯಾಗಿರಬಹುದು. ಪ್ರತಿ ಪ್ರಾಕ್ಸಿ ಓದನ್ನು ಸ್ಥಿರ ಎಂಟು ಬೈಟ್ ಓದಿನಿಂದ ಬದಲಿಸುವುದು ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಸರಿಪಡಿಸಿ ಇನ್ನೊಂದನ್ನು ಮುರಿಯುತ್ತದೆ.