ನೆಟ್‌ವರ್ಕ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ - ಟಿಸಿಪಿ. TCP ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್‌ನಲ್ಲಿ ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಳುಹಿಸಲಾದ ಡೇಟಾವನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ದಟ್ಟಣೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ

ನೆಟ್ವರ್ಕ್ ಪ್ರೋಟೋಕಾಲ್ಗಳ ಮೂಲಕ ಪ್ರಯಾಣ.

TCP ಮತ್ತು UDP ಎರಡೂ ಸಾರಿಗೆ ಲೇಯರ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಾಗಿವೆ. UDP ಎಂಬುದು ಖಾತರಿಯಿಲ್ಲದ ಪ್ಯಾಕೆಟ್ ವಿತರಣೆಯೊಂದಿಗೆ ಸಂಪರ್ಕವಿಲ್ಲದ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. TCP (ಟ್ರಾನ್ಸ್‌ಮಿಷನ್ ಕಂಟ್ರೋಲ್ ಪ್ರೋಟೋಕಾಲ್) ಎಂಬುದು ಗ್ಯಾರಂಟಿ ಪ್ಯಾಕೆಟ್ ವಿತರಣೆಯೊಂದಿಗೆ ಸಂಪರ್ಕ-ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಮೊದಲು ಹ್ಯಾಂಡ್ಶೇಕ್ ಇದೆ (ಹಲೋ. | ಹಲೋ. | ಚಾಟ್ ಮಾಡೋಣ? | ಹೋಗೋಣ.), ಅದರ ನಂತರ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ನಂತರ ಈ ಸಂಪರ್ಕದ ಮೂಲಕ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಹಿಂದಕ್ಕೆ ಮತ್ತು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ (ಸಂಭಾಷಣೆಯು ಪ್ರಗತಿಯಲ್ಲಿದೆ), ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಲುಪಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ ಕಳೆದುಹೋದರೆ ಅಥವಾ ಬಂದರೆ ಆದರೆ ಮುರಿದುಹೋಗುತ್ತದೆ ಚೆಕ್ಸಮ್, ನಂತರ ಅದನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ("ಪುನರಾವರ್ತನೆ, ನಾನು ಕೇಳಲಿಲ್ಲ"). ಹೀಗಾಗಿ, TCP ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ, ಆದರೆ ಇದು ಅನುಷ್ಠಾನದ ದೃಷ್ಟಿಕೋನದಿಂದ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಹೆಚ್ಚಿನ ಗಡಿಯಾರ ಚಕ್ರಗಳು / ಮೆಮೊರಿ ಅಗತ್ಯವಿರುತ್ತದೆ, ಇದು ಮೈಕ್ರೊಕಂಟ್ರೋಲರ್‌ಗಳಿಗೆ ಕಡಿಮೆ ಮುಖ್ಯವಲ್ಲ. TCP ಅನ್ನು ಬಳಸುವ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಉದಾಹರಣೆಗಳು FTP, HTTP, SMTP, ಮತ್ತು ಇತರ ಹಲವು.

TL;DR

HTTP (ಹೈಪರ್‌ಟೆಕ್ಸ್ಟ್ ಟ್ರಾನ್ಸ್‌ಫರ್ ಪ್ರೋಟೋಕಾಲ್) ಎಂಬುದು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು, ಅದರೊಂದಿಗೆ ಸರ್ವರ್ ನಮ್ಮ ಬ್ರೌಸರ್‌ಗೆ ಪುಟಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ. HTTP ಅನ್ನು ಈಗ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ವರ್ಲ್ಡ್ ವೈಡ್ ವೆಬ್ವೆಬ್‌ಸೈಟ್‌ಗಳಿಂದ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯಲು. ಬೋರ್ಡ್‌ನಲ್ಲಿ OS ಅನ್ನು ಹೊಂದಿರುವ ಮೈಕ್ರೋಕಂಟ್ರೋಲರ್‌ನಲ್ಲಿ ದೀಪವನ್ನು ಚಿತ್ರ ತೋರಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಬಣ್ಣಗಳನ್ನು ಬ್ರೌಸರ್ ಮೂಲಕ ಹೊಂದಿಸಲಾಗಿದೆ.

HTTP ಪ್ರೋಟೋಕಾಲ್ ಪಠ್ಯ ಆಧಾರಿತ ಮತ್ತು ತುಂಬಾ ಸರಳವಾಗಿದೆ. ವಾಸ್ತವವಾಗಿ ಇದು ತೋರುತ್ತಿದೆ GET ವಿಧಾನ, ನೆಟ್‌ಕ್ಯಾಟ್ ಉಪಯುಕ್ತತೆಯಿಂದ ಲೈಟ್‌ಗಳೊಂದಿಗೆ ಸರ್ವರ್‌ನ ಸ್ಥಳೀಯ IPv6 ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಲಾಗಿದೆ:

~$ nc fe80::200:e2ff:fe58:b66b%mazko 80<

HTTP ವಿಧಾನವು ಸಾಮಾನ್ಯವಾಗಿ ದೊಡ್ಡ ಅಕ್ಷರಗಳಲ್ಲಿ ಬರೆಯಲಾದ ಚಿಕ್ಕ ಇಂಗ್ಲಿಷ್ ಪದವಾಗಿದೆ ಮತ್ತು ಇದು ಕೇಸ್ ಸೆನ್ಸಿಟಿವ್ ಆಗಿದೆ. ಪ್ರತಿ ಸರ್ವರ್ ಕನಿಷ್ಠ GET ಮತ್ತು HEAD ವಿಧಾನಗಳನ್ನು ಬೆಂಬಲಿಸಬೇಕು. GET ಮತ್ತು HEAD ವಿಧಾನಗಳ ಜೊತೆಗೆ, POST, PUT ಮತ್ತು DELETE ವಿಧಾನಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಂಪನ್ಮೂಲದ ವಿಷಯಗಳನ್ನು ವಿನಂತಿಸಲು GET ವಿಧಾನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ GET /b HTTP/1.0 ಇಲ್ಲಿ /b ಮಾರ್ಗವು ಬಣ್ಣಕ್ಕೆ (ನೀಲಿ) ಕಾರಣವಾಗಿದೆ. ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆ:

HTTP/1.0 200 OK ಸರ್ವರ್: Contiki/2.4 http://www.sics.se/contiki/ ಸಂಪರ್ಕ: ಸಂಗ್ರಹ-ನಿಯಂತ್ರಣವನ್ನು ಮುಚ್ಚಿ: ನೋ-ಕ್ಯಾಶ್, ನೋ-ಸ್ಟೋರ್, ಮಸ್ಟ್-ರಿವಾಲಿಡೇಟ್ ಪ್ರಾಗ್ಮಾ: ನೋ-ಕ್ಯಾಶ್ ಅವಧಿ ಮುಗಿಯುತ್ತದೆ: 0 ವಿಷಯ- ಪ್ರಕಾರ: text/html

ಕೆಂಪು ಆಫ್ ಆಗಿದೆ

ಹಸಿರು ಆಫ್ ಆಗಿದೆ

ನೀಲಿ ಆನ್ ಆಗಿದೆ

ಸ್ಥಿತಿ ಕೋಡ್ (ನಮ್ಮಲ್ಲಿ 200 ಇದೆ) ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯೆಯ ಮೊದಲ ಸಾಲಿನ ಭಾಗವಾಗಿದೆ. ಇದು ಮೂರು-ಅಂಕಿಯ ಪೂರ್ಣಾಂಕವಾಗಿದೆ. ಮೊದಲ ಅಂಕಿಯು ಸ್ಥಿತಿಯ ವರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ವಿವರಣಾತ್ಮಕ ಪದಗುಚ್ಛವನ್ನು ಒಂದು ಜಾಗದಿಂದ ಬೇರ್ಪಡಿಸಲಾಗುತ್ತದೆ, ಇದು ಈ ನಿರ್ದಿಷ್ಟ ಪ್ರತಿಕ್ರಿಯೆಯ ಕಾರಣವನ್ನು ವ್ಯಕ್ತಿಗೆ ವಿವರಿಸುತ್ತದೆ. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಸರ್ವರ್ ದೋಷಗಳಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡಿದೆ, ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದೆ (ಸರಿ).

ವಿನಂತಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆ ಎರಡೂ ಹೆಡರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತವೆ (ಪ್ರತಿ ಸಾಲು ಪ್ರತ್ಯೇಕ ಹೆಡರ್ ಕ್ಷೇತ್ರವಾಗಿದೆ, ಹೆಸರು-ಮೌಲ್ಯದ ಜೋಡಿಯನ್ನು ಕೊಲೊನ್‌ನಿಂದ ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ). ಹೆಡರ್ ಖಾಲಿ ರೇಖೆಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಅದರ ನಂತರ ಡೇಟಾವನ್ನು ಅನುಸರಿಸಬಹುದು.

ಸ್ಥಳೀಯ IPv6 ವಿಳಾಸವನ್ನು ತೆರೆಯಲು ನನ್ನ ಬ್ರೌಸರ್ ನಿರಾಕರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೈಕ್ರೋಕಂಟ್ರೋಲರ್ ಫರ್ಮ್‌ವೇರ್‌ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ವಿಳಾಸವನ್ನು ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅದೇ ಪೂರ್ವಪ್ರತ್ಯಯವನ್ನು ಸಿಮ್ಯುಲೇಟರ್‌ನ ವರ್ಚುವಲ್ ನೆಟ್‌ವರ್ಕ್ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ನಿಯೋಜಿಸಬೇಕಾಗುತ್ತದೆ:

~$ sudo ip addr add abcd::1/64 dev mazko # linux ~$ netsh ಇಂಟರ್ಫೇಸ್ ipv6 ಸೆಟ್ ವಿಳಾಸ mazko abcd::1 # windows ~$ curl http://

TCP ಕ್ಲೈಂಟ್/ಸರ್ವರ್ ಪರಿಸರಕ್ಕೆ ಸ್ವಾಭಾವಿಕವಾಗಿ ಸಂಯೋಜನೆಗೊಳ್ಳುತ್ತದೆ (ಚಿತ್ರ 10.1 ನೋಡಿ). ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ದೋಷಗಳು(ಆಲಿಸಿ) ಒಳಬರುವ ಸಂಪರ್ಕ ವಿನಂತಿಗಳು. ಉದಾಹರಣೆಗೆ, WWW, ಫೈಲ್ ವರ್ಗಾವಣೆ ಅಥವಾ ಟರ್ಮಿನಲ್ ಪ್ರವೇಶ ಸೇವೆಗಳು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬರುವ ವಿನಂತಿಗಳನ್ನು ಆಲಿಸುತ್ತವೆ. TCP ಯಲ್ಲಿನ ಸಂವಹನಗಳು ಸೂಕ್ತ ವಾಡಿಕೆಯ ಮೂಲಕ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ, ಇದು ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ (ಸಾಕೆಟ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್ ಕುರಿತು ಅಧ್ಯಾಯ 21 ನೋಡಿ).

ಅಕ್ಕಿ. 10.1ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಅನ್ನು ಕರೆಯುತ್ತಾನೆ.

ವಾಸ್ತವದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಮತ್ತೊಂದು ಸರ್ವರ್ ಆಗಿರಬಹುದು. ಉದಾಹರಣೆಗೆ, ಕಂಪ್ಯೂಟರ್‌ಗಳ ನಡುವೆ ಇಮೇಲ್ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ಮೇಲ್ ಸರ್ವರ್‌ಗಳು ಇತರ ಮೇಲ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಬಹುದು.

TCP ಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಯಾವ ರೂಪದಲ್ಲಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬೇಕು? TCP ಯಾವ ರೂಪದಲ್ಲಿ IP ಗೆ ಡೇಟಾವನ್ನು ರವಾನಿಸುತ್ತದೆ? ಕಳುಹಿಸುವ ಮತ್ತು ಸ್ವೀಕರಿಸುವ TCP ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಗತ್ಯವಿರುವ ಡೇಟಾ ಅಂಶಗಳ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ಹೇಗೆ ಗುರುತಿಸುತ್ತವೆ? ಈ ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಮುಂದಿನ ವಿಭಾಗಗಳಲ್ಲಿ ಉತ್ತರಿಸಲಾಗಿದೆ, ಇದು TCP ಯ ಮೂಲ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಕಲ್ಪನಾತ್ಮಕಸಂಪರ್ಕ ಮಾದರಿಯು ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಪೀರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅದರ ಸಂಪರ್ಕ ಪಾಲುದಾರರಿಂದ ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಇದು ಸಮರ್ಥವಾಗಿದೆ. TCP ಒದಗಿಸುತ್ತದೆ ಪೂರ್ಣ ಡ್ಯುಪ್ಲೆಕ್ಸ್(ಪೂರ್ಣ ಡ್ಯುಪ್ಲೆಕ್ಸ್) ಆಪರೇಟಿಂಗ್ ಮೋಡ್ ಇದರಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ಸೇವೆಯನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಎರಡು ಹೊಳೆಗಳುಡೇಟಾ (ಚಿತ್ರ 10.2 ನೋಡಿ).

ಅಕ್ಕಿ. 10.2ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತವೆ.

TCP ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಡೇಟಾಗ್ರಾಮ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲು ಸೂಕ್ತವಾದ ಫಾರ್ಮ್ ಆಗಿ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಪರಿವರ್ತಿಸಬಹುದು. ಹೇಗೆ?

ಅಪ್ಲಿಕೇಶನ್ TCP ಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಈ ಪ್ರೋಟೋಕಾಲ್ ಅದನ್ನು ಇರಿಸುತ್ತದೆ ಔಟ್ಪುಟ್ ಬಫರ್(ಬಫರ್ ಕಳುಹಿಸಿ). ಮುಂದೆ, TCP ಬಫರ್‌ನಿಂದ ಡೇಟಾದ ತುಣುಕುಗಳನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಹೆಡರ್ ಅನ್ನು ಸೇರಿಸುತ್ತದೆ (ಇದು ಉತ್ಪಾದಿಸುತ್ತದೆ ವಿಭಾಗಗಳು- ವಿಭಾಗ). ಅಂಜೂರದಲ್ಲಿ. 10.3 ಡೇಟಾ ಹೇಗೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ ಔಟ್ಪುಟ್ ಬಫರ್ TCP ಅನ್ನು ವಿಭಾಗಗಳಾಗಿ ಪ್ಯಾಕೆಟ್ ಮಾಡಲಾಗಿದೆ. TCP ಪ್ರತ್ಯೇಕ ಡೇಟಾಗ್ರಾಮ್ ಆಗಿ ವಿತರಣೆಗಾಗಿ ವಿಭಾಗವನ್ನು IP ಗೆ ರವಾನಿಸುತ್ತದೆ. ಡೇಟಾವನ್ನು ಸರಿಯಾದ ಉದ್ದದ ಭಾಗಗಳಾಗಿ ಪ್ಯಾಕೆಟೈಜ್ ಮಾಡುವುದು ಸಮರ್ಥ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ಖಾತ್ರಿಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿಭಾಗವನ್ನು ರಚಿಸುವ ಮೊದಲು ಔಟ್‌ಪುಟ್ ಬಫರ್‌ನಲ್ಲಿ ಸೂಕ್ತ ಪ್ರಮಾಣದ ಡೇಟಾ ಲಭ್ಯವಾಗುವವರೆಗೆ TCP ಕಾಯುತ್ತದೆ.

ಅಕ್ಕಿ. 10.3 TCP ವಿಭಾಗವನ್ನು ರಚಿಸಲಾಗುತ್ತಿದೆ

ಆದಾಗ್ಯೂ, ನೈಜ-ಪ್ರಪಂಚದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಅನ್ವಯಿಸಲು ಅಸಾಧ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಅಂತಿಮ-ಬಳಕೆದಾರ ಕ್ಲೈಂಟ್ ಪ್ರೋಗ್ರಾಂ ರಿಮೋಟ್ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸಂವಾದಾತ್ಮಕ ಅಧಿವೇಶನವನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಬಳಕೆದಾರರು ನಂತರ ಆಜ್ಞೆಗಳನ್ನು ಮಾತ್ರ ನಮೂದಿಸುತ್ತಾರೆ (ಕೀಲಿಯನ್ನು ಒತ್ತುವ ಮೂಲಕ ಅನುಸರಿಸಲಾಗುತ್ತದೆ ಹಿಂತಿರುಗಿ).

ರಿಮೋಟ್ ಹೋಸ್ಟ್‌ಗೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಈ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತಕ್ಷಣವೇ ನಿರ್ವಹಿಸಲು ಬಳಕೆದಾರರ ಕ್ಲೈಂಟ್ ಪ್ರೋಗ್ರಾಂಗೆ TCP ಅಗತ್ಯವಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಇದನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಹೊರಗೆ ತಳ್ಳುವುದು(ತಳ್ಳುವುದು).

ನೀವು ಸಂವಾದಾತ್ಮಕ ಸೆಷನ್‌ನಲ್ಲಿನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನೋಡಿದರೆ, ಕಡಿಮೆ ಡೇಟಾದೊಂದಿಗೆ ನೀವು ಅನೇಕ ವಿಭಾಗಗಳನ್ನು ಕಾಣಬಹುದು ಮತ್ತು ಇದಲ್ಲದೆ, ಪ್ರತಿಯೊಂದು ಡೇಟಾ ವಿಭಾಗದಲ್ಲಿಯೂ ಪಾಪಿಂಗ್ ಅನ್ನು ಕಾಣಬಹುದು. ಆದಾಗ್ಯೂ, ಫೈಲ್ ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ ತಳ್ಳುವಿಕೆಯನ್ನು ಬಳಸಬಾರದು (ಕೊನೆಯ ವಿಭಾಗವನ್ನು ಹೊರತುಪಡಿಸಿ), ಮತ್ತು TCP ಡೇಟಾವನ್ನು ವಿಭಾಗಗಳಾಗಿ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪ್ಯಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್‌ನ ಡೇಟಾ ಫಾರ್ವಾರ್ಡಿಂಗ್ ಮಾದರಿಯು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಪ್ರಯಾಣಿಸುವ ಬೈಟ್‌ಗಳ ಆದೇಶದ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಸಂವಾದಾತ್ಮಕ ಅಧಿವೇಶನ ಉದಾಹರಣೆಯನ್ನು ಮತ್ತೊಮ್ಮೆ ಉಲ್ಲೇಖಿಸಿ, ಬಳಕೆದಾರರು ಕೀಲಿಯನ್ನು ಒತ್ತಿದರೆ ಎಂದು ಭಾವಿಸೋಣ ಗಮನ(ಗಮನ) ಅಥವಾ ಬ್ರೇಕ್(ಅಡಚಣೆ). ರಿಮೋಟ್ ಅಪ್ಲಿಕೇಶನ್ ಮಧ್ಯಪ್ರವೇಶಿಸುವ ಬೈಟ್‌ಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಲು ಮತ್ತು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಕೀಸ್ಟ್ರೋಕ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಯಾಂತ್ರಿಕತೆ ತುರ್ತು ಡೇಟಾ(ತುರ್ತು ಡೇಟಾ) ಒಂದು ವಿಭಾಗದಲ್ಲಿ ವಿಶೇಷ ಮಾಹಿತಿಯನ್ನು ಎಂದು ಗುರುತಿಸುತ್ತದೆ ತುರ್ತು.ಇದನ್ನು ಮಾಡುವ ಮೂಲಕ, ವಿಭಾಗವು ತುರ್ತು ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅದು ಎಲ್ಲಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸಬಹುದು ಎಂದು TCP ತನ್ನ ಪೀರ್‌ಗೆ ಹೇಳುತ್ತದೆ. ಪಾಲುದಾರರು ಈ ಮಾಹಿತಿಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ತಲುಪಬೇಕಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ರವಾನಿಸಬೇಕು.

ಕ್ಲೈಂಟ್ ಪ್ರವೇಶಿಸಲು ಬಯಸುವ ಸೇವೆಯನ್ನು ಗುರುತಿಸಬೇಕು. ಹೋಸ್ಟ್ ಸೇವೆಯ IP ವಿಳಾಸ ಮತ್ತು ಅದರ TCP ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯ ವಿವರಣೆಯ ಮೂಲಕ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ. UDP ಯಂತೆಯೇ, TCP ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳು 0 ರಿಂದ 65535 ರವರೆಗೆ ಇರುತ್ತದೆ. 0 ರಿಂದ 1023 ರವರೆಗಿನ ಪೋರ್ಟ್‌ಗಳನ್ನು ಪ್ರಸಿದ್ಧ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರಮಾಣಿತ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.

ಪ್ರಸಿದ್ಧ ಪೋರ್ಟ್‌ಗಳ ಹಲವಾರು ಉದಾಹರಣೆಗಳನ್ನು ಮತ್ತು ಅವುಗಳ ಅನುಗುಣವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕೋಷ್ಟಕ 10.1 ರಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ. ಸೇವೆಗಳು ತಿರಸ್ಕರಿಸು(ಪೋರ್ಟ್ 9) ಮತ್ತು ಆರೋಪಿಸಿದರು(ಪೋರ್ಟ್ 19) ಯುಡಿಪಿ ಮೂಲಕ ನಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಸೇವೆಗಳ TCP ಆವೃತ್ತಿಗಳಾಗಿವೆ. TCP ಪ್ರೋಟೋಕಾಲ್ನ ಪೋರ್ಟ್ 9 ಗೆ ಸಂಚಾರವು UDP ಪ್ರೋಟೋಕಾಲ್ನ ಪೋರ್ಟ್ 9 ಗೆ ಸಂಚಾರದಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದೆ ಎಂದು ನೆನಪಿನಲ್ಲಿಡಬೇಕು.

ಕೋಷ್ಟಕ 10.1 ಸುಪ್ರಸಿದ್ಧ TCP ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಅನುಗುಣವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು

ಗ್ರಾಹಕರು ಬಳಸುವ ಪೋರ್ಟ್‌ಗಳ ಬಗ್ಗೆ ಏನು? ಅಪರೂಪದ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಪ್ರಸಿದ್ಧ ಪೋರ್ಟ್ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಆದರೆ ಅಂತಹ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲು ಬಯಸಿದಲ್ಲಿ, ಇದು ಬಳಕೆಯಾಗದ ಮತ್ತು ಕಾಯ್ದಿರಿಸದ ಪೋರ್ಟ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಕೇಳುತ್ತದೆ. ಸಂಪರ್ಕದ ಕೊನೆಯಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಈ ಪೋರ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಬೇಕು, ಅದರ ನಂತರ ಪೋರ್ಟ್ ಅನ್ನು ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಮರುಬಳಕೆ ಮಾಡಬಹುದು. ಕಾಯ್ದಿರಿಸದ ಸಂಖ್ಯೆಯ ಪೂಲ್‌ನಲ್ಲಿ 63,000 ಕ್ಕಿಂತ ಹೆಚ್ಚು TCP ಪೋರ್ಟ್‌ಗಳು ಇರುವುದರಿಂದ, ಕ್ಲೈಂಟ್ ಪೋರ್ಟ್ ನಿರ್ಬಂಧಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸಬಹುದು.

ನಾವು ಈಗಾಗಲೇ ತಿಳಿದಿರುವಂತೆ, ಸಂವಹನಕ್ಕಾಗಿ IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ನ ಸಂಯೋಜನೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ವಿಳಾಸ ಸಾಕೆಟ್.ಸಂಪರ್ಕದ ಪ್ರತಿ ತುದಿಯಲ್ಲಿರುವ ಸಾಕೆಟ್ ವಿಳಾಸದಿಂದ TCP ಸಂಪರ್ಕವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಗುರುತಿಸಲಾಗುತ್ತದೆ. ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.4 ಸಾಕೆಟ್ ವಿಳಾಸದೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ತೋರಿಸುತ್ತದೆ (128.36.1.24, ಪೋರ್ಟ್ = 3358) ಮತ್ತು ಸಾಕೆಟ್ ವಿಳಾಸದೊಂದಿಗೆ ಸರ್ವರ್ (130.42.88.22, ಪೋರ್ಟ್ = 21).

ಅಕ್ಕಿ. 10.4ಸಾಕೆಟ್ ವಿಳಾಸಗಳು

ಪ್ರತಿ ಡೇಟಾಗ್ರಾಮ್‌ನ ಹೆಡರ್ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ IP ವಿಳಾಸಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. TCP ವಿಭಾಗದ ಹೆಡರ್‌ನಲ್ಲಿ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ನಂತರ ನೋಡುತ್ತೀರಿ.

ವಿಶಿಷ್ಟವಾಗಿ, ಸರ್ವರ್ ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಿರ್ವಹಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ವಿಶಿಷ್ಟ ಸರ್ವರ್ ಸಾಕೆಟ್ ವಿಳಾಸಗಳನ್ನು ಅದರ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ (Fig. 10.5 ನೋಡಿ).

ಅಕ್ಕಿ. 10.5ಸರ್ವರ್ ಸಾಕೆಟ್ ವಿಳಾಸಗಳಿಗೆ ಬಹು ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪರ್ಕಗೊಂಡಿವೆ

ಐಪಿ ವಿಳಾಸಗಳು ಮತ್ತು ಪೋರ್ಟ್‌ಗಳಿಂದ ಗುರುತಿಸಲಾದ ಟಿಸಿಪಿ ಸಂಪರ್ಕ ವಿಭಾಗವನ್ನು ಡೇಟಾಗ್ರಾಮ್ ಒಳಗೊಂಡಿರುವುದರಿಂದ, ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಬಹು ಸಂಪರ್ಕಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು ಸರ್ವರ್‌ಗೆ ತುಂಬಾ ಸುಲಭ.

ಈ ವಿಭಾಗದಲ್ಲಿ, ಪ್ರಸರಣದ ಕ್ರಮವನ್ನು ಸಂರಕ್ಷಿಸುವಾಗ ಮತ್ತು ನಷ್ಟ ಅಥವಾ ನಕಲು ತಪ್ಪಿಸುವಾಗ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಡೇಟಾವನ್ನು ತಲುಪಿಸಲು ಬಳಸುವ TCP ಕಾರ್ಯವಿಧಾನವನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ.

