ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ TCP ವಿಭಾಗಗಳ ಗಡಿಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ

Squid ಮೂಲಕ ಹಾದುಹೋದ ನಂತರ HTTP ಪ್ರತಿಕ್ರಿಯೆಯು ಸೆರೆಹಿಡಿಯಲಾದ ಹಲವು TCP ವಿಭಾಗಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ. ಅದು ಸಾಮಾನ್ಯ TCP ವರ್ತನೆಯಾಗಿರಬಹುದು, ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತಪ್ಪಾಗಿ ವಿಭಜಿಸಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.

ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ಸಂಪರ್ಕಗಳಿರುತ್ತವೆ:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೂ ತನ್ನದೇ TCP ಸ್ಥಿತಿ, ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಮತ್ತು ಪ್ಯಾಕೆಟೀಕರಣ ಇರುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಒಂದು ಸಂಪರ್ಕದಿಂದ ಡೇಟಾ ಓದಿ ಇನ್ನೊಂದಕ್ಕೆ ಬರೆಯಬಹುದು, ಮೂಲ ವಿಭಾಗದ ಗಾತ್ರಗಳನ್ನು ಉಳಿಸದೆ. ಬಫರಿಂಗ್, ಕಳುಹಿಸುವ ಸಮಯ, ದಟ್ಟಣೆ ಮತ್ತು ಮಾರ್ಗದ ಗಾತ್ರ ಮಿತಿಗಳು ಬೇರೆ ಗುಂಪನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಬೇಕಾದ ಮೂರು ಗಡಿಗಳು

ಒಂದು ಓದುವಿಕೆಯಲ್ಲಿ ಹೆಡರ್‌ನ ಒಂದು ಭಾಗ, ಪೂರ್ಣ ಹೆಡರ್ ಜೊತೆಗೆ ಬಾಡಿ ಬೈಟ್‌ಗಳು, ಅಥವಾ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಅನ್ವಯಿಕ-ಹಂತದ ಗಡಿಗಳನ್ನು ದಾಟುವ ಡೇಟಾ ಇರಬಹುದು. TCP “HTTP ಪ್ರತಿಕ್ರಿಯೆಯ ಅಂತ್ಯ”ವನ್ನು ಯಶಸ್ವಿ ಓದುವಿಕೆಯ ಅಂತ್ಯಕ್ಕೆ ಜೋಡಿಸುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ HTTP/1.1 ಪಾರ್ಸರ್ ಹೆಡರ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಅನ್ವಯವಾಗುವ ಬಾಡಿ-ಚೌಕಟ್ಟು ನಿಯಮಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಅವುಗಳಲ್ಲಿ ಉದ್ದ, ಸಾಗಣೆ ಕೋಡಿಂಗ್ ಅಥವಾ ಅನುಮತಿಸಿದ ಸಂಪರ್ಕ ಮುಚ್ಚುವಿಕೆ ಸೇರಿವೆ. HTTP/2 ಚೌಕಟ್ಟು ಸ್ವತಃ TCP ವಿಭಾಗಗಳನ್ನು ದಾಟಬಲ್ಲ ಪ್ರೋಟೋಕಾಲ್ ರಚನೆ; ಅದು ಜಾಲ ಪ್ಯಾಕೆಟ್‌ನ ಇನ್ನೊಂದು ಹೆಸರಲ್ಲ.

ಯಶಸ್ವಿ CONNECT ಸುರಂಗವು ಸುರಂಗದ ಬೈಟ್ ಹರಿವನ್ನು ಉಳಿಸುತ್ತದೆ, ಆದರೂ ಎರಡು TCP ಪಾದಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಸುರಂಗದೊಳಗಿನ ಬೈಟ್‌ಗಳನ್ನು ಬದಲಿಸದಿದ್ದರೂ ಅದರ ವಿಭಾಗ ಗಡಿಗಳು ಭಿನ್ನವಾಗಿರಬಹುದು.

ಹಾನಿಯನ್ನು ತನಿಖೆ ಮಾಡುವಾಗ ಮರುಜೋಡಿಸಿದ ಅನ್ವಯಿಕ ಡೇಟಾವನ್ನು ಹೋಲಿಸಿ. ಪ್ಯಾಕೆಟ್ ಎಣಿಕೆಗಳನ್ನು ಹೋಲಿಸುವುದು ಅಥವಾ ಎರಡೂ ಬದಿಗಳಲ್ಲಿ ಒಂದೇ ಪ್ಯಾಕೆಟ್ ಉದ್ದವನ್ನು ನಿರೀಕ್ಷಿಸುವುದು TCP ಯಿಂದ ಅದು ನೀಡದ ಗಡಿ ಖಾತರಿಯನ್ನು ಕೇಳುವುದು.