延迟退休方案今年推出 不同岗位绝不“一刀切”
| Модель TCP/IP (RFC 1122) |
|---|
| Прикладний р?вень |
| Транспортний р?вень |
| Мережевий р?вень |
| Канальний р?вень |
Transmission Control Protocol, TCP (укр. Протокол управл?ння передачею) — разом ?з протоколом IP ? стрижневим протоколом ?нтернету, який дав назву модел? TCP/IP. Протокол призначений для керування передаванням даних у комп'ютерних мережах, працю? на транспортному р?вн? модел? OSI.[1]
На в?дм?ну в?д ?ншого поширеного протоколу транспортного р?вня UDP, TCP забезпечу? над?йне доправляння даних в?д хоста-в?дправника до хоста-отримувача, для цього встановлю?ться лог?чний зв'язок м?ж хостами.[2] Таким чином TCP належить до класу протокол?в з? встановленим з'?днанням[en].
TCP отриму? потоки даних в?д протокол?в верхн?х р?вн?в OSI-модел?, початковим джерелом яких ? протоколи прикладного р?вня, так? як HTTP, FTP та ?нш?. Кожний протокол верхнього р?вня ма? св?й визначений TCP-порт.
TCP розбива? конкретний пот?к даних на порц??, та дода? до кожно? з них заголовок з номером посл?довност?. Отриман? таким чином порц?? даних традиц?йно називаються TCP-сегментами.[3] Дал? кожний сегмент ?нкапсулю?ться в IP-пакет ? переда?ться через IP-протокол до хоста-отримувача.
П?сля надходження IP-пакету до хоста-отримувача перев?ря?ться коректн?сть отриманих даних у TCP-сегмент?, методом перерахування контрольно? суми, та перекону?ться, що попередн? сегменти даних також були усп?шно отриман?. П?сля чого хост-отримувач надсила? запит до хоста-в?дправника про нову, або повторне передавання порц?? даних, що одночасно ? п?дтвердженням того, що вс? сегменти з номерами посл?довност?, меншими н?ж номер нового запиту, були усп?шно отриман?.
У свою чергу TCP-сегменти де?нкапсулюються з IP-пакет?в, розм?щуються в правильному порядку та з них вилучаються TCP-заголовки. Отриманий таким чином пот?к даних переда?ться до того протоколу верхнього р?вня, з якого перв?сно над?йшли дан? на сторон? хоста-в?дправника.
П?онером у розробц? сучасних комп'ютерних мереж вважа?ться Агентство передових оборонних досл?дницьких проект?в США, (DARPA, Defense Advanced Research Projects Agency) з? сво?ю розробкою - мережею ARPANET запущеною у 1969 роц?.[4]
Появою протоколу вважають 1974 р?к, коли ?нститут ?нженер?в з електротехн?ки та електрон?ки опубл?кував роботу ?Протокол для пакетно? мережево? комун?кац?? (A Protocol for Packet Network Intercommunication)?, авторами яко? були В?нтон Серф та Роберт Елл?от Кан.[5] У ц?й прац? TCP було абрев?атурою в?д Transmission Control Program (програма керування передаванням).
Блок даних (PDU[en], Protocol data unit) TCP назива?ться сегментом,[6] хоча часто також використовують слово пакет, але таке вживання може вносити плутанину з IP-пакетом.
TCP-сегмент склада?ться ?з TCP-заголовка ? поля Дан? (Data), яке називають сегментом даних або пейлодом[7] або SDU[en][8].
Стандартний розм?р TCP-заголовка — 20 байт, але з використанням опц?й розм?р може зростати до 60 байт. Як правило, опц?ями хости обм?нюються на етап? встановлення з'?днання.
Розм?р сегменту даних (поля даних) визнача?ться опц??ю MSS (Максимальний розм?р сегменту, Maximum segment size) на етап? встановлення з'?днання. Якщо обм?ну опц?ями не в?дбулося, то розм?р сегменту даних встановлю?ться за замовчуванням 536 байт.[9] Розм?р сегменту даних т?сно пов'язаний з MTU (Максимальний розм?р блоку пересилання). Фактично MSS дор?вню? MTU з в?дн?манням розм?ру IP- ? TCP-заголовк?в. Наприклад у сучасн?й мереж? Ethernet MTU дор?вню? 1500 байт; тод? оптимальний розм?р MSS буде 1460 байт?в (1500 м?нус 20 байт заголовка IP ? 20 байт заголовка TCP).
| Октет (Байт) | 0 | 1 | 2 | 3 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Б?т | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | |
| 0 | 0 | Порт джерела (Source port) | Порт призначення (Destination port) | ||||||||||||||||||||||||||||||
| 4 | 32 | Номер посл?довност? (Sequence number) | |||||||||||||||||||||||||||||||
| 8 | 64 | Номер п?дтвердження (Acknowledgment number) | |||||||||||||||||||||||||||||||
| 12 | 96 | Зм?щення даних (Data offset) | Зарезервовано (Reserved) 0 0 0 |
N S |
C W R |
E C E |
U R G |
A C K |
P S H |
R S T |
S Y N |
F I N |
Розм?р в?кна (Window Size) | ||||||||||||||||||||
| 16 | 128 | Контрольна сума (Checksum) | Показник важливост? (Urgent pointer) | ||||||||||||||||||||||||||||||
| 20 … 56 |
160 ... 448 |
Опц?? (Options) необов'язкове, розм?р залежно в?д значення поля ?Зм?щення даних? | |||||||||||||||||||||||||||||||
| 20+ … |
160+ … |
Дан? (Data) | |||||||||||||||||||||||||||||||
- 0 — 15 б?ти. Порт джерела (Source port) ?дентиф?ку? номер TCP-порту, з якого в?дправля?ться сегмент.
- 16 — 31 б?ти. Порт призначення (Destination port) ?дентиф?ку? номер TCP-порту, на який в?дправля?ться сегмент.
Див. також список номер?в TCP- та UDP-порт?в.
- 32 — 63 б?ти. Номер посл?довност? (Sequence number) ? числом, що в?добража? номер першого байту в сегмент? над?сланих даних в?д хоста-в?дправника до хоста-отримувача. Це число ? акумулювальним, тобто поточний номер посл?довност? ? сумою номера посл?довност? попереднього сегменту ? к?лькост? даних (в байтах) в?дправлених у ньому. Використову?ться для в?дстежування к?лькост? та правильно? посл?довност? отриманих сегмент?в даних.[10]
- 64 — 95 б?ти. Номер п?дтвердження (Acknowledgment number) фактично ? запитом в?д хоста отримувача на над?слання нового сегменту даних починаючи з? вказаного номера. З ?ншого боку, коли хост в?дправник отриму? це пов?домлення, в?н перекону?ться, що вс? сегменти даних з номерами посл?довност? меншими за номер п?дтвердження були усп?шно прийнят? отримувачем.
- 96 — 99 б?ти. Зм?щення даних[2] (Data offset) 4-б?тний номер, який визнача? розм?р TCP-заголовка в 32-б?тових словах. М?н?мальний розм?р становить 5 (0101) сл?в, а максимальний — 15 (1111), що ? в?дпов?дно 20 ? 60 байт. Фактично визнача? розм?р поля Опц?? (Options) в?д 0 до 40 байт.
- 100—102 б?ти, зарезервован? для майбутнього використання ? повинн? м?стити нул? (000).
Це поле м?стить б?тов? прапорц?, з яких ш?сть основних описан? в RFC 793[11] з 106 по 111 б?т, два прапорц? додан? до заголовка в RFC 3168, розм?щуються в 104 ? 105 б?тах заголовка, в 103 б?т? знаходиться експериментальний прапорець зг?дно з RFC 3540. Прапорц? вважа?ться встановленими, якщо ?х б?тове значення ? 1.
- 103 NS — Одноразова сума (Nonce Sum), використову?ться з метою покращення роботи механ?зму явного пов?домлення про перевантаження (Explicit Congestion Notification, ECN).
- 104 CWR — В?кно перевантаження зменшено (Congestion Window Reduced), прапорець встановлю?ться, щоб показати що TCP-сегмент був отриманий з? встановленим полем ECE, ?ншими словами це ? п?дтвердженням отримання сегменту даних з прапорцем ECE в?д хоста партнера.
- 105 ECE — ECN-Ехо (ECN-Echo), поле показу?, що в?дправник п?дтриму? ECN.
Основн?:
- 106 URG — Важлив?сть (Urgent), вказу?, що TCP-сегмент м?стить важлив? дан?. Коли до хоста-отримувача надходить сегмент з? встановленим прапорцем URG, TCP в?дправля? важлив? дан? з цього сегменту, як? знаходяться завдяки полю покажчик важливост? до в?дпов?дного протоколу верхнього р?вня минаючи чергу ? без перев?рки усп?шност? надходження попередн?х сегмент?в.[12]
- 107 ACK — П?дтвердження (Acknowledge) усп?шност? отримання TCP-сегменту
- 108 PSH — Просування (Push), також як ? прапорець URG, вказу?, на пр?оритетн?сть TCP-сегменту. Хост-в?дправник позачергово надсила? цей сегмент даних через IP-мережу. За аналог??ю з прапорцем URG, PSH ?нструкту? хост-отримувач, що сегмент даних ма? бути негайно переданий до прикладного р?вня (к?нцевого споживача даних).
- 109 RST — Обривання (Reset) вказу?, хосту-отримувачу негайно скинути з'?днання без подальшо? вза?мод??. Така ситуац?я наступа? у раз?, якщо сервер (хост-в?дправник) не нада? послуги визначеного серв?су. Наприклад кл??нт (хост-отримувач) запросив у вебсерверa послуги у формат? протоколу HTTPS (TCP-порт 443), але вебсервер нада? послуги лише у формат? HTTP (TCP-порт 80). Ця властив?сть TCP часто використову?ться хакерами для сканування порт?в мереж? жертви.
- 110 SYN — Синхрон?зац?я (Synchronize) використову?ться для встановлення з'?днання м?ж хостами при так званому триходовому рукостисканн?[en]
- 111 FIN — Ф?н?ш (Finish) вказу? на завершення з'?днання.
- 112—127 б?ти. Розм?р в?кна (англ. Window Size) визнача? к?льк?сть байт?в даних, як? в?дправник може над?слати до того, як отрима? п?дтвердження (запит на новий сегмент) в?д хоста-отримувача[13] На практиц? це означа?, що хост-в?дправник може надсилати певну к?льк?сть сегмент?в даних без отримання п?дтвердження в?д хоста-отримувача. Розм?р в?кна TCP вирахову? на основ? максимально? пропускно? здатност? (англ. bandwidth) л?н?? зв'язку м?ж хостами (фактично це ? пропускна здатн?сть в?др?зка шляху з ?? найг?ршим значенням) та загальн?й затримц? (часу потр?бному на доставку сегмента) на всьому шляху.
- 128—143 б?ти. Контрольна сума (Checksum) розрахову?ться на основ? усього TCP-сегменту включно ?з заголовком та важливих пол?в IP-пакета: IP-адрес хост?в в?дправника та отримувача, номера протоколу[en] (TCP ма? номер 6) та загального розм?ру IP-пакету. Контрольна сума забезпечу? можлив?сть перев?рки ц?л?сност? над?сланих даних.
- 144—159 б?ти. Покажчик важливост?[2] (Urgent pointer). Поле береться до уваги т?льки в раз? встановленого прапорця URG, та м?стить значення зм?щення в?дносно номера посл?довност? сегменту. Фактично це число вказу? на позиц?ю в TCP-сегмент? де зак?нчуються важлив? дан?.[14] Тобто важлив? дан? знаходяться одразу п?сля TCP-заголовка ? зак?нчуються перед м?сцем на яке вказу? покажчик важливост?.
- 160—479 б?ти. Опц?? (Options) необов'язкове поле, розм?р якого визнача?ться в залежност? в?д значення поля зм?щення даних та ? кратним 8 (одному байту). Кожна опц?я в свою чергу склада?ться з 3-х пол?в: Номер (kind)[15] — 1 байт, Довжина (length, вказу? на загальний розм?р опц?? в байтах) — 1 байт, Дан? (data) в залежност? в?д поля довжина. Опц?? використову?ться для обм?ну додаткових параметр?в м?ж хостами з метою покращення функц?онування протоколу TCP. Част?ше за все це поле включа? наступн? опц??[16]:
- MSS (Максимальний розм?р сегменту, Maximum segment size), RFC 793, номер — 2, довжина — 4.[17] Опц?я максимальний розм?р сегменту визнача? максимальний розм?р поля Дан? в TCP-сегмент? тобто к?льк?сть даних як? можуть бути пом?щен? в один сегмент при ?х передаванн? м?ж хостами.
- Масштабування в?кна (Window scale), RFC 7323, номер — 3, довжина — 3,[18] слугу? для зб?льшення значення TCP-в?кна, максимальне значення ц??? опц?? ? 14. Новий розм?р TCP-в?кна вирахову?ться по формул?: розм?р в?кна * 2n, де n ? значення опц?? масштабування в?кна. Стандартний максимальний розм?р в?кна в?добража?ться 16-ти б?товим числом, тобто може мати максимальне значення — 65535 (64 Кб), використовуючи опц?ю масштабування в?кна з максимально допустимим значенням 14, отриму?мо 65535 * 214 = 65535 * 16384 = 1073725440 (1 Гб). Велик? значення TCP-в?кна використовуються коли на шляху пакет?в ?з TCP-сегментами зустр?чаються WAN-л?нки з? значними максимальними пропускними здатностями (bandwidth) та великими затримками (latency).
- Виб?рков? п?дтвердження (Selective Acknowledgments, SACK), RFC 2018, номер — 2, довжина — в?д 4 байт — верхня межа вар?ю?ться,[19] як правило м?стить у соб? два 2-х байтних поля даних. Мета ?? введення ? покращення ефективност? роботи TCP, як в?домо TCP для передавання сегмент?в даних використову? протокол IP, який ? протоколом без встановлення з'?днання[en], тобто доправлення пакет?в з TCP-сегментами не ? гарантованим, допуска?ться, що частина IP-пакет?в може бути втрачена. В свою чергу TCP забезпечу? над?йне доправляння даних, що базу?ться на механ?зм? надсилання номер?в п?дтвердження (acknowledgment number). Якщо якийсь сегмент в?д в?дправника до отримувача не над?йшов у встановлений час то ?н?ц?ю?ться повторне передавання починаючи з? втраченого сегменту, нав?ть якщо TCP-сегменти з номерами посл?довност? б?льшими за номер втраченого сегменту були усп?шно отриман?. Механ?зм виб?ркового п?дтвердження дозволя? ретранслювати лише втрачен? сегменти даних, чим сутт?во покращу? ефективн?сть роботи TCP.
- М?тки часу (Timestamps), RFC 7323, номер — 8, довжина — 10,[20] м?стить у соб? два 4-х байтних поля Значення м?тки часу (Timestamp Value) та Ехо-в?дпов?дь м?тки часу (Timestamp Echo Reply).[21] Як правило хости обм?нюються значеннями м?ток часу на етап? встановлення з'?днання. За допомогою м?ток часу TCP визнача? ск?льки потр?бно часу на доправлення сегмент?в м?ж хостами. На основ? цих значень встановлюються TCP-таймери в?дпов?дальн? на сторон? хоста-в?дправника за повторне передавання даних, якщо п?дтвердження отримання не над?йшло у встановлений час, а у раз? використання опц?? виб?ркового п?дтвердження хост-отримувач самост?йно ?н?ц?ю? запит на повторне пересилання конкретного сегменту даних.
Якщо деякий прост?р поля Опц?? лиша?ться незаповненим то в?н заповню?ться спец?альною опц??ю NOP (No-Operation, н?чого не робити), RFC 793, номер — 1, довжина — в?дсутня.[22]
Поняття порт (port) ? ключовим у протокол? TCP. Порт з точки зору операц?йних систем назива?ться сокетом (socket) процесу. ?ншими словами це програмний ?нтерфейс для забезпечення обм?ну даними м?ж процесами.
Для розум?ння поняття порту з точки зору комп'ютерних мереж легко провести аналог?ю з роботою звичайно? пошти. Коли ви в?дправля?те листа, то заповню?те поля Куди: адреса будинку ? Кому: людина, яка прожива? у цьому будинку. У мереж? ?нтернет на питання Куди: в?дпов?да? IP-протокол, тобто це ? IP-адреса хоста, а на питання Кому: в?дпов?да? TCP-протокол (або ?нший протокол транспортного р?вня), тобто це номер протоколу прикладного р?вня (процес, що в?дпов?да? за цей протокол з точки зору операц?йно? системи), який ?мешка?? за вказаною IP-адресою хоста. За аналог??ю з? звичайною поштою ви можете направити 2-а листа 2-м р?зним людям, як? живуть в одному будинку, в ?нтернет? ви можете направити TCP-сегменти 2-м р?зним протоколам прикладного р?вня за одн??ю ? т??ю ж самою IP-адресою. Звичайно треба заповнити ? зворотню адресу.
В ?нтернет? широко вжива?ться форма запису : ip-адреса: порт.
Команда netstat -n може показати наступне:
192.168.1.31:54132 198.35.26.96:443 192.168.1.31:54138 198.35.26.96:22
Тобто якийсь хост з локально? мереж? (використову? приватну IP-адресу) ма? одночасно з'?днання з сервером в глобальн?й мереж? ?нтернет з ip-адресою 198.35.26.96 [Арх?вовано 18 вересня 2016 у Wayback Machine.] по портам 443 (протокол HTTPS) та 22 (протокол SSH).
За надання ? використання порт?в в?дпов?дальна IANA[23], хоча на практиц? на в?дм?ну в?д використання IP-адрес це правило не завжди дотриму?ться. Наприклад н?чого не заважа? адм?н?страторам 2-х хост?в домовитися передавати, якийсь тип IP-траф?ку по порту 80, який ? закр?плений за протоколом http ? ? в?дкритим на б?льшост? файрвол?в.
TCP-заголовок ма? 16-б?тов? поля порт джерела та порт призначення, як? можуть приймати значення в?д 0 до 65535.
Порти под?ляються на категор??:
- Загальнов?дом? (well-known), д?апазон номер?в 0 — 1023.[24] Як правило це порти, як? використовують протоколи прикладного р?вня TCP/IP стеку затверджен? IETF, зг?дно з принципами в?дкритого стандарту. Наприклад: HTTP порт ?80, HTTPS — 443, SMTP — 25, Telnet — 23, SSH — 22.
- Заре?строван? (registered), д?апазон номер?в 1024 — 49151. За задумом, ц? порти призначаються для протокол?в р?зних виробник?в програмного забезпечення, як? мають ?х заре?струвати в IANA. Наприклад ?гровий серв?с Xbox Live використову? заре?стрований порт 3074.[25] На практиц? багато порт?в у цьому д?апазон? використовуються без оф?ц?йно? ре?страц??.
- Динам?чн? (приватн?, ефемерн?, dynamic, private, ephemeral), д?апазон номер?в 49152-65535. IANA не ре?стру? ц? порти. Використовуються, як правило хостами-кл??нтами, для встановлення TCP-з'?днань з хостами-серверами. Як у приклад? вище, коли кл??нт з IP-адресою 192.168.1.31 встановив 2 з'?днання з? сервером 198.35.26.96, на сторон? кл??нта використовуються динам?чн? порти 54132 та 54138, а на сторон? сервера загальнов?дом? порти 443 (протокол HTTPS) та 22 (протокол SSH).
Завданням протоколу, як виплива? з його назви (?протокол керування пересиланням?), ? контроль над?йного передавання даних м?ж хостами, для забезпечення цього м?ж хостами встановлю?ться лог?чне з'?днання[en], яке зветься TCP-сес??ю.[26] Протокол TCP працю? у формат? арх?тектури кл??нт-сервер. Хост який надсила? запит на отримання серв?су ? кл??нтом, той хто в?дпов?да? на запит зветься сервером. Хости зв'язуються один з одним за TCP-портами, на сторон? кл??нта це, як правило, динам?чний порт, а на сторон? сервера це загальнов?домий або заре?стрований порт, номер якого в?дпов?да? протоколу прикладного р?вня. Номери порт?в та значення ?нших параметр?в заносяться до заголовка TCP-сегменту.
Тут п?д терм?ном сервер (server) розум?ють комп'ютер п?д управл?нням операц?йно? системи, який ма? доступ до IP-мереж? та нада? послуги одного чи дек?лькох серв?с?в прикладного р?вня. В свою чергу на сервер?-комп'ютер? встановлен? спец?альн? сервер-програми, як? забезпечують роботу протокол?в прикладного р?вня. Таким чином, якщо це вебсервер, то на ньому мусить бути встановлена одна ?з таких програм, як наприклад: Apache HTTP Server. На практиц? сервер-комп'ютер нада? послуги в?дзразу дек?лькох серв?с?в, тобто на ньому може бути встановлено б?льше одн??? сервер-програми, що забезпечують роботу дек?лькох протокол?в прикладного р?вня. Наприклад сервер-комп'ютер може бути одночасно вебсервером ? FTP-сервером та забезпечувати роботу протокол?в HTTP, HTTPS та FTP.
Важливо розум?ти, що протягом TCP-сес?? дан? надсилаються в обох напрямках, як в?д сервера до кл??нта так ? в?д кл??нта до сервера, тобто створюються два потоки даних. Причому не завжди б?льший пот?к даних пряму? в?д сервера до кл??нта.
Кожна окрема сес?я роботи протоколу ТСР може бути под?лена на три фази:
- Встановлення з'?днання
- Передавання даних
- Зак?нчення з'?днання
Необх?дною умовою для встановлення ТСР-сес?? ? в?дкритий доступ до програмного сокету процесу на сервер?, що в?дпов?да? за роботу протоколу прикладного р?вня, який мовою ТСР зветься портом. За тако? умови стан ТСР-сес?? на сторон? сервера ? LISTEN (слухати).[27] Тобто сервер слуха?, якийсь конкретний TCP-порт ? оч?ку? отримати запит в?д кл??нта на надання послуг, що в?дпов?дають номеру цього порту. Початковий стан ТСР-сес?? на сторон? кл??нта ? CLOSED.
Для встановлення з'?днання протокол TCP використову? триходове (рукостискання[en]), назване так за к?льк?стю пов?домлень м?ж хостами:
- Кл??нт форму? TCP-заголовок: у поле порт джерела заносить св?й номер TCP-порта, як правило динам?чний, у поле порт призначення номер порту протоколу прикладного р?вня, послуги якого хоче отримати, в поле номер посл?довност? сегменту дов?льне значення та встановлю? прапорець SYN. Сформований таким чином TCP-сегмент в?дправля?ться серверу. ТСР-сес?я на сторон? кл??нта переходить у стан SYN-SENT.
- Сервер отриму? ТСР-сегмент в?д кл??нта з? встановленим прапорцем SYN та у в?дпов?дь форму? TCP-заголовок: у поле порт джерела заносить св?й номер TCP-порта, у поле порт призначення номер порту кл??нта. Дода? до отриманого в?д кл??нта номера посл?довност? сегменту 1 ? пом?ща? отримане число до номеру п?дтвердження, вносить св?й власний початковий номер посл?довност? сегменту та в?дправля? сегмент до кл??нта з прапорцями SYN та ACK. ТСР-сес?я на сторон? сервера переходить у стан SYN-RECEIVED.
- П?сля отримання ТСР-сегмента з? встановленими прапорцями ACK та SYN кл??нт переходить у стан ESTABLISHED та в?дпов?да? на запит сервера про синхрон?зац?ю шляхом додавання 1 до номера отримано? посл?довност? сегменту та пом?ща? це число до номера п?дтвердження. Дал? кл??нт надсила? таким чином сформований сегмент до сервера з прапорцем ACK
П?сля отримання сервером ТСР-сегмента з прапорцем ACK стан ТСР-сес?? на його сторон? ста? також ESTABLISHED, разом з чим розпочина?ться передавання даних.
Також на етап? встановлення з'?днання м?ж хостами, як правило в?дбува?ться обм?н опц?ями, тобто TCP-параметрами, як? впливають на ефективн?сть передавання даних.
?н?ц?атором зак?нчення з'?днання може бути, як кл??нт так ? сервер.[28] Для зак?нчення TCP-сес?? використову?ться так зване чотириходове рукостискання (four-way handshake).
- ?н?ц?атор роз?рвання з'?днання направля? сво?му партнеру TCP-сегмент з? встановленим прапорцем FIN. TCP-сес?я ?н?ц?атора переходить з? стану ESTABLISHED у стан FIN-WAIT-1
- Хост-отримувач прийма? FIN в?д ?н?ц?атора та посила? у в?дпов?дь TCP-сегмент з? встановленим прапорцем АСК. TCP-сес?я отримувача переходить з? стану ESTABLISHED у стан CLOSE-WAIT. З набуттям хостом цього стану TCP припиня? отримувати нов? запити, на передавання даних, в?д в?дпов?дного протоколу верхнього р?вня та встановлю? таймер на завершення попередн?х запит?в. ?н?ц?атор отриму? АСК та переходить у стан FIN-WAIT-2.
- П?сля зак?нчення оброблення вс?х запит?в протокол?в верхнього р?вня хост-отримувач переходить у стан LAST-ACK та в?дправля? ?н?ц?атору TCP-сегмент з? встановленим прапорцем FIN.
- ?н?ц?атор прийма? FIN в?д отримувача та посила? у в?дпов?дь TCP-сегмент з? встановленим прапорцем АСК. Отримувач прийма? АСК та переходить у стан CLOSED.
?н?ц?атор роз?рвання з'?днання чека? протягом подв?йного часу в?д MSL[en] (максимального життя сегмента, maximum segment lifetime), щоб переконатися, що посланий ACK був отриманий та також переходить у стан CLOSED.
- RFC 793 — Transmission Control Protocol
- Специф?кац?я протоколу TCP [Арх?вовано 22 жовтня 2007 у Wayback Machine.](рос.)
- Douglas E. Comer. Internetworking with TCP/IP, Vol. 1: Principles, Protocols and Architecture
- Дуглас Камер. Сети TCP/IP, том 1. Принципы, протоколы и структура. М. ?Вильямс? 2003, ISBN 0-13-018380-6,
- ↑ TCP/IP Overview — Cisco. Арх?в ориг?налу за 23 жовтня 2015. Процитовано 30 жовтня 2015.
- ↑ а б в Лекц?я № 10. Протокол транспортного р?вня. Арх?в ориг?налу за 11 вересня 2016. Процитовано 30 жовтня 2015.
- ↑ IP Application Services Configuration Guide, Cisco IOS XE Release 3S — Configuring TCP [Cisco IOS XE 3S] — Cisco. Арх?в ориг?налу за 29 жовтня 2015. Процитовано 23 жовтня 2015.
- ↑ What is ARPANET? The First Internet. Арх?в ориг?налу за 27 жовтня 2018. Процитовано 26 лютого 2016.
- ↑ apf — Vinton G. Cerf, Robert E. Kahn, (May 1974). ?A Protocol for Packet Network Intercommunication? (PDF). IEEE Transactions on Communications 22 (5): 637—648. doi:10.1109/tcom.1974.1092259 (PDF). Арх?в ориг?налу (PDF) за 23 липня 2015. Процитовано 23 липня 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ CCENT: Cisco Certified Entry Networking Technician Study Guide: ICND1 (Exam … — Todd Lammle — Google Books. Арх?в ориг?налу за 23 листопада 2015. Процитовано 22 листопада 2015.
- ↑ Checking your TCP Packets are pulling their weight (TCP Max Segment Size or MSS) — On The Wire — Site Home — TechNet Blogs. Арх?в ориг?налу за 22 грудня 2015. Процитовано 18 грудня 2015.
- ↑ F2R001A TCP. Арх?в ориг?налу за 22 грудня 2015. Процитовано 18 грудня 2015.
- ↑ The TCP/IP Guide — TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size. Арх?в ориг?налу за 20 жовтня 2020. Процитовано 17 грудня 2015.
- ↑ Understanding TCP Sequence and Acknowledgment Numbers — PacketLife.net. Арх?в ориг?налу за 26 жовтня 2015. Процитовано 19 жовтня 2015.
- ↑ Security Configuration Guide: Access Control Lists, Cisco IOS Release 15E — Creating an IP Access List to Filter TCP Flags [Cisco IOS 15.2E] — Cisco. Арх?в ориг?налу за 16 жовтня 2015. Процитовано 21 жовтня 2015.
- ↑ TCP Flag Options — Section 4. Арх?в ориг?налу за 8 листопада 2015. Процитовано 7 листопада 2015.
- ↑ TCP, Transmission Control Protocol. Арх?в ориг?налу за 14 листопада 2015. Процитовано 5 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP Window Size, Checksum & Urgent Pointer — Section 5. Арх?в ориг?налу за 10 листопада 2015. Процитовано 7 листопада 2015.
- ↑ Transmission Control Protocol (TCP) Parameters. Арх?в ориг?налу за 9 листопада 2015. Процитовано 17 листопада 2015.
- ↑ Analysing TCP Header Options — Section 6. Арх?в ориг?налу за 17 листопада 2015. Процитовано 12 листопада 2015.
- ↑ TCP option 2, Maximum Segment Size. Арх?в ориг?налу за 24 березня 2016. Процитовано 17 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP option 3, Window Scale. Арх?в ориг?налу за 27 листопада 2015. Процитовано 17 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP option 5, Selective Acknowledgment. Арх?в ориг?налу за 4 березня 2016. Процитовано 17 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP option 8, Timestamp. Арх?в ориг?налу за 9 листопада 2015. Процитовано 16 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP option 8, Timestamp. Арх?в ориг?налу за 9 листопада 2015. Процитовано 16 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ TCP option 1, No operation. Арх?в ориг?налу за 4 березня 2016. Процитовано 18 листопада 2015. [Арх?вовано 2025-08-06 у Wayback Machine.]
- ↑ Service Name and Transport Protocol Port Number Registry. The Internet Assigned Numbers Authority (IANA). Арх?в ориг?налу за 28 грудня 2017. Процитовано 9 листопада 2015.
- ↑ RFC 6335 — Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Transport Protocol Port Number and Service Name Registry. Арх?в ориг?налу за 7 кв?тня 2019. Процитовано 10 листопада 2015.
- ↑ Xbox 360 Network Ports and Router Configurations for Xbox Live. Арх?в ориг?налу за 12 листопада 2015. Процитовано 10 листопада 2015.
- ↑ IP Application Services Configuration Guide, Cisco IOS XE Release 3S — Configuring TCP [Cisco IOS XE 3S] — Cisco. Арх?в ориг?налу за 29 жовтня 2015. Процитовано 23 жовтня 2015.
- ↑ The TCP/IP Guide — TCP Connection Establishment Process: The ?Three-Way Handshake?. Арх?в ориг?налу за 20 листопада 2015. Процитовано 19 листопада 2015.
- ↑ The TCP/IP Guide — TCP Connection Termination. Арх?в ориг?налу за 6 грудня 2015. Процитовано 22 грудня 2015.
