Відмінності між версіями «TCP»

Матеріал з Вікі ЦДУ
Перейти до: навігація, пошук
Рядок 46: Рядок 46:
 
Control Bits (контрольні біти) 6 біт
 
Control Bits (контрольні біти) 6 біт
 
Біти цього поля зліва неправо
 
Біти цього поля зліва неправо
 +
    URG: поле термінового покажчика задіяне
 +
    ACK: поле підтвердження задіяне
 +
    PSH: функція проштовхування
 +
    RST: перезавантаження даного з'єднання
 +
    SYN: синхронізація номерів черги
 +
    FIN: немає більше даних для передачі
  
  
 
[[category:Комп'ютерні мережі]]
 
[[category:Комп'ютерні мережі]]

Версія за 22:16, 7 грудня 2008

Протокол 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.

Формат TCP заголовка

TCP1.jpg

Відзначимо, що кожна мітка вказує тут місце для відповідного біта.

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: 	немає більше даних для передачі