Б.1. Класификация на мрежови протоколи
B.1.1. Физическият слой OSI B.1.2. Слоят на предаване на данни OSI Б.1.3. Мрежа ниво OSI B.1.3.1. ARP B.1.3.2. RARP B.1.3.3. IP B.1.3.4. IPv6 Б.1.4. Транспортният слой OSI B.1.4.1. ICMP B.1.4.2. UDP B.1.4.3. TCP B.1.4.3.1. Структурата на TCP B.1.4.3.2 пакет. Откриване TCP връзка ръкостискане тройна B.1.4.3.3. Затварянето на TCP B.1.4.3.4 връзка. Състоянието на Б.1.5 на TCP връзки. представяне на ниво приложение и продължителност на сесията
За класификацията на мрежови протоколи се използват така наречените еталон седем елемент модел на OSI (вж. [URL: // уики-OSI-RU]).
OSI модел мрежа (английски Open Systems Взаимно свързване референтен модел -. Модел на отворени системи за взаимно свързване) - абстрактен модел за мрежови комуникации и развитие мрежови протоколи.
Моделът разделя мрежовите протоколи на седем нива:
- Физическият слой (Физически слой).
- Слоят на връзка (Data Link слой);
- Мрежа слой (мрежа слой);
- Слоят транспорт (Транспорт слой);
- Сесия на слоя (Session слой);
- Представяне Layer (Представяне слой);
- слой приложение (Application слой);
B.1.1. Физическа OSI слой
Физическият слой се използва директно за предаване на сигнала. Протоколът от физическия слой е описано, например, трябва да се подреди линия (усукана двойка), така че да е гарантирано да пропусне сигнал към Ethernet 100base-TX стандарт: дебелината на отделните ядра, тяхната устойчивост, честотата на фолио, минималното разстояние от проводник към захранващия кабел, maksismalnoe брой навивки в гнездото и минимален радиус на залива, дължината на тел от повторителя да ретранслатор брой кабел тип съединения rozerka, методът живее окабеляване съединител RJ-45.
На физическо ниво, има центрове и ретранслатори (известни също като ретранслатори). Назначаване на член на ретранслатори за увеличаване на сигнала. Те са необходими в случай, че е необходимо за предаване на сигнала-далеч от това, предоставена от стандарта. Необходима е Концентраторът (известен също като център), с цел да се подобри не само на сигнала, но и да я предава от един проводник към няколко други по този начин главина трябва да се комбинират няколко устройства в Ethernet сегмент.
B.1.2. OSI слоя на връзката
превключватели (превключвател) работа на това ниво, мост (мост) и, разбира се, реалните Ethernet интерфейс карти (мрежови карти).
Ако мрежата не се събира на превключвателите и хъбове (т.е. не по switch'ah и hub'ah, има склонни жаргонен израз "нецензурни мрежа" за мрежата), всички рамки са доставени на всички. Такава организация е лошо, не само от гледна точка на безопасността, но най-вече от гледна точка на производителността. Ако две Ethernet устройства в същото време, изпратени до сегмента на рамката, а след това ще има конфликт - както на кадъра. препраща рамките се извършва. За конфликт няма да се случи отново, повторно експедиране се забави за произволен период от време. Колкото повече устройства в мрежата, толкова по-голяма вероятността от сблъсъци. Pro устройство, което може да влезе в такъв конфликт, те казват, че те са в "сблъсък на домейн". По този начин, основното предимство switch'ey преди hub'ami е, че те се разделят мрежата на много малки сблъскване домейни, като по този начин значително подобряване на производителността на мрежата.
За да се следи слой заглавието на предаване на данни в Tcpdump на програмата (1), при условие -e опция. (Вж. Раздел 6.11, "Демонстрация на основните умения за работа с полезност Tcpdump (1)").
Б.1.3. OSI мрежа слой
На това ниво на функциониране, IP протокол IPv6, ARP, RARP, както и някои други, но ние сме тук само се интересуват от четиримата.
B.1.3.1. ARP
B.1.3.2. RARP
B.1.3.3. IP
IP протокол за предаване на пакети, задачата за формиране на пакет, не са включени контрол грешка в IP функции протокол. Това е прерогатив на протоколи по-високо ниво, като например TCP, UDP, ICMP.
В раздел 6.11, "Демонстрация на основните умения за работа с Tcpdump (1) полезност" е Tcpdump списък с програми (1) с прихващането на две ICMP пакети. В този пример е описано подробно, което е в заглавната част на пакета IP.
B.1.3.4. IPv6
Б.1.4. Транспорт OSI слой
Забележка: Възможно е да се добавят допълнителни кодове ICMP по някакъв друг, по-скорошно RFC. Така например, в RFC 950 добавен съобщенията Адрес Маска Заявка (код 17) и адрес маска отговор (код 18)
Най izvetsnye ICMP съобщения, това е може би най-ехо искане и ехо отговор. Те обикновено се използват за целите на изпитване. В раздел 6.4.2, «проследяващи (1)" описва как проследяващи програма (8) чрез тях се определя маршрут от точка до точка.
B.1.4.2. UDP
UDP протокол работи на принципа на "огън и забрави". Той не само не гарантира доставка на пакети, но тя дори не гарантира, че доставените пакети ще дойдат в същия ред, в който са изпратени. Въпреки това, за надеждни мрежи в името на растежа на производителността е възможно в някои приложения да използват UDP протокола. По едно време на мрежата NFS файлова система се основава на UDP протокол, както и контрол на грешки се извършва при по-високи слоеве OSI. В момента, обаче, тази практика е намалял.
B.1.4.3. TCP
И накрая, TCP протокол UDP протокол се различава от това, че той работи механизъм за контрол грешка. За да се приложи този механизъм в заглавната добавя допълнително поле за знамената на TCP. (Това не е единственото усложнение в сравнение с UDP, и ние се интересуваме от това, но е така.) Всеки TCP пакети се потвърждава пакет с ACK флаг (потвърждение). Един пакет с ACK флаг може да потвърди получаването на няколко пакета. Протоколът е предвидено трудно да се провери, което се случи, когато отваряне и затваряне на връзката.
B.1.4.3.1. Структурата на пакета TCP
Таблица Б.2. Форматът на заглавната част на TCP
Източник Port Port подател 16 бита - номер на порт. Дестинация Порт Destination Port, 16 бита - броят на пристанището на дестинация. Пореден номер Брой опашка 32 бита - номер на последователност на първия октет данни в този сегмент (с изключение, когато флагът за синхронизация SYN присъства). Ако флага SYN присъства, след номера на последователност е инициализация (ISN), а броят на първия октет данни - ISN + 1. Потвърждение брой номера за потвърждение, 32 бита - Ако сигналът за ACK, това поле съдържа следващия номер последователност, която подателят на дейтаграмата иска да се върне. Потвърждение номера непрекъснато се изпращат, веднага след като връзката е установена. Data Offset Офсет данни, 4 бита - Броят на 32-битови думи в заглавието на TCP. Това показва началото на полето за данни. TCP хедър винаги завършва на 32-битова дума граница, дори и ако той има опции. Резервиран Резервиран поле трябва да се запълва с нули. 6 бита. Битове за управление знамена TCP, 8 бита (осем знамена). Знамена От ляво на дясно: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN. Първите две знамена в старите ръководства често ottsutstvuyut. Знамената са дадени в таблица Б.3, «TCP флаговете". Window Window, 16 бита - Броят на октета данни, започващи с октет, чийто номер е посочен в полето за потвърждение. Броят на октета, което чака за получаване на изпращача на този сегмент. Контролната сума на шах 16-битов Спешна Pointer Pointer 16 бита на неотложност - В това поле се отчита текущата стойност на спешната показалеца. Последното е положителна стойност - офсет от номера на реда в този сегмент. Спешна показалка разказва поредния номер на октет след неотложните данни. Това поле се тълкува единствено в случаите, когато този сегмент е изложена URG флаг. Опции Опции, с променлива дължина.
Таблица Б.3. TCP флагове
подателя информира получателя за превоза забавяне (вж. [RFC-3168])
спешно поле показалка, участващи
потвърждение Невярно е замесена
рестартиране на съединението
синхронизация на номера на последователност
Няма по данни за изпращане
B.1.4.3.2. Откриване TCP връзки тройна ръкостискане
TCP съединение, за разлика от UDP, подкрепя идеята за "комуникационна сесия". Това означава, че данните могат да отидат от източника до местоназначението с един поток. Протоколът осигурява проверка за грешки. Данните не могат да бъдат загубени или многократни или изпревари един от друг. За изпълнение на тази trebovniya организира завръщането на трафика от приемника на подателя, в който получателят съобщи за това, което той получава пакети и докладват своите контролни суми. За тази цел, изпратени пакети с ACK флаг.
В горната схема илюстрира еднопосочен поток от данни. Т.е. дори и за еднопосочен поток от данни се изисква да преминат пакети в двете посоки. В същото време, по-голямата част от TCP връзки двупосочна като протоколи за приложения (HTTP, SMTP, и т.н.) за прехвърляне на данни в двете посоки. Например, ако браузърът трябва да изтеглите един ресурс, а след това от браузъра изпрати заявка за GET <имя ресурса>, и от собствени ресурси на сървъра. Помислете как да се отвори двупосочен връзка.
На първо място, една от страните, ние ще я наричаме "клиент" изпраща друг ( "сървър") пакет Строние с изложен SYN флаг. Това е вид на молба за откриване на връзка.
Сървърът трябва да потвърди получаването на този пакет и изпраща обратно пакет с набор от АСК флаг. Но тъй като връзката трябва да бъде двупосочна, той също трябва да изпрати пакета на клиента със заявлението за откриване на връзката, т.е. с SYN флаг. Тези два пакета със знамена SYN АСК, и могат да бъдат комбинирани в един пакет.
Клиентът, получена от пакета SYN към сървъра, сега той трябва да го докаже, и го изпраща на сървъра АСК пакет потвърждава откритието на връзката от сървъра към клиента.
По този начин, на клиента и сървъра са разменили три пакета: 1) клиентът е направил искане за отваряне на връзка от клиента към сървъра; 2) Сървърът потвърди откритието на това съединение и прави искане за отваряне на връзка от сървъра към клиента; 3) откриване на клиент връзка потвърди от сървъра към клиента. Тази процедура се нарича процедура от три пакет обмен "тройно ръкостискане» (тройно договаряне).
Първите три пакетите, които забелязваме, че те просто се отнасят до процедурата за трикратното ръкостискане. Това може да се види, че първият SYN пакет е с флаг (означени с главна буква S в разпечатката), също е втори SYN флаг и знамето ACK сделка. Третият пакет не е имал знаме, различно от АСК.
Следващите два пакета (4 и 5) в нашите печатни опаковки носи отговорност за предаване на данни през HTTP. В първата, клиентът изпраща заявка HTTP-ресурс протокол HTTP GET команда. Тъй като цялата заявка опаковани в един пакет, PSH (тласък) на знамето е обявен в този пакет. Този флаг се поставя да причини на сървъра да изпрати всички натрупани пакети заявлението е в очакване на тях (т.е. уеб сървър). В отговор, сървърът изпраща страницата HTML. Тази страница също се вписват в един пакет, и поради това също се очаква да PSH флаг.
Накрая последните четири пакетите съответстват на закриването на TCP връзки и процедурата ще бъдат обсъдени по-долу.
B.1.4.3.3. Затваряне на TCP връзка
TCP връзка, както е споменато по-горе, двупосочно, така че затваря отделен клиент и сървър. По този начин генерира пакет 4: 1), сървърът изпраща уведомление за затваряне на канала от сървъра към клиента, с FIN флага на пакета; 2) Клиентът потвърждава получаването му с флаг ACK пакет; 3) Клиентът изпраща FIN пакет - известие за затваряне на канала от клиент-сървър; 4) сървъра признава получаването му. Понякога пакети 2 и 3 се смесват в същия начин, както това се случва при тройната ръкостискане.
След домакин изпраща пакет с FIN флаг, той вече няма право да изпраща данни през един и същ контакт.
Защо не клиентът изпраща FIN пакет в една и съща опаковка, в която го изпраща флаг ACK? Заради затварянето на канала - независима процедура. То се извършва в момента, когато функциите на приложението (браузър или уеб сървър), да се обадя в затворите (2). По принцип, след като връзката от сървъра към клиента е бил затворен и остава в полу-затворено състояние, клиентът все още може да продължи да предава някои данни към сървъра.
При тази процедура, има някакъв проблем, когато клиентът е получил последния пакет с ACK флаг, потвърждаващ получаването на пакета с FIN сървър флаг, той не изпраща на сървъра. Тъй като сървърът знае, че клиентът получава своята пакет ACK? За да не попаднат в порочния кръг и да експулсира потвърждение безкрайност за потвърждение, на следния алгоритъм е избран в TCP протокол: не е абстрактна величина, наречена "пределната забавяне сегмент» (MSL максимален сегмент през живота). Този параметър характеризира очаквания максималния възможен план на сегмент на мрежата, преди да се изхвърли другаде. В [RFC-793] препоръчва стойност MSL на 2 минути. На практика, този път зависи от конкретното изпълнение на операционната система и може да бъде по-малко. Сървърът след изпращане на пакети АСК чака два пъти по време MSL и ако през това време той не се ре-FIN пакет, той смята, че неговият пакети АСК безопасно за клиента и затваря контакта.
B.1.4.3.4. Състоянието на TCP връзки
Имайте предвид състоянието на TIME_WAIT, както вече бе споменато, отнема два пъти по време на MSL, т.е. за 4 минути. В това състояние става само страната, която изпълнява активна тясната връзка. В понижено графиката е клиент, и разпечатка Tcpdump (1), в примера с уеб сървър е сървър. В ситуация, когато сървърът изпълнява активна близо (и на уеб сървър, това е вярно), може да се натрупа голям брой изключителни контакти. Рано или късно, за претоварените уеб сървър тя може да се превърне в сериозен проблем. Поради тази причина, повечето съвременни операционни системи, на това място не отговарят на RFC. FreeBSD е в състояние на TIME_WAIT за една минута.
Свързани статии