ಸಂಖ್ಯೆಗಳಿಗೆ ಅರ್ಥ ಇರುವಂತೆ VPN ವೇಗವನ್ನು ಪರೀಕ್ಷಿಸುವುದು ಹೇಗೆ
ಪರೀಕ್ಷಾ ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ, ಕೆಳ ಪದರವನ್ನು ಚಲಿಸದೆ ಇರಿಸಿ ಮತ್ತು ವಿಳಂಬವನ್ನು ಥ್ರೂಪುಟ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಓದಿ. ಟನೆಲ್ ಏನನ್ನೂ ಅಳೆಯುವ ಮೊದಲೇ ಮಾರ್ಗವನ್ನು ಬದಲಿಸುತ್ತದೆ.
ವೇಗ ಪರೀಕ್ಷೆ ಎಂದಿಗೂ VPN ಅನ್ನು ಅಳೆಯುವುದಿಲ್ಲ. ಅದು ಒಂದು ಮಾರ್ಗವನ್ನು ಅಳೆಯುತ್ತದೆ, ಮತ್ತು ಟನೆಲ್ ಆನ್ ಮಾಡಿದಾಗ ಮೊದಲ ಬೈಟ್ ಚಲಿಸುವ ಮೊದಲೇ ಆ ಮಾರ್ಗದ ಒಂದು ಭಾಗ ಬದಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ಒಂದೇ ಲ್ಯಾಪ್ಟಾಪ್ ಒಂದು ಸೈಟ್ನಲ್ಲಿ ಆರೋಗ್ಯಕರ ಸಂಖ್ಯೆ ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಕಳಪೆ ಸಂಖ್ಯೆ ತೋರಿಸುತ್ತದೆ, ಎರಡೂ ಕಡೆ ಏನೂ ಬದಲಾಗದಿದ್ದರೂ. ಫಲಿತಾಂಶವನ್ನು ಮಾರ್ಗದ ಬಗ್ಗೆ ಸಾಕ್ಷಿಯಾಗಿ ಓದಿ, ಉತ್ಪನ್ನದ ಅಂಕವಾಗಿ ಅಲ್ಲ.
ಹೋಲಿಕೆ ಏನಾದರೂ ಮೌಲ್ಯವಿದೆಯೇ ಎಂದು ಮೂರು ವಿಷಯಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಎರಡೂ ರನ್ಗಳು ಒಂದೇ ಗುರಿಯನ್ನು ತಲುಪಿದವೆಯೇ, ಪ್ರವೇಶ ಜಾಲ ಸ್ಥಿರವಾಗಿ ಉಳಿಯಿತೇ, ಮತ್ತು ನೀವು ಪರಿಮಾಣದ ಜೊತೆಗೆ ವಿಳಂಬವನ್ನು ದಾಖಲಿಸಿದಿರಾ.
ಮೊದಲ ಬೈಟ್ಗಿಂತ ಮೊದಲು ಟನೆಲ್ ಏನನ್ನು ಮರುಬರೆಯುತ್ತದೆ
ಕ್ಲೈಂಟ್ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಇನ್ನೊಂದು ಹೆಡರ್ನಲ್ಲಿ ಸುತ್ತುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ ಉಪಯುಕ್ತ ಪೇಲೋಡ್ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ವೆಚ್ಚವು ಪ್ರತಿ ವರ್ಗಾವಣೆಗೆ ಅಲ್ಲ, ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ, ಅಂದರೆ ದೊಡ್ಡ ಫೈಲ್ಗೆ ಟನೆಲ್ ಇಲ್ಲದೆ ಕಳುಹಿಸಿದ ಅದೇ ಫೈಲ್ಗಿಂತ ಹೆಚ್ಚು ಪ್ಯಾಕೆಟ್ಗಳು ಬೇಕು. ಅಂತಹ ಹೆಚ್ಚುವರಿ ವೆಚ್ಚವು ಕಾಣುವ ಸೆಟ್ಟಿಂಗ್ ಆಗಿ ಅಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಸಂಖ್ಯೆಯಾಗಿ ಕಾಣುತ್ತದೆ.
ಅದರಿಂದ ಎರಡು ಪರಿಣಾಮಗಳು ಬರುತ್ತವೆ. ದೊಡ್ಡ ಬ್ಲಾಕ್ಗಳಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ನ ವೆಚ್ಚವನ್ನು ಅನುಭವಿಸುತ್ತದೆ, ಹಲವು ಸಣ್ಣ ವಿನಂತಿಗಳಿಂದ ಮಾಡಿದ ಪರೀಕ್ಷೆ ಬದಲಾಗಿ ಹೋಗು-ಬಾ ಪ್ರಯಾಣವನ್ನು ಅನುಭವಿಸುತ್ತದೆ. ಮತ್ತು ಮಾರ್ಗದ MTU ಶೋಧನೆ ಎಲ್ಲಾದರೂ ದಾರಿಯಲ್ಲಿ ತಡೆಯಲ್ಪಟ್ಟರೆ, ಟನೆಲ್ ಚಿಕ್ಕ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಕ್ಕೆ ನಿಲ್ಲುತ್ತದೆ ಮತ್ತು ಥ್ರೂಪುಟ್ ಸೈಫರ್ಗಳಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲದ ಕಾರಣದಿಂದ ಇಳಿಯುತ್ತದೆ.
ನೀವು ಮೇಲ್ಛಾವಣಿಯನ್ನು ನೇರವಾಗಿ ನೋಡಬಹುದು. ಲಿನಕ್ಸ್ನಲ್ಲಿ ತುಣುಕುಗೊಳ್ಳದೆ ಹಾದುಹೋಗುವ ಅತಿದೊಡ್ಡ ಪೇಲೋಡ್ ಕೇಳಿ, ನಂತರ ಟನೆಲ್ ಆನ್ ಮಾಡಿ ಪುನರಾವರ್ತಿಸಿ:
ping -M do -s 1472 -c 3 203.0.113.10
ಅದು ವಿಫಲವಾದರೆ 1,400 ಗೆ ಇಳಿದು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ. ಕೇವಲ 1,380 ಬೈಟ್ ಸಾಗಿಸುವ ಟನೆಲ್, ಮಾರ್ಗದ ಕೆಳಗೆ ಇನ್ನೇನೋ ಒತ್ತುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಎಷ್ಟೇ ಟ್ಯೂನಿಂಗ್ ಮಾಡಿದರೂ ಅದು ಮೇಲೇರದು.
ಟನೆಲ್ ಬಂದಾಗ ಪರೀಕ್ಷಾ ಸರ್ವರ್ ಏಕೆ ಸರಿಯುತ್ತದೆ
ಹೆಚ್ಚಿನ ಉಪಕರಣಗಳು ತಾವು ಕಾಣುವ ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಆಧಾರದ ಮೇಲೆ ಹತ್ತಿರದ ಸರ್ವರ್ ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. ಟನೆಲ್ ಆನ್ ಇದ್ದಾಗ ಆ ವಿಳಾಸ ನಿರ್ಗಮನ ನೋಡ್ಗೆ ಸೇರಿದ್ದಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಉಪಕರಣ ಬೇರೆ ನಗರ ಅಥವಾ ದೇಶದ ಹೋಸ್ಟ್ ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಆಗ ನೀವು ಎರಡು ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಹೋಲಿಸುತ್ತೀರಿ, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವು ನಿರ್ಗಮನದಿಂದ ಪರೀಕ್ಷಾ ಹೋಸ್ಟ್ವರೆಗಿನ ದೂರವನ್ನೂ ಒಳಗೊಂಡಿರುತ್ತದೆ.
ಮೊದಲ ರನ್ಗಿಂತ ಮೊದಲು ಸರ್ವರ್ ಅನ್ನು ಹೆಸರು ಅಥವಾ ID ಮೂಲಕ ಸ್ಥಿರಗೊಳಿಸಿ ಮತ್ತು ಮುಂದಿನ ಪ್ರತಿ ರನ್ನಲ್ಲಿ ಅದನ್ನು ಹಿಡಿದಿಡಿ. ಉಪಕರಣ ಅದನ್ನು ಹಿಡಿದಿಡದಿದ್ದರೆ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಗುರಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ನೀವೇ ಚಲಾಯಿಸಿ: iperf3 -c test.example.net -R -t 20 ಗಮ್ಯಸ್ಥಾನವನ್ನು ಸ್ಥಿರವಾಗಿ ಇಡುತ್ತದೆ ಮತ್ತು ನಿನ್ನೆಯೊಂದಿಗೆ ಹೋಲಿಸಬಹುದಾದ ಸಂಖ್ಯೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಒಂದು ಚರವನ್ನು ಬದಲಿಸಿ, ಮತ್ತು ಕೆಳ ಪದರ ಒಂದಲ್ಲ
ತಂತಿಯಿಲ್ಲದ ಸಂಪರ್ಕವೇ ಸಾಮಾನ್ಯ ಗುಪ್ತ ಬದಲಾವಣೆ. ಲ್ಯಾಪ್ಟಾಪ್ ಚಲಿಸಿದಾಗ ಸಂಕೇತದ ಬಲ ಬದಲಾಗುತ್ತದೆ ಮತ್ತು ನೆರೆಯವರು ಕರೆ ಆರಂಭಿಸಿದಾಗ ಚಾನೆಲ್ ಒತ್ತಡ ಬದಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ Wi-Fi ನಲ್ಲಿ ಹತ್ತು ನಿಮಿಷಗಳ ಅಂತರದ ಎರಡು ರನ್ಗಳು ಒಂದೇ ಪರೀಕ್ಷೆಯ ಪುನರಾವರ್ತನೆಗಳಲ್ಲ. ಕೇಬಲ್, ಅಥವಾ ಸಂಕೇತದ ಮಟ್ಟವನ್ನು ಬರೆದಿಟ್ಟ ಸ್ಥಿರ ಸ್ಥಾನ, ಆ ಗದ್ದಲದ ಬಹುಪಾಲನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಪ್ರತಿ ರನ್ನ ಆರಂಭದಲ್ಲಿ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಸಂಕೇತದ ಮಟ್ಟವನ್ನು ಟಿಪ್ಪಣಿ ಮಾಡುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡು ರನ್ಗಳು ಒಟ್ಟಿಗೆ ಸೇರುತ್ತವೆಯೇ ಎಂದು ತೋರಿಸಲು ಸಾಕು.
ಸಾಧನದ ಹೊರೆಯೂ ಅದೇ ಬುಟ್ಟಿಯಲ್ಲಿದೆ. ಒಂದೇ ಕೋರ್ನಲ್ಲಿ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಲಿಂಕ್ಗಿಂತ ಬಹಳ ಮೊದಲೇ ತನ್ನ ಮೇಲ್ಛಾವಣಿ ತಲುಪುತ್ತದೆ, ಮತ್ತು ಹಿನ್ನೆಲೆ ಸಿಂಕ್ ಇನ್ನೂ ಬೇಗ ತಲುಪುತ್ತದೆ. ರನ್ನ ಸಮಯದಲ್ಲಿ CPU ನೋಡಿ ಮತ್ತು ಬೇರೆ ಏನು ತೆರೆದಿತ್ತು ಎಂದು ಟಿಪ್ಪಣಿ ಮಾಡಿ. ವಿದ್ಯುತ್ ಸೆಟ್ಟಿಂಗ್ಗಳೂ ಇಲ್ಲಿ ಕಚ್ಚಬಹುದು, ಏಕೆಂದರೆ ಬ್ಯಾಟರಿಯಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಲ್ಯಾಪ್ಟಾಪ್ ಲಿಂಕ್ ಬ್ಯುಸಿ ಆಗುವ ಬಹಳ ಮೊದಲೇ ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸಬಹುದು.
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
ಕೆಳ ಪದರದ ಸರಾಸರಿ ತೆಗೆದುಕೊಳ್ಳುವ ಬದಲು ಅದನ್ನು ಚಲಿಸದೆ ಇರಿಸಿ. ಒಪ್ಪುವ ಮೂರು ರನ್ಗಳು ಬೇರೆ ಬೇರೆ ಕೊಠಡಿಗಳಲ್ಲಿ ತೆಗೆದ ಹತ್ತಕ್ಕಿಂತ ಹೆಚ್ಚು ಹೇಳುತ್ತವೆ.
ವಿಳಂಬ, ನಷ್ಟ ಮತ್ತು ICMP ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ
ಪಿಂಗ್ ಸ್ಥಿರ ವಿಳಾಸಕ್ಕೆ ಸಣ್ಣ ತನಿಖೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಹಲವು ಜಾಲಗಳು ICMP ಗೆ ಕಡಿಮೆ ಆದ್ಯತೆಯಲ್ಲಿ ಉತ್ತರಿಸುತ್ತವೆ ಅಥವಾ ಸಂಪೂರ್ಣ ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ. ಬಾರದ ಉತ್ತರಗಳು ಅಪ್ಲಿಕೇಶನ್ನ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಅಲ್ಲ, ತನಿಖೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ. ಹೊರೆಯಲ್ಲಿ ಏರುವ ಹೋಗು-ಬಾ ಸಮಯ ಸಾಮಾನ್ಯವಾಗಿ ಸರದಿ ತುಂಬುತ್ತಿದೆ ಎಂದು ಅರ್ಥ, ಮಾರ್ಗ ಉದ್ದವಾಯಿತು ಎಂದಲ್ಲ.
ಟನೆಲ್ ವಿಳಂಬ ಸೇರಿಸುತ್ತದೆಯೇ ಎಂದು ತಿಳಿಯಲು ಒಂದು ಗುರಿಯನ್ನು ಅದರೊಂದಿಗೆ ಮತ್ತು ಅದಿಲ್ಲದೆ ಹೋಲಿಸಿ, ಅಥವಾ ಅದೇ ಪ್ರವೇಶ ಜಾಲದಿಂದ ತಲುಪಬಹುದಾದ ಎರಡು ನಿರ್ಗಮನಗಳನ್ನು ಹೋಲಿಸಿ. ತನಿಖೆಯನ್ನು ಪದೇ ಪದೇ ಚಲಾಯಿಸಿ ಮತ್ತು ಹರಡುವಿಕೆಯನ್ನು ನೋಡಿ, ಏಕೆಂದರೆ ಸರಾಸರಿ ಕರೆಯನ್ನು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿಸುವ ಆ ಏರುಪೇರನ್ನೇ ಮರೆಮಾಡುತ್ತದೆ.
ನಿಧಾನವೆನಿಸಿದ ಕೆಲಸಕ್ಕೆ ಹಿಂತಿರುಗಿ
ಕರೆ ಇನ್ನೂ ತುಂಡಾಗುತ್ತಿದ್ದರೂ ಸುಧಾರಿಸುವ ಅಳತೆ ಬೇರೆ ಯಾವುದೋ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಿದೆ. ತನಿಖೆ ಆರಂಭಿಸಿದ ಕೆಲಸವನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ, ಅದು ಸಭೆಯಾಗಿರಲಿ, ಫೈಲ್ ಹಂಚಿಕೆಯಾಗಿರಲಿ ಅಥವಾ ದೂರದ ಡೆಸ್ಕ್ಟಾಪ್ ಸೆಷನ್ ಆಗಿರಲಿ. ಸಂಖ್ಯೆ ಸುಧಾರಿಸಿ ಕೆಲಸ ಸುಧಾರಿಸದಿದ್ದರೆ, ಅಡಚಣೆ ಪರೀಕ್ಷೆ ಎಂದೂ ತಲುಪದ ಜಾಗದಲ್ಲಿತ್ತು, ಉದಾಹರಣೆಗೆ ಟನೆಲ್ನ ಹಿಂದಿನ ಸರ್ವರ್ ಅಥವಾ ನಿಮ್ಮ ಕಡೆಯ ಅಪ್ಲಿಂಕ್.
ಪ್ರತಿ ರನ್ ಅನ್ನು ಸಾಧನ, ಪ್ರವೇಶ ಜಾಲ, ಅಂತ್ಯಬಿಂದು, ಪ್ರೋಟೋಕಾಲ್, ಗುರಿ ಮತ್ತು ಸಮಯದೊಂದಿಗೆ ದಾಖಲಿಸಿ. ಎಂದೂ ಸಂಪರ್ಕಗೊಳ್ಳದ ರನ್ ಶೂನ್ಯ ಥ್ರೂಪುಟ್ ಅಲ್ಲ, ತಲುಪುವಿಕೆಯ ಫಲಿತಾಂಶ, ಆದ್ದರಿಂದ ಅದನ್ನು ಅಳಿಸುವ ಬದಲು ಆ ಲೇಬಲ್ ಅಡಿಯಲ್ಲಿ ಇರಿಸಿ.
ಮುಂದಿನ ಹೋಲಿಕೆಗೆ ಮೊದಲು ಸಣ್ಣ ಪಟ್ಟಿ
ಗುರಿಯನ್ನು ಸ್ಥಿರಗೊಳಿಸಿ ಮತ್ತು ಏಕೆ ಆಯ್ಕೆ ಮಾಡಿದಿರಿ ಎಂದು ಬರೆಯಿರಿ. ಮಾರ್ಗ ಅನುಮತಿಸುವ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ದಾಖಲಿಸಿ, ನಂತರದ ಇಳಿಕೆಗೆ ವಿವರಣೆ ಇರಲಿ. ಪ್ರವೇಶ ಜಾಲವನ್ನು ಒಂದೇ ರೀತಿ ಇರಿಸಿ, CPU ಹೊರೆಯನ್ನು ಟಿಪ್ಪಣಿ ಮಾಡಿ, ಮತ್ತು ವ್ಯತ್ಯಾಸವನ್ನು ನಂಬುವ ಮೊದಲು ಮೂರು ರನ್ ತೆಗೆದುಕೊಳ್ಳಿ.
ನಂತರ ನಿಖರವಾಗಿ ಒಂದು ವಿಷಯವನ್ನು ಬದಲಿಸಿ ಪುನರಾವರ್ತಿಸಿ. ನೀವು ವಿವರಿಸಬಹುದಾದ ಹೋಲಿಕೆ ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಹೋಲಿಕೆಗಿಂತ ಉತ್ತಮ.