Какво означава rtp протокол върху udp. IP телефония: от медни проводници до цифрова обработка на сигнала

При използване на RTP протокол се отварят два порта за комуникация. Един за предаване на потока от медийни данни (четен номер на порт) и един за предаване на сигнални данни (обратна връзка за QoS и контрол на медийния поток) - RTCP. Стойностите на номерата на портовете не са строго обвързани; като цяло те силно зависят от използваното приложение.

RTP - Транспортен протокол в реално време RTCP - Протокол за управление в реално време Допълнително включва информация за: Загуба на пакети Джитър буфериране Закъснения Сила на сигнала Показател за качество на сигнала (Метрики за качество на повикване) Загуба на връщане на ехо и др. RTCP XR - Протокол за контрол в реално време Разширени отчети Всички полета, описани за протокола RTCP, плюс: R фактор - Параметър за качество на сигнала MOS - Параметър за качество на сигнала и други
Пакетите, съдържащи предавания глас, се предават с помощта на протокола RTP/RTCP, който се използва за VOIP разговори. RTP протоколът може да прехвърля медийни данни, идентифицирани чрез параметри, които са регистрирани от организацията: „Internet assigned numbers Authority“ – IANA. Те се използват и за полета в протокола, който се използва в съобщенията.

Някои стойности на полето за полезен товар:

П.Т.	име на кодек	аудио/видео (A/V)	тактова честота (Hz)	брой канали	Документ	0	PCMU	А	8000	1	RFC3551	3	GSM	А	8000	1	RFC3551	4	G723	А	8000	1	Кумар	5	DVI4	А	8000	1	RFC3551	6	DVI4	А	16000	1	RFC3551	7	ЗЗК	А	8000	1	RFC3551	8	PCMA	А	8000	1	RFC3551	9	G722	А	8000	1	RFC3551	10	L16	А	44100	2	RFC3551	11	L16	А	44100	1	RFC3551	12	QCELP	А	8000	1	-	13	CN	А	8000	1	RFC3389	14	MPA	А	90000		RFC3551, RFC2250	15	G728	А	8000	1	RFC3551	16	DVI4	А	11025	1	DiPol	17	DVI4	А	22050	1	DiPol	18	G729	А	8000	1		19	запазено	А				20	не е зададен	А				21	не е зададен	А				22	не е зададен	А				23	не е зададен	А				24	не е зададен	V				25	CelB	V	90000		RFC2029	26	JPEG	V	90000		RFC2435	27	не е зададен	V				28	nv	V	90000		RFC3551	29	не е зададен	V				30	не е зададен	V				31	H261	V	90000		RFC2032	32	MPV	V	90000		RFC2250	33	MP2T	AV	90000		RFC2250	34	H263	V	90000		Джу	35--71	не е зададен				72--76	запазени за RTCP, за да се избегнат конфликти				RFC3550	77--95	не е зададен				77--95	динамичен			RFC3551

IANA: Параметри на регистриран RTP протокол: http://www.iana.org/assignments/rtp-parameters

RTP протокол и транслация на IP адрес (NAT) При провеждане на VOIP комуникационна сесия се формират два RTP потока, по един във всяка посока. Ако един от участниците, участващи в тази сесия, използва IP адрес от частната мрежа, тогава потокът от абоната, намиращ се в публичната мрежа, към NAT сървъра няма да може да достигне до абоната, намиращ се във вътрешната мрежа. За решаване на този проблем често се използва (симетричен RTP). За повече информация относно използването на VOIP през NAT мрежи вижте: NAT и VOIP Статии RTCP XR измерва производителността на VoIP Network World 17/11/03 RFC документи: IETF RFC 3550 RTP: Транспортен протокол за приложения в реално време. IETF RFC 3611Разширени отчети на RTP контролен протокол (RTCP XR) IETF RFC 1890 RTP профил за аудио и видео конференции с минимален контрол. IETF RFC 2508Компресиране на заглавки на IP/UDP/RTP пакети за нискоскоростни комуникационни линии. IETF RFC 3545Усъвършенствана RTP (CRTP) компресия за връзки с висока латентност, голяма загуба на пакети и често повторно изпращане на данни.

Една от най-важните тенденции в развитието на съвременните телекомуникации е развитието на IP телефонията - разнообразие от нови технологии, които осигуряват предаването на мултимедийни съобщения (говор, данни, видео) чрез информационни и компютърни мрежи (ICN), изградени на основа на IP (Интернет протокол), включително локални, корпоративни, глобални компютърни мрежи и Интернет. Концепцията за IP телефония включва интернет телефония, която позволява организиране на телефонна комуникация между интернет абонати, между абонати на обществени телефонни мрежи (PSTN) през интернет, както и телефонна комуникация между PSTN и интернет абонати помежду си.

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

Какви международни стандарти и протоколи регламентират основните параметри и алгоритми за функциониране на хардуерните и софтуерни комуникации, използвани в IP телефонията? Очевидно, както подсказва името, тази технология се основава на IP протокола, който обаче се използва не само за телефония: той първоначално е разработен за предаване на цифрови данни към информационни системи с пакетна комутация.

В мрежи, които не осигуряват гарантирано качество на услугата (те включват мрежи, изградени на IP протокол), пакетите могат да бъдат загубени, редът на пристигането им може да се промени и данните, предавани в пакети, могат да бъдат изкривени. За да се осигури надеждна доставка на предаваната информация при тези условия, се използват различни процедури на транспортния слой. При предаване на цифрови данни за тази цел се използва протоколът TCP (Transmission Control Protocol). Този протокол осигурява надеждна доставка на данни и възстановява първоначалния ред на пакетите. Ако бъде открита грешка в пакета или пакетът е изгубен, TCP процедурите изпращат заявка за повторно предаване.

