Transmission Control Protocol (ТСР) е еден од основните протоколи на ТСР/ IP. ТСР обезбедува сигурна, точна и подредена достава на проток на октети, од програмата на еден компјутер на друг. Тој е протокол кој се користи од страна на прелистувачите на мрежни места на World Wide Web, електронска пошта, далечинска администрација и пренос на податотеки. Други апликации, кои не бараат сигурна услуга за пренос на податоци, може да го користат User Datagram Protocol (UDP), кој обезбедува датаграм услуги кои ја нагласуваат намалената латенција над сигурност.

Потекло
-------

Во мај 1974 година на Институтот за електро инженери и инженери по електроника (IEEE) објави труд под наслов "A Protocol for Packet Network Intercommunication". Авторите Vint Cerf и Bob Kahn, опишаа меѓумрежен протокол за споделување на ресурси со користење на пакетно преклопување (packet-switching) меѓу јазли. Централна контролна компонента на овој модел е *Програмата за контрола на трансмисија (Transmission Control Program)* која инкорпорира и конекциски ориетирани линкови и датаграм услуги помеѓу домаќините. Монолитната Програма за контрола на трансмисија подоцна беше поделена во модуларна архитектура, која се состои од *Протоколот за контрола на пренос* кој работи на конекциски ориентираниот слој и *Интернет протокол* кој работи на меѓумрежниот/датаграм (internetworking) слој. Моделот стана познат неофицијално како TCP/IP, иако формално беше наречен Пакет на Интернет протоколи (Internet Protocol Suite).

Мрежна фунција
--------------

Протоколот одговара на транспортниот слој на TCP/IP пакетот. TCP обезбедува комуникациски услуги на средно ниво меѓу апликациската програма и Интернет Протоколот (IP). Кога некоја апликациска програма сака да испрати големо парче на податоци преку интернет користејќи IP, наместо делење на податоците во IP делови и издавање на серија на IP барања, софтверот може да издаде едно барање на TCP и TCP да справи со IP деталите.

IP работи со размена на делови од информација наречени пакети. Пакет е низа од октети и се состои од наслов (header) проследено со тело (body). Насловот ја опишува одредиште на пакет и по можност, насочувачите кои се користат за пренасочување на пекетот сè додека не пристигне до неговото одредиште. Телото ги содржи податоците кои IP ги емитува.

Поради преоптоварување во мрежата, сообраќајот се балансира(Load Balancing), или се случуваат некои други непредвидливи однесувања на мрежата, IP пакетите може да бидат изгубени, да бидат дуплицирани или испорачани вон редслед. TCP ги детектира овие проблеми, може да побара и реемитување на изгубени податоци, ги преуредува измешаните пакети па дури и помага да се минимизира метежот во мрежата и да се намали појавата на други проблеми. Откако TCP на страната на примачот ќе ги состави октетите по точен редослед ги предава а апликациите на погорно ниво. Така, TCP ја абстрахира комуникацијата на апликацијата со детали на подолните мрежни нивоа.

TCP е оптимизиран за точна испорака наместо навремена испорака и затоа со TCP понекогаш настануваат релативно долги закаснувања(од ранг на секунди), додека се чекаат неподредените или изгубените пораки. TCP не е погоден за апликации кои работат во реално време како што се Voice over IP. За таквите апликации се препорачани протоколи како RTP (Real-time Transport Protocol) кој работи врз UDP.

TCP е сервис за надежна испорака кој гарантира дека сите пристигнати бајти ќе бидат идентични со бајтите испратени и во правилен редослед. Бидејќи трансферот на пакети не е сигурен, техника позната како позитивна потврда со реемитување(acknowledgment with retransmission) се користи за да се гарантира сигурноста на трансферот. Оваа фундаментална техника бара примачот да одговори со потврдна порака како што добива податоци. Испраќачот чува (record) евиденција за секој пакет што се испраќа. Испраќачот, исто така, има тајмер кој мери кога пакет бил испратен и го препраќа пакетот ако тајмерот истече пред испораката да е потврдена. Тајмерот е потребен во случај да се добиваат изгубени или оштетени пакети.