ವಿಶ್ವಾಸಾರ್ಹ ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು TCP ಸಂಖ್ಯಾ ಮತ್ತು ಸ್ವೀಕೃತಿಯನ್ನು (ACK) ಬಳಸುತ್ತದೆ. TCP ಸಂಖ್ಯೆಯ ಯೋಜನೆಯು ಸ್ವಲ್ಪ ಅಸಾಮಾನ್ಯವಾಗಿದೆ: ಪ್ರತಿಸಂಪರ್ಕದ ಮೂಲಕ ರವಾನಿಸಲಾಗಿದೆ ಆಕ್ಟೆಟ್ಸರಣಿ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. TCP ವಿಭಾಗದ ಹೆಡರ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿದೆ ಈ ವಿಭಾಗದಲ್ಲಿ ಡೇಟಾದ ಮೊದಲ ಆಕ್ಟೇಟ್.

ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸಲು ರಿಸೀವರ್ ಅಗತ್ಯವಿದೆ. ಸಮಯ ಮೀರುವ ಮಧ್ಯಂತರದಲ್ಲಿ ACK ಬರದಿದ್ದರೆ, ಡೇಟಾವನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ರಿಲೇಯೊಂದಿಗೆ ಧನಾತ್ಮಕ ದೃಢೀಕರಣ(ಮರುಪ್ರಸಾರದೊಂದಿಗೆ ಧನಾತ್ಮಕ ಸ್ವೀಕೃತಿ).

TCP ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವವರು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಒಳಬರುವ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಅನುಕ್ರಮವಾಗಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಕಾಣೆಯಾದ ಭಾಗಗಳಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತಾರೆ. ACK ಯಾದೃಚ್ಛಿಕವಾಗಿ ಕಳೆದುಹೋಗಬಹುದು ಅಥವಾ ವಿಳಂಬವಾಗಬಹುದು, ನಕಲು ವಿಭಾಗಗಳು ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಲುಪಬಹುದು. ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ನಕಲಿ ಡೇಟಾವನ್ನು ಗುರುತಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ನಂತರ ಅದನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.

ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.6 TCP ಯಲ್ಲಿ ಸಮಯ ಮೀರುವಿಕೆ ಮತ್ತು ಮರುಪ್ರಸಾರದ ಸರಳೀಕೃತ ನೋಟವನ್ನು ತೋರಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 10.6. TCP ಯಲ್ಲಿ ಸಮಯ ಮೀರುವಿಕೆ ಮತ್ತು ಮರುಪ್ರಸಾರ

ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಿರುವಂತೆ. 10.7, TCP ಹೆಡರ್‌ನ ಮೊದಲ ಕೆಲವು ಕ್ಷೇತ್ರಗಳು ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಮೌಲ್ಯಗಳಿಗೆ ಸ್ಥಳಾವಕಾಶವನ್ನು ಒದಗಿಸುತ್ತವೆ, ಸುತ್ತುವರಿದ ಡೇಟಾದ ಮೊದಲ ಬೈಟ್‌ನ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ ಮತ್ತು ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗೆ ಸಮಾನವಾದ ACK ಮುಂದೆಇನ್ನೊಂದು ತುದಿಯಲ್ಲಿ ಬೈಟ್ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, TCP ತನ್ನ ಪೀರ್‌ನಿಂದ 30 ವರೆಗಿನ ಎಲ್ಲಾ ಬೈಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, ಈ ಕ್ಷೇತ್ರವು 31 ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಇದು ಮುಂದಿನ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ವಿಭಾಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 10.7. TCP ಹೆಡರ್ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ಆರಂಭಿಕ ಮೌಲ್ಯಗಳು

ಒಂದು ಸಣ್ಣ ವಿವರವನ್ನು ಕಡೆಗಣಿಸಲಾಗುವುದಿಲ್ಲ. TCP 1 ರಿಂದ 50 ಬೈಟ್‌ಗಳನ್ನು ಕಳುಹಿಸಿದೆ ಮತ್ತು ಕಳುಹಿಸಲು ಹೆಚ್ಚಿನ ಡೇಟಾ ಇಲ್ಲ ಎಂದು ಭಾವಿಸೋಣ. ಪೀರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದರೆ, TCP ಅದರ ರಶೀದಿಯನ್ನು ಅದರೊಂದಿಗೆ ಲಗತ್ತಿಸಲಾದ ಡೇಟಾ ಇಲ್ಲದೆ ಹೆಡರ್ ಕಳುಹಿಸುವ ಮೂಲಕ ಅಂಗೀಕರಿಸಬೇಕು. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ಹೆಡರ್ ACK ಮೌಲ್ಯವನ್ನು ಒಳಗೊಂಡಿದೆ. ಅನುಕ್ರಮ ಕ್ಷೇತ್ರದಲ್ಲಿ - ಮೌಲ್ಯವು 51 ಆಗಿದೆ, ಅಂದರೆ. ಮುಂದಿನ ಬೈಟ್‌ನ ಸಂಖ್ಯೆ, ಇದು ಉದ್ದೇಶಿಸಿದೆ TCP ಕಳುಹಿಸಿ. TCP ಮುಂದಿನ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಿದಾಗ, ಹೊಸ TCP ಹೆಡರ್ ಸಹ 51 ರ ಅನುಕ್ರಮ ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

ಎರಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪರಸ್ಪರ ಹೇಗೆ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ? ಸಂವಹನದ ಮೊದಲು, ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಒಂದು ಮೆಮೊರಿ ಬ್ಲಾಕ್ ಅನ್ನು ರೂಪಿಸಲು ಸಬ್‌ರುಟೀನ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ, ಅದನ್ನು ನಿರ್ದಿಷ್ಟ ಸಂಪರ್ಕದ TCP ಮತ್ತು IP ನಿಯತಾಂಕಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಸಾಕೆಟ್ ವಿಳಾಸಗಳು, ಪ್ರಸ್ತುತ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ, ಆರಂಭಿಕ ಜೀವಿತಾವಧಿ ಮೌಲ್ಯ, ಇತ್ಯಾದಿ.

ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ಕ್ಲೈಂಟ್ ಕಾಣಿಸಿಕೊಳ್ಳಲು ಕಾಯುತ್ತದೆ, ಅವರು ಸರ್ವರ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಬಯಸುತ್ತಾರೆ, ವಿನಂತಿಯನ್ನು ನೀಡುತ್ತಾರೆ ಸಂಯುಕ್ತ(ಸಂಪರ್ಕ), ಸರ್ವರ್‌ನ IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಗುರುತಿಸುವುದು.

ಒಂದು ತಾಂತ್ರಿಕ ವೈಶಿಷ್ಟ್ಯವಿದೆ. ಪ್ರತಿಯೊಂದು ಬದಿಯು ಪ್ರತಿ ಬೈಟ್ ಅನ್ನು ಒಂದರಿಂದ ಅಲ್ಲ, ಆದರೆ ಅದರೊಂದಿಗೆ ಸಂಖ್ಯೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಯಾದೃಚ್ಛಿಕ ಸರಣಿ ಸಂಖ್ಯೆ(ಇದನ್ನು ಏಕೆ ಮಾಡಲಾಗುತ್ತದೆ ಎಂದು ನಾವು ನಂತರ ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ). ಮೂಲ ವಿವರಣೆಯು ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು 32-ಬಿಟ್ ಬಾಹ್ಯ ಟೈಮರ್ ಅನ್ನು ಆಧರಿಸಿ ರಚಿಸಬೇಕೆಂದು ಸಲಹೆ ನೀಡುತ್ತದೆ, ಅದು ಸರಿಸುಮಾರು ಪ್ರತಿ 4 µs ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಸಂಪರ್ಕ ವಿಧಾನವನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು-ಮಾರ್ಗ ಹ್ಯಾಂಡ್ಶೇಕ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಮೂರು ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲಾಗುತ್ತದೆ - SYN, SYN ಮತ್ತು ACK.

ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ, ಪಾಲುದಾರರು ಮೂರು ಪ್ರಮುಖ ಮಾಹಿತಿಯನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ:

1. ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಬಫರ್ ಸ್ಪೇಸ್

2. ಒಳಬರುವ ವಿಭಾಗದಲ್ಲಿ ಸಾಗಿಸಲಾದ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಡೇಟಾ

3. ಹೊರಹೋಗುವ ಡೇಟಾಕ್ಕಾಗಿ ಬಳಸಲಾದ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತಿದೆ

ಸೂಚಿಸಲು ಪ್ರತಿ ಪಕ್ಷವು 1 ಮತ್ತು 2 ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ ಇತರ ಪಕ್ಷವು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮಿತಿಗಳು.ಪರ್ಸನಲ್ ಕಂಪ್ಯೂಟರ್ ಸಣ್ಣ ರಿಸೀವ್ ಬಫರ್ ಹೊಂದಿರಬಹುದು, ಆದರೆ ಸೂಪರ್ ಕಂಪ್ಯೂಟರ್ ದೊಡ್ಡ ಬಫರ್ ಹೊಂದಿರಬಹುದು. ವೈಯಕ್ತಿಕ ಕಂಪ್ಯೂಟರ್‌ನ ಮೆಮೊರಿ ರಚನೆಯು ಒಳಬರುವ ಡೇಟಾ ಭಾಗಗಳನ್ನು 1 KB ಗೆ ಸೀಮಿತಗೊಳಿಸಬಹುದು, ಆದರೆ ಸೂಪರ್‌ಕಂಪ್ಯೂಟರ್ ದೊಡ್ಡ ವಿಭಾಗಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ಇನ್ನೊಂದು ಬದಿಯು ಡೇಟಾವನ್ನು ಹೇಗೆ ಕಳುಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುವ ಸಾಮರ್ಥ್ಯವು TCP/IP ಅನ್ನು ಸ್ಕೇಲೆಬಲ್ ಮಾಡುವ ಪ್ರಮುಖ ಲಕ್ಷಣವಾಗಿದೆ.

ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.8 ಉದಾಹರಣೆ ಸಂಪರ್ಕ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ರೇಖಾಚಿತ್ರವನ್ನು ಓವರ್ಲೋಡ್ ಮಾಡದಂತೆ ಸರಳವಾದ ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲಾಗುತ್ತದೆ. ಈ ಚಿತ್ರದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ಗಿಂತ ದೊಡ್ಡ ವಿಭಾಗಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಅಕ್ಕಿ. 10.8ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವುದು

ಕೆಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ:

1. ಸರ್ವರ್ ಆರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಸಿದ್ಧವಾಗುತ್ತದೆ (ಈ ಸ್ಥಿತಿಯನ್ನು ನಿಷ್ಕ್ರಿಯ ಮುಕ್ತ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ).

2. ಕ್ಲೈಂಟ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ IP ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ನಲ್ಲಿ ಸರ್ವರ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲು TCP ಅನ್ನು ವಿನಂತಿಸುತ್ತದೆ (ಈ ಸ್ಥಿತಿಯನ್ನು ಸಕ್ರಿಯ ಮುಕ್ತ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ).

3. ಕ್ಲೈಂಟ್ TCP ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಪಡೆಯುತ್ತದೆ (ಈ ಉದಾಹರಣೆಯಲ್ಲಿ 1000) ಮತ್ತು ಕಳುಹಿಸುತ್ತದೆ ಸಿಂಕ್ ವಿಭಾಗ(ಸಿಂಕ್ರೊನೈಸ್ ವಿಭಾಗ - SYN). ಈ ವಿಭಾಗವು ಅನುಕ್ರಮ ಸಂಖ್ಯೆ, ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಗಾತ್ರ (4K) ಮತ್ತು ಕ್ಲೈಂಟ್ ಸ್ವೀಕರಿಸಬಹುದಾದ ದೊಡ್ಡ ವಿಭಾಗದ ಗಾತ್ರವನ್ನು (1460 ಬೈಟ್‌ಗಳು) ಹೊಂದಿರುತ್ತದೆ.

4. SYN ಬಂದಾಗ, ಸರ್ವರ್ TCP ಸ್ವೀಕರಿಸುತ್ತದೆ ನನ್ನದುಆರಂಭದ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ (3000). ಇದು ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ (3000), ACK 1001 (ಅಂದರೆ ಕ್ಲೈಂಟ್ ಕಳುಹಿಸಿದ ಮೊದಲ ಬೈಟ್ ಅನ್ನು 1001 ಎಂದು ನಮೂದಿಸಲಾಗಿದೆ), ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಗಾತ್ರ (4K) ಮತ್ತು ಸರ್ವರ್ ಮಾಡಬಹುದಾದ ದೊಡ್ಡ ವಿಭಾಗದ ಗಾತ್ರವನ್ನು ಹೊಂದಿರುವ SYN ವಿಭಾಗವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಸ್ವೀಕರಿಸಿ (1024 ಬೈಟ್‌ಗಳು).

5. ಕ್ಲೈಂಟ್ TCP, ಸರ್ವರ್‌ನಿಂದ SYN/ACK ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ACK 3001 ಅನ್ನು ಮರಳಿ ಕಳುಹಿಸುತ್ತದೆ (ಸರ್ವರ್‌ನಿಂದ ಕಳುಹಿಸಲಾದ ಡೇಟಾದ ಮೊದಲ ಬೈಟ್ 3001 ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರಬೇಕು).

6. ಕ್ಲೈಂಟ್ TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲು ಅದರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ.

7. ಸರ್ವರ್ TCP, ಕ್ಲೈಂಟ್ TCP ನಿಂದ ACK ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವ ಬಗ್ಗೆ ಅದರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಿಳಿಸುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಸ್ವೀಕರಿಸಿದ ಡೇಟಾಕ್ಕಾಗಿ ತಮ್ಮ ನಿಯಮಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಅವರ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿ ಮತ್ತು ಡೇಟಾ ವಿನಿಮಯಕ್ಕೆ ಸಿದ್ಧವಾಗುತ್ತದೆ. TCP ವಿವರಣೆಯು ಮತ್ತೊಂದು ಸನ್ನಿವೇಶಕ್ಕೆ (ಅತ್ಯಂತ ಯಶಸ್ವಿಯಾಗಿಲ್ಲ), ಪೀರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿ ಪರಸ್ಪರ ತೆರೆದಾಗ ಅನುಮತಿಸುತ್ತದೆ.

ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಅಪ್ಲಿಕೇಶನ್ ವಿನಂತಿಯು ಸಂಪರ್ಕ ಡೇಟಾವನ್ನು ಸಾಗಿಸುವ IP ಡೇಟಾಗ್ರಾಮ್‌ಗಳಿಗೆ ನಿಯತಾಂಕಗಳನ್ನು ಸಹ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ನಿರ್ದಿಷ್ಟ ನಿಯತಾಂಕದ ಮೌಲ್ಯವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಉದಾಹರಣೆಗೆ, ಒಂದು ಅಪ್ಲಿಕೇಶನ್ IP ಆದ್ಯತೆ ಅಥವಾ ಸೇವೆಯ ಪ್ರಕಾರಕ್ಕಾಗಿ ಬಯಸಿದ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು. ಸಂಪರ್ಕಿತ ಪ್ರತಿಯೊಂದು ಪಕ್ಷಗಳು ಸ್ವತಂತ್ರವಾಗಿ ತನ್ನದೇ ಆದ ಆದ್ಯತೆ ಮತ್ತು ಸೇವೆಯ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿಸುವುದರಿಂದ, ಸೈದ್ಧಾಂತಿಕವಾಗಿ ಈ ಮೌಲ್ಯಗಳು ಡೇಟಾ ಹರಿವಿನ ವಿಭಿನ್ನ ದಿಕ್ಕುಗಳಿಗೆ ಭಿನ್ನವಾಗಿರುತ್ತವೆ. ನಿಯಮದಂತೆ, ಪ್ರಾಯೋಗಿಕವಾಗಿ ವಿನಿಮಯದ ಪ್ರತಿಯೊಂದು ದಿಕ್ಕಿಗೆ ಒಂದೇ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಸರ್ಕಾರ ಅಥವಾ ಮಿಲಿಟರಿ ಭದ್ರತಾ ಆಯ್ಕೆಗಳನ್ನು ಒಳಗೊಂಡಿರುವಾಗ, ಸಂಪರ್ಕದ ಪ್ರತಿಯೊಂದು ಅಂತಿಮ ಬಿಂದುವು ಅದೇ ಭದ್ರತಾ ಮಟ್ಟವನ್ನು ಬಳಸಬೇಕು ಅಥವಾ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುವುದಿಲ್ಲ.

ಸಂಪರ್ಕ ರಚನೆಯ ಮೂರು-ಹಂತದ ದೃಢೀಕರಣವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ ಡೇಟಾ ವರ್ಗಾವಣೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ (ಚಿತ್ರ 10.9 ನೋಡಿ). TCP ಮಾನದಂಡವು ಸ್ವೀಕೃತಿ ವಿಭಾಗಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ ಡೇಟಾವನ್ನು ಸೇರಿಸಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಸಂಪರ್ಕವು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಅದನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಲುಪಿಸಲಾಗುವುದಿಲ್ಲ. ಸಂಖ್ಯೆಯನ್ನು ಸರಳಗೊಳಿಸಲು, 1000-ಬೈಟ್ ಸಂದೇಶಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು TCP ಹೆಡರ್ ವಿಭಾಗವು ಸಂಪರ್ಕ ಪಾಲುದಾರರಿಂದ ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸಲಾದ ಬೈಟ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಗುರುತಿಸುವ ACK ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿದೆ.

ಅಕ್ಕಿ. 10.9ಸರಳ ಡೇಟಾ ವಿನಿಮಯ ಮತ್ತು ACK ಹರಿವು

ಕ್ಲೈಂಟ್ ಕಳುಹಿಸಿದ ಮೊದಲ ವಿಭಾಗವು 1001 ರಿಂದ 2000 ಬೈಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಅದರ ACK ಕ್ಷೇತ್ರವು 3001 ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು, ಇದು ಸರ್ವರ್‌ನಿಂದ ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸಲಾದ ಬೈಟ್ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ಗೆ 1000 ಬೈಟ್‌ಗಳ ಡೇಟಾವನ್ನು ಹೊಂದಿರುವ ವಿಭಾಗದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ (ಸಂಖ್ಯೆ 3001 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ). ಅದರ TCP ಹೆಡರ್ ACK ಕ್ಷೇತ್ರವು 1001 ರಿಂದ 2000 ವರೆಗಿನ ಬೈಟ್‌ಗಳನ್ನು ಈಗಾಗಲೇ ಯಶಸ್ವಿಯಾಗಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ನಿಂದ ನಿರೀಕ್ಷಿಸಲಾದ ಮುಂದಿನ ವಿಭಾಗದ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ 2001 ಆಗಿರಬೇಕು.

ಕ್ಲೈಂಟ್ ನಂತರ ಬೈಟ್‌ಗಳು 2001, 3001 ಮತ್ತು 4001 ರಿಂದ ಪ್ರಾರಂಭವಾಗುವ ವಿಭಾಗಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಅನುಕ್ರಮದಲ್ಲಿ ಕಳುಹಿಸುತ್ತದೆ. ಕಳುಹಿಸಿದ ಪ್ರತಿಯೊಂದು ವಿಭಾಗಗಳ ನಂತರ ಕ್ಲೈಂಟ್ ACK ಗಾಗಿ ಕಾಯುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಅದರ ಬಫರ್ ಸ್ಪೇಸ್ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಡೇಟಾವನ್ನು ಪೀರ್‌ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ (ಸ್ವೀಕೃತದಾರನು ಅವನಿಗೆ ಕಳುಹಿಸಿದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ನಿಖರವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು ಎಂದು ನಾವು ಕೆಳಗೆ ನೋಡುತ್ತೇವೆ).

ಎಲ್ಲಾ ವಿಭಾಗಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವಲ್ಲಿ ಯಶಸ್ಸನ್ನು ಸೂಚಿಸಲು ಸರ್ವರ್ ಒಂದೇ ACK ಅನ್ನು ಬಳಸುವ ಮೂಲಕ ಸಂಪರ್ಕ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಉಳಿಸುತ್ತದೆ.

ಅಂಜೂರದಲ್ಲಿ. ಮೊದಲ ವಿಭಾಗವು ಕಳೆದುಹೋದಾಗ ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಚಿತ್ರ 10.10 ತೋರಿಸುತ್ತದೆ. ಅವಧಿ ಮೀರಿದಾಗ, ವಿಭಾಗವನ್ನು ಮರುಪ್ರಸಾರಿಸಲಾಗುತ್ತದೆ. ಕಳೆದುಹೋದ ವಿಭಾಗವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಸ್ವೀಕರಿಸುವವರು ಎರಡೂ ವಿಭಾಗಗಳ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯನ್ನು ದೃಢೀಕರಿಸುವ ಏಕೈಕ ACK ಅನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ.

ಅಕ್ಕಿ. 10.10.ಡೇಟಾ ನಷ್ಟ ಮತ್ತು ಮರುಪ್ರಸಾರ

ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವಾಗ ಅದೇ ಟ್ರಿಪಲ್ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕದ ಸಾಮಾನ್ಯ ಮುಕ್ತಾಯವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಪಕ್ಷವು ಈ ಕೆಳಗಿನ ಸನ್ನಿವೇಶವನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು ಪ್ರಾರಂಭಿಸಬಹುದು:

ಉ:

ಬಿ:"ಉತ್ತಮ".

IN:"ನಾನೂ ಕೆಲಸ ಮುಗಿಸಿದೆ."

ಉ:"ಉತ್ತಮ".

ನಾವು ಈ ಕೆಳಗಿನ ಸನ್ನಿವೇಶವನ್ನು ಊಹಿಸೋಣ (ಆದರೂ ಇದನ್ನು ಬಹಳ ವಿರಳವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ):

ಉ:"ನಾನು ಮುಗಿಸಿದ್ದೇನೆ. ಕಳುಹಿಸಲು ಹೆಚ್ಚಿನ ಡೇಟಾ ಇಲ್ಲ."

IN:"ಸರಿ. ಆದಾಗ್ಯೂ, ಸ್ವಲ್ಪ ಡೇಟಾ ಇದೆ..."

IN:"ನಾನೂ ಕೆಲಸ ಮುಗಿಸಿದೆ."

ಉ:"ಉತ್ತಮ".

ಕೆಳಗಿನ ಉದಾಹರಣೆಯಲ್ಲಿ, ಕ್ಲೈಂಟ್/ಸರ್ವರ್ ಸಂಪರ್ಕಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಸರ್ವರ್‌ನಿಂದ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬಳಕೆದಾರರು ಅಧಿವೇಶನದಲ್ಲಿ ಪ್ರವೇಶಿಸಿದ ನಂತರ ಟೆಲ್ನೆಟ್ಲಾಗ್‌ಔಟ್ ಆಜ್ಞೆಯು ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು ವಿನಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸರ್ವರ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಿರುವ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ. 10.11, ಈ ಕೆಳಗಿನ ಕ್ರಿಯೆಗಳನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ:

1. ಸರ್ವರ್‌ನಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು TCP ಗೆ ಹೇಳುತ್ತದೆ.

2. TCP ಸರ್ವರ್ ಅಂತಿಮ ವಿಭಾಗವನ್ನು ಕಳುಹಿಸುತ್ತದೆ (ಅಂತಿಮ ವಿಭಾಗ - FIN), ಕಳುಹಿಸಲು ಹೆಚ್ಚಿನ ಡೇಟಾ ಇಲ್ಲ ಎಂದು ತನ್ನ ಪೀರ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ.

3. ಕ್ಲೈಂಟ್‌ನ TCP FIN ವಿಭಾಗದಲ್ಲಿ ACK ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

4. ಕ್ಲೈಂಟ್‌ನ TCP ತನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸರ್ವರ್ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು ಬಯಸುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ.

5. ಕ್ಲೈಂಟ್ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು ಅದರ TCP ಗೆ ಹೇಳುತ್ತದೆ.

6. TCP ಕ್ಲೈಂಟ್ FIN ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

7. TCP ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ನಿಂದ FIN ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ACK ಸಂದೇಶದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ.

8. ಸರ್ವರ್‌ನ TCP ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲು ಅದರ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೇಳುತ್ತದೆ.

ಅಕ್ಕಿ. 10.11.ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲಾಗುತ್ತಿದೆ

ಎರಡೂ ಪಕ್ಷಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮುಚ್ಚುವಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರತಿ ಪೀರ್ ACK ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಿದ ನಂತರ ಸಾಮಾನ್ಯ ಸಂಪರ್ಕ ಮುಚ್ಚುವಿಕೆಯು ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ.

ಪ್ರತಿ ಪಕ್ಷವು ಸಂಪರ್ಕದ ಹಠಾತ್ ಮುಕ್ತಾಯವನ್ನು (ಹಠಾತ್ ಮುಚ್ಚುವಿಕೆ) ವಿನಂತಿಸಬಹುದು. ಅಪ್ಲಿಕೇಶನ್ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಲು ಬಯಸಿದಾಗ ಅಥವಾ TCP ತನ್ನದೇ ಆದ ವಿಧಾನದಿಂದ ಪರಿಹರಿಸಲಾಗದ ಗಂಭೀರ ಸಂವಹನ ಸಮಸ್ಯೆಯನ್ನು ಪತ್ತೆ ಮಾಡಿದಾಗ ಇದು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ. TCP ಹೆಡರ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಫ್ಲ್ಯಾಗ್‌ನಿಂದ ಸೂಚಿಸಲಾದ ಪೀರ್‌ಗೆ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಮರುಹೊಂದಿಸುವ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಹಠಾತ್ ಮುಕ್ತಾಯವನ್ನು ವಿನಂತಿಸಲಾಗುತ್ತದೆ.

ಒಳಬರುವ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನೊಂದಿಗೆ TCP ರಿಸೀವರ್ ಅನ್ನು ಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಅದು ಎಷ್ಟು ಮಾಹಿತಿಯನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಈ ಮಿತಿಯು TCP ಕಳುಹಿಸುವವರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಈ ಕಾರ್ಯವಿಧಾನದ ಕೆಳಗಿನ ವಿವರಣೆಯು ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ, ಮತ್ತು ಅಭಿವರ್ಧಕರು ಅದನ್ನು ತಮ್ಮ ಉತ್ಪನ್ನಗಳಲ್ಲಿ ವಿಭಿನ್ನ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು.

ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ, ಪ್ರತಿ ಪೀರ್ ಸಂಪರ್ಕದ ಇನ್‌ಪುಟ್ ಬಫರ್‌ಗಾಗಿ ಜಾಗವನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ಇತರ ಪಕ್ಷಕ್ಕೆ ತಿಳಿಸುತ್ತದೆ. ವಿಶಿಷ್ಟವಾಗಿ, ಬಫರ್ ಗಾತ್ರವನ್ನು ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರಗಳ ಪೂರ್ಣಾಂಕ ಸಂಖ್ಯೆಯಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ.

