Ръководство за UDP (User Datagram Protocol)

Протоколът за потребителска програма е като „Грозно пате“ на Ханс Кристиан Андерсен. След десетилетия на пренебрегване и осмиване, този прост протокол внезапно привлече почитателите като транспортния протокол за новите, бляскави мултимедийни приложения, които станаха възможни с широколентова скорост. Днес всяко приложение, което трябва да достави данни, бързо избира UDP спрямо доминиращия преди това TCP (Transmission Control Protocol).

История на UDP

UDP съществува почти толкова дълго, колкото интернет. Интернет възниква през май 1974 г., когато Институтът на инженерите по електроника и електроника публикува „Програма за комуникация на пакетни мрежи”От Винт Серф и Боб Хан. Концепцията трябваше да бъде разработена и Хан и Серф продължиха да усъвършенстват своите идеи, докато работят за правителството на САЩ Агенция за напреднали научни проекти в областта на отбраната, което е известно още като DARPA. Джон Постел се включи и предложи разделянето на единната структура, предложена в първоначалната идея на Серф и Хан. Това създаде многопластова концепция. Оригиналната програма за контрол на предаването, съдържаща се в контура от 1974 г., беше разделена на протокола за контрол на предаването на по-висок слой и интернет протокола на по-нисък слой (следователно TCP / IP).

Модулният подход на Постел има смисъл, когато екипът започна да мисли за прилагането на теорията. Има ясно разделение на труда между това, което стана известно като Транспортен слой, което е местоположението на протокола за контрол на предаването и Интернет слой, където пребивава Интернет протоколът. Въпреки това, Серф и Хан предвиждаха необходимостта от бърза опция. Те съставиха схема за това как данните ще бъдат подготвени за предаване чрез предаване от един слой в друг. Задачите за обработка бяха представени като права вертикална линия, спускаща се чрез новата си диаграма на стека, показваща прогресията от приложение към TCP и към IP.

Когато стана дума за рисуване в бързия път, те не искаха да начертават извита линия на заобикаляне, която избягваше преминаване през TCP. Вместо това те начертаха продълговата форма, която представляваше интернет слоя малко по-широк от блока, който представляваше транспортния слой. С тази визуална настройка, както обикновеният, така и бързият маршрут може да се спусне през стека като успоредни линии. Този трик обаче остави празнина, която Постел смяташе, че трябва да бъде запълнена. Ето защо е създаден протоколът User Datagram Protocol. Точно там, за да направи схемата на стека на протокола да изглежда балансирана.

Предимствата на TCP

Протоколът за контрол на предаването предоставя основни услуги на данните в транзит. Той гарантира, че всички пакети в поток действително пристигат и проверява дали те пристигат в ред. Тези процедури за контрол, които осигуряват правилен трансфер, не са възможни без мярка за координация между двете страни. И така, TCP първо установява споразумение между двете устройства, които възнамеряват да обменят данни. Това споразумение се нарича сесия. Това е и самото определение на „Връзка.„UDP няма процедури за установяване на сесия и затова се нарича„конекция.”

Сесията дава на двете страни на връзката референтен номер, който те могат да маркират на своите административни размени. Сесията също дава възможност за въвеждане на концепцията за пристанищата. Идентификационният номер на сесията всъщност е комбинация от идентификатори, съдържащи се в заглавката на TCP. С този идентификатор дизайнерите на TCP процедури успяха да излязат с идеята за „гнездо.”Номерата на порта също се разпределят към UDP, но този протокол може да използва само IP адреса на дестинация и номера на порта като уникален идентификатор. Идентификаторът, получен от тази комбинация, би блокирал всички други процеси, опитващи се да имат достъп до същия порт, въпреки че те се изпълняват на различни компютри, така че UDP беше създадена само за доставка, без процедури за активиране на двупосочен диалог.

Концепциите за TCP връзка са разработени в много сложен универсален метод, за да се гарантира, че данните, преминаващи между компютрите, не са били смесени или разбъркани. Сокетът даде възможност за отваряне на няколко връзки между едни и същи два компютъра едновременно. Тази идея създаде възможността да има повече от един канал, работещ за предаване на данни. Това е често използвана процедура, от която много предишни мрежови приложения се възползваха. Най- Протокол за прехвърляне на файлове, например използва два канала: един за предаване на данните и отделен канал за административна комуникация. Различните номера на портове за канали за данни и контрол създават две различни гнезда.

