TCP

Од Википедија — слободната енциклопедија
Прејди на: содржини, барај
Петте нивоа на TCP/IP моделот
5. Апликациско ниво (Application layer)

DHCP • FTP • IMAP4 • POP3 • SIP • SMTP • SSH • BGP •

4. Транспортно ниво (Transport layer)

UDP • TCP • DCCP • SCTP • RSVP • ECN

3. Мрежно ниво (Network layer)

IP (IPv4 • IPv6) • ICMP • IGMP • RSVP • IPsec

2. Податочно ниво (Data Link Layer)

ATM • DTM • Ethernet • FDDI • Frame Relay • GPRS • PPP • ARP • RARP • L2TP • PPTP

1. Физичко ниво (Physical layer)

Етернет • ISDN • Модеми • PLC • SONET/SDH • G.709 • Wi-Fi •

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

Потекло[уреди | уреди извор]

Во мај 1974 година на Институтот за електро инженери и инженери по електроника (IEEE) објави труд под наслов "A Protocol for Packet Network Intercommunication"[1]. Авторите, 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.[2]

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

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

Структура на TCP сегмент[уреди | уреди извор]

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

Еден 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
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
Големина на прозорец
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 бита. Дополнувањето се состои од нули.[5]

Протокол[уреди | уреди извор]

Поедноставен дијаграм на состојби за TCP. За подетален дијаграм кој ги содржи состојбите внатре во ESTABLISHED состојбата погледнете го TCP EFSM diagram.

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

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

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. Ова е можеби најчестиот метод.[7]

Можно е двата домаќини да испратат 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[8]

Denial of Service[уреди | уреди извор]

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

Преземање на конекција[уреди | уреди извор]

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

TCP вето[уреди | уреди извор]

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

Референци[уреди | уреди извор]

  1. Vinton G. Cerf, Robert E. Kahn, (мај 1974 г). A Protocol for Packet Network Intercommunication. „IEEE Transactions on Communications“ том  22 (5): 637–648. http://ece.ut.ac.ir/Classpages/F84/PrincipleofNetworkDesign/Papers/CK74.pdf. 
  2. 2,0 2,1 Comer, Douglas E. (2006). Internetworking with TCP/IP:Principles, Protocols, and Architecture. 1 (5th издание). Prentice Hall. ISBN 0-13-187671-6. 
  3. TCP (Linktionary term)
  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
  10. Laurent Joncheray, Simple Active Attack Against TCP, 1995