ಡೇಟಾ ಸ್ಟ್ರೀಮ್ ಇನ್‌ಪುಟ್ ಬಫರ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಮೊದಲು ಅಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ (ಟಿಸಿಪಿ ಪೋರ್ಟ್‌ನಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ). ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.12 4 KB ಅನ್ನು ಸ್ವೀಕರಿಸಬಹುದಾದ ಇನ್‌ಪುಟ್ ಬಫರ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 10.12.ಇನ್‌ಪುಟ್ ಬಫರ್ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ

ಡೇಟಾ ಬಂದಂತೆ ಬಫರ್ ಸ್ಪೇಸ್ ತುಂಬಿದೆ. ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಬಫರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಹಿಂಪಡೆಯಿದಾಗ, ಹೊಸ ಒಳಬರುವ ಡೇಟಾಗೆ ಮುಕ್ತವಾದ ಸ್ಥಳವು ಲಭ್ಯವಾಗುತ್ತದೆ.

ವಿಂಡೋವನ್ನು ಸ್ವೀಕರಿಸಲಾಗುತ್ತಿದೆ(ವಿಂಡೋವನ್ನು ಸ್ವೀಕರಿಸಿ) - ಇನ್‌ಪುಟ್ ಬಫರ್‌ನಲ್ಲಿನ ಯಾವುದೇ ಸ್ಥಳವು ಈಗಾಗಲೇ ಡೇಟಾದಿಂದ ಆಕ್ರಮಿಸಲ್ಪಟ್ಟಿಲ್ಲ. ಗುರಿ ಅಪ್ಲಿಕೇಶನ್ ಬಳಸುವವರೆಗೆ ಡೇಟಾ ಇನ್‌ಪುಟ್ ಬಫರ್‌ನಲ್ಲಿ ಉಳಿಯುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ತಕ್ಷಣವೇ ಡೇಟಾವನ್ನು ಏಕೆ ಸಂಗ್ರಹಿಸುವುದಿಲ್ಲ?

ಈ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸಲು ಸರಳ ಸನ್ನಿವೇಶವು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಅತ್ಯಂತ ಕಾರ್ಯನಿರತ ಬಹು-ಬಳಕೆದಾರ ಕಂಪ್ಯೂಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ FTP ಸರ್ವರ್‌ಗೆ ಕ್ಲೈಂಟ್ ಫೈಲ್ ಅನ್ನು ಕಳುಹಿಸಿದೆ ಎಂದು ಭಾವಿಸೋಣ. FTP ಪ್ರೋಗ್ರಾಂ ನಂತರ ಬಫರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಓದಬೇಕು ಮತ್ತು ಅದನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಬೇಕು. ಸರ್ವರ್ ಡಿಸ್ಕ್ I/O ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಿದಾಗ, ಆ ಕಾರ್ಯಾಚರಣೆಗಳು ಪೂರ್ಣಗೊಳ್ಳಲು ಪ್ರೋಗ್ರಾಂ ಕಾಯುತ್ತದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಮತ್ತೊಂದು ಪ್ರೋಗ್ರಾಂ ಪ್ರಾರಂಭವಾಗಬಹುದು (ಉದಾಹರಣೆಗೆ, ವೇಳಾಪಟ್ಟಿಯ ಪ್ರಕಾರ) ಮತ್ತು FTP ಪ್ರೋಗ್ರಾಂ ಮತ್ತೆ ಪ್ರಾರಂಭವಾದಾಗ, ಮುಂದಿನ ಡೇಟಾವು ಈಗಾಗಲೇ ಬಫರ್‌ನಲ್ಲಿ ಬರುತ್ತದೆ.

ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಕೊನೆಯದಾಗಿ ಒಪ್ಪಿಕೊಂಡ ಬೈಟ್‌ನಿಂದ ಬಫರ್‌ನ ಅಂತ್ಯದವರೆಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ಅಂಜೂರದಲ್ಲಿ. 10.12, ಮೊದಲು ಸಂಪೂರ್ಣ ಬಫರ್ ಲಭ್ಯವಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ, 4 KB ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಲಭ್ಯವಿದೆ. ಮೊದಲ KB ಬಂದಾಗ, ಸ್ವೀಕರಿಸುವ ವಿಂಡೋವನ್ನು 3 KB ಗೆ ಕಡಿಮೆಗೊಳಿಸಲಾಗುತ್ತದೆ (ಸರಳತೆಗಾಗಿ, ಪ್ರತಿ ವಿಭಾಗವು 1 KB ಗಾತ್ರದಲ್ಲಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ, ಆದಾಗ್ಯೂ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಈ ಮೌಲ್ಯವು ಅಪ್ಲಿಕೇಶನ್‌ನ ಅಗತ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುತ್ತದೆ). ಮುಂದಿನ ಎರಡು 1 KB ವಿಭಾಗಗಳ ಆಗಮನವು ಸ್ವೀಕರಿಸುವ ವಿಂಡೋವನ್ನು 1 KB ಗೆ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ರಿಸೀವರ್ ಕಳುಹಿಸುವ ಪ್ರತಿಯೊಂದು ಎಸಿಕೆಯು ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಅದರ ಆಧಾರದ ಮೇಲೆ ಮೂಲದಿಂದ ಡೇಟಾ ಹರಿವು ನಿಯಂತ್ರಿಸಲ್ಪಡುತ್ತದೆ.

ಬಹುಮಟ್ಟಿಗೆ, ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ ಇನ್‌ಪುಟ್ ಬಫರ್‌ನ ಗಾತ್ರವನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ, ಆದಾಗ್ಯೂ TCP ಮಾನದಂಡವು ಈ ಬಫರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದಿಲ್ಲ. ಕಳುಹಿಸುವವರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನೀಡುವ ಮೂಲಕ ಇನ್‌ಪುಟ್ ಬಫರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಬಹುದು ಅಥವಾ ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಬರುವ ವಿಭಾಗವನ್ನು ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದಲ್ಲಿ ಇರಿಸಬಹುದಾದರೂ ಅದು ಕ್ರಮಬದ್ಧವಾಗಿಲ್ಲದಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಎಲ್ಲಾ ಅಳವಡಿಕೆಗಳು ಒಳಬರುವ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತವೆ ಮತ್ತು ಬಹು ವಿಭಾಗಗಳ ಸಂಪೂರ್ಣ ಪಕ್ಕದ ಬ್ಲಾಕ್‌ಗೆ ಮಾತ್ರ ಸ್ವೀಕೃತಿಯನ್ನು (ACK) ಕಳುಹಿಸುತ್ತವೆ ಎಂದು ಸಾಮಾನ್ಯವಾಗಿ ಊಹಿಸಲಾಗಿದೆ. ಇದು ಸರಿಯಾದ ಮಾರ್ಗವಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲದಿದ್ದರೆ, ಆದೇಶದಿಂದ ಹೊರಬರುವ ಡೇಟಾವನ್ನು ತಿರಸ್ಕರಿಸುವುದು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಡೇಟಾವನ್ನು ರವಾನಿಸುವ ವ್ಯವಸ್ಥೆಯು ಎರಡು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಬೇಕು: ಎಷ್ಟು ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ಅಂಗೀಕರಿಸಲಾಗಿದೆ ಮತ್ತು ಸ್ವೀಕರಿಸುವವರ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಪ್ರಸ್ತುತ ಗಾತ್ರ. ಸಕ್ರಿಯ ಜಾಗವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ(ಸ್ಪೇಸ್ ಕಳುಹಿಸು) ಮೊದಲ ಅಂಗೀಕರಿಸದ ಆಕ್ಟೆಟ್‌ನಿಂದ ಪ್ರಸ್ತುತ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಎಡ ಅಂಚಿನವರೆಗೆ ವಿಸ್ತರಿಸುತ್ತದೆ. ಭಾಗ ಕಿಟಕಿ, ಬಳಸಲಾಗುತ್ತದೆ ಕಳುಹಿಸಲು, ಪಾಲುದಾರರಿಗೆ ಎಷ್ಟು ಹೆಚ್ಚುವರಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದು ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ ಮತ್ತು ಆರಂಭಿಕ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಗಾತ್ರವನ್ನು ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ. ಅಕ್ಕಿ. ಚಿತ್ರ 10.13 ಡೇಟಾ ವರ್ಗಾವಣೆ ಕಾರ್ಯವಿಧಾನದ ಕೆಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ.

1. ಕಳುಹಿಸುವವರು 4 KB ಕಳುಹಿಸುವ ವಿಂಡೋದೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

2. ಕಳುಹಿಸುವವರು 1 KB ಕಳುಹಿಸುತ್ತಾರೆ. ಈ ಡೇಟಾದ ನಕಲನ್ನು ಸ್ವೀಕೃತಿ (ACK) ಸ್ವೀಕರಿಸುವವರೆಗೆ ಉಳಿಸಿಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅದನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡಬೇಕಾಗಬಹುದು.

3. ಮೊದಲ KB ಗೆ ACK ಸಂದೇಶ ಬರುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ 2 KB ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಫಲಿತಾಂಶವನ್ನು ಅಂಜೂರದ ಮೇಲಿನಿಂದ ಮೂರನೇ ಭಾಗದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ. 10.13. 2 KB ಸಂಗ್ರಹಣೆ ಮುಂದುವರಿಯುತ್ತದೆ.

4. ಅಂತಿಮವಾಗಿ, ರವಾನೆಯಾದ ಎಲ್ಲಾ ಡೇಟಾಗೆ ACK ಆಗಮಿಸುತ್ತದೆ (ಅಂದರೆ, ರಿಸೀವರ್ ಮೂಲಕ ಎಲ್ಲವನ್ನೂ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆ). ACK ಕಳುಹಿಸುವ ವಿಂಡೋ ಗಾತ್ರವನ್ನು 4 KB ಗೆ ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 10.13.ವಿಂಡೋವನ್ನು ಕಳುಹಿಸಿ

ಗಮನಸೆಳೆಯಲು ಯೋಗ್ಯವಾದ ಹಲವಾರು ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ:

■ ಕಳುಹಿಸುವವರು ಅದು ಕಳುಹಿಸುವ ಪ್ರತಿಯೊಂದು ಡೇಟಾ ವಿಭಾಗಕ್ಕೆ ACK ಗಾಗಿ ಕಾಯುವುದಿಲ್ಲ. ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ಏಕೈಕ ನಿರ್ಬಂಧವೆಂದರೆ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಗಾತ್ರ (ಉದಾಹರಣೆಗೆ, ಕಳುಹಿಸುವವರು 4K ಏಕ-ಬೈಟ್ ವಿಭಾಗಗಳನ್ನು ಮಾತ್ರ ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕು).

■ ಕಳುಹಿಸುವವರು ಹಲವಾರು ಚಿಕ್ಕ ವಿಭಾಗಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಎಂದು ಭಾವಿಸೋಣ (ಉದಾಹರಣೆಗೆ, 80 ಬೈಟ್‌ಗಳು). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಪ್ರಸರಣಕ್ಕಾಗಿ ಡೇಟಾವನ್ನು ಮರು ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ಒಂದೇ ವಿಭಾಗದಲ್ಲಿ).

ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.14 ವಿಭಾಗದ ಸ್ವರೂಪವನ್ನು ತೋರಿಸುತ್ತದೆ (TCP ಹೆಡರ್ ಮತ್ತು ಡೇಟಾ). ಹೆಡರ್ ಮೂಲ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಐಡಿಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಮುಂದಿನ ಮುಂದಿನ ಕ್ಷೇತ್ರ ಕ್ರಮ ಸಂಖ್ಯೆ(ಅನುಕ್ರಮ ಸಂಖ್ಯೆ) ಹೊರಹೋಗುವ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಈ ವಿಭಾಗವು ಆಕ್ರಮಿಸಿಕೊಂಡಿರುವ ಸ್ಥಾನವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಕ್ಷೇತ್ರ ಎಸಿಕೆ(ಸ್ವೀಕಾರ) ಇನ್‌ಪುಟ್ ಡೇಟಾ ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ನಿರೀಕ್ಷಿತ ಮುಂದಿನ ವಿಭಾಗದ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ.

ಅಕ್ಕಿ. 10.14. TCP ವಿಭಾಗ

ಆರು ಧ್ವಜಗಳಿವೆ:

ಕ್ಷೇತ್ರ ಡೇಟಾ ಆಫ್‌ಸೆಟ್‌ಗಳು(ಡೇಟಾ ಆಫ್‌ಸೆಟ್) 32-ಬಿಟ್ ಪದಗಳಲ್ಲಿ TCP ಹೆಡರ್‌ನ ಗಾತ್ರವನ್ನು ಒಳಗೊಂಡಿದೆ. TCP ಹೆಡರ್ 32-ಬಿಟ್ ಬೌಂಡರಿಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬೇಕು.

ಪ್ಯಾರಾಮೀಟರ್ "ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರ"(ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರ - MSS) ಅನ್ನು ಸಿಸ್ಟಮ್‌ನಿಂದ ಸ್ವೀಕರಿಸಬಹುದಾದ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಘೋಷಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಹೆಸರು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಸರಿಯಾಗಿಲ್ಲ. ವಿಶಿಷ್ಟವಾಗಿ TCP ಯಲ್ಲಿ ವಿಭಾಗಹೆಡರ್ ಪ್ಲಸ್ ಡೇಟಾ ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರಎಂದು ವಿವರಿಸಬಹುದು:

ಸ್ವೀಕರಿಸಬಹುದಾದ ದೊಡ್ಡ ಡೇಟಾಗ್ರಾಮ್‌ನ ಗಾತ್ರವು 40 ಆಗಿದೆ

ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, MSS ಶ್ರೇಷ್ಠತೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ ಪೇಲೋಡ್ TCP ಮತ್ತು IP ಹೆಡರ್‌ಗಳು 20 ಬೈಟ್‌ಗಳಷ್ಟು ಉದ್ದವಿರುವಾಗ ರಿಸೀವರ್‌ನಲ್ಲಿ. ಹೆಚ್ಚುವರಿ ನಿಯತಾಂಕಗಳು ಇದ್ದರೆ, ಅವುಗಳ ಉದ್ದವನ್ನು ಒಟ್ಟು ಗಾತ್ರದಿಂದ ಕಳೆಯಬೇಕು. ಆದ್ದರಿಂದ, ಒಂದು ವಿಭಾಗದಲ್ಲಿ ಕಳುಹಿಸಬಹುದಾದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಹೀಗೆ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ:

ಹೇಳಿಕೆ ಮೌಲ್ಯ MSS + 40 – (TCP ಮತ್ತು IP ಹೆಡರ್ ಉದ್ದಗಳ ಮೊತ್ತ)

ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವಾಗ ಆರಂಭಿಕ SYN ಸಂದೇಶಗಳಲ್ಲಿ ಗೆಳೆಯರು ಸಾಮಾನ್ಯವಾಗಿ MSS ಮೌಲ್ಯಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಸಿಸ್ಟಮ್ ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರದ ಮೌಲ್ಯವನ್ನು ಜಾಹೀರಾತು ಮಾಡದಿದ್ದರೆ, 536 ಬೈಟ್‌ಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ.

ಗರಿಷ್ಟ ವಿಭಾಗದ ಗಾತ್ರವನ್ನು 2-ಬೈಟ್ ಲೀಡ್-ಇನ್ ಆಗಿ ಎನ್ಕೋಡ್ ಮಾಡಲಾಗಿದೆ ನಂತರ 2-ಬೈಟ್ ಮೌಲ್ಯ, ಅಂದರೆ. ದೊಡ್ಡ ಮೌಲ್ಯವು 2 16 -1 (65,535 ಬೈಟ್‌ಗಳು) ಆಗಿರುತ್ತದೆ.

TCP ಯಲ್ಲಿ ಕಳುಹಿಸಿದ ಡೇಟಾದ ಮೇಲೆ MSS ತೀವ್ರ ಮಿತಿಯನ್ನು ವಿಧಿಸುತ್ತದೆ: ರಿಸೀವರ್ ದೊಡ್ಡ ಮೌಲ್ಯಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಕಳುಹಿಸುವವರು ವಿಭಾಗಗಳನ್ನು ಬಳಸುತ್ತಾರೆ ಚಿಕ್ಕ ಗಾತ್ರ,ಸಂಪರ್ಕಕ್ಕಾಗಿ ಮಾರ್ಗದಲ್ಲಿ MTU ಗಾತ್ರವನ್ನು ಸಹ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ.

ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಲು ಕಳುಹಿಸಲಾದ ಮೊದಲ ವಿಭಾಗವು 1 ರ SYN ಫ್ಲ್ಯಾಗ್ ಮತ್ತು 0 ರ ACK ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಹೊಂದಿದೆ. ಆರಂಭಿಕ SYN ಒಂದೇ ಒಂದು 0 ಮೌಲ್ಯದೊಂದಿಗೆ ACK ಕ್ಷೇತ್ರವನ್ನು ಹೊಂದಿರುವ ವಿಭಾಗ. TCP ಸೆಶನ್‌ಗಾಗಿ ಇನ್‌ಪುಟ್ ವಿನಂತಿಗಳನ್ನು ಗುರುತಿಸಲು ಭದ್ರತಾ ಪರಿಕರಗಳು ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ.

ಕ್ಷೇತ್ರ ಕ್ರಮ ಸಂಖ್ಯೆಒಳಗೊಂಡಿದೆ ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ(ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ), ಕ್ಷೇತ್ರ ಕಿಟಕಿ -ಆರಂಭಿಕ ಗಾತ್ರ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ. TCP ಸ್ವೀಕರಿಸಲು ನಿರೀಕ್ಷಿಸುವ ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರ (ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದಲ್ಲಿ, 536 ಬೈಟ್‌ಗಳ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ) ಮಾತ್ರ TCP ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಪ್ರಸ್ತುತ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಈ ಮೌಲ್ಯವು 32 ಬಿಟ್‌ಗಳನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಷೇತ್ರದಲ್ಲಿ ಸಂಪರ್ಕ ವಿನಂತಿಯಲ್ಲಿ ಇರುತ್ತದೆ ಆಯ್ಕೆಗಳು(ಆಯ್ಕೆ). MSS ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ TCP ಹೆಡರ್ 24 ಬೈಟ್‌ಗಳಷ್ಟು ಉದ್ದವಾಗಿದೆ.

ಸಂಪರ್ಕ ವಿನಂತಿಗೆ ಅನುದಾನದ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ, ಎರಡೂ ಫ್ಲ್ಯಾಗ್‌ಗಳು (SYN ಮತ್ತು ACK) 1 ಕ್ಕೆ ಸಮಾನವಾಗಿರುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯಿಸುವ ವ್ಯವಸ್ಥೆಯು ಸೂಕ್ತವಾದ ಕ್ಷೇತ್ರದಲ್ಲಿ ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಮತ್ತು ಕ್ಷೇತ್ರದಲ್ಲಿ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಗಾತ್ರವನ್ನು ಸೂಚಿಸುತ್ತದೆ ಕಿಟಕಿ. ಸ್ವೀಕರಿಸುವವರು ಬಳಸಲು ಬಯಸುವ ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರವು ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕ ವಿನಂತಿಯ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಕಂಡುಬರುತ್ತದೆ ( ಆಯ್ಕೆಗಳು) ಈ ಮೌಲ್ಯವು ಸಂಪರ್ಕವನ್ನು ವಿನಂತಿಸುವ ಪಕ್ಷದ ಮೌಲ್ಯಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿರಬಹುದು, ಅಂದರೆ. ಎರಡು ವಿಭಿನ್ನ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಬಹುದು.

ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ 1 ಮೌಲ್ಯದೊಂದಿಗೆ ಮರುಹೊಂದಿಸುವ ಫ್ಲ್ಯಾಗ್ (RST) ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ ಸಂಪರ್ಕ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು.

TCP ವಿವರಣೆಯು ಸಂಪರ್ಕ ಸೆಟಪ್ ಸಮಯದಲ್ಲಿ ಪ್ರತಿ ಪಕ್ಷವು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತದೆ ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ(32-ಬಿಟ್ ಆಂತರಿಕ ಟೈಮರ್ನ ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಆಧರಿಸಿ). ಇದನ್ನು ಹೇಗೆ ಮಾಡಲಾಗುತ್ತದೆ?

ವ್ಯವಸ್ಥೆ ಕುಸಿದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸೋಣ. ಕ್ರ್ಯಾಶ್ ಆಗುವ ಮೊದಲು ಬಳಕೆದಾರರು ಸಂಪರ್ಕವನ್ನು ತೆರೆದರು ಮತ್ತು ಸ್ವಲ್ಪ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸೋಣ. ಚೇತರಿಕೆಯ ನಂತರ, ಈಗಾಗಲೇ ಪ್ರಾರಂಭಿಸಿದ ಸಂಪರ್ಕಗಳು ಮತ್ತು ನಿಯೋಜಿಸಲಾದ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳು ಸೇರಿದಂತೆ, ಕ್ರ್ಯಾಶ್‌ಗೆ ಮೊದಲು ಮಾಡಿದ ಯಾವುದನ್ನೂ ಸಿಸ್ಟಮ್ ಇನ್ನು ಮುಂದೆ ನೆನಪಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಬಳಕೆದಾರನು ಸಂಪರ್ಕವನ್ನು ಮರು-ಸ್ಥಾಪಿಸುತ್ತಾನೆ. ಪೋರ್ಟ್ ಸಂಖ್ಯೆಗಳು ಮೂಲ ಕಾರ್ಯಯೋಜನೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಈಗಾಗಲೇ ಕ್ರ್ಯಾಶ್‌ಗೆ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಮೊದಲು ಸ್ಥಾಪಿಸಲಾದ ಇತರ ಸಂಪರ್ಕಗಳಿಂದ ಬಳಕೆಯಲ್ಲಿರಬಹುದು.

ಆದ್ದರಿಂದ, ಸಂಪರ್ಕದ ಕೊನೆಯಲ್ಲಿ ಇತರ ಪಕ್ಷವು ಅದರ ಪಾಲುದಾರ ಕ್ರ್ಯಾಶ್ ಆಗಿದೆ ಮತ್ತು ನಂತರ ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ತಿಳಿದಿರುವುದಿಲ್ಲ. ಇದೆಲ್ಲವೂ ಗಂಭೀರ ಅಡಚಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ಹಳೆಯ ಡೇಟಾವು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಹಾದುಹೋಗಲು ಮತ್ತು ಹೊಸದಾಗಿ ರಚಿಸಲಾದ ಸಂಪರ್ಕದಿಂದ ಡೇಟಾದೊಂದಿಗೆ ಮಿಶ್ರಣ ಮಾಡಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ನವೀಕರಣದೊಂದಿಗೆ (ತಾಜಾ ಪ್ರಾರಂಭ) ಪ್ರಾರಂಭದ ಟೈಮರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಅಂತಹ ಸಮಸ್ಯೆಗಳನ್ನು ನಿವಾರಿಸುತ್ತದೆ. ಹಳೆಯ ಡೇಟಾವು ಹೊಸ ಸಂಪರ್ಕದ ಅನುಕ್ರಮ ಸಂಖ್ಯೆ ಶ್ರೇಣಿಗಿಂತ ವಿಭಿನ್ನ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಹ್ಯಾಕರ್‌ಗಳು, ವಿಶ್ವಾಸಾರ್ಹ ಹೋಸ್ಟ್‌ಗಾಗಿ ಮೂಲ IP ವಿಳಾಸವನ್ನು ವಂಚಿಸುವಾಗ, ಸಂದೇಶದಲ್ಲಿ ಊಹಿಸಬಹುದಾದ ಆರಂಭಿಕ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಮೂಲಕ ಕಂಪ್ಯೂಟರ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಆಂತರಿಕ ಕೀಲಿಗಳ ಆಧಾರದ ಮೇಲೆ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಹ್ಯಾಶಿಂಗ್ ಕಾರ್ಯವು ಸುರಕ್ಷಿತ ಬೀಜಗಳನ್ನು ಆಯ್ಕೆಮಾಡಲು ಉತ್ತಮ ವಿಧಾನವನ್ನು ಒದಗಿಸುತ್ತದೆ.

ಪ್ರಸರಣಕ್ಕಾಗಿ TCP ಹೆಡರ್ ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವಾಗ, ರವಾನೆಯಾದ ಡೇಟಾದ ಮೊದಲ ಆಕ್ಟೆಟ್‌ನ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಕ್ಷೇತ್ರದಲ್ಲಿ ಸೂಚಿಸಲಾಗುತ್ತದೆ ಕ್ರಮ ಸಂಖ್ಯೆ(ಕ್ರಮ ಸಂಖ್ಯೆ).

ಸಂಪರ್ಕ ಪಾಲುದಾರರಿಂದ ನಿರೀಕ್ಷಿಸಲಾದ ಮುಂದಿನ ಆಕ್ಟೆಟ್‌ನ ಸಂಖ್ಯೆಯನ್ನು ಕ್ಷೇತ್ರದಲ್ಲಿ ನಮೂದಿಸಲಾಗಿದೆ ದೃಢೀಕರಣ(ಸ್ವೀಕಾರ ಸಂಖ್ಯೆ) ACK ಬಿಟ್ ಅನ್ನು 1. ಕ್ಷೇತ್ರಕ್ಕೆ ಹೊಂದಿಸಿದಾಗ ಕಿಟಕಿ(ವಿಂಡೋ) ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಪ್ರಸ್ತುತ ಗಾತ್ರಕ್ಕೆ ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ಈ ಕ್ಷೇತ್ರವು ಒಳಗೊಂಡಿದೆ ಸ್ವೀಕರಿಸಬಹುದಾದ ಸ್ವೀಕೃತಿ ಸಂಖ್ಯೆಯಿಂದ ಬೈಟ್‌ಗಳ ಸಂಖ್ಯೆ. ಈ ಮೌಲ್ಯವು ಡೇಟಾ ಹರಿವಿನ ನಿಖರವಾದ ನಿಯಂತ್ರಣವನ್ನು ಅನುಮತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಈ ಮೌಲ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು, ವಿನಿಮಯ ಅಧಿವೇಶನದಲ್ಲಿ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ನಿಜವಾದ ಸ್ಥಿತಿಯನ್ನು ಪೀರ್ ಸೂಚಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ TCP ನಲ್ಲಿ ಪುಶ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ನಂತರ PUSH ಫ್ಲ್ಯಾಗ್ ಅನ್ನು 1 ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಸ್ವೀಕರಿಸುವ TCP ಈ ಫ್ಲ್ಯಾಗ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು, ಕಳುಹಿಸುವವರು ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬಯಸಿದ ತಕ್ಷಣ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಡೇಟಾವನ್ನು ತ್ವರಿತವಾಗಿ ತಲುಪಿಸಬೇಕು.

