Squid ಲಾಗ್ಗಳು: 407ರ ನಂತರ 200 ಬಂದರೆ ಅದು ವಿಫಲತೆ ಎಂದು ಪರಿಗಣಿಸಬೇಕೇ?
Squid ಸವಾಲಿನ ನಂತರ ಯಶಸ್ವಿ ಸುರಂಗವನ್ನು ದಾಖಲಿಸಿದಾಗ, ಪೂರ್ಣಗೊಂಡ ಕ್ರಿಯೆಗಳನ್ನು ದೃಢೀಕರಣ ವಿನಿಮಯಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಎಣಿಸಿ.
ಕ್ಲೈಂಟ್ ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳಿಲ್ಲದೆ ಒಂದು ವಿನಂತಿ ಕಳುಹಿಸಿ, ಸವಾಲು ಪಡೆದು ನಂತರ ಯಶಸ್ವಿಯಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಿ. ವಿನಂತಿ ಲಾಗ್ನಲ್ಲಿ ಎರಡು ನಮೂದುಗಳಿರಬಹುದು. ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವ ವ್ಯಕ್ತಿ ಒಂದೇ ಪೂರ್ಣಗೊಂಡ ಕ್ರಿಯೆಯನ್ನು ಅನುಭವಿಸಿದ್ದಾನೆ.
ಆದ್ದರಿಂದ TCP_DENIED/407 ಮತ್ತು TCP_TUNNEL/200 ನಡುವೆ ಸಮಾನವಾಗಿ ವಿಭಜಿಸಲಾದ ಲಾಗ್ ತಾನಾಗಿಯೇ ಐವತ್ತು ಪ್ರತಿಶತ ವಿಫಲತೆ ದರವನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಮೊದಲು ನಮೂದುಗಳು ಸವಾಲು-ಮತ್ತು-ಮರುಪ್ರಯತ್ನ ಜೋಡಿಗಳನ್ನು ರೂಪಿಸುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ.
ನಿಜವಾಗಿ ನಿಮಗೆ ಮುಖ್ಯವಾದದ್ದನ್ನು ಎಣಿಸಿ
| ಅಳತೆ | ಎಣಿಕೆ |
|---|---|
| ದೃಢೀಕರಣ ಸವಾಲುಗಳು | ದೃಢೀಕರಣ ಕೇಳುವ ಪ್ರಾಕ್ಸಿ ಪ್ರತಿಕ್ರಿಯೆಗಳು |
| ಪ್ರಾಕ್ಸಿ ಪ್ರಯತ್ನಗಳು | ಮಧ್ಯವರ್ತಿ ದಾಖಲಿಸುವ ಪ್ರತ್ಯೇಕ ವಹಿವಾಟುಗಳು |
| ಪೂರ್ಣಗೊಂಡ ಕೆಲಸಗಳು | ಉದ್ದೇಶಿತ ಫಲಿತಾಂಶ ತಲುಪುವ ಅಪ್ಲಿಕೇಶನ್ ಕ್ರಿಯೆಗಳು |
ಸಮಯ ಮುದ್ರೆಗಳು, ಕ್ಲೈಂಟ್ ಸಂದರ್ಭ, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಲಭ್ಯವಿರುವ ಯಾವುದೇ ವಿನಂತಿ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಪರಸ್ಪರ ಸಂಬಂಧಿಸಿ. ದೃಢೀಕರಣವಿಲ್ಲದ ಪ್ರಯತ್ನಕ್ಕೆ ದಾಖಲಾದ ಬಳಕೆದಾರಹೆಸರು ಇಲ್ಲದಿರಬಹುದು, ಆದರೆ ಅದರ ಯಶಸ್ವಿ ಮರುಪ್ರಯತ್ನಕ್ಕೆ ಇರುತ್ತದೆ. ಏಕಕಾಲಿಕ ಚಟುವಟಿಕೆ ಎಂದರೆ ಪಕ್ಕದ ಸಾಲುಗಳು ಮಾತ್ರ ಎರಡು ನಮೂದುಗಳು ಒಟ್ಟಿಗೆ ಸೇರಿವೆ ಎಂಬುದಕ್ಕೆ ದುರ್ಬಲ ಸಾಕ್ಷ್ಯ.
ಯಶಸ್ವಿ ಸುರಂಗವನ್ನು ಯಶಸ್ವಿ ವೆಬ್ಸೈಟ್ ಕ್ರಿಯೆಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. CONNECT ಸ್ವೀಕಾರ ಸುರಂಗವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ; ಗಮ್ಯಸ್ಥಾನವು ಇನ್ನೂ TLS ಸಮಯದಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು ಅಥವಾ ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದು.
ಪುನರಾವರ್ತಿತ ಅಂತಿಮ ಸವಾಲುಗಳು, ನಂತರ ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದ ಕೆಲಸಗಳು ಅಥವಾ ವಿನಿಮಯಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಹಠಾತ್ ಬದಲಾವಣೆಯನ್ನು ತನಿಖೆ ಮಾಡಿ. ಇವು ತಮ್ಮ ಸಂರಚನೆ ಕೇಳಿದ್ದನ್ನು ನಿಖರವಾಗಿ ಮಾಡುವ ಸ್ಥಿರ ಸವಾಲು-ಮೊದಲ ಕ್ಲೈಂಟ್ಗಿಂತ ಭಿನ್ನವಾಗಿವೆ. ಕೇವಲ ಡ್ಯಾಶ್ಬೋರ್ಡ್ ಹಸಿರಾಗಿಸಲು ದೃಢೀಕರಣವನ್ನು ಒತ್ತಡಕ್ಕೆ ಒಳಪಡಿಸುವುದು ಅಳತೆಯನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ಸೇವೆಯನ್ನೇ ಬದಲಾಯಿಸುತ್ತದೆ.