TCP состои од множество правила: правила за протоколот за контрола на пренос, и правила за IP, за праќање на податоци "во форма на порака единици" помеѓу компјутерите на интернет. Додека IP справува со реалната испорака на податоци, TCP ги следи поединечните единици на пренос на податоци, наречени *сегменти*. Пораката која се праќа е поделена за ефикасно насочување преку мрежата. На пример, кога една HTML податотека се праќа од опслужувачот, софтверскиот TCP слој на тој опслужувач ја дели низата октети на податотеката во сегменти и ги предава на IP софтверскиот слој (интернет слој). Интернет слојот го енкапсулира секој сегмент во IP пакет со додавање на наслов (header) кој ја вклучува (меѓу другите податоци) дестинациската IP-адреса. Иако секој пакет има истата дестинациска адреса, тие може да се рутраат низ различни патеки на мрежата. Кога клиентската програма на дестинацискиот компјутер ги прима, TCP слојот (Transport Layer) ги спојува одделните сегменти и обезбедува тие се правилно да се подредат, без грешки, при што се пренесуваат на апликацијата.

Структура на TCP сегмент
------------------------

Протоколот за контрола на трансмисија ги прифаќа податоците од поток, ги сегментира, и со додавање на TCP заглавје ги создава TCP сегментите. Тогаш сегментите се енкапсулираат во пакети на Интернет Протоколот (IP пакети/датаграми). Еден TCP сегмент е „пакет од информации кои TCP ги користи за размена на податоци со другите нодови".
Терминот *TCP пакет*, иако понекогаш е неформално користен, не е во согласност со прифатената терминологија. Прифатено е PDU-то (Податочна единица на протокол = Protocol Data Unit) на TCP да се нарекува сегмент, PDU на IP е датаграм, а на слојот за податочна врска се рамки.

Еден TCP сегмент се состои од заглавје на сегментот и дел за податоци. Заглавјето содржи 10 задолжителни полиња и опционално поле за екстензии. (Опции, со портокалова позадина во табелата).

TCP заглавје| *Отстапувања* | Октет | 0 | 1 | 2 | 3 |
| --- | --- | --- | --- | --- | --- |
| Октет | Bit |  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 | Изворна порта | Дестинациска порта |
| 4 | 32 | Број на низа |
| 8 | 64 | Број на потврда (ако ACK е поставено) |
| 12 | 96 | Податочно отстапување | Резервирано**0 0 0** | NS | CWR | ECE | URG | ACK | PSH | RST | SYN | FIN | Големина на прозорец |
| 16 | 128 | Контролен збир | Покажувач за ургентност (ако URG е поставено) |
| 20... | 160... | Опции (ако *податочното отстапување* (*offset*) > 5. Се дополнува на крајот со "0" ако е потребно.)... |

* Изворна порта (16 бита) - ја идентификува испраќачката порта
* Дестинациска порта (16 бита) - ја идетификува примачката порта
* Број на низа (32 бита) - има двојна улога
	+ Ако SYN знаменцето е поставено, тогаш ова е почетниот број на низа. низниот број на брвиот бајт и потврдениот број во соодведното ACK тогаш се овој низен број плус 1
	+ Ако SYN знаменцето е нула, тогаш ова е ова е акумулираниот низен број на првиот бајт од овој сегмент за моменталната сесија.