ತುರ್ತು ಫ್ಲ್ಯಾಗ್, 1 ಕ್ಕೆ ಹೊಂದಿಸಿದಾಗ, ತುರ್ತು ಡೇಟಾ ವರ್ಗಾವಣೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ ಮತ್ತು ಅನುಗುಣವಾದ ಪಾಯಿಂಟರ್ ತುರ್ತು ಡೇಟಾದ ಕೊನೆಯ ಆಕ್ಟೆಟ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸಬೇಕು. ತುರ್ತು ಡೇಟಾದ ವಿಶಿಷ್ಟ ಬಳಕೆಯು ಟರ್ಮಿನಲ್‌ನಿಂದ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ ಅಥವಾ ಸ್ಥಗಿತಗೊಳಿಸುವ ಸಂಕೇತಗಳನ್ನು ಕಳುಹಿಸುವುದು.

ತುರ್ತು ಡೇಟಾವನ್ನು ಹೆಚ್ಚಾಗಿ ಕರೆಯಲಾಗುತ್ತದೆ ಬ್ಯಾಂಡ್ ಹೊರಗೆ ಮಾಹಿತಿ(ಬ್ಯಾಂಡ್ ಹೊರಗೆ). ಆದಾಗ್ಯೂ, ಈ ಪದವು ಅಸ್ಪಷ್ಟವಾಗಿದೆ. ತುರ್ತು ಡೇಟಾವನ್ನು ಸಾಮಾನ್ಯ TCP ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಕಳುಹಿಸಲಾಗುತ್ತದೆ, ಆದಾಗ್ಯೂ ವೈಯಕ್ತಿಕ ಅನುಷ್ಠಾನಗಳು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತುರ್ತು ಡೇಟಾ ಬಂದಿದೆ ಎಂದು ಸೂಚಿಸಲು ವಿಶೇಷ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಹೊಂದಿರಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ಸಂದೇಶ ಬೈಟ್‌ಗಳು ಬರುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ತುರ್ತು ಡೇಟಾದ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಬೇಕು.

ಸಂಪರ್ಕವನ್ನು ಅಸಹಜವಾಗಿ ಕೊನೆಗೊಳಿಸಿದಾಗ ರೀಸೆಟ್ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು 1 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಪ್ರಸ್ತುತ ಯಾವುದೇ TCP ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿರದ ವಿಭಾಗವು ಬಂದಾಗ ಅದೇ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಹೊಂದಿಸಲಾಗಿದೆ.

ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚುವ ಸಂದೇಶಗಳಿಗಾಗಿ FIN ಫ್ಲ್ಯಾಗ್ ಅನ್ನು 1 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ.

IP ಚೆಕ್‌ಸಮ್ IP ಹೆಡರ್‌ಗೆ ಮಾತ್ರ, TCP ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಸಂಪೂರ್ಣ ವಿಭಾಗಕ್ಕೆ ಮತ್ತು IP ಹೆಡರ್‌ನಿಂದ ರಚಿಸಲಾದ ಹುಸಿ-ಹೆಡರ್‌ಗೆ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. TCP ಚೆಕ್ಸಮ್ ಲೆಕ್ಕಾಚಾರದ ಸಮಯದಲ್ಲಿ, ಅನುಗುಣವಾದ ಕ್ಷೇತ್ರವು 0 ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಚಿತ್ರ 10.15 ಯುಡಿಪಿ ಚೆಕ್‌ಸಮ್‌ನಲ್ಲಿ ಬಳಸಿದ ಹುಸಿ-ಹೆಡರ್ ಅನ್ನು ಹೋಲುತ್ತದೆ.

ಅಕ್ಕಿ. 10.15.ಹುಸಿ-ಹೆಡರ್ ಕ್ಷೇತ್ರವನ್ನು TCP ಚೆಕ್‌ಸಮ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ

TCP ಹೆಡರ್‌ನ ಉದ್ದವನ್ನು ಡೇಟಾದ ಉದ್ದಕ್ಕೆ ಸೇರಿಸುವ ಮೂಲಕ TCP ಉದ್ದವನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ. TCP ಚೆಕ್ಸಮ್ ಆಗಿದೆ ಕಡ್ಡಾಯ, ಯುಡಿಪಿಯಂತೆ ಅಲ್ಲ. ಆಗಮಿಸುವ ವಿಭಾಗದ ಚೆಕ್‌ಸಮ್ ಅನ್ನು ಮೊದಲು ರಿಸೀವರ್‌ನಿಂದ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ TCP ಹೆಡರ್ ಚೆಕ್‌ಸಮ್ ಕ್ಷೇತ್ರದ ವಿಷಯಗಳೊಂದಿಗೆ ಹೋಲಿಸಲಾಗುತ್ತದೆ. ಮೌಲ್ಯಗಳು ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ವಿಭಾಗವನ್ನು ತ್ಯಜಿಸಲಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 10.16, ವಿಶ್ಲೇಷಕ ಕಾರ್ಯಾಚರಣೆ ಪ್ರೋಟೋಕಾಲ್ ಸ್ನಿಫರ್ನೆಟ್‌ವರ್ಕ್ ಜನರಲ್‌ನಿಂದ, TCP ವಿಭಾಗಗಳ ಅನುಕ್ರಮವಾಗಿದೆ. ಮೊದಲ ಮೂರು ವಿಭಾಗಗಳು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ ಟೆಲ್ನೆಟ್. ಕೊನೆಯ ವಿಭಾಗವು 12 ಬೈಟ್‌ಗಳ ಡೇಟಾವನ್ನು ಹೊಂದಿದೆ.

ಅಕ್ಕಿ. 10.16.ಸ್ನಿಫರ್ ವಿಶ್ಲೇಷಕದಿಂದ TCP ಹೆಡರ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತಿದೆ

ವಿಶ್ಲೇಷಕ ಸ್ನಿಫರ್ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳನ್ನು ದಶಮಾಂಶ ರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಫ್ಲ್ಯಾಗ್ ಮೌಲ್ಯಗಳು ಹೆಕ್ಸಾಡೆಸಿಮಲ್ ಆಗಿ ಔಟ್ಪುಟ್ ಆಗಿವೆ. 12 ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವ ಫ್ಲ್ಯಾಗ್ 010010 ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಚೆಕ್‌ಸಮ್ ಸಹ ಹೆಕ್ಸಾಡೆಸಿಮಲ್‌ನಲ್ಲಿ ಔಟ್‌ಪುಟ್ ಆಗಿದೆ.

ವೇಗದ ಕಳುಹಿಸುವವರು ಮತ್ತು ನಿಧಾನ ರಿಸೀವರ್ ಗಾತ್ರ 0 ಬೈಟ್‌ಗಳ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋವನ್ನು ರಚಿಸಬಹುದು. ಈ ಫಲಿತಾಂಶವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಕಿಟಕಿಯನ್ನು ಮುಚ್ಚುವುದು(ಕಿಟಕಿ ಮುಚ್ಚಿ). ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಗಾತ್ರವನ್ನು ನವೀಕರಿಸಲು ಮುಕ್ತ ಸ್ಥಳವು ಲಭ್ಯವಾದಾಗ, ACK ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಅಂತಹ ಸಂದೇಶವು ಕಳೆದುಹೋದರೆ, ಎರಡೂ ಪಕ್ಷಗಳು ಅನಿರ್ದಿಷ್ಟವಾಗಿ ಕಾಯಬೇಕಾಗುತ್ತದೆ.

ಈ ಪರಿಸ್ಥಿತಿಯನ್ನು ತಪ್ಪಿಸಲು, ಕಳುಹಿಸುವವರು ಹೊಂದಿಸುತ್ತಾರೆ ಉಳಿಸಬಹುದಾದ ಟೈಮರ್(ಪರ್ಸಿಸ್ಟ್ ಟೈಮರ್) ತಾತ್ಕಾಲಿಕ ವಿಂಡೋವನ್ನು ಮುಚ್ಚುವಾಗ. ಟೈಮರ್ ಮೌಲ್ಯವು ಮರುಪ್ರಸಾರ ಸಮಯ ಮೀರಿದೆ. ಟೈಮರ್ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ಒಂದು ವಿಭಾಗವನ್ನು ಪಾಲುದಾರರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ವಿಂಡೋ ಸೆನ್ಸಿಂಗ್(ವಿಂಡೋ ಪ್ರೋಬ್; ಕೆಲವು ಅಳವಡಿಕೆಗಳು ಡೇಟಾವನ್ನು ಒಳಗೊಂಡಿವೆ). ಪ್ರಸ್ತುತ ವಿಂಡೋ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುವ ACK ಅನ್ನು ಪೀರ್ ಮರಳಿ ಕಳುಹಿಸಲು ಪ್ರೋಬಿಂಗ್ ಕಾರಣವಾಗುತ್ತದೆ.

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

ದೋಷಯುಕ್ತ ಗೇಟ್‌ವೇ ಅಥವಾ ಲಿಂಕ್‌ನಿಂದಾಗಿ ಸಂಪರ್ಕ ಪಾಲುದಾರ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದು ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಅಡಚಣೆಯಾಗಬಹುದು. TCP ಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುವುದನ್ನು ತಡೆಯಲು, ಹಲವಾರು ಕಾರ್ಯವಿಧಾನಗಳಿವೆ.

TCP ಮೊದಲ ಮರುಪ್ರಸಾರ ಮಿತಿಯನ್ನು ತಲುಪಿದಾಗ, ವಿಫಲವಾದ ರೂಟರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು IP ಗೆ ಹೇಳುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಸಮಸ್ಯೆ ಇದೆ ಎಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಿಳಿಸುತ್ತದೆ. ಸಂಪರ್ಕವನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಎರಡನೇ ಮಿತಿಯನ್ನು ತಲುಪುವವರೆಗೆ TCP ಡೇಟಾವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.

ಸಹಜವಾಗಿ, ಇದು ಸಂಭವಿಸುವ ಮೊದಲು, ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪಲಾಗುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುವ ICMP ಸಂದೇಶವು ಆಗಮಿಸಬಹುದು. ಕೆಲವು ಅಳವಡಿಕೆಗಳಲ್ಲಿ, ಇದರ ನಂತರವೂ, ಸಮಯ ಮೀರುವ ಮಧ್ಯಂತರ ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ TCP ಗಮ್ಯಸ್ಥಾನವನ್ನು ಪ್ರವೇಶಿಸಲು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ (ಆ ಸಮಯದಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಬಹುದು). ಮುಂದೆ, ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪಲಾಗುವುದಿಲ್ಲ ಎಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ತಿಳಿಸಲಾಗಿದೆ.

ಡೇಟಾ ವಿತರಣೆಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ಕಾಲಾವಧಿಯನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಈ ಮಧ್ಯಂತರವು ಕೊನೆಗೊಂಡಾಗ ತನ್ನದೇ ಆದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮಾಡಬಹುದು. ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಲಾಗುತ್ತದೆ.

ಅಪೂರ್ಣ ಸಂಪರ್ಕವು ದೀರ್ಘಕಾಲದವರೆಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ನಿಷ್ಕ್ರಿಯವಾಗುತ್ತದೆ. ನಿಷ್ಕ್ರಿಯತೆಯ ಅವಧಿಯಲ್ಲಿ, ನೆಟ್‌ವರ್ಕ್ ಕ್ರ್ಯಾಶ್ ಆಗಬಹುದು ಅಥವಾ ಭೌತಿಕ ಸಂವಹನ ಮಾರ್ಗಗಳು ಅಡ್ಡಿಯಾಗಬಹುದು. ನೆಟ್‌ವರ್ಕ್ ಮತ್ತೆ ಕಾರ್ಯನಿರ್ವಹಿಸಿದ ತಕ್ಷಣ, ಪಾಲುದಾರರು ಸಂವಹನ ಸೆಷನ್‌ಗೆ ಅಡ್ಡಿಯಾಗದಂತೆ ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ. ಈ ತಂತ್ರವು ರಕ್ಷಣಾ ಸಚಿವಾಲಯದ ಅಗತ್ಯತೆಗಳಿಗೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ಯಾವುದೇ ಸಂಪರ್ಕ - ಸಕ್ರಿಯ ಅಥವಾ ನಿಷ್ಕ್ರಿಯ - ಬಹಳಷ್ಟು ಕಂಪ್ಯೂಟರ್ ಮೆಮೊರಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಕೆಲವು ನಿರ್ವಾಹಕರು ಬಳಕೆಯಾಗದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಹಿಂತಿರುಗಿಸಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಅನೇಕ TCP ಅಳವಡಿಕೆಗಳು ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಲು ಸಮರ್ಥವಾಗಿವೆ ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವುದು(ಜೀವಂತವಾಗಿರಿಸಿಕೊಳ್ಳಿ), ಇದು ನಿಷ್ಕ್ರಿಯ ಸಂಪರ್ಕಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಅದರ ಅಸ್ತಿತ್ವವನ್ನು ಪರಿಶೀಲಿಸಲು ಅಂತಹ ಸಂದೇಶಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಪಾಲುದಾರರಿಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆ ACK ಸಂದೇಶಗಳಾಗಿರಬೇಕು. ಕೀಪ್-ಲೈವ್ ಸಂದೇಶಗಳ ಬಳಕೆ ಐಚ್ಛಿಕವಾಗಿರುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅದನ್ನು ಅತಿಕ್ರಮಿಸಬಹುದು. ಅಂದಾಜು ಅವಧಿ ಪೂರ್ವನಿಯೋಜಿತಸಂಪರ್ಕ ನಿರ್ವಹಣೆಯ ಅವಧಿ ಪೂರ್ಣ ಎರಡು ಗಂಟೆಗಳು!

ಅಪ್ಲಿಕೇಶನ್ ತನ್ನದೇ ಆದ ಟೈಮರ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು ಎಂಬುದನ್ನು ನಾವು ನೆನಪಿಸೋಣ, ಅದರ ಪ್ರಕಾರ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಬೇಕೆ ಎಂದು ಅದು ತನ್ನದೇ ಆದ ಮಟ್ಟದಲ್ಲಿ ನಿರ್ಧರಿಸುತ್ತದೆ.

TCP ಎಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ? ಸಂಪನ್ಮೂಲ ಕಾರ್ಯಕ್ಷಮತೆಯು ಅನೇಕ ಅಂಶಗಳಿಂದ ಪ್ರಭಾವಿತವಾಗಿರುತ್ತದೆ, ಮುಖ್ಯವಾದವುಗಳು ಮೆಮೊರಿ ಮತ್ತು ಬ್ಯಾಂಡ್ವಿಡ್ತ್ (ಚಿತ್ರ 10.17 ನೋಡಿ).

ಅಕ್ಕಿ. 10.17. TCP ಕಾರ್ಯಕ್ಷಮತೆಯ ಅಂಶಗಳು

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

ಸ್ವೀಕರಿಸುವ ಅಂತ್ಯವು ಕಳುಹಿಸುವವರಿಗೆ ಯಾವುದೇ ಅಡಚಣೆಯಿಲ್ಲದೆ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ಅನುಮತಿಸಲು ಸಾಕಷ್ಟು ಬಫರ್ ಸ್ಥಳವನ್ನು ಒದಗಿಸಬೇಕು. ಹೈ-ಲೇಟೆನ್ಸಿ ನೆಟ್‌ವರ್ಕ್‌ಗಳಿಗೆ ಇದು ವಿಶೇಷವಾಗಿ ಮುಖ್ಯವಾಗಿದೆ, ಅಲ್ಲಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ACK ಸ್ವೀಕರಿಸುವ ನಡುವೆ ದೀರ್ಘಾವಧಿಯ ಮಧ್ಯಂತರವಿದೆ (ಮತ್ತು ವಿಂಡೋ ಗಾತ್ರವನ್ನು ಮಾತುಕತೆ ಮಾಡುವಾಗ). ಮೂಲದಿಂದ ಡೇಟಾದ ಸ್ಥಿರ ಹರಿವನ್ನು ನಿರ್ವಹಿಸಲು, ಸ್ವೀಕರಿಸುವ ತುದಿಯು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು ಲೇಟೆನ್ಸಿಯ ಉತ್ಪನ್ನದ ಕನಿಷ್ಠ ಗಾತ್ರದ ವಿಂಡೋವನ್ನು ಹೊಂದಿರಬೇಕು.

ಉದಾಹರಣೆಗೆ, ಮೂಲವು 10,000 ಬೈಟ್‌ಗಳು/ಸೆಕೆಂಡು ದರದಲ್ಲಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬಹುದಾದರೆ ಮತ್ತು ACK ಹಿಂತಿರುಗಲು 2 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಇನ್ನೊಂದು ಬದಿಯು ಕನಿಷ್ಟ 20,000 ಬೈಟ್‌ಗಳ ಗಾತ್ರದಲ್ಲಿ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋವನ್ನು ಒದಗಿಸಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಡೇಟಾ ಹರಿವು ಆಗುವುದಿಲ್ಲ ನಿರಂತರವಾಗಿರಲಿ. 10,000 ಬೈಟ್ ಸ್ವೀಕರಿಸುವ ಬಫರ್ ಥ್ರೋಪುಟ್ ಅನ್ನು ಅರ್ಧದಷ್ಟು ಕಡಿತಗೊಳಿಸುತ್ತದೆ.

ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಮತ್ತೊಂದು ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯ ಘಟನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಮತ್ತು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಹೋಸ್ಟ್‌ನ ಸಾಮರ್ಥ್ಯ ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್, ಅಂದರೆ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ ಮತ್ತು ಇತರರಿಗೆ ಬದಲಿಸಿ. ಹೋಸ್ಟ್ ಬಹು ಸ್ಥಳೀಯ ಬಳಕೆದಾರರು, ಬ್ಯಾಚ್ ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಡಜನ್ಗಟ್ಟಲೆ ಏಕಕಾಲಿಕ ಸಂವಹನ ಸಂಪರ್ಕಗಳನ್ನು ಸಂವಾದಾತ್ಮಕವಾಗಿ ಬೆಂಬಲಿಸುತ್ತದೆ. ಸಿಸ್ಟಂನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಮರೆಮಾಡುವಾಗ ಈ ಎಲ್ಲಾ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸನ್ನಿವೇಶ ಸ್ವಿಚಿಂಗ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ನೊಂದಿಗೆ TCP/IP ಅನ್ನು ಸಂಯೋಜಿಸುವ ಅಳವಡಿಕೆಗಳು ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ಬಳಸುವ ಹೊರೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು.

TCP ಹೆಡರ್ ಪ್ರಕ್ರಿಯೆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಕಂಪ್ಯೂಟರ್ CPU ಸಂಪನ್ಮೂಲಗಳು ಅಗತ್ಯವಿದೆ. ಪ್ರೊಸೆಸರ್ ತ್ವರಿತವಾಗಿ ಚೆಕ್ಸಮ್ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಇದು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಡೇಟಾ ವರ್ಗಾವಣೆಯ ವೇಗದಲ್ಲಿ ಇಳಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡೆವಲಪರ್‌ಗಳು TCP ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಸಂರಚನೆಯನ್ನು ಸರಳೀಕರಿಸಲು ನೋಡಬೇಕು ಇದರಿಂದ ನೆಟ್‌ವರ್ಕ್ ನಿರ್ವಾಹಕರು ತಮ್ಮ ಸ್ಥಳೀಯ ಅವಶ್ಯಕತೆಗಳಿಗೆ ಸರಿಹೊಂದುವಂತೆ ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಉದಾಹರಣೆಗೆ, ಬಫರ್ ಗಾತ್ರವನ್ನು ನೆಟ್‌ವರ್ಕ್ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು ಲೇಟೆನ್ಸಿಗೆ ಹೊಂದಿಸುವ ಸಾಮರ್ಥ್ಯವು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಸುಧಾರಿಸುತ್ತದೆ. ದುರದೃಷ್ಟವಶಾತ್, ಅನೇಕ ಅಳವಡಿಕೆಗಳು ಈ ಸಮಸ್ಯೆಗೆ ಸಾಕಷ್ಟು ಗಮನ ಕೊಡುವುದಿಲ್ಲ ಮತ್ತು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಪ್ರೋಗ್ರಾಂ ಸಂವಹನ ನಿಯತಾಂಕಗಳನ್ನು.

ನೆಟ್‌ವರ್ಕ್ ಪರಿಸರವು ಪರಿಪೂರ್ಣವಾಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ: ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳಿವೆ ಮತ್ತು ಕೌಬಾಯ್‌ಗಳು ತಮ್ಮ ರಿವಾಲ್ವರ್‌ಗಳನ್ನು ಬೀಸುವುದಕ್ಕಿಂತ ವೇಗವಾಗಿ ಸಂದರ್ಭ ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಅತ್ಯುತ್ತಮ ಪ್ರದರ್ಶನ ಸಿಗುತ್ತದೆಯೇ?

ಯಾವಾಗಲು ಅಲ್ಲ. ಟಿಸಿಪಿ ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿಯ ಗುಣಮಟ್ಟವೂ ಮುಖ್ಯವಾಗಿದೆ. ವರ್ಷಗಳಲ್ಲಿ, ಅನೇಕ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ವಿವಿಧ TCP ಅಳವಡಿಕೆಗಳಲ್ಲಿ ಗುರುತಿಸಲಾಗಿದೆ ಮತ್ತು ಪರಿಹರಿಸಲಾಗಿದೆ. ಇಂಟರ್ನೆಟ್ ಹೋಸ್ಟ್‌ಗಳ ಸಂವಹನ ಪದರದ ಅವಶ್ಯಕತೆಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ RFC 1122 ಗೆ ಅನುಗುಣವಾಗಿ ಅತ್ಯುತ್ತಮ ಸಾಫ್ಟ್‌ವೇರ್ ಎಂದು ಪರಿಗಣಿಸಬಹುದು.

ಅಪವಾದವೂ ಅಷ್ಟೇ ಮುಖ್ಯ ಮತ್ತು ಜಾಕೋಬ್ಸನ್, ಕೆರ್ನ್ ಮತ್ತು ಪಾರ್ಟ್ರಿಡ್ಜ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಬಳಕೆ (ಈ ಆಸಕ್ತಿದಾಯಕ ಕ್ರಮಾವಳಿಗಳನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗುವುದು).

ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್‌ಗಳು ಸಣ್ಣ ಪ್ರಮಾಣದ ಡೇಟಾದ ಅನಗತ್ಯ ವರ್ಗಾವಣೆಯನ್ನು ತೆಗೆದುಹಾಕುವ ಪ್ರೋಗ್ರಾಂಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ಗಮನಾರ್ಹ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಬಹುದು ಮತ್ತು ಪ್ರಸ್ತುತ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಉಚಿತ ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಟೈಮರ್‌ಗಳನ್ನು ಹೊಂದಬಹುದು.

TCP ಯ ಸಂಕೀರ್ಣವಾದ ಭಾಗವನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಮುಂದುವರಿಯುತ್ತಾ, ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮತ್ತು ಕಡಿಮೆ ಥ್ರೋಪುಟ್‌ನೊಂದಿಗೆ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. ಈ ವಿಭಾಗವು ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಚರ್ಚಿಸುತ್ತದೆ:

■ ನಿಧಾನ ಆರಂಭ(ನಿಧಾನ ಆರಂಭ) ಜಾಲದ ದಟ್ಟಣೆಯ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ಹೊಸ ಸೆಷನ್‌ಗಾಗಿ ಬಳಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು ವ್ಯರ್ಥಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು.

■ ನಿಂದ ಗುಣಪಡಿಸುವುದು "ಕ್ಲೂಲೆಸ್ ವಿಂಡೋ" ಸಿಂಡ್ರೋಮ್(ಸಿಲ್ಲಿ ವಿಂಡೋ ಸಿಂಡ್ರೋಮ್) ಕಳಪೆಯಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸಂದೇಶಗಳೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

■ ತಡವಾದ ACK(ವಿಳಂಬ ACK) ಸ್ವತಂತ್ರ ಡೇಟಾ ಫಾರ್ವರ್ಡ್ ಸ್ವೀಕೃತಿ ಸಂದೇಶಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ದಟ್ಟಣೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

■ ಮರುಪ್ರಸಾರ ಸಮಯ ಮೀರಿದೆ ಎಂದು ಲೆಕ್ಕಹಾಕಲಾಗಿದೆ(ಕಂಪ್ಯೂಟಿಂಗ್ ಮರುಪ್ರಸಾರ ಸಮಯ ಮೀರಿದೆ) ನೈಜ ಅಧಿವೇಶನ ಸಮಯದ ಮಾತುಕತೆಯ ಮೇಲೆ ಆಧಾರಿತವಾಗಿದೆ, ಅನಗತ್ಯ ಮರುಪ್ರಸಾರಗಳ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ, ಆದರೆ ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಾದ ಡೇಟಾ ವಿನಿಮಯಕ್ಕಾಗಿ ದೊಡ್ಡ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ.

■ ಯಾವಾಗ TCP ಫಾರ್ವರ್ಡ್ ಮಾಡುವಿಕೆಯ ಪ್ರತಿಬಂಧ ಓವರ್ಲೋಡ್ಗಳುನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ರೂಟರ್‌ಗಳು ತಮ್ಮ ಮೂಲ ಮೋಡ್‌ಗೆ ಹಿಂತಿರುಗಲು ಮತ್ತು ಎಲ್ಲಾ ಸೆಷನ್‌ಗಳಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಅನುಮತಿಸುತ್ತದೆ.

