UDP
Оваа статија можеби бара дополнително внимание за да ги исполни стандардите за квалитет на Википедија. Ве молиме подобрете ја оваа статија ако можете. |
Оваа статија или заглавие има потреба од викифицирање за да ги исполни стандардите за квалитет на Википедија. Ве молиме помогнете во подобрувањето на оваа статија со соодветни внатрешни врски. |
Корисничкиот Протокол(UDP) е еден од клучните делови на Интернет протокол(IP), множество од мрежни протоколи кои се користат за Интернет. Со овој протокол, компјутерските апликации можат да праќаат пораки, во тој случај познати како датаграми. Протоколот е дизајниран од Дејвид Рид во 1980 година и конечно е дефиниран во RFC 768. Корисничкиот податочен протокол користи едноставен модел без имплицитни ракувачки дијалози за обезбедување сигурност, подреденост, или интегритет на податоците. Според ова, овој кориснички протокол овозможува несигурен сервис и датаграмите може да не пристигнат по ред, некаде се појавуваат дупликати, или исчезнуваат без претходна најава. Протоколот претпоставува дека грешката при проверка и корегирање е или непотребна или изведена во апликацијата, притоа избегнувајќи ја големата контрола на таа обработка на интерфејсот на мрежното ниво. Апликацијата која зависи од времето, честопати го користи овој протокол бидејќи испуштените пакети се подобри од чекањето на задоцнетите пакети. UDP е исто така корисна за опслужувачите одговарајќи на мал број прашања од огромен број на клиенти. За разлика од TCP, UDP е компатибилен со емитуваниот пакет(праќање на податоци или пораки од еден до сите компјутери на локалната мрежа) и мултикастингот (праќање на сите претплатници).
Портови на сервисот
уредиUDP апликациите користат сокети пакети за да воспостават хост до хост комуникација. Апликацијата поврзува приклучок до нејзината крајна точка на пренесувањето на податоци, којашто е комбинација на IP-адреса и порт на сервисот. Портот е структурен софтвер која е недефинирана од број на порт, 16 бита целобројна вредност, дозволувајќи им на броевите на портовите да бидат помеѓу 0 и 65 535. Портот 0 е резервиран, но е дозволен како вредност ако испраќачкиот процес не очекува пораки за возврат.
Internet Assigned Numbers Authority ги поделува бројните портови во три нивоа. Бројните портови како 0 преку 1023 се користени за заеднички, добро познати сервиси. Unix оперативните системи, кои користат една од овие порти бараат дозвола од корисникот кој го користи самиот оперативниот систем. Бројните портови 1024 преку 49 151 се регистрираните портови користени за IANA-регистрирани сервиси. Портовите 49 152 преку 65 535 се динамични портови кои не се за било кој специфичен сервис и може да биде користен за било која цел. Тие исто така се користени како краткотрајни портови, чијшто софтвер работи на хостот и може случајно да одбере порт со цел да се дефинира самиот. Всушност, тие се користени како привремени портови примарно од клиенти кои комуницираат со опслужувачите.
Пакет на структури
уредиUDP е минимална порака на транспортното ниво на протоколот документиран во IETF RFC 768. UDP не овозможува гаранции на протоколот на горното ниво за достава на пораки. Поради оваа цел, UDP понекогаш се однесува како Несигурен Датаграм протокол. UDP овозможува апликација мултиплексирање (преку бројот на порти) и проверка на интегритетот (преку проверка) на заглавјето. Ако сигурното пренесување е посакувано, мора да биде имплементирано во апликацијата на корисникот.
UDP заглавјето се состои од 4 полиња, од кое што секое е 2 бајти(16 бита). Употребата на две од нив е опционално во IPv4. Во IPv6 само изворот на порта е опционален(види подолу).
Број на изворна порта
уредиОва поле ја идентификува портата на испраќачот кој треба значајно да биде порта за возвраќање ако е тоа потребно. Ако не е користен, тогаш треба да биде нула. Ако изворот на хостот е клиентот, бројот на портата би требало да биде еден краткотраен број на порта. Ако изворот на хостот е опслужувачот, бројот на порта би требало да биде добро познат број на порта.
Број на дестинациска порта
уредиОва поле ја идентификува портата на примачот на кој е баран.Слично на изворот на број на порта, ако клиентот е дестинациски хост тогаш бројот на порта би требало да биде краткотраен број на порта и ако дестинацискиот хост е опслужувачот тогаш број на порта би требало да биде добро познат број на порта.
Должина
уредиПоле кое ја одредува должината во бајти на целиот пакет:заглавје и податоци. Минималната должина е 8 бајти откога тоа е должина на заглавјето. Големината на полето поставува теоретска граница од 65,535 бајти (8 бајти заглавје + 65,527 бајти податоци) за UDP пакетот. Практичната граница за должина на податоци која е наметната од подвлечениот IPv4 протокол е 65,507 бајти (65,535 − 8 бајти UDP заглавје − 20 бајти IP заглавје).
Проверка
уредиПолето за проверка е употребено за проверка на грешки на заглавјето и податоците. Ако проверката не е генерирана од предавателот, полето ја користи вредноста со сите нули. Ова поле не е опционално за IPv6.
Проверка на пресметка
уредиОвој метод користен за пресметување на проверката е дефиниран во RFC 768: Проверка е 16-от бит на едниот комплемент на сумата на истиот комплемент на псевдо заглавјето на информација од IP заглавјето, UDP заглавјето, и податоците, поставени со нула октети на крајот(ако е потребно) за да се направи повеќе од два октети. Со други зборови, сите 16-битни збора се сумирани да го користат едниот аритметички комплемент . Сумата на едниот комплемент ја надополнува вредноста на UDP полето за проверка. Ако проверката за пресметување резултати на вредноста нула(сите 16 бита нули) треба да биде пратена како едниот комплемент(сите да бидат први). Разликата помеѓу IPv4 и IPv6 е во податоците употребени да ја пресметуваат проверката.
IPv4 ПСЕВДО-ЗАГЛАВЈЕ
уредиКога UDP работи преку IPv4, проверката се пресметува користејќи ПСЕВДО-ЗАГЛАВЈЕ што содржи некои од истите информации за вистинското IPv4 заглавје. ПСЕВДО-ЗАГЛАВЈЕТО не е вистински IPv4 заглавје користен за праќање на IP пакет. Изворот и одредиштето на адреси се оние во IPv4 заглавјето. Должината на полето на UDP е должината на UDP заглавјето и податоците. UDP проверката на пресметката е опционална за IPv4. Ако не е користена проверката треба да биде наместена до вредноста нула.
IPv6 ПСЕВДО-ЗАГЛАВЈЕ
уредиСекое транспортно или друго горно ниво на протоколот вклучува адреси од IP заглавјето во неговата проверка на пресметка која мора да биде сменета за употреба на IPv6 и да ги вклучи 128-битните IPv6 адреси. Кога се пресметува проверката, повторно ПСЕВДО-ЗАГЛАВЈЕТО е користен за имитирање на вистинското IPv6 заглавje. Изворот на адреса е еден во IPv6 заглавје. Дестинациската адреса е последното одредиште, ако IPv6 пакетот не содржи Насочувачко заглавје, кое ќе биде дестинациска адреса во IPv6 заглавје, инаку, кај првичниот јазол, ќе биде адресата на последниот елемент на Насочувачкото заглавје и кај приемниот јазол, ќе биде дестинациската адреса во IPv6 заглавјето. Вредноста на полето на Следното Заглавје е вредноста на протоколот за UDP: 17. Полето на UDP должината е должината на UDP заглавјето и податоците.
Апликации
уредиМногубројни клучни Интернет апликации користат UDP, вклучувајќи: the Domain Name System (DNS), каде што прашалниците(зборови или фрази или ред текст што се користи за пронаоѓање и извлекување податоци од базата податоци) мора да бидат брзи и се состои само од едно барање проследено од единствен пакетен одговор,Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP)[1] и Dynamic Host Configuration Protocol (DHCP).
Споредба на UDP и TCP
уредиTCP е протокол за основно поврзување, што значи дека бара поставување на крај со крај комуникација. Откако поврзувањето е поставено корисникот на податоци може да испраќа директно преку поврзувањето.
- Сигурност-TCP управува со пораката.Многу обиди се направени за да се испрати пораката. Ако се загуби по пат,
опслужувачот повторно ќе го бара изгубениот дел. Во TCP, или нема податоци што недостасуваат или, во случај на долго време, поврзувањето се отфрла.
- Подреденост-ако две пораки се испратени на истото поврзување во низа, првата порака ќе стигне прво до апликацијата која прима. Кога некои сегменти на податоци ќе стигнат во погрешен ред, сите податоци на TCP баферите можат да бидат соодветно подредени и испратени до апликацијата.
- Heavyweight-TCP бара три пакети за да постави приклучок за поврзување, пред да бидат пратени од било кој корисник на податоци. TCP се справува со сигурноста и застојот на контрола.
- Стриминг– Податоците се читаат како бајт стрим, без разлика индикации се пренесуваат за да ги сигнализираат границите(сегмент) на пораката.
UDP е едноставен основен протокол. Неповрзаните протоколи не претставуваат крај со крај поврзување. Поврзувањето е завршено со пренесување на информација во една насока од изворот до одредиштето без да ја провери подготвеноста или состојбата на примачот.
- Несигурност – Кога пораката е пратена, но не се знае дали ќе стигне до нејзиното одредиште.
Може да се изгуби по пат. Нема концепт на признавање или реемитување.
- Неподреденост – Ако две пораки се пратени на истиот примач, редот во којшто ќе пристигнат не може да се предвиди.
- Lightweight – Нема подредување на пораките, нема последователни поврзувања итн. Тоа е мал транспорт дизајниран на врвот на IP.
- Пакети – Пакетите се пратени поединечно и се проверени за интегритет само кога ќе стигнат.
Пакетите имаат дефинитивни граници кои се пречекани после приемот, што значи операција за читање кај сокетот ќе донесе цела порака како што била првично пратена.
Наводи
уреди1.^ a b c Kurose, J.F. & Ross, K.W. (2010). Computer Networking, 5th ed. Boston, MA: Pearson Education, Inc.
2.^ a b c d e f g Forouzan, B.A. (2000). TCP/IP: Protocol Suite, 1st ed. New Delhi, India: Tata McGraw-Hill Publishing Company Limited.
3.^ Clark, M.P. (2003). Data Networks IP and the Internet, 1st ed. West Sussex, England: John Wiley & Sons Ltd.
4.^ a b Postel, J. (August 1980). RFC 768: User Datagram Protocol. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc768
5.^ a b Deering S. & Hinden R. (December 1998). RFC 2460: Internet Protocol, Version 6 (IPv6) Specification. Internet Engineering Task Force. Retrieved from http://tools.ietf.org/html/rfc2460
6.^ The impact of UDP on Data Applications
RFC наводи
уредиRFC 768 - User Datagram Protocol
RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification
RFC 4113 - Management Information Base for the UDP
RFC 5405 - Unicast UDP Usage Guidelines for Application Designers