Уникалният идентификатор за всяка сесия означава, че TCP добавя стойност към комуникацията между два компютъра. В края на 70-те и началото на 80-те само големи организации и академични институции имаха компютри и мрежи. И така, имаше голяма вероятност две организации да се нуждаят от големите си мейнфрейми, за да се свързват едновременно с различни цели. Докато професор изпраща файл на колега в друг университет, изследовател може също да иска да отвори сесия на Telnet на компютъра в същия отдалечен университет. Благодарение на TCP два компютъра могат да поддържат няколко връзки едновременно и всяка от тези сесии може да работи по няколко канала едновременно. Тези едновременни връзки не биха били възможни, ако комуникациите се управляват само от интернет протокола с разпределението на един IP адрес на компютър. UDP, без механизъм за сесия, не е в състояние да управлява приложения, които изискват свързан компютър за изпращане на отговор.

Сигурност на данните

Блестящите конструкции на TCP направиха възможни връзките между мрежите и интернет започна да се разширява извън Академията към света на бизнеса. Създаването на Световна мрежа, което стана публично достояние през 1991 г. беше възможно само поради лекотата, с която уеб страницата, пренасяща протокол за прехвърляне на хипертекст (HTTP), може да седи на върха на TCP.

Учените и техниците, които обединиха интернет и разработиха обществено достъпната световна мрежа, бяха сини небеса мислители. Те бяха развълнувани от технологията и нейните възможности за ускоряване на изследванията и подобряване на взаимодействието между хората по целия свят. Те не успяха да отчетат факта, че тяхното прекрасно изобретение беше подарък за крадци, измамници и градски терористи. Нито интернет, нито световната мрежа изобщо нямаха сигурност.

Това отведе потребителите Netscape Corporation за да забележим този проблем. Netscape създаде водещия световен уеб браузър и го раздаде безплатно, за да насърчи разпространението на интернет сред широката общественост. Планът работи и обменът на информация и каналите за контакт се разпространиха, насърчавайки повече хора да се регистрират за интернет услуги. както и да е липсата на сигурност представлява пречка за комерсиализацията на мрежата. Без способността да примамва хората да плащат за онлайн услуги, нямаше стимул за бизнеса да инвестира в разработването на нови приложения, уебсайтове или онлайн услуги.

Основната бариера пред събирането на плащания през мрежата беше липсата на сигурност. Няколко заглавия относно кражбата на данни при интернет предаването изключиха възможността интернет да стане търговски жизнеспособен. въпреки това, Netscape излезе с HTTPS – сигурна версия на HTTP, която защитава предаването. Идеалното място в TCP / IP стека за тези процедури за сигурност беше по време на процесите за установяване на сесия на TCP. Така, TCP стана още по-важно за работата на интернет и изглеждаше още по-вероятно UDP никога да не бъде използван.

UDP излита

Въпреки че съществува от 1980 година, UDP беше напълно пренебрегнат докато широколентовите интернет услуги не станат достъпни в началото на този век. Протоколът на User Datagram беше в голяма степен игнориран, докато уеб и други интернет приложения се разширяваха във функционалността на TCP.

въпреки това, възможността за водене на гласови разговори и видеоконференции по интернет винаги е харесвала бизнеса. Тези приложения са съществували преди широколентови мрежи, но само за използване в по-бързи частни мрежи. С изградената технология за предаване на звук и видео по мрежи, по-бързите скорости на широколентовия достъп донесоха възможността тези приложения да бъдат достъпни за широката публика се превърна в осъществима идея. Скоростите, достъпни по интернет обаче, не бяха достатъчно добри.

Непосредственото решение за изтласкване на достатъчно достатъчна скорост извън интернет беше да се извадят всички административни процедури на TCP и обърнете се към почти забравения UDP.

Проблемите с TCP

Интерактивните приложения предпочитат да се справят с някои от проблемите, възникнали по време на самото предаване. Една от основните характеристики на TCP, която тези приложения наистина не искат, е буфериране.

