Sa link ng data at mga antas ng protocol ng network TCP/IP packet, na may kinalaman sa pangunahing mekanismo para sa paglilipat ng mga bloke ng data sa pagitan ng mga bansa at sa pagitan ng mga network, ang mga pangunahing kaalaman TCP/IP. Ginagamit nila ang protocol stack, ngunit hindi sila direktang ginagamit sa mga application na tumatakbo sa protocol TCP/IP. Sa artikulong ito, titingnan natin ang dalawang protocol na ginagamit ng mga application: User Datagram Protocol (UDP) at Transmission Control Protocol (TCP).

User Datagram Protocol
Ang User Datagram Protocol ay isang napakasimpleng protocol. Parang IP, ito ay isang maaasahang protocol na walang koneksyon. Hindi mo kailangang magtatag ng isang koneksyon sa host upang makipagpalitan ng data gamit ito UDP, at walang mekanismo upang matiyak ang ipinadalang data.
Block ng data na ipinadala gamit UDP tinatawag na datagram. UDP nagdaragdag ng apat na 16-bit na field ng header (8 bytes) sa ipinadalang data. Ang mga field na ito ay: length field, checksum field, at source at destination port number. Ang "Port", sa kontekstong ito, ay kumakatawan sa software ng port, hindi ang hardware port.
Ang konsepto ng numero ng port ay karaniwan sa pareho UDP at TCP. Tinutukoy ng mga numero ng port kung aling protocol module ang nagpapasa (o tumatanggap) ng data. Karamihan sa mga protocol ay may mga karaniwang port na karaniwang ginagamit para dito. Halimbawa, ang Telnet protocol ay karaniwang gumagamit ng port 23. Simple Mail Transfer Protocol (SMTP), ay gumagamit ng port 25. Ang paggamit ng mga standard na port number ay nagpapahintulot sa mga kliyente na makipag-ugnayan sa server nang hindi muna nagpapasya kung aling port ang gagamitin.
Port at numero ng protocol sa field ng header IP duplicate ang isa't isa sa ilang lawak, bagama't ang mga protocol field ay hindi available sa mas mataas na antas na mga protocol. IP ginagamit ang field ng protocol upang matukoy kung saan dapat ipadala ang data UDP o TCP mga module. UDP o TCP gamitin ang port number para matukoy kung aling application layer protocol ang dapat tumanggap ng data.
sa kabila, UDP ay hindi palya, ito ay isang angkop na pagpipilian para sa maraming mga aplikasyon. Ito ay ginagamit ng mga real-time na application tulad ng streaming audio at video, kung saan kung ang data ay nawala, mas mahusay na gawin nang wala ito kaysa ipadala ito muli sa pagkakasunud-sunod. Ginagamit din ito ng mga protocol tulad ng Simple Network Management Protocol (SNMP).
I-broadcast
UDP angkop para sa pagsasahimpapawid ng impormasyon dahil hindi ito nangangailangan ng bukas na koneksyon sa komunikasyon Ang mga target ng isang mensahe ng broadcast ay tinutukoy ng nagpadala, sa tinukoy na IP address. UDP ang mga datagram na may patutunguhang IP address ay binary 255.255.255.255) at matatanggap ng bawat host sa lokal na network. Bigyang-pansin ang salitang lokal: ang mga datagram na may ganoong address ay hindi tatanggapin ng router sa Internet.
Maaaring idirekta ang mga pagpapadala sa mga partikular na network. UDP datagrams mula sa host at subnet na bahagi ng IP address na itinakda bilang binary ay ibino-broadcast sa lahat ng host sa lahat ng subnet ng network na tumutugma sa purong bahagi ng IP address. Kung ang receiving end lang (sa madaling salita, lahat ng bits na zero sa subnet mask) ay nakatakda sa binary, ang broadcast ay limitado sa lahat ng host sa subnet na tumutugma sa natitirang address.
Ginagamit ang multicast upang magpadala ng data sa isang pangkat ng mga host na nagpahayag ng pagnanais na matanggap ito. Multicast UDP ang datagram ay may patutunguhang address kung saan ang unang apat na bit ay 1110, na nagbibigay ng mga address sa hanay na 224.xxx hanggang 239.xxx Ang natitirang mga bit ng address ay ginagamit upang italaga ang multicast na grupo. Ito ay mas katulad ng isang channel sa radyo o TV. Kaya, halimbawa, ang 224.0.1.1 ay ginagamit para sa NTP protocol. Kung TCP/IP Nais ng mga application na makatanggap ng multicast na mensahe, dapat silang sumali sa naaangkop na multicast group, na ginagawa nito sa pamamagitan ng pagpasa ng address ng grupo sa protocol stack.
Ang mga broadcast ay mahalagang sinasala ang paghahatid. Hindi isinasaalang-alang ng Multicaster ang mga indibidwal na mensahe para sa bawat host na sasali sa grupo. Sa halip, ang mga mensahe ay ibino-broadcast, at ang mga driver sa bawat host ay magpapasya kung babalewalain ang mga ito o ipapasa ang mga nilalaman sa protocol stack.
Nangangahulugan ito na ang mga multicast na mensahe ay dapat na mai-broadcast sa buong Internet, dahil hindi alam ng multicaster kung aling mga host ang gustong makatanggap ng mga mensahe. Sa kabutihang palad, hindi ito kinakailangan. Gumagamit ang IP ng isang protocol na tinatawag na Internet Group Management Protocol (IGMP) upang sabihin sa mga router kung aling mga host ang gustong makatanggap ng mga multicast na mensahe ng grupo upang maipadala lamang ang mga mensahe kung saan kinakailangan ang mga ito.
Transmission Control Protocol
Ang Transmission Control Protocol ay isang transport layer protocol at ginagamit ng karamihan sa mga application sa Internet tulad ng Telnet, FTP at HTTP. Ito ay isang protocol na nakatuon sa koneksyon. Nangangahulugan ito na ang dalawang computer - ang isa ay isang kliyente, ang isa ay isang server - ay kailangang magtatag ng isang koneksyon sa pagitan ng mga ito bago mailipat ang data sa pagitan nila.
TCP nagbibigay ng pagiging maaasahan. Application na gumagamit TCP alam na nagpapadala ito ng data na natanggap sa kabilang dulo, at natanggap ito ng tama. TCP gumagamit ng mga checksum sa parehong mga header at data. Kapag tumatanggap ng data, TCP nagpapadala ng kumpirmasyon pabalik sa nagpadala. Kung ang nagpadala ay hindi nakatanggap ng kumpirmasyon sa loob ng isang tiyak na tagal ng panahon, ang data ay muling ipapadala.
TCP may kasamang mga mekanismo upang matiyak na dumating ang data sa reverse order sa pagkakasunud-sunod na ipinadala nito. Nagpapatupad din ito ng kontrol sa daloy upang hindi madaig ng nagpadala ang tatanggap ng data.
TCP nagpapadala ng data gamit ang IP sa mga bloke na tinatawag na mga segment. Ang haba ng segment ay tinutukoy ng protocol. Bilang karagdagan sa IP header, ang bawat segment ay binubuo ng 20 bytes ng header. Heading TCP nagsisimula sa isang 16-bit na source at destination port number field. Parang UDP, tinutukoy ng mga field na ito ang antas ng aplikasyon na naglalayong makatanggap ng data. Ang IP address at numero ng port ay katangi-tanging tumutukoy sa mga serbisyong tumatakbo para sa host at sa pares na kilala bilang socket.
Susunod sa header ay isang 32-bit na sequence number. Tinutukoy ng numerong ito ang posisyon sa stream ng data na dapat sakupin ng unang byte ng data sa segment. Serial number TCP nagbibigay-daan sa stream ng data na panatilihin sa tamang pagkakasunud-sunod, bagama't maaaring makuha ang mga segment mula sa isang sequence.
Ang susunod na field ay isang 32-bit na field na ginagamit upang ibalik sa nagpadala na ang data ay natanggap nang tama. Kung ang ACK ay isang flag, na karaniwan ay, ang field na ito ay naglalaman ng posisyon ng susunod na byte ng data na inaasahan na matanggap ng nagpadala ng segment.
SA TCP hindi na kailangang kilalanin ang bawat segment ng data. Ang halaga sa field ng kumpirmasyon ay binibigyang kahulugan bilang "ang lahat ng data na natanggap OK sa ngayon." Makakatipid ito ng bandwidth kapag ang lahat ng data ay nai-ruta sa isang direksyon, na binabawasan ang pangangailangan para sa pagkilala ng segment. Kung ang data ay ipinadala nang sabay-sabay sa parehong direksyon, tulad ng sa buong duplex na komunikasyon, ang mga selyo ay hindi nauugnay sa mga gastos, dahil ang isang segment ng data sa isang paraan ay maaaring maglaman ng isang pagkilala para sa data na ipinadala sa kabilang paraan.
Susunod sa header ay isang 16-bit na field na naglalaman ng haba ng header at mga flag. TCP maaaring maglaman ng mga karagdagang field ang mga header, kaya maaaring mag-iba ang haba mula 20 hanggang 60 byte. Mga Flag: URG, ACK (na nabanggit na namin), PSH, RST, SYN at FIN. Mamaya, titingnan natin ang iba pang mga flag.
Ang header ay naglalaman ng isang field na tinatawag na laki ng window, na nagbibigay ng bilang ng mga byte na matatanggap ng receiver. Mayroon ding 16-bit na checksum na sumasaklaw sa header at data. Sa wakas (bago ang karagdagang data) mayroong isang field na tinatawag na "urgency indicator". Kapag nakatakda ang flag ng URG, ang halagang ito ay binibigyang kahulugan bilang isang sequence number offset. Tinutukoy nito ang pagsisimula ng data sa isang stream na kailangang maproseso nang madalian. Ang data na ito ay madalas na tinutukoy bilang "out-of-group" na data. Ang isang halimbawa ng paggamit nito ay kapag pinindot ng user ang break key upang matakpan ang paglabas sa programa sa panahon ng isang session ng Telnet.

Ang UDP ay isang simpleng protocol at may partikular na saklaw. Una sa lahat, ito ay mga pakikipag-ugnayan ng client-server at multimedia. Gayunpaman, karamihan sa mga application sa Internet ay nangangailangan ng maaasahan at pare-parehong paghahatid. Hindi natutugunan ng UDP ang mga kinakailangang ito, kaya kailangan ng ibang protocol. Ang protocol na ito ay tinatawag na TCP, at ito ang workhorse ng Internet.

Mga Pangunahing Kaalaman sa TCP

Ang Transmission Control Protocol (TCP) ay partikular na idinisenyo upang magbigay ng maaasahang end-to-end na byte stream sa isang hindi mapagkakatiwalaang Internet network. Ang isang magkakaugnay na network ay naiiba sa isang stand-alone na network dahil ang iba't ibang mga seksyon nito ay maaaring may ibang mga topologies, bandwidth, latency value, laki ng packet, at iba pang mga parameter. Nakatuon ang pagbuo ng TCP sa kakayahan ng protocol na umangkop sa mga katangian ng internetwork at maging matatag sa harap ng iba't ibang problema.

Ang TCP protocol ay inilarawan sa RFC 793. Sa paglipas ng panahon, iba't ibang mga error at kamalian ang natuklasan, at sa ilang mga aspeto ang mga kinakailangan ay nabago. Ang isang detalyadong paglalarawan ng mga paglilinaw at pagwawasto na ito ay ibinibigay sa RFC 1122. Ang mga extension ng protocol ay ibinibigay sa RFC 1323.

Ang bawat makina na sumusuporta sa TCP protocol ay may TCP transport entity, na alinman sa isang library procedure, isang proseso ng user, o bahagi ng system kernel. Sa alinmang kaso, pinamamahalaan ng transport entity ang mga daloy ng TCP at ang interface sa IP layer. Ang TCP entity ay tumatanggap ng mga stream ng data ng user mula sa mga lokal na proseso, pinaghiwa-hiwalay ang mga ito sa mga piraso na hindi hihigit sa 64 KB (sa pagsasagawa, ang numerong ito ay karaniwang 460 bytes ng data, na nagpapahintulot sa kanila na mailagay sa isang Ethernet frame na may mga IP at TCP header), at ipinapadala ang mga ito bilang hiwalay na mga datagram ng IP. Kapag dumating sa makina ang mga datagram ng IP na naglalaman ng data ng TCP, ipinapasa ang mga ito sa entity ng TCP, na nagre-reconstruct sa orihinal na byte stream. Para sa pagiging simple, kung minsan ay gagamitin namin ang "TCP" upang sumangguni sa TCP transport entity (isang piraso ng software) o sa TCP protocol (isang hanay ng mga panuntunan). Mula sa konteksto ay magiging malinaw kung ano ang ibig sabihin. Halimbawa, sa expression na "Nagpapadala ang user ng data ng TCP," natural na ipinahiwatig ang transport entity na TCP.

Hindi ginagarantiyahan ng layer ng IP ang tamang paghahatid ng mga datagram, kaya dapat subaybayan ng TCP ang mga nag-expire na timeout at muling magpadala ng mga packet kung kinakailangan. Minsan dumating ang mga datagram sa maling pagkakasunud-sunod. TCP ay responsable din para sa pagbawi ng mga mensahe mula sa naturang datagrams. Kaya, ang TCP ay idinisenyo upang magbigay ng pagiging maaasahan na nais ng maraming mga gumagamit na hindi ibinibigay ng IP.

Modelo ng Serbisyo ng TCP

Ang serbisyo ng TCP ay batay sa tinatawag na mga socket (mga socket o endpoint) na ginawa ng parehong nagpadala at ang tatanggap. Tinalakay ang mga ito sa seksyong Berkeley Sockets. Ang bawat socket ay may numero (address) na binubuo ng IP address ng host at isang 16-bit na numero na lokal sa host na tinatawag na port. Ang isang port sa TCP ay tinatawag na isang TSAP address. Upang ma-access ang serbisyo ng TCP, dapat na malinaw na maitatag ang isang koneksyon sa pagitan ng isang socket sa sending machine at isang socket sa recipient machine.

Maaaring gamitin ang isang socket para sa maraming koneksyon nang sabay-sabay. Sa madaling salita, ang dalawa o higit pang mga koneksyon ay maaaring magtapos sa parehong socket. Ang mga koneksyon ay nakikilala sa pamamagitan ng mga socket ID sa magkabilang dulo - (socket1, socket2). Hindi ginagamit ang mga virtual channel number o iba pang identifier.

Ang mga numero ng port sa ibaba 1024, na tinatawag na mga sikat na port, ay nakalaan sa mga karaniwang serbisyo. Halimbawa, ang anumang proseso na gustong kumonekta sa isang host upang maglipat ng file gamit ang FTP ay maaaring makipag-ugnayan sa port 21 ng destination host at sa gayon ay makipag-ugnayan sa FTP daemon nito. Ang isang listahan ng mga sikat na port ay ibinigay sa website na www.iana.org.

Siyempre, maaari naming itali ang FTP daemon sa port 21 sa oras ng boot, pagkatapos ay itali ang telnet daemon sa port 23, atbp. Gayunpaman, kung gagawin namin iyon, mag-aaksaya lamang kami ng memorya sa impormasyon tungkol sa mga daemon na , sa katunayan , madalas silang walang ginagawa. Sa halip, karaniwan nang gumamit ng isang daemon, na tinatawag na inetd sa UNIX, na nakikipag-ugnayan sa maraming port at naghihintay para sa unang papasok na koneksyon. Kapag nangyari ito, gagawa ang inetd ng bagong proseso at hinihiling ang naaangkop na daemon para pangasiwaan ang kahilingan. Kaya, ang inetd lamang ang patuloy na aktibo, ang iba ay tinatawag lamang kapag may trabaho para sa kanila. Ang Inetd ay may espesyal na configuration file kung saan maaari itong matuto tungkol sa mga port assignment. Nangangahulugan ito na maaaring i-configure ng system administrator ang system upang ang mga persistent daemon ay nauugnay sa mga pinaka-abalang port (halimbawa, 80), at ang inetd ay nauugnay sa iba pa.

Ilang nakalaan na port
	Protocol	Paggamit
21	FTP	Paglilipat ng mga file
23	Telnet	Malayong pag-login
25	SMTP	E-mail
69	TFTP	Ang pinakasimpleng file transfer protocol
79	daliri	Paghahanap para sa impormasyon ng gumagamit
80	HTTP	World Wide Web
110	POP-3	Malayong pag-access sa email
119	NNTP	Mga newsgroup

Ang lahat ng koneksyon sa TCP ay full duplex at point-to-point. Ang ibig sabihin ng full duplex ay maaaring dumaloy ang trapiko sa magkasalungat na direksyon sa parehong oras. Ang point-to-point na koneksyon ay nangangahulugan na mayroon itong dalawang endpoint. Ang pagsasahimpapawid at multicasting ay hindi sinusuportahan ng TCP.

Ang koneksyon sa TCP ay isang byte stream, hindi isang stream ng mensahe. Ang mga hangganan sa pagitan ng mga mensahe ay hindi pinapanatili. Halimbawa, kung ang isang proseso ng pagpapadala ay nagsusulat ng apat na 512-byte na chunks ng data sa isang TCP stream, ang data na iyon ay maaaring maihatid sa proseso ng pagtanggap bilang apat na 512-byte na chunks, dalawang 1024-byte na chunks, isang 2048-byte na chunk, o iba pa. iba pa. Walang paraan para matukoy ng tatanggap kung paano isinulat ang data.

Ang mga file sa isang UNIX system ay mayroon ding katangiang ito. Hindi matukoy ng programang nagbabasa ng riles kung paano isinulat ang file na ito: block-by-block, byte-by-byte, o ganap na sabay-sabay. Tulad ng mga UNIX system file, ang mga TCP program ay walang ideya o walang pakialam sa kahulugan ng bytes. Ang isang byte para sa kanila ay isang byte lamang.

Sa sandaling makatanggap ang TCP ng data mula sa isang application, maaari itong ipadala nang sabay-sabay o i-buffer ito upang magpadala ng mas malaking bahagi ng data nang sabay-sabay, ayon sa pipiliin nito. Gayunpaman, kung minsan ang isang application ay nangangailangan ng data upang maipadala kaagad. Sabihin nating, halimbawa, na ang isang user ay nag-log in sa isang malayuang makina. Pagkatapos niyang magpasok ng command at pindutin ang Enter key, mahalagang maihatid kaagad sa remote machine ang linyang pinapasok niya, sa halip na ma-buffer hanggang sa makapasok ang susunod na linya. Upang pilitin ang data na mailipat nang walang pagkaantala, maaaring itakda ng isang application ang PUSH flag.

Ginamit ng ilang mas lumang application ang PUSH flag bilang isang delimiter ng mensahe. Bagama't minsan gumagana ang trick na ito, hindi lahat ng pagpapatupad ng TCP ay nagpapasa ng PUSH flag sa tumatanggap na application. Bilang karagdagan, kung ang TCP entity ay makakatanggap ng ilang higit pang mga naturang packet bago ipadala ang unang PUSH packet sa linya (iyon ay, ang output line ay abala), ang TCP entity ay magkakaroon ng karapatang ipadala ang lahat ng data na ito bilang isang solong datagram, hindi hinahati ang mga ito sa magkakahiwalay na bahagi.

Ang huling tampok ng serbisyo ng TCP na nagkakahalaga ng pagbanggit ay ang agarang data. Kapag ang isang user na nakikipag-ugnayan sa isang program ay interactive na pinindot ang Delete o Ctrl-C upang i-abort ang isang malayong proseso na isinasagawa, ang pagpapadala ng application ay naglalagay ng impormasyon ng kontrol sa stream ng data ng output at ipinapasa ito sa serbisyo ng TCP kasama ang URGENT na flag. Ang flag na ito ay nagiging sanhi ng TCP entity na huminto sa pag-iipon ng data at agad na ilabas ang anumang mayroon ito para sa koneksyon sa network.

Kapag dumating ang kagyat na data sa patutunguhan nito, naaantala ang pagtanggap ng application (iyon ay, "na-signal" sa terminolohiya ng UNIX), pagkatapos nito ay mababasa nito ang data mula sa input stream at maghanap ng kagyat na data sa kanila. Ang pagtatapos ng apurahang data ay minarkahan upang makilala ng application kung saan ito magtatapos. Ang pagsisimula ng agarang data ay hindi minarkahan. Ang application ay dapat malaman ito sa sarili nitong. Ang circuit na ito ay nagbibigay ng crude signaling mechanism, na iniiwan ang lahat ng iba pa sa application.

TCP protocol

Tatalakayin ng seksyong ito ang protocol ng TCP sa mga pangkalahatang tuntunin. Sa susunod na seksyon, tatalakayin natin ang header ng protocol, bawat field.

Ang isang pangunahing katangian ng TCP na tumutukoy sa buong istraktura ng protocol ay na sa isang koneksyon sa TCP, ang bawat byte ay may sariling 32-bit na sequence number. Sa mga unang taon ng Internet, ang pangunahing bilis ng paglipat ng data sa pagitan ng mga router sa mga naupahang linya ay 56 Kbps. Para sa isang host na patuloy na nagbobomba ng data sa pinakamataas na bilis, aabutin ng higit sa isang linggo para sa mga numero ng pagkakasunud-sunod na maging ganap na bilog. Sa kasalukuyang bilis, ang mga numero ng pagkakasunud-sunod ay maaaring maubos nang napakabilis, higit pa dito sa ibang pagkakataon. Ang mga hiwalay na 32-bit na sequence number ay ginagamit para sa mga pagkilala at para sa mekanismo ng sliding window, na tatalakayin din sa ibang pagkakataon.

Ang pagpapadala at pagtanggap ng mga entity ng TCP ay nagpapalitan ng data sa anyo ng mga segment. Ang isang segment ay binubuo ng isang nakapirming 20-byte na header (kasama ang isang opsyonal na bahagi), na maaaring sundan ng mga byte ng data. Ang laki ng mga segment ay tinutukoy ng TCP software. Maaari nitong pagsamahin ang data na nakuha bilang resulta ng ilang mga operasyon sa pagsulat sa isang segment, o, sa kabaligtaran, ipamahagi ang resulta ng isang pagsulat sa ilang mga segment. Ang laki ng mga segment ay nililimitahan ng dalawang limitasyon. Una, ang bawat segment, kabilang ang TCP header, ay dapat magkasya sa 65,515-byte na field ng payload ng IP packet. Pangalawa, ang bawat network ay may Maximum Transfer Unit (MTU), at dapat magkasya ang bawat segment sa MTU. Sa pagsasagawa, ang laki ng maximum transmission unit ay karaniwang 1500 bytes (na tumutugma sa laki ng Ethernet payload field), at sa gayon ay tinutukoy ang pinakamataas na limitasyon ng laki ng segment.

Ang pangunahing protocol na ginagamit ng mga TCP entity ay ang sliding window protocol. Kapag nagpapadala ng segment, magsisimula ang nagpadala ng timer. Kapag dumating ang segment sa patutunguhan nito, ang tumatanggap na TCP entity ay nagpapadala ng isang segment (na may data kung mayroong anumang ipapadala, o walang data) na may numero

pagkilala na katumbas ng sequence number ng susunod na inaasahang segment. Kung mag-expire ang timeout ng pagkilala, muling ipapadala ng nagpadala ang segment.

Bagama't mukhang simple ang protocol na ito, may ilang mga detalye na kailangang suriin nang mas detalyado. Maaaring dumating ang mga segment sa maling pagkakasunud-sunod. Kaya, halimbawa, posibleng dumating na ang mga byte 3072 hanggang 4095, ngunit hindi maipapadala ang isang pagkilala para sa kanila dahil hindi pa natatanggap ang mga byte 2048 hanggang 3071. Bilang karagdagan, ang mga segment ay maaaring magtagal sa network nang napakatagal na ang nagpadala ay nag-time out at ipinadala muli ang mga ito. Ang na-retransmit na segment ay maaaring magsama ng iba't ibang hanay ng mga fragment, kaya napakaingat na pangangasiwa ay kinakailangan upang matukoy ang mga byte number na natanggap na nang tama. Gayunpaman, dahil ang bawat byte sa stream ay natatanging kinilala sa pamamagitan ng offset nito, magagawa ang gawaing ito.

Dapat kayang harapin ng TCP ang mga problemang ito at lutasin ang mga ito nang mahusay. Maraming pagsisikap ang ginugol sa pag-optimize ng pagganap ng mga stream ng TCP. Sa susunod na seksyon, tatalakayin natin ang ilang mga algorithm na ginagamit sa iba't ibang pagpapatupad ng TCP protocol.

Header ng segment ng TCP

Ang bawat segment ay nagsisimula sa isang 20-byte na fixed-format na header. Maaaring sundan ito ng mga karagdagang field. Pagkatapos ng mga karagdagang field ay maaaring magkaroon ng hanggang 65,535 - 20 - 20 = 65,495 bytes ng data, kung saan ang unang 20 byte ay ang IP header at ang pangalawa ay ang TCP header. Maaaring walang data ang mga segment. Ang ganitong mga segment ay kadalasang ginagamit upang magpadala ng mga pagkilala at kontrolin ang mga mensahe.

Tingnan natin ang field ng TCP header ayon sa field. Ang mga field ng Receiver Port at Source Port ay mga identifier ng mga lokal na endpoint ng koneksyon. Ang numero ng port kasama ang host IP address ay bumubuo ng isang natatanging 48-bit na endpoint identifier. Ang isang pares ng naturang source at destination identifier ay natatanging kinikilala ang isang koneksyon.

Ang mga field ng Sequence Number at Confirmation Number ay gumaganap ng kanilang mga karaniwang function. Tandaan na ang field ng Acknowledgment Number ay tumutukoy sa susunod na byte na inaasahan, hindi ang huling byte na natanggap. Parehong 32-bit dahil ang bawat byte ng data sa isang stream ng TCP ay binibilang.

Ang field ng TCP Header Length ay naglalaman ng laki ng TCP header, na ipinahayag sa 32-bit na salita. Ang impormasyong ito ay kinakailangan dahil ang field na Opsyonal na Mga Patlang, at kasama nito ang buong header, ay maaaring may variable na haba. Sa esensya, tinutukoy ng field na ito ang offset mula sa simula ng segment hanggang sa field ng data, na sinusukat sa 32-bit na salita. Ito ay kapareho ng haba ng pamagat.

Susunod ay isang hindi nagamit na 6-bit na field. Ang katotohanan na ang larangang ito ay nakaligtas sa loob ng isang-kapat ng isang siglo ay isang patunay kung gaano kahusay ang pag-iisip ng disenyo ng TCP.

Sinusundan ito ng anim na 1-bit na flag. Ang URG bit ay nakatakda sa 1 kapag ginagamit ang field ng Urgent Data Pointer, na naglalaman ng byte offset mula sa kasalukuyang byte sequence number hanggang sa lokasyon ng apurahang data. Ito ay kung paano ipinapatupad ng TCP ang mga interrupt na mensahe. Tulad ng nabanggit na, tinitiyak lamang ng TCP protocol ang paghahatid ng signal ng user sa tatanggap, nang hindi interesado sa sanhi ng pagkaantala.

Kung ang ACK bit ay nakatakda sa 1, ang field ng Acknowledgment Number ay naglalaman ng makabuluhang data. Kung hindi, ang segment na ito ay hindi naglalaman ng isang pagkilala at ang field na Numero ng Pagkilala ay binabalewala lamang.

Ang PSH bit ay mahalagang PUSH flag na nagsasabi sa nagpadala na itulak ang data sa application sa sandaling matanggap nito ang packet, sa halip na itago ito sa isang buffer hanggang sa mapuno ito. (Ang tatanggap ay maaaring mag-buffer para sa higit na kahusayan.)

Ang RST bit ay ginagamit upang i-reset ang estado ng isang koneksyon na, dahil sa pagkabigo ng host o iba pang dahilan, ay naging deadlocked. Ginagamit din ito upang tanggihan ang isang hindi wastong segment o isang pagtatangka na lumikha ng isang koneksyon. Kung nakatanggap ka ng isang segment na may RST bit set, may ilang problema.

Ang SYN bit ay ginagamit upang magtatag ng isang koneksyon. Ang isang kahilingan sa koneksyon ay may SYN bit = 1 at ang ACK bit = 0, na nangangahulugan na ang field ng pagkilala ay hindi ginagamit. Ang tugon sa kahilingang ito ay naglalaman ng isang pagkilala, kaya ang mga halaga ng mga bit na ito ay: SYN= 1, ACK- 1. Kaya, ang SYN bit ay ginagamit upang ipahiwatig ang CONNECTION REQUEST at CONNECTION ACCEPTED na mga segment, at ang ACK bit ay ginagamit upang makilala sila sa isa't isa.

Ang FIN bit ay ginagamit upang wakasan ang koneksyon. Ito ay nagpapahiwatig na ang nagpadala ay wala nang data na ipapadala. Gayunpaman, kahit na matapos isara ang koneksyon, ang proseso ay maaaring magpatuloy na makatanggap ng data nang walang katapusan. Ang mga segment na may mga FIN at SYN bit ay may mga sequence number upang matiyak na ang mga ito ay naisakatuparan sa tamang pagkakasunud-sunod.

Ang kontrol sa daloy sa TCP protocol ay isinasagawa gamit ang isang sliding window na may variable na laki. Ang patlang na Laki ng Window ay nagsasabi kung gaano karaming mga byte ang maaaring ipadala pagkatapos ng acknowledgement byte. Ang halaga ng field na Laki ng Window ay maaaring zero, na nangangahulugan na ang lahat ng byte hanggang sa Acknowledgment Number-1 ay natanggap na, ngunit ang tatanggap ay kasalukuyang nagkakaroon ng ilang mga problema at hindi pa matanggap ang natitirang mga byte. Ang pahintulot para sa karagdagang paghahatid ay maaaring makuha sa pamamagitan ng pagpapadala ng isang segment na may parehong halaga ng field ng Acknowledgment Number at isang hindi zero na value ng field na Laki ng Window.

Sa ilang protocol, nauugnay ang mga frame acknowledgement sa mga pahintulot na magpatuloy sa paghahatid. Ang kaugnayang ito ay bunga ng mahigpit na naayos na laki ng sliding window sa mga protocol na ito. Sa TCP, ang mga pagkilala ay pinaghihiwalay mula sa mga pahintulot na magpadala ng data. Sa esensya, maaaring sabihin ng receiver, "Nakatanggap ako ng mga byte hanggang k-ro, ngunit ayaw kong magpatuloy sa pagtanggap ng data sa ngayon." Ang dibisyong ito (ipinahayag bilang isang sliding window na may variable na laki) ay nagbibigay sa protocol ng karagdagang flexibility. Tatalakayin natin ang aspetong ito nang mas detalyado sa ibaba.

Ginagamit ang field ng Checksum upang mapataas ang pagiging maaasahan. Naglalaman ito ng checksum ng header, data at pseudo-header. Kapag nagsasagawa ng mga kalkulasyon, ang Checksum field ay nakatakda sa zero, at ang data field ay nilagyan ng zero byte kung ang haba nito ay isang kakaibang numero. Idinaragdag lang ng checksum algorithm ang lahat ng 16-bit na salita sa complement ng dalawa at pagkatapos ay kinakalkula ang kabuuan ng complement. Bilang resulta, kapag sinuri ng tatanggap ang buong segment, kabilang ang field ng Checksum, dapat na 0 ang resulta.

Ang pseudo-header ay naglalaman ng 32-bit source at destination IP address, ang protocol number para sa TCP (6), at ang byte count para sa TCP segment (kabilang ang header). Ang pagsasama ng pseudo-header sa TCP checksum ay nakakatulong na matukoy ang mga maling naihatid na packet, bagama't sinisira nito ang hierarchy ng protocol dahil ang mga IP address dito ay nabibilang sa IP layer, hindi sa TCP layer. Ginagamit ng UDP ang parehong pseudo-header para sa checksum.

Ang field na Opsyonal na Mga Patlang ay nagbibigay ng mga karagdagang kakayahan na hindi sakop ng karaniwang header. Gamit ang isa sa mga field na ito, maaaring tukuyin ng bawat host ang maximum na laki ng field ng payload na maaari nitong tanggapin. Kung mas malaki ang sukat ng mga segment na ginamit, mas malaki ang kahusayan dahil binabawasan nito ang overhead ng 20-byte na mga header, ngunit hindi lahat ng host ay maaaring tumanggap ng napakalaking mga segment. Maaaring ipaalam ng mga host sa isa't isa ang maximum na laki ng field ng payload sa panahon ng pag-setup ng koneksyon. Bilang default, ang laki na ito ay 536 bytes. Kinakailangang tanggapin ng lahat ng host ang mga segment ng TCP na may sukat na 536 + 20 = 556 bytes. Ang bawat direksyon ay maaaring magkaroon ng sarili nitong maximum na laki ng field ng payload.

Para sa mga linyang may matataas na rate ng paglilipat at/o mataas na latency, masyadong maliit ang 64 KB na window. Kaya, para sa isang TZ line (44.736 Mbit/s), ang isang buong window ay maaaring ipadala sa linya sa loob lamang ng 12 ms. Kung ang oras ng round trip ay 50 ms (karaniwan para sa transcontinental optical cable), 3/4 ng oras na gugugol ng nagpadala sa paghihintay para sa isang pagkilala. Kapag nakikipag-usap sa pamamagitan ng satellite, mas malala pa ang sitwasyon. Ang mas malaking laki ng window ay mapapabuti ang kahusayan, ngunit ang 16-bit na patlang na Sukat ng Window ay hindi pinapayagan ito. Nagmungkahi ang RFC 1323 ng bagong parameter ng Window Scale, ang halaga kung saan maaaring magkasundo ang dalawang host kapag nagtatatag ng koneksyon. Binibigyang-daan ng numerong ito ang field na Laki ng Window na ilipat hanggang 14 bits sa kaliwa, na nagpapahintulot sa laki ng window na lumawak sa 230 byte (1 GB). Sa kasalukuyan, karamihan sa mga pagpapatupad ng TCP protocol ay sumusuporta sa feature na ito.

Ang isa pang opsyon, na iminungkahi sa RFC 1106 at ngayon ay malawakang ginagamit, ay ang paggamit ng selective retry protocol sa halip na mag-backtrack Kung ang destinasyon ay makakatanggap ng isang masamang segment na sinusundan ng isang malaking bilang ng mga mahusay, isang normal na TCP protocol ay magtatapos at ito ay magtatapos. muling ipadala ang lahat ng hindi kilalang mga segment, kabilang ang mga natanggap nang tama. Iminungkahi ng RFC 1106 ang paggamit ng mga negatibong pagkilala (NAK) upang payagan ang tatanggap na humiling ng isang segment o maramihang mga segment. Kapag natanggap na, maaaring kilalanin ng tatanggap na partido ang lahat ng data na nakaimbak sa buffer, kaya binabawasan ang dami ng data na muling ipinadala.

Ang mga transport layer protocol, na susunod sa hierarchy sa IP, ay ginagamit upang maglipat ng data sa pagitan ng mga proseso ng application na tumatakbo sa mga network node. Ang isang data packet na natanggap mula sa isang computer patungo sa isa pa sa pamamagitan ng Internet ay dapat ilipat sa isang proseso ng handler, at tiyak para sa isang partikular na layunin. Ang transport layer ay may pananagutan para dito. Mayroong dalawang pangunahing protocol sa antas na ito: TCP at UDP.

Kahulugan

TCP— transport protocol para sa paglilipat ng data sa mga TCP/IP network, na preliminarily na nagtatatag ng koneksyon sa network.

UDP- isang transport protocol na nagpapadala ng mga mensahe ng datagram nang hindi kinakailangang magtatag ng koneksyon sa isang IP network.

Paghahambing

Ang pagkakaiba sa pagitan ng mga protocol ng TCP at UDP ay ang tinatawag na "garantiya sa paghahatid". Ang TCP ay nangangailangan ng tugon mula sa kliyente kung kanino inihatid ang data packet, kumpirmasyon ng paghahatid, at para dito kailangan nito ng isang paunang itinatag na koneksyon. Gayundin, ang TCP protocol ay itinuturing na maaasahan, habang ang UDP ay nakatanggap pa ng pangalang "hindi mapagkakatiwalaang datagram protocol." Tinatanggal ng TCP ang pagkawala ng data, pagdoble at paghahalo ng mga packet, at pagkaantala. Pinapayagan ng UDP ang lahat ng ito, at hindi nangangailangan ng koneksyon upang gumana. Ang mga prosesong tumatanggap ng data sa pamamagitan ng UDP ay dapat gumawa ng magawa sa kung ano ang kanilang natatanggap, kahit na may mga pagkalugi. Kinokontrol ng TCP ang pagsisikip ng koneksyon, walang kontrol ang UDP maliban sa integridad ng mga natanggap na datagrams.

Sa kabilang banda, dahil sa gayong kawalan ng pagpili at kawalan ng kontrol, ang UDP ay naghahatid ng mga packet ng data (datagrams) nang mas mabilis, samakatuwid para sa mga application na idinisenyo para sa mataas na throughput at mabilis na pagpapalitan, ang UDP ay maaaring ituring na pinakamainam na protocol. Kabilang dito ang mga laro sa online at browser, pati na rin ang pagtingin sa mga programa streaming video at mga aplikasyon para sa komunikasyong video (o boses): ang pagkawala ng isang pakete, kumpleto o bahagyang, ay hindi nagbabago ng anuman, hindi na kailangang ulitin ang kahilingan, ngunit ang pag-download ay mas mabilis. Ang TCP protocol, na mas maaasahan, ay matagumpay na ginagamit kahit sa mga email program, na nagpapahintulot sa iyo na kontrolin hindi lamang ang trapiko, kundi pati na rin ang haba ng mensahe at ang bilis ng palitan ng trapiko.

Website ng mga konklusyon

1. Ginagarantiyahan ng TCP ang paghahatid ng mga packet ng data sa isang hindi nabagong anyo, pagkakasunud-sunod at walang pagkawala, hindi ginagarantiyahan ng UDP ang anuman.
2. Ang TCP ay nangangailangan ng isang paunang itinatag na koneksyon, ang UDP ay hindi nangangailangan ng isang koneksyon.
3. Nagbibigay ang UDP ng mas mataas na rate ng paglilipat ng data.
4. Ang TCP ay mas maaasahan at kinokontrol ang proseso ng pagpapalitan ng data.
5. Mas mainam ang UDP para sa mga programang naglalaro ng streaming video, videophony at telephony, at mga laro sa network.

Gumagamit ang UDP ng isang simpleng modelo ng paghahatid, na walang implicit na pakikipagkamay upang matiyak ang pagiging maaasahan, pag-order, o integridad ng data. Kaya, ang UDP ay nagbibigay ng isang hindi mapagkakatiwalaang serbisyo, at ang mga datagram ay maaaring dumating nang hindi maayos, madoble, o mawala nang walang bakas. Ang UDP ay nagpapahiwatig na ang pagsuri at pagwawasto ng error ay hindi kinakailangan o dapat gawin ng application. Ang mga application na sensitibo sa oras ay madalas na gumagamit ng UDP dahil mas mainam na mag-drop ng mga packet kaysa maghintay para sa mga naantalang packet, na maaaring hindi posible sa mga real-time na system. Kung kinakailangan upang iwasto ang mga error sa layer ng interface ng network, maaaring gamitin ng application ang TCP o SCTP na idinisenyo para sa layuning ito.

Ang katangian ng UDP bilang stateless protocol ay kapaki-pakinabang din para sa mga server na tumutugon sa maliliit na kahilingan mula sa malaking bilang ng mga kliyente, tulad ng DNS at streaming media application tulad ng IPTV, Voice over IP, IP tunneling protocol, at maraming online na laro.

Mga port ng serbisyo

Ang UDP ay hindi nagbibigay ng anumang mga garantiya sa paghahatid ng mensahe sa upper-layer na protocol at hindi nag-iimbak ng estado ng mga ipinadalang mensahe. Para sa kadahilanang ito, kung minsan ang UDP ay tinatawag na Unreliable Datagram Protocol.

Bago kalkulahin ang checksum, ang mensahe ng UDP ay may padded sa dulo na may zero bits sa isang haba na maramihang 16 bits (ang pseudo-header at karagdagang zero bits ay hindi ipinadala kasama ng mensahe). Checksum field sa UDP header sa panahon ng pagkalkula ng checksum ipinadala ang mga mensahe ay tinatanggap bilang null.

Upang kalkulahin ang checksum, ang pseudo-header at UDP na mensahe ay nahahati sa mga salita (1 salita = 2 byte (octets) = 16 bits). Pagkatapos ay kinakalkula ang bitwise complement ng kabuuan ng lahat ng salita na may bitwise complement. Ang resulta ay nakasulat sa kaukulang field sa UDP header.

Ang isang checksum value na zero ay nakalaan at nangangahulugan na ang datagram ay walang checksum. Kung ang kalkuladong checksum ay katumbas ng zero, ang field ay puno ng mga binary unit.

Kapag natanggap ang isang mensahe, kinakalkula muli ng tatanggap ang checksum (isinasaalang-alang ang field ng checksum), at kung ang resulta ay isang binary na numero ng labing-anim na numero (iyon ay, 0xffff), kung gayon ang checksum ay itinuturing na nag-converge. Kung ang kabuuan ay hindi nadagdagan (ang data ay nasira sa panahon ng paghahatid), ang datagram ay nawasak.

Halimbawa ng pagkalkula ng checksum

Halimbawa, kalkulahin natin ang checksum ng ilang 16-bit na salita: 0x398a, 0xf802, 0x14b2, 0xc281. Hanapin ang kanilang kabuuan na may bitwise complement.
0x398a + 0xf802 = 0x1318c → 0x318d
0x318d + 0x14b2 = 0x0463f → 0x463f
0x463f + 0xc281 = 0x108c0 → 0x08c1
Ngayon nakita namin ang bitwise na pandagdag ng resultang resulta:

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e o, kung hindi - 0xffff − 0x08c1 = 0xf73e . Ito ang gustong checksum.

Kapag kinakalkula ang checksum, muling ginagamit ang isang pseudo-header, na tinutulad ang isang tunay na IPv6 header:

Bits	0 – 7								8 – 15								16 – 23								24 – 31
0	Address ng pinagmulan
32
64
96
128	Address ng tatanggap
160
192
224
256	haba ng UDP
288	Mga zero																								Susunod na pamagat
320	Pinagmulan na port																Destination port
352	Ang haba																Checksum
384+	Data

Ang source address ay kapareho ng sa IPv6 header. Address ng tatanggap - huling tatanggap; kung ang IPv6 packet ay hindi naglalaman ng isang Routing header, ito ang magiging destination address mula sa IPv6 header, kung hindi, sa panimulang node, ito ang magiging address ng huling elemento ng routing header, at sa receiving node, ang patutunguhang address mula sa IPv6- header. Ang halaga ng Susunod na Header ay katumbas ng halaga ng protocol - 17 para sa UDP. Haba ng UDP - ang haba ng header at data ng UDP.

Pagiging maaasahan at solusyon sa mga problema sa labis na karga

Dahil sa kakulangan ng pagiging maaasahan nito, ang mga aplikasyon ng UDP ay dapat na handa para sa ilang pagkawala, error, at pagdoble. Ang ilan sa mga ito (halimbawa, TFTP) ay maaaring opsyonal na magdagdag ng mga elementarya na mekanismo ng pagiging maaasahan sa antas ng aplikasyon.

Ngunit mas madalas kaysa sa hindi, ang mga naturang mekanismo ay hindi ginagamit ng mga aplikasyon ng UDP at kahit na nakakasagabal sa kanila. Ang streaming media, real-time multiplayer gaming, at VoIP ay mga halimbawa ng mga application na kadalasang gumagamit ng UDP protocol. Sa mga partikular na application na ito, ang pagkawala ng packet ay karaniwang hindi isang malaking problema. Kung nangangailangan ang application ng mataas na antas ng pagiging maaasahan, maaaring gumamit ng ibang protocol (TCP) o mga erasure code.

Ang isang mas malaking potensyal na problema ay, hindi tulad ng TCP, ang mga application na nakabatay sa UDP ay hindi kinakailangang magkaroon ng mahusay na kontrol sa pagsisikip at mga mekanismo ng pag-iwas. Ang mga application na UDP na sensitibo sa congestion na kumukonsumo ng malaking bahagi ng available na bandwidth ay maaaring makompromiso ang katatagan ng Internet.

Ang mga mekanismo ng network ay idinisenyo upang mabawasan ang mga potensyal na epekto ng kasikipan sa panahon ng hindi nakokontrol, mataas na bilis ng pag-load. Ang mga elemento ng network tulad ng mga router na gumagamit ng mga packet queues at drop technique ay kadalasang ang tanging mga tool na magagamit upang pabagalin ang labis na trapiko ng UDP. Ang DCCP (Datagram Congestion Control Protocol) ay idinisenyo bilang bahagyang solusyon sa potensyal na problemang ito sa pamamagitan ng pagdaragdag ng mga mekanismo sa end host upang masubaybayan ang congestion para sa mga high-speed na stream ng UDP gaya ng streaming media.

Mga aplikasyon

Maraming pangunahing application sa Internet ang gumagamit ng UDP, kabilang ang DNS (kung saan ang mga kahilingan ay dapat na mabilis at binubuo lamang ng isang kahilingan na sinusundan ng isang packet ng tugon), Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP), Dynamic Host Configuration (DHCP) .

Ang trapiko ng boses at video ay karaniwang dinadala gamit ang UDP. Ang mga live na video at audio streaming protocol ay idinisenyo upang mahawakan ang mga random na pagkawala ng packet upang ang kalidad ay bahagyang bumaba sa halip na magdulot ng malalaking pagkaantala kapag ang mga nawawalang packet ay muling ipinadala. Dahil parehong gumagana ang TCP at UDP sa parehong network, napansin ng maraming kumpanya na ang kamakailang pagtaas sa trapiko ng UDP mula sa mga real-time na application na ito ay humahadlang sa pagganap ng mga TCP application tulad ng database o mga accounting system. Dahil ang parehong negosyo at real-time na mga aplikasyon ay mahalaga sa mga kumpanya, ang pagbuo ng mga de-kalidad na solusyon sa mga problema ay itinuturing ng ilan bilang isang pangunahing priyoridad.

Paghahambing ng UDP at TCP

Ang TCP ay isang protocol na nakatuon sa koneksyon, na nangangahulugang isang "pagkakamay" ay kinakailangan upang magtatag ng koneksyon sa pagitan ng dalawang host. Kapag naitatag na ang koneksyon, maaaring magpadala ang mga user ng data sa parehong direksyon.

• pagiging maaasahan- Pinamamahalaan ng TCP ang pagkilala sa mensahe, muling pagpapadala, at timeout. Maraming mga pagtatangka ang ginawa upang maihatid ang mensahe. Kung mawala ito sa daan, hihilingin muli ng server ang nawalang bahagi. Sa TCP walang nawawalang data o (sa kaso ng maraming timeout) mga sirang koneksyon.

• Kaayusan- Kung ang dalawang mensahe ay ipinadala nang sunud-sunod, ang unang mensahe ay unang makakarating sa tatanggap ng aplikasyon. Kung dumating ang mga chunks ng data sa maling pagkakasunud-sunod, ipinapadala ng TCP ang out-of-order na data sa isang buffer hanggang sa ma-order at maipadala ang lahat ng data sa application.

• Kabigatan- Nangangailangan ang TCP ng tatlong packet para magtatag ng socket connection bago magpadala ng data. Sinusubaybayan ng TCP ang pagiging maaasahan at kasikipan.

• Threading- ang data ay binabasa bilang isang stream ng mga byte, walang mga espesyal na pagtatalaga para sa mga hangganan ng mensahe o mga segment na ipinadala.

Ang UDP ay isang mas simple, nakabatay sa mensahe, walang koneksyon na protocol. Ang mga uri ng protocol na ito ay hindi nagtatag ng isang nakalaang koneksyon sa pagitan ng dalawang host. Ang komunikasyon ay nakakamit sa pamamagitan ng pagpasa ng impormasyon sa isang direksyon mula sa isang mapagkukunan patungo sa isang tatanggap nang hindi sinusuri ang kahandaan o estado ng tatanggap. Gayunpaman, ang pangunahing bentahe ng UDP sa TCP ay nasa Voice over Internet Protocol (VoIP) na mga application, kung saan ang anumang pakikipagkamay ay hahadlang sa magandang komunikasyon ng boses. Sa VoIP, ang mga end user ay inaasahang magbigay ng anumang kinakailangang pagkilala sa pagtanggap ng mensahe sa real time.

• Hindi mapagkakatiwalaan- kapag ang isang mensahe ay ipinadala, ito ay hindi alam kung ito ay makakarating sa kanyang patutunguhan - ito ay maaaring mawala sa daan. Walang mga konsepto tulad ng pagkumpirma, muling pagpapadala, pag-timeout.

• Disorder- kung ang dalawang mensahe ay ipinadala sa parehong tatanggap, kung gayon ang pagkakasunud-sunod kung saan nakamit nila ang layunin ay hindi mahulaan.

• Kagaanan- walang pag-order ng mga mensahe, walang pagsubaybay sa mga koneksyon, atbp. Ito ay isang maliit na layer ng transportasyon na dinisenyo sa IP.

• Mga Datagram- Ang mga packet ay ipinapadala nang isa-isa at sinusuri ang integridad lamang kung dumating ang mga ito. Ang mga packet ay may ilang partikular na hangganan na iginagalang kapag natanggap, ibig sabihin, ang isang read operation sa receiving socket ay maglalabas ng mensahe gaya ng orihinal na ipinadala nito.

• Walang overload control- Ang UDP mismo ay hindi umiiwas sa pagsisikip. Posible para sa mga high-bandwidth na application na maging sanhi ng pagbagsak ng congestion maliban kung nagpapatupad sila ng mga kontrol sa antas ng application.

Mga Link ng RFC

• RFC 768 – User Datagram Protocol
• RFC 2460 – Bersyon 6 ng Detalye ng Internet Protocol (IPv6)
• RFC 2675 - IPv6 Jumbograms
• RFC 4113 – Base ng Impormasyon sa Pamamahala para sa UDP
• RFC 5405 – Mga Alituntunin sa Paggamit ng Unicast UDP para sa Mga Designer ng Application

Tingnan din

Mga link

• Kurose, J. F.; Ross, K. W. (2010). Computer Networking: Isang Top-Down Approach (5th ed.). Boston, MA: Edukasyon ng Pearson. ISBN 978-0-13-136548-3.
• Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
• [email protected]. "UDP Protocol Overview". IPv6.com. Hinango noong Agosto 17, 2011.
• Clark, M.P. (2003). Mga Network ng Data IP at ang Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
• Postel, J. (Agosto 1980). RFC 768: User Datagram Protocol. Task Force sa Internet Engineering. Nakuha mula sa http://tools.ietf.org/html/rfc768
• Deering S. & Hinden R. (Disyembre 1998). RFC 2460: Internet Protocol, Bersyon 6 (IPv6) Detalye. Task Force sa Internet Engineering. Nakuha mula sa http://tools.ietf.org/html/rfc2460
• "Ang epekto ng UDP sa Mga Application ng Data". networkperformancedaily.com. Hinango noong Agosto 17, 2011.
• D. Comer. Internetworking gamit ang TCP/IP. Kabanata 11. UDP Protocol.

Mga pangunahing protocol ng TCP/IP ayon sa mga antas ng modelo ng OSI (Listahan ng mga TCP at UDP port)
Pisikal
Duct

User Datagram Protocol - UDP

UDP protocol ay isa sa dalawang transport layer protocol na ginagamit sa TCP/IP protocol stack. Pinapayagan ng UDP ang isang application program na magpadala ng mga mensahe nito sa isang network na may kaunting overhead na nauugnay sa pag-convert ng mga protocol ng layer ng application sa IP. Gayunpaman, ang application program mismo ay dapat mag-ingat sa pagkumpirma na ang mensahe ay naihatid sa destinasyon nito. Ang UDP datagram (mensahe) na header ay kamukha ng ipinapakita sa Figure 2.10.

kanin. 2.10. UDP na istraktura ng header ng mensahe

Ang UDP protocol data unit ay tinatawag na UDP packet o user datagram. Ang isang UDP packet ay binubuo ng isang header at isang data field na naglalaman ng application layer packet. Ang header ay may simpleng format at binubuo ng apat na dalawang-byte na field:

UDP source port - numero ng port ng proseso ng pagpapadala,

UDP destination port - numero ng port ng proseso ng tatanggap,

Haba ng mensahe ng UDP - haba ng UDP packet sa mga byte,

UDP checksum - checksum ng UDP packet

Hindi lahat ng field ng isang UDP packet ay dapat punan. Kung ang ipinadalang datagram ay hindi umaasa ng tugon, ang mga zero ay maaaring ilagay sa lugar ng address ng nagpadala. Maaari mo ring tanggihan na kalkulahin ang checksum, ngunit mangyaring tandaan na ang IP protocol ay kinakalkula ang checksum para lamang sa IP packet header, hindi pinapansin ang field ng data

Ang mga port sa header ay tumutukoy sa UDP protocol bilang isang multiplexer na nagpapahintulot sa mga mensahe mula sa mga application na kolektahin at ipadala sa layer ng protocol. Sa kasong ito, ang application ay gumagamit ng isang partikular na port. Ang mga application na nakikipag-ugnayan sa network ay maaaring gumamit ng iba't ibang port, na makikita sa packet header. Sa kabuuan, 216 iba't ibang port ang maaaring tukuyin. Ang unang 256 port ay itinalaga sa tinatawag na "mga kilalang serbisyo", na kinabibilangan, halimbawa, UDP port 53, na itinalaga sa serbisyo ng DNS.

Patlang Ang haba tinutukoy ang kabuuang haba ng mensahe. Patlang Checksum nagsisilbing kontrolin ang integridad ng data. Dapat pangalagaan ng isang application na gumagamit ng UDP protocol ang integridad ng data sa pamamagitan ng pagsusuri sa mga field ng Checksum at Length. Bilang karagdagan, kapag nagpapalitan ng data sa pamamagitan ng UDP, ang mismong programa ng aplikasyon ay dapat mag-ingat sa pagsubaybay sa paghahatid ng data sa tatanggap. Ito ay karaniwang nakakamit sa pamamagitan ng pagpapalitan ng mga kumpirmasyon sa paghahatid sa pagitan ng mga programa ng aplikasyon.

Ang pinakakilalang UDP-based na mga serbisyo ay ang BIND Domain Name Service at ang NFS Distributed File System. Pagbabalik sa halimbawa ng traceroute, ang program na ito ay gumagamit din ng UDP transport. Sa totoo lang, ito ay ang mensahe ng UDP na ipinadala sa network, ngunit ito ay gumagamit ng isang port na walang serbisyo, kung kaya't ang isang ICMP packet ay nabuo, na nakakakita ng kakulangan ng serbisyo sa receiving machine kapag ang packet sa wakas ay umabot sa patutunguhang makina.

Transfer Control Protocol - TCP

Kung ang pagsubaybay sa kalidad ng paghahatid ng data sa network ay mahalaga para sa isang aplikasyon, kung gayon sa kasong ito ang TCP protocol ay ginagamit. Ang protocol na ito ay tinatawag ding isang maaasahan, nakatuon sa koneksyon, at naka-orient sa daloy na protocol. Bago talakayin ang mga katangiang ito ng protocol, isaalang-alang natin ang format ng datagram na ipinadala sa network (Larawan 2.11). Ayon sa istrukturang ito, ang TCP, tulad ng UDP, ay may mga port. Ang unang 256 port ay itinalaga sa WKS, ang mga port 256 hanggang 1024 ay itinalaga sa mga serbisyo ng Unix, at ang iba ay magagamit sa iyong paghuhusga. Sa bukid Sequence Number ang numero ng packet ay tinukoy sa pagkakasunud-sunod ng mga packet na bumubuo sa buong mensahe, na sinusundan ng isang field ng pagkilala Bilang ng Kaalaman at iba pang impormasyon sa pagkontrol.

kanin. 2.11. TCP packet structure

Ang source port (SOURS PORT) ay sumasakop ng 2 byte, kinikilala ang proseso ng pagpapadala;

Ang destinasyong port (DESTINATION PORT) ay sumasakop ng 2 byte, kinikilala ang proseso ng tatanggap;

Ang sequence number (SEQUENCE NUMBER) ay sumasakop ng 4 na byte, na nagpapahiwatig ng byte number, na tumutukoy sa offset ng segment na nauugnay sa stream ng ipinadalang data;

Ang nakumpirmang numero (ACNOWLEDGEMENT NUMBER) ay sumasakop ng 4 na byte, naglalaman ng maximum na byte na numero sa natanggap na segment, na nadagdagan ng isa; ito ang halaga na ginagamit bilang isang resibo;

Haba ng Header (HLEN) ay 4 bits ang haba at nagpapahiwatig ng haba ng TCP segment header, na sinusukat sa 32-bit na salita. Ang haba ng header ay hindi naayos at maaaring mag-iba depende sa mga halaga na itinakda sa field na Mga Opsyon;

Ang Reserve (RESERVED) ay sumasakop ng 6 bits, ang field ay nakalaan para magamit sa ibang pagkakataon;

Ang mga code bit (CODE BITS) ay sumasakop ng 6 na bits at naglalaman ng impormasyon ng serbisyo tungkol sa uri ng isang partikular na segment, na tinukoy sa pamamagitan ng pagtatakda ng kaukulang mga bit ng field na ito sa isa:

URG - agarang mensahe;

ACK - resibo para sa natanggap na segment;

PSH - humiling na magpadala ng mensahe nang hindi naghihintay na mapunan ang buffer;

RST - humiling na ibalik ang koneksyon;

SYN - mensahe na ginagamit upang i-synchronize ang mga counter ng ipinadalang data kapag nagtatatag ng isang koneksyon;

Ang FIN ay isang senyales na ang bahagi ng pagpapadala ay umabot sa huling byte sa ipinadalang stream ng data.

Ang isang window (WINDOW) ay sumasakop ng 2 byte, naglalaman ng ipinahayag na halaga ng laki ng window sa mga byte;

Ang checksum (CHECKSUM) ay tumatagal ng 2 byte at kinakalkula bawat segment;

Ang urgent pointer (URGENT POINTER) ay sumasakop ng 2 bytes, ay ginagamit kasabay ng URG code bit, ay nagpapahiwatig ng pagtatapos ng data na dapat mapilit na matanggap, sa kabila ng buffer overflow;

OPTIONS - ang field na ito ay may variable na haba at maaaring wala sa kabuuan, ang maximum na laki ng field ay 3 bytes;

ginagamit upang malutas ang mga pantulong na problema, halimbawa, kapag pumipili ng maximum na laki ng segment;

Ang PADDING, isang variable-length na padding, ay isang dummy field na ginagamit upang dalhin ang laki ng header sa isang integer na bilang ng mga 32-bit na salita. Ang pagiging maaasahan ng TCP ay nakasalalay sa katotohanan na ang data source ay umuulit sa pagpapadala nito maliban kung ito ay nakatanggap ng kumpirmasyon mula sa tatanggap sa loob ng isang tiyak na tagal ng panahon na ito ay matagumpay na natanggap. Ang mekanismong ito ay tinatawag. Tulad ng nauna naming tinukoy, ang yunit ng paghahatid (data packet, mensahe, atbp.) sa mga termino ng TCP ay tinatawag na isang segment. Mayroong checksum field sa TCP header. Kung ang data ay nasira sa panahon ng paghahatid, ang module na naghihiwalay sa mga segment ng TCP mula sa mga IP packet ay maaaring matukoy ito gamit ang checksum. Ang nasirang packet ay nawasak at walang ipinadala sa pinagmulan. Kung ang data ay hindi nasira, ipapasa ito sa pagpupulong ng mensahe ng aplikasyon, at isang pagkilala ay ipapadala sa pinagmulan.

Ang oryentasyon ng koneksyon ay tinutukoy ng katotohanan na bago magpadala ng isang segment ng data, ang pinagmulan at patutunguhan na mga module ng TCP ay nagpapalitan ng impormasyon ng kontrol. Ang palitan na ito ay tinatawag pakikipagkamay(literal na "pagkakamay"). Gumagamit ang TCP ng three-phase hand-shake:

Ang pinagmulan ay nagtatatag ng koneksyon sa patutunguhan sa pamamagitan ng pagpapadala dito ng isang packet na may flag na Synchronize Sequence Numbers (SYN). Ang numero sa sequence ay kinikilala ang packet number sa application message. Hindi ito kailangang maging 0 o isa.

Ngunit ang lahat ng iba pang mga numero ay gagamitin ito bilang isang base, na magpapahintulot sa mga packet na makolekta sa tamang pagkakasunud-sunod;

Tumugon ang tatanggap gamit ang isang numero sa field ng pagkilala sa resibo ng SYN na tumutugma sa numerong itinakda ng pinagmulan. Bilang karagdagan, ang field na "numero sa pagkakasunud-sunod" ay maaari ring magpahiwatig ng numero na hiniling ng pinagmulan;

Kinukumpirma ng source na tinanggap nito ang destination segment at ipinapadala ang unang piraso ng data.

Graphically ang prosesong ito ay ipinakita sa Figure 2.12.

kanin. 2.12. Pagtatatag ng koneksyon sa TCP

Sa sandaling maitatag ang koneksyon, ang pinagmulan ay nagpapadala ng data sa tatanggap at naghihintay para sa kumpirmasyon mula sa kanya na ito ay natanggap, pagkatapos ay ipinapadala muli ang data, at iba pa, hanggang sa matapos ang mensahe. Nagtatapos ang mensahe kapag nakatakda ang FIN bit sa field ng mga flag, na nangangahulugang "wala nang data".

Malinaw na ang streaming na kalikasan ng protocol at ang pangangailangan upang kumpirmahin ang pagtanggap ng data ay nagbibigay ng problema sa bilis ng paglipat ng data. Upang malutas ang problemang ito, gumamit ng "window" - isang field - window. Ang ideya ng paggamit ng window ay medyo simple: magpadala ng data nang hindi naghihintay ng kumpirmasyon ng pagtanggap nito. Nangangahulugan ito na ang pinagmulan ay nagpapadala ng isang tiyak na halaga ng data na katumbas ng window nang hindi naghihintay ng kumpirmasyon ng pagtanggap nito, at pagkatapos nito ay huminto ito sa paghahatid at naghihintay para sa kumpirmasyon. Kung nakatanggap ito ng kumpirmasyon para lamang sa bahagi ng ipinadalang data, magsisimula itong magpadala ng bagong bahagi mula sa numerong kasunod ng nakumpirma. Ito ay ipinapakita nang grapiko sa Figure 2.13.

kanin. 2.13. Mekanismo ng paghahatid ng data ng TCP

Sa halimbawang ito, nakatakda ang window sa 250 bytes ang lapad. Nangangahulugan ito na ang kasalukuyang segment ay isang segment na may SYN offset na 250 bytes. Gayunpaman, pagkatapos na mailipat ang buong window, ang source TCP module ay nakatanggap ng isang pagkilala upang makatanggap lamang ng unang 100 byte. Samakatuwid, ang paglipat ay magsisimula sa 101 byte, at hindi mula sa 251.

Kaya, napagmasdan namin ang lahat ng mga pangunahing katangian ng TCP protocol. Nananatili lamang itong pangalanan ang pinakasikat na mga application na ginagamit ng TCP para sa pagpapalitan ng data. Ang mga ito ay pangunahing TELNET at FTP, pati na rin ang HTTP protocol, na siyang puso ng World Wide Web.

Patigilin natin ng kaunti ang pag-uusap tungkol sa mga protocol at ibaling natin ang ating pansin sa isang mahalagang bahagi ng buong TCP/IP system bilang mga IP address.