IPB

Здравейте ( Вход | Регистрация )

> Пътешествието на пакета., Basic journey of a packet
never_mind
коментар Jul 7 2006, 19:42
Коментар #1


...the necessary evil...

Група: ???????? ?????
Коментари: 2,266
Регнат: 6-November 05
От: София
???: ???



Целта на тази статия е да даде основна представа за пътя, който изминава един пакет през Интернет, от създаването му, през суичове, рутери, NAT и т.н. до достигане на крайната цел. Тя е подходяща за тези, за които тази материя е нова и още нямат основата и разбирането й.

Пътешествието

Когато дадено интернет приложение бива извикато, се случват серия от събития. Например някой отваря Firefox за да провери сутрешните новини от любимия си сайт. На заден план, невидимо за юзъра, се случват няколко неща. След като се завърши 3-стъпковия TCP/IP handshake ( това е процес на създаване на TCP връзка м/у 2 машини, в случая - връзка м/у машината на юзъра и сървъра, хостващ желания сайт. Този handshake е наложителен, защото tcp протокола е протокол, който изисква да се изгради логическа връзка ( канал ) м/у двете машини, докато например при udp протокола това не е необходимо, защото той е stateless ), уеб браузърът ( в случая Firefox ) ще създаде заявка, искаща от уеб сървъра неговата начална страница ( homepage ). Сега тази HTTP GET заявка трябва да бъде изпратена до сървъра. Сега Firefox изисква заявка за писане от системата ( write request ). При този процес информацията, която Firefox иска да изпрати и се намира заредена в application memory space ( част от системната памет, заделена и ползваща се в момента от дадена програма, в случая Firefox ), се копира в специален буфер за изпращане, намиращ се вътре в ядрото на операционната система ( socket send buffer ). В зависимост какъв протокол използва дадената програма ( Firefox ), socket слоя ще извика или TCP, или UDP протокол. Трябва да се запомни, че не всяка програма използва TCР протокол. DNS използва и двата протокола, докато TFTP ползва само UDP. След като socket слоя извика нужния протокол, информацията бива копирана в socket буфера.
Малко отклонение: Какво е това socket, което употребихме няколко много пъти по-горе.
Socket е крайната точка на връзката в една TCP/IP мрежа, така, както телефона е крайната точка в една телефонна мрежа. Socket е комбинацията от TCP порт и IP адрес. Порта е логическия интерфейс за дадената програма, за който има зададен определен номер. Например HTTP протокола ( който е протокол от по-високо ниво в модела на OSI, няма нищо общо с TCP протокола, за да не запитате защо TCP протокола няма порт ) се намира на порт 80 ( стандартно ). Използвайки аналогията с телефона, TCP порта е като номера на телефона, а IP адреса е местонахождението му. Socket-а е като телефон, на който му е бил зададен номер. Въпреки това един хост ( компютър ) може да има едновременни много актовни сокета ( постига се чрез мултиплексиране ). Сокета се създава в процеса на осъществяване на връзката м/у две машини, когато едната прави заявка да се върже към другата на определен порт. Когато връзката е осъществена , трансфера започва. Сокетите са основната абстракция на сокет интерфейса. Сокет интерфейса е API ( application programming interface ) , а сокета е мястото където програмния процес прави връзка с друг процес през мрежата. Сокет интерфейса е това, което позволява дадена програма да се свърже с порт и IP адрес. Ако програмата има нужда от услугите на tcp протокола, тя използва stream socket, който предлага двупосочна надеждна логическа връзка м/у двете машини. Datagram socket-а се използва, когато не е нужна сигурната tcp връзка. Той минава през udp протокола.

До тук с отклонението, да се върнем на създаването на пакета.

Фрагментация