TCP гарантира, че пакетите пристигат последователно. Ако пакет липсва от потока, приемащата TCP реализация ще изпрати заявка до изпращащата TCP програма за повторно изпращане на този конкретен пакет. Междувременно този пакет може да пристигне късно. TCP използва плъзгаща се рамкова система за обработка на пристигащи пакети и ако сегментът е закъснял или загубен, този слайд се задръства. Временното съхраняване на редица кадри в паметта е това, което е известно като буфериране. TCP изчаква, докато може да запълни празния слот с пакета, който носи липсващия пореден номер. В случай на интернет телефония подобно действие би довело до изчезване на линията. В видео потока изчакването за липсващ пакет ще накара видеоплейъра да замръзне.

Интерактивните приложения нямат процедури за заобикаляне на TCP буфериране. Основното зад стековите слоеве е, че по-високите слоеве искат услуга и я оставят на долния слой, за да я предоставят. Няма сигнал „да се захващам с“, че приложение може да изпрати на транспортния слой.

Ако пакетът се изгуби при цифров телефонен разговор, обаждащите се ще преживеят кратко мълчание, но приложението от двете страни просто ще продължи и ще продължи да изпраща и получава следните пакети. По времето, когато липсващ пакет може да бъде възстановен, интерактивният разговор вече щеше да продължи, така че няма смисъл да се опитвате да го инжектирате обратно в потока; просто е по-добре да отпишете загубата и да продължите. По същия начин, изгубен пакет би означавал само кратко пропускане на жив видео поток и зрителите биха предпочели, че видеото продължава да се движи напред, отколкото да задържа сюжета за една милисекунда от кадрите.

Вероятно сте виждали видео плейър да прави пауза и да наслагва съобщението „буфериране”Над снимката. Обикновено има и брояч, който показва процента на буферирането, което е приключило. Това буфериране се случва, ако скоростта на предаване на връзката е по-ниска от честотата на кадрите на възпроизвеждането на видео. Решаващият момент за това съобщение е, че той показва, че буферирането се управлява от играча, а не от транспортния протокол..

Протоколи за партньорство

Въпреки че интерактивното приложение не искаше забавянията, причинени от TCP, те искаха част от функционалността на този протокол. Те искаха повече, отколкото може да осигури UDP. Така че бяха създадени други протоколи за попълване на части от възможностите на TCP.

Протоколът за започване на сесия

Протоколът за иницииране на сесията (SIP) е изобретен за приложенията Voice over IP (VoIP). Интернет телефонията не искаше буфериране на TCP, но те трябваше да подражават на традиционните процедури за установяване на разговори на телефони – набиране, позвъняване, заето, повикване и край на повикване. Въпреки това, SIP не управлява цялата сесия, той просто се грижи за създаването на връзката и функциите за прекратяване на TCP. Всяко обаждане, което се осъществява по интернет, използва SIP. Толкова много, че „SIP“ почти се превърна в взаимозаменяем термин с „VoIP.”

Извършването на гласов трафик чрез високоскоростни цифрови връзки е известно като „SIP транкинг.„Превключването на разговор от интернет към обикновен стационарен телефон се нарича„SIP прекратяване.„Индустрията за цифрова телефония използва SIP, за да идентифицира технологията си, но основата на всичките им дейности е UDP.

Транспортният протокол в реално време

Въпреки решението, че TCP е твърде голяма част от интерактивния трафик и трябва да бъде изваден, комуникационните инженери продължиха да се връщат към съоръженията, предоставени от TCP и те пожелаха да ги имат с UDP. Транспортният протокол в реално време (RTP) компенсира голяма част от недостига във функционалността, който се наблюдава при използване на UDP.

Основна характеристика на тези добавъчни протоколи, които правят UDP релевантни за поточно предаване на медии е, че те позволяват някои от процесите, традиционно управлявани от TCP, да бъдат изтласкани до приложението. RTP управлява някои от функциите за управление на трафика на TCP, но не всички от тях.

RTP е в състояние да пренарежда от последователни пакети и да забелязва изгубени пакети. Функцията за секвениране обаче не е необходимо да се прилага и е невъзможна за изпълнение без буфериране на транспортния слой.

Протоколът за контрол на RTP