* Број на потврда (32 бита) - ако ACK знаменцето е поставено тогаш вредноста на ова поле е следниот број на низа што примачот го очекува. Ова го потврдува примањето на сите претходи бајти. Првиот ACK пратен од двете страни ја потврдува почетната низа на другиот, не потврдува праќање на податоци.
* Податочно отстапување (4 бита) - кажува колку е големо заглавјето во 32-битни зборови. Минималната големина е 5 збора, максимум е 15 што ја дава минималната големина од 20 бајти и максимум од 60 бајти, дозволувајќи 40 бајти простор за опции во заглавјето. Ова поле името го добива од фактот дека го претставува отстапувањето од почетокот на TCP сегментот до податоците во него.
* Резервирани (3 бита) - за идна потреба, треба да се нула
* Знаменца (9 бита) - познати и како контролни битови, содржи 9 едно битни знаменца
	+ NS - додаден во RFC 3540
	+ CWR - Congestion Window Reduced - се поставува ова знаменце од страна на испраќачот да индицира дека примил TCP сегмент со поставено ECE знаменце и одговорил на механизмот за контрола на загушувањето (додадено е во заглавјето во RFC 3168)
	+ ECE - ECN-Еcho покажува
		- Ако е поставенo SYN знаменцето, тогаш овој TCP соговорник има можност за експлицитно известување за загушување (Explicit Congestion Notification - ECN)
		- Ако не е поставено SYN тогаш бил добиен пакет кој во IP заглавјето имал поставен Congestion Experienced знаменце (било забележано загушување во ИП слојот) (додадено во заглавјето во RFC 3168).
	+ URG - покажува дека полето Urgent/Итно да се зема предвид
	+ ACK - покажува дека полето за Acknowledgement/Потврда се зема предвид. Сите сегменти по првичниот SYN сегмент мора да го имаат поставено ова знаменце
	+ PSH - Функција за пренесувње (Push), бара баферираните податоци да се пренесат на апликацијата која ги прима.
	+ RST - ја ресетира врската.
	+ SYN - синхронизирај ги броевите на низа. Само првите сегменти пратени од двата краја треба да го имаат поставено ова знаменце. Некои од останатите знаменца може да си го променат значењето во зависност од поставеноста на ова знаменце, некои се валидни само ако е ова поставено, некои само ако не е.
	+ FIN - нема повеќе податоци од испраќачот.
* Големина на прозорец (16 бита) - големината на примачкиот прозорец кој кажува колку бајти праќачот на овој сегмент е спремен да прими.
* Контролен збир (16 бита) - поле кое се користи за проверка на грешки во заглавјето и податоците.
* Покажувач за ургентност - ако е поставено URG знаменцео, тогаш ова поле е отстапувањаето од бројот на низата што покажува кој е последниот бајт кој е ургентен.
* Опции (Помеѓу 0 и 320 бита, број деллив со 32) - големината на ова поле е одредено од полето Податочно отпстапување. Опциите имат до 3 полиња: Тип на опција (1 бајт), Должина на опција (1 бајт), Податоци на опција (променливо).
* Дополнување (Padding) - Заглавјето на TCP мора да завршува на граница од 32 бита. Дополнувањето се состои од нули.

Протокол
--------

Поедноставен дијаграм на состојби за TCP. За подетален дијаграм кој ги содржи состојбите внатре во ESTABLISHED состојбата погледнете го TCP EFSM diagram.
Операциите на TCP протоколот може да се поделат на три фази. Врските мора да се прописно воспостават во процес на преговарање во повеќе чекори (handshake) што е фазата на *воспоставување врска* пред да се започне со фазата на *трансфер на податоци*. По преносот на податоци, настапува *терминирање на врската* со што се затвораат сите виртуелни кола и се ослободуваат алоцираните ресурси.

TCP врската е водена од оперативниот систем преку програмски интерфејс кој претставува локална крајна точка за комуникациите наречена сокет (Internet Socket). За време на една TCP врска локалната крајна точка преминува низ серија промени на состојба:

LISTEN(опслужувач) претставува чекање за барање за врска од било кој оддалечен TCP и порта.
SYN-SENT(клиент) претставува чекање на соодветно барање на врска имајќи пратено веќе барање на врска.
SYN-RECEIVED(опслужувач) претставува чекање на потврда за побараната врска откако двете страни побарале и испратиле барање за врска.
ESTABLISHED(опслужувач и клиент) отворена врска, податоците кои се примаат се предаваат на корисникот. Нормална состојба за фазата на пренос на податоци.
FIN-WAIT-1(опслужувач и клиент) чекање на барање за терминирање на врска од оддалечениот TCP, или потврда дека претходно било испратено барање за терминирање на врска.
FIN-WAIT-2(опслужувач и клиент) челање на барање за терминирање на врска од оддалечениот TCP.
CLOSE-WAIT(опслужувач и клиент) чекање за барање за терминирање на врска од локалниот корисник.
CLOSING(опслужувач и клиент) чекање за потврда за барање за затворање врска од оддалечениот TCP.
LAST-ACK(опслужувач и клиент) чекање на потврда за претходно пратено барање кон оддалечениот TCP (што вклучува потврда на неговото барање за терминирање на врска).
TIME-WAIT(или опслужувач или клиент) чекање да помине доволно време за да се осигура дека оддалечениот TCP ја примил потврдата за неговото барање за терминирање на врската [Според RFC 793 една врска може да остане во TIME-WAIT максимум 4 минути]
CLOSED(опслужувач и клиент) состојба каде нема никаква врска.
### Воспоставување врска

За да се воспостави врска, ТСР користи three-way handshake. Пред клиентот да се обиде да се поврзе со опслужувачот, опслужувачот мора прво да се врзе за порта и да ја слушне за да ја отвори за врска: ова се нарекува пасивно отворање. Откако ќе се воспостави пасивно отворање, клиентот може да бара активно отворање. За да се воспостави врска, three-way handshake се појавува:

1. **SYN**: Активното отворање се врши од страна на праќањето на SYN до опслужувачот од клиентот. Клиентот го поставува низниот број на сегментот на случајна вредност А.

2. **SYN-АСК**: Како одговор, опслужувачот одговара со SYN-АСК. Број за потврда е поставен на еден повеќе од примениот низни број (А+1), и низен број што го избира опслужувачот за пакетот е уште еден случаен број В.

3. **АСК**: Конечно, клиентот праќа назад АСК до опслужувачот. низниот број е поставен на добиениот број за потврда т.е А+1, и бројот за потврда е поставен на еден повеќе од примениот низниот број односно В+1.

Во овој момент, и клиентот и опслужувачот имаат добиено потврда за врска. Чекорите 1 и 2, воспоставуваат врска параметар (низен број) во еден правец и тоа се потврдува. Чекорите 2 и 3, воспоставуваат врска параметар (низен број) во другиот правец и тоа се потврдува. Со овие, се воспоставува full-duplex комуникација.

### Терминирање на врската

Терминирање на врска
Фазата на терминирање на врска користи ракување преку четири чекори и со секоја страна од врската раскинувањето независно. Кога крајна точка сака да прекине половина од врската, таа испраќа FIN пакет, кој на другиот крај потврдува со ACK. Затоа, типичното прекинување бара еден пар на FIN и ACK сегмент од двете крајни точки на TCP. Откако двете размени на FIN/ACK се заклучени, страната која ја испрати првата FIN чека за истек на време пред конечно да ја затвори врската, време за кое локалната порта е недостапна за нови врски, тоа спречува конфузија при испорака на задоцнети пакети да стигнат во текот на следните врски.

Врската може да биде "полуотворена", во кој случај едната страна ја прекинува врската од својот крај, но другата не. Страната што ја раскинала не може да испрати податоци во врската, но од друга страна може. Терминираната страна треба да го продолжи читањето на податоците додека другата страна побара раскинување.

Исто така е можно да се прекине врската со 3 чекори на ракување, кога домаќинот А испраќа FIN и домаќинот Б одговара со FIN и ACK (комбинира 2 чекори во еден) и домаќинот враќа со ACK. Ова е можеби најчестиот метод.

Можно е двата домаќини да испратат FIN истовремено тогаш и двата само треба да ACK. Ова веројатно би можело да се смета за ракување во 2 чекора бидејќи FIN/ACK низата е направена во паралела за двете насоки.

