Mrezi notes chapter 3

*Услуги на транспортен слој
	-Транспортниот слој нуди логичка комуникација помеѓу процеси кои работат на различни хостови. Е сега, пред да почниме да дрдориме за транспортниот слој, прво арно е да напрајме honorable mention на network слојот, односно IP which stands for Internet Protocol. IP ни овозможува логичка комуникација помеѓу hosts, додека за разлика од него транспортниот слој не ни знае ниту за рутери, ниту за линкови, туку транспортниот слој е задолжен за делење на пораките од апликацискиот слој во помали делчиња, енкапсулирање на тие помали делчиња кои сега се нарекуваат сегменти и предавање на тие сегменти до мрежниот слој. Кога овие сегменти ќе пристигнат до дестинацискиот хост, транспортниот слој на дестинацискиот host ги добива овие сегменти, ги составува во една порака и ги предава на соодветниот процес до апликацискиот слој.
	-Постојат 2 протоколи на транспортниот слој и тоа: TCP(Transmission control protocol) и UDP(User datagram protocol).
		*TCP - ни овозможува надежна достава по редослед, исто така обезбедува контрола на застој, контрола на проток и воспоставување на врска.
		*UDP - ненадежна достава, не нуди ништо, како сакат тој работат, как че му текнит, шо убо, земат плата за работање како шо сакат тој, ја сакам ваква работа во животот.

*Мултиплексирање и демултиплексирање
	-Basic definition: Мултиплексирање е бејзикли: Транспортниот слој земат дата од апликацискиот слој, ја делит на сегменти, додават свој хедер и тие сегменти ги дават на мрежниот слој. Демултиплексирање - на дестинацискиот хост транспортниот слој ги земат сегментите од мрежниот слој ги составјат во една порака и ги пренасочвит до соодветниот процес од апликациско ниво.

	-UDP мултиплексирање и демултиплексирање
		*Значи, за мултиплексирање: Процесот кој што сака да испрати податоци до некоја апликација која што се наоѓа на друг хост, најпрвин отвара сокет до транспортниот слој, па преку тој сокет му ја дава пораката на транспортниот слој што треба да ја пренесе до дестинацискиот хост. UDP значи ја зема датата, ја енкапсулира и во заглавјето додава source port i dest port.
		*Демултиплексирање: UDP добива датаграми од мрежниот слој, во кој има изворна и дестинациска IP адреса. Секој датаграм има еден сегмент од транспортниот слој, кои се екстрахираат. Кога UDP ќе ги добие сегментите на дестинацискиот хост, тој според заглавјето гледа до која порта, односно до кој сокет треба да ги испрати сегментите. UDP сокет е дефиниран само со Destination IP:destination port. Ако има два различни сегменти од два различни хоста со иста дестинациска порта, тогаш двата сегменти ќе бидат упатени кон истиот сокет. Source портата која се додава во мултиплексирањето е потребна ако дестинацискиот хост сака да испрати повратна порака до originating хост.
	-TCP мултиплексирање и демултиплексирање
		*Мултиплексирање: Pretty much the same како и кај UDP
		*Демултиплексирање: Демултиплексирањето е малку поразлично во однос на тоа како е дефиниран TCP сокетот. Значи дестинацискиот транспортен слој добива датаграм од мрежниот слој, кој содржи дестинациска и source IP адреса. Од тој датаграм се екстрахира сегмент, кој содржи дестинациска и source порта. Е сега, кај UDP сокетот се отвараше само со дестинациската IP адреса и порта, но кај TCP, сокетот се отвара со source IP, destination IP, source port & destination port. Значи ако два различни сегменти имаат различни source порти, тогаш за тие 2 сегменти се отвараат 2 различни сокети на дестинацискиот хост иако дестинациската порта може да им биде еднаква. Пример: да речиме дека два хоста сакаат да отворат TCP конекција со ист веб сервер кој слуша на порта 80. Тогаш серверот ќе отвори два посебни сокети за овие два сегменти за истата апликација, односно HTTP.

*Бесконекциски пренос: UDP
	-UDP има многу малце работа, односно извршува ептен минимум работа колку што може еден транспортен протокол да изврши.
	-Целиот процес: UDP ја зема пораката од погорниот слој, односно апликацискиот слој , додава source port и destination port во заглавјето кои се потребни за демултиплексирање, додава length и checksum и сегментот го предава на мрежниот слој подолу. Мрежниот слој го енкапсулира сегментот, и се обидува да го испрати до дестинацискиот хост. Доколку сегментот пристигне на дестинацискиот хост, тогаш UDP преку демултиплексирањето значи од заглавјето го гледа дестинацискиот порт и го упатува сегментот до соодветниот сокет.
	-UDP за разлика од TCP нема threeway handshake, односно не воспоставува врска, т.е конекција, туку само ги испраќа пакетите (ги фрла на некој начин, не му е гајле аљ че стигнет аљ не)
	-Причини зошто UDP би се избрал пред TCP:
		*UDP многу брзо ја завршува својата работа, односно на најбрз и наједноставен начин ја превзема пораката од апликациското ниво и ја предава на мрежното ниво, што е погодно за апликации како video streaming, односно real-time апликации на кои времето им е многу поважно од тоа дали податоците сигурно стигнале до саканата дестинација.
		*UDP не воспоставува конекција, што го намалува доцнењето(delay)
		*UDP не чува connection state, што овозможува една апликација да има повеќе активни корисници at a time, отколку кога апликацијата би користела TCP
		*UDP нема congestion control, што значи дека може да работи со посакуваната брзина
		*UDP има многу мало заглавје: од само 8 бајти, додека TCP има заглавје од дури 20 бајти.
	-Структура на UDP сегмент
		*header field (8 bytes)
		*data field
		-header field: се состои од 4 полиња(source port, destination port, length, checksum), секое со големина од по 2 бајти.
			*source port: портата на испраќачкиот хост, потребна за (де)мултиплексирање
			*destination port: портата на дестинацискиот хост, потребна за (де)мултиплексирање
			*length: големината на целиот сегмент, вклучувајќи ја и големината на заглавјето, изразена во бајти
			*checksum: 16-битно поле кое укажува дали при преносот на сегментот настанале некакви промени, односно грешки во рамките на сегментот
		-data field: во зависност од апликацијата која го користи UDP како транспортен протокол, во data field може да има фајл, текст, и слично.
	-UDP Checksum
		*UDP checksum претставува 16-битно поле во заглавјето на UDP сегментот кое ни укажува дали при преносот на сегментот настанале некакви грешки или промени.
		*Како работи?: Значи како што веќе кажавме, секое поле во заглавјето се состои од 16 бита, односно од 16-битни зборови, кои можат да се претставени бинарно. Е сега како се конструира checksum?: значи се собираат останатите 3 16-битни зборови од заглавјето(ако има overflow, преносот се додава на резултатот) и на тоа се бара прв комплемент(односно се нулите се заменуваат со единици, а единиците со нули). Е сега, кога UDP ќе го добие сегментот на дестинацискиот хост, тој пак ги собира овие 3 полиња и резултатот го собира со checksum-от. Што значи ако нема никаква грешка при преносот овој резултат треба да биде 1111111111111111(16 единици). Ако има грешка UDP не прави ништо за тоа(of course, lazy ass mothafucka), можно е само на сокетот да го извести дека има грешка при преносот на сегментот.

*Принципи на надежен пренос на податоци
-Во овој chapter се опишуваат генерални концепти на надежен пренос на податоци, кои концепти можат да се искористат не само во транспортниот слој, а уште погенерално и не само во рамки на самиот Интернет, туку овие концепти пронаоѓаат поширока употреба.
-Целта е да се конструира таков надежен канал каде податочните битови нема да бидат изгубени или променети и ќе бидат доставени по ред до дестинацискиот хост, дури и каналот под овој канал да биде ненадежен канал за пренос. На пример: TCP е надежен канал за пренос кој користи IP како ненадежен канал за пренос на податоци од еден до друг хост.
	-Вовед во надежен податочен пренос(rdt) - концептот е едноставен, на испраќачката страна апликацискиот слој ја повикува функцијата rdt_send() која датата која што треба да се пренесе му ја дава на подолниот слој(во случајов на транспортниот слој), па потоа кога овој канал ќе биде спремен ја повикува функцијата udt_send() што значи дека сега пакетот му се дава на ненадежниот канал за пренос на податоци. Кога пакетот ќе пристигне до дестинацискиот хост, транспортниот протокол за надежен пренос на податоци ја повикува функцијата rdt_rcv() со што пакетот од udt (unrealiable data transfer) каналот се пренесува во транспортниот канал. Па конечно од rdt се повикува функцијата rdt_deliver_data() со која што податоците се пренесуваат на погорниот слој, односно апликацискиот слој.
	-Понатаму:
		*ќе ги надградуваме испраќачот и примачот кои користат надежен податочен протокол за пренос на податоци
		*ќе разгледаме пренос на податоци во една насока, каде контролните податоци ќе бидат двонасочни
		*ќе користиме конечни автомати за да ги опишиме испраќачот и примачот
	-Reliable data transfer over a perfectly reliable channel: introducing rdt1.0
		*Значи најпрвин го земаме наједноставниот случај, односно кога каналот кој се користи под овој надежен канал е исто така комплетно надежен, односно нема простор за грешки. Овој протокол користи FSM(Finite-state machine) машини, една кај испраќачот и една кај примачот. FSM машините во овој протокол имаат само една состојба(state). Стрелките кај FSM машините ја прикажуваат транзицијата од една во друга состојба, во случајов транзиција од првата состојба во самата себе. Настанот кој што ја предизвикува транзицијата е прикажана над хоризонталната линија, а акциите кои што се превземаат кога ќе се случи настанот се прикажани под хоризонталната линија.
		*Постапка:
			-The  sending  side  of rdt  simply  accepts  data  from  the  upper  layer  via  the rdt_send(data)  event,  creates  a  packet  containing  the  data  (via  the  action make_pkt(data))  and  sends  the  packet  into  the  channel.  In  practice,  the rdt_send(data)  event  would  result  from  a  procedure  call  (for  example,  to rdt_send()) by the upper-layer application.
			-On  the  receiving  side,  rdt  receives  a  packet  from  the  underlying  channel  via the rdt_rcv(packet)  event,  removes  the  data  from  the  packet  (via  the  action extract  (packet,  data))  and  passes  the  data  up  to  the  upper  layer  (via the action deliver_data(data)). In practice, the rdt_rcv(packet) event would result from a procedure call (for example, to rdt_rcv()) from the lower-layer protocol.
	-Reliable data transfer over a channel with bit errors: introducing rdt2.0
		*Тука претпоставуваме дека сите испратени пакети сигурно пристигнуваат, но истите може да претпрат некакви грешки при преносот.
		*Концептот на ваквите протоколи е дека ако пакетот кој што е пристигнат на дестинациската страна има грешка, тогаш испраќачот го препраќа пакетот. Ваквите протоколи се познати како ARQ(Automatic repeat reQuest) protocols. Ваквите протоколи имаат 3 посебни карактеристики, односно задачи, и тоа:
			-Error detection: Најпрвин за да знаеме дали пакетот треба да се препрати или не, треба најпрво да провериме дали пристигнатиот пакет има некаква грешка или е примен онака како што е испратен.
			-Receiver feedback: Ако има грешка, тогаш примачот мора да му укаже на испраќачот дека пакетот има грешка и дека треба да се препрати
			-Retransmission: Кога испраќачот ќе добие информација од примачот дека пакетот е оштетен, тој истиот го препраќа
		*Процес:
			-Испраќач: Кај испраќачот имаме една FSM со две состојби.
				*Прва состојба: Првата состојба е "Wait call from above", а акции кои се превземаат во оваа состојба се: направи го пакетот со датата добиена од погорниот слој и испрати го тој пакет и смени ја состојбата.
				*Втора состојба: Втората состојба е "Wait for ACK or NAK". Ако се добие NAK, тогаш препрати го оригиналниот пакет и повторно стави се во состојба "Wait for ACK or NAK". Ако добиениот пакет е ACK, тогаш смени ја состојбата во првата состојба, т.е "Wait for call from above".
			-Примач: Кај примачот имаме една состојба, но различни акции се превземаат во зависност од тоа дали пристигнатиот пакет има грешки или не.
				*Ако има грешки: Се испраќа NAK назад до примачот и повторно се враќа во состојба на чекање.
				*Ако нема грешки: Се превзема пакетот, се екстрахира и датата се пренесува до погорниот слој, се испраќа ACK назад до примачот дека пакетот е примен без никакви грешки и се враќа во состојба на чекање повторно.
		*Зошто овој протокол има една фатална грешка?
			-Затоа што ACK или NAK пакетот може да претрпи грешка при пренос. Тоа значи дека ако примачот испрати ACK и ако настане грешка при пренос на овој пакет(што е 0 или 1) тогаш ACK ќе пристигне како NAK и испраќачот ќе постапи погрешно. И во обратен случај ако се испрати NAK. Па затоа, ни треба подобар канал од овој.
	-Introducing rdt2.1
		*Значи во 2.1 испраќачот пакетите ги нумерира, односно им додава секвенцијален број
		*Испраќач: најпрвин се наоѓа во состојба чекај 0 од горе, што значи дека чека повик од од апликацискиот слој и тој пакет ќе го нумерира со секвенцијален број 0. Пакетот го испраќа и ја менува својата состојба во чекај АЦК или НАК 0, што значи дека ќе чека АЦК или НАК за испратениот пакет. Тука можат да се случат неколку работи. Доколку примачот ја примил пораката и испратил АЦК и испраќачот го примил тој АЦК и тој пакет не е кораптед, тогаш не прави ништо и ја сменува состојбата во чекај повик од горе 1, но ако се добил НАК или пак добиениот пакет е кораптед, тогаш го препраќа пакетот и повторно чека АЦК или НАК. И истото се повторува во следниот стејт за 1.
		*Примач: Значи примачот најпрвин во иницијална форма чека пакет со секвенцијален број 0. Ако е кораптед му праќа на испраќачот НАК и повторно чека пакет со сек. број 0. Ако не е кораптед си го прима пакетот, му испраќа АЦК на испраќачот и сега чека пакет со сек. број 1. Сега во овој стејт може да се случат три работи. Првата работа: Може испраќачот да не го примил нашиот АЦК како што треба па повторно го испраќа претходниот пакет со сек.број 0, па ние му испраќаме АЦК повторно дека тој пакет е примен. Вториот случај е да се прими пакет и тој да е кораптед, тогаш на испраќачот му испраќаме НАК. Третиот случај е да се добие пакет со сек.број 1 и тој да не е кораптед, во тој случај го примаме овај пакет, му испраќаме АЦК на испраќачот и сега преминуваме стејт на чекање пакет со сек.број 0.
	-rdt2.2
		*rdt2.2 е ист како и rdt2.1, но не користи NAKs, туку само ACKS.
		*Испраќач: Најпрвин се наоѓа во состојба чекај повик 0 од горе, што значи дека чека повик од апликацискиот слој и новиот пакет ќе го означи со сек.број 0, ќе го испрати и ќе го промени стејтот чекај АЦК за 0. Е сега може да се случат две работи: пристигнатиот пакет(што треба да е АЦК) може да биде кораптед или да биде АЦК за пакет со сек бр.1, во овој случај се препраќа испраќачкиот пакет. Ако добиениот АЦК не е кораптед и е АЦК со за пакет со сек.број 0, тогаш се променува стејтот во чекај повик од горе 1. Се повторува истото само со сек.број 1.
		*Примач: Најпрвин е во состојба чекај повик од долу 0. Значи дека чека пакет со сек.број 0. Имаме два случаи: Може да се прими кораптед пакет или пакет со сек. број 1, во тој случај се испраќа АЦК за пакет со сек.број 1. Вториот случај е да се прими пакет кој не е кораптед и има сек број.0, во тој случај го примаме пакетот и испраќаме АЦК за пакет со сек.број 0.
	-rdt3.0
		*rdt3.0 ја користи основната функционалност на rdt2.2, но со мали додатоци. rdt3.0 претпоставува дека не само што може пакетот да биде погрешно примен, т.е да има грешки при пренос, туку дека пакетот може да биде и изгубен. За таа цел кај испраќачот се воведува тајмер.
		*Испраќач: Испраќачот се наоѓа во почетна состојба чекај 0 од горе, што значи дека по повик од апликацискиот слој, ќе креира пакет со добиената дата и секвенцијален број 0, ќе го испрати тој пакет, ќе го стартува тајмерот и ќе ја промени состојбата во чекај ацк за 0. Тука имаме 3 случаи: првиот случај е да добиеме кораптед пакет или АЦК за пакет со секв. број 1, во тој случај не правиме ништо, вториот случај е да не добиеме никаков одговор, односно тајмаут, што значи дека ќе го препратиме пакетот и ќе го пуштиме тајмерот наново, третиот случај вика дека сме добиле ацк за пакет со секв.број 0 навреме, во тој случај го стопираме тајмерот и ја сменуваме состојбата во чекај од горе 1. Доколку пак во овој нов стејт добиеме некаков пакет, што најверојатно е залутан пакет кој што е препратен заради тајмаут, тогаш не правиме ништо. Истото се повторува понатаму.
		*Примач: Исти концепт како кај rdt2.2.
	-Проточни протоколи:
		*Проблемот кај rdt е тоа што е stop and wait protocol, што значи дека може да испрати само еден пакет at a time, што е многу неефективно. Затоа се измислиле овие проточни протоколи, каде што повеќе пакети се испраќаат наеднаш.
		-Go-back-N: Испраќачот може да има најмногу N испратени, но непотврдени пакети. Значи, испраќачот ги испраќа N пакетите, почнува да чека ACKs за пакетите и отвара тајмер за најстариот(односно најпрво испратениот) непотврден пакет. Доколку има timeout, се препраќа пакетот N и сите пакети после него и тајмерот се рестартира.
			*Примачот од друга страна пак испраќа ACK за последно-примениот пакет, односно пакет со редоследно најголем секвентен број. Бидејќи примачот редоследно ги предава пакетите на погорниот слој, ако на пример пристигнал пакет 3, не пристигнал пакет 4, но пристигнал пакет 5, тогаш примачот не го баферира пакет 5, туку ги паѓа и пакет 4 и пакет 5 и праќа ацк за пакет 3, па испраќачот треба да ги препрати пакет 4 и 5.
		-Selective repeat: Испраќачот може да има најмногу N испратени, но непотврдени пакети. Значи, испраќачот ги испраќа N пакетите, почнува да чека ACKs за пакетите и отвара тајмер за СЕКОЈ пакет. Доколку има тајмаоут на некој од тајмерите, тогаш го препраќа оној пакет каде што се појавил тајмаутот и го рестартира истиот тајмер.
				   *Примач: Примачот ги прима пакетите и за пакетите кои се успешно примани и немаат грешка испраќа назад до испраќачот ACK и пакетите редоследно ги испраќа до погорниот слој. Е сега доколку дојде до губење на некој пакет кој го руши редот, на пример пакет 3, 5, 6, 7 се примени, но пакет 4 е изгубен, тогаш успешно примените пакети примачот ги баферира и чека пакетот 4 да биде препратен, за разлика од GoBackN кој би ги препратил сите пакети после 4 вклучително со 4тиот. Кога изгубениот пакет ќе биде успешно препратен и пристигнат, тогаш сите пакети повторно се испраќаат редоследно до апликацискиот слој.

*Конекциски пренос на податоци: TCP
-TCP претставува конекциски-ориентиран протокол, затоа што за еден апликациски процес да може да испрати податоци до друг апликациски процес, овие два процеси најпрво мора да поминат низ т.н процес на ракување, т.е three-way-handshake.
-Значи една многу важна работа која треба да се спомне е дека TCP не е end-to-end врска како TDM или FDM, туку TCP конекцијата претставува логичка конекција, врска помеѓу два процеси на различни хостови, односно TCP не е задолжен за физичката конекција помеѓу овие 2 хоста.
-TCP конекцијата е full-duplex, односно и двете страни на конекцијата истовремено можат и да испраќаат и да примаат податоци. Исто така TCP е point-to-point конекција, односно има само две страни, испраќач и примач, не може да има на пример еден испраќач и повеќе примачи и сл.
-Како TCP работи накратко површински: Еден процес кој што работи на еден хост сака да иницијализира конекција со друг процес на друг хост(клиентски и серверски процес). Па најпрвин клиентскиот процес го информира транспортниот слој дека сака да иницира конекција со некој серверски процес на некој сервер. Најпрвин клиентскиот процес испраќа специјален пакет до серверскиот процес, па серверскиот процес испраќа одговор на тој специјален пакет и на крај клиентскиот процес истот така одговара на одговорот од серверот. Затоа овој процес се нарекува three-way handshake.
-Процесите својата дата која треба да биде пренесена на TCP му ја предаваат преку socket. TCP има sending buffer и receiving buffer за испраќање и примање на сегменти.
-Maximum segment sizе(MSS): претставува максималната големина на податоци кои може сегментот да ги прима од апликацискиот слој, без да се земе во предвид заглавјето на TCP кое типично е 20 бајти. MSS е типично 1460 бајти, а тоа го добиваме според Maximum transmission unit, односно максималните податоци кои подолните слоеви можат да ги пренесат што е типично 1500 бајти, значи од тие 1500 бајти се одземаат 20 бајти за заглавјето на TCP и 20 бајти за заглавјето кое го поставува мрежниот слој и така се добиваат овие 1460 бајти.
	-Структура на TCP сегмент
		*data field(payload) - големината зависи од MSS
		*header:
			-source port 2B
			-destination port 2B
			-checksum 2B
			-sequence number 4B
			-acknowledgment number 4B
			-receive window (used for flow control, it means the max amount of bytes that the receiver can receive) 2B
			-header length field
			-flag field(URG, ACK, PSH, RST, SYN, FIN) 6 bits + 2 unused bits
			-urgent data pointer 2B
			-optional options field(used when sender and receiver negotiate the MSS)
	*Секвентни броеви и ACK кај TCP
		-Секвентни броеви: се означени со првиот бајт од сегментот од податочниот проток
		-ACK: тоа е секвенцијалниот број на следниот очекуван бајт од другата страна.
		*ова се учит со примери.
	*RTT estimation and timeout
		-SampleRTT - измерено време од испраќањето на сегментот до примањето на неговиот ACK (не се брои SampleRTT на пакети кои се препраќаат)
		-EstimatedRTT = (1-alfa) * EstimatedRTT + alfa*SampleRTT (alfa е типично 0.125)
		-DevRTT(отсапување од SampleRTT и EstimatedRTT)
		-DevRTT = (1 - beta) * DevRTT + beta * |SampleRTT-EstimatedRTT| , типично beta = 0.25
		-Timeout interval = EstimatedRTT + 4*DevRTT
	-Надежен пренос на податоци(односно како TCP овозможува сите пакети да пристигнат и тоа да бидат примени по ред и без никакви грешки)
		*Испраќач: креира сегмент со секвенцијален број, секвенцијалниот број е првиот податочен бајт во сегментот од протокот на бајти, стартува тајмер, доколку моментално нема активен тајмер(тајмерот е за најстариот непотврден сегмент, интервал на истекување се пресметува со формулата за TimeOutInterval), ако настане тајмаут го препраќа сегментот кој предизвикал тајмаут и го рестартира тајмерот, сетирајќи го тајмаут интервалот за реемитираните пакети за двојно од претходниот интервал) и примачот прима ACK за некој претходно непотврден сегмент.
		-Креирање на ACK кај TCP(4 настани):
			*Пристигнува редоследен сегмент со очекуван секв. бр. Сите податоци до секв. бр. се потврдени; Акција: Се испраќа одложен ACK. Чека до 500ms за нареден сегмент. Ако нема сегмент, испраќа ACK.
			*Пристигнува редоследен сегмент со очекуван секв. бр. Постои сегмент за кој не е пратен ACK; Акција: Веднаш се испраќа кумулативен ACK, со кој се потврдуваат двата сегменти по редослед
			*Пристигнува сегмент кој е вон редослед и со поголем секв. бр. од очекуваниот. Детектира дупка во секв. бр; Акција: Веднаш испраќа дупликат ACK, во кој се наведува секв. број на наредниот очекуван бајт.
			*пристигнува сегмент кој парцијално или целосно ја исполнува дупката; Акција: веднаш испраќа ACK, доколку сегментот почнува на долната граница од дупката
		-TCP fast retransmit - Ако испраќачот прими 3 ACK за истиот сегмент(три дупликат ACK), го препраќа непотврдениот сегмент со најмал секв. број без да чека да се појави тајмаут.
	-Flow control(контрола на проток)
		*Значи кога се отвора TCP конекција примачот, т.е двете страни(TCP е full duplex нели) алоцираат бафер простор, односно тоа е просторот каде што се сместуваат пристигнатите сегменти кои се' уште не се доставени до апликацискиот слој(апликацискиот слој не секогаш веднаш ги прима сегментите, туку има одреден delay, дали заради тоа што апликацијата е зафатена со друг task или некоја друга причина).
		*Како што пристигнуваат нови сегменти кај примачот, овој бафер се полни, па така примачот заедно во секој ACK што го испраќа за пристигнатите сегменти, во заглавјето на ACK сегментот го испраќа слободниот простор на баферот (кој се пресметува како rwnd = InitBufferSpace - [LastByteRcvd - LastByteRead].
		*Flow control-ата ни овозможува испраќачот да го ограничи испраќањето на сегменти во зависност од тоа колку примачот има слободно место во својот бафер.
		*Со тоа се гарантира дека испраќачот нема да испраќа повеќе податоци отколку што примачот може да прими.
	-TCP Connection Management(Управување со конекција)
		*Воспоставување на конекција(3 чекори):
			-1. чекор: Клиентот, односно иницијаторот на конекцијата испраќа пакет(кој не содржи податоци од апликацискиот слој, односно payload), но знаменцето SYN во заглавјето е поставено на 1, со што овој сегмент се нарекува SYN сегмент. Исто така клиентот randomly го избира својот прв секвенцијален број и го запишува во заглавјето на овој SYN сегмент. Овој сегмент се енкапсулира и предава на мрежното ниво.
			-2. чекор: Кога IP датаграмот кој што го содржи TCP SYN сегментот на клиентот ќе пристигне до серверот, серверот го екстрахира TCP SYN сегментот, го алоцира потребниот бафер простор и испраќа повратен сегмент до клиентот. Овој повратен сегмент има три важни работи во своето заглавје: прво, SYN flag-от е поставен на 1, второ, во ackowledgment полето се запишува (seqnumofclientSYNpacket+1) и серверот исто така по случаен избор генерира секв.број и истиот го запишува во заглавјето. Овој повратен сегмент се нарекува SYNACK сегмент.
			3. чекор: Кога клиентот ќе го добие SYNACK сегментот, клиентот исто така алоцира бафер простор(full-duplex, remember?). Потоа клиентот испраќа уште еден сегмент до серверот, овој пат SYN flag-от е поставен на 0, acknowledgment бројот се генерира на тој начин што на серверскиот секв.број се додава 1 и истиот се запишува во заглавјето на сегментот кој треба да биде испратен. Исто така овој сегмент може да содржи податоци од апликациското ниво.
		*Кога ќе се реализира конекцијата, 2та хоста можат да си испраќаат сегменти меѓусебно. Иницирањето на конекција се состои од 3 чекори, односно меѓусебно испраќање на 3 пакети и затоа се нарекува three-way-handshake.
		-Затварање на конекција:
			*Клиентот: најпрвин испраќа FIN сегмент, односно сегмент со FIN flag = 1 и влегува во фаза на FIN_WAIT 1, чекајќи ACK од страна на серверот. Кога тој ACK е добиен, клиентот ја променува својата состојба во FIN_WAIT_2, притоа не испраќајќи ништо до серверот, чекајќи FIN сегмент од страна на серверот. Кога овој FIN ќе биде примен, клиентот испраќа ACK и преминува во состојба TIME_WAIT. Во оваа фаза типично клиентот чека 30на секунди и потоа конечно ја затвара конекцијата.
			*Серверот: Најпрвин добива FIN сегмент од страна на клиентот и испраќа ACK, променувајќи ја својата состојба во CLOSE_WAIT. Во оваа фаза серверот испраќа FIN сегмент и преминува во LAST_ACK фаза. Во оваа фаза треба да добие ACK од страна на клиентот, а потоа ја затвора конекцијата.

*Принципи на контрола на застој
-Контролата на застој или congestion control е различна од flow control, во тоа што контролата на застој е задолжена да нема застој на линковите од мрежното ниво, односно сега TCP наместо да го лимитира испраќачот заради недоволното место во баферот на примачот, сега TCP го лимитира испраќачот во однос на тоа колку е зафатен линкот по кој што треба да се испратат TCP сегментите.
-Ако оваа контрола на застој не постои и секој TCP испраќач испраќа сегменти со брзина која што тој сака, тогаш на мрежното ниво ќе настане хаос и линковите ќе се преплават со информации, што ќе резултира баферите на рутерите да се полнат, што пак предизвикува големи delays или во најлош случај голем број на паднати пакети.
-Постојат 2 генерални принципи на контрола на застој, а тоа се: контрола на застој без помош од network layer и контрола на застој со помош од network layer. Во контролата на застој без помош, TCP протоколот го анализира сообраќајот на линкот според своеизработени анализи врз база на испратените и изгубените сегменти, додека во контролата на застој со помош, рутерите директно му даваат на транспортниот протокол информација за тоа колкавав е сообраќајот на линкот кој се користи за транспорт на податоци.

*TCP контрола на застој
-Basic aproach: TCP користи контрола на застој без помош од мрежниот слој. Како работи контролата на застој кај TCP? Значи секој испраќач ја лимитира ратата на испраќање на сегменти/податоци во линкот. Ако испраќачот утврди дека нема или има многу малку сообраќај во линкот, тогаш испраќачот ја зголемува ратата со која испраќа податоци низ линкот. Додека пак ако испраќачот утврди дека линкот се загушува, т.е дека има премногу сообраќај во линкот, тогаш испраќачот ја намалува ратата со која испраќа податоци во линкот. Ајде да го продлабочиме овај концепт.

-Механизмот за контрола на застој кај TCP испраќачот има една променлива која води сметка за сообраќајот, односно загушеноста на линкот, односно познато како congestion window, кој е означен со cwnd. Cwnd ни означува со колкава рата може TCP испраќачот да испраќа податоци во линкот. Бројот на непотврдени пакети не смеат да го преминат минимумот на cwnd и rwnd, односно: LastByteSend - LastByteAcked <= min(cwnd, rwnd).

-Ратата на пренос ~ cwnd/RTT bytes/sec

	*Slow start фаза, на почетокот cwnd иницјално се поставува на 1 MSS bytes, cwnd двојно се зголемува се' додека не се појави тајмаут или 3 дупликат ACKs како индикатор на загуба, во тој случај во општ случај cwnd се ресетира на 1 MSS, додека пак се воведува и нова променлива ssthresh која пред да се ресетира cwnd ја добива вредноста cwnd/2.
	*Congestion Avoidance, кога cwnd ќе се ресетира на 1 MSS, тој пак експоненцијално расте се' додека не дојде до ssthresh, каде продолжува да расте линеарно.
	*TCP RENO и TCP TAHOE
		-TCP RENO, кога ќе добие 3 дупликат ACKs, cwnd не го поставува на 1, туку почнува од ssthresh и продолжува да расте линеарно.
		-TCP TAHOE, секогаш го поставува cwnd на 1, и продолжува да расте експоненцијално се' до ssthresh, каде продолжува да расте линеарно.