Когато се копира информацията в socket буфера, при необходимост TCP ще я фрагментира ( раздроби ). Въпреки, че GET заявката ще се побере идеално в един пакет и ще попадне под MTU ( Maximum Transmission Unit, най-големия размер на пакета, който даден мрежови протокол от даден мрежови слой може да пренесе ) за Ethernet, какво ще стане ако все пак заявката на браузъра надвиши MTU? Ако това се случи, tcp протокола има задачата да раздроби информацията, за да подсигури нейното събиране в MTU от 1500 байта за етернет. Тук е важно да се отбележи, че фрагментацията се прави на tcp ниво. Ако програмата ползваше udp протокол и се налагаше фрагментация, тя щеше да бъдя извършена на IP ниво. Когато информацията премине tcp нивото, идва ред на IP слоя. Тук се създава IP хедъра, като се записват всички необходими IP адреси. След това информацията попада в data link слоя , където Local Link control и
OSI модел IPB Image
Media access control нивата добавят своята част към пакета. Сега вече пакета е готов да бъде транспортиран от физическия слой, олицетворение на който е NIC картата ( Network interface card или на български лан-ка. Трябва да се отбележи обаче, че лан-ката не е единствената NIC, която съществува ). И така като серия от 0 и 1 заявката на браузъра пътува през средата, която може да е най-разнообразна ( кабел, радиовълна, оптика, инфрачервена светлина и др. ), докато достигне ethernet суич в случая. Суича е различно хардуерно устройство от рутера, въпреки, че за повечето домашни юзъри SoHo рутера е всъщност комбинация от суич и прост рутер. В повечето случаи компютърът е свързан със суича чрез UTP cat-5 кабел, но съществуват и много други среди. Ако суича няма твърдо зададена CАМ таблица, тогава той си отбелязва MAC адреса на компютъра ( това е уникален адрес за всяка NIC ). Когато пакетът се завърне, носейки нужната информация, суичът ще знае към кой компютър да я насочи, защото си е отбелязал неговия MAC адрес.
Как нашият компютър знае кой е default gateway за него? Ако не се използва DHCP протокол, при който настройките на всяка карта се задават автоматично, се налага всеки да ги въвежда ръчно. Тази информация се предоставя от доставчика на интернет. Когато е зададен default gateway, компютърът вече знае откъде да достигне Интернет. След като пакета премине суича, той винаги достига рутер ( освен ако пакета не е предназначен за някой компютър в същият сегмент на мрежата, в която сме и ние ). Най-вероятно рутера действа и като защитна стена ( firewall ), поради което пакета бива анализиран и дадена информация от него ( не самата потребителска информация, а IP адреса и порта на подателя и получателя ) бива записана в таблиците на рутера. Това се прави ако рутера действа като stateful firewall, тоест следи всяка една връзка и я записва. Ако действа като прост пакетен филтър подобен анализ не се извършва. Firewall-a ще пази тази информация в таблицата на състоянията ( state table ) и така регулира достъпа до мрежата. Ако пакетът не е записан като напускащ мрежата, той просто няма да бъде допуснат обратно в нея.

за рутирането и NAT-а

Когато пакетът премине firewall-a ( ако има такъв ), той е готов да премине и през рутера. Сега частният IP адрес, който пакета има( най-често адрес от мрежа 192.168/16 ), ще бъде заменен с рутиран публичен адрес. Това е необходимо, защото частните адреси не се рутират. Тази процедура се нарича NAT ( Network address translation ). Сега пакетът започва пътешествието си из интернет през рутери, които ще го насочват, докато достигне целта. Всеки път, щом пакетът премине от един рутер към друг, нещо се случва с него. Нека хвърлим поглед към рутерите, гледащи към интернет. Те рутират пакетите на базата на своите рутиращи таблици. Когато даден рутер приеме нашия пакет, той ще го насочи спрямо своята рутираща таблица. Преди това обаче, той ще промени няколко полета в хедъра на пакета. Едно от тях е ttl ( time to live ).

* TTL се използва, за да се окаже максималния живот на пакета. При преминаване на пакета през рутер, той намаля с 1 числото в ttl полето. Когато то стане 0 пакета бива дропнат и подателя бива уведомен. TTL и много полезен при предотвратяване на зацикляния на пакети в мрежата в следствие на грешни маршрутизиращи таблици или др. явления. Също така може да се използва и за защита/ограниченаване .

Сега, когато част от хедъра е променен, рутера трябва да прибави нова checksum-a към пакета.

* Checksum-a се използва за защита от грешки. Това е последователност от битове, генерирана чрез използването на различни похвати в/у информацията в пакета. Благодарение на checksum-aта получателя разбира дали пакета е получен правилно или има грешка и евентуално дали може да се поправи грешката .

Това се случва всеки път, когато пакета преине през рутер. И така докато достигне целта, а именно уеб сървъра. Когато пакета достигне последният рутер преди сървъра, рутера ще го насочи към порт 80 на сървъра. Сървърът ще получи пакета и ще се заеме с обработката му. Физическия слой ще подаде IRQ ( interrupt request, заявка за прекъсване ) към процесора на сървъра, казвайки му, че има информация за обработка. Когато това се случи, информацията бива пратена нагоре до data link слоя, където сървъра разпознава MAC-а и праща пакета нагоре до IP слоя. Там се разпознава IP адреса на сървъра. Следва вкарване на информацията в TCP буфера. Тук сървърната програма разпознава, че информацията е за нея и започва с обработката й. Резултата: създава се исканата информация, генерира се сокет и пакета се праща по абсолютно аналогичния начин до нашия компютър. Сега за него остава само задачата да си намери път. Това става по абсолютно същият начин ( но най-често не по същият път!!! ).
source: http://www.securityfocus.com
превод и добавки: never_mind

За създаването на тази статия са използвани материали от: http://www.securityfocus.com ( идеята и основните неща ), http://wikipedia.org/, http://linktionary.com/
Go to the top of the page
 
+Quote Post
 
Start new topic
Отговори (1 - 1)
Paagrio
коментар Jul 13 2006, 19:33
Коментар #2


Доверено лице

Група: ?????????? +
Коментари: 1,277
Регнат: 27-April 05
От: Пловдив
???: ???



направо дай линка където ги четеш тия работи biggrin.gif
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
2 потребител(и) четат тази тема (2 гости и 0 скрити)
0 Потребител(и):

 



- Елате в .: BGtop.net :. Топ класацията на българските сайтове и гласувайте за този сайт!!! Олекотена версия

Сега е: 28th October 2021 - 22:05