Відмінності між версіями «TCP»
Hiss (обговорення • внесок) |
Стойка (обговорення • внесок) |
||
| (не показані 15 проміжних версій 3 учасників) | |||
| Рядок 1: | Рядок 1: | ||
Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача. | Протокол '''TCP''' (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача. | ||
| − | Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші | + | Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервіси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів. |
| − | Термін "заснований на з'єднанні" (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від | + | Термін "заснований на з'єднанні" (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від віддаленого абонента, коли він говорить "алло", після чого необхідно сказати, хто дзвонить. |
TCP забезпечує свою надійність завдяки наступному: | TCP забезпечує свою надійність завдяки наступному: | ||
| − | + | <ul> | |
| − | + | <li>Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment).</li> | |
| − | + | <li>Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з віддаленого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно.</li> | |
| − | + | <li>Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.</li> | |
| − | + | <li>TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.)</li> | |
| − | + | <li>Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку.</li> | |
| − | + | <li>Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані.</li> | |
| − | + | <li>TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити їх у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.</li> | |
| + | </ul> | ||
Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. | Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці. | ||
| Рядок 20: | Рядок 21: | ||
Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. | Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP. | ||
| − | Формат TCP заголовка | + | [http://www.asmodeus.com.ua/library/net/tcpip2/tcp17.htm Формат TCP заголовка] |
<center>[[Image:TCP1.jpg]]</center> | <center>[[Image:TCP1.jpg]]</center> | ||
| Рядок 26: | Рядок 27: | ||
Відзначимо, що кожна мітка вказує тут місце для відповідного біта. | Відзначимо, що кожна мітка вказує тут місце для відповідного біта. | ||
| − | Source Port (порт відправника) 16 біт | + | ''Source Port'' (порт відправника) 16 біт |
номер порту відправника | номер порту відправника | ||
| − | Destination Port (порт одержувача) 16 біт | + | ''Destination Port'' (порт одержувача) 16 біт |
номер порту одержувача | номер порту одержувача | ||
| − | Sequence Number (номер черги) 32 біта | + | ''Sequence Number'' (номер черги) 32 біта |
Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. | Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1. | ||
| − | Acknowledgment Number (номер підтвердження) 32 біта | + | ''Acknowledgment Number'' (номер підтвердження) 32 біта |
Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. | Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено. | ||
| − | Data Offset (зсув даних) 4 біти | + | ''Data Offset (зсув даних)'' 4 біти |
Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. | Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції. | ||
| − | Reserved 6 біт | + | ''Reserved 6 біт'' |
Це резервне поле, повинне бути заповнено нулями. | Це резервне поле, повинне бути заповнено нулями. | ||
| − | Control Bits (контрольні біти) 6 біт | + | ''Control Bits'' (контрольні біти) 6 біт |
Біти цього поля зліва неправо | Біти цього поля зліва неправо | ||
| + | URG: поле термінового покажчика задіяне | ||
| + | ACK: поле підтвердження задіяне | ||
| + | PSH: функція проштовхування | ||
| + | RST: перезавантаження даного з'єднання | ||
| + | SYN: синхронізація номерів черги | ||
| + | FIN: немає більше даних для передачі | ||
| + | |||
| + | ''Window (вікно)'' 16 біт | ||
| + | Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента. | ||
| + | |||
| + | ''Checksum'' (контрольна сума) 16 біт | ||
| + | Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями. | ||
| + | |||
| + | Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP. | ||
| + | |||
| + | <center>[[Image:TCP2.jpg]]</center> | ||
| + | |||
| + | Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується. | ||
| + | |||
| + | Urgent Pointer (терміновий покажчик) 16 біт | ||
| + | Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG. | ||
| + | |||
| + | Options (опції) довжина змінної | ||
| + | Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми. | ||
| + | |||
| + | Опції можуть починатися з будь-якого октету. Вони можуть мати два формати: | ||
| + | - однооктетний тип опцій; | ||
| + | - октет типу опції, октет довжини опції й октети даних розглянутої опції. | ||
| + | |||
| + | В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними. | ||
| + | |||
| + | Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією "End-of-Option", повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції. | ||
| + | |||
| + | В даний час визначені наступні опції: | ||
| + | |||
| + | Тип Довжина Значення | ||
| + | |||
| + | 0 - кінець списку опцій | ||
| + | |||
| + | 1 - немає операцій | ||
| + | |||
| + | 2 4 максимальний розмір сегмента | ||
| + | |||
| + | |||
| + | Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1, http://mirror.bsdblog.org.ua/BSDA-Course/apbs01.html | ||
| + | |||
| + | [[TCP/IP]] | ||
[[category:Комп'ютерні мережі]] | [[category:Комп'ютерні мережі]] | ||
Поточна версія на 12:59, 5 травня 2009
Протокол TCP (Transmission Соntrоl Рrоtосоl - протокол керування передачею ) - протокол керування передачею даних, що використовує автоматичну повторну передачу пакетів, що містять помилки. Протокол TCP відповідає за розбивку переданої інформації на пакети і правильне відновлення інформації з пакетів одержувача.
Незважаючи на те, що TCP і UDP використовують той самий мережний рівень (IP), TCP надає додаткам абсолютно інші сервіси, ніж UDP. TCP надає заснований на з'єднанні надійний сервіс потоку байтів.
Термін "заснований на з'єднанні" (connection-oriented) означає, що два додатки, що використовують TCP (як правило, це клієнт і сервер), повинні установити TCP з'єднання один з одним, після чого в них з'являється можливість обмінюватися даними. Типова аналогія - це набір телефонного номера, чекання відповіді від віддаленого абонента, коли він говорить "алло", після чого необхідно сказати, хто дзвонить.
TCP забезпечує свою надійність завдяки наступному:
- Дані від додатка розбиваються на блоки визначеного розміру, що будуть відправлені. Це цілком відрізняється від UDP, у якому кожен запис, що здійснює додаток, генерує IP датаграму цього розміру. Блок інформації, що передається від TCP у IP, називається сегментом (segment).
- Коли TCP посилає сегмент, він установлює таймер, очікуючи, що з віддаленого кінця прийде підтвердження на цей сегмент. Якщо підтвердження не отримане після закінчення часу, сегмент передається повторно.
- Коли TCP приймає дані від віддаленої сторони з'єднання, він відправляє підтвердження. Це підтвердження не відправляється негайно, а звичайно затримується на долі секунди.
- TCP здійснює розрахунок контрольної суми для свого заголовка і даних. Це контрольна сума, що розраховується на кінцях з'єднання, метою якої є виявити будь-яку зміну даних у процесі передачі. Якщо сегмент прибуває з невірною контрольною сумою, TCP відкидає його і підтвердження не генерується. (Очікується, що відправник відробить тайм-аут і здійснить повторну передачу.)
- Через те що TCP сегменти передаються у вигляді IP датаграм, а IP датаграми можуть прибувати безладно, також безладно можуть прибувати і TCP сегменти. Після одержання даних TCP може по необхідності змінити їхню послідовність, у результаті додаток одержує дані в правильному порядку.
- Через те що IP датаграма може бути продубльована, що TCP, який приймає, повинен відкидати продубльовані дані.
- TCP здійснює контроль потоку даних. Кожна сторона TCP з'єднання має визначений простір буфера. TCP на приймаючій стороні дозволяє вилученій стороні посилати дані тільки в тому випадку, якщо одержувач може помістити їх у буфер. Це запобігає переповненню буферів повільних хостів швидкими хостами.
Між двома додатками по TCP з'єднання здійснюється обмін потоком 8-бітових байтів. Автоматично TCP не вставляє запису маркерів. Це називається сервісом потоку байтів (byte stream service). Якщо додаток на одному кінці записав спочатку 10 байт, потім 20 байт і потім ще 50 байт, додаток на іншому кінці з'єднання не може сказати якого розміру був кожен запис. На іншому кінці ці 80 байт можуть бути лічені, наприклад, за 4 рази по 20 байт за щораз. Один кінець з'єднання поміщає потік байт у TCP, і точно так само ідентичний потік байт з'являється на іншому кінці.
TCP не інтерпретує вміст байтів. TCP поняття не має про те, чи відбувається обмін двійковими даними, ASCII символами, EBCDIC символами або чим-небудь ще. Ця інтерпретація потоку байтів здійснюється додатками на кожній стороні з'єднання.
Передача TCP сегментів здійснюється у вигляді Internet датаграм. Заголовок датаграми в Internet протоколі має кілька інформаційних полів, включаючи адреси хост- комп'ютерів, що відправляють і приймають. Заголовок TCP слідує за Internet заголовком і доповнює його інформацією, специфічною для TCP протоколу. Такий розподіл допускає використання на рівні хост-комп’ютерів протоколів, інших ніж TCP.
Відзначимо, що кожна мітка вказує тут місце для відповідного біта.
Source Port (порт відправника) 16 біт номер порту відправника
Destination Port (порт одержувача) 16 біт номер порту одержувача
Sequence Number (номер черги) 32 біта Номер черги для першого октету даних у даному сегменті (за винятком тих випадків, коли є присутнім прапор синхронізації SYN). Якщо ж прапор SYN є присутнім, то номер черги є ініціалізаційним (ISN), а номер першого октету даних - ISN+1.
Acknowledgment Number (номер підтвердження) 32 біта Якщо встановлено контрольний біт ACK, то це поле містить наступний номер черги, що відправник даної датаграми бажає одержати в зворотному напрямку. Номераи підтвердження посилаються постійно, як тільки з'єднання буде установлено.
Data Offset (зсув даних) 4 біти Кількість 32-бітних слів у TCP заголовку. Указує на початок поля даних. TCP заголовок завжди кінчається на 32-бітній границі слова, навіть якщо він містить опції.
Reserved 6 біт Це резервне поле, повинне бути заповнено нулями.
Control Bits (контрольні біти) 6 біт Біти цього поля зліва неправо
URG: поле термінового покажчика задіяне ACK: поле підтвердження задіяне PSH: функція проштовхування RST: перезавантаження даного з'єднання SYN: синхронізація номерів черги FIN: немає більше даних для передачі
Window (вікно) 16 біт Кількість октетів даних, починаючи з октету, чий номер зазначений у полі підтвердження. Кількість октетів, одержання яких чекає відправник дійсного сегмента.
Checksum (контрольна сума) 16 біт Поле контрольної суми - це 16-бітне доповнення суми всіх 16- бітних слів заголовка і тексту. Якщо сегмент містить у заголовку і тексті непарну кількість октетів, що підлягають обліку в контрольній сумі, останній октет буде доповнений нулями праворуч для того, щоб утворити для надання контрольній сумі 16-бітне слово. Виниклий при такому вирівнюванні октет не передається разом із сегментом по мережі. Перед обчисленням контрольної суми поле цієї суми заповнюється нулями.
Контрольна сума, крім усього іншого, враховує 96 біт псевдозаголовка, що для внутрішнього вживання ставиться перед TCP заголовком. Цей псевдозаголовок містить адресу відправника, адресу одержувача, протокол і довжину TCP сегмента. Такий підхід забезпечує захист протоколу TCP від помилившихся в маршруті сегментів. Цю інформацію обробляє Internet протокол. Вона передається через інтерфейс протокол TCP/локальна мережа як аргументи або результати запитів від протоколу TCP до протоколу IP.
Довжина TCP сегмента - це довжина TCP заголовка і поля даних, вимірювана в октетах. Це не є точною вказівкою кількості переданих по мережі октетів, вона не враховує 12 октетів псевдозаголовку, проте розрахунок цього параметра усе-таки виконується.
Urgent Pointer (терміновий покажчик) 16 біт Це поле повідомляє поточне значення термінового покажчика. Останній є позитивною величиною - зсувом щодо номера черги даного сегмента. Терміновий покажчик повідомляє номер черги для октету, що випливає за терміновими даними. Це поле інтерпретується тільки в тому випадку, коли в сегменті виставлений контрольний біт URG.
Options (опції) довжина змінної Опції можуть розташовуватися наприкінці TCP заголовка, а їхня довжина кратна 8 біт. Всі опції враховуються при розрахунку контрольної суми.
Опції можуть починатися з будь-якого октету. Вони можуть мати два формати: - однооктетний тип опцій; - октет типу опції, октет довжини опції й октети даних розглянутої опції.
В октеті довжини опції враховуються октет типу опції, сам октет довжини, а також всі октети з даними.
Відмітимо, що список опцій може виявитися коротше, ніж можна вказати в полі Data Offset. Місце в заголовку, що залишається за опцією "End-of-Option", повинне бути заповнено нулями. Протокол TCP повинний бути готовий обробляти всі опції.
В даний час визначені наступні опції:
Тип Довжина Значення
0 - кінець списку опцій
1 - немає операцій
2 4 максимальний розмір сегмента
Докладныше дивись на http://www.citforum.ru/internet/tifamily/tcpspec.shtml#3.1, http://mirror.bsdblog.org.ua/BSDA-Course/apbs01.html