Некои TCP стакови на страна на домаќинот може да имплементираат полудуплекс низа на терминирање, како што прават Linux или HP-UX. Ако таков домаќин активно ја затвора врската, но сепак не ги прочитал сите влезни податоци кои стакот веќе ги добил од линкот, овој хост праќа RST наместо FIN (Секција 4.2.2.13 во RFC 1122). Ова им овозможува на TCP апликациите да бидат сигурни апликацијата од другата страна ги прочитала сите податоци пред тоа испратени - чекајќи на FIN од далечинската страна, кога е активно затворена врската. Сепак, далечинскиот TCP стак не може да прави разлика помеѓу *Прекинување на Врската RST* и оваа *Загубени податоци RST*. И двете причинуваат TCP стакот на апликацијата од другата страна да ги отфрли сите податоци што ги добил, но апликацијата не ги прочитала.

Некои апликациски протоколи може да го нарушат OSI моделот користејќи го ракувањето со TCP open/close во апликацискиот протокол. Ваквите апликации можат да се соочат со RST проблемот на затворање на активна врска. Како пример:

```
s = connect(remote);
send(s, data);
close(s);
```

Доколку програмскиот тек е како опишаниот погоре, TCP/IP стакот не гарантира дека сите податоци ќе се испорачаат на апликацијата од другата страна.

### Употреба на ресурси

Повеќето имплементации алоцираат влез во табела која мапира сесија до активен процес на оперативниот систем. Бидејќи TCP пакетите не вклучуваат идентификатор за сесија, двете крајни точки ја идентификуваат сесијата користејќи ја адресата на клиентот и портата. Секогаш кога еден пакет е примен, имплементација на TCP мора да изврши пребарување на оваа табела да се најде одредиштето на процесот.
Бројот на сесии во страна на опслужувачот е ограничен само од меморија и можат да расте како што пристигаат нови врски, но клиентот мора да алоцира број на порта на случаен начин пред испраќањето на првиот SYN пакет на опслужувачот. Оваа порта останува алоцирана во текот на целиот разговор, и ефикасно го ограничува бројот на излезни врски на секоја од IP-адресите на клиентот. Ако некоја апликација не успее правилно да ги затвори непотребните врски, клиентот може да снема ресурси и биде оневозможен да воспостави нови TCP врски, дури и од други апликации.
Двете крајни точки, исто така, мора да одвојат простор за непотврдени пакети и примени (но непрочитани) податоци.

### Пренос на податоци

Постојат неколку клучни одлики кои го разликуваат ТСР од UDP:

• Подреден пренос на податоци – дестинацискиот домаќин ги преуредува податоците по низниот број.

• Повторен праќање на изгубени пакети – било кој кумулативен прилив што не е потврден, се препраќа повторно.

• Пренос без грешки

• Контрола на проток – ја ограничува стапката на трансфер на податоци од испраќачот за да се гарантира сигурна достава. Примачот постојано му укажува на испраќачот за тоа колку податоци можат да бидат примени (контролирано од лизгачкиот прозорец). Кога баферот на примачот ќе се наполни, следната потврда содржи 0 во големина на прозоред, за да запре трансферот и да овозможи податоците во баферот да се обработат.

• Контрола на застој

Контрола на застој
------------------

Еден од главните аспекти на ТСР е контрола на застој. ТСР користи голем број на механизми за да постигне високи перформанси и да избегне застој, каде ефикасноста на мрежата може да се намали. Овие маханизми ја контролираат стапката на влез на податоци во мрежата, одржувајќи го протокот на податоци под стапката која ќе го предизвика застојот. Тие исто така, даваат приближно максимум-минимум фер распределба помеѓу тековите.

Потврди за испратените податоци, или недостаток на потврди, се користат од страна испраќачите да ги заклучат мрежните услови помеѓу ТСР испраќачот и примачот. Заедно со тајмерите, ТСР испраќачите и примачите може да го сменат однесувањето на протокот на податоци. Ова е општо познато како контрола на застој и/или избегнување на застој на мрежата.

Модерните имплементации на ТСР содржат четири испреплетени алгоритми: бавен почеток, избегнување на застој, брзо препредавање, и брзо закрепнување.

Слабости
--------