■ ರವಾನೆ ನಕಲಿ ಎಸಿಕೆಗಳು(ನಕಲು ACK) ಅನುಕ್ರಮದಿಂದ ಒಂದು ವಿಭಾಗವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಸಮಯ ಮೀರುವ ಮೊದಲು ಮರುಪ್ರಸಾರ ಮಾಡಲು ಗೆಳೆಯರನ್ನು ಅನುಮತಿಸುತ್ತದೆ.

ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಮನೆಯಲ್ಲಿ ಎಲ್ಲಾ ಮನೆಯ ವಿದ್ಯುತ್ ಉಪಕರಣಗಳನ್ನು ಆನ್ ಮಾಡಿದರೆ, ವಿದ್ಯುತ್ ನೆಟ್ವರ್ಕ್ ಓವರ್ಲೋಡ್ ಆಗುತ್ತದೆ. ಕಂಪ್ಯೂಟರ್ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ನಿಧಾನ ಆರಂಭಮುಖ್ಯ ಫ್ಯೂಸ್‌ಗಳನ್ನು ಊದುವುದನ್ನು ತಡೆಯುತ್ತದೆ.

ಈಗಾಗಲೇ ಕಾರ್ಯನಿರತ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ತಕ್ಷಣ ಪ್ರಾರಂಭಿಸುವ ಹೊಸ ಸಂಪರ್ಕವು ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. ನಿಧಾನಗತಿಯ ಪ್ರಾರಂಭದ ಕಲ್ಪನೆಯು ನಿಜವಾದ ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್‌ಗೆ ಅನುಗುಣವಾಗಿ ಡೇಟಾ ವರ್ಗಾವಣೆ ದರವನ್ನು ನಿಧಾನವಾಗಿ ಹೆಚ್ಚಿಸುವಾಗ ಹೊಸ ಸಂಪರ್ಕವು ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಾರಂಭವಾಗುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು. ಕಳುಹಿಸುವವರು ಲೋಡ್ ವಿಂಡೋದ ಗಾತ್ರದಿಂದ ಸೀಮಿತವಾಗಿರುತ್ತಾರೆ, ದೊಡ್ಡ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದಿಂದಲ್ಲ.

ವಿಂಡೋವನ್ನು ಲೋಡ್ ಮಾಡಿ(ದಟ್ಟಣೆ ವಿಂಡೋ) 1 ವಿಭಾಗದ ಗಾತ್ರದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಯಶಸ್ವಿಯಾಗಿ ಸ್ವೀಕರಿಸಿದ ACK ಯೊಂದಿಗೆ ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ, ಸ್ವೀಕರಿಸುವ ವಿಂಡೋಕ್ಕಿಂತ ಚಿಕ್ಕದಾಗುವವರೆಗೆ ಲೋಡ್ ವಿಂಡೋ ಗಾತ್ರವನ್ನು 1 ವಿಭಾಗದಿಂದ ಹೆಚ್ಚಿಸಲಾಗುತ್ತದೆ. ನೆಟ್ವರ್ಕ್ ದಟ್ಟಣೆಯಿಲ್ಲದಿದ್ದರೆ, ಲೋಡ್ ವಿಂಡೋ ಕ್ರಮೇಣ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಗಾತ್ರವನ್ನು ತಲುಪುತ್ತದೆ. ಸಾಮಾನ್ಯ ಫಾರ್ವರ್ಡ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ಈ ವಿಂಡೋಗಳ ಗಾತ್ರಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ.

ನಿಧಾನವಾದ ಆರಂಭವು ನಿಧಾನವಾಗಿರುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಮೊದಲ ACK ನಂತರ, ಲೋಡ್ ವಿಂಡೋ ಗಾತ್ರವು 2 ವಿಭಾಗಗಳು, ಮತ್ತು ಎರಡು ಭಾಗಗಳಿಗೆ ACK ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಗಾತ್ರವು 8 ಭಾಗಗಳಿಗೆ ಹೆಚ್ಚಾಗಬಹುದು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ವಿಂಡೋ ಗಾತ್ರವು ಘಾತೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.

ACK ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಬದಲು, ಸಮಯ ಮೀರುವ ಪರಿಸ್ಥಿತಿ ಉಂಟಾಗುತ್ತದೆ ಎಂದು ಭಾವಿಸೋಣ. ಈ ಸಂದರ್ಭದಲ್ಲಿ ಲೋಡ್ ವಿಂಡೋದ ನಡವಳಿಕೆಯನ್ನು ಕೆಳಗೆ ಚರ್ಚಿಸಲಾಗಿದೆ.

ಮೊದಲ TCP/IP ಅಳವಡಿಕೆಗಳಲ್ಲಿ, ಅಭಿವರ್ಧಕರು ಈ ವಿದ್ಯಮಾನವನ್ನು ಎದುರಿಸಿದರು "ಕ್ಲೂಲೆಸ್ ವಿಂಡೋ" ಸಿಂಡ್ರೋಮ್(ಸಿಲ್ಲಿ ವಿಂಡೋ ಸಿಂಡ್ರೋಮ್ - SWS), ಇದು ಸಾಕಷ್ಟು ಬಾರಿ ಕಾಣಿಸಿಕೊಂಡಿತು. ನಡೆಯುತ್ತಿರುವ ಘಟನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಈ ಕೆಳಗಿನ ಸನ್ನಿವೇಶವನ್ನು ಪರಿಗಣಿಸಿ, ಇದು ಅನಪೇಕ್ಷಿತ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ, ಆದರೆ ಸಾಕಷ್ಟು ಸಾಧ್ಯ:

1. ಕಳುಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ತ್ವರಿತವಾಗಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

2. ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಇನ್‌ಪುಟ್ ಬಫರ್‌ನಿಂದ 1 ಬೈಟ್ ಡೇಟಾವನ್ನು ಓದುತ್ತದೆ (ಅಂದರೆ ನಿಧಾನವಾಗಿ).

3. ಓದಿದ ನಂತರ ಇನ್‌ಪುಟ್ ಬಫರ್ ತ್ವರಿತವಾಗಿ ತುಂಬುತ್ತದೆ.

4. ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ 1 ಬೈಟ್ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು TCP ACK ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಅಂದರೆ "1 ಬೈಟ್ ಡೇಟಾಗೆ ನನ್ನ ಬಳಿ ಉಚಿತ ಸ್ಥಳವಿದೆ."

5. ಕಳುಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ 1-ಬೈಟ್ TCP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

6. ಸ್ವೀಕರಿಸುವ TCP ACK ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಅಂದರೆ "ಧನ್ಯವಾದಗಳು. ನಾನು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದ್ದೇನೆ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಉಚಿತ ಸ್ಥಳವಿಲ್ಲ."

7. ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ 1 ಬೈಟ್ ಅನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ACK ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಇಡೀ ಪ್ರಕ್ರಿಯೆಯು ಪುನರಾವರ್ತನೆಯಾಗುತ್ತದೆ.

ನಿಧಾನವಾಗಿ ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾ ಬರಲು ದೀರ್ಘಕಾಲ ಕಾಯುತ್ತದೆ ಮತ್ತು ನಿರಂತರವಾಗಿ ಸ್ವೀಕರಿಸಿದ ಮಾಹಿತಿಯನ್ನು ವಿಂಡೋದ ಎಡ ಅಂಚಿಗೆ ತಳ್ಳುತ್ತದೆ, ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಹೆಚ್ಚುವರಿ ದಟ್ಟಣೆಯನ್ನು ಉಂಟುಮಾಡುವ ಸಂಪೂರ್ಣ ಅನುಪಯುಕ್ತ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ.

ನೈಜ ಸನ್ನಿವೇಶಗಳು, ಸಹಜವಾಗಿ, ತುಂಬಾ ತೀವ್ರವಾಗಿಲ್ಲ. ವೇಗದ ಕಳುಹಿಸುವವರು ಮತ್ತು ನಿಧಾನ ರಿಸೀವರ್ ಸಣ್ಣ (ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ) ಡೇಟಾವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಬಹುತೇಕ ಪೂರ್ಣ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಮೇಲೆ ಬದಲಾಯಿಸುತ್ತಾರೆ. ಅಂಜೂರದಲ್ಲಿ. ಚಿತ್ರ 10.18 "ಸ್ಟುಪಿಡ್ ವಿಂಡೋ" ಸಿಂಡ್ರೋಮ್ನ ಗೋಚರಿಸುವಿಕೆಯ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 10.18ಬಫರ್ ರಿಸೀವಿಂಗ್ ವಿಂಡೋ ಬಹಳ ಕಡಿಮೆ ಜಾಗವನ್ನು ಹೊಂದಿದೆ

ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವುದು ಕಷ್ಟವೇನಲ್ಲ. ಸ್ವೀಕರಿಸುವ ವಿಂಡೋವು ಈ ಗುರಿಯ ಗಾತ್ರಕ್ಕಿಂತ ಕಡಿಮೆ ಉದ್ದಕ್ಕೆ ಕಡಿಮೆಯಾದ ತಕ್ಷಣ, TCP ಕಳುಹಿಸುವವರನ್ನು ಮೋಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಕಳುಹಿಸುವವರಿಗೆ TCP ಸೂಚಿಸಬಾರದು ಹೆಚ್ಚುವರಿಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಬಫರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ಸಣ್ಣ ಭಾಗಗಳಲ್ಲಿ ಓದಿದಾಗ ವಿಂಡೋ ಸ್ಪೇಸ್. ಬದಲಾಗಿ, ಬಿಡುಗಡೆ ಮಾಡಿದ ಸಂಪನ್ಮೂಲಗಳು ಸಾಕಷ್ಟು ಇರುವವರೆಗೆ ಕಳುಹಿಸುವವರಿಂದ ನೀವು ರಹಸ್ಯವಾಗಿಡಬೇಕಾಗುತ್ತದೆ. ಸಂಪೂರ್ಣ ಇನ್‌ಪುಟ್ ಬಫರ್ ಒಂದೇ ವಿಭಾಗವನ್ನು ಸಂಗ್ರಹಿಸದ ಹೊರತು ಒಂದೇ ವಿಭಾಗದ ಗಾತ್ರವನ್ನು ಶಿಫಾರಸು ಮಾಡಲಾಗುತ್ತದೆ (ನಂತರದ ಸಂದರ್ಭದಲ್ಲಿ, ಅರ್ಧ-ಬಫರ್ ಗಾತ್ರವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ). TCP ವರದಿ ಮಾಡಬೇಕಾದ ಗುರಿ ಗಾತ್ರವನ್ನು ಹೀಗೆ ವ್ಯಕ್ತಪಡಿಸಬಹುದು:

ಕನಿಷ್ಠ (1/2 ಇನ್‌ಪುಟ್ ಬಫರ್, ಗರಿಷ್ಠ ವಿಭಾಗದ ಗಾತ್ರ)

ವಿಂಡೋ ಗಾತ್ರವು ಈ ಗಾತ್ರಕ್ಕಿಂತ ಚಿಕ್ಕದಾದಾಗ TCP ಸುಳ್ಳು ಹೇಳಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ವಿಂಡೋ ಗಾತ್ರವು ಸೂತ್ರದಿಂದ ಪಡೆದ ಮೌಲ್ಯಕ್ಕಿಂತ ಕಡಿಮೆಯಿಲ್ಲದಿದ್ದಾಗ ಸತ್ಯವನ್ನು ಹೇಳುತ್ತದೆ. ಕಳುಹಿಸುವವರಿಗೆ ಯಾವುದೇ ಹಾನಿ ಇಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸಿ, ಏಕೆಂದರೆ ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗಾದರೂ ಅದು ನಿರೀಕ್ಷಿಸುವ ಹೆಚ್ಚಿನ ಡೇಟಾವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

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

ಕಳುಹಿಸುವವರು, ಸ್ವೀಕರಿಸುವವರಿಗಿಂತ ಸ್ವತಂತ್ರವಾಗಿ, ಕಳುಹಿಸುವ ಮೊದಲು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಮೂಲಕ ಬಹಳ ಕಡಿಮೆ ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ತಪ್ಪಿಸಬೇಕು. ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಳುಹಿಸಲಾದ ಕಿರು ಡೇಟಾಗ್ರಾಮ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಅತ್ಯಂತ ಸರಳವಾದ ಕಲ್ಪನೆಯನ್ನು Nagle ನ ಅಲ್ಗಾರಿದಮ್ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಹಿಂದೆ ರವಾನೆಯಾದ ಡೇಟಾದಿಂದ ACK ಗಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ಡೇಟಾ ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದನ್ನು (ಮತ್ತು ತಳ್ಳುವುದು) ವಿಳಂಬಗೊಳಿಸಲು ಅಲ್ಗಾರಿದಮ್ ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ. ಸಂಚಿತ ಡೇಟಾವನ್ನು ಹಿಂದೆ ಕಳುಹಿಸಿದ ಮಾಹಿತಿಗಾಗಿ ACK ಸ್ವೀಕರಿಸಿದ ನಂತರ ಅಥವಾ ಪೂರ್ಣ ವಿಭಾಗದ ಮೊತ್ತದಲ್ಲಿ ಕಳುಹಿಸಲು ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ನಂತರ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಬೇಕಾದ ನೈಜ-ಸಮಯದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಈ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಬಾರದು.

ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತೊಂದು ಕಾರ್ಯವಿಧಾನವು ACK ವಿಳಂಬ ವಿಧಾನವಾಗಿದೆ. ACK ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುವುದರಿಂದ ಇತರ ಟ್ರಾಫಿಕ್ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಬಳಸಬಹುದಾದ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. TCP ಪೀರ್ ACK ಕಳುಹಿಸಲು ಸ್ವಲ್ಪ ವಿಳಂಬ ಮಾಡಿದರೆ, ನಂತರ:

■ ಒಂದೇ ACK ಯೊಂದಿಗೆ ಬಹು ವಿಭಾಗಗಳನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಬಹುದು.

■ ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಸಮಯ ಮೀರುವ ಮಧ್ಯಂತರದಲ್ಲಿ ಕೆಲವು ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಅಂದರೆ. ACK ಔಟ್‌ಪುಟ್ ಹೆಡರ್ ಅನ್ನು ಹೊಂದಿರಬಹುದು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಸಂದೇಶವನ್ನು ರಚಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ಪೂರ್ಣ-ಉದ್ದದ ಭಾಗಗಳ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕಳುಹಿಸುವಾಗ ವಿಳಂಬವನ್ನು ತಪ್ಪಿಸಲು (ಉದಾಹರಣೆಗೆ, ಫೈಲ್‌ಗಳನ್ನು ವಿನಿಮಯ ಮಾಡುವಾಗ), ಕನಿಷ್ಠ ಪ್ರತಿ ಇತರ ಪೂರ್ಣ ವಿಭಾಗಕ್ಕೆ ACK ಅನ್ನು ಕಳುಹಿಸಬೇಕು.

ಅನೇಕ ಅಳವಡಿಕೆಗಳು 200ms ಕಾಲಾವಧಿಯನ್ನು ಬಳಸುತ್ತವೆ. ಆದರೆ ವಿಳಂಬವಾದ ACK ವಿನಿಮಯ ದರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದಿಲ್ಲ. ಒಂದು ಸಣ್ಣ ವಿಭಾಗ ಬಂದಾಗ, ಹೊಸ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಲು ಇನ್‌ಪುಟ್ ಬಫರ್‌ನಲ್ಲಿ ಇನ್ನೂ ಸಾಕಷ್ಟು ಮುಕ್ತ ಸ್ಥಳವಿರುತ್ತದೆ ಮತ್ತು ಕಳುಹಿಸುವವರು ಫಾರ್ವರ್ಡ್ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು (ಜೊತೆಗೆ, ಮರು ಕಳುಹಿಸುವಿಕೆಯು ಸಾಮಾನ್ಯವಾಗಿ ನಿಧಾನವಾಗಿರುತ್ತದೆ). ಇಡೀ ವಿಭಾಗವು ಬಂದರೆ, ನೀವು ಅದೇ ಸೆಕೆಂಡಿನಲ್ಲಿ ACK ಸಂದೇಶದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕಾಗುತ್ತದೆ.

ವಿಭಾಗವನ್ನು ಕಳುಹಿಸಿದ ನಂತರ, TCP ಟೈಮರ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ACK ಆಗಮನವನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ. ಸಮಯ ಮೀರುವ ಅವಧಿಯೊಳಗೆ ACK ಸ್ವೀಕರಿಸದಿದ್ದರೆ, TCP ವಿಭಾಗವನ್ನು (ರಿಲೇ) ಮರುಪ್ರಸಾರಿಸುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಸಮಯ ಮೀರುವ ಅವಧಿ ಏನಾಗಿರಬೇಕು?

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

ಸರಿಯಾದ ಸಮಯ ಮೀರುವ ಅವಧಿಯನ್ನು ಹೇಗೆ ಆರಿಸುವುದು? ಹೆಚ್ಚಿನ ವೇಗಕ್ಕೆ ಸೂಕ್ತವಾದ ಮೌಲ್ಯ ಸ್ಥಳೀಯ ನೆಟ್ವರ್ಕ್, ಅನೇಕ ಹಿಟ್‌ಗಳೊಂದಿಗೆ ರಿಮೋಟ್ ಸಂಪರ್ಕಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲ. ಇದರರ್ಥ "ಯಾವುದೇ ಷರತ್ತುಗಳಿಗೆ ಒಂದು ಮೌಲ್ಯ" ಎಂಬ ತತ್ವವು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಕ್ತವಲ್ಲ. ಇದಲ್ಲದೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿರ್ದಿಷ್ಟ ಸಂಪರ್ಕಕ್ಕೆ ಸಹ, ನೆಟ್ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಬದಲಾಗಬಹುದು ಮತ್ತು ವಿಳಂಬಗಳು ಹೆಚ್ಚಾಗಬಹುದು ಅಥವಾ ಕಡಿಮೆಯಾಗಬಹುದು.

ಜಾಕೋಬ್ಸನ್, ಕೆರ್ನ್ ಮತ್ತು ಪಾರ್ಟ್ರಿಡ್ಜ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳು (ಲೇಖನಗಳಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ , ವ್ಯಾನ್ ಜಾಕೋಬ್ಸನ್, ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯದ ಅಂದಾಜುಗಳನ್ನು ಸುಧಾರಿಸುವುದು, ಕಾರ್ನ್ ಮತ್ತು ಪಾರ್ಟ್ರಿಡ್ಜ್) ಬದಲಾಗುತ್ತಿರುವ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳಲು TCP ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಈ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಹೊಸ ಅಳವಡಿಕೆಗಳಲ್ಲಿ ಬಳಸಲು ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ. ನಾವು ಅವುಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಕೆಳಗೆ ನೋಡುತ್ತೇವೆ.

ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂಪರ್ಕಕ್ಕೆ ಸರಿಯಾದ ಸಮಯ ಮೀರುವ ಸಮಯವನ್ನು ಅಂದಾಜು ಮಾಡಲು ಉತ್ತಮ ಆಧಾರವೆಂದರೆ ಮೇಲ್ವಿಚಾರಣೆ ಎಂದು ಸಾಮಾನ್ಯ ಜ್ಞಾನವು ನಿರ್ದೇಶಿಸುತ್ತದೆ. ಸೈಕಲ್ ಸಮಯ(ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯ) ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಅದರ ರಶೀದಿಯ ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸುವ ನಡುವಿನ ಮಧ್ಯಂತರವಾಗಿ.

ಈ ಕೆಳಗಿನ ಪ್ರಮಾಣಗಳಿಗೆ ಉತ್ತಮ ಪರಿಹಾರಗಳನ್ನು ಮೂಲ ಅಂಕಿಅಂಶಗಳಿಂದ ಪಡೆಯಬಹುದು (ಚಿತ್ರ 10.19 ನೋಡಿ) ಸಮಯ ಮೀರುವ ಸಮಯವನ್ನು ಲೆಕ್ಕಹಾಕಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದಾಗ್ಯೂ, ನೀವು ಸರಾಸರಿಗಳನ್ನು ಅವಲಂಬಿಸಬಾರದು, ಏಕೆಂದರೆ ಅಂದಾಜುಗಳ ಅರ್ಧಕ್ಕಿಂತ ಹೆಚ್ಚು ಅಂಕಿಅಂಶಗಳ ಸರಾಸರಿಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಒಂದೆರಡು ಔಟ್‌ಲೈಯರ್‌ಗಳನ್ನು ಪರಿಗಣಿಸುವ ಮೂಲಕ, ಸಾಮಾನ್ಯ ವಿತರಣೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಉತ್ತಮ ಅಂದಾಜುಗಳನ್ನು ನಾವು ಪಡೆಯಬಹುದು ಮತ್ತು ಅತಿಯಾದ ದೀರ್ಘ ಮರುಪ್ರಸಾರ ಕಾಯುವ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

ಅಕ್ಕಿ. 10.19ಸೈಕಲ್ ಸಮಯಗಳ ವಿತರಣೆ

ವಿಚಲನಗಳ ಔಪಚಾರಿಕ ಗಣಿತದ ಅಂದಾಜುಗಳನ್ನು ಪಡೆಯಲು ದೊಡ್ಡ ಪ್ರಮಾಣದ ಲೆಕ್ಕಾಚಾರಗಳ ಅಗತ್ಯವಿಲ್ಲ. ಕೊನೆಯ ಮೌಲ್ಯ ಮತ್ತು ಸರಾಸರಿ ಅಂದಾಜಿನ ನಡುವಿನ ವ್ಯತ್ಯಾಸದ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವನ್ನು ಆಧರಿಸಿ ನೀವು ಸಾಕಷ್ಟು ಒರಟು ಅಂದಾಜುಗಳನ್ನು ಬಳಸಬಹುದು:

ಕೊನೆಯ ವಿಚಲನ = | ಕೊನೆಯ ಚಕ್ರ - ಸರಾಸರಿ |

ಸರಿಯಾದ ಸಮಯ ಮೀರುವ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, ಪ್ರಸ್ತುತ ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಿಂದಾಗಿ ಸೈಕಲ್ ಸಮಯದ ಬದಲಾವಣೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಮತ್ತೊಂದು ಅಂಶವಾಗಿದೆ. ಒಂದು ಗಂಟೆಯ ಹಿಂದೆ ಏನಾಯಿತು ಎನ್ನುವುದಕ್ಕಿಂತ ಕೊನೆಯ ಕ್ಷಣದಲ್ಲಿ ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದು ಮುಖ್ಯ.

ನಾವು ದೀರ್ಘಾವಧಿಯ ಅವಧಿಗೆ ಚಕ್ರದ ಸರಾಸರಿಯನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತಿದ್ದೇವೆ ಎಂದು ಭಾವಿಸೋಣ. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮೊದಲಿಗೆ ಲಘುವಾಗಿ ಲೋಡ್ ಮಾಡೋಣ, ಮತ್ತು ನಾವು 1000 ಸಣ್ಣ ಮೌಲ್ಯಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ, ಆದರೆ ನಂತರ ಸುಪ್ತತೆಯಲ್ಲಿ ಗಮನಾರ್ಹ ಹೆಚ್ಚಳದೊಂದಿಗೆ ದಟ್ಟಣೆಯಲ್ಲಿ ಹೆಚ್ಚಳ ಕಂಡುಬಂದಿದೆ.

ಉದಾಹರಣೆಗೆ, 1000 ಮೌಲ್ಯಗಳು 170 ಯೂನಿಟ್‌ಗಳ ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯ ಸರಾಸರಿಯನ್ನು ನೀಡಿದರೆ, ಆದರೆ ನಂತರ 50 ಮೌಲ್ಯಗಳನ್ನು ಸರಾಸರಿ 282 ನೊಂದಿಗೆ ಅಳೆಯಲಾಗುತ್ತದೆ, ಆಗ ಪ್ರಸ್ತುತ ಸರಾಸರಿ ಹೀಗಿರುತ್ತದೆ:

170×1000/1050 + 282×50/1050 = 175

ಹೆಚ್ಚು ಸಮಂಜಸವಾದ ಮೌಲ್ಯವು ಇರುತ್ತದೆ ಸುಗಮ ಸೈಕಲ್ ಸಮಯ(ಸ್ಮೂತ್ಡ್ ರೌಂಡ್-ಟ್ರಿಪ್ ಸಮಯ - SRTT), ಇದು ನಂತರದ ಮೌಲ್ಯಗಳ ಆದ್ಯತೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

ಹೊಸ SRTT = (1 – α)×(ಹಳೆಯ SRTT) + α×ಕೊನೆಯ ಸೈಕಲ್ ಮೌಲ್ಯ

α ನ ಮೌಲ್ಯವು 0 ಮತ್ತು 1 ರ ನಡುವೆ ಇರುತ್ತದೆ. ಹೆಚ್ಚಿಸಿ aನಯವಾದ ಸರಾಸರಿಯಲ್ಲಿ ಪ್ರಸ್ತುತ ಚಕ್ರದ ಸಮಯದ ಹೆಚ್ಚಿನ ಪ್ರಭಾವವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಕಂಪ್ಯೂಟರ್‌ಗಳು ಬೈನರಿ ಸಂಖ್ಯೆಗಳನ್ನು ಬಲಕ್ಕೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ 2 ರ ಶಕ್ತಿಗಳಿಂದ ತ್ವರಿತವಾಗಿ ವಿಭಜನೆಯನ್ನು ಮಾಡಬಹುದಾದ್ದರಿಂದ, α ಅನ್ನು ಯಾವಾಗಲೂ (1/2)n (ಸಾಮಾನ್ಯವಾಗಿ 1/8) ಎಂದು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ:

ಹೊಸ SRTT = 7/8× ಹಳೆಯ SRTT + 1/8× ಕೊನೆಯ ಸೈಕಲ್ ಸಮಯ

ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿನ ಬದಲಾವಣೆಯು ಚಕ್ರದ ಸಮಯವನ್ನು ಹಂತಹಂತವಾಗಿ ಹೆಚ್ಚಿಸಲು ಕಾರಣವಾದಾಗ SRTT ಯ ಸೂತ್ರವು ಪ್ರಸ್ತುತ 230 ಯೂನಿಟ್‌ಗಳ SRTT ಮೌಲ್ಯಕ್ಕೆ ಹೇಗೆ ಸರಿಹೊಂದಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕೋಷ್ಟಕ 10.2 ತೋರಿಸುತ್ತದೆ (ಯಾವುದೇ ಕಾಲಾವಧಿಯು ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂದು ಊಹಿಸಿ). ಕಾಲಮ್ 3 ರಲ್ಲಿನ ಮೌಲ್ಯಗಳನ್ನು ಕೋಷ್ಟಕದ ಮುಂದಿನ ಸಾಲಿಗೆ ಕಾಲಮ್ 1 ರಲ್ಲಿನ ಮೌಲ್ಯಗಳಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ (ಅಂದರೆ, ಹಳೆಯ SRTT ನಂತೆ).

