ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ ಸ್ಟ್ರೀಮಿಂಗ್ vs ಪೂರ್ಣ-ಪ್ರತಿಕ್ರಿಯೆ ಬಫರಿಂಗ್

ಡೌನ್‌ಲೋಡ್ ಕಾಯುತ್ತಿರುವಂತೆ ಕಂಡಾಗ ಮೂರು ಘಟನೆಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ: ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್‌ಗಳು ಬರುವುದು, ಬಾಡಿ ಬೈಟ್‌ಗಳು ಬರುವುದು, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಫಲಿತಾಂಶವನ್ನು ಬಳಸಲು ಅಥವಾ ತೋರಿಸಲು ಸಾಧ್ಯವಾಗುವುದು. ಕೇವಲ ಸ್ಪಿನ್ನರ್ ಯಾವುದು ವಿಳಂಬವಾಗಿದೆ ಎಂದು ಗುರುತಿಸಲಾರದು.

ಸಾಮಾನ್ಯ ಸ್ಟ್ರೀಮಿಂಗ್ ಹಂತಗಳು ಒಂದರ ಮೇಲೊಂದು ಬರಬಹುದು:

origin produces a chunk → proxy forwards bytes → client consumes them

ಪ್ರಾಕ್ಸಿ ರಿಲೇ ಮಾಡುವಾಗ ಸೂಕ್ತವಾದ ವಿಷಯವನ್ನು ಕ್ಯಾಶ್‌ಗೆ ಬರೆಯಬಹುದು. ಕ್ಯಾಶಿಂಗ್ ಇಡೀ ಫೈಲ್‌ಗಾಗಿ ಕಾಯುವ ಅಗತ್ಯವಿಲ್ಲ. Squid ನ read_ahead_gap ವಿತರಣೆಗಿಂತ ಮುಂದೆ ಚಲಿಸುವ ಪಡೆಯುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಇದು ಇನ್ನೊಂದು ರೀತಿಯ ಬಫರಿಂಗ್.

ನಿಧಾನ ಕ್ಲೈಂಟ್ ಔಟ್‌ಪುಟ್ ಸರದಿಗಳನ್ನು ತುಂಬಿದಾಗ ಹಿಮ್ಮುಖ ಒತ್ತಡವು ಮೇಲ್ಮುಖ ಓದುವಿಕೆಯನ್ನು ತಾತ್ಕಾಲಿಕವಾಗಿ ನಿಲ್ಲಿಸಬಹುದು. Content-Length ಕೂಡ ಪೂರ್ಣ ಬಫರಿಂಗ್ ಇಲ್ಲದೆ ಉದ್ದವನ್ನು ನೀಡುತ್ತದೆ. HTTP/1.1 chunked ಎನ್‌ಕೋಡಿಂಗ್ ಕ್ರಮೇಣ ವಿತರಣೆಯನ್ನು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಹಿಂದಿನ ಘಟಕ ಡೇಟಾವನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಂಡರೆ ಕಡಿಮೆ ವಿಳಂಬದ ಭರವಸೆ ನೀಡಲಾರದು.

ನಂತರ ಸಂಸ್ಕರಣಾ ಹಂತಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಮರುಬರವಣಿಗೆ ಅಥವಾ ತಪಾಸಣೆಗೆ ಬಾಡಿಯ ಭಾಗ ಅಥವಾ ಇಡೀ ಬಾಡಿ ಬೇಕಾಗಬಹುದು. ಸಂಕೋಚನ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಚೌಕಟ್ಟು ಉಪಯುಕ್ತ ಔಟ್‌ಪುಟ್ ಅನ್ನು ವಿಳಂಬಗೊಳಿಸಬಹುದು. ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಪೂರ್ಣ ಬೈಟ್ ಸರಣಿಗಾಗಿ ಕಾಯುವ ವಿಧಾನ ತಡವಾಗಿ ಮರಳುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ತೋರಿಸುವ ಮೊದಲೇ ಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು.

ಯಶಸ್ವಿ CONNECT ನಂತರ ಸಾಮಾನ್ಯ ಪ್ರಾಕ್ಸಿ ಟನಲ್ ಮಾಡಿದ ಫೈಲ್‌ನ ಅಂತಿಮ ಉದ್ದವನ್ನು ತಿಳಿಯದೆ ಸೇವಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ರಿಲೇ ಮಾಡುತ್ತದೆ. ಬಫರ್ ಅಥವಾ ಟೈಮೌಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಮೇಲಿನ ಮೊದಲ ಕಾಣೆಯಾದ ಘಟನೆಯನ್ನು ಅನುಸರಿಸಿ. curl ವೀಕ್ಷಕನಾದಾಗ ಅದರ no-buffer ಆಯ್ಕೆ ಸ್ಥಳೀಯ ಔಟ್‌ಪುಟ್ ಹಂತವನ್ನು ಬದಲಿಸುತ್ತದೆ.