TCP може да биде нападнат на различни начини. Резултатите од сеопфата проценка на протоколот, заедно со можните начини за избегнување на идентификуваните проблеми се публикувани во 2009 и моментално се разгледуваат од страна на IETF

### Denial of Service

Со користење на лажна IP-адреса и повеќекратно праќање на намерно создадени SYN пакети, напаѓачите може да го натераат опслужувачот да заземе огромно количество ресурси обидувајќи се да ги следи лажните врски. Ова е познато како напад со SYN поплава (SYN flood attack). Предлог решенијата вклучуваат SYN колачиња и криптографски загатки. Друг начин на избегнување на вакви напади е со подобро менаџирање на системските ресурси.

### Преземање на врска

Напаѓач кој е во можност да прислушкува една TCP сесија и да ги насочува пакетите може и да преземе нечија TCP врска. За да го стори тоа прво што напаѓачот прави е го открива бројот на низата на постоечката комуникација и прави лажен сегмент кој изгледа како следниот сегмент кој се очекува во комуникацијата. Ова резултира еден пакет да биде прифатен на другиот крај по грешка. Кога хостот кој прима ќе го потврди екстра сегментот се губи синхронизацијата. Преземањето на врска може да се комбинира со ARP или насочувачки напади кои дозволуваат добивање контрола над протокот на пакети, со цел да се добие трајна контрола на преземаната TCP сесија.
Лажирањето на IP-адреса не беше тешко пред RFC 1948, кога почетниот секвенцен број беше лесен за погодување. Тоа му дозволува на напаѓачот слепо да праќа низа од пакети кои примачот би им верувал дека доаѓаат од различна IP-адреса, без потребата да користат ARP или насочувачки напади. Доволно е напаѓачот да се осигура оригиналниот сопственик на лажната IP-адреса да не е вклучен на мрежата или пак да го оневозможи со DoS напади. Затоа сега почетниот секвенцен број се бира по случаен избор.

### TCP вето

Напаѓач кој може да прислушкува и да ја предвиди големината на следниот пакет кој треба да се прати може да го натера примачот да прифати малициозна содржина без да ја наруши постоечката врска. Напаѓачот наместо оригиналната содржина на пакетот ја поставува малициозната задржувајќи ги бројот на низата и должината на пакетот. Кога ќе се прими вистинскиот пакет кој има ист број на низа и иста должина со претходно примен пакет, тој се отфрла тивко како обичен дупликат пакет - добива вето од страна на малициозниот пакет.
За разлика од другите напади овој напад е тежок за детекција бидејќи врската не е нарушена, а единствен доказ што се остава е еден дупликат пакет, нешто што и нормално се случува во една IP мрежа. Испаќачот пак на пакетот кој добива вето нема никакви докази за нападот.

Наводи
------

1. ↑  Vinton G. Cerf, Robert E. Kahn (May 1974). „*A Protocol for Packet Network Intercommunication*" (PDF). *IEEE Transactions on Communications*. **22** (5): 637–648. Архивирано од изворникот (PDF) на 2016-03-04. Посетено на 2013-03-29.
2. 1 2  Comer, Douglas E. (2006). *Internetworking with TCP/IP:Principles, Protocols, and Architecture*. **1** (5. изд.). Prentice Hall. ISBN 0-13-187671-6.
3. ↑  „TCP (Linktionary term)". Архивирано од изворникот на 2013-04-07. Посетено на 2013-03-29.
4. ↑  RFC 791 – section 2.1
5. ↑  RFC 793 section 3.1
6. ↑  RFC 793 Section 3.2
7. ↑  Tanenbaum, Andrew S. (2003-03-17). *Computer Networks* (Fourth. изд.). Prentice Hall. ISBN 0-13-066102-3.
8. ↑  Security Assessment of the Transmission Control Protocol (TCP)
9. ↑  „Some insights about the recent TCP DoS (Denial of Service) vulnerabilities" (PDF). Архивирано од изворникот (PDF) на 2013-06-18. Посетено на 2013-05-25.
10. ↑  Laurent Joncheray, *Simple Active Attack Against TCP*, 1995