ಕೋಷ್ಟಕ 10.2 ಸುಗಮ ಚಕ್ರದ ಸಮಯದ ಲೆಕ್ಕಾಚಾರ

ಈಗ ಮರುಪ್ರಸಾರ ಕಾಲಾವಧಿಗೆ ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಶ್ನೆ ಬರುತ್ತದೆ. ಸೈಕಲ್ ಸಮಯದ ಮೌಲ್ಯಗಳ ವಿಶ್ಲೇಷಣೆಯು ಪ್ರಸ್ತುತ ಸರಾಸರಿ ಮೌಲ್ಯದಿಂದ ಈ ಮೌಲ್ಯಗಳ ಗಮನಾರ್ಹ ವಿಚಲನವನ್ನು ತೋರಿಸುತ್ತದೆ. ವಿಚಲನಗಳ ಪ್ರಮಾಣಕ್ಕೆ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ. ಮರುಪ್ರಸಾರ ಸಮಯ ಮೀರುವಿಕೆಗೆ ಉತ್ತಮ ಮೌಲ್ಯವನ್ನು (RFC ಮಾನದಂಡಗಳಲ್ಲಿ ಈ ಮೌಲ್ಯವನ್ನು ಮರುಪ್ರಸಾರ ಟೈಮ್‌ಔಟ್ - RTO ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ) ಸುಗಮವಾದ ವಿಚಲನ (SDEV) ನಿರ್ಬಂಧದೊಂದಿಗೆ ಕೆಳಗಿನ ಸೂತ್ರದಿಂದ ನೀಡಲಾಗಿದೆ:

T = ಮರುಪ್ರಸಾರ ಸಮಯ ಮೀರಿದೆ = SRTT + 2×SDEV

T = SRTT + 4×SDEV

SDEV ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು, ಮೊದಲು ಪ್ರಸ್ತುತ ವಿಚಲನದ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವನ್ನು ನಿರ್ಧರಿಸಿ:

DEV = | ಕೊನೆಯ ಸೈಕಲ್ ಸಮಯ - ಹಳೆಯ SRTT |

ನಂತರದ ಮೌಲ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಲು ಮೃದುಗೊಳಿಸುವ ಸೂತ್ರವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ:

ಹೊಸ SDEV = 3/4×ಹಳೆಯ SDEV + 1/4×DEV

ಒಂದು ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ - ಯಾವ ಆರಂಭಿಕ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು? ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ:

ಆರಂಭಿಕ ಅವಧಿ = 3ಸೆ

ಆರಂಭಿಕ SRTT = 0

ಆರಂಭಿಕ SDEV = 1.5 ಸೆ

ವ್ಯಾನ್ ಜಾಕೋಬ್ಸನ್ ವೇಗದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿದ್ದಾರೆ, ಅದು ಡೇಟಾ ಮರುಪ್ರಸಾರ ಅವಧಿಯನ್ನು ಬಹಳ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.

ಮೇಲೆ ಲೆಕ್ಕ ಹಾಕಿದ ಕಾಲಾವಧಿ ಎಷ್ಟು ಯಶಸ್ವಿಯಾಗುತ್ತದೆ? ಈ ಮೌಲ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿದಾಗ, ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಗಳನ್ನು ಗಮನಿಸಲಾಗಿದೆ. ಒಂದು ಉದಾಹರಣೆಯೆಂದರೆ ತಂಡದ ಅಂಕಿಅಂಶಗಳು netstat, ಸಿಸ್ಟಂನಲ್ಲಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ ಹುಲಿ- ಪ್ರಪಂಚದಾದ್ಯಂತದ ಅನೇಕ ಹೋಸ್ಟ್‌ಗಳಿಂದ ಪ್ರವೇಶಿಸಲಾದ ಇಂಟರ್ನೆಟ್ ಸರ್ವರ್.

1510769 ಪ್ಯಾಕೆಟ್‌ಗಳು (314955304 ಬೈಟ್‌ಗಳು) ಅನುಕ್ರಮವಾಗಿ ಸ್ವೀಕರಿಸಲಾಗಿದೆ

ವ್ಯವಸ್ಥೆ ಹುಲಿ TCP ಡೇಟಾ ವಿಭಾಗಗಳಲ್ಲಿ 2.5% ಕ್ಕಿಂತ ಕಡಿಮೆ ಮರುಪ್ರಸಾರ ಮಾಡಲಾಗಿದೆ. ಒಂದೂವರೆ ಮಿಲಿಯನ್ ಒಳಬರುವ ಡೇಟಾ ವಿಭಾಗಗಳಿಗೆ (ಉಳಿದವು ಶುದ್ಧ ACK ಸಂದೇಶಗಳು), ಕೇವಲ 0.6% ನಕಲು ಮಾಡಲಾಗಿದೆ. ಇನ್ಪುಟ್ ಡೇಟಾದಲ್ಲಿನ ನಷ್ಟಗಳ ಮಟ್ಟವು ಔಟ್ಪುಟ್ ವಿಭಾಗಗಳಿಗೆ ಸರಿಸುಮಾರು ಮಟ್ಟಕ್ಕೆ ಅನುಗುಣವಾಗಿರುತ್ತದೆ ಎಂದು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು. ಹೀಗಾಗಿ, ವ್ಯರ್ಥ ಮರುಪ್ರಸಾರ ಸಂಚಾರವು ಒಟ್ಟು ದಟ್ಟಣೆಯ ಸುಮಾರು 0.6% ರಷ್ಟಿದೆ.

ಮೇಲೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾದ ಸೂತ್ರಗಳು ಒಂದು ವಿಭಾಗವನ್ನು ಕಳುಹಿಸುವ ಮತ್ತು ಅದರ ರಶೀದಿಯ ಸ್ವೀಕೃತಿಯನ್ನು ಪಡೆಯುವ ನಡುವಿನ ಮಧ್ಯಂತರವಾಗಿ ಸೈಕಲ್ ಸಮಯವನ್ನು ಬಳಸುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಸಮಯ ಮೀರುವ ಅವಧಿಯೊಳಗೆ ಯಾವುದೇ ಸ್ವೀಕೃತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿಲ್ಲ ಮತ್ತು ಡೇಟಾವನ್ನು ಮರು ಕಳುಹಿಸಬೇಕು ಎಂದು ಭಾವಿಸೋಣ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಸೈಕಲ್ ಸಮಯವನ್ನು ಬದಲಾಯಿಸಬಾರದು ಎಂದು ಕೆರ್ನ್ ಅಲ್ಗಾರಿದಮ್ ಊಹಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ ಸುಗಮಗೊಳಿಸಿದ ಸೈಕಲ್ ಸಮಯದ ಮೌಲ್ಯ ಮತ್ತು ಸುಗಮ ವಿಚಲನನಿರ್ದಿಷ್ಟ ವಿಭಾಗವನ್ನು ಮರುಕಳುಹಿಸದೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸುವವರೆಗೆ ಅವುಗಳ ಮೌಲ್ಯಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ. ಈ ಹಂತದಿಂದ, ಉಳಿಸಿದ ಮೌಲ್ಯಗಳು ಮತ್ತು ಹೊಸ ಅಳತೆಗಳ ಆಧಾರದ ಮೇಲೆ ಲೆಕ್ಕಾಚಾರಗಳನ್ನು ಪುನರಾರಂಭಿಸಲಾಗುತ್ತದೆ.

ಆದರೆ ದೃಢೀಕರಣವನ್ನು ಸ್ವೀಕರಿಸುವ ಮೊದಲು ಏನಾಗುತ್ತದೆ? ಮರುಪ್ರಸಾರದ ನಂತರ, TCP ನಡವಳಿಕೆಯು ಆಮೂಲಾಗ್ರವಾಗಿ ಬದಲಾಗುತ್ತದೆ, ಮುಖ್ಯವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ದಟ್ಟಣೆಯಿಂದಾಗಿ ಡೇಟಾ ನಷ್ಟದಿಂದಾಗಿ. ಆದ್ದರಿಂದ, ಡೇಟಾವನ್ನು ಮರುಕಳಿಸುವ ಪ್ರತಿಕ್ರಿಯೆ ಹೀಗಿರುತ್ತದೆ:

■ ಕಡಿಮೆಯಾದ ಮರುಪ್ರಸಾರ ದರ

■ ಒಟ್ಟಾರೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವ ಮೂಲಕ ನೆಟ್‌ವರ್ಕ್ ದಟ್ಟಣೆಯನ್ನು ಎದುರಿಸಿ

ಮರುಪ್ರಸಾರದ ನಂತರ, ಸಮಯ ಮೀರುವ ಮಧ್ಯಂತರವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಟೈಮರ್ ಮತ್ತೆ ಉಕ್ಕಿ ಹರಿದರೆ ಏನಾಗುತ್ತದೆ? ಡೇಟಾವನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಮರುಪ್ರಸಾರ ಅವಧಿಯು ಮತ್ತೆ ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ. ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಘಾತೀಯ ಬ್ರೇಕಿಂಗ್(ಘಾತೀಯ ಬ್ಯಾಕ್ಆಫ್).

ನೆಟ್‌ವರ್ಕ್ ದೋಷವು ಸಂಭವಿಸುವುದನ್ನು ಮುಂದುವರಿಸಿದರೆ, ಮೊದಲೇ ಹೊಂದಿಸಲಾದ ಗರಿಷ್ಠ ಮೌಲ್ಯವನ್ನು ತಲುಪುವವರೆಗೆ (ಸಾಮಾನ್ಯವಾಗಿ 1 ನಿಮಿಷ) ಸಮಯ ಮೀರುವ ಅವಧಿಯು ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ. ಅವಧಿ ಮುಗಿದ ನಂತರ, ಒಂದು ವಿಭಾಗವನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಬಹುದು. ACK ಸ್ವೀಕರಿಸದೆಯೇ ಡೇಟಾ ವರ್ಗಾವಣೆಗಳ ಸಂಖ್ಯೆಗೆ ಪೂರ್ವನಿಗದಿ ಮೌಲ್ಯವನ್ನು ಮೀರಿದಾಗ ಸಮಯ ಮೀರುವಿಕೆ ಸಂಭವಿಸುತ್ತದೆ.

ಕಳುಹಿಸಲಾದ ಡೇಟಾದ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಮೇಲೆ ಚರ್ಚಿಸಿದ ಕಾರ್ಯವಿಧಾನಗಳಿಗಿಂತ ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಈಗಾಗಲೇ ಹೇಳಿದ ನಿಧಾನ ಆರಂಭದಂತೆಯೇ ಇದು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಆದರೆ, ಆರಂಭದಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುವ ದಟ್ಟಣೆಯ ಮಟ್ಟದಲ್ಲಿ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಲಾಗಿರುವುದರಿಂದ, ಒಂದು ವಿಭಾಗಕ್ಕೆ ಲೋಡ್ ವಿಂಡೋದ ಗಾತ್ರದಲ್ಲಿನ ಹೆಚ್ಚಳದಿಂದಾಗಿ ವಿನಿಮಯ ವೇಗವು ವಾಸ್ತವವಾಗಿ ನಿಧಾನಗೊಳ್ಳುತ್ತದೆ. ಕಳುಹಿಸುವ ವೇಗವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನೀವು ಗಡಿ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಅಪಾಯದ ಮಿತಿಯನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ:

ಗಡಿ - 1/2 ಕನಿಷ್ಠ (ಪ್ರಸ್ತುತ ಲೋಡ್ ವಿಂಡೋ, ಪಾಲುದಾರ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ)

ಫಲಿತಾಂಶದ ಮೌಲ್ಯವು ಎರಡು ವಿಭಾಗಗಳಿಗಿಂತ ಹೆಚ್ಚಿದ್ದರೆ, ಅದನ್ನು ಗಡಿಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ಇಲ್ಲದಿದ್ದರೆ, ಗಡಿ ಗಾತ್ರವನ್ನು ಎರಡು ಭಾಗಗಳಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಸಂಪೂರ್ಣ ಮರುಪಡೆಯುವಿಕೆ ಅಲ್ಗಾರಿದಮ್ ಅಗತ್ಯವಿದೆ:

■ ಲೋಡ್ ವಿಂಡೋ ಗಾತ್ರವನ್ನು ಒಂದು ವಿಭಾಗಕ್ಕೆ ಹೊಂದಿಸಿ.

■ ಸ್ವೀಕರಿಸಿದ ಪ್ರತಿ ACK ಗೆ, ಗಡಿಯನ್ನು ತಲುಪುವವರೆಗೆ ಲೋಡ್ ವಿಂಡೋ ಗಾತ್ರವನ್ನು ಒಂದು ಭಾಗದಿಂದ ಹೆಚ್ಚಿಸಿ (ಸ್ಲೋ ಸ್ಟಾರ್ಟ್ ಮೆಕ್ಯಾನಿಸಂನಂತೆಯೇ).

■ ನಂತರ, ಪ್ರತಿ ACK ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಲೋಡ್ ವಿಂಡೋಗೆ ಸಣ್ಣ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸಿ, ಸೈಕಲ್ ಸಮಯಕ್ಕೆ ಪ್ರತಿ ವಿಭಾಗದ ಹೆಚ್ಚಳದ ದರವನ್ನು ಆಧರಿಸಿ ಆಯ್ಕೆಮಾಡಲಾಗುತ್ತದೆ (ಹೆಚ್ಚಳವನ್ನು MSS/N ಎಂದು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ, ಇಲ್ಲಿ N ಲೋಡ್ ವಿಂಡೋದ ಗಾತ್ರವಾಗಿದೆ ವಿಭಾಗಗಳಲ್ಲಿ).

ಆದರ್ಶ ಸನ್ನಿವೇಶವು ಚೇತರಿಕೆಯ ಕಾರ್ಯವಿಧಾನವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಸರಳೀಕೃತ ಪ್ರಾತಿನಿಧ್ಯವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಪಾಲುದಾರನ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ (ಮತ್ತು ಪ್ರಸ್ತುತ ಲೋಡ್ ವಿಂಡೋ) ಸಮಯಾವಧಿಯನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮೊದಲು 8 ವಿಭಾಗಗಳ ಗಾತ್ರವನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ಗಡಿಯನ್ನು 4 ವಿಭಾಗಗಳಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ ಎಂದು ಭಾವಿಸೋಣ. ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಬಫರ್‌ನಿಂದ ಡೇಟಾವನ್ನು ತಕ್ಷಣವೇ ಓದಿದರೆ, ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಗಾತ್ರವು 8 ವಿಭಾಗಗಳಾಗಿ ಉಳಿಯುತ್ತದೆ.

■ 1 ವಿಭಾಗವನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ (ಲೋಡ್ ವಿಂಡೋ = 1 ವಿಭಾಗ).

■ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ - 2 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ.

■ 2 ವಿಭಾಗಗಳಿಗೆ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ - 4 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ (ಬೌಂಡರಿ ತಲುಪಿದೆ).

■ 4 ವಿಭಾಗಗಳಿಗೆ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ. 5 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ.

■ 5 ವಿಭಾಗಗಳಿಗೆ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ. 6 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ.

■ 6 ವಿಭಾಗಗಳಿಗೆ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ. 7 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ.

■ 7 ವಿಭಾಗಗಳಿಗೆ ACK ಸ್ವೀಕರಿಸಲಾಗಿದೆ. 8 ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ (ಲೋಡಿಂಗ್ ವಿಂಡೋ ಮತ್ತೆ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋಗೆ ಗಾತ್ರದಲ್ಲಿ ಸಮಾನವಾಗಿರುತ್ತದೆ).

ಸಮಯ ಮೀರಿದ ಮರುಪ್ರಸಾರಕ್ಕೆ ಎಲ್ಲಾ ಕಳುಹಿಸಿದ ಡೇಟಾದ ಸ್ವೀಕೃತಿಯ ದೃಢೀಕರಣದ ಅಗತ್ಯವಿರುವುದರಿಂದ, ಲೋಡ್ ವಿಂಡೋ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಗಾತ್ರವನ್ನು ತಲುಪುವವರೆಗೆ ಪ್ರಕ್ರಿಯೆಯು ಮುಂದುವರಿಯುತ್ತದೆ. ನಡೆಯುವ ಘಟನೆಗಳನ್ನು ಅಂಜೂರದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ. 10.20. ವಿಂಡೋ ಗಾತ್ರವು ಘಾತೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ, ನಿಧಾನ ಪ್ರಾರಂಭದ ಅವಧಿಯಲ್ಲಿ ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಗಡಿಯನ್ನು ತಲುಪಿದ ನಂತರ ರೇಖೀಯವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 10.20.ದಟ್ಟಣೆಯ ಸಮಯದಲ್ಲಿ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ವೇಗವನ್ನು ಮಿತಿಗೊಳಿಸುವುದು

ಕೆಲವು ಅನುಷ್ಠಾನಗಳು ಎಂಬ ಐಚ್ಛಿಕ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸುತ್ತವೆ ವೇಗವಾಗಿ ಮರುಕಳುಹಿಸಿ(ವೇಗದ ಮರುಪ್ರಸಾರ) - ಕೆಲವು ಷರತ್ತುಗಳ ಅಡಿಯಲ್ಲಿ ಡೇಟಾವನ್ನು ಮರು-ಕಳುಹಿಸುವಿಕೆಯನ್ನು ವೇಗಗೊಳಿಸಲು. ಸ್ವೀಕರಿಸಿದ ಡೇಟಾದಲ್ಲಿನ ಅಂತರವನ್ನು ಸೂಚಿಸುವ ಹೆಚ್ಚುವರಿ ACK ಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಸ್ವೀಕರಿಸುವವರು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಆದೇಶದ ಹೊರಗಿರುವ ವಿಭಾಗವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ರಿಸೀವರ್ ಮೊದಲ ಬೈಟ್‌ಗೆ ಸೂಚಿಸುವ ACK ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಸೋತರುಡೇಟಾ (ಚಿತ್ರ 10.21 ನೋಡಿ).

ಅಕ್ಕಿ. 10.21.ನಕಲಿ ಎಸಿಕೆಗಳು

ಕಳುಹಿಸುವವರು ತಕ್ಷಣವೇ ಡೇಟಾವನ್ನು ಮರುಪ್ರಸಾರ ಮಾಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ IP ಸಾಮಾನ್ಯವಾಗಿ ಕಳುಹಿಸುವ ಅನುಕ್ರಮವಿಲ್ಲದೆ ಸ್ವೀಕರಿಸುವವರಿಗೆ ಡೇಟಾವನ್ನು ತಲುಪಿಸುತ್ತದೆ. ಆದರೆ ಹಲವಾರು ಹೆಚ್ಚುವರಿ ನಕಲು ಡೇಟಾ ACK ಗಳನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ (ಉದಾಹರಣೆಗೆ, ಮೂರು), ಸಮಯ ಮೀರುವವರೆಗೆ ಕಾಯದೆ ಕಾಣೆಯಾದ ವಿಭಾಗವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಪ್ರತಿ ನಕಲಿ ACK ಡೇಟಾ ವಿಭಾಗದ ಸ್ವೀಕೃತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಹಲವಾರು ನಕಲಿ ಎಸಿಕೆಗಳು ನೆಟ್‌ವರ್ಕ್ ಸಾಕಷ್ಟು ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ತಲುಪಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಆದ್ದರಿಂದ ಹೆಚ್ಚು ಲೋಡ್ ಆಗುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಒಟ್ಟಾರೆ ಅಲ್ಗಾರಿದಮ್ನ ಭಾಗವಾಗಿ, ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ನಲ್ಲಿ ನಿಜವಾದ ಹೆಚ್ಚಳವಾದಾಗ ಲೋಡ್ ವಿಂಡೋದ ಗಾತ್ರದಲ್ಲಿ ಸಣ್ಣ ಕಡಿತವನ್ನು ನಡೆಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲಸವನ್ನು ಮರುಸ್ಥಾಪಿಸುವಾಗ ಆಮೂಲಾಗ್ರ ಮರುಗಾತ್ರಗೊಳಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಅನ್ವಯಿಸಲಾಗುವುದಿಲ್ಲ.

ಮಾನದಂಡದ ಪ್ರಕಾರ ಹೋಸ್ಟ್ ಅಗತ್ಯತೆಗಳು(ಹೋಸ್ಟ್ ಅವಶ್ಯಕತೆಗಳು) TCP ಮೂಲವನ್ನು ತಣಿಸುವಾಗ ಮೇಲೆ ವಿವರಿಸಿದಂತೆ ಅದೇ ನಿಧಾನಗತಿಯ ಪ್ರಾರಂಭವನ್ನು ನಿರ್ವಹಿಸಬೇಕು. ಆದಾಗ್ಯೂ, ಈ ಸಂದೇಶವು ಗುರಿಯಾಗಿರುವುದಿಲ್ಲ ಅಥವಾ ಪರಿಣಾಮಕಾರಿಯಾಗಿರುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುವ ಸಂಪರ್ಕವು ಹೆಚ್ಚು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಉತ್ಪಾದಿಸದಿರಬಹುದು. ಪ್ರಸ್ತುತ ನಿರ್ದಿಷ್ಟತೆ ರೂಟರ್ ಅಗತ್ಯತೆಗಳು(ರೂಟರ್ ಅವಶ್ಯಕತೆಗಳು) ಮಾರ್ಗನಿರ್ದೇಶಕಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ ಮಾಡಬಾರದುಮೂಲ ನಿಗ್ರಹದ ಬಗ್ಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಿ.

ಅಂತಿಮವಾಗಿ, ತಂಡದ ಅಂಕಿಅಂಶಗಳ ಸಂದೇಶಗಳನ್ನು ನೋಡೋಣ ನೆಟ್‌ಸ್ಟಾಟ್,ಕೆಲಸದಲ್ಲಿ ಮೇಲೆ ವಿವರಿಸಿದ ಅನೇಕ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನೋಡಲು.

879137 ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳು (226966295 ಬೈಟ್‌ಗಳು)

21815 ಡೇಟಾ ಪ್ಯಾಕೆಟ್‌ಗಳು (8100927 ಬೈಟ್‌ಗಳು) ಮರುಪ್ರಸಾರವಾಗಿದೆ

132957 ಅಕ್-ಓನ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು (104216 ವಿಳಂಬವಾಗಿದೆ)

ತಡವಾದ ACK.

ಶೂನ್ಯ ಗಾತ್ರ.

762469 acks (226904227 ಬೈಟ್‌ಗಳಿಗೆ)

ಅನುಕ್ರಮದಿಂದ ಹೊರಗಿದೆ.

1510769 ಪ್ಯಾಕೆಟ್‌ಗಳು (314955304 ಬೈಟ್‌ಗಳು)

9006 ಸಂಪೂರ್ಣವಾಗಿ ನಕಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು (867042 ಬೈಟ್‌ಗಳು)

ಡೇಟಾ ವಿತರಣೆ.

ಕೆಲವು ಡಪ್‌ನೊಂದಿಗೆ 74 ಪ್ಯಾಕೆಟ್‌ಗಳು. ಡೇಟಾ (12193 ಬೈಟ್‌ಗಳು ನಕಲಿ)

ಮರುಹೊಂದಿಸಿದಾಗ ಹೆಚ್ಚುವರಿ ಬೈಟ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಕೆಲವು ಡೇಟಾವನ್ನು ಮರುಪ್ಯಾಕೇಜ್ ಮಾಡಲಾಗಿದೆ.

13452 ಔಟ್-ಆಫ್-ಆರ್ಡರ್ ಪ್ಯಾಕೆಟ್‌ಗಳು (2515087 ಬೈಟ್‌ಗಳು)

ವಿಂಡೋದ ನಂತರ ಡೇಟಾದ 530 ಪ್ಯಾಕೆಟ್‌ಗಳು (8551 ಬೈಟ್‌ಗಳು).

ಧ್ವನಿ ಸಂದೇಶಗಳಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ.

ಮುಚ್ಚಿದ ನಂತರ 402 ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ

ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ.

ಕೆಟ್ಟ ಚೆಕ್‌ಸಮ್‌ಗಳಿಗಾಗಿ 108 ತಿರಸ್ಕರಿಸಲಾಗಿದೆ

ಕೆಟ್ಟ ಹೆಡರ್ ಆಫ್‌ಸೆಟ್ ಕ್ಷೇತ್ರಗಳಿಗಾಗಿ 0 ಅನ್ನು ತಿರಸ್ಕರಿಸಲಾಗಿದೆ

ಪ್ಯಾಕೆಟ್ ತುಂಬಾ ಚಿಕ್ಕದಾಗಿರುವ ಕಾರಣ 7 ತಿರಸ್ಕರಿಸಲಾಗಿದೆ

14677 ಸಂಪರ್ಕಗಳನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ (ಸ್ವೀಕರಿಸುವುದು ಸೇರಿದಂತೆ)

18929 ಸಂಪರ್ಕಗಳನ್ನು ಮುಚ್ಚಲಾಗಿದೆ (643 ಹನಿಗಳನ್ನು ಒಳಗೊಂಡಂತೆ)

4100 ಭ್ರೂಣದ ಸಂಪರ್ಕಗಳನ್ನು ಕೈಬಿಡಲಾಗಿದೆ

572187 ವಿಭಾಗಗಳನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ rtt (587397 ಪ್ರಯತ್ನಗಳಲ್ಲಿ)

ಸೈಕಲ್ ಸಮಯ, ಸಮಯ ಮೀರುವ ಮೊದಲು ACK ಆಗಮಿಸದ ಕಾರಣ,

26 ಸಂಪರ್ಕಗಳನ್ನು ಮರುಪಾವತಿ ಸಮಯ ಮೀರುವ ಮೂಲಕ ಕೈಬಿಡಲಾಗಿದೆ

ಮರುಕಳುಹಿಸಿ, ಕಳೆದುಹೋದ ಸಂಪರ್ಕವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

ಶೂನ್ಯ ವಿಂಡೋ.

ಮುರಿದ ಸಂಪರ್ಕ.

ಕೀಪಲೈವ್‌ನಿಂದ 472 ಸಂಪರ್ಕಗಳನ್ನು ಕೈಬಿಡಲಾಗಿದೆ