За приложенията за аудио и видеоконференции закъсненията на пакетите имат много по-голямо влияние върху качеството на сигнала, отколкото повредите на отделните данни. Разликите в закъсненията могат да доведат до паузи. Такива приложения изискват друг протокол на транспортния слой, който осигурява възстановяване на оригиналната последователност от пакети, доставката им с минимално забавяне, възпроизвеждане в реално време в точно определени моменти, разпознаване на типа трафик, групова или двупосочна комуникация. Този протокол е транспортен протокол в реално време RTP (Real-Time Transport Protocol). Този протокол регулира прехвърлянето на мултимедийни данни в пакети през IVS на транспортно ниво и се допълва от протокола за управление на преноса на данни в реално време RTCP (Real-Time Control Protocol). Протоколът RTCP от своя страна осигурява контрол на доставката на медия, контрол на качеството на услугата, комуникация относно участниците в текущата комуникационна сесия, управление и идентификация и понякога се счита за част от RTP протокола.

Много публикации, посветени на IP телефонията, отбелязват, че по-голямата част от мрежовото оборудване и специалния софтуер за тази технология е разработен на базата на секторната препоръка за стандартизация на телекомуникациите H.323 на Международния съюз по телекомуникации (ITU-T) (включително TAPI 3.0, NetMeeting 2.0 и др. .). Как се свързва H.323 с протоколите RTP и RTCP? H.323 е широка концептуална рамка, която включва много други стандарти, всеки от които покрива различни аспекти на трансфера на информация. Повечето от тези стандарти, като стандартите за аудио и видео кодеци, се използват широко не само в IP телефонията. Що се отнася до протоколите RTP/RTCP, те са в основата на стандарта H.323, фокусирани са върху предоставянето на IP технология и са в основата на организацията на IP телефонията. Тази статия е посветена на разглеждането на тези протоколи.

2. Основни понятия

Транспортният протокол в реално време RTP осигурява предаване в реално време от край до край на мултимедийни данни като интерактивно аудио и видео. Този протокол прилага разпознаване на тип трафик, номериране на последователност от пакети, управление на времеви печат и контрол на предаването.

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

Обърнете внимание, че самият RTP няма механизъм, който да гарантира навременно предаване на данни и качество на услугата, но използва базови услуги, за да гарантира това. Това не предотвратява пакети извън реда, но не предполага, че основната мрежа е напълно надеждна и предава пакети в правилната последователност. Поредните номера, включени в RTP, позволяват на получателя да реконструира последователността на пакетите на подателя.

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

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

Блоковете данни на протокола RTP/RTCP се наричат пакети. Пакетите, генерирани в съответствие с протокола RTP и използвани за предаване на мултимедийни данни, се наричат информационни пакети или пакети с данни, а пакетите, генерирани в съответствие с протокола RTCP и използвани за предаване на служебна информация, необходима за надеждна работа на телеконференция, се наричат контролни пакети или контролни пакети. RTP пакетът включва фиксиран хедър, незадължително разширение на хедъра с променлива дължина и поле за данни. RTCP пакетът започва с фиксирана част (подобно на фиксираната част на RTP информационните пакети), последвана от структурни елементи, които имат променлива дължина.

За да бъде протоколът RTP по-гъвкав и да може да се използва за различни приложения, някои от неговите параметри са умишлено недефинирани, но той предоставя концепцията за профил. Профилът е набор от параметри на протоколите RTP и RTCP за определен клас приложения, които определят характеристиките на тяхното функциониране. Профилът определя използването на отделни полета на заглавката на пакета, типове трафик, добавяне на заглавка и разширения на заглавка, типове пакети, услуги и алгоритми за осигуряване на комуникационна сигурност, характеристики на използването на основния протокол и т.н. (като пример раздел 11 разглежда този, предложен в RFC 1890 RTP профил за аудио и видео конференции с минимален контрол). Всяко приложение обикновено работи само с един профил, като типът на профила се задава чрез избиране на съответното приложение. Няма изрично указание за типа на профила чрез номер на порт, идентификатор на протокол и др. не е предоставено.

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

Характеристиките на прехвърлянето на мултимедийни данни по време на аудио и видеоконференции са разгледани в следващите раздели.

2.1. Групова аудиоконференция

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

Приложението за аудиоконференция, използвано от всеки участник в конференцията, изпраща аудио данни на малки парчета, като например 20 ms. Всяка част от аудио данни се предхожда от RTP хедър; RTP заглавката и данните се формират последователно (капсулират) в UDP пакет. RTP заглавката показва какъв тип аудио кодиране (като PCM, ADPCM или LPC) е използвано за генериране на данните в пакета. Това дава възможност за промяна на типа кодиране по време на конференцията, например, когато се появи нов участник, който използва връзка с ниска честотна лента, или когато има претоварване на мрежата.

В Интернет, както и в други мрежи за данни с комутация на пакети, пакетите понякога се губят и пренареждат и се забавят за различно време. За да противодейства на тези събития, RTP хедърът съдържа клеймо за време и пореден номер, който позволява на получателите да нулират времето, така че например части от аудио сигнала да се възпроизвеждат непрекъснато от високоговорителя на всеки 20 ms. Тази синхронизираща реконструкция се извършва отделно и независимо за всеки източник на RTP пакети в дискусионната група. Поредният номер може също да се използва от получателя за оценка на броя на изгубените пакети.

Тъй като участниците в телеконференция могат да се присъединяват и напускат конференцията, докато тя е в ход, е полезно да знаете кой в момента участва в конференцията и колко добре участниците в конференцията получават аудио данни. За целта всеки екземпляр на аудио приложението по време на конференция периодично издава съобщения на контролния порт (RTCP порт) за приложенията на всички останали участници за приемане на пакети, посочващи името на неговия потребител. Съобщението за получаване показва колко добре се чува текущият високоговорител и може да се използва за управление на адаптивни енкодери. В допълнение към потребителското име може да бъде включена и друга идентификационна информация за контрол на честотната лента. При напускане на конференцията сайтът изпраща RTCP BYE пакет.

2.2. Видеоконферентна връзка

Ако в телеконференция се използват и аудио, и видео сигнали, те се предават отделно. За предаване на всеки тип трафик независимо от другия, спецификацията на протокола въвежда концепцията за RTP комуникационна сесия (вижте списъка с използвани съкращения и термини). Една сесия се определя от конкретна двойка транспортни адреси на дестинация (един мрежов адрес плюс двойка портове за RTP и RTCP). Пакетите за всеки тип трафик се изпращат с помощта на две различни двойки UDP портове и/или групови адреси. Няма директна RTP връзка между аудио и видео сесии, освен че потребителят, участващ и в двете сесии, трябва да използва едно и също канонично име в RTCP пакетите и за двете сесии, така че сесиите да могат да бъдат свързани.

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

2.3. Концепцията за смесители и транслатори

Не всички сайтове винаги могат да получават мултимедийни данни в един и същи формат. Помислете за случая, при който участници от едно място са свързани чрез нискоскоростна връзка с повечето други участници в конференцията, които имат широколентов достъп до мрежата. Вместо да принуждава всички да използват по-ниска честотна лента и аудио кодиране с по-ниско качество, комуникационното средство на RTP слоя, наречено миксер, може да бъде поставено в зона с ниска честотна лента. Този миксер повторно синхронизира входящите аудио пакети, за да възстанови оригиналните интервали от 20 ms, смесва тези реконструирани аудио потоци в единичен поток, кодира аудио сигнала за тясна честотна лента и предава пакетния поток по нискоскоростна връзка. В този случай пакетите могат да бъдат адресирани до един получател или група получатели с различни адреси. За да позволи на приемащите крайни точки да осигурят правилна индикация за източника на съобщения, RTP хедърът включва средство за миксери за идентифициране на източниците, които са допринесли за състава на смесения пакет.

Някои от участниците в аудио конференцията може да са свързани чрез широколентови връзки, но може да не са достъпни чрез IP мултикаст (IPM) групова конференция. Например, те може да са зад защитна стена на приложния слой, която няма да позволи предаването на IP пакети. За такива случаи не ви трябват миксери, а друг вид комуникационно оборудване на RTP ниво, наречено транслатори. От двете релета едното е инсталирано извън защитната стена и препраща външно всички мултикаст пакети, получени чрез защитена връзка, към другото реле, инсталирано зад защитната стена. Релето зад защитната стена ги предава отново като мултикаст пакети към група от много потребители, ограничена до вътрешната мрежа на сайта.

Смесителите и транслаторите могат да бъдат проектирани за различни цели. Пример: Видео миксер, който мащабира видео изображения на отделни хора в независими видео потоци и ги композира в един видео поток, симулирайки групова сцена. Примери за превод: свързване на група хостове само за IP/UDP към група хостове само за ST-II или прекодиране на видео пакет по пакет от отделни източници без повторна синхронизация или смесване. Подробности за работата на миксерите и транслаторите са разгледани в раздел 5.

2.4. Ред на байтовете, подравняване и формат на клеймото за време

Всички полета на RTP/RTCP пакети се предават по мрежата в байтове (октети); първо се предава най-значимият байт. Всички данни в полето на заглавката се подравняват според дължината му . Октетите, определени като незадължителни, имат стойност нула.

Абсолютното време (Wallclock time) в RTP се представя с помощта на формата на времевия печат на Network Time Protocol (NTP), който е референтен час в секунди спрямо нула часа на 1 януари 1900 г. Пълният формат на NTP клеймо за време е неподписано 64-битово число с фиксирана запетая с цяла част в първите 32 бита и дробна част в последните 32 бита. Някои полета с по-компактно представяне използват само средните 32 бита - по-малките 16 бита от целочислената част и най-значимите 16 бита от дробната част.

Следващите два раздела на тази статия (3 и 4) обсъждат форматите на пакетите и работните характеристики съответно на протоколите RTP и RTCP.

3. Протокол за пренос на данни RTP 3.1. RTP фиксирани заглавни полета

Както беше отбелязано по-горе, RTP пакетът включва фиксиран хедър, незадължително разширение на хедъра с променлива дължина и поле за данни. Фиксираният хедър на пакетите на RTP протокола има следния формат: .

Първите дванадесет октета присъстват във всеки RTP пакет, докато полето CSRC (допринасящ източник) присъства само когато е вмъкнато от миксера. Полетата имат следните цели.

Версия (V): 2 бита. Това поле идентифицира RTP версията. Тази статия обхваща версия 2 на RTP протокола (стойност 1 беше използвана в първия проект на RTP).

Подложка (P): 1 бит. Ако битът за запълване е зададен на единица, тогава пакетът в края съдържа един или повече запълващи октети, които не са част от трафика. Последният октет на подложката съдържа индикация за броя на тези октети, които впоследствие трябва да бъдат игнорирани. Подпълването може да се изисква от някои алгоритми за криптиране с фиксирани размери на блокове или за пренасяне на множество RTP пакети в един основен блок от данни на протокола.

Разширение (X): 1 бит. Ако битът за разширение е зададен, тогава фиксираната заглавка е последвана от разширение за заглавка с формата, дефиниран в .

CSRC брояч (CC): 4 бита. CSRC броячът съдържа броя на включените идентификатори на CSRC източник (вижте списъка с използвани съкращения и термини), които следват фиксираната заглавка.

Маркер (M): 1 бит. Интерпретацията на маркера се определя от профила. Предназначено е да позволи значими събития (като граници на видеокадър) да бъдат маркирани в пакетен поток. Профилът може да въведе допълнителни маркерни битове или да определи, че няма маркерен бит, като промени броя на битовете в полето тип трафик (вижте ).

Тип трафик (PT): 7 бита. Това поле идентифицира формата на RTP трафик и определя как приложението го интерпретира. Профилът дефинира статично съпоставяне по подразбиране между PT стойностите и форматите на трафика. Допълнителни кодове за тип трафик могат да се дефинират динамично чрез средства, различни от RTP. Изпращачът на RTP пакет произвежда единична стойност за тип RTP трафик във всеки даден момент; Това поле не е предназначено за мултиплексиране на отделни медийни потоци (вижте ).

Пореден номер: 16 бита. Стойността на поредния номер се увеличава с единица с всеки изпратен RTP информационен пакет и може да се използва от получателя за откриване на загуби на пакети и възстановяване на оригиналната им последователност. Първоначалната стойност на поредния номер е избрана на случаен принцип, за да затрудни разбиването на ключа въз основа на известни стойности на това поле (дори ако кодирането не се използва от източника, тъй като пакетите могат да преминат през преводач, който използва криптиране) . Времево клеймо: 32 бита. Времето клеймо отразява точката на вземане на проби за първия октет в RTP информационния пакет. Точката на вземане на проби трябва да бъде получена от таймер, който увеличава своите стойности монотонно и линейно във времето, за да осигури синхронизация и да открие трептене (вижте раздел 4.3.1). Разделителната способност на таймера трябва да е достатъчна за желаната точност на синхронизирането и измерване на трептенето на пакета (един отчет на таймера за видеокадър обикновено не е достатъчен). Честотата на синхронизиране зависи от формата на предавания трафик и се задава статично в профила или спецификацията на формата на трафика или може да се задава динамично за формати на трафик, дефинирани чрез "средства, различни от RTP". Ако RTP пакетите се генерират периодично, трябва да се използват номиналните времена за вземане на проби, определени от таймера за вземане на проби, а не стойностите на системния таймер. Например, за аудиосигнал с фиксирана скорост е желателно сензорът за клеймо за време да се увеличава с единица за всеки период на вземане на проби. Ако аудио приложение от входно устройство чете блокове, съдържащи 160 проби, тогава клеймото за време трябва да се увеличи със 160 за всеки такъв блок, независимо дали блокът се предава в пакет или се нулира като пауза. Първоначалната стойност на клеймото за време, подобно на началната стойност на поредния номер, е случайна променлива. Множество последователни RTP пакети може да имат еднакви времеви отпечатъци, ако са логически генерирани по едно и също време, например ако принадлежат към един и същ видеокадър. Последователните RTP пакети могат да съдържат немонотонни времеви отпечатъци, ако данните не се предават в ред на вземане на проби, какъвто е случаят с интерполирани MPEG видеокадри (обаче номерата на последователността на пакетите все още ще бъдат монотонни, когато се предават).

SSRC: 32 бита. Полето SSRC (източник на синхронизация) идентифицира източника на синхронизация (вижте списъка с използвани съкращения и термини). Този идентификатор се избира произволно, така че нито един източник на синхронизация в една и съща RTP сесия да няма един и същ SSRC идентификатор. Въпреки че вероятността множество източници да изберат един и същ идентификатор е ниска, всички реализации на RTP трябва да бъдат подготвени за откриване и разрешаване на такива сблъсъци. Раздел 6 обсъжда вероятността от сблъсъци заедно с механизъм за разрешаването им и откриване на вериги на RTP слоя въз основа на уникалността на SSRC идентификатора. Ако източник промени своя транспортен адрес на източника, той трябва също така да избере нов SSRC идентификатор, за да избегне тълкуването му като източник с обратна връзка.

CSRC списък: 0 до 15 елемента, по 32 бита всеки. Списъкът CSRC (допринасящ източник) идентифицира включените източници на трафика, съдържащ се в пакета. Броят на идентификаторите се определя от полето CC. Ако има повече от петнадесет включени източника, тогава само 15 от тях могат да бъдат идентифицирани. CSRC ID се вмъкват от миксери, когато се използват SSRC ID за комутирани източници. Например, за аудио пакети, SSRC идентификаторите на всички източници, които са били смесени при създаването на пакета, са изброени в CSRC списъка, предоставяйки правилна индикация за източниците на съобщения на получателя.

3.2. RTP комуникационни сесии

Както бе споменато по-горе, според RTP протокола, различните видове трафик трябва да се предават отделно, в различни RTP комуникационни сесии. Една сесия се определя от конкретна двойка транспортни адреси на дестинация (един мрежов адрес плюс двойка портове за RTP и RTCP). Например, в телеконференция, съставена от отделно кодирани аудио и видео, всеки тип трафик трябва да бъде изпратен в отделна RTP сесия със собствен транспортен адрес на дестинация. Не е предвидено аудио и видео да се предават в една и съща RTP сесия и да се разделят въз основа на тип трафик или SSRC полета. Преплитането на пакети с различни типове трафик, но използване на един и същ SSRC би причинило някои проблеми:

Ако един от типовете трафик се промени по време на сесия, няма да има общи средства за определяне коя от старите стойности е била заменена от новата.

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

Съобщенията на RTCP подател и получател (вижте раздел 4.3) описват само една стойност на времеви интервал и пространство на пореден номер за SSRC и не носят поле за тип трафик.

RTP миксерът не е в състояние да комбинира преплетени потоци от различни типове трафик в един поток.

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

Като използвате различни SSRC за всеки тип трафик, но ги предавате в една и съща RTP сесия, можете да избегнете първите три проблема, но не можете да избегнете последните два. Следователно спецификацията на RTP протокола изисква всеки тип трафик да използва своя собствена RTP сесия.

3.3. Промени в RTP заглавието, дефинирано от профила

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

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

Допълнителна информация, която се изисква за конкретен формат на трафик (например тип кодиране на видео), трябва да се носи в полето за данни на пакета. Може да бъде поставен на определено място в началото или вътре в масива от данни.

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

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

3.4. Разширение на заглавката на RTP

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

Ако битът X в заглавката на RTP е зададен на единица, тогава към фиксираната заглавка на RTP се добавя разширение на заглавката с променлива дължина (следвайки списъка на CSRC, ако има такъв). Имайте предвид, че това разширение на заглавката е само за ограничена употреба. Разширението на заглавката на RTP пакета има следния формат:

Разширението съдържа 16-битово поле за дължина, което показва броя на 32-битовите думи в него, с изключение на заглавката на разширението от четири октета (следователно дължината може да бъде нула). Само едно разширение може да бъде добавено към заглавка на фиксиран RTP информационен пакет. За да се позволи на всяка от множеството оперативно съвместими реализации да експериментира независимо с различни разширения на заглавка или за да се позволи на конкретна реализация да експериментира с повече от един тип разширение на заглавка, използването на първите 16 бита от разширението е неуточнено, запазено за разграничаващи идентификатори или параметри. Форматът на тези 16 бита трябва да се определя от спецификацията на профила, с който работят приложенията.

1999
2000

RTP и RTCP протоколи във VoIP

RTP е основният транспортен протокол в мрежите за IP телефония. RTP (Протокол в реално време) е протокол в реално време, който е създаден за предаване на мултимедия (аудио, видео), кодирана и пакетирана информация през IP мрежи в рамките на строги времеви ограничения. Предаването на RTP сегменти се осъществява съответно по UDP и IP протоколите на различни нива на OSI модела. Използването на UDP, което не гарантира доставка, се дължи на стриктното време за предаване на медии в реално време, както и на невъзможността на TCP да работи в реално време. Следователно, въпреки загубата на някои данни, навременната доставка е по-важна в този случай.
Като цяло разпределението на протокола между слоевете на OSI модела е както следва:
Транспортен слой: RTP през UDP
Мрежа: IP
Канал: Ethernet
Физически: Ethernet
При предаване на мултимедийна информация с помощта на RTP протокола се използва следното капсулиране:

Минималният размер на RTP сегмент е 12 байта. Първите два бита определят версията на протокола. Днес се използва RTPv.2. Следващото поле P също е дълго 2 бита и показва наличието на знаци за допълване в полето с данни, когато се използват сегменти със същата дължина. Полето X определя дали се използва разширен хедър. След това 4-битовото CC поле дефинира броя на CSRC полетата в края на RTP хедъра, т.е. броя на източниците, формиращи потока. Следва полето M, маркерен бит, използван за подчертаване на важни данни. Следващото PT поле е с размер 7 бита. Предназначен за определяне на вида на полезния товар - данните, необходими за приложението. Използвайки посочения код, приложението определя вида на мултимедийната информация и начина на декодиране.
Останалата част от заглавието се състои от поле SequenceNumber - поредният номер на сегмента, който проследява реда на пакетите и тяхната загуба; Полета за клеймо за време - код за синхронизация, указващ времето на първата кодирана проба в полезния товар, този печат се използва от буферите за възстановяване на синхронизацията, за да се елиминират загубите на качество, причинени от вариация на забавянето; полета за източник на синхронизация SSRC - произволно число, което разграничава една RTP сесия от друга, за създаване на възможности за мултиплексиране. След постоянната фиксирана част на RTP хедъра могат да се добавят до 15 тридесет и две битови CSRC полета, които идентифицират източниците на данни.
Нека опишем процедурата за установяване на RTP сесия. Протоколът установява, че трафикът от различен тип се предава в отделни комуникационни сесии. За да се установи сесия, е необходимо да се определи двойка транспортни адреси на дестинация, т.е. един мрежов адрес и два порта за RTP и RTCP. Така че за видеоконференция е необходимо да се предават аудио и видео в различни сесии със съответно различни портове за дестинация. Пренасянето на различни типове трафик с помощта на преплитане в една и съща сесия може да причини следните проблеми:
- при промяна на един от видовете трафик е невъзможно да се определи кой параметър в сесията трябва да бъде заменен с нова стойност;
- за установяване на сесия се използва само един времеви интервал, а при предаване на хетерогенен трафик всеки тип ще има свой собствен интервал и те ще се различават;
- миксерът RTP не може да комбинира преплетени потоци от различни видове трафик в един поток;
- предаването на няколко вида трафик в една RTP сесия е невъзможно поради следните причини: използването на различни мрежови пътища или разпределението на мрежовите ресурси; получаване на подмножество от мултимедийни данни, когато е необходимо, например само аудио, ако видео сигналът надвишава наличната честотна лента; реализации на слушател, които използват отделни процеси за различни типове трафик, докато използването на отделни RTP сесии позволява както еднопроцесни, така и многопроцесни реализации.

Въпреки това, RTP (Протокол за транспорт в реално време) и UDP (Протокол за потребителски дейтаграми) не гарантират качество, тоест не работят с QoS (Качество на услугата). Поради това RTP протоколът се поддържа от Real-Time Transport Control Protocol (RTCP), който предоставя допълнителна информация за състоянието на RTP комуникационната сесия.
Протоколът RTCP изпълнява четири основни функции:
I. Основната задача на RTCP протокола е да осигури обратна връзка, за да гарантира качеството на предаване на данни. Обратната връзка може да бъде директно полезна, когато се прилага за предаване на адаптивно кодиране. Също така, когато се използва IP мултикастиране, е изключително важно получателите да диагностицират грешки при предаване на съобщения (пакети). Изпращането на съобщения с отчети за получаване позволява на изпращащата страна да определи причината за неуспешното предаване на съобщения, ако такова се случи.
II. RTCP съдържа неизменен идентификатор на транспортния слой за RTP източника, който се нарича „канонично име“ или „Cname“. Тъй като идентификаторът на SSRC може да се промени, ако бъдат открити сблъсъци, приемникът се нуждае от стойност Cname, за да следи всеки участник. Получателите също използват Cname за картографиране на множество потоци от данни от един участник при установяване на множество сесии едновременно, например за синхронизиране на аудио и видео канали при предаване на видео с аудио.
III. Горните две функции предполагат, че всички участници в сесиите са изпратили RTCP пакети, така че скоростта на предаване трябва да се контролира, така че RTP да може да установи сесии с голям брой потребители. Когато всеки участник предава своите контролни пакети на всички останали, всеки партньор може самостоятелно да определи общия брой участници в сесията. Това е необходимо за изчисляване на скоростта на предаване на RTCP съобщения.
IV. Тази функция се използва за предаване на минимално необходимата контролна информация, като например ID на участника, който се използва от GUI. Тази функция се използва за слабо контролирани сесии, при които потребителите влизат и излизат без правилно договаряне на параметри и характеристики. RTCP служи като удобен канал за връзка с всички участници, но не е задължително да поддържа всички комуникационни изисквания на приложението.
В IP мрежи, използващи мултикастинг, функции едно, две и три са задължителни при използване на RTP сесии. Използването им се препоръчва и за предаване в други мрежи и среди. Днес се препоръчва разработчиците на RTP приложения да използват инструменти, които им позволяват да работят в режим на множествено предаване, а не само в режим на едноадресно предаване.
Нека разгледаме формата на RTCP пакетите.
Стандартът на протокола дефинира няколко типа RTCP пакети. RTCP е проектиран да предава сервизна информация:
sr: Доклад на изпращача. Необходими за статистика на приемане и предаване на участници в сесията, които са пряко активни податели;
rr: Доклад на получателя. Изисква се за статистика от участници, които не са получатели;
sdes: Описва източника, включва Cname;
чао: Служи за указване на край (изход) на сесията;
приложение: специфични за приложението функции;
Всеки RTCP пакет се състои от постоянна част, както при RTP протокола, която се използва от RTP пакети, последвана от полета, които могат да варират по дължина в зависимост от типа на пакета, но са кратни на 32 бита. Изискванията за подравняване и полето за дължина във фиксираната част на заглавката са въведени, за да направят RTCP пакетите съединими. Множество RTCP пакети могат да бъдат свързани заедно, без да се въвеждат разделители, за да се получи съставен RTCP пакет, който се изпраща по транспортен протокол на ниско ниво, като UDP. Няма специален брояч за отделни RTCP пакети, тъй като протоколът от ниско ниво ще определи общата дължина и ще определи края на съставния пакет.

Форматът на RTCP пакета на изпращащото съобщение е както следва, както е показано на фигурата по-горе.

RTCP пакетите подлежат на следните проверки за надеждност.
- Полето за RTP версия трябва да е равно на 2.
- Полето за тип данни на първия RTCP пакет в съставен пакет трябва да бъде SR или RR.
- Битът за запълване (P) трябва да бъде нула за първия пакет от съставен RTCP пакет, тъй като запълването може да присъства само в последния.
- Дължината на полетата на отделните RTCP пакети трябва да е равна на общата дължина на съставния пакет.

Добър ден

Общо: системата за мониторинг е комплекс, свързан в ненатрапчив режим към n-броя 10-gigabit Ethernet връзки, който непрекъснато „наблюдава“ предаването на всички RTP видео потоци, присъстващи в трафика, и прави измервания в определено време интервал, за да ги запишете по-късно в базата данни. Въз основа на данните от базата данни се генерират редовно отчети за всички камери.

Какво толкова трудно има в това?

В процеса на търсене на решение веднага бяха идентифицирани няколко проблема:

Ненатрапчива връзка. Системата за мониторинг се свързва към вече работещи канали, в които повечето връзки (чрез RTSP) вече са установени, сървърът и клиентът вече знаят кои портове се обменят, но ние не знаем това предварително. Има добре познат порт само за протокола RTSP, но UDP потоците могат да преминават през произволни портове (освен това се оказа, че те често нарушават изискването ТРЯБВА за паритет на четни/нечетни портове, вижте rfc3550). Как да определите, че определен пакет от определен IP адрес принадлежи към видео поток? Например, протоколът BitTorrent се държи по подобен начин - на етапа на установяване на връзка клиентът и сървърът се споразумяват за портове и тогава целият UDP трафик изглежда като „просто битов поток“.
Свързаните връзки могат да съдържат повече от просто видео потоци. Може да има HTTP, BitTorrent, SSH и всякакви други протоколи, които използваме днес. Следователно системата трябва да идентифицира правилно видео потоците, за да ги отдели от останалия трафик. Как да направите това в реално време с 8 десет гигабитови връзки? Разбира се, те обикновено не са пълни на 100%, така че общият трафик няма да бъде 80 гигабита / сек, а около 50-60, но това не е толкова малко.
Мащабируемост. Там, където вече има много видео потоци, може да има още повече, тъй като видеонаблюдението отдавна се е доказало като ефективен инструмент. Това предполага, че трябва да има резерв за производителност и резерв за връзки.

Търсим подходящо решение...

Естествено се опитахме да се възползваме максимално от собствения си опит. По времето, когато беше взето решението, вече имахме реализация на обработка на Ethernet пакети на устройството Berkut-MX, захранвано от FPGA (по-просто - MX). Използвайки Berkut-MX, успяхме да получим необходимите полета за анализ от заглавките на Ethernet пакетите. За съжаление, нямахме опит в обработката на такъв обем трафик с помощта на „обикновени“ сървъри, така че погледнахме на такова решение с известна предпазливост...

Изглежда, че всичко, което остава, е просто да приложим метода към RTP пакети и златният ключ ще бъде в джоба ни, но MX може да обработва само трафик; той няма възможностите за отчитане и съхраняване на статистика. В FPGA няма достатъчно памет за съхраняване на намерените връзки (комбинации IP-IP-порт-порт), тъй като в 2x10-гигабитова връзка, влизаща на входа, може да има около 15 хиляди видеопотока и за всеки трябва да " запомни” броя на получените пакети, броя на изгубените пакети и т.н... Освен това търсенето с такава скорост и такова количество данни, подлежащи на обработка без загуби, се превръща в нетривиална задача.

За да намерим решение, трябваше да „копаем по-дълбоко“ и да разберем какви алгоритми ще използваме за измерване на качеството и идентифициране на видео потоци.

Какво може да се измери с помощта на полетата на RTP пакет?

От описанието става ясно, че от гледна точка на качествените измервания в RTP пакета, ние се интересуваме от следните полета:

пореден номер - 16-битов брояч, който се увеличава с всеки изпратен пакет;
timestamp - времева марка, за h.264 стойността на дискретизация е 1/90000 s (т.е. съответства на честота от 90 KHz);
Бит за маркер. В rfc3550 обикновено се описва, че този бит е предназначен да указва „значими“ събития, но всъщност камерите най-често използват този бит, за да маркират началото на видеокадър и специализирани пакети със SPS/PPS информация.

Съвсем очевидно е, че поредният номер ви позволява да определите следните параметри на потока:

загуба на рамка;
повторно изпращане на пакета (дубликат);
промяна на реда на пристигане (пренареждане);
рестартиране на камерата, ако има голяма „празнина“ в последователността.

Timestamp ви позволява да измервате:

вариация на забавянето (наричана още трептене). В този случай 90 KHz брояч трябва да работи от приемащата страна;
по принцип забавяне на преминаването на пакета. Но за да направите това, трябва да синхронизирате времето на камерата с времевия печат и това е възможно, ако камерата предава доклади на изпращача (RTCP SR), което обикновено е неправилно, т.к. в реалния живот много камери игнорират съобщението RTCP SR (около половината от камерите, с които сме работили).

Е, M-bit ви позволява да измервате честотата на кадрите. Вярно е, че SPS/PPS кадрите на протокола h.264 въвеждат грешка, защото не са видео рамки. Но това може да бъде смекчено чрез използване на информация от заглавката на NAL-единицата, която винаги следва RTP заглавката.

Подробните алгоритми за измерване на параметрите са извън обхвата на статията, няма да навлизам в дълбочина. Ако се интересувате, rfc3550 има примерен код за изчисляване на загубите и формула за изчисляване на трептене. Основният извод е, че за измерване на основните характеристики на транспортния поток са достатъчни само няколко полета от RTP пакети и NAL единици. Но останалата част от информацията не участва в измерванията и може и трябва да бъде изхвърлена!

Как да идентифицирам RTP потоци?

За да се поддържа статистика, информацията, получена от RTP хедъра, трябва да бъде „свързана“ с идентификатор на камера (видео поток). Камерата може да бъде уникално идентифицирана по следните параметри:

IP адреси на източника и местоназначението
Изходен и дестинационен порт
SSRC. От особено значение е, когато от едно IP се излъчват няколко потока, т.е. в случай на многопортов енкодер.

Интересното е, че първоначално идентифицирахме камерите само по IP на източника и SSRC, разчитайки на идеята, че SSRC трябва да е случаен, но на практика се оказа, че много камери задават SSRC на фиксирана стойност (да речем 256). Явно това се дължи на спестяване на ресурси. В резултат на това трябваше да добавим портове към идентификатора на камерата. Това реши напълно проблема с уникалността.

Как да отделя RTP пакети от друг трафик?

Остава въпросът: как Berkut-MX, след като получи пакета, ще разбере, че това е RTP? RTP хедърът няма такава изрична идентификация като IP, няма контролна сума, може да се предава чрез UDP с номера на портове, които се избират динамично при установяване на връзка. Но в нашия случай повечето от връзките вече са установени от дълго време и можете да чакате много дълго време за преинсталиране.

За да се реши този проблем, rfc3550 (Приложение A.1) препоръчва да се проверят битовете на RTP версията - това са два бита, а полето Payload Type (PT) е седем бита, което в случай на динамичен тип заема малък диапазон. На практика установихме, че за много камери, с които работим, PT попада в диапазона от 96 до 100.

Има още един фактор - паритет на пристанището, но както показа практиката, той не винаги се спазва, така че трябваше да бъде изоставен.

По този начин поведението на Berkut-MX е следното:

Получаваме пакета, анализираме го в полета;

ако версията е 2 и типът полезен товар е в посочените граници, тогава изпращаме заглавките към сървъра.

Очевидно при този подход има фалшиви положителни резултати, т.к Не само RTP пакетите могат да попаднат под такива прости критерии. Но за нас е важно, че определено няма да пропуснем RTP пакета и сървърът ще филтрира „грешните“ пакети.

За да филтрира фалшивите случаи, сървърът използва механизъм, който регистрира източника на видео трафик в няколко последователно получени пакета (пакетът съдържа пореден номер!). Ако са пристигнали няколко пакета с последователни номера, това не е случайно съвпадение и започваме да работим с този поток. Този алгоритъм се оказа много надежден.

Да продължим...

След като осъзнахме, че цялата информация, идваща в пакетите, не е необходима за измерване на качеството и идентифициране на потоци, ние решихме да поставим цялата високонатоварена и критична във времето работа по получаване и изолиране на полетата на RTP пакети на Berkut-MX, т.е. на FPGA. Той „намира“ видео потока, анализира пакета, оставя само необходимите полета и го изпраща в UDP тунел към обикновен сървър. Сървърът прави измервания за всяка камера и записва резултатите в базата данни.

В резултат на това сървърът работи не с 50-60 Gigabit/s, а с максимум 5% (точно това е съотношението на изпратените данни към средния размер на пакета). Тоест входът на цялата система е 55 Gigabit/s, а до сървъра достига само не повече от 3 Gigabit/s!

В резултат на това получихме следната архитектура:

И получихме първия резултат в тази конфигурация две седмици след задаване на първоначалните технически спецификации!

Какво в крайна сметка прави сървърът?

И така, какво прави сървърът в нашата архитектура? Неговите задачи:

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

Като се има предвид, че общият трафик на входа на сървъра е около 3 Gigabit/s, сървърът се справя дори и да не използваме DPDK, а просто да работим през Linux сокет (като преди това сме увеличили размера на буфера за сокета, разбира се). Освен това ще бъде възможно да се свързват нови връзки и MX, тъй като маржът на производителността остава.

Ето как изглежда горната част на сървъра (това е горната част само на един lxc контейнер, отчетите се генерират в друг):

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

Минуси и плюсове

Време е да се похвалите и да признаете недостатъците на решението.

Ще започна с плюсовете:

без загуби на интерфейса с 10G връзки. Тъй като FPGA поема цялото „въздействие“, можем да сме сигурни, че всеки пакет ще бъде анализиран;
за да наблюдавате 55 000 камери (или повече), имате нужда само от един сървър с една 10G карта. В момента използваме сървъри, базирани на 2 Xeon-а с 4 ядра по 2400 MHz всяко. Достатъчно за спестяване: успоредно със събирането на информация се генерират отчети;
наблюдението на 8 „дузини“ (10G връзки) се побира само в 2-3 единици: не винаги има много място и мощност в шкафа за система за наблюдение;
когато свързвате връзки от MX през комутатора, можете да добавяте нови връзки, без да спирате наблюдението, защото не е необходимо да вмъквате никакви платки в сървъра и не е необходимо да го изключвате, за да направите това;
сървърът не е претоварен с данни, той получава само това, което е необходимо;
заглавките от MX идват в jumbo Ethernet пакет, което означава, че процесорът няма да бъде затрупан от прекъсвания (освен това не забравяме за коалесцията на прекъсванията).

За да бъда честен, ще разгледам и недостатъците:

поради строгата оптимизация за конкретна задача, добавянето на поддръжка за нови полета или протоколи изисква промени в кода на FPGA. Това води до повече прекарано време, отколкото ако направихме същото на процесора. Както в разработка и тестване, така и в разгръщане;
видео информацията изобщо не се анализира. Камерата може да заснема ледена висулка, висяща пред нея, или може да е обърната в грешната посока. Този факт ще остане незабелязан. Ние, разбира се, предоставихме възможност за запис на видео от избрана камера, но операторът не може да премине през всичките 55 000 камери!
сървър и устройства, работещи с FPGA, са по-скъпи от само един или два сървъра;)

Резюме

В крайна сметка получихме софтуерно-хардуерен комплекс, в който можем да контролираме както частта, която анализира пакетите на интерфейсите, така и тази, която поддържа статистика. Пълният контрол върху всички системни възли буквално ни спаси, когато камерите започнаха да се превключват в RTSP/TCP interleaved режим. Тъй като в този случай RTP хедърът вече не се намира в пакета с фиксирано отместване: той може да се намира навсякъде, дори на границата на два пакета (първата половина в единия, втората в другия). Съответно алгоритъмът за получаване на RTP хедъра и неговите полета претърпя драматични промени. Трябваше да направим повторно сглобяване на TCP на сървъра за всички 50 000 връзки - оттук и доста високото натоварване в горната част.

Никога преди не сме работили в областта на приложения с високо натоварване, но успяхме да разрешим проблема, използвайки нашите FPGA умения и се получи доста добре. Дори остава резерв - например към система с 55 000 камери могат да се свържат още 20-30 хиляди потока.

Оставих настройката на подсистемите на Linux (разпределяне на опашки за прекъсване, увеличаване на буферите за получаване, директно разпределение на ядра към конкретни процеси и т.н.) извън обхвата на статията, т.к. Тази тема вече е много добре покрита.

Не съм описал всичко, събрах много рейкове, така че не се колебайте да задавате въпроси :)

Много благодаря на всички, които прочетоха до края!