Контролният протокол RTP (RTCP - Real-Time Control Protocol) се основава на периодично предаване на контролни пакети до всички участници в комуникационна сесия, използвайки същия механизъм за разпространение като RTP протокола. Базовият протокол трябва да осигурява мултиплексиране на информационни и контролни пакети, например, използвайки различни номера на UDP портове. Протоколът RTCP изпълнява четири основни функции.
Функции от една до три са необходими, когато RTP се използва при IP мултикастиране и се препоръчват във всички останали случаи. Разработчиците на RTP приложения се съветват да избягват механизми, които работят само двупосочно и не са мащабируеми за увеличаване на броя на потребителите.
4.1. Изисквания за RTCP пакети
Няколко вида RTCP пакети са дефинирани за предаване на различни видове контролна информация, включително:
- SR: Sender Report, за статистическа информация относно предаването и приемането на участници, които са активни изпращачи;
- RR: Отчет на получателя, за статистически данни за получаване от участници, които не са активни податели;
- SDES: клаузи за описание на източника, включително CNAME;
- BYE: индикатор за край на телеконференцията;
- APP: Функции, дефинирани от приложението.
Всеки RTCP пакет започва с фиксирана част (подобно на фиксираната част на RTP информационните пакети). Това е последвано от структурни елементи, които могат да бъдат с променлива дължина в зависимост от типа на пакета, но винаги са подравнени на 32-битова граница. Изискването за подравняване и включването на поле за дължина във фиксираната част са предназначени да осигурят "способност за подреждане" на RTCP пакети. Множество RTCP пакети могат да бъдат свързани без никакви разделители, за да образуват съставен RTCP пакет, който се пренася в един основен блок от данни на протокола, като UDP. Няма индикация за броя на отделните RTCP пакети в съставен пакет, тъй като основните протоколи използват информация за общата дължина на съставния пакет, за да определят края на съставния пакет.
Всеки отделен RTCP пакет в съставен пакет може да се обработва отделно без никакви изисквания по отношение на реда или комбинацията от пакети. Въпреки това, за да функционират правилно функциите на протокола, съществуват следните изисквания.
Статистиката за приемане (в SR пакети с доклади на подател или RR пакети с отчети на получател) трябва да се изпраща толкова често, колкото честотната лента позволява, за да се увеличи максимално точността на статистиката: следователно всеки RTCP съставен пакет трябва да включва пакет с отчети.
Новите участници в телеконференцията трябва да получат канонично име на източник (CNAME) възможно най-скоро, за да идентифицират източника и да започнат да преговарят за медийния формат, така че всеки съставен RTCP пакет трябва също да включва SDES пакет с описание на източника с клауза CNAME.
Броят на типовете пакети, които могат да се появят първи в съставен пакет, трябва да бъде ограничен, за да се увеличи броят на постоянните битове в първата дума и да се намали вероятността от грешки при разпознаването на RTCP пакети сред пакети на други протоколи.
Следователно всички RTCP пакети трябва да бъдат изпратени в съставен пакет, съдържащ поне два отделни пакета (SR/RR и SDES), със следния препоръчителен формат.
Префикс за криптиране. Ако и само ако един съставен пакет трябва да бъде шифрован, тогава той се предшества от произволна 32-битова стойност, която се препредава във всеки съставен пакет.
SR или RR. Първият RTCP пакет в съставен пакет винаги трябва да бъде пакет за отчет, за да се улесни валидирането на заглавката. Това се изисква дори ако не са изпратени или получени данни и ако единственият RTCP пакет в съставния пакет е BYE пакет (тогава се изпраща празен RR пакет).
Допълнителни RR пакети. Ако броят на източниците, за които се докладва получена статистика, надвишава 31 (максималният брой източници, докладван в единичен SR или RR пакет), тогава първоначалният пакет за отчет трябва да бъде последван от допълнителни RR пакети.
SDES. SDES пакет, съдържащ клауза CNAME, ТРЯБВА да бъде включен във всеки съставен RTCP пакет. Ако се изисква от конкретно приложение, допълнителни клаузи за описание на източника могат да бъдат включени в SDES пакета в съответствие с ограниченията на честотната лента (вижте ).
ЧАО или ПРИЛОЖЕНИЕ. Другите типове RTCP пакети могат да се появят в произволен ред, с изключение на това, че пакетът BYE трябва да бъде последният пакет, изпратен с даден SSRC/CSRC.
Желателно е транслаторите и смесителите да комбинират отделни RTCP пакети от множеството източници, с които оперират, в един съставен пакет, когато е възможно, за да намалят излишъка и да избегнат изпращането на ненужни заглавки на пакети (вижте Раздел 5). Ако общата дължина на съставен пакет надвишава максималната единица за предаване (MTU) на мрежовия път, тогава съставният пакет може да бъде сегментиран на много по-къси съставни пакети, които ще бъдат предадени в отделни единици данни на основния протокол. Имайте предвид, че в този случай всеки от съставните пакети трябва да започва със SR или RR пакет.
Едно приложение може да игнорира входящи RTCP пакети от неизвестен тип. Допълнителни типове RTCP пакети могат да бъдат регистрирани в Internet Assigned Numbers Authority (IANA).
4.2. Скорост на предаване на пакети RTCP
RTP протоколът позволява на приложението автоматично да мащабира представителността на комуникационна сесия, варираща от няколко участници до няколко хиляди. Например при аудиоконференция трафикът на данни е по същество самоограничаващ се, тъй като само един или двама души могат да говорят наведнъж, а при групово разпределение скоростта на данни във всяка връзка остава относително постоянна, независимо от броя на участниците. Контролният трафик обаче не се самоограничава. Ако отчетите за получаване от всеки участник се изпращат с постоянна скорост, тогава контролният трафик ще расте линейно с увеличаване на броя на участниците. Следователно трябва да се предвиди специален механизъм за намаляване на честотата на предаване на контролните пакети.
За всяка сесия се приема, че трафикът на данни отговаря на общо ограничение, наречено честотна лента на сесията, което се споделя от всички участници. Тази честотна лента може да бъде резервирана и нейното ограничение се задава от мрежата. Широчината на честотната лента на сесията не зависи от типа кодиране на медия, но изборът на тип кодиране може да бъде ограничен от честотната лента на сесията. Очаква се настройката за честотна лента на сесията да бъде осигурена от приложението за управление на сесия, когато извиква медийното приложение, но медийните приложения могат също така да задават стойност по подразбиране въз основа на честотната лента на данните за един подател за типа кодиране, избран за дадена сесия.
Изчисленията на честотната лента за управление и трафик на данни се извършват, като се вземат предвид основните протоколи за транспорт и мрежов слой (като UDP и IP) . Заглавките на слоя за връзка за данни (DLC) не се вземат предвид при изчисленията, тъй като пакетът може да бъде капсулиран с различни заглавки на слоя DLC, докато се предава.
Контролният трафик трябва да бъде ограничен до малка и известна част от честотната лента на сесията: достатъчно малка, за да не бъде засегната основната функция на транспортния протокол - предаване на данни; известен, така че контролният трафик да може да бъде включен в спецификацията на честотната лента, дадена на протокола за резервиране на ресурси, и така че всеки участник да може самостоятелно да изчисли своя дял. Предполага се, че частта от честотната лента на сесията, разпределена за RTCP, трябва да бъде зададена на 5%. Всички участници в сесията трябва да използват еднакво количество RTCP честотна лента, така че изчислените стойности на интервала на предаване на контролен пакет да са еднакви. Следователно тези константи трябва да бъдат зададени за всеки профил.
Алгоритъмът за изчисляване на интервала между изпращането на съставни RTCP пакети за разделяне на честотната лента, разпределена за контролния трафик между участниците, има следните основни характеристики.
Подателите колективно използват поне 1/4 от честотната лента на контролния трафик, както при сесии с много получатели, но малко податели; Веднага след като връзката бъде установена, участниците получават CNAME на изпращащите сайтове в рамките на кратък период от време.
Изисква се изчисленият интервал между RTCP пакетите да бъде най-малко по-голям от 5 секунди, за да се избегнат изблици на RTCP пакети, надвишаващи разрешената честотна лента, когато броят на участниците е малък и трафикът не е изгладен според закона за големите числа.
Интервалът между RTCP пакетите се променя на случаен принцип в рамките на половин до един и половина от изчислените интервали, за да се избегне неволно синхронизиране на всички участници. Първият RTCP пакет, изпратен след въвеждане на сесия, също се забавя произволно (до половината от минималния RTCP интервал) в случай, че приложението се стартира на няколко сайта едновременно, като например при обявяване на началото на сесия.
За автоматично адаптиране към промените в количеството предадена контролна информация се изчислява динамична оценка на средния съставен размер на RTCP пакета, като се използват всички получени и изпратени пакети.
Този алгоритъм може да се използва за сесии, в които предаването на пакети е приемливо за всички участници. В този случай параметърът за честотна лента на сесията е честотната лента на отделния подател, умножена по броя на участниците, а RTCP честотната лента е 5% от тази стойност.
4.2.1. Отчитане на броя на участниците в комуникационна сесия
Изчисляването на интервалите на предаване на RTCP пакет зависи от оценката на броя на участниците в комуникационната сесия. Новите членове се броят, когато се регистрират и когато за всеки се създаде запис в таблица със съответния SSRC или CSRC ID (вижте раздел 6.2). Новите записи не могат да влязат в сила, докато не бъдат получени множество пакети, съдържащи новия SSRC. Когато се получи BYE пакет със съвпадащ SSRC ID, записите в таблицата се премахват.
Участник може да маркира друг сайт като неактивен или да изтрие съответния запис, ако не са получени RTP или RTCP пакети за определен брой RTCP интервали за отчитане (предлагат се пет интервала). Това осигурява известна устойчивост срещу загуба на пакети. Всички сайтове трябва да изчислят приблизително един и същ период на отчитане на RTCP според указаното време за изчакване, за да функционират правилно.
Ако сайт, разпознат като участник в телеконференция, впоследствие бъде маркиран като неактивен, състоянието на този сайт трябва да остане непроменено за известно време и сайтът все още трябва да се брои в общия брой сайтове, споделящи RTCP честотна лента. Предложената стойност за това изчакване е 30 минути. Имайте предвид, че това все още е по-голямо от 5 пъти най-големия очакван и приемлив RTCP интервал на отчитане, който е приблизително 2 до 5 минути.
4.2.2. Разпределение на честотната лента за SDES пакети с описание на източника
В допълнение към необходимата клауза CNAME на пакетите с описание на източника (SDES - описание на източника) тази статия обсъжда и други елементи, като ИМЕ (лично име), EMAIL (имейл адрес) и др. Приложенията трябва да обмислят възможността за предаване на допълнителни точки, когато разпределят RTCP честотна лента, тъй като това ще забави скоростта, с която се предават отчетите за получаване и CNAME, като по този начин ще влоши производителността на протокола. Препоръчва се не повече от 20% от честотната лента на RTCP, разпределена за един участник, да се използва за предаване на допълнителна информация. Освен това не се изисква всички клаузи на SDES да се използват от всяко приложение. Тези, които са включени в употреба, трябва да имат определена част от честотната лента, която им е присвоена.
Например едно приложение може да бъде проектирано да включва само клаузи CNAME, NAME, EMAIL и никакви други в SDES пакети. Елементът NAME може да получи много по-висок приоритет от елемента EMAIL, тъй като елементът NAME ще се показва непрекъснато в потребителския интерфейс на дадено приложение, докато елементът с потребителско описание EMAIL ще се показва само при поискване. На всеки RTCP интервал се изпращат RR пакет и SDES пакет с клауза CNAME. За сесия с малък брой потребители, работеща на минимален интервал на отчитане, това ще бъде средно на всеки 5 секунди. На всеки трети интервал (15 секунди), един допълнителен елемент ще бъде включен в SDES пакета. Седем от осем пъти ще бъде елементът NAME и всеки осми път (2 минути) ще бъде елементът EMAIL.
Ако множество приложения работят едновременно, комуникирайки помежду си чрез общ CNAME (например в мултимедийна конференция, съставена от RTP сесии за всеки тип трафик), тогава допълнителната SDES информация може да бъде представена само в една RTP сесия. Във всички други сесии се предава само клаузата CNAME.
4.3. Пакети с отчети на изпращача и получателя (SR и RR)
RTP получателите предоставят обратна връзка - оценка на качеството на приемане - с помощта на RTCP пакети с отчети, които могат да приемат една от двете форми в зависимост от това дали получателят е и изпращач или не. Единствената разлика между формулярите SR (отчет на подателя) и отчета на получателя (RR), различни от кода на типа пакет, е, че докладът на подателя включва 20-байтова секция с информация за изпращача за използване от активни податели. SR се изпраща, ако сайтът е изпратил някакви пакети данни през интервала от изпращането на последния или предишния отчет, в противен случай се изпраща RR.
Формулярите SR и RR включват нула или повече блокове за отчет за получаване, по един за всеки от източниците на синхронизация, от които получателят е получил RTP пакети данни след последния доклад. Не се издават отчети за включени източници, посочени от CSRC. Всеки блок за отчет за получаване предоставя статистика относно данните, получени от конкретния източник, идентифициран в този блок. Тъй като в SR или RR пакетите са възможни максимум 31 блока за получаване на отчет, допълнителни RR пакети могат да бъдат подредени след първоначалните SR или RR пакети. Това е необходимо, за да съдържа отчети за приемане за всички източници, маркирани по време на интервала на докладване след последния доклад.
Следващите раздели определят форматите на двата типа пакети с отчети (подател и получател), как те могат да бъдат разширени по дефиниран от профила начин, ако приложението изисква допълнителна информация за обратна връзка и как могат да се използват отчетите. Подробности за получаване на доклади от преводачи и смесители са дадени в раздел 5.
4.3.1. Формат на пакета за доклад на изпращача (SR).
Пакетът с отчет на изпращача съдържа три основни секции и може да съдържа опционална четвърта секция за разширение, дефинирана от профила. Първият раздел, заглавката, е с дължина 8 октета (вижте таблицата). Неговите полета имат следните значения.
Версия (V - версия): 2 бита. Идентифицира RTP версията, която е една и съща в RTCP пакетите и RTP информационните пакети. Тази статия обсъжда версия 2 на протокола.
Допълнение (стр - подложка): 1 бит. Ако битът за допълване е зададен на 1, тогава този RTCP пакет съдържа някои допълващи октети в края, които не са част от контролната информация. Последният октет за допълване е броят на допълнителните октети, които трябва да се игнорират. Подпълването може да се изисква от някои алгоритми за криптиране с фиксирани размери на блокове. В съставен RTCP пакет подпълването трябва да се използва само в последния отделен пакет, тъй като съставният пакет е криптиран като цяло.
Брояч на отчети за получаване (RC - брой отчети за приемане): 5 бита. Броят блокове за получени отчети, съдържащи се в този пакет. Нула е възможна RC стойност.
Тип пакет (PT - тип пакет): 8 бита. Съдържа константата 200 за идентифициране на пакета като RTCP SR пакет.
Дължина: 16 бита. Дължината на даден RTCP пакет в 32-битови думи минус една дума, включително заглавката и всякаква подложка (отместване с единица прави нулата валидна стойност и предотвратява възможността за безкраен цикъл при разглеждане на съставен RTCP пакет; от друга страна , преброяването на 32-битови думи елиминира проверката на валидността на дължината на стойността за кратни на четири).
SSRC: 32 бита. Идентификаторът на източника на часовника за източника на този SR пакет.
Вторият раздел, информация за изпращача, е с дължина 20 октета и присъства във всеки пакет с отчет за изпращача. Той обобщава фактите за предаване на данни от този подател. Полетата от втория раздел имат следните значения.
NTP клеймо за време: 64 бита. Показва абсолютния час, в който е изпратен този отчет, така че да може да се използва в комбинация с времеви клейма, върнати в отчетите за получаване от други получатели, за измерване на времето за двупосочно предаване за тези получатели. Получателите трябва да очакват, че точността на измерването на клеймото за време може да се приеме, че е много по-малка от резолюцията на клеймото за време NTP. Несигурността на измерването за клеймото за време не е посочена, защото не може да бъде известна. Изпращач, който може да следи изминалото време, но няма информация за абсолютното време, може вместо това да използва изминалото време от началото на връзката на сесията. Трябва да е по-малко от 68 години, тогава най-значимата цифра ще има нулева стойност. За оценка на изминалото абсолютно време е допустимо да се използва таймер за вземане на проби. Изпращач, който не познава абсолютното или изминалото време, може да зададе времевия печат на NTP на нула.
Времево клеймо на RTP: 32 бита. Съответства на същото време като времевия печат на NTP (вижте по-горе), но се изразява в същите единици и със същото произволно отместване като времевия печат на RTP в пакетите с данни. Това картографиране може да се използва за външна и вътрешна мултимедийна синхронизация на източници, чиито NTP времеви отпечатъци са синхронизирани и може да се използва от независими от типа трафик приемници за оценка на номиналната честота на RTP таймера. Обърнете внимание, че в повечето случаи това времево клеймо няма да бъде равно на RTP клеймото във всеки съседен информационен пакет. Изчислява се от съответния времеви печат на NTP, като се използва връзката между брояча на времевия печат на RTP и реалното време, което се поддържа чрез периодично наблюдение на абсолютното време по време на вземане на проби.
Брояч на изпращащи пакети: 32 бита. Общият брой RTP информационни пакети, предадени от изпращача от началото на предаването до момента на генериране на SR пакета. Броячът се нулира, ако подателят промени своя SSRC ID.
Брояч на октети на подателя: 32 бита. Общият брой октети за трафик (т.е. пакетни октети, без заглавие и подплата), предадени в RTP информационни пакети от подателя от момента на започване на предаването до момента на генериране на SR пакета. Броячът се нулира, ако подателят промени своя SSRC ID. Това поле може да се използва за оценка на средната скорост на трансфер на трафик.
Третият раздел на пакета SR съдържа нула или повече блокове за получени отчети (започвайки с последния доклад) в зависимост от броя на другите източници, които подателят "вижда". Всеки блок за отчет за получаване докладва статистическа информация за приемането на RTP пакети от един източник на часовник. Получателите не прехвърлят статистика, когато източникът промени своя SSRC ID поради сблъсъци. Тези статистики включват следната информация.
SSRC_n (идентификатор на източника): 32 бита. SSRC идентификаторът на източника, за който се отнася информацията в този блок за получен отчет.
Степен на загуба: 8 бита. Частта от RTP информационни пакети от източник SSRC_n, които са били загубени след изпращането на предишния SR или RR пакет, изразена като цяло число с фиксирана запетая без знак (като цяло число след умножаване на фракцията на изгубените пакети по 256). Тази част се дефинира като броят на загубените пакети, разделен на броя на очакваните пакети. Ако стойността на загубата е отрицателна поради наличието на дублиращи се пакети, тогава степента на загуба е равна на нула.
Общ брой загубени пакети: 24 бита. Общият брой RTP пакети данни от източник SSRC_n, които са били загубени от началото на получаването. Това число е разликата между броя пакети, които се очаква да бъдат получени, и броя на действително получените пакети. Получените пакети включват всякакви пакети, включително закъснели пакети и дубликати. По този начин пакетите, които пристигат със закъснение, не се считат за изгубени и броят на загубите може да бъде отрицателен, ако има дубликати. Очакваният брой пакети е разликата между последния получен пореден номер и първоначално получения пореден номер.
Получен разширен най-голям пореден номер: 32 бита. По-малките 16 бита съдържат най-високия пореден номер, получен в RTP информационния пакет от източник SSRC_n, а най-значимите 16 бита разширяват този пореден номер със съответния брояч на цикъла на пореден номер . Обърнете внимание, че различните получатели в рамките на една и съща сесия ще генерират различни разширения на пореден номер, ако началните им времена се различават значително.
Трептене при пристигане: 32 бита. Това е статистическа оценка на разликата в относителните времена на пристигане на RTP информационни пакети, измерена в единици времеви клейма и изразена като цяло число без знак. Трептенето при пристигане J се определя като средната стойност (изгладена абсолютна стойност) на разликата D на времето между пристигането на два пакета до получателя и времето между моментите на предаване на тези пакети. Както е показано в уравнението по-долу, това е еквивалентно на разликата в относителното време на предаване за двата пакета (относителното време на предаване е разликата между клеймото на RTP пакета и стойността на таймера на получателя в момента на пристигане, изразено в същото единици).
Ако Si е времевият печат на RTP на пакет i и Ri е времето на пристигане в единици на времевия печат на RTP на пакет i, тогава за два пакета i и j, D може да се изрази като
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si).
Трептенето при пристигане се изчислява непрекъснато, докато всеки информационен пакет i пристига от източник SSRC_n, като се използва разликата D за този пакет и предишния пакет i-1 в реда на пристигане (не непременно в последователността на предаване), съгласно формулата
J=J+(|D(i-1,i)|-J)/16.
Всеки път, когато се изпрати отчет за получаване, се определя текущата стойност на J. Изчислението на трептенето, описано тук, позволява на независими от профила монитори да правят правилни интерпретации на доклади, идващи от различни реализации. Този алгоритъм е оптимален оценител от първи ред и коефициент на тежест от 1/16 дава добър коефициент на намаляване на шума, като същевременно поддържа приемлива степен на конвергенция.
Последно времево клеймо на SR (LSR): 32 бита. Средните 32 бита от 64-те бита на времевия печат на NTP (както е показано в раздел 2.4), получени като част от най-новите пакети за RTCP Sender Report (SR) от източник SSRC_n. Ако SR все още не е получен, тогава LSR клеймото за време има стойност нула.
Латентност от последния SR (DLSR): 32 бита. Закъснението при приемника на пакета, изразено в единици, равни на 1/65536 от секундата, между получаването на последния SR пакет от източник SSRC_n и изпращането на този блок с отчет за получаване. Ако SR пакет все още не е получен от SSRC_n, тогава полето DLSR има стойност нула.
Използвайки последното времево клеймо на SR (LSR) и латентност от последните стойности на SR (DLSR), източникът SSRC_n може да изчисли забавянето на разпространението на пакетите по пътя към и от дестинацията SSRC_r (закъснение при двупосочно пътуване). Когато пристигне отчет за получаване, източникът SSRC_n записва времето на това събитие T. След това изчислява общото време за двойно прескачане T-LSR, като използва полето за последно SR времево клеймо (LSR) и изважда забавянето на DLSR, което води до време за двупосочно пътуване (T- LSR) -DLSR). Това може да се използва като груба мярка за разстоянието до клъстер от получатели, въпреки че някои връзки имат много асиметрични забавяния. отчет
Форматът на пакета RR (отчет на получателя) е същият като формата на пакета SR, с изключение на това, че полето за тип на пакета съдържа константа, равна на 201, и липсват пет думи от информация за изпращача (времеви клейма за NTP и RTP и пакет за подател и октетни броячи). Останалите полета имат същото значение като за SR пакета.
Когато няма предаване или приемане на данни за докладване, празен RR пакет (RC = 0) се поставя в началото на RTCP съставния пакет.
4.3.3. Разширяване на отчетите за изпращач и получател
Ако има допълнителна информация за подателя или получателите, която трябва да се докладва редовно, тогава профилът трябва да дефинира разширения към отчета за подателя и получателя. Използването на този метод е за предпочитане пред дефинирането на различен тип RTCP пакет, тъй като изисква по-малко излишък:
- по-малко октети на пакет (не се изисква RTCP хедър или SSRC поле);
- по-прост и по-бърз анализ, тъй като приложенията, работещи под този профил, могат да бъдат програмирани винаги да разглеждат полетата за разширение в непосредствено достъпното място след получаването на отчетите.
Ако е необходима допълнителна информация за изпращача, тя трябва да бъде включена първо в разширението за отчети за подателя, но не трябва да се показва в отчетите за получаване. Ако информацията за получателя трябва да бъде включена, данните могат да бъдат структурирани като блоков масив, паралелен на съществуващия блоков масив за отчет за получаване. Броят на блоковете трябва да бъде посочен от полето RC.
4.3.4. Анализ на отчети за изпращач и получател
Обратната връзка за качеството на получаване е полезна не само за изпращача, но и за получателите и мониторите от трети страни. Изпращачът може да променя своите предавания въз основа на обратна връзка; получателите могат да определят дали проблемите са местни, регионални или глобални; Мрежовите мениджъри могат да използват независими от профила монитори, които получават RTCP пакети, за да оценят производителността на мрежите за мултикаст разпространение.
Кумулативните броячи на изгубени пакети се използват в информацията за изпращача и блоковете за отчет за получаване. Разликата между стойностите на брояча в двата получени отчета може да се използва за оценка на текущото качество на предаване на пакети за кратки и дълги интервали от време, като същевременно се гарантира устойчивост срещу загуба на отчети. Данните за времевия печат на NTP позволяват нивата на загуба да бъдат изчислени от тези разлики през интервала между два отчета. Тъй като това времево клеймо е независимо от тактовата честота на кодиране на данни, могат да се използват независими от кодирането и профила монитори.
Нека разгледаме пример за изчисляване на скоростта на загуба на пакети в интервала между два доклада за получаване. Разликата между кумулативните броячи на изгубени пакети дава броя на изгубените пакети през този интервал. Разликата в последните получени разширени поредни номера дава броя на пакетите, очаквани през интервала. Съотношението на тези две величини е частта от загубите на пакети за интервал. Това съотношение трябва да е равно на стойността на полето за дял на загубите, ако двата доклада са последователни, в противен случай не. Броят на пакетите, загубени за 1 секунда, може да се получи чрез разделяне на скоростта на загуба на разликата в NTP времевите марки, изразена в секунди. Броят на получените пакети е броят на очакваните пакети минус броя на изгубените пакети. Броят на очакваните пакети може също да се използва за определяне на статистическата достоверност на всяка оценка на загубата. Например, загубата на един пакет от пет има по-ниска представителна стойност от загубата на 200 пакета от 1000.
От информацията за изпращача мониторът на трета страна може да изчисли средната скорост на трафик на интервала и средната скорост на предаване на пакети, без да получава данни. Съотношението на тези две величини дава средния размер на полето с данни. Ако вероятността за загуба на пакети не зависи от техния размер, тогава броят на пакетите, получени от определен приемник, умножен по средния размер на полето за данни (или съответния размер на пакета), дава пропускателната способност на този приемник.
В допълнение към кумулативните броячи, които предоставят мярка за загуба на пакети за дълги периоди от време въз основа на разлики в отчетите, полето Loss Fraction предоставя краткосрочна мярка, базирана на един отчет. Това става по-важно с нарастването на броя на участниците в телеконференцията, тъй като информацията за състоянието на приемане може да не бъде предоставена на всички получатели и интервалът между докладите става доста дълъг.
Полето за трептене при пристигане осигурява втора краткосрочна мярка за претоварване на мрежата. Загубата на пакети проследява продължително задръстване, докато трептенето може да проследява преходно задръстване. Критерият за трептене може да показва претоварване, преди да причини загуба на пакети. Тъй като полето за трептене при пристигане съдържа само моментно трептене в момента на генериране на отчета, може да е необходимо да се анализират множество отчети, получени от един и същ получател във времето или от множество получатели, например в рамките на една и съща мрежа.
Глава 6
Минало, настояще
и бъдещето на TCP/IP протокола
След като прочетете тази глава и изпълните практическите упражнения, ще можете да:
· разкажете историята на появата на TCP/IP;
· да обясни принципите на работа на TCP и IP протоколите, както и методите за използване на UDP протоколи вместо TCP;
· говори за IP адресиране и разбира как да го прилага в локални и глобални мрежи;
· разговор за новия протокол IP версия 6 и неговото предназначение;
· обсъждане на начини за използване на приложни протоколи, включени в TCP/IP стека;
· разбират предназначението на приложните протоколи на TCP/IP стека;
· свързване на изпълнението на TCP/IP с референтния модел на OSI.
Когато компютрите комуникират по интернет, те използват протокол за управление на предаването/интернет протокол (TCP/IP) като свой език за комуникация. Освен това TCP/IP протоколите се използват широко в повечето средни и големи мрежи. Тези протоколи поддържат мрежи, базирани на платформите Novell NetWare, UNIX и Windows, особено нововъзникващи мрежи и мрежи, които използват клиент-сървър или уеб-базирани приложения. Широкото приемане, доказана технология и разширяемост правят TCP/IP добър избор за повечето LAN и WAN проекти за взаимно свързване. Дори в малки мрежи внедряването на TCP/IP може да бъде жизненоважно за бъдещото развитие на мрежата.
Тази глава ще разгледа подробно TCP/IP протоколите, включително описания на TCP и IP пакети и методи за IP адресиране. Ще научите и за алтернатива на TCP - User Datagram Protocol (UDP), който се използва, когато потвърждаването на предадените данни не е толкова важно, колкото скоростта и ниското натоварване на мрежата. Главата обсъжда най-новата версия на IP протокола, наречена IPv6, и я сравнява с нейния предшественик IPv4. Освен това той описва приложните протоколи, включени в TCP/IP стека и предназначени за емулиране на терминали за прехвърляне на файлове и имейл съобщения, конвертиране и присвояване на IP адреси, както и за управление на мрежата. Накрая ще научите как TCP/IP архитектурата е свързана с референтния модел на OSI.
Кратка история на TCP/IP стека
В края на 60-те години ARPA работи, за да направи ARPANET достъпна за обществеността, позволявайки на компютри в университети, изследователски институции и Министерството на отбраната да комуникират в широкообхватна мрежа. Една от забележителните пречки за постигането на тази цел беше, че производителите на компютри имаха свои собствени стандарти и производителите защитаваха информацията за принципите на своите системи като търговска тайна.
Първият опит за създаване на средство за взаимодействие между различни компютри беше направен от няколко университета, които разработиха мрежов протокол, наречен мрежа контрол протокол (NCP) и позволи на хост компютри от различни компании, включително DEC и IBM, да обменят информация. NCP беше прост протокол, който позволяваше на различни видове DEC и IBM компютри да работят в мрежа и да изпълняват приложения през мрежа, в която хостовете са географски отдалечени един от друг. Например, едно от приложенията на протокола NCP беше прехвърлянето на файлове между компютри. Това беше добро начало, но NCP протоколът не можеше да осигури достатъчно надеждно предаване на данни, така че ARPA стартира проект за модернизирането му. Разработеният протокол всъщност беше комбинация от два протокола - Предаване контрол протокол (TCP) И интернет протокол (IP) чиито имена обикновено се съкращават на TCP/IP.
Забележка
NCP все още се използва в по-стари DEC и IBM мрежи, въпреки че е много трудно да се конфигурира. Този протокол създава голямо натоварване на процесора, тъй като съдържа известно ниво на мрежова комуникация, което не се използва от TCP.
внимание
IBM използва акронима NCP за обозначаване на своята програма за контрол на мрежата. Тази програма е приложение, което работи на периферен процесор (малък компютър) или SNA шлюз, който е свързан към мейнфрейма, позволявайки на последния да комуникира по мрежата.
Основи на TCP/IP стека
TCP протоколът, описан в RFC 793, първоначално е проектиран за комуникация от точка до точка между компютри в една и съща мрежа, докато IP протоколът (RFC 791) е предназначен да осигури комуникации между компютри, свързани към различни мрежи или към широкообхватни мрежи . Скоро след въвеждането им и двата протокола бяха комбинирани като TCP/IP стек за използване в популярните операционни системи Berkeley UNIX и бяха вградени в системата за виртуална памет на DEC (VMS, сега OpenVMS) и Multiple Virtual Storage (MVS, сега OpenMVS) IBM.
От въвеждането си в началото на 70-те години TCP/IP стекът се използва широко в мрежи по целия свят. Внедрява се за PC-съвместими компютри, UNIX работни станции, миникомпютри, Macintosh компютри и мрежови устройства, свързващи клиенти и хостове. TCP/IP предоставя на хиляди обществени и търговски мрежи интернет свързаност, която може да се използва от милиони хора.
TCP/IP е многослоен протоколен стек, който е подобен, но не и еквивалентен на OSI протоколните слоеве. TCP/IP стекът съдържа около сто стандартизирани протокола за осигуряване на надежден и ефективен трансфер на данни между системите. Основните протоколи в TCP/IP стека са следните:
· Протокол за контрол на предаването (TCP);
· Протокол за потребителска дейтаграма (UDP);
· Интернет протокол (IP).
Всеки от тези протоколи е разгледан подробно в следващите раздели.
Функциониране на протоколаTCP
TCP е транспортен протокол, който се използва за установяване на сесии с данни между процеси на приложения, стартирани от мрежови клиенти. TCP е проектиран да доставя данни надеждно, като гарантира, че кадрите се получават правилно и като контролира потока от данни. За да разреши тези проблеми, протоколът предвижда поръчване на рамки и потвърждаване на тяхното получаване.
Двете комуникиращи устройства определят пореден номер за всеки предаван кадър и този номер се записва в заглавката на TCP кадъра.Поредният номер не само показва местоположението на кадъра в следващите рамки, но също така показва дължината на данните, съдържащи се в тази рамка. При получаване на рамка приемащият възел проверява поредния номер, за да се увери, че е получил правилната рамка в правилния ред. Ако целевият възел получи рамката, той изпраща потвърждение на изпращащия възел. Пакетът за потвърждение не само показва успешното приемане на рамката, но също така съдържа поредния номер на следващата рамка, която получаващият възел чака за предаване.
Извиква се броят байтове данни, прехвърлени в рамка плъзганепрозорец (плъзгащ се прозорец), тъй като този брой може да се увеличи или намали в процеса на обмен на информация по взаимно съгласие между взаимодействащи възли. Размерът на плъзгащия се прозорец се определя динамично от възлите, като се вземат предвид два фактора:
· текущ мрежов трафик;
Кооперации с печалба (собственост на служителите)
Образователни
Правителство
Организации за регистрация на имена на домейни
Организации, създадени по международни договори
музей
Домейни за лично ползване
Доставчици на мрежови услуги
Нестопанска цел
Професионални (например асоциации на лекари, счетоводители или адвокати)
Таблица 6.4. DMS имена на домейни
Таблица 6.5. Предложени глобални имена на домейни от първо ниво (TLD)
Резолвери на именаDNSи пространства от имена
DNS услугата изисква преобразуватели на имена на домейни на всеки клиент, както и сървър за имена на домейни, инсталиран на един или повече хостове. Поддръжка на DNS сървъри пространство от имена(именно пространство) за предприятие и внедряване на механизъм за преобразуване на компютърни имена и домейни в IP адреси, както и обратното преобразуване. Пространството от имена е логическа област на мрежа, която съдържа списък с именувани обекти (като компютри) и позволява разделяне на имена.
Използване на зони
DNS сървърите поддържат таблици с информация, които свързват имена на компютри или домейни с IP адреси. Тези таблици са свързани с дяловете на DNS сървъра, наречени зонии съдържащи записи на ресурси. Всяка зона е таблица (файл на зона или база данни на зона) със записи на ресурси от различни типове (например записи, които свързват домейн сървъри с услуги, които се изпълняват на тези сървъри). Други записи на ресурси свързват имена на компютри и IP адреси.
Зоната, която свързва имената на компютрите със съответните JH адреси, се нарича зона за търсене напред. Тази зона съдържа записи на имена на хостове, наречени адресни записи. Всеки сървър и клиент в IP мрежа трябва да има адресен запис, който позволява да бъде намерен чрез DNS. Например, ако DNS сървърът е с име NetAdmin и има адрес 129.70.10.1, тогава зоната за търсене напред свързва името NetAdmin с адреса 129.70.10.1. За IPv4 записът на хост се нарича ресурсен запис на адрес на хост (A). За протокола IPv6 такъв запис се нарича ресурсен запис на адрес на хост (тип AAAA) (запис на ресурс на IPv6 хост адрес (AAAA)).
Забележка
Когато инсталирате директорийна услуга (като Active Directory), трябва да имате поне един DNS сървър във вашата мрежа, тъй като услугата е част от пространството от имена, използвано за съхраняване на информация за мрежови обекти (като компютри, принтери и споделяния). За да актуализира тази информация, справочната услуга трябва да комуникира с DNS сървъра.
В друга зона т.нар зона за обратно търсене(зона за обратно търсене) се съхраняват записи на указателни ресурси (като напрPTR) (запис на ресурс на указател (PTR), който свързва IP адреси с имена на хостове. Зоните за обратно търсене не се използват толкова често, колкото зоните за търсене напред, но не трябва да се създават в случаите, когато мрежовите комуникации изискват IP адрес да бъде свързан с име на компютър (например за наблюдение на мрежа чрез IP - адреси).
РолиDNS- сървъри
Обикновено DNS сървър в мрежа играе една от двете роли: може да действа или като основен DNS сървър, или може да действа като вторичен DNS сървър. ОсновенDNS- сървър(основен DNS сървър) се счита за сървър, който отговаря за определена зона и следователно се нарича авторитетен сървър за тази зона. Например, ако зона за директно търсене за домейн DD се създаде на определен DNS сървър за първи път, тогава запис на ресурс за начало на зона (SOA) (запис на ресурс за начало на авторитет (SOA)) идентифицира този сървър като доверен DNS сървър за домейна. Това означава, че всички промени в зоната (например създаване на записи за ресурс на адрес на хост (тип A)) трябва да се извършват на този сървър.
В средни и големи мрежи обикновено се инсталира един или повече резервни DNS сървъри, наречени (по отношение на основния DNS) допълнителен,или вторичен DNS- сървъри(вторичен DNS сървър). Вторичният DNS сървър съдържа копие на файла на зоната, съхранен на основния DNS сървър, но това копие не може да се използва за административни задачи. За да актуализирате копието, зоната се прехвърля по мрежата. По време на пренасочване на зона, съдържанието на зоната се прехвърля от основния DNS сървър към вторичния DNS сървър.
Допълнителните DNS сървъри изпълняват три важни задачи. Първо, те ви позволяват да получите копие на основните данни на DNS сървъра в случай на повреда на сървъра. Второ, те ви позволяват да разпределите натоварването на DNS услугата (позволявайки достъп до записи на споделени ресурси) между основния и вторичния DNS сървър. Балансирането на натоварването означава, че ако основният DNS сървър не може да разреши име поради претоварване, второ искане за разрешаване на име може да бъде обработено от вторичен DNS сървър, което води до по-бързи отговори на клиентските заявки. Трето, допълнителни DNS сървъри могат да бъдат поставени в различни зони на мрежата (например в различни подмрежи или на географски отдалечени сайтове), което води до намалено натоварване на отделни секции от мрежата.
съвет
За да се осигури толерантност към грешки в средни и големи мрежи, се препоръчва да се създаде поне един допълнителен ONS сървър във всяка подмрежа, която е различна от подмрежата, където се намира главният DNS сървър.
За да се запознаете със зоните, записите за ресурси за начало на зона (SOA) и друга информация, съхранявана на DNS сървър, изпълнете практика 6-8.
СтандартиDNS
Упълномощените сървъри обикновено поддържат два DNS стандарта: записи на ресурсни услуги и DNS Dynamic Update Protocol. Ресурсен записуслуги (видSVR) Запис на ресурс за услуга (SVR RR) е описан в RFC 2052 и е вид DNS запис, който позволява на DNS да разпознава различни сървъри и да определя местоположението на често използвани TCP/IP услуги, изпълнявани на конкретни сървъри. SRV записите позволяват на DNS сървъра да генерира списък от мрежови сървъри, които предоставят TCP/IP услуги. Тези записи също отчитат протоколите, поддържани от тези сървъри, и ви позволяват да определите предпочитания сървър за конкретна услуга. Форматът на SRV запис съдържа информация за типа услуга, изпълнявана на сървър, името на домейна, който се обслужва от този сървър, и протокола, използван от сървъра.
Протокол за динамично актуализиранеDNS(протокол за динамична актуализация на DNS) е описан в RFC 2136, с негова помощ можете автоматично да актуализирате информацията на 1 DNS сървър. Пример би бил работна станция с Windows XP Professional, актуализираща своя IP адрес, получен от DHCP сървър. Протоколът за динамично обновяване на DNS може да спести много време на мрежовия администратор, тъй като той няма да има нужда да регистрира ръчно всяка нова работна станция или да регистрира компютър всеки път, когато наетият IP адрес изтече при получаване на нов адрес.
съвет
В мрежа, работеща с Microsoft Active Directory, SRV записите позволяват на работните станции бързо да намерят най-близкия сървър за удостоверяване на заявките за влизане в мрежата. Това ви позволява да намалите ненужния мрежов трафик.
Протокол за динамично конфигуриране на хост (DHCP)
протокол Динамичен Домакин Конфигурация протокол (DHCP) (Dynamic Host Configuration Protocol) ви позволява автоматично да задавате 1P адреси в мрежата с помощта на DHCP сървър. Когато нов компютър, конфигуриран за DHCP, се присъедини към мрежата, той се свързва с DHCP сървър, който разпределя (наема) IP адрес на компютъра, като го предава през DHCP протокола. Продължителността на наема се задава на DHCP сървъра от мрежовия администратор. Например, периодът на наемане на настолен компютър може да варира от няколко дни до няколко седмици (тъй като компютърът е постоянно свързан към мрежата). Периодът на наемане на лаптоп може да варира от няколко часа до един ден (тъй като лаптопът често се изключва от мрежата или се премества в други части на мрежата). И накрая, хост компютърът или сървърът могат да наемат адреса завинаги, тъй като адресът му никога не се променя.
съвет
За да опростите администрирането на мрежата, инсталирайте съвместими DNS и DHCP сървъри, които поддържат протокола за динамично актуализиране на DNS. Това гарантира, че DNS зоните се актуализират автоматично от DHCP сървъра или DHCP клиентите и освобождава администратора от необходимостта да прави това ръчно.
Протокол за разрешаване на адреси(ARP)
В повечето случаи, за да изпрати пакет до приемащия хост, подателят трябва да знае както IP адреса, така и MAC адреса. Например при мултикастиране се използват и двата адреса (IP и MAC). Тези адреси не съвпадат с мен и имат различни формати (съответно десетичен и шестнадесетичен с точки).
Адрес Резолюция протокол (ARP) (Address Resolution Protocol) позволява на изпращащия възел да получи MAC адресите на избрания получаващ възел, преди да изпрати пакети. Ако изходният възел се нуждае от определен MAC адрес, тогава той изпраща ARP разпръскван кадър, съдържащ собствения му MAC адрес и IP адреса на желания приемащ възел. Получаващият възел изпраща обратно ARP пакет с отговор, съдържащ неговия MAC адрес.
Поддържащият протокол е Обратен Адрес Резолюция протокол (RARP) (Reverse Name Resolution Protocol), чрез който мрежовият хост може да определи своя собствен IP адрес. Например, RARP се използва от бездискови работни станции, които не могат да намерят своите адреси, освен като направят RARP заявка към своя хост сървър. Освен това RARP се използва от някои приложения за определяне на IP адреса на компютъра, на който се изпълняват.
Прост протокол за управление на мрежата (SNMP)
просто мрежа Управление протокол (SNMP) (Simple Network Management Protocol) позволява на мрежовите администратори непрекъснато да наблюдават мрежовата активност. SNMP е разработен през 80-те години, за да предостави на стека TCP/IP алтернативен механизъм на стандарта за управление на мрежата OSI. често срещани Управление Интерфейс протокол (CMIP) (Общ протокол за контролна информация).
Въпреки че SNMP е създаден за TCP/IP стека, той следва OSI референтния модел. Повечето производители са избрали да използват SNMP, а не CMIP, поради голямата популярност на TCP/IP протоколите, както и простотата на SNMP. SNMP се поддържа от много стотици мрежови устройства, включително файлови сървъри, мрежови адаптерни карти, рутери, повторители, мостове, комутатори и хъбове. За сравнение, CMIP се използва от IBM в някои Token Ring мрежи, но не се намира в много други мрежи.
ПредимстваSNMP
Важно предимство на SNMP е, че той работи независимо от мрежата, т.е. не се нуждае от двупосочна връзка с други мрежови обекти на ниво протокол. Това позволява на SNMP да анализира мрежовата активност, като откриване на непълни пакети и наблюдение на излъчвания, без да бъде засегнат от грешна информация, която може да дойде от дефектен възел. За сравнение, CMIP се свързва с мрежови възли на ниво протокол, което означава, че способността му да открива проблеми зависи от изправността на някой възел, който може да е повреден.
Друго предимство на SNMP е, че функциите за наблюдение се изпълняват в някаква станция за управление на мрежата. По това SNMP се различава от протокола CMIP, за който функциите за управление се разпределят между отделни мрежови възли, които също са обекти за наблюдение. Освен това SN. MP изисква по-малко RAM от CMIP. CMIP изисква до 1,5 MB памет за всеки изследван възел, докато SNMP изисква само 64 KB.
Типове възли, използвани от протоколаSNMP
Протоколът SNMP предоставя два типа възли: станция за управление на мрежата (NMS) и мрежови агенти. Станцията за управление на мрежата наблюдава мрежови устройства, които поддържат SNMP. Тези устройства работят с агентски софтуер, който взаимодейства със станцията. Повечето устройства, свързани към съвременните мрежи, са агенти. Те включват рутери, повторители, хъбове, комутатори, мостове, персонални компютри (чрез техните мрежови адаптери), сървъри за печат, сървъри за достъп и непрекъсваеми захранвания.
С помощта на конзолата в станцията за управление на мрежата можете да изпращате команди до мрежови устройства и да получавате данни за производителността (статистика). Станцията за управление на мрежата може да изгради блокова схема на цялата мрежа. Ако в мрежата се появи ново устройство, станцията може да го открие веднага. Софтуерът на станцията за управление на мрежата може да открие кога агентът е изключен или не работи правилно. Иконата на агента може да се появи в различен цвят на блок-схемата или може да прозвучи аларма. Обикновено програмите за станции за управление на мрежата имат графичен потребителски интерфейс и са много лесни за работа.
Много софтуерни пакети на станции за управление на мрежата могат да осигурят графични показания на броячите, които показват използването на мрежата, потока на пакетите и други статистики. Когато възникне неизправност, графичните символи ви помагат да разберете сериозността на проблема и да идентифицирате типа агент, който е неуспешен. Някои пакети имат интерфейси за програмиране на приложения (API), които ви позволяват да взаимодействате със софтуера и да програмирате специфични задачи, като използвате прост език (като Visual Basic).
Всеки мрежов агент съхранява информационна база, съдържаща броя на изпратените или получените пакети, броя на грешките в пакетите и други данни. Тази база данни се нарича Информационна база за управление (MIB). Станцията за управление на мрежата има много команди, които ви позволяват да осъществявате достъп и да управлявате данни в тази база данни. Такива команди се изпращат с помощта на съвместими с OSI протоколни единици данни (PDU) и съдържат тип съобщение (например получаване на заявка, получаване на следваща заявка, отговор на заявка, зададена заявка и системно прихващане). Получените данни ви позволяват да определите дали устройството е включено и дали има проблеми с мрежата. Станцията за управление на мрежата дори ви позволява да рестартирате устройството дистанционно. Съобщенията между станцията и агента се предават по UDP протокола, SNMP хедърът се добавя към пакетите. Полезният товар на SNMP съдържа име на групата(име на общността), което е парола, обща за станцията за управление на мрежата и агента.
Базата данни с информация за управление съхранява информация за мрежови обекти (като работни станции, сървъри, мостове, рутери, хъбове и повторители). Основният набор от променливи, съдържащи се в тази база данни, е представен в табл. 6.6. MIB таблицата първоначално е описана в стандарта Management Information Base-I. Този стандарт дефинира информация за устройството и много свързани променливи. MIB стандартите са разработени от Internet Engineering Task Force (IETF).
Таблица 6.6. Променливи на базата с контролна информация (МлIN)
ПроменливиMIB | Предназначение |
Група за превод на адреси | Преобразува мрежовите адреси в подмрежови адреси или физически адреси |
Група протоколи за електронен шлюз | Предоставя информация за хостовете в същия сегмент като мрежовия агент |
Група интерфейси | Следи броя на мрежовите адаптери и броя на подмрежите |
Група протоколи за интернет контролни съобщения | Събира данни за количеството. съобщения, изпратени и получени от агента |
Група интернет протоколи | Проследява броя на приетите входни дейтаграми и броя на отхвърлените дейтаграми |
SNMP група | Събира данни за обажданията към MIB базата данни |
Системна група | Съдържа информация за мрежовия агент |
Група протоколи за контрол на предаването | Предоставя информация за TCP връзките в мрежата, включително адрес и информация за изчакване |
Група протоколи за потребителска дейтаграма | Предоставя информация за слушащия агент, с който станцията за управление на мрежата комуникира в момента |
Новият, подобрен стандарт MIB-II описва допълнителни функции за сигурност, поддръжка за мрежи с токен ринг и високоскоростни интерфейси, както и поддръжка за телекомуникационни интерфейси. Стандартът MIB-II е възприет от много производители на мрежово оборудване.
Нови функции на протоколаSNMPv2
Първата версия на протокола SNMP имаше някои недостатъци, които бяха коригирани във втората версия, наречена SNMPv2. Може би най-големият недостатък на SNMP е липсата на механизми за сигурност. Когато използвате SNMP, името на групата се изпраща некриптирано от станцията за управление на мрежата и, ако бъде прихваната, тази парола може да се използва за получаване на достъп до важни команди за управление на мрежата. В резултат на такова изтичане атакуващият може дистанционно да промени настройките на рутер или хъб и да дискредитира сигурността на мрежата.
SNMPv2 позволява криптиране на имена на групи, подобрено обработване на грешки и оперативна съвместимост с много протоколи. Той също така поддържа IPX и AppleTalk. В допълнение, SNMPv2 осигурява по-бърз трансфер на информация и позволява повече данни да бъдат извлечени от MIB-II едновременно.
Мониторинг с помощта на протоколиSNMPИSNMPv2
Протоколите SNMP и SNMPv2 могат да се използват за управление на всяка мрежа: локална, глобална и смесена. Има много инструменти за наблюдение на мрежата и софтуерни пакети, които използват SNMP и SNMPv2. Те включват програмите Sniffer на Network Associates (вижте www. снифър. com) и Network Monitor от Microsoft (вижте www.).
Важен SNMP-съвместим инструмент, използван за наблюдение на локални мрежи, свързани чрез широкообхватни мрежи, е стандартът, разработен в началото на 90-те години Дистанционно мрежа Мониторинг (RMON) (отдалечено наблюдение на мрежата). RMON не само използва протокола SNMP, но също така използва специална база данни за дистанционно наблюдение, наречена RMON MIB-II. Тази база данни позволява на отдалечените мрежови възли да събират мрежова статистика почти навсякъде в локална или глобална мрежа. Тези отдалечени възли са агенти или сонди. Информацията, получена от агентите, може да бъде предадена на някаква контролна станция, която я въвежда в база данни. В момента стандартите RMON MIB-II са адаптирани към мрежи FDDI, Ethernet и Token Ring.
Други приложни протоколи на TCP/IP стека
Има други протоколи или приложения, които са част от TCP/IP стека - Те улесняват интернет услугите, трансфера на данни от мултимедийни приложения, управлението на мрежата и отстраняването на проблеми. Тези допълнителни протоколи и приложения са изброени в таблица. 6.7.
Таблица 6.7. TCP/IP стекови приложения и протоколи
Протокол илиприложение | Описание |
Приложение, което позволява на потребителя на TCP/IP стек да намира FTP сайтове, съдържащи информация по конкретна тема |
|
Bootstrap протокол (BOOTP) | Протокол, използван от бездискови работни станции за определяне на техния IP адрес и за комуникация със сървъра, от който се копират файловете на операционната система, необходими за стартиране на тези станции |
Протокол за мултикаст векторно маршрутизиране на разстояние (DVMRP) | Протокол за маршрутизиране на мултикаст, използван във връзка с RIP, за да се определи кои хостове са абонирани за групово предаване на специфични мултимедийни приложения (вижте глава 10) |
Използвайки тази помощна програма, мрежовият потребител може да определи кои други потребители и хостове са активни в мрежата |
|
Приложение, което предлага списък с теми, от които потребителите имат достъп до други менюта или текстови файлове (например файл, съдържащ списък с телефонни номера). Услугите на Gopher са рядкост в наши дни, защото бяха заменени предимно от уеб сървъри |
|
Протокол за трансфер на хипертекст (HTTP) | Протокол за предаване на HTML (Hypertext Markup Language) документи през Интернет въз основа на заявки от уеб браузъри; тези документи могат да включват аудио и видео файлове, както и изображения и графики |
Протокол за управление на интернет групи (IGMP) | Протокол, който позволява предаването на мултикаст пакети към техните получатели и рутери. Определя кои работни станции принадлежат към конкретна мултикаст група (см.глава 10) |
Multicast Open Shortest Path First Protocol (MOSPF) | Протокол за мултикаст маршрутизиране за определяне на най-краткия маршрут от източника до дестинацията за мултикаст предавания |
Open Shortest Path First Protocol (OSPF) | Протокол, използван от рутери за обмен на данни от таблици за маршрутизиране и за оценка на мрежови маршрути при предаване на данни въз основа на определени критерии (като цена на маршрута) |
Помощна програма, която позволява на мрежов възел да комуникира с друг възел в същата или отдалечена мрежа и да определи дали посоченият възел комуникира и отговаря на заявки. Мрежовият администратор може да използва помощната програма ping, за да провери бързо връзките към глобалната мрежа, като се свърже с някой отдалечен хост |
|
Протокол в реално време (RIP) | Този протокол се използва за ефективно управление на групови предавания в реално време, използвани за видеоконференции или подобни мултимедийни приложения. (вижте глава 10) |
Протокол за управление на транспорта в реално време (RTCP) | Позволява ви да управлявате мрежовия трафик, което улеснява използването на мултимедийни приложения в реално време (вижте глава 10) |
Протокол за резервиране на ресурси (RSVP) | Протокол, който позволява мрежовите ресурси да бъдат разпределени към конкретни приложения (например резервиране на честотна лента за мултимедийни приложения) (вижте глава 10) |
Протокол за информация за маршрутизиране (RIP) | Използвайки този протокол, рутерите предават съдържанието на таблиците за маршрутизиране един на друг и определят най-малкия брой релета от един мрежов възел към друг |
Прост протокол за управление на мрежата (SNMP) | Протоколът, който събира мрежова статистика, съхранява тази информация в база данни |
Traceroute (tracert) | Приложение, което позволява на потребителя да определи броя на релетата между два мрежови възела |
В практическите упражнения 6-9 и 6-10 можете да практикувате използването на командата ping, а в упражненията 6-11 и 6-12 ще научите как да използвате командите tracert и ping, за да определите броя на релетата от една точка на мрежа към друга.
Сравнение на TCP/IP стекова архитектура и референтен моделOSI
Както е показано на фиг. 6.11, компонентите на TCP/IP стека, обсъдени в тази глава, съответстват на слоевете на OSI референтния модел. Тъй като TCP/IP стекът се развива, неговите компоненти все повече следват OSI модела. Например, във физическия слой и слоя за връзка с данни TCP/IP стекът е съвместим с Ethernet, Token Ring, FDDI и ATM мрежи, както и мрежи с токен шини. На физическия слой TCP/IP стекът поддържа коаксиални, усукани двойки и оптични влакна, както и безжични комуникации. В допълнение, на слоя за връзка с данни, стекът е съвместим със стандарта IEEE 802.2 за контрол на логическата връзка и MAC адресиране.
Еквивалентът на мрежовия слой в TCP/IP стека е IP протоколът. Следващото ниво на съвместимост е транспортният слой; и двата протокола – TCP и UDP – могат да работят на това ниво. Горните слоеве на OSI модела са представени от TCP/IP приложни протоколи. Например, протоколът Telnet работи на ниво, еквивалентно на сесийния слой, докато протоколите SMTP и FTP работят на нива, подобни на OSI Representative и Application слоеве.
Резюме
· TCP/IP е най-широко използваният мрежов протокол в света. Той е основата за интернет и позволява на милиони компютри и сървъри, разположени по цялата планета, да взаимодействат помежду си. TCP протоколът е проектиран да предава надеждно данни чрез установяване на връзки между възли и използване на сигнали за потвърждение, че пакетите са получени.
· UDP протоколът е алтернатива на TCP. Поради факта, че връзките между възлите не са установени, той генерира по-малко служебна информация, но е по-малко надежден от TCP. IP протоколът се използва за предаване на пакети към приемащи възли в локални и глобални мрежи. Има методи за адресиране за идентифициране на възел и мрежата, в която се намира. Най-новата версия на IP е IPv6, която има разширен адресен формат, който му позволява да покрие големия брой нови мрежови и хост адреси, които се появяват поради бързия растеж на Интернет и различни мрежи.
· За надеждна доставка на пакети, всеки IP адрес трябва да бъде уникален. Методите за IP адресиране се използват за идентифициране на конкретен хост и мрежата, към която принадлежи.
· Важно е да се разбере, че основната цел на IPv6 е да осигури логичен преход от IPv4, така че приложенията и мрежовите устройства да могат да се справят с новите изисквания, когато възникнат.
· Всъщност TCP/IP е набор от протоколи и приложения, които предоставят важни възможности. Протоколът Telnet се използва за свързване на работни станции към хост компютри (като работните станции действат като терминали). FTP е протокол, който милиони клиенти използват всеки ден за изтегляне на файлове от интернет. SMTP протоколът захранва имейл услугите, а DNS преобразува имената на компютрите в техните IP адреси. Протоколът DHCP автоматично присвоява IP адреси на мрежови компютри. SNMP е важен за мрежите, защото може да събира информация за производителността на мрежата и може да се използва за отстраняване на проблеми. ARP позволява на компютри или устройства да определят MAC адреса на друг компютър или устройство.
· Броят на интернет програмите, локалните и глобалните мрежови приложения, както и техните възможности продължават да растат. TCP/IP изигра важна роля в развитието на мрежите и ще продължи да бъде важен и в бъдеще. Тъй като броят на мрежовите потребители и мрежовите приложения се увеличава и честотната лента на мрежата също се увеличава, TCP/IP протоколът вероятно ще претърпи значителни модификации, особено след като все повече клиенти използват интернет телевизия, гласови технологии на IP мрежи и мултимедия
· Трябва да се отбележи, че с развитието на протокола TCP/IP някои от неговите компоненти са станали по-съвместими с референтния модел на OSI.
1. TCP протокол от семейството TCP/IP
TCP е един от най-широко използваните протоколи на транспортния слой. IP е без връзка. Той просто предава дейтаграмата от възел на възел и ако възникне някакво нарушение, тя просто се отхвърля и подателят се уведомява за това чрез ICMP съобщение. Отговорност на TCP е да проверява получените данни и да препредава данни, които не достигат до получателя. Той следи доставката на данни по IP протокола.
Основната функция на TCP е да доставя съобщения без загуба. За да направите това, първо се установява връзка между изпращащото приложение и получаващото приложение, осигурявайки надеждна доставка на дейтаграми. TCP е този, който препредава повреден или изгубен пакет.
TCP регулира прехвърлянето на данни от приложния слой към мрежовия слой и обратно. TCP трябва да отговаря за поддържането на приоритетите и защитата на данните, за прекратяването на приложението на по-високо ниво, което чака дейтаграма, и за обработката на грешки на по-ниските нива. за поддържане на таблици на състоянието за всички потоци както в самия TCP, така и на други нива. Разделянето на всички тези функции в отделен слой освобождава разработчиците на приложения от решаването на проблемите с контрола на потока и осигуряването на надеждността на трансфера на данни. Без TCP функциите, изброени по-горе, ще трябва да бъдат внедрени във всяка приложна програма.
TCP е ориентиран към свързване протокол, осигуряващ предаване от край до край на данни от изпращаща машина към получаваща машина. Тъй като използва връзка, получателят, който получава дейтаграмата, трябва да уведоми подателя за това. Терминът виртуален канал обикновено се използва, за да посочи, че изпращащата машина и получаващата машина обменят съобщения, повечето от които са потвърждения за получаване или кодове за грешка.
TCP получава поток от байтове и го сглобява в пакети, наричани още сегменти, като добавя заглавки към началото на сегментите. Заглавката съдържа контролната сума и поредния номер на пакета с данни. Дължината на сегмента обикновено се определя от TCP или се избира от системния администратор. (В повечето случаи дължините на TCP сегментите и дължините на IP дейтаграмите нямат нищо общо помежду си.)
Процесът на установяване на връзка започва с предаване на заявка за връзка от изпращащата машина към получаващата машина. Заявката съдържа номер, наречен номер на сокет. В отговор получаващото приложение изпраща своя номер на сокет. Номерата на гнездата на изпращача и получателя уникално идентифицират връзката между приложенията.
След като връзката е установена, TCP започва да предава сегменти от съобщения към IP модула, който преобразува всеки от тях в една или повече дейтаграми. Тези операции се извършват без участие на TCP. След като преминат през мрежата от изпращащата машина до получаващата машина, дейтаграмите пристигат в IP слоя на последната. Той събира изпратения сегмент от тях и го предава на TCP. На свой ред съобщението от TCP достига до приложението получател чрез използвания протокол на приложния слой.
Ако едно съобщение се състои от няколко TCP сегмента (да не се бърка с IP дейтаграми), TCP на получаващата машина го сглобява въз основа на последователните номера на сегменти, съхранени в заглавката. Ако даден сегмент е изгубен или повреден (открит от контролна сума в заглавката на сегмента), до подателя се изпраща съобщение, съдържащо поредния номер на грешния или изгубен сегмент. В този случай изпращачът препредава сегмента.
Ако съобщението се състои само от един TCP сегмент, тогава след сравняване на получените и изчислените контролни суми TCP софтуерът на получаващата машина изпраща потвърждение за получаване (ACK) на подателя. Издаването на разписка в отговор на получен сегмент се нарича потвърждение.
Както при повечето протоколи, ориентирани към свързване, таймерите играят важна роля в TCP. Съобщението се счита за непълно, ако разписката не е получена в посочения период на изчакване. Това намалява времето за изчакване на потвърждение в случай на загуба на данни. В този случай съответните сегменти обикновено се препредават.
TCP не предоставя потвърждение, ако сегмент пристигне неправилно образуван. Загубата на сегмент се открива с помощта на таймер за повторно предаване: ако разписката за сегмент не е получена навреме, той се счита за изгубен и се предава повторно.
Използването на таймери обаче създава редица проблеми. Съгласно TCP протокола, разписка за получен сегмент се издава само след получаване на всички изпратени преди това сегменти от същото съобщение. С други думи, разписката потвърждава получаването на всички изпратени преди това сегменти на съобщението. Тъй като сегментите се доставят на получаващата машина в произволен ред, издаването на разписка може да се забави, докато не бъде получено цялото съобщение, което от своя страна може да доведе до повторно предаване на правилно получени сегменти.
Повторно доставените копия на сегменти, изпратени, тъй като времето за изчакване на получаването е изтекло, се отхвърлят от софтуера на получаващата машина. В този случай не се изпраща известие до подателя, тъй като за него е важно само да знае, че сегментът е получен.
В изпращащата машина данните, получени от TCP софтуера от приложния слой, се натрупват в буфер. Моментът, в който те се пакетират в сегмент, обикновено се определя на ниво TCP. Данните от буфера могат също да бъдат изпратени спешно по искане на обслужвания процес на приложния слой. Тази операция се нарича бутане. Използването му се дължи на задаване на специален флаг в заглавката на протокола на приложния слой.
2. Портове и гнезда
Приложение, използващо TCP (или UDP), се идентифицира уникално с номер, наречен номер на порт. По принцип номерата на портове могат да бъдат избрани произволно, но за да се улесни оперативната съвместимост между различни реализации на TCP софтуер, са приети конвенции за номера на портове, присвоени на конкретни услуги.
Обикновено портове между 0 и 255 се разпределят за системни процеси, а портове над 255 се разпределят за потребителски процеси. В Интернет разпределянето на портове се управлява от Органа за присвоени номера в Интернет (IANA). Списък с номера на портове за интернет услуги може да бъде намерен в съответното оперативно предложение (RFC). Извадки от него са дадени в таблицата. Портове 0 и 255 са запазени.
Всеки комуникационен канал в TCP слоя се идентифицира уникално с две числа, тази комбинация се нарича сокет. Сокетът се определя от IP адреса на машината и номера на порта, използван от TCP софтуера. При връзка всяка машина се идентифицира уникално чрез IP адрес и всеки работещ процес се идентифицира чрез порт, така че връзката между два / процеса се идентифицира уникално чрез сокет.
3. TCP таймери
Необходими са таймери, за да се избегнат прекомерни забавяния и състояния на изчакване. Те улесняват заобикалянето на някои от клопките при прехвърляне на данни. Ролята на различните таймери, използвани от TCP при предаване на данни, се обсъжда в следващите раздели.
Таймер за препредаване. Таймерът за повторно предаване измерва времето за изчакване за разписка за изпратен сегмент (таймаут за повторно предаване, RTO). Този параметър се задава въз основа на типа мрежа и скоростта на доставка на съобщенията. Ако разписката не пристигне навреме, сегментът се изпраща отново и периодът на повторно предаване се увеличава експоненциално. Това се повтаря няколко пъти, докато периодът на повторно предаване достигне определен лимит, след което се издава съобщение за грешка към обслужвания процес.
Първоначалното време за изчакване на разписка се задава чрез измерване на времето между изпращането на сегмент и получаването на разписка за него. Тази стойност се нарича време за двойно преминаване. Очакваната стойност (т.е. средната) на измерените стойности се нарича изгладено време на двойно преминаване. Изчислява се с помощта на формула и може да бъде увеличена, за да отчете неочаквани закъснения.
Таймер за забавяне. Получателят може да получава сегменти дори след прекратяване на връзката. Тихият таймер предотвратява повторното отваряне на новозатворени портове от пристигащи сегменти. Продължителността на забавянето обикновено се задава на два пъти максималния живот на сегмента (това е същото като стойността на полето за живот в заглавката на IP дейтаграмата). Забавянето може да бъде до 30 секунди. В отговор на всеки сегмент, пристигащ през този период, се изпраща съобщение за грешка.
Таймер за заявка. Таймерът за постоянство е предвиден за доста редкия случай, когато получател, след като е спрял предаването на данни чрез изпращане на сегмент с размер на прозореца нула, изпраща съобщение до своя партньор да възобнови работата, но той не го получава. За да продължи предаването, изпращачът изпраща заявки с един байт данни на период от време. В отговор на тях той получава сегменти, където е посочен размерът на прозореца. Ако размерът на прозореца е нула, дестинацията все още е заета, а ако не, тогава е готова да получи полезна информация, след което предаването на данни се възобновява. Периодът на повторение на заявката се определя от таймера на заявката.
Таймер за наблюдение и таймер за изключване. Тези таймери са предназначени да проверяват връзката. Таймерът за поддържане кара сегментите да се издават периодично без поле за данни, а таймерът за неактивност указва максималното време за изчакване на отговор. След този период връзката се счита за прекратена.
Обикновено периодът на таймера за наблюдение се задава на приложния слой, стойностите му са между 5 и 45 секунди. Максималното време на изчакване обикновено е 360 секунди.
4. TCP сегменти от данни
TCP комуникира с основния слой чрез IP протокола и с приложния слой по-горе, използвайки сервизни примитиви. Освен това трябва да комуникира с TCP софтуер на други машини. За последната задача се използват протоколни блокове данни, които на TCP език се наричат сегменти. Заглавката на сегмента се състои от следните полета:
Изходен порт, 16-битово поле, което идентифицира локалния изходен порт (обикновено потребителски процес на приложен слой).
Дестинационен порт, 16-битово поле, указващо номера на дестинационния порт
Сегментна позиция (пореден номер). Полето съдържа поредния номер j на първия байт сегментни данни в съобщението.
Очаква се първият байт (номер на потвърждение). 1 се използва, когато сегментът служи като разписка (ACK флаг = 1). Съдържа последователността/поредния номер на първия очакван байт. Всички байтове на съобщения с по-ниски поредни номера се считат за потвърдени.
Отместване на данни. Дължината на заглавието, измерена в 32 думи. Служи като указател към началото на полето с данни.
Запазено. Все още не се използва и трябва да се нулира. Размерът на полето е 6 бита.
Знамена. В състояние 1 те означават следното.
Флаг на URG. Полето за спешност на данните подлежи на обработка. ACK флаг. Сегментът служи като разписка.
PSH флаг. Сегментът трябва да бъде "натиснат" - изпратен първи.
RST флаг. Сегментът служи като заявка за задаване на първоначалните параметри на връзката.
SYN флаг. Сегментът служи за синхронизиране на броячите на предадени данни при установяване на връзка.
FIN флаг. Показва, че последният байт от съобщението е изпратен. ASCII еквивалентът на маркера за край на предаването (EOT).
Размер на прозореца. Показва колко байта е готов да приеме получателят.
Контролна сума, 16-битова контролна сума, дефинирана за блок от данни, състоящ се от псевдозаглавие и самия сегмент, 96-битово псевдозаглавие, предхожда TCP заглавката и се създава в процедурата за изчисляване на контролната сума. Псевдозаглавието съдържа IP адреса на подателя, IP адреса на получателя, идентификатора на протокола и дължината на сегмента. Тези параметри се предават на IP при изпращане на сегмента и се използват от IP протокола при получаването му. Процедурата за изчисляване на контролната сума отнема доста време.
Спешен указател. Използва се, когато флаг URG=1. Представлява отместването спрямо поредния номер в заглавката. Специалната обработка на спешни данни се извършва на приложния слой, а не на TCP слоя.
Настроики. Подобно на полето със същото име в IP хедъра, всяка опция съдържа собствен номер (един байт), дължина в байтове и стойност. В момента има само три опции:
O - Край на списъка с опции;
1 - Без операции;
2 - Максимален размер на сегмента.
Подложка. Разширява заглавката до цял брой 32-битови думи.
Заглавката е последвана от поле с данни, чиято дължина не е фиксирана. С опцията за максимален размер на сегмент TCP софтуерът на получателя може да избере подходящ размер на буфера за данни.
5. TCP връзка
Комуникацията през TCP протокола се управлява от множество правила. Процедурите за установяване на връзка, предаване на полезна информация и прекъсване на връзката обикновено се представят от крайни автомати. (TCP е управляван от състоянието протокол и следователно неговите операции зависят от състоянията на флагове или подобни структури.) Вместо това ще използвам прости схеми за взаимодействие.
Има две възможности за установяване на връзки: действително свързване и приемане на връзка. Преди да започнете връзката, трябва да инициализирате и стартирате WSA - Windows Socket Architecture. Нека изпълним функцията за това
1. WSAStartup(wVersionRequested, lpWSAData): Цяло число;
Където:
wVersionRequested - номерът на необходимата версия за стартиране на приложението. В нашия случай този параметър трябва да бъде равен на $0101.
lpWSAData - структура, в която WSA конекторът връща: номер на версията, описание, статус, максимален брой гнезда на конектора, информация за разработчици и т.н. Тази структура няма значение за нас.
Кодът за грешка, възникнал в случай на неуспешно изпълнение на която и да е функция, свързана с конектори на гнездо, може да бъде получен с помощта на функцията WSAGetLastError. Дешифрирането на тези кодове е във файла sock.hlp, включен в дистрибуцията на Delphi.
Възможност за свързване
Преди да свържете съединители, гнезда, трябва да създадете функция за гнездо на конектора
2. Сокет (af, тип, протокол) : цяло число;
Където:
af е семейство от адреси, в нашия случай af:= PF_INET.
type - тип на сокет конектора (SOCK_STREAM, базиран на фамилията TCP адреси и ориентиран към връзки, и SOCK_DGRAM, базиран на фамилията UDP адреси и работещ без връзки (ние използваме SOCK_STREAM, защото е по-надежден)).
протокол - параметър, който определя някои характеристики на протокола, в нашия случай - 0.
След изпълнение функцията връща стойност Integer, която е указател към новия сокет. След това трябва да зададете опциите на структурата TSockAddrIn, която съдържа информация за връзката. Тази структура има много полета, но ние се интересуваме само от три от тях:
sin_family - съдържа името на семейството на адресите. Тази опция е подобна на af.
sin_port - номер на адрес на порта, през който се осъществява комуникацията с конектора на гнездото. Адресът на порта трябва да е по-голям от 1024, тъй като по-малките стойности са запазени за съществуващи приложения. Номерът на порта трябва да бъде посочен в така наречения мрежов формат, когато високите байтове отиват към ниските адреси. Това се различава от съхранението, прието в x86 (Intel) архитектурата, така че е необходимо да се преобразува с помощта на функцията htons() от формата на тази архитектура към мрежовия (htons означава Host To Network, Short (т.е. 16-битов) )). Обратният превод може да се извърши с помощта на функцията ntohs().
sin_addr - това поле има подполе s_addr: integer, на което трябва да присвоим стойността на функцията inet_addr(iAddr). Тази функция преобразува низов IP адрес в 4-байтово число, т.е. iAddr е адресът на компютъра, с който искаме да се свържем. Можете да получите адреса, като изпълните командата NETSTAT -r на компютъра, който търсите. Адресът също трябва да бъде в мрежов формат, но функцията inet_addr() вече връща резултат в мрежов формат и в този случай не е необходимо преобразуване. Ако това трябва да се направи, тогава могат да се използват функциите htonl() и ntohl(). Забележка: Когато предавате данни в двоичен формат по мрежа, имайте предвид различното тълкуване на реда на байтовете на думите при различните архитектури и преобразувайте данните в мрежовия формат.
Сега, след като попълнихме адресната структура, изпълняваме функцията
3. Connect(Sock, SA, SASize): Цяло число;
Където:
SASize - SA размер.
Ако в резултат на изпълнението на Connect се върне SOCKET_ERROR, тогава функцията е изпълнена неправилно (вижте примера) В противен случай се връща 0.
След като установите връзка, можете да използвате функции за получаване и изпращане на данни, като recv, send.
Функцията за свързване чрез API изпраща съобщение до драйвера на TCP протокола, който от своя страна изпраща инициализиращ пакет до целевия компютър чрез протоколи от по-ниско ниво за установяване на връзка. Функцията приключва при установяване на връзката.
4. Recv(Sock, Buf, BufSize, Flags) : Цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
Buf - буферът, където ще отидат получените данни.
BufSize - размер на буфера.
Знамена - знамена. Може да бъде MSG_PEEK или MSG_OOB. Нека зададем това поле на 0.
5. Send(Sock, Buf, BufSize, Flags) : Цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
Buf - буфер на изпратените данни.
BufSize - размер на буфера.
Знамена - знамена. Равно на 0.
Ако не е възникнала грешка, се връща броят на получените байтове; ако връзката е затворена правилно, 0; в противен случай, ако връзката е затворена, се връща отрицателно число.
За да прекратите връзката, използвайте функцията
6. CloseSocket(Sock) : Цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
Опция „Приемане на връзка“
Друг вариант за установяване на връзка е да я приемете. Най-общо казано, във всяка връзка трябва да има и двете възможности - свързване и получаване на връзка (единият компютър е сървър, той извършва приемането, другият е клиент, той инициира приемането). Процедурата за инициализиране на сървъра е същата като за клиента, с тази разлика, че:
Вместо адреса на друг компютър, ние въвеждаме нашия адрес или „0.0.0.0“ в структурата TSockAddrIn, за да приемем всички входящи връзки.
вместо Connect "a ние изпълняваме функциите:
7. Bind(Sock, SA, SASize) : цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
SA е структурата TSockAddrIn, която попълнихме.
SASize - неговият размер.
Ако не са възникнали грешки, се връща 0, в противен случай SOCKET_ERROR.
Тази функция обвързва нашия конектор за гнездо към посочения от нас адрес.
8. Listen(Sock, Backlog) : Integer;
Където:
Sock е резултат от изпълнение на функцията Socket.
Backlog - максималният размер на опашката от чакащи връзки.
Ако не са възникнали грешки, се връща 0, в противен случай SOCKET_ERROR.
Тази функция настройва конектора на гнездото в режим на слушане на канала.
9. Accept(Sock, SA, SASize) : цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
SA е структурата TSockAddrIn, която попълнихме.
SASize - SA размер.
Ако в резултат на изпълнението на Accept се върне SOCKET_ERROR, тогава функцията е изпълнена неправилно (вижте примера) В противен случай се връща 0.
След като установите връзка, можете да използвате функции за получаване и изпращане на данни, като recv, send. Функцията приключва при установяване на връзката.
След свързване
След като се свържете, можете да започнете да обменяте информация, като използвате горните функции за приемане и изпращане. Можете също така да добавите, че конекторите за гнезда се класифицират като заключващи и незаключващи. Първите чакат края на операцията, вторите не чакат.
За да настроите конекторите на гнездата в неблокиращо състояние, използвайте функцията:
ioctlsocket(Sock, CMD, Value) : Цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
CMD е команда за управление на конектор за гнездо (в нашия пример това е константата FIONBIO).
Стойност - нейната стойност 0 - включено, 1 - изключено.
Ако не са възникнали грешки, се връща 0, в противен случай SOCKET_ERROR.
Когато работите директно със сокет конектори, не винаги ще получавате в получателя точно броя байтове, които сте изпратили, и след известно време трябва да „четете“ байтовете от сокет конектора. Това се обяснява с принципа на организиране на стрийминг сокети, които в този случай се възприемат като файлове. Възможно е обаче да деактивирате алгоритъма NAGLE, който контролира разделянето на съобщения в дейтаграми, като използвате следната функция:
setsockopt(Sock, Level, Parameter, PChar(Value), ValueSize) : Цяло число;
Където:
Sock е резултат от изпълнение на функцията Socket.
Ниво - отборно ниво.
Параметърът е команда за управление на конектор със сокет (в нашия пример константата TCP_NODELAY).
Стойност - неговата стойност (0 - включено, 1 - изключено).
ValueSize - размер на стойността.
Ако не са възникнали грешки, се връща 0, в противен случай SOCKET_ERROR.
Можете да определите адреса на кореспондента от структурата TSockAddrIn след изпълнение на командата accept (вижте по-горе) или като използвате функцията getpeername (вижте Delphi sock.hlp).
Можете да определите името на компютъра по адрес с помощта на функцията GetHostByAddr (вижте Delphi sock.hlp).
В съвременния свят информацията се разпространява за секунди. Новината току-що се появи, а секунда по-късно вече е достъпна в някой сайт в интернет. Интернет се смята за едно от най-полезните развития на човешкия ум. За да се насладите на всички предимства, които интернет предоставя, трябва да се свържете с тази мрежа.
Малко хора знаят, че простият процес на посещение на уеб страници включва сложна система от действия, невидими за потребителя. Всяко щракване върху връзка активира стотици различни изчислителни операции в сърцето на компютъра. Те включват изпращане на заявки, получаване на отговори и много други. Така наречените TCP/IP протоколи са отговорни за всяко действие в мрежата. Какво са те?
Всеки интернет протокол TCP/IP работи на собствено ниво. С други думи, всеки прави своето. Цялото семейство TCP/IP протоколи вършат огромно количество работа едновременно. И потребителят в този момент вижда само ярки снимки и дълги редове текст.
Концепцията за протоколен стек
Протоколният стек TCP/IP е организиран набор от основни мрежови протоколи, който е йерархично разделен на четири нива и представлява система за транспортно разпространение на пакети в компютърна мрежа.
TCP/IP е най-известният стек от мрежови протоколи, който се използва днес. Принципите на TCP/IP стека се прилагат както за локални, така и за широкообхватни мрежи.
Принципи на използване на адреси в стека на протокола
Стекът на мрежовия протокол TCP/IP описва пътищата и посоките, в които се изпращат пакетите. Това е основната задача на целия стек, изпълнявана на четири нива, които взаимодействат помежду си с помощта на регистриран алгоритъм. За да се гарантира, че пакетът е изпратен правилно и доставен точно до точката, която го е поискала, беше въведено и стандартизирано IP адресиране. Това се дължи на следните задачи:
- Адресите от различни типове трябва да са последователни.Например преобразуване на домейн на уебсайт в IP адрес на сървър и обратно или преобразуване на име на хост в адрес и обратно. По този начин достъпът до точката става възможен не само чрез IP адреса, но и чрез нейното интуитивно име.
- Адресите трябва да са уникални.Това е така, защото в някои специални случаи пакетът трябва да достигне само една конкретна точка.
- Необходимостта от конфигуриране на локални мрежи.
В малки мрежи, където се използват няколко десетки възли, всички тези задачи се изпълняват просто, като се използват най-простите решения: съставяне на таблица, описваща собствеността на машината и съответния й IP адрес, или можете ръчно да разпределите IP адреси към всички мрежови адаптери. Въпреки това, за големи мрежи с хиляда или две хиляди машини задачата за ръчно издаване на адреси не изглежда толкова осъществима.
Ето защо беше изобретен специален подход за TCP / IP мрежи, който се превърна в отличителна черта на протоколния стек. Беше въведена концепцията за мащабируемост.
Слоеве на протоколния стек TCP/IP
Тук има определена йерархия. TCP/IP протоколният стек има четири слоя, всеки от които обработва свой собствен набор от протоколи:
Приложен слой: създаден, за да позволи на потребителя да взаимодейства с мрежата. На това ниво се обработва всичко, което потребителят вижда и прави. Слоят позволява на потребителя достъп до различни мрежови услуги, например: достъп до бази данни, възможност за четене на списък с файлове и отварянето им, изпращане на имейл съобщение или отваряне на уеб страница. Заедно с потребителските данни и действия, на това ниво се предава информация за услугата.
Транспортен слой:Това е чист механизъм за предаване на пакети. На това ниво няма никакво значение нито съдържанието на пакета, нито принадлежността му към някакво действие. На това ниво има значение само адресът на възела, от който е изпратен пакетът, и адресът на възела, до който трябва да бъде доставен пакетът. По правило размерът на фрагментите, предавани с помощта на различни протоколи, може да се променя, следователно на това ниво блоковете информация могат да бъдат разделени на изхода и сглобени в едно цяло на местоназначението. Това причинява възможна загуба на данни, ако по време на предаване на следващия фрагмент възникне краткотрайно прекъсване на връзката.
Транспортният слой включва много протоколи, които са разделени на класове, от най-простите, които просто предават данни, до сложните, които са оборудвани с функционалност за потвърждение на получаването или повторна заявка на липсващ блок от данни.
Това ниво осигурява по-високото (приложно) ниво с два вида услуги:
- Осигурява гарантирана доставка чрез TCP протокола.
- Доставя чрез UDP, когато е възможно .
За гарантиране на доставката се установява връзка по TCP протокола, който позволява пакетите да бъдат номерирани на изхода и потвърдени на входа. Номерирането на пакетите и потвърждението за получаване е така наречената служебна информация. Този протокол поддържа предаване в режим "Дуплекс". Освен това, благодарение на добре обмислените разпоредби на протокола, той се счита за много надежден.
UDP протоколът е предназначен за моменти, когато е невъзможно да конфигурирате предаване чрез TCP протокола или трябва да спестите в сегмента за мрежово предаване на данни. Също така UDP протоколът може да взаимодейства с протоколи от по-високо ниво, за да увеличи надеждността на предаването на пакети.
Мрежов слой или "интернет слой":базовия слой за целия TCP/IP модел. Основната функционалност на този слой е идентична с едноименния слой в OSI модела и описва движението на пакети в съставна мрежа, състояща се от няколко по-малки подмрежи. Той свързва съседни слоеве на TCP/IP протокола.
Мрежовият слой е свързващият слой между по-високия транспортен слой и по-ниското ниво на мрежовите интерфейси. Мрежовият слой използва протоколи, които получават заявка от транспортния слой и чрез регулирано адресиране предават обработената заявка към протокола на мрежовия интерфейс, като посочват на кой адрес да се изпратят данните.
На това ниво се използват следните TCP/IP мрежови протоколи: ICMP, IP, RIP, OSPF. Основният и най-популярен на ниво мрежа е, разбира се, IP (Интернет протокол). Основната му задача е да предава пакети от един рутер към друг, докато единица данни достигне мрежовия интерфейс на целевия възел. IP протоколът се внедрява не само на хостове, но и на мрежово оборудване: рутери и управлявани комутатори. IP протоколът работи на принципа на най-доброто усилие, негарантирана доставка. Тоест, няма нужда да установявате връзка предварително, за да изпратите пакет. Тази опция води до спестяване на трафик и време за движение на ненужни сервизни пакети. Пакетът се насочва към местоназначението си и е възможно възелът да остане недостъпен. В този случай се връща съобщение за грешка.
Ниво на мрежов интерфейс:е отговорен за гарантирането, че подмрежите с различни технологии могат да взаимодействат помежду си и да предават информация в един и същи режим. Това се постига в две прости стъпки:
- Кодиране на пакет в междинна мрежова единица данни.
- Преобразува информацията за местоназначението в необходимите стандарти на подмрежата и изпраща единицата данни.
Този подход ни позволява постоянно да разширяваме броя на поддържаните мрежови технологии. Веднага щом се появи нова технология, тя незабавно попада в TCP/IP протоколния стек и позволява на мрежи с по-стари технологии да прехвърлят данни към мрежи, изградени с помощта на по-модерни стандарти и методи.
Прехвърлени единици данни
По време на съществуването на такова явление като TCP/IP протоколите бяха установени стандартни термини за единиците предавани данни. Данните по време на предаване могат да бъдат фрагментирани по различни начини в зависимост от технологиите, използвани от целевата мрежа.
За да имате представа какво се случва с данните и в кой момент от време, беше необходимо да излезете със следната терминология:
- Поток от данни- данни, които пристигат на транспортния слой от протоколи на по-висок приложен слой.
- Сегментът е фрагмент от данни, на който потокът е разделен според стандартите на TCP протокола.
- Дейтаграма(особено неграмотните хора го произнасят като „Дейтаграма“) - единици данни, които се получават чрез разделяне на поток с помощта на протоколи без връзка (UDP).
- Найлонов плик- единица данни, генерирана чрез IP протокола.
- TCP/IP протоколите пакетират IP пакети в блокове от данни, предавани през съставни мрежи, т.нар. персоналили рамки.
Видове стекови адреси на TCP/IP протоколи
Всеки TCP/IP протокол за пренос на данни използва един от следните типове адреси за идентифициране на хостове:
- Локални (хардуерни) адреси.
- Мрежови адреси (IP адреси).
- Имена на домейни.
Локални адреси (MAC адреси) - използвани в повечето технологии за локална мрежа за идентифициране на мрежови интерфейси. Когато говорим за TCP/IP, думата локален означава интерфейс, който работи не в съставна мрежа, а в отделна подмрежа. Например подмрежата на интерфейс, свързан с интернет, ще бъде локална, а интернет мрежата ще бъде съставна. Локална мрежа може да бъде изградена на всяка технология и независимо от това, от гледна точка на комбинирана мрежа, машина, разположена в отделна специална подмрежа, ще се нарича локална. По този начин, когато пакет влезе в локалната мрежа, неговият IP адрес след това се свързва с локалния адрес и пакетът се изпраща до MAC адреса на мрежовия интерфейс.
Мрежови адреси (IP адреси). Технологията TCP/IP предоставя собствено глобално адресиране на възли за решаване на прост проблем - комбиниране на мрежи с различни технологии в една голяма структура за предаване на данни. IP адресирането е напълно независимо от технологията, използвана в локалната мрежа, но IP адресът позволява на мрежов интерфейс да представлява машина в съставна мрежа.
В резултат на това беше разработена система, в която на хостовете се присвояват IP адрес и подмрежова маска. Подмрежовата маска показва колко бита са разпределени за номера на мрежата и колко за номера на хоста. IP адресът се състои от 32 бита, разделени на блокове от по 8 бита.
Когато се предава пакет, му се присвоява информация за номера на мрежата и номера на възела, към който трябва да бъде изпратен пакетът. Първо рутерът препраща пакета към желаната подмрежа и след това се избира хост, който го чака. Този процес се извършва от протокола за разрешаване на адреси (ARP).
Домейн адресите в TCP/IP мрежите се управляват от специално проектирана система за имена на домейни (DNS). За да направите това, има сървъри, които свързват името на домейна, представено като низ от текст, с IP адреса и изпращат пакета в съответствие с глобалното адресиране. Няма съответствие между име на компютър и IP адрес, така че за да преобразува име на домейн в IP адрес, изпращащото устройство трябва да има достъп до таблицата за маршрутизиране, която е създадена на DNS сървъра. Например, записваме адреса на сайта в браузъра, DNS сървърът го свързва с IP адреса на сървъра, на който се намира сайтът, и браузърът чете информацията, получавайки отговор.
В допълнение към Интернет е възможно да се издават имена на домейни на компютри. По този начин процесът на работа в локална мрежа е опростен. Няма нужда да запомняте всички IP адреси. Вместо това можете да дадете произволно име на всеки компютър и да го използвате.
IP адрес. формат. Компоненти. Подмрежова маска
IP адресът е 32-битово число, което в традиционното представяне се записва като числа от 1 до 255, разделени с точки.
Тип IP адрес в различни формати на запис:
- Десетичен IP адрес: 192.168.0.10.
- Двоична форма на същия IP адрес: 11000000.10101000.00000000.00001010.
- Въвеждане на адреса в шестнадесетична бройна система: C0.A8.00.0A.
Няма разделител между идентификатора на мрежата и номера на точката в записа, но компютърът може да ги раздели. Има три начина да направите това:
- Фиксирана граница.С този метод целият адрес се разделя условно на две части с фиксирана дължина, байт по байт. Така, ако дадем един байт за номера на мрежата, тогава ще получим 2 8 мрежи от 2 24 възела всяка. Ако границата се премести с още един байт вдясно, тогава ще има повече мрежи - 2 16 и по-малко възли - 2 16. Днес подходът се счита за остарял и не се използва.
- Подмрежова маска.Маската е свързана с IP адрес. Маската има последователност от стойности "1" в тези битове, които са разпределени към номера на мрежата, и определен брой нули в тези места на IP адреса, които са разпределени към номера на възела. Границата между единици и нули в маската е границата между идентификатора на мрежата и идентификатора на хоста в IP адреса.
- Метод на адресните класове.Компромисен метод. Когато се използва, размерите на мрежата не могат да бъдат избрани от потребителя, но има пет класа - A, B, C, D, E. Три класа - A, B и C - са предназначени за различни мрежи, а D и E са запазени за мрежи със специално предназначение. В система от класове всеки клас има своя собствена граница на номер на мрежа и ID на възел.
Класове IP адреси
ДА СЕ клас АТе включват мрежи, в които мрежата се идентифицира с първия байт, а останалите три са номера на възела. Всички IP адреси, които имат стойност на първи байт от 1 до 126 в техния диапазон, са мрежи от клас A. Има много малко мрежи от клас A като количество, но всяка от тях може да има до 2 24 точки.
клас Б- мрежи, в които двата най-високи бита са равни на 10. В тях за номера на мрежата и идентификатора на точката се отделят 16 бита. В резултат на това се оказва, че броят на мрежите от клас B е количествено различен от броя на мрежите от клас A, но те имат по-малък брой възли - до 65 536 (2 16) единици.
В мрежите клас C- има много малко възли - 2 8 във всеки, но броят на мрежите е огромен, поради факта, че мрежовият идентификатор в такива структури заема три байта.
мрежи клас D- вече принадлежат към специални мрежи. Започва с последователност 1110 и се нарича мултикаст адрес. Интерфейси с адреси от клас A, B и C могат да бъдат част от група и да получават, в допълнение към индивидуалния адрес, групов адрес.
Адреси клас Е- в резерв за бъдещето. Такива адреси започват с последователността 11110. Най-вероятно тези адреси ще се използват като групови адреси, когато има недостиг на IP адреси в глобалната мрежа.
Настройка на TCP/IP протокола
Настройката на TCP/IP протокола е достъпна за всички операционни системи. Това са Linux, CentOS, Mac OS X, Free BSD, Windows 7. TCP/IP протоколът изисква само мрежов адаптер. Разбира се, сървърните операционни системи са способни на повече. TCP/IP протоколът е много широко конфигуриран с помощта на сървърни услуги. IP адресите на обикновените настолни компютри се задават в настройките за мрежова връзка. Там конфигурирате мрежовия адрес, шлюза - IP адреса на точката, която има достъп до глобалната мрежа, и адресите на точките, където се намира DNS сървъра.
TCP/IP Интернет протоколът може да се конфигурира ръчно. Въпреки че това не винаги е необходимо. Можете автоматично да получавате параметри на TCP/IP протокола от динамичния адрес за разпространение на сървъра. Този метод се използва в големи корпоративни мрежи. На DHCP сървър можете да картографирате локален адрес към мрежов адрес и щом машина с даден IP адрес се появи в мрежата, сървърът незабавно ще й даде предварително подготвен IP адрес. Този процес се нарича резервация.
TCP/IP протокол за разрешаване на адреси
Единственият начин да се установи връзка между MAC адрес и IP адрес е чрез поддържане на таблица. Ако има таблица за маршрутизиране, всеки мрежов интерфейс знае своите адреси (локални и мрежови), но възниква въпросът как правилно да се организира обменът на пакети между възлите, използвайки протокола TCP/IP 4.
Защо е изобретен протоколът за разрешаване на адреси (ARP)? За да свържете фамилията TCP/IP протоколи и други системи за адресиране. Таблица за ARP съпоставяне се създава на всеки възел и се попълва чрез запитване на цялата мрежа. Това се случва при всяко изключване на компютъра.
ARP таблица
Ето как изглежда пример за компилирана ARP таблица.
команда netstat -стр protocol показва статистика за посочения протокол (udp, tcp, sctp, ip, icmp), който може да бъде посочен или по име, или по псевдоним.
Някои имена и псевдоними на протоколи са изброени във файла /etc/protocols. Празен отчет означава, че няма информация за посочения протокол. Ако функцията за събиране на статистика не е инсталирана за посочения протокол, се показва съобщение, че е зададен неизвестен протокол.
По-долу е даден пример за команден изход за ip протокола: # netstat -p ip ip: 45775 получени пакета 0 с грешки в контролната сума на заглавието 0 с размер по-малък от минималния 0 с размер на данните< длины данных 0 с длиной заголовка < размера данных 0 с длиной данных < длины заголовка 0 с неправильными параметрами 0 с неправильным номером версии 0 фрагментов получено 0 фрагментов отброшено (повтор или нехватка памяти) 0 фрагментов отброшено после истечения тайм-аута 0 пакетов успешно пересобрано 45721 пакет для данного хоста 51 пакет неизвестных/не поддерживаемых протоколов 0 пакетов переслано 4 пакета не удалось переслать 0 перенаправлений 33877 пакетов отправлено с данного узла 0 пакетов отправлено с искусственным заголовком ip 0 исходящих пакетов отброшено из-за отсутствия буферов и пр. 0 исходящих пакетов отброшено из-за отсутствия маршрута 0 дейтаграмм вывода фрагментировано 0 фрагментов создано 0 дейтаграмм не удалось разбить на фрагменты 0 многоцелевых пакетов IP отброшено из-за отсутствия получателя 0 успешных циклов поиска путей MTU 1 повторная попытка цикла поиска путей MTU 3 оценки поиска путей MTU без ответа 3 оценки поиска путей MTU с ответом 1 снижение количества операций поиска путей MTU 8 пакетов поиска путей MTU отправлено 0 сбоев выделения путей поиска путей MTU 0 переполнений ipintrq 0 с неверным источником 0 пакетов обработано нитями 0 пакетов отброшено нитями 0 пакетов отброшено по причине переполнения буфера входящих пакетов сокета 0 пакетов обнаружения сбоев в работе шлюза отправлено 0 ошибок выделения пакетов функции обнаружения сбоев в работе шлюза 0 ошибок выделения шлюзов функции обнаружения сбоев в работе шлюза
- Получени пакети
Общият брой получени IP дейтаграми.
- Невалидни контролни суми на заглавка или отхвърлени фрагменти
Ако стойността в полето за лоша контролна сума на заглавката или фрагментите е отхвърлена поради повторно възпроизвеждане или липса на памет е различна от нула, тогава или пакетите са повредени, докато се предават по мрежата, или размерът на опашката за получаване на драйвера на устройството е недостатъчен.
- Получени фрагменти
Общият брой на получените фрагменти.
- Отпадна поради изчакване
Ненулев брой отхвърлени фрагменти поради изтичане на времето означава, че поради голямо претоварване на мрежата TTL броячът на ip фрагменти достига нула, преди да бъдат получени всички фрагменти от дейтаграма. За да коригирате тази грешка, увеличете стойността на параметъра ipfragttlизползвайки командата no. Друга възможна причина е липсата на свободни буфери. В този случай трябва да увеличите стойността стената.
- Пакети, изпратени от този хост
Броят IP дейтаграми, създадени и изпратени от локалната система. Този брояч не отчита препратени (транзитни) дейтаграми.
- Създадени фрагменти
Броят на фрагментите, създадени в локалната система, когато се изпращат дейтаграми.
Когато преглеждате статистиката на IP протокола, обърнете внимание на съотношението на броя на получените пакети към броя на получените фрагменти. В мрежи с малък MTU не трябва да се фрагментират повече от 10 процента от пакетите. Големият брой фрагменти означава, че протоколите от по-високо ниво на отдалечени хостове предават данни в блокове, по-големи от размера на интерфейса MTU. Освен това пакетите могат да бъдат фрагментирани от рутери и шлюзове. Същото важи и за съотношението на броя на изпратените пакети към броя на създадените фрагменти.
Фрагментирането увеличава натоварването на процесора, така че е важно да се определи причината. Моля, имайте предвид, че фрагментацията е неизбежна при стартиране на някои приложения. Например, фрагментация възниква, ако дадено приложение изпраща данни на малки парчета. Ако възникне фрагментация, въпреки че приложението изпраща данни на големи блокове, определете причината за фрагментацията. Възможно е указаният MTU размер на интерфейса да не съответства на MTU размера на отдалечените системи.
Следното е пример за команден изход за udp протокола: # netstat -p udp udp: 11623 получени дейтаграми 0 непълни заглавки 0 полета с неправилна дължина 0 неправилни контролни суми 620 отхвърлени поради липсващ сокет 232850 предупреждение и многофункционални дейтаграми отхвърлени поради липсващ сокет 0 сокет буфери пълни 14 доставени дейтаграми 12 изпратени дейтаграми
Маркираните полета в изхода на командата са описани по-долу:
- Неправилни контролни суми
Неправилни контролни суми възникват в резултат на повреда на адаптера или повреда на кабела.
- Изхвърлен поради липса на букса
Броят на получените UDP дейтаграми, чийто целеви порт не е бил отворен. В този случай се връща съобщението ICMP Receiver Unreachable - Port Unreachable. Не се изпращат ICMP съобщения за грешка за UDP предупредителни дейтаграми. Ако броят на отхвърлените дейтаграми е голям, тогава приложението вероятно изпитва грешки в сокета.
- Препълване на буфера на сокета
Препълването на буфера на сокетите се причинява от недостатъчни UDP сокети за изпращане и получаване, nfsd демони или недостатъчни стойности на параметри. nfs_socketsize, udp_recvspaceИ sb_max.
Ако резултатът от командата netstat -p udpброят на препълванията на буфера на сокета е различен от нула, препоръчително е да се увеличи броят на nfsd демоните на сървъра. Първо проверете дали процесорът на системата или I/O подсистемата са претоварени и след това извикайте командата no -аи се уверете, че другите нива на протокола са зададени на препоръчителните стойности. Ако системата е претоварена, трябва да намалите натоварването или да увеличите количеството системни ресурси.
Следното е пример за команден изход за tcp протокола: # netstat -p tcp tcp: 576 изпратени пакета 512 пакета данни (62323 байта) 0 пакета данни (0 байта) препредадени 55 пакета с известия (28 отложени) 0 спешни пакета 0 пакети за проверка на прозорец 0 пакети за актуализиране на прозорец 9 контролни пакета 0 операции largesend 0 байта, изпратени с largesend 0 байта в максимален пакет largesend 719 получени пакета 504 пакета за известяване (за 62334 байта) 19 повтарящи се известия 0 известия за неизпратени данни 449 получени пакета (4291 байта) в правилния ред 8 пълни копия на пакети (8 байта) 0 стари копия на пакети 0 пакети за копиране на данни (0 байта копия) 5 пакета извън реда (0 байта) 0 пакета (0 байта) данни след прозорец 0 проверки на прозорец 2 пакети за актуализиране на прозореца 0 пакета, получени след затваряне 0 пакета с неправилна хардуерна контролна сума 0 отхвърлени поради неправилна контролна сума 0 отхвърлени поради неправилни полета на заглавката 0 отхвърлени поради твърде кратка дължина 0 отхвърлени от получателите 0 отхвърлени поради препълване на опашки на получатели 71 правилни прогнози за заглавки на пакети за уведомяване 71 правилни прогнози за заглавки на пакети с данни 6 заявки за връзка 8 разрешени връзки 14 установени връзки (включително разрешени) 6 затворени връзки (включително 0 прекъснати) 0 ECN активирани връзки 0 ECN отговори 0 първоначални прекъснати връзки 504 актуализирани сегмента (505 опита) 0 сегменти с намален брой битове на прозореца за зареждане 0 сегменти с набор от битове, тестван при натоварване 0 повторни предавания, свързани с изчисления на MTU на маршрута 0 Търсенията на MTU път са прекъснати поради повторно предаване 0 изчаквания на повторно предаване 0 прекъснати връзки поради изчакване rexmit -out 0 бързи повторни предавания 0 с прозорец за зареждане, който не надвишава 3 сегмента 0 нови повторни предавания 0 предотвратени погрешни бързи повторни предавания 0 постоянни изчаквания 0 прекъснати връзки поради постоянни изчаквания 16 изтичащи изчаквания 16 изпратени теста за изтичане 0 отхвърлени връзки поради изтичане 0 операции за разширяване на блоков масив SACK 0 операции за разширяване на масив с пропуски в SACK 0 отхвърлени пакети поради неуспешно разпределение на паметта 0 повторно използвани връзки 0 забавени известия за SYN 0 забавени известия за FIN 0 изпращания на операции с прекъсване на връзката 0 сложни връзки 0 затворени сложни връзки 0 нулиране на сложни връзки 0 изчаквания на сложна връзка 0 изчаквания на постоянна сложна връзка 0 изтичане на сложна връзка таймаути
Маркираните полета в изхода на командата са описани по-долу:
- Изпратени пакети
- Пакети данни
- Пакетите с данни са изпратени повторно
- Получени пакети
- Повторете пакетите
- Изтичане на времето за прехвърляне
Сравнете броя на изпратените пакети с броя на повторно изпратените пакети. Ако броят на повторно предадените пакети надвиши 10 до 15 процента от общия брой пакети, настъпва изчакване на TCP. Най-вероятно те се дължат на факта, че мрежата е твърде заета, така че известието не може да бъде изпратено преди изтичането на времето за изчакване. Освен това повторното предаване на TCP пакети може да се дължи на голямо натоварване на получаващата система или на цялостна лоша производителност на мрежата. Повторното предаване увеличава потока от данни и допълнително увеличава натоварването на мрежата.
Освен това сравнете броя на получените пакети с броя на повторените пакети. Ако времето за изчакване на потвърждението изтече след изпращането на пакет, пакетът се предава повторно. В този случай целевата система може да получи всички предадени копия на пакета. Ако броят на пакетите за повторно възпроизвеждане надвишава 10 до 15 процента, мрежата или получаващата система може да са претоварени. Повторното предаване на пакети също увеличава потока от данни в мрежата.
Времето за изчакване на повторно предаване възниква, когато възел изпрати пакет, но не получи потвърждение в рамките на определеното време. В този случай пакетът се предава отново. Тази стойност се увеличава за всяко повторно предаване. Повтарящите се предавания увеличават натоварването на процесора. Ако никога не бъде получено потвърждение, пакетът ще бъде отхвърлен.