ಪ್ರಸ್ತುತ TCP ಮಾನದಂಡವು ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸುವಾಗ ನಿಧಾನಗತಿಯ ಪ್ರಾರಂಭದ ಕಾರ್ಯವಿಧಾನಕ್ಕೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಬದ್ಧವಾಗಿರಲು ಮತ್ತು ಡೇಟಾ ಮರುಹೊಂದಿಸುವ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಮತ್ತು ಲೋಡ್ ನಿಯಂತ್ರಣವನ್ನು ಅಂದಾಜು ಮಾಡಲು ಕೆರ್ನ್ ಮತ್ತು ಜಾಕೋಬ್ಸನ್ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಲು ಅಳವಡಿಕೆಗಳ ಅಗತ್ಯವಿದೆ. ಈ ಕಾರ್ಯವಿಧಾನಗಳು ಗಮನಾರ್ಹ ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಣೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತವೆ ಎಂದು ಪರೀಕ್ಷೆಗಳು ತೋರಿಸಿವೆ.

ಈ ಮಾನದಂಡಗಳಿಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅಂಟಿಕೊಳ್ಳದ ವ್ಯವಸ್ಥೆಯನ್ನು ನೀವು ಸ್ಥಾಪಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ? ಇದು ತನ್ನದೇ ಆದ ಬಳಕೆದಾರರಿಗೆ ಸಾಕಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿನ ಇತರ ಸಿಸ್ಟಮ್‌ಗಳಿಗೆ ಕಳಪೆ ನೆರೆಯಾಗಿರುತ್ತದೆ, ಇದು ತಾತ್ಕಾಲಿಕ ಓವರ್‌ಲೋಡ್‌ನಿಂದ ಚೇತರಿಸಿಕೊಳ್ಳುವುದನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಕೈಬಿಡಲು ಕಾರಣವಾಗುವ ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.

ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ನೂರಾರು ಅಥವಾ ಮಿಲಿಯನ್ ಬಿಟ್‌ಗಳ ವರ್ಗಾವಣೆ ದರಗಳೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಕ TCP ತನ್ನ ನಮ್ಯತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿದೆ. ಈ ಪ್ರೋಟೋಕಾಲ್ ಆಧುನಿಕ ಲೋಕಲ್ ಏರಿಯಾ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಎತರ್ನೆಟ್, ಟೋಕನ್-ರಿಂಗ್ ಮತ್ತು ಫೈಬರ್ ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಡೇಟಾ ಇಂಟರ್ಫೇಸ್ (ಎಫ್‌ಡಿಡಿಐ) ಟೋಪೋಲಾಜಿಗಳು, ಹಾಗೆಯೇ ಕಡಿಮೆ-ವೇಗದ ಸಂವಹನ ಲಿಂಕ್‌ಗಳು ಅಥವಾ ದೂರದ ಸಂಪರ್ಕಗಳಿಗೆ (ಉಪಗ್ರಹ ಲಿಂಕ್‌ಗಳಂತೆಯೇ) ಉತ್ತಮ ಫಲಿತಾಂಶಗಳನ್ನು ಸಾಧಿಸಿದೆ.

ನೆಟ್‌ವರ್ಕ್ ದಟ್ಟಣೆಯಂತಹ ವಿಪರೀತ ಪರಿಸ್ಥಿತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು TCP ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಪ್ರೋಟೋಕಾಲ್‌ನ ಪ್ರಸ್ತುತ ಆವೃತ್ತಿಯು ನೂರಾರು ಅಥವಾ ಸಾವಿರಾರು ಮೆಗಾಬೈಟ್‌ಗಳ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ನೀಡುವ ಭರವಸೆಯ ತಂತ್ರಜ್ಞಾನಗಳಲ್ಲಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ. ಒಳಗೊಂಡಿರುವ ಸಮಸ್ಯೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಸರಳವಾದ (ಅವಾಸ್ತವಿಕವಾದರೂ) ಉದಾಹರಣೆಯನ್ನು ಪರಿಗಣಿಸಿ.

ಎರಡು ಸಿಸ್ಟಮ್‌ಗಳ ನಡುವೆ ಫೈಲ್ ಅನ್ನು ಚಲಿಸುವಾಗ, ನೀವು ನಿರಂತರವಾದ ವಿನಿಮಯದ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತೀರಿ ಎಂದು ಭಾವಿಸೋಣ. ಅದನ್ನು ಊಹಿಸೋಣ:

■ ಗರಿಷ್ಠ ರಿಸೀವರ್ ವಿಭಾಗದ ಗಾತ್ರವು 1 KB ಆಗಿದೆ.

■ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ - 4 ಕೆಬಿ.

■ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ನಿಮಗೆ 1 ಸೆಗಳಲ್ಲಿ ಎರಡು ವಿಭಾಗಗಳನ್ನು ಕಳುಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

■ ಸ್ವೀಕರಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಅದು ಬಂದಂತೆ ಡೇಟಾವನ್ನು ಬಳಸುತ್ತದೆ.

■ ACK ಸಂದೇಶಗಳು 2 ಸೆಕೆಂಡುಗಳ ನಂತರ ಬರುತ್ತವೆ.

ಕಳುಹಿಸುವವರು ನಿರಂತರವಾಗಿ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲು ಸಮರ್ಥರಾಗಿದ್ದಾರೆ. ಎಲ್ಲಾ ನಂತರ, ವಿಂಡೋಗೆ ನಿಯೋಜಿಸಲಾದ ಪರಿಮಾಣವು ತುಂಬಿದಾಗ, ಒಂದು ACK ಆಗಮಿಸುತ್ತದೆ, ಇದು ಮತ್ತೊಂದು ವಿಭಾಗವನ್ನು ಕಳುಹಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ:

2 ಸೆಕೆಂಡುಗಳ ನಂತರ:

ವಿಭಾಗ 1 ರ AC ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ವಿಭಾಗ 5 ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ವಿಭಾಗ 2 ರ ಎಸಿಕೆ ಸ್ವೀಕರಿಸಿ, ವಿಭಾಗ 6 ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ವಿಭಾಗ 3 ರ AC ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ವಿಭಾಗ 7 ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ವಿಭಾಗ 4 ರ AC ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ವಿಭಾಗ 8 ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ಇನ್ನೊಂದು 2 ಸೆಕೆಂಡುಗಳ ನಂತರ:

ವಿಭಾಗ 5 ರ AC ಅನ್ನು ಸ್ವೀಕರಿಸಿ, ವಿಭಾಗ 9 ಅನ್ನು ಕಳುಹಿಸಬಹುದು.

ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಕೇವಲ 2 KB ಆಗಿದ್ದರೆ, ಕಳುಹಿಸುವವರು ಮುಂದಿನ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಪ್ರತಿ ಎರಡರಲ್ಲಿ ಒಂದು ಸೆಕೆಂಡ್ ಕಾಯುವಂತೆ ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. ವಾಸ್ತವವಾಗಿ, ಡೇಟಾದ ನಿರಂತರ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಹಿಡಿದಿಡಲು, ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಕನಿಷ್ಠವಾಗಿರಬೇಕು:

ವಿಂಡೋ = ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ × ಸೈಕಲ್ ಸಮಯ

ಉದಾಹರಣೆಯು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಉತ್ಪ್ರೇಕ್ಷಿತವಾಗಿದ್ದರೂ (ಸರಳ ಸಂಖ್ಯೆಗಳನ್ನು ಒದಗಿಸಲು), ಸಣ್ಣ ವಿಂಡೋವು ಹೆಚ್ಚಿನ ಲೇಟೆನ್ಸಿ ಉಪಗ್ರಹ ಸಂಪರ್ಕಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.

ಈಗ ಹೆಚ್ಚಿನ ವೇಗದ ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ. ಉದಾಹರಣೆಗೆ, ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ದರವನ್ನು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 10 ಮಿಲಿಯನ್ ಬಿಟ್‌ಗಳಲ್ಲಿ ಅಳೆಯಲಾಗುತ್ತದೆ, ಆದರೆ ಸೈಕಲ್ ಸಮಯವು 100 ms (ಸೆಕೆಂಡಿನ 1/10) ಆಗಿದ್ದರೆ, ನಿರಂತರ ಸ್ಟ್ರೀಮ್‌ಗಾಗಿ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಕನಿಷ್ಠ 1,000,000 ಬಿಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು, ಅಂದರೆ. . 125,000 ಬೈಟ್‌ಗಳು. ಆದರೆ TCP ಸ್ವೀಕರಿಸುವ ವಿಂಡೋಗಾಗಿ ಹೆಡರ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಬರೆಯಬಹುದಾದ ದೊಡ್ಡ ಸಂಖ್ಯೆ 65,536 ಆಗಿದೆ.

ಹೆಚ್ಚಿನ ಬಾಡ್ ದರಗಳಲ್ಲಿ ಮತ್ತೊಂದು ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ ಏಕೆಂದರೆ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳು ಬೇಗನೆ ಖಾಲಿಯಾಗುತ್ತವೆ. ಸಂಪರ್ಕವು 4 GB/s ವೇಗದಲ್ಲಿ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಬಹುದಾದರೆ, ನಂತರ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಗಳನ್ನು ಪ್ರತಿ ಸೆಕೆಂಡಿನಲ್ಲಿ ನವೀಕರಿಸಬೇಕು. ಹೊಸ ಹೊಸ ಡೇಟಾದಿಂದ ಇಂಟರ್ನೆಟ್‌ನಾದ್ಯಂತ ಚಲಿಸುವಾಗ ಒಂದು ಸೆಕೆಂಡ್‌ಗಿಂತ ಹೆಚ್ಚು ವಿಳಂಬವಾದ ಹಳೆಯ ನಕಲಿ ಡೇಟಾಗ್ರಾಮ್‌ಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಗುರುತಿಸಲು ಯಾವುದೇ ಮಾರ್ಗವಿರುವುದಿಲ್ಲ.

TCP/IP ಅನ್ನು ಸುಧಾರಿಸಲು ಮತ್ತು ಮೇಲೆ ತಿಳಿಸಲಾದ ಅಡೆತಡೆಗಳನ್ನು ನಿವಾರಿಸಲು ಹೊಸ ಸಂಶೋಧನೆಯನ್ನು ಸಕ್ರಿಯವಾಗಿ ನಡೆಸಲಾಗುತ್ತಿದೆ.

ಈ ಅಧ್ಯಾಯವು TCP ಯ ಹಲವು ಕಾರ್ಯಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಮುಖ್ಯವಾದವುಗಳನ್ನು ಕೆಳಗೆ ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ:

■ಸಂಪರ್ಕಗಳೊಂದಿಗೆ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು

■ ಮೂರು-ಹಂತದ ದೃಢೀಕರಣವನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ

■ ನೆಟ್‌ವರ್ಕ್ ಓವರ್‌ಲೋಡ್ ಅನ್ನು ತಪ್ಪಿಸಲು ನಿಧಾನವಾದ ಪ್ರಾರಂಭವನ್ನು ನಿರ್ವಹಿಸುವುದು

■ ಫಾರ್ವರ್ಡ್ ಮಾಡುವಾಗ ಡೇಟಾ ವಿಭಜನೆ

■ ಡೇಟಾ ಸಂಖ್ಯೆ

■ ಒಳಬರುವ ನಕಲಿ ವಿಭಾಗಗಳ ಪ್ರಕ್ರಿಯೆ

■ ಚೆಕ್ಸಮ್ಗಳ ಲೆಕ್ಕಾಚಾರ

■ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋ ಮತ್ತು ಕಳುಹಿಸುವ ವಿಂಡೋ ಮೂಲಕ ಡೇಟಾ ಹರಿವಿನ ನಿಯಂತ್ರಣ

■ ಸ್ಥಾಪಿತ ರೀತಿಯಲ್ಲಿ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಿ

■ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುವುದು

■ ತುರ್ತು ಡೇಟಾವನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲಾಗುತ್ತಿದೆ

■ ಮರುಹಂಚಿಕೆಗೆ ಧನಾತ್ಮಕ ದೃಢೀಕರಣ

■ ಮರುಪ್ರಸಾರ ಕಾಲಾವಧಿಯನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಿ

■ ನೆಟ್‌ವರ್ಕ್ ದಟ್ಟಣೆಯ ಸಮಯದಲ್ಲಿ ಕಡಿಮೆಯಾದ ರಿಟರ್ನ್ ಟ್ರಾಫಿಕ್

■ ವಿಭಾಗಗಳು ಕ್ರಮಬದ್ಧವಾಗಿಲ್ಲ ಎಂದು ಸೂಚಿಸುವುದು

■ ಸ್ವೀಕರಿಸುವ ವಿಂಡೋದ ಮುಚ್ಚುವಿಕೆಯನ್ನು ಗ್ರಹಿಸುವುದು

TCP ಸಂಪರ್ಕವು ಹಲವಾರು ಹಂತಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ: ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ, ನಂತರ ಡೇಟಾವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ವಿಶೇಷ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡುವ ಮೂಲಕ ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಲಾಗುತ್ತದೆ. ಸಂಪರ್ಕ ಕಾರ್ಯಾಚರಣೆಯ ಪ್ರತಿಯೊಂದು ಹಂತವು ನಿರ್ದಿಷ್ಟವಾಗಿ ಅನುರೂಪವಾಗಿದೆ ಸ್ಥಿತಿಈ ಸಂಪರ್ಕ. ಸಂಪರ್ಕದ ಪ್ರತಿ ತುದಿಯಲ್ಲಿರುವ TCP ಸಾಫ್ಟ್‌ವೇರ್ ಸಂಪರ್ಕದ ಇನ್ನೊಂದು ಬದಿಯ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ.

ಸಂಪರ್ಕದ ವಿರುದ್ಧ ತುದಿಯಲ್ಲಿರುವ ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವಿನ ವಿಶಿಷ್ಟ ಸ್ಥಿತಿಯ ಪರಿವರ್ತನೆಯನ್ನು ನಾವು ಕೆಳಗೆ ಸಂಕ್ಷಿಪ್ತವಾಗಿ ನೋಡುತ್ತೇವೆ. ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವಾಗ ನಾವು ಎಲ್ಲಾ ಸಂಭವನೀಯ ಸ್ಥಿತಿಗಳ ಸಮಗ್ರ ವಿವರಣೆಯನ್ನು ಒದಗಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿಲ್ಲ. ಇದನ್ನು RFC 793 ಮತ್ತು ದಾಖಲೆಯಲ್ಲಿ ನೀಡಲಾಗಿದೆ ಹೋಸ್ಟ್ ಅಗತ್ಯತೆಗಳು.

ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯ ಸಮಯದಲ್ಲಿ, ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ರಾಜ್ಯಗಳ ಒಂದೇ ರೀತಿಯ ಅನುಕ್ರಮಗಳ ಮೂಲಕ ಹೋಗುತ್ತಾರೆ. ಸರ್ವರ್ ಸ್ಟೇಟ್ಸ್ ಅನ್ನು ಟೇಬಲ್ 10.3 ರಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸ್ಟೇಟ್ಸ್ ಅನ್ನು ಟೇಬಲ್ 10.4 ರಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ.

ಕೋಷ್ಟಕ 10.3 ಸರ್ವರ್ ರಾಜ್ಯದ ಅನುಕ್ರಮ

ಕೋಷ್ಟಕ 10.4 ಕ್ಲೈಂಟ್ ಸ್ಟೇಟ್ ಸೀಕ್ವೆನ್ಸ್

ಪಾಲುದಾರರು ಏಕಕಾಲದಲ್ಲಿ ಪರಸ್ಪರ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ (ಇದು ಅತ್ಯಂತ ಅಪರೂಪ), ಪ್ರತಿಯೊಬ್ಬರೂ ಮುಚ್ಚಿದ, SYN-SENT, SYN- ಸ್ವೀಕರಿಸಿದ ಮತ್ತು ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಗಳ ಮೂಲಕ ಹೋಗುತ್ತಾರೆ.

ಒಂದು ಪಕ್ಷವು ಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ಸಂಪರ್ಕದ ಅಂತಿಮ ಪಕ್ಷಗಳು ಸ್ಥಾಪಿತ ಸ್ಥಿತಿಯಲ್ಲಿಯೇ ಇರುತ್ತವೆ ಮುಚ್ಚಿದ FIN ವಿಭಾಗವನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಸಂಪರ್ಕಗಳು. ಸಾಮಾನ್ಯ ಮುಕ್ತಾಯದ ಸಮಯದಲ್ಲಿ, ಮುಚ್ಚುವಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವ ಪಕ್ಷವು ಟೇಬಲ್ 10.5 ರಲ್ಲಿ ತೋರಿಸಿರುವ ರಾಜ್ಯಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಅವಳ ಪಾಲುದಾರನು ಕೋಷ್ಟಕ 10.6 ರಲ್ಲಿ ಪ್ರಸ್ತುತಪಡಿಸಿದ ರಾಜ್ಯಗಳ ಮೂಲಕ ಹೋಗುತ್ತಾನೆ.

ಕೋಷ್ಟಕ 10.5 ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚುವ ಬದಿಯ ರಾಜ್ಯಗಳ ಅನುಕ್ರಮ

ಕೋಷ್ಟಕ 10.6 ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಿದಾಗ ಪಾಲುದಾರರ ಸ್ಥಿತಿಗಳ ಅನುಕ್ರಮ

ತಂಡ netstat -anಪ್ರಸ್ತುತ ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ರಾಜ್ಯಗಳಲ್ಲಿನ ಸಂಪರ್ಕಗಳನ್ನು ಕೆಳಗೆ ತೋರಿಸಲಾಗಿದೆ ಆಲಿಸಿ, ಪ್ರಾರಂಭ, ಸ್ಥಾಪಿಸಿ, ಮುಚ್ಚುವುದುಮತ್ತು ಸಮಯ-ಕಾಯುವುದು.

ಪ್ರತಿ ಸ್ಥಳೀಯ ಮತ್ತು ಬಾಹ್ಯ ವಿಳಾಸದ ಕೊನೆಯಲ್ಲಿ ಸಂಪರ್ಕ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯನ್ನು ಪಟ್ಟಿ ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ಕ್ಯೂ ಎರಡಕ್ಕೂ TCP ಟ್ರಾಫಿಕ್ ಇರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು.

Pro Recv-Q ಕಳುಹಿಸಿ-Q ಸ್ಥಳೀಯ ವಿಳಾಸ ವಿದೇಶಿ ವಿಳಾಸ (ರಾಜ್ಯ)

Tcp 0 0 128.121.50.145.25 128.252.223.5.1526 SYN_RCVD

Tcp 0 0 128.121.50.145.25 148.79.160.65.3368 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 127.0.0.1.1339 127.0.0.1.111 TIME_WAIT

Tcp 0 438 128.121.50.145.23 130.132.57.246.2219 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.25 192.5.5.1.4022 TIME_WAIT

Tcp 0 0 128.121.50.145.25 141.218.1.100.3968 TIME_WAIT

Tcp 0 848 128.121.50.145.23 192.67.236.10.1050 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.1082 128.121.50.141.6000 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.1022 128.121.50.141.1017 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.514 128.121.50.141.1020 CLOSE_WAIT

Tcp 0 1152 128.121.50.145.119 192.67.239.23.3572 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.1070 192.41.171.5.119 TIME_WAIT

Tcp 579 4096 128.121.50.145.119 204.143.19.30.1884 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 0 128.121.50.145.119 192.67.243.13.3704 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

Tcp 0 53 128.121.50.145.119 192.67.236.218.2018 FIN_WAIT_1

Tcp 0 0 128.121.50.145.119 192.67.239.14.1545 ಸ್ಥಾಪಿಸಲಾಗಿದೆ

ಮೊದಲಿನಿಂದಲೂ, TCP ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವಿವಿಧ ತಯಾರಕರಿಂದ ನೆಟ್ವರ್ಕ್ ಉಪಕರಣಗಳನ್ನು ಪರಸ್ಪರ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. TCP ವಿವರಣೆಯು ಆಂತರಿಕ ಅನುಷ್ಠಾನ ರಚನೆಗಳು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿಖರವಾಗಿ ಸೂಚಿಸುವುದಿಲ್ಲ. ಈ ಪ್ರಶ್ನೆಗಳನ್ನು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಬಿಡಲಾಗಿದೆ, ಅವರು ಪ್ರತಿ ನಿರ್ದಿಷ್ಟ ಅನುಷ್ಠಾನಕ್ಕೆ ಉತ್ತಮ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಕಾರ್ಯವನ್ನು ಹೊಂದಿದ್ದಾರೆ.

ಸಹ RFC 1122 (ಡಾಕ್ಯುಮೆಂಟ್ ಹೋಸ್ಟ್ ಅವಶ್ಯಕತೆಗಳು -ಅತಿಥೇಯಗಳ ಅವಶ್ಯಕತೆಗಳು) ವ್ಯತ್ಯಾಸಗಳಿಗೆ ಸಾಕಷ್ಟು ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಕಾರ್ಯಗತಗೊಳಿಸಿದ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ಮಟ್ಟದ ಹೊಂದಾಣಿಕೆಯೊಂದಿಗೆ ಗುರುತಿಸಲಾಗಿದೆ:

■ ಮೇ (ಅನುಮತಿ ಇದೆ)

■ ಮಾಡಬಾರದು

ದುರದೃಷ್ಟವಶಾತ್, ಕೆಲವೊಮ್ಮೆ ಅಗತ್ಯತೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸದ ಉತ್ಪನ್ನಗಳಿವೆ. ಪರಿಣಾಮವಾಗಿ, ಬಳಕೆದಾರರು ಕಡಿಮೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಅನಾನುಕೂಲತೆಯನ್ನು ಅನುಭವಿಸುತ್ತಾರೆ.

ಕೆಲವು ಉತ್ತಮ ಅನುಷ್ಠಾನದ ಅಭ್ಯಾಸಗಳು ಮಾನದಂಡಗಳಲ್ಲಿ ಒಳಗೊಂಡಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಸ್ಥಳೀಯ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಈ ವಿಧಾನವನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸವಲತ್ತು ಪಡೆದ ಪ್ರಕ್ರಿಯೆಗಳ ಮೂಲಕ ಪ್ರಸಿದ್ಧ ಪೋರ್ಟ್‌ಗಳ ಬಳಕೆಯನ್ನು ನಿರ್ಬಂಧಿಸುವ ಮೂಲಕ ಭದ್ರತೆಯನ್ನು ಸುಧಾರಿಸಬಹುದು. ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸಲು, ಅಳವಡಿಕೆಗಳು ಕಳುಹಿಸಿದ ಅಥವಾ ಹಿಂಪಡೆದ ಡೇಟಾವನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಕಡಿಮೆ ನಕಲಿಸಬೇಕು ಮತ್ತು ಸರಿಸಬೇಕು.

ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ(ಹಾಗೆಯೇ ಭದ್ರತಾ ನೀತಿ) ಇದರಿಂದ ವಿವಿಧ ಸೆಟ್‌ಗಳ ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಕರಗಳೊಂದಿಗೆ ಪ್ರಯೋಗಿಸಲು ಮುಕ್ತ ಸ್ಥಳವಿದೆ. ಆದಾಗ್ಯೂ, ಇದು ಪ್ರತಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಬಳಸುವುದಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು ಮತ್ತು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳ ನಡುವೆ ಅಪ್ಲಿಕೇಶನ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸರಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.

ವಾಸ್ತವವಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಟೂಲ್‌ಕಿಟ್‌ಗಳನ್ನು ಬರ್ಕ್ಲಿಯಿಂದ ಎರವಲು ಪಡೆದ ಸಾಕೆಟ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಆಧರಿಸಿದ್ದಾರೆ. ವಿನ್‌ಸಾಕ್ (ವಿಂಡೋಸ್ ಸಾಕೆಟ್) ಆಗಮನದೊಂದಿಗೆ ಸಾಫ್ಟ್‌ವೇರ್ ಇಂಟರ್ಫೇಸ್‌ನ ಪ್ರಾಮುಖ್ಯತೆಯು ಹೆಚ್ಚಾಯಿತು, ಇದು ಹೊಸ ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಪ್ರಸರಣಕ್ಕೆ ಕಾರಣವಾಯಿತು, ಅದು ಟಿಸಿಪಿ/ಐಪಿ ಸ್ಟಾಕ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಯಾವುದೇ ವಿನ್‌ಸಾಕ್ ಇಂಟರ್‌ಫೇಸ್‌ನ ಮೇಲೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಮೂಲ TCP ಮಾನದಂಡವನ್ನು RFC 793 ರಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ನವೀಕರಣಗಳು, ಪರಿಷ್ಕರಣೆಗಳು ಮತ್ತು ಹೊಂದಾಣಿಕೆಯ ಅಗತ್ಯತೆಗಳನ್ನು RFC 1122 ನಲ್ಲಿ ತಿಳಿಸಲಾಗಿದೆ. ಕೆರ್ನ್ ಮತ್ತು ಪಾರ್ಟ್ರಿಡ್ಜ್ ಲೇಖನವನ್ನು ಪ್ರಕಟಿಸಿದರು ವಿಶ್ವಾಸಾರ್ಹ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಲ್ಲಿ ರೌಂಡ್-ಟ್ರಿಪ್ ಅಂದಾಜುಗಳನ್ನು ಸುಧಾರಿಸುವುದುಪತ್ರಿಕೆಯಲ್ಲಿ ACM SIGCOMM 1987 ರ ಪ್ರಕ್ರಿಯೆಗಳು.ಜಾಕೋಬ್ಸನ್ ಅವರ ಲೇಖನ ದಟ್ಟಣೆ ತಪ್ಪಿಸುವಿಕೆ ಮತ್ತು ನಿಯಂತ್ರಣಕಾಣಿಸಿಕೊಂಡರು ACM SIGCOMM 1988 ಕಾರ್ಯಾಗಾರದ ಪ್ರಕ್ರಿಯೆಗಳು.ಜಾಕೋಬ್ಸನ್ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕ್ರಮಾವಳಿಗಳನ್ನು ಪರಿಷ್ಕರಿಸುವ ಹಲವಾರು RFCಗಳನ್ನು ಸಹ ಬಿಡುಗಡೆ ಮಾಡಿದರು.

ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ TCP ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್‌ನಲ್ಲಿ

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