RTP винаги си партнира с RTCP, който е протоколът за контрол на RTP. RTPC емулира някои от функциите за управление на сесиите на TCP, с изключение на ръководния принцип на протокола е да не се натрапва в потока и да не се забавя предаването на медиите; затова неговите дейности са редки. Протоколът ще събира данни за производителността, включително загуба на пакети, и информация за скоростта на трансфер. Приемащият плейър може да използва тази информация, за да реши дали да премине към видео с по-ниска разделителна способност или към друг стандарт за кодиране на видео.

Ако използвате видео и аудио приложение, почти сигурно е, че участват и RTP, и RTCP. Има “преплитане”В дефиницията на RTSP (виж по-долу), която би преместила RTP предавания към TCP. Това обаче е необичайно предложение, което никога не е било приложено извън лабораторията. Без тази спецификация, всички RTP и RTCP дейности се извършват от UDP.

Протоколът за поточно предаване в реално време

Протоколът за поточно предаване в реално време (RTSP) почти винаги участва в приложения за възпроизвеждане на видео и аудио или запис. Този протокол предоставя бутони за управление на вашия плейър и рекордер. Това са пауза, запис / възпроизвеждане, бързо превъртане напред и назад. Любопитно е, че въпреки че RTSP може да работи над UDP, той обикновено се транспортира през TCP, въпреки че е партньор с поддържан от UDP видео или аудио поток.

Приложения само за UDP

Редица леки мрежови приложения, използващи UDP, без други протоколи, съставляващи симулация на TCP функции. Тези функции са почти изключително предназначени само за използване в частни мрежи тъй като те не включват никакви процедури за удостоверяване или криптиране на предаването.

Ако управлявате мрежа, ще бъдете запознати с Протокол за мрежово време (NTP), на Система за имена на домейни (DNS), на Протокол за динамична конфигурация на хоста (DHCP), и на Тривиален протокол за прехвърляне на файлове (TFTP). Всички тези административни услуги работят над UDP. Извън тези приложения за частни мрежи е много трудно да се намери всяко приложение, което работи само над UDP.

UDP срещу TCP

Сравнение на UDP заглавната структура и TCP заглавната структура ви показва ограниченията на UDP.

UDP заглавката има само четири полета. От тези четири, The Източник Порт полето не е задължително и може да се остави празно. В IPv4, the Контролната сума полето също е незадължително, въпреки че е задължително за реализациите на IPv6. Това означава, че в случай на IPv4 предавания, UDP заглавката трябва да има само две части информация в него.

TCP заглавката може да носи много повече информация.

Както можете да видите от илюстрацията, заглавката на пакета TCP има серия от девет знамена, които адаптират значението на заглавката. Това събитие има „спешно“ поле. Това дава на TCP системата много по-голяма гъвкавост от UDP и показва, че много повече време е инвестирано в процедурите за TCP и структурата на пакета му за заглавие, отколкото е изразходвано за разработването на UDP.

Фактът, че заглавката на TCP трябва да включва изходния порт, прави възможно създаването на по-уникален сокет, създавайки идентификационен номер на сесията от IP адресите на източника и местоназначението и номерата на източника и местоназначението. С UDP, тъй като няма процедури за създаване на сесия, всяко съобщение се третира като завършена задача, и протоколът не се опитва да свързва пакети заедно. Следователно приложенията, които използват USP, трябва сами да управляват тази приемственост.

Сигурност за UDP

Ориентираните към връзката методи на TCP правят сигурността много по-лесна за внедряване в този протокол в UDP. Съществуват обаче стандарти за криптиране за UDP. Основната опция, която е насочена директно към защитата на UDP, е протоколът за сигурност на Datagram Transport Layer или DTLS.

за щастие, DTLS се предлага в редица безплатни библиотеки с отворен код, така че не е необходимо да гребете чрез дефиницията на протокола и да напишете вашата отворена програма, за да я приложите. OpenSSL, която е библиотека с код с отворен код, е най-често срещаният източник за внедряване на Transport Layer Security, която е най-широко внедрената система за сигурност за TCP. Тази библиотека също включва реализация на DTLS, така че трябва да имате възможност да срещнете сигурни опции за UDP в същите приложения, които предлагат защитени TCP връзки.

Друга възможност за потребителите на UDP е да разчитат на система за сигурност, която е проектирана да работи на интернет слой. Това е IPSec, или сигурност на интернет протокола. Тъй като IPSec работи под транспортния слой, той не е в състояние да работи с портове и затова фактът, че UDP не е в състояние да поддържа сесия, няма значение, когато IPSec е ангажиран – Протоколите на IP слой също не могат да създават сесии. Като система с по-нисък слой, IPSec е в състояние да поддържа всеки протокол за транспортния слой, включително UDP.

IPSec включва методи за автентификация и също криптира пакети, за да ги предпази от подслушване на снайпери. ИТ предлага също толкова сигурност, колкото популярната TLS, но е по-малко широко внедрена. IPSec използва системата за обмен на ключове в Интернет (IKEv2), за да настрои автентичността, така че доста често IPSec се таксува като IKEv2. Използва се методологията на IKEv2 Diffie-Hellman процедури за обмен на ключове, която е точно същата система, която TLS използва за методологията на сесията за сигурна уеб страница на HTTPS.

Kerberos и Kerberized Интернет преговори на ключове (KINK) са два елемента на система за сигурност, която обикновено се нарича Kerberos. Процедурите за установяване на сесията в Kerberos използват система от „билети“, която е подобна на TLS метода за използване на „сертификати“. В самата дъна на стека Kerberos се поддържа от IPSec. Едноименният слой Kerberos седи отгоре на UDP и използва UDP гнезда за улесняване на комуникацията. Това е система за сигурност, благоприятна за UDP. Вълнуващо средство на Kerberos е, че ви позволява да използвате AES криптиране, за да защитите вашите UDP трансфери. AES е може би най-сигурният шифър в общата употреба днес и това е препоръчителният метод за сигурност за най-добрите световни системи за защита на поверителност VPN.

Въпреки очевидните трудности при договаряне на ключове за криптиране в среда, която не осигурява никакво управление на връзката, UDP предлага опции за защита. Така че, когато внедрявате базирано на UDP приложение, не изоставяйте задачата да осигурите вашите предавания.

Бъдещето на UDP

Чистите UDP-базирани приложения, които не включват странични протоколи, за да имитират TCP, са рядкост и има вероятност да станат още по-редки. Леките мрежови комунални услуги, които използват UDP, процъфтяват в защитените локални мрежи. Въпреки това, тъй като заплахите за сигурността от нови атаки с нулев ден нарастват всяка седмица, концепцията за наличието на несигурни протоколи за управление на ключовите услуги за управление на конфигурацията и адресиране изглежда глупаво самодоволна.

Докато мрежите преместват услугата си в облака, услугите на базирани на UDP TFTP и DHCP ще започнат да се заменят с по-сигурни алтернативи. Лесното решение за сърфиране на приложения през HTTPS, за да им осигури сигурност без допълнителни усилия за програмиране, наклонява бъдещето към TCP, който носи HTTPS и отнема възможности далеч от списъка на компетенциите на UDP.

Нишата на UDP за поддържане на медийни предавания вероятно ще издържи. Вече има много конкурентни транспортни системи, предложени за поддръжка на интерактивни приложения, но никоя от тях не свали UDP от позицията си като първи избор за VoIP и видео стрийминг. Този списък на съперниците включва:

Протоколът за надеждна потребителска програма (RUDP), който има реализации на Cisco и Microsoft.

Протокол за предаване на контрол на потока (SCTP), който бе неуспешно предложен като заместител на комбо UDP / RTP / RTCP, но никога не се спусна.

Това грозно патенце, наречено UDP, беше открито като лебед, благодарение на магическите преобразуващи сили на широколентовите и интерактивни приложения. Тази съживена звезда ще продължи да се плъзга без усилия във водите на интернет.

Какви методи на предаване използвате? Виждате ли UDP грозно патенце като лебед? Пишете за своите преживявания в секцията за коментари по-долу.

Свързани:
Крайно ръководство за TCP / IP
Какво е TCPdump?
Преглед на SolarWinds TFTP сървър
Преглед на TFTPD32 TFTP сървър

Снимки:
Ръководител на UDP от Devarshi в английски Wikibooks лицензирани под CC BY-SA 2.5
TCP оформление на пакети с битова скала от Quliyevferman чрез Wikimedia Commons. Лицензиран под CC BY-SA 4.0