From Wikipedia, the free encyclopedia
TCP/IP моделот (Трансмисиски контролен протокол/Интернетски протокол) е описна рамка за компјутерски мрежни протоколи создадена во 1970 од страна на DARPA, агенција на Министерството за одбрана на САД. Моделот еволуирал од ARPANET, кој беше првата светски широкопојасна мрежа и е претходник на Интернет.
TCP/IP модел понекогаш се нарекува Интернет модел или DoD модел.
TCP/IP модел, или Internet Protocol Suite, опишува множество на општи насоки за дизајн и имплементација на специфични мрежни протоколи за да се овозможи компјутерите да комуницираат преку компјутерска мрежа. TCP/IP обезбедува крај-крај поврзување и конкретизирање на тоа како треба да се форматирани податоците, адресирани, пренесени, насочени и примени на одредиштето. Протоколи постојат за различни типови на комуникациски услуги помеѓу компјутери.
TCP/IP моделот има четири издвоени слоеви како што е дефинирано во RFC 1122. Овој слој архитектура често се споредува со седум-слојниот OSI Референтен модел, користејќи термини како што e Интернет референтен модел. Сепак, ова е неправилно поради тоа што TCP / IP моделот е описен, додека OSI Референтен модел би требало да биде наменет за давање упатства, па оттука и се вика референтен модел.
TCP/IP моделот и слични протоколи се одржуваат од страна на специјална единица за интернет инжинерство (IETF).
TCP/IP (Интернет протокол Suite) |
---|
Апликациски слој BGP • DHCP • DNS • FTP • HTTP • IMAP • IRC • LDAP • MGCP • NNTP • NTP • POP |
Транспортен слој |
Интернет слој |
Линк слој ARP/InARP • NDP • OSPF • Tunnels (L2TP) • PPP • |
![]() | Оваа статија или заглавие има потреба од викифицирање за да ги исполни стандардите за квалитет на Википедија. Ве молиме помогнете во подобрувањето на оваа статија со соодветни внатрешни врски. |
Ран архитектонски документ, RFC 1122, го нагласува значењето на архитектонските принципи над слоевитоста.
Дури и кога слоевите се испитуваат, избрани архитектонски документи (не постои единствен архитектонски модел како ИСО 7498, OSI референтен модел) имаат помалку и помалку строго дефинирани слоеви од OSI моделот, и на тој начин овозможуваат полесно вклопување во вистинските светски протоколи. Всушност, еден документ на кој често се повикуваат, RFC 1958, не содржи многу слоеви.Недостатокот на истакнување на наслојувањето е силна разлика помеѓу IETF приодот и OSI приодот. Ова се однесува само на постоењето на "интернет слој" и, воопшто, на "горните слоеви", овој документ беше наменет како "слика" од 1996 на архитектурата: "Интернетот и неговата архитектура се израснаа на еволутивен начин повеќе од скромни почетоци, а не од некој голем план. Иако овој процес на еволуција е една од главните причини за успех на технологијата, сепак се чини корисно да зачува слика на тековните принципи на интернет архитектурата. "
Документот RFC 1122, насловен како „Побарувања на Хостот“, е структуиран во вид на параграфи кои се однесуваат на слоевите. Меѓутоа, документот се однесува на многу други принципи на архитектурата, притоа не нагласувајќи го наслојувањето. Лабаво дефинира четири-слоен модел, со имиња на слоевите, а не бројки, како што се следниве:
Интернет протоколот Suite и дизајнот на множество од протоколи биле користени пред OSI моделот да биде воспоставен. Од тогаш, TCP/IP моделот се споредува со OSI моделот во книги и училници, што често резултира во конфузија, бидејќи двата модели користат различни претпоставки, вклучувајќи ја и релативната важност на строгото раслојување.
Слоевите во близина на врвот се логично поблиску до корисничката апликација, додека оние кои се во близина на дното се логично поблиску до физичкиот пренос на податоци. Гледањето на слоевите како обезбедување или конзумирање на услуга е метод на апстракција да се изолира горниот слој протоколи од основните детали за пренесување на битовите, на пример, Етернет и детекција на колизија, додека пониските слоеви ја избегнуваат обврската да ги знаат сите детали на секоја апликација и нејзиниот протокол.
Оваа апстракција исто така дозволува горните слоеви да обезбедат услуги кои пониските слоеви не можат, или избираат да не ги обезбедат. Повторно, оригиналниот OSI Референтен модел бил проширен за да вклучи услуги без врска (OSIRM CL). На пример, IP не е дизајниран да биде сигурен и е протокол за најдобар напор испорака. Ова значи дека сите имплементации на Транспортниот слој мора да изберат дали треба или не да се обезбеди сигурност и до кој степен. UDP обезбедува интегритет на податоците (преку проверка) но не гарантира испорака; TCP обезбедува и интегритет на податоците и гаранција за испорака (со постојано ретрансмитирање сè додека примателот не го признае приемот на пакет).
На овој модел му недостасува формализмот на OSI референтниот модел и придружните документи, но IETF не користи формален модел и не го смета ова како ограничување, како што кажува во својот коментар, Давид Д. Кларк, "Одбиваме: кралеви, претседатели и гласање. Ние веруваме во: груб консензус и извршен код". Критиките на овој модел, кои се направени во однос на OSI Референтен модел, често не ги сметаат подоцнeжните ISO екстензии за тој модел.
Следново е опис на секој слој на TCP/IP мрежниот модел почнувајќи од најниско ниво.
Линк слој е мрежниот обем на локалната мрежна врска на која домаќинот е приклучен. Овој режим е наречен линк во интернет литературата. Ова е најнискиот составен слој од интернет протоколите, бидејќи TCP/IP е дизајниран да биде независен од хардвер. Како резултат на ова TCP/IP е имплементиран на врвот на речиси секоја хардверска мрежна технологија во постоење.
Линк слојот се користи за движење на пакети помеѓу интерфејси на Интернет Слој на два различни домаќини на истиот линк. Процесите на пренесување и примање пакети на даден линк може да се контролираат во драјверот на софтверскиот уред за мрежната картичка, како и специјализирани множества од чипови. Овие ќе извршат податочни линк функции како додавање на еден заглавје пакет за да се подготви за пренос, а всушност рамката ќе биде пренесена преку физички медиум. TCP/IP моделот ги вклучува спецификациите за преведување на мрежните адресирачки методи кои се користат во интернет протокол за податочно линк адресирање, како што е Контрола на медиумски пристап (MAC), но сепак, сите други аспекти под тоа ниво се претпоставува дека имплицитно постојат во Линк слојот, но не се експлицитно дефинирани.
Линк слојот е слој каде пакетите може да бидат избрани да бидат испратени преку виртуелна приватна мрежа, или друг мрежен тунел. Во ова сценарио, податоците на Линк слојот може да се сметаат за апликациски податоци кои преминуваат друга инстантација на множество IP за пренос или прием преку друга IP врска. Таква врска, или виртуелен линк, може да се воспостави со протокол за транспорт или дури и апликациски обем протокол кој служи како тунел во Линк слојот на множеството протоколи. Така, TCP/IP моделот не диктира строга хиерархиска херметичка низа.
Интернет слојот го решава проблемот за испраќање на пакети низ една или повеќе мрежи. Оваа врска бара испраќање на податоци од изворната мрежа до мрежата која е одредиште. Овој процес се нарекува насочување.
Во Интернет протоколот Suite, Интернет протоколот врши две основни функции:
IP може да носи податоци за голем број на различни протоколи од погорните слоеви. Секој од овие протоколи се идентификува со единствен број на протокол: на пример, Интернет протокол за контрола на пораки (ICMP) и Интернет протокол за групно управување (IGMP) се протоколи 1 и 2, соодветно.
Некои од протоколите извршени од страна на IP, како што се ICMP (се користи за пренос на дијагностички информации за IP пренос) и IGMP (се користи за управување со IP мултикаст податоци), се подредени на врвот на IP но вршат функции за поврзување. Ова ги илустрира разликите во архитектурата на TCP/IP множество на Интернет и OSI моделот.
Обврските на транспортниот слој вклучуваат способности за крај-крај трансфер на пораки независно од основната мрежа, заедно со контрола на грешки, сегментација, контрола на проток, контрола на метеж, и адресирање на апликации (броеви на порти). Крај-крај преносот на пораки или поврзувачките апликации кај транспортниот слој може да се категоризираат или како конекциски ориентирани, имплементирани во Протоколот за контрола на пренос (TCP), или безконекциски, имплементирани во Протоколот за кориснички датаграм (UDP).
Транспортниот слој може да се смета како транспортен механизам, на пример, возило со одговорност да се осигура дека неговата содржина (патници / добра) ќе стигне безбедно и сигурно до своето одредиште, освен во случај кога друг слој на протокол не е одговорен за безбедна испорака.
Транспортниот слој ја обезбедува оваа услуга на поврзување на апликациите преку употреба на услужни порти. Бидејќи IP обезбедува само најдобар напор за испорака, транспортниот слој е првиот слој на TCP/IP множеството кој може да понуди сигурност. IP може да работи на линк протокол на стабилни податоци како што е Контрола на податочен линк со високо ниво (HDLC). Протоколи над транспорт, како што е RPC, исто така може да обезбедат сигурност.
На пример, Протоколот за контрола на пренос (TCP) е конектирачки ориентиран протокол кој посветува внимание на бројни сигурносни прашања за да обезбеди стабилен бајт поток:
Поновиот Преносен протокол за контрола на текот (SCTP) е исто така сигурен, конекциски ориентиран транспортен механизам. Тој е ориентиран кон тек на пораки — а не е ориентиран кон тек на бајтови како што е TCP — и обезбедува повеќе струи мултиплексирани над една врска. Исто така обезбесува и multi-homing поддршка, во која крајот на врската може да биде претставен со повеќе IP-адреси (кои претставуваат повеќе физички интерфејси), така што ако некоја не успее, врската не се прекинува. Првично бил развиен за телефонски апликации (за транспорт на SS7 преку IP), но исто така може да се користи и за други апликации.
Протоколот за кориснички датаграм е безконекциски датаграм протокол. Како IP, тој е најдобар напор, "нестабилен" протокол. Стабилноста е покриена со откривање на грешки со користење на алгоритам слаба проверка. UDP обично се користи за апликации како што се стриминг медиуми (аудио, видео, Глас преку IP и сл.) каде што навременото пристигнување е многу поважно отколку сигурноста, или за едноставни пребарување / одговор апликации како DNS пребарувања, каде прекумерната контрола за создавање на стабилна врска е несразмерно голема. Транспортен протокол во реално време (RTP) е датаграм протокол кој е наменет за податоци во реално време, како што е стриминг аудио и видео.
TCP и UDP се користат за носење на збир од апликации од повисоко ниво. Соодветниот транспортен протокол е избран врз основа на протокол апликација од повисок слој. На пример, Протоколот за пренос на податотеки очекува сигурна врска, но Мрежниот Даточен Систем (NFS) претпоставува дека потчинетиот Далечен процедурален повик протокол, а не транспорт, ќе гарантира сигурен пренос. Други апликации, како што е VoIP, може да поднесат одредена загуба на пакети, но не и преуредување или одложување кое можеле да биде предизвикано од реемитување.
Апликациите во било која дадена мрежна адреса се разликуваат по својата TCP или UDP порта. Со конвенција одредени познати порти се поврзуваат со специфични апликации. (Видете Список на TCP и UDP броеви на порти.)
Апликацискиот слој се однесува на протоколи од повисоко ниво кои се користат од страна на повеќето апликации за мрежна комуникација. Примери за апликациски слојни протоколи се Протоколот за трансфер на податотеки (FTP) и Протоколот за едноставен трансфер на пошта (SMTP). Податоците кодирани според апликациски слојни протоколи потоа се енкапсулираат во еден или (понекогаш) во повеќе транспортни слојни протоколи (како на пример Протоколот за контрола на пренос (TCP) или Протоколот за кориснички датаграм (UDP)), кои пак ги користат долните слојни протоколи за да влијаат на вистинскиот трансфер на податоци.
Бидејќи IP множеството не дефинира слоеви помеѓу апликацијата и транспортните слоеви, апликацискиот слој мора да ги вклучи сите протоколи кои дејствуваат како презентација на OSI и сесиските слојни протоколи. Ова обично се прави преку библиотеки.
Протоколите на апликацискиот слој го третираат транспортниот слој (и пониските) протоколи како "црни кутии" кои обезбедуваат стабилна мрежна врска преку која ќе се комуницира, иако апликациите обично се свесни за клучните квалитети на врската на транспортниот слој како што се IP-адреси со крајна точка и броеви на порти. Како што е наведено погоре, слоевите не мора да се јасно дефинирани во интернет протокол suite. Протоколите на апликацискиот слој се најчесто поврзувани со клиент–опслужувач апликации, и позастапените опслужувачи имаат одредени порти кои им се доделени од страна на IANA: HTTP ја има порта 80; Telnet ја има порта 23 итн. Клиентите, од друга страна, пак, имаат тенденција да користат краткотрајни порти, односно броеви на порти доделени по случаен избор од голем број резервирани за таа цел.
Транспортниот и слоевите од пониско ниво не се заинтересирани во голема мера за подробностите на протоколите на апликацискиот слој. Насочувачите и преклопниците не "гледаат во внатрешноста" на затворениот сообраќај за да видат каков тип на апликациски протокол претставува тој, туку тие само обезбедуваат еден вид канал за тоа. Сепак, некои заштитни ѕидови и апликации за пригушување на опсег се обидуваат да утврдат што има внатре, како што е Протоколот за резервација на ресурси (RSVP). Исто така, понекогаш е потребно објекти за Превод на мрежна адреса (NAT) за да се земат предвид потребите од одредени апликациски слојни протоколи. (NAT овозможува домаќините на приватни мрежи да комуницираат со надворешниот свет преку една видлива IP-адреса со користење на портно пренасочување, и е речиси насекаде одлика на модерните домашни широкопојасни насочувачи).
Нормално, апликациските програмери се занимаваат само со интерфејси во Апликацискиот слој, а често и во Транспортниот слој, додека пониските слоеви се услуги обезбедени од страна на TCP/IP множеството во оперативниот систем. Микроконтролер во мрежниот адаптер обично се справува со линк прашања, поддржан од драјверски софтвер во оперативниот систем. Не-програмабилна аналогна и дигитална електроника вообичаено е задолжена за физичките компоненти во Линк слојот, обично со користење на чипсет со специфично за апликацијата интегрално коло (ASIC) за секој мрежен интерфејс или друг физички стандард.
Сепак, имплементација на хардвер или софтвер не е наведена во протоколите или слоевитиот референтен модел. Насочувачите со високи перформанси се во голема мера засновани на брза не-програмабилна дигитална електроника, која го спроведува префрлањето на линк нивото.
Три горни слоеви на OSI моделот Апликацискиот слој Архивирано на 27 септември 2011 г., Презентацискиот слој[мртва врска] и Сесискиот слој[мртва врска] не се разликуваат одвоено во TCP/IP моделот каде што тие се претставени само како Апликациски слој. Додека некои чисто OSI протокол апликации, како што е X.400[мртва врска], исто така, ги комбинираат, не постои услов дека TCP/IP протокол множеството треба да наметне монолитна архитектурата над Транспортниот слој. На пример, апликацискиот протокол на Мрежниот даточен систем (NFS) работи преку презентацискиот протокол за Надворешно претставување на податоците[мртва врска] (XDR), кој, пак, работи преку еден протокол со функционалност на сесиски слој, Далечен процедурален повик[мртва врска] (RPC). RPC овозможува сигурен пренос на евиденција, па може да работи сигурно преку транспортот на Протоколот за кориснички датаграм (UDP).
Сесискиот слој грубо соодветствува со функционалноста на виртуелниот терминал на Telnet, кој е дел од протоколите засновани на текст како HTTP и SMTP TCP/IP модел протоколи со Апликациски слој. Тој, исто така соодвествува и со TCP и UDP портното нумерирање, кое се смета како дел од Транспортниот слој во TCP/IP моделот. Некои функции кои би биле вршени со презентацискиот слој на OSI се реализира во интернет апликацискиот слој со користење на MIME[мртва врска] стандард, кој се користи во апликациски слој протоколи како HTTP и SMTP.
Бидејќи IETF при развојот на протоколите не се занимава со строго раслојување, некои од нејзините протоколи може да не се вклопуваат целосно во OSI моделот. Ваквите конфликти, сепак, се почести кога се разгледува оригиналниот OSI модел, ISO 7498, без да се гледа во анекси на овој модел (на пример, ISO 7498 / 4 Управувачка Рамка), или ISO 8648 Внатрешна организација на мрежниот слој (IONL). Кога документите IONL и Управувачка Рамка се земаат предвид, ICMP и IGMP се уредно дефинирани како слој на управувачки протоколи за мрежниот слој. На сличен начин, IONL обезбедува структура за "конвергентни објекти кои се подмрежно зависни" како што се ARP[мртва врска] и RARP[мртва врска].
IETF протоколите може да се енкапсулираат рекурзивно, како што е покажано со тунелирањето протоколи како што е Општата Рутинг Енкапсулација[мртва врска] (GRE). Додека основните OSI документи не го прифаќаат тунелирањето, има некој концептот за тунелирање во уште еден продолжеток на OSI архитектурата, конкретно порталите на транспортниот слој во состав на Меѓународната Стандардизирана Профил рамка [10]. Поврзаните со ова развојни напори на OSI, сепак, биле напуштени со оглед на огромното усвојување на TCP/IP протоколите.
Следната табела ги прикажува имињата на слоевите и бројот на слоеви на мрежни модели претставени во RFCs и учебниците кои се во широка употреба во универзитетските курсеви за компјутерски мрежи.
Курозе[11], Фроузен [12] | Комер[13], Козиерок[14] | Сталингс[15] | Таненбаум[16] | RFC 1122, Интернет STD 3 (1989) | Cisco Академија[17] | "Арпанет Референцен модел" на Мајк Падлипксу 1982 (RFC 871) |
---|---|---|---|---|---|---|
Пет слоеви | Четири+ еден слоеви | Пет слоеви | Четири слоеви | Четири слоеви | Четири слоеви | Три слоеви |
„Пет-слоен Интернет модел“ или „TCP/IP протокол suite“ | „TCP/IP 5-слоен референтенмодел“ | „TCP/IP модел“ | „TCP/IP референтен model“ | „Интернет модел“ | „Интернет модел“ | „Арпанет референтен модел“ |
Апликација | Апликација | Апликација | Апликација | Апликација | Апликација | Апликација/Процес |
Транспорт | Транспорт | Домаќин-домаќин или транспорт | Транспорт | Транспорт | Транспорт | Домаќин-домаќин |
Мрежа | Интернет | Интернет | Интернет | Интернет | Интернет работа | |
Податочен линк | Податочен линк (Мрежен интерфејс) | Мрежен пристап | Домаќин-мрежа | Линк | Мрежен интерфејс | Мрежен интерфејс |
Физички | (Хардвер) | Физички |
Овие учебници се второстепени извори и можат да бидат во спротивност со намерата на RFC 1122 и други IETF примарни извори како што е RFC 3439[18].
Различни автори ги толкувале RFCs поинаку во однос на прашањето дали Линк слојот (и TCP/IP моделот) ги покрива прашањата во однос на Физичкиот слој, или во однос на претпоставката дека хардверскиот слој е под Линк слојот. Некои автори се обиделе да користат и други имиња за Линк слојот, како на пример слој за мрежен интерфејс, со цел да се избегне забуна со Податочниот линк слој на седум-слојниот OSI модел. Други се обиделе да го мапираат моделот на Интернет протокол кон OSI моделот. Мапирањето често резултирало со модел со пет слоеви каде што Линк слојот е поделен во Слој на податочниот линк кој се наоѓа врз Физички слој. Во литературата со дното-нагоре пристап до интернет комуникацијата [12][13][15],во кој се потенцираат хардвер прашања, тие се често дискутирани во однос на физичкиот слој и слојот на податочниот линк.
Интернет слојот обично е директно мапиран во Мрежниот слој Архивирано на 10 декември 2011 г. на OSI моделот, ова е еден поопшт концепт на мрежна функционалност. Транспортниот слој од TCP / IP моделот, понекогаш опишуван и како домаќин-домаќин слој, е мапиран на OSI Слој 4 (Транспортен слој), понекогаш, исто така, вклучувајќи аспекти на функционалноста на OSI Слој 5 (Сесиски слој[мртва врска]). Апликацискиот слој Архивирано на 27 септември 2011 г., Презентацискиот слој[мртва врска] на OSI и останатата функционалност на Сесискиот слој се урива во Апликацискиот слој на TCP/IP. Факт е дека овие OSI слоеви обично не постојат како одвоени процеси и протоколи во Интернет апликации.
Сепак, интернет протокол множеството никогаш не е променето од страна на Специјалната Единица за Интернет Инжинерство од четирите слоеви дефинирани во RFC 1122. IETF не прави никакви напори да го следи OSI моделот иако RFCs понекогаш се однесуваат на него и често ги користат старите OSI слој броеви. IETF во неколку наврати изјави дека интернет протоколот и развојот на архитектурата не е наменет да биде компатибилен со OSI. RFC 3439, правејќи осврт на интернет архитектурата, содржи дел насловен како: „Слоевитоста се смета за штетна“. [18]
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.