ಕೆಳಗಿನ ಪ್ರೋಗ್ರಾಂ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಸಂಪರ್ಕ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸರ್ವರ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಸರ್ವರ್ ಅನ್ನು ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ, ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು ಸರ್ವರ್ ಒಪ್ಪಿಕೊಳ್ಳುವವರೆಗೆ ಥ್ರೆಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸಲಾಗುತ್ತದೆ. ಈ ಅಪ್ಲಿಕೇಶನ್ ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಸರಳ ಸರ್ವರ್ ಅನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸುತ್ತದೆ .

TCP ಸರ್ವರ್

ಸರ್ವರ್ ರಚನೆಯ ರಚನೆಯನ್ನು ಕೆಳಗಿನ ಕ್ರಿಯಾತ್ಮಕ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ತೋರಿಸಲಾಗಿದೆ:

SocketServer.cs ಪ್ರೋಗ್ರಾಂಗಾಗಿ ಸಂಪೂರ್ಣ ಕೋಡ್ ಇಲ್ಲಿದೆ:

// ಸಿಸ್ಟಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು SocketServer.cs; System.Text ಅನ್ನು ಬಳಸುವುದು; System.Net ಅನ್ನು ಬಳಸುವುದು; System.Net.Sockets ಅನ್ನು ಬಳಸುವುದು; ನೇಮ್‌ಸ್ಪೇಸ್ ಸಾಕೆಟ್‌ಸರ್ವರ್ (ಕ್ಲಾಸ್ ಪ್ರೋಗ್ರಾಂ (ಸ್ಟ್ರಿಂಗ್ ಅನೂರ್ಜಿತ ಮುಖ್ಯ (ಸ್ಟ್ರಿಂಗ್ ಆರ್ಗ್‌ಗಳು) , 11000 ); // ಒಂದು Tcp/Ip ಸಾಕೆಟ್ ರಚಿಸಿ sListener = ಹೊಸ ಸಾಕೆಟ್ (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp); sListener(10); ಒಳಬರುವ ಸಂಪರ್ಕ ಸಾಕೆಟ್ ಹ್ಯಾಂಡ್ಲರ್ = sListener. ಸ್ಟ್ರಿಂಗ್ ಡೇಟಾ = ಶೂನ್ಯ; \n\n"); // ಕ್ಲೈಂಟ್\ ಸ್ಟ್ರಿಂಗ್ ಪ್ರತ್ಯುತ್ತರಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸಿ = "" + data.Length.ToString() + " ಅಕ್ಷರಗಳಲ್ಲಿ ವಿನಂತಿಗಾಗಿ ಧನ್ಯವಾದಗಳು"; ಬೈಟ್ msg = ಎನ್‌ಕೋಡಿಂಗ್.UTF8.GetBytes(ಪ್ರತ್ಯುತ್ತರ); ಹ್ಯಾಂಡ್ಲರ್.ಕಳುಹಿಸು(ಸಂದೇಶ); ವೇಳೆ (data.IndexOf(" ") > -1) ( Console.WriteLine("ಸರ್ವರ್ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಿದೆ."); ಬ್ರೇಕ್; ) ಹ್ಯಾಂಡ್ಲರ್ ( Console.WriteLine (ex.ToString()); ) ಅಂತಿಮವಾಗಿ ( Console.ReadLine(); ) ) )

ಈ ಕಾರ್ಯಕ್ರಮದ ರಚನೆಯನ್ನು ನೋಡೋಣ.

ಸಾಕೆಟ್ ಅನ್ನು ಸ್ಥಳೀಯ ಅಂತಿಮ ಬಿಂದುವಿಗೆ ಹೊಂದಿಸುವುದು ಮೊದಲ ಹಂತವಾಗಿದೆ. ಸಂಪರ್ಕಗಳನ್ನು ಕೇಳಲು ಸಾಕೆಟ್ ತೆರೆಯುವ ಮೊದಲು, ನೀವು ಅದಕ್ಕೆ ಸ್ಥಳೀಯ ಅಂತ್ಯಬಿಂದು ವಿಳಾಸವನ್ನು ಸಿದ್ಧಪಡಿಸಬೇಕು. ವಿಶಿಷ್ಟವಾದ TCP/IP ಸೇವಾ ವಿಳಾಸವನ್ನು ಸರ್ವಿಸಿಂಗ್ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಹೋಸ್ಟ್‌ನ IP ವಿಳಾಸದ ಸಂಯೋಜನೆಯಿಂದ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ, ಇದು ಸರ್ವಿಸಿಂಗ್ ಎಂಡ್ ಪಾಯಿಂಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ.

ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸಾಧನವು ಬೆಂಬಲಿಸುವ ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸಗಳ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಹಿಂದಿರುಗಿಸುವ ವಿಧಾನಗಳನ್ನು Dns ವರ್ಗ ಒದಗಿಸುತ್ತದೆ. LAN ಸಾಧನವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, Dns ವರ್ಗವು ಎಲ್ಲಾ ನೆಟ್‌ವರ್ಕ್ ವಿಳಾಸಗಳ ಮಾಹಿತಿಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ರಚನೆಯಿಂದ ಸೇವೆ ಸಲ್ಲಿಸಲು ಸೂಕ್ತವಾದ ವಿಳಾಸವನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕು.

Dns.Resolve() ವಿಧಾನದಿಂದ ಪಡೆದ ಹೋಸ್ಟ್ ಕಂಪ್ಯೂಟರ್‌ನ ಮೊದಲ IP ವಿಳಾಸವನ್ನು ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಮೂಲಕ ಸರ್ವರ್‌ಗಾಗಿ IPEndPoint ಅನ್ನು ರಚಿಸೋಣ:

IPHostEntry ipHost = Dns.GetHostEntry("localhost"); IPAddress ipAddr = ipHost.AddressList; IPEndPoint ipEndPoint = ಹೊಸ IPEndPoint(ipAddr, 11000);

ಇಲ್ಲಿ IPEndPoint ವರ್ಗವು ಪೋರ್ಟ್ 11000 ನಲ್ಲಿ ಸ್ಥಳೀಯ ಹೋಸ್ಟ್ ಅನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. ಮುಂದೆ, ನಾವು ಸಾಕೆಟ್ ವರ್ಗದ ಹೊಸ ನಿದರ್ಶನದೊಂದಿಗೆ ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ. ಸಂಪರ್ಕಗಳನ್ನು ಕೇಳಲು ಸ್ಥಳೀಯ ಅಂತಿಮ ಬಿಂದುವನ್ನು ಹೊಂದಿಸಿದ ನಂತರ, ನಾವು ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸಬಹುದು:

ಸಾಕೆಟ್ sListener = ಹೊಸ ಸಾಕೆಟ್ (ipAddr.AddressFamily, SocketType.Stream, ProtocolType.Tcp);

ವರ್ಗಾವಣೆ ವಿಳಾಸ ಕುಟುಂಬವಿಳಾಸವನ್ನು ಪರಿಹರಿಸಲು ಸಾಕೆಟ್ ವರ್ಗದ ನಿದರ್ಶನವನ್ನು ಬಳಸಬಹುದಾದ ವಿಳಾಸ ಯೋಜನೆಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.

ನಿಯತಾಂಕದಲ್ಲಿ ಸಾಕೆಟ್ ಪ್ರಕಾರ TCP ಮತ್ತು UDP ಸಾಕೆಟ್‌ಗಳು ವಿಭಿನ್ನವಾಗಿವೆ. ಅದರಲ್ಲಿ ನೀವು ಇತರ ವಿಷಯಗಳ ಜೊತೆಗೆ, ಈ ಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು:

ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. Dgram ಮೌಲ್ಯವು ವಿಳಾಸ ಕುಟುಂಬ ಪ್ಯಾರಾಮೀಟರ್‌ನಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರ ಮತ್ತು ಇಂಟರ್‌ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ Udp ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿದೆ.

ಆಧಾರವಾಗಿರುವ ಸಾರಿಗೆ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ.

ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್‌ಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ಸ್ಟ್ರೀಮ್ ಮೌಲ್ಯವು ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರಕ್ಕಾಗಿ Tcp ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವ ಅಗತ್ಯವಿದೆ.

ಮೂರನೇ ಮತ್ತು ಅಂತಿಮ ಪ್ಯಾರಾಮೀಟರ್ ಸಾಕೆಟ್‌ಗೆ ಅಗತ್ಯವಿರುವ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ನಿಯತಾಂಕದಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರನೀವು ಈ ಕೆಳಗಿನ ಪ್ರಮುಖ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು - Tcp, Udp, Ip, Raw.

ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಸಾಕೆಟ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಮುಂದಿನ ಹಂತವು ಇರಬೇಕು ಬೈಂಡ್(). ಕನ್‌ಸ್ಟ್ರಕ್ಟರ್‌ನಿಂದ ಸಾಕೆಟ್ ಅನ್ನು ತೆರೆದಾಗ, ಅದಕ್ಕೆ ಹೆಸರನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿಲ್ಲ, ಹ್ಯಾಂಡಲ್ ಅನ್ನು ಮಾತ್ರ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ. ಸರ್ವರ್ ಸಾಕೆಟ್‌ಗೆ ಹೆಸರನ್ನು ನಿಯೋಜಿಸಲು ಬೈಂಡ್ () ವಿಧಾನವನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಸಾಕೆಟ್‌ಗೆ TCP ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್ ಅನ್ನು ಗುರುತಿಸಲು, ಸರ್ವರ್ ಪ್ರೋಗ್ರಾಂ ತನ್ನ ಸಾಕೆಟ್‌ಗೆ ಹೆಸರನ್ನು ನೀಡಬೇಕು:

SListener.Bind(ipEndPoint);

ಬೈಂಡ್ () ವಿಧಾನವು ಸಾಕೆಟ್ ಅನ್ನು ಸ್ಥಳೀಯ ಅಂತಿಮ ಬಿಂದುವಿಗೆ ಬಂಧಿಸುತ್ತದೆ. Listen() ಮತ್ತು Accept() ವಿಧಾನಗಳನ್ನು ಕರೆಯುವ ಯಾವುದೇ ಪ್ರಯತ್ನಗಳ ಮೊದಲು Bind() ವಿಧಾನವನ್ನು ಕರೆಯಬೇಕು.

ಈಗ, ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸಿ ಮತ್ತು ಅದರೊಂದಿಗೆ ಹೆಸರನ್ನು ಸಂಯೋಜಿಸಿದ ನಂತರ, ನೀವು ವಿಧಾನವನ್ನು ಬಳಸಿಕೊಂಡು ಒಳಬರುವ ಸಂದೇಶಗಳನ್ನು ಕೇಳಬಹುದು ಕೇಳು(). ಆಲಿಸುವ ಸ್ಥಿತಿಯಲ್ಲಿ, ಒಳಬರುವ ಸಂಪರ್ಕ ಪ್ರಯತ್ನಗಳನ್ನು ಸಾಕೆಟ್ ಆಲಿಸುತ್ತದೆ:

SListener.Listen(10);

ನಿಯತಾಂಕವು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ ಬಾಕಿ, ಕ್ಯೂನಲ್ಲಿ ಕಾಯುತ್ತಿರುವ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಮೇಲಿನ ಕೋಡ್‌ನಲ್ಲಿ, ಪ್ಯಾರಾಮೀಟರ್ ಮೌಲ್ಯವು ಸರದಿಯಲ್ಲಿ ಹತ್ತು ಸಂಪರ್ಕಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.

ಆಲಿಸುವ ಸ್ಥಿತಿಯಲ್ಲಿ, ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕಿಸಲು ನೀವು ಒಪ್ಪಿಕೊಳ್ಳಲು ಸಿದ್ಧರಾಗಿರಬೇಕು, ಇದಕ್ಕಾಗಿ ವಿಧಾನವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಒಪ್ಪಿಕೊಳ್ಳಿ(). ಈ ವಿಧಾನವು ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಹೆಸರಿನ ಸಂಯೋಜನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ. ಸಂಪರ್ಕವು ಬರುವವರೆಗೆ ಸ್ವೀಕರಿಸುವ () ವಿಧಾನವು ಕರೆ ಮಾಡುವ ಪ್ರೋಗ್ರಾಂನ ಥ್ರೆಡ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುತ್ತದೆ.

ಸ್ವೀಕರಿಸುವ () ವಿಧಾನವು ಬಾಕಿ ಇರುವ ವಿನಂತಿಗಳ ಸರದಿಯಿಂದ ಮೊದಲ ಸಂಪರ್ಕ ವಿನಂತಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೊಸ ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಹೊಸ ಸಾಕೆಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದ್ದರೂ, ಮೂಲ ಸಾಕೆಟ್ ಆಲಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬಹು ಸಂಪರ್ಕ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಬಹು-ಥ್ರೆಡಿಂಗ್‌ನೊಂದಿಗೆ ಬಳಸಬಹುದು. ಯಾವುದೇ ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್ ಆಲಿಸುವ ಸಾಕೆಟ್ ಅನ್ನು ಮುಚ್ಚಬಾರದು. ಒಳಬರುವ ಕ್ಲೈಂಟ್ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಒಪ್ಪಿಕೊಳ್ಳುವ ವಿಧಾನದಿಂದ ರಚಿಸಲಾದ ಸಾಕೆಟ್‌ಗಳ ಜೊತೆಗೆ ಇದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬೇಕು.

(ನಿಜ) (Console.WriteLine("ಪೋರ್ಟ್ (0) ನಲ್ಲಿ ಸಂಪರ್ಕಕ್ಕಾಗಿ ನಿರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ", ipEndPoint); // ಒಳಬರುವ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ಪ್ರೋಗ್ರಾಂ ವಿರಾಮಗೊಳ್ಳುತ್ತದೆ ಸಾಕೆಟ್ ಹ್ಯಾಂಡ್ಲರ್ = sListener.Accept();

ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಪರಸ್ಪರ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಬಹುದು ಮತ್ತು ಸ್ವೀಕರಿಸಬಹುದು ಕಳುಹಿಸು()ಮತ್ತು ಸ್ವೀಕರಿಸಿ ()ವರ್ಗ ಸಾಕೆಟ್.

ಕಳುಹಿಸು() ವಿಧಾನವು ಸಂಪರ್ಕಿತ ಸಾಕೆಟ್‌ಗೆ ಹೊರಹೋಗುವ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತದೆ. ರಿಸೀವ್ () ವಿಧಾನವು ಒಳಬರುವ ಡೇಟಾವನ್ನು ಸ್ಟ್ರೀಮ್ ಸಾಕೆಟ್‌ಗೆ ಓದುತ್ತದೆ. TCP ಆಧಾರಿತ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸುವಾಗ, ಕಳುಹಿಸು () ಮತ್ತು ಸ್ವೀಕರಿಸಿ () ವಿಧಾನಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೊದಲು ಸಾಕೆಟ್‌ಗಳ ನಡುವೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಬೇಕು. ಎರಡು ಸಂವಹನ ಘಟಕಗಳ ನಡುವಿನ ನಿಖರವಾದ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಮುಂಚಿತವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಬೇಕು ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ತಮ್ಮ ಡೇಟಾವನ್ನು ಮೊದಲು ಯಾರು ಕಳುಹಿಸಬೇಕು ಎಂದು ತಿಳಿಯದೆ ಪರಸ್ಪರ ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ.

ಸರ್ವರ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ನಡುವಿನ ಡೇಟಾ ವಿನಿಮಯ ಪೂರ್ಣಗೊಂಡಾಗ, ನೀವು ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕವನ್ನು ಮುಚ್ಚಬೇಕಾಗುತ್ತದೆ ಮುಚ್ಚಲಾಯಿತು()ಮತ್ತು ಮುಚ್ಚಿ():

ಹ್ಯಾಂಡ್ಲರ್.ಶಟ್‌ಡೌನ್(ಸಾಕೆಟ್‌ಶಟ್‌ಡೌನ್.ಎರಡೂ); ಹ್ಯಾಂಡ್ಲರ್.ಕ್ಲೋಸ್();

ಸಾಕೆಟ್ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆಯು ನಿಲ್ಲಿಸಲು ಮೂರು ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿರುವ enum ಆಗಿದೆ: ಎರಡೂ- ಸಾಕೆಟ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮತ್ತು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಸ್ವೀಕರಿಸಿ- ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸದಂತೆ ಸಾಕೆಟ್ ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಕಳುಹಿಸು- ಸಾಕೆಟ್ ಮೂಲಕ ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

ಸಾಕೆಟ್ ಅನ್ನು ಕ್ಲೋಸ್ () ವಿಧಾನವನ್ನು ಕರೆಯುವ ಮೂಲಕ ಮುಚ್ಚಲಾಗುತ್ತದೆ, ಇದು ಸಾಕೆಟ್‌ನ ಸಂಪರ್ಕಿತ ಆಸ್ತಿಯನ್ನು ತಪ್ಪು ಎಂದು ಹೊಂದಿಸುತ್ತದೆ.

TCP ಕ್ಲೈಂಟ್

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

ಈ ಪ್ರೋಟೋಕಾಲ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸರ್ವರ್‌ಗಳು ಕಾರ್ಪೊರೇಟ್ ನೆಟ್ವರ್ಕ್, ಕ್ಲೈಂಟ್‌ಗೆ IP ವಿಳಾಸ, ಗೇಟ್‌ವೇ, ನೆಟ್‌ಮಾಸ್ಕ್, ನೇಮ್ ಸರ್ವರ್‌ಗಳು ಮತ್ತು ಪ್ರಿಂಟರ್ ಅನ್ನು ಸಹ ಒದಗಿಸಿ. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸಲು ಬಳಕೆದಾರರು ತಮ್ಮ ಹೋಸ್ಟ್‌ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ.

ಕ್ಯೂಎನ್‌ಎಕ್ಸ್ ನ್ಯೂಟ್ರಿನೊ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಆಟೋಐಪಿ ಎಂಬ ಮತ್ತೊಂದು ಸ್ವಯಂ-ಕಾನ್ಫಿಗರೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಇದು ಐಇಟಿಎಫ್ ಸಮಿತಿಯ ಯೋಜನೆಯಾಗಿದೆ. ಸ್ವಯಂಚಾಲಿತ ಸಂರಚನೆ. ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಲಿಂಕ್-ಸ್ಥಳೀಯ IP ವಿಳಾಸಗಳನ್ನು ನಿಯೋಜಿಸಲು ಈ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸಣ್ಣ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ. ಆಟೋಐಪಿ ಪ್ರೋಟೋಕಾಲ್ ಸ್ವತಂತ್ರವಾಗಿ ಲಿಂಕ್‌ಗೆ ಸ್ಥಳೀಯ ಐಪಿ ವಿಳಾಸವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಇತರ ಹೋಸ್ಟ್‌ಗಳೊಂದಿಗೆ ಸಮಾಲೋಚನಾ ಯೋಜನೆಯನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ಕೇಂದ್ರ ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸದೆ.

PPPoE ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸುವುದು

PPPoE ಎಂಬ ಸಂಕ್ಷೇಪಣವು ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಪ್ರೋಟೋಕಾಲ್ ಓವರ್ ಎತರ್ನೆಟ್ ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಈ ಪ್ರೋಟೋಕಾಲ್ ಬ್ರಿಡ್ಜ್ಡ್ ಟೋಪೋಲಜಿಯೊಂದಿಗೆ ಎತರ್ನೆಟ್ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಪ್ರಸರಣಕ್ಕಾಗಿ ಡೇಟಾವನ್ನು ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಟ್ ಮಾಡುತ್ತದೆ.

PPPoE ಬಳಕೆದಾರರ ಸಂಪರ್ಕದ ವಿವರಣೆಯಾಗಿದೆ ಎತರ್ನೆಟ್ ಜಾಲಗಳುಡಿಜಿಟಲ್ ಚಂದಾದಾರರ ಲೈನ್, ವೈರ್‌ಲೆಸ್ ಸಾಧನ ಅಥವಾ ಕೇಬಲ್ ಮೋಡೆಮ್‌ನಂತಹ ಬ್ರಾಡ್‌ಬ್ಯಾಂಡ್ ಸಂಪರ್ಕದ ಮೂಲಕ ಇಂಟರ್ನೆಟ್‌ಗೆ. PPPoE ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಬ್ರಾಡ್‌ಬ್ಯಾಂಡ್ ಮೋಡೆಮ್‌ನ ಬಳಕೆಯು ಬಳಕೆದಾರರಿಗೆ ಸ್ಥಳೀಯವನ್ನು ಒದಗಿಸುತ್ತದೆ ಗಣಕಯಂತ್ರದ ಜಾಲಗೆ ವೈಯಕ್ತಿಕ ದೃಢೀಕೃತ ಪ್ರವೇಶ ಹೆಚ್ಚಿನ ವೇಗದ ಜಾಲಗಳುಡೇಟಾ ಪ್ರಸರಣ.

PPPoE ಪ್ರೋಟೋಕಾಲ್ ಈಥರ್ನೆಟ್ ತಂತ್ರಜ್ಞಾನವನ್ನು PPP ಪ್ರೋಟೋಕಾಲ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ, ಪ್ರತಿ ಬಳಕೆದಾರರಿಗೆ ರಿಮೋಟ್ ಸರ್ವರ್‌ಗೆ ಪ್ರತ್ಯೇಕ ಸಂಪರ್ಕವನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ರಚಿಸುತ್ತದೆ. ಪ್ರವೇಶ ನಿಯಂತ್ರಣ, ಸಂಪರ್ಕ ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ ಮತ್ತು ಸೇವಾ ಪೂರೈಕೆದಾರರ ಆಯ್ಕೆಯನ್ನು ಬಳಕೆದಾರರಿಗೆ ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ, ಹೋಸ್ಟ್‌ಗಳಿಗೆ ಅಲ್ಲ. ಈ ವಿಧಾನದ ಪ್ರಯೋಜನವೆಂದರೆ ದೂರವಾಣಿ ಕಂಪನಿ ಅಥವಾ ಇಂಟರ್ನೆಟ್ ಸೇವಾ ಪೂರೈಕೆದಾರರು ಇದಕ್ಕೆ ಯಾವುದೇ ವಿಶೇಷ ಬೆಂಬಲವನ್ನು ನೀಡಬೇಕಾಗಿಲ್ಲ.

ಡಯಲ್-ಅಪ್ ಸಂಪರ್ಕಗಳಿಗಿಂತ ಭಿನ್ನವಾಗಿ, DSL ಮತ್ತು ಕೇಬಲ್ ಮೋಡೆಮ್ ಸಂಪರ್ಕಗಳು ಯಾವಾಗಲೂ ಸಕ್ರಿಯವಾಗಿರುತ್ತವೆ. ರಿಮೋಟ್ ಸೇವಾ ಪೂರೈಕೆದಾರರಿಗೆ ಭೌತಿಕ ಸಂಪರ್ಕವನ್ನು ಬಹು ಬಳಕೆದಾರರಲ್ಲಿ ಹಂಚಿಕೊಳ್ಳಲಾಗಿರುವುದರಿಂದ, ಕಳುಹಿಸುವವರು ಮತ್ತು ಟ್ರಾಫಿಕ್‌ನ ಸ್ಥಳಗಳನ್ನು ದಾಖಲಿಸುವ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಶುಲ್ಕ ವಿಧಿಸುವ ಲೆಕ್ಕಪತ್ರ ವಿಧಾನದ ಅಗತ್ಯವಿದೆ. PPPoE ಪ್ರೋಟೋಕಾಲ್ ಸಂವಹನ ಅಧಿವೇಶನದಲ್ಲಿ ಭಾಗವಹಿಸುವ ಬಳಕೆದಾರ ಮತ್ತು ರಿಮೋಟ್ ನೋಡ್ ಅನ್ನು ಗುರುತಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ನೆಟ್ವರ್ಕ್ ವಿಳಾಸಗಳುಎಂಬ ಆರಂಭಿಕ ವಿನಿಮಯದ ಸಮಯದಲ್ಲಿ ಪರಸ್ಪರ ಪತ್ತೆ(ಆವಿಷ್ಕಾರ). ಪ್ರತ್ಯೇಕ ಬಳಕೆದಾರ ಮತ್ತು ರಿಮೋಟ್ ಹೋಸ್ಟ್ (ಉದಾಹರಣೆಗೆ, ಇಂಟರ್ನೆಟ್ ಸೇವಾ ಪೂರೈಕೆದಾರ) ನಡುವೆ ಅಧಿವೇಶನವನ್ನು ಸ್ಥಾಪಿಸಿದ ನಂತರ, ಸೆಶನ್ ಅನ್ನು ಸಂಚಯ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಬಹುದು. ಅನೇಕ ಮನೆಗಳು, ಹೋಟೆಲ್‌ಗಳು ಮತ್ತು ನಿಗಮಗಳು ಈಥರ್ನೆಟ್ ತಂತ್ರಜ್ಞಾನ ಮತ್ತು PPPoE ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಡಿಜಿಟಲ್ ಚಂದಾದಾರರ ಮಾರ್ಗಗಳ ಮೂಲಕ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತವೆ.

PPPoE ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಸಂಪರ್ಕವು ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಎತರ್ನೆಟ್ ವಿಶೇಷಣಗಳಿಗೆ ಹತ್ತಿರವಿರುವ ಯಾವುದೇ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ IP ವಿಳಾಸಗಳನ್ನು ನೀಡಲು ಮತ್ತು ಆ IP ವಿಳಾಸಗಳನ್ನು ಬಳಕೆದಾರರೊಂದಿಗೆ ಮತ್ತು ಐಚ್ಛಿಕವಾಗಿ ವರ್ಕ್‌ಸ್ಟೇಷನ್-ಆಧಾರಿತ ದೃಢೀಕರಣಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ವರ್ಕ್‌ಸ್ಟೇಷನ್‌ಗಳೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ. PPPoE ಸರ್ವರ್ ಪ್ರತಿ ಕ್ಲೈಂಟ್‌ಗೆ ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ ಸಂಪರ್ಕವನ್ನು ರಚಿಸುತ್ತದೆ.

PPPoE ಅಧಿವೇಶನವನ್ನು ಹೊಂದಿಸಲಾಗುತ್ತಿದೆ

PPPoE ಅಧಿವೇಶನವನ್ನು ರಚಿಸಲು, ನೀವು ಸೇವೆಯನ್ನು ಬಳಸಬೇಕುpppoed. ಘಟಕio-pkt-*nPPPoE ಪ್ರೋಟೋಕಾಲ್ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಮೊದಲು ನೀವು ಓಡಬೇಕುio-pkt-*ಜೊತೆಗೆಸೂಕ್ತವಾದ ಚಾಲಕ. ಉದಾಹರಣೆ: