TCP/IP модел

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).

Клучни принципи на архитектурата

Ран архитектонски документ, RFC 1122, го нагласува значењето на архитектонските принципи над слоевитоста.

• Крај-крај принцип: Овој принцип се развивал во текот на времето. Неговиот првобитен израз го ставал одржувањето на состојбата и целокупната интелигенција на краевите и претпоставувал дека интернетот што ги поврзува краевите се концентрира на брзина и едноставност. Меѓутоа, реалните потреби на светот од заштитни ѕидови, преведувачи на мрежни адреси, кеширање на веб содржини и слично го принудиле овој принцип на промени.^[2]
• Принцип на сила: "Во главно, имплементацијата мора да биде конзервативна во своето испраќачко однесување, и либерална во своето однесување при примање. Значи, мора да биде внимателна во испрќањето добро формирани датаграми, но мора да го прифати секој датаграм што може да го протолкува (на пр. не се противи на технички грешки каде што значењето е сè уште јасно)." "Вториот дел од принципот е речиси исто толку важен: софтверот на други домаќини може да содржи недостатоци поради кои не би било мудро да се искористат легалните но нејасни протокол одлики."

Дури и кога слоевите се испитуваат, избрани архитектонски документи (не постои единствен архитектонски модел како ИСО 7498, OSI референтен модел) имаат помалку и помалку строго дефинирани слоеви од OSI моделот, и на тој начин овозможуваат полесно вклопување во вистинските светски протоколи. Всушност, еден документ на кој често се повикуваат, RFC 1958, не содржи многу слоеви.Недостатокот на истакнување на наслојувањето е силна разлика помеѓу IETF приодот и OSI приодот. Ова се однесува само на постоењето на "интернет слој" и, воопшто, на "горните слоеви", овој документ беше наменет како "слика" од 1996 на архитектурата: "Интернетот и неговата архитектура се израснаа на еволутивен начин повеќе од скромни почетоци, а не од некој голем план. Иако овој процес на еволуција е една од главните причини за успех на технологијата, сепак се чини корисно да зачува слика на тековните принципи на интернет архитектурата. "
Документот RFC 1122, насловен како „Побарувања на Хостот“, е структуиран во вид на параграфи кои се однесуваат на слоевите. Меѓутоа, документот се однесува на многу други принципи на архитектурата, притоа не нагласувајќи го наслојувањето. Лабаво дефинира четири-слоен модел, со имиња на слоевите, а не бројки, како што се следниве:

• Апликациски слој (процес-процес): Ова е обемот во кој апликации создаваат кориснички податоци и ги разменуваат овие податоци со други процеси или апликации на друг или истиот домаќин. Комуникациските партнери често се нарекуваат пар. Овде работат протоколите од "повисоко ниво" како што се SMTP, FTP, SSH, HTTP, итн.
• Транспортниот слој (домаќин-домаќин): Транспортниот слој претставува мрежен режим помеѓу два мрежни домаќини, независно дали се на локална мрежа или на оддалечени мрежи разделени со насочувачи. Транспортниот слој обезбедува униформиран интерфејс за вмрежување, кој ја крие вистинската топологија (распоред) на основните мрежни врски. Овде постојат контола на проток, исправка на грешки поврзувачки протоколи, како на пример TCP. Овој слој се занимава со отворање и одржување на врски помеѓу интернет домаќини.
• Интернет слој (интернет): Интернет слојот има за задача размена на датаграми низ мрежните граници. Затоа е исто така познат како слојот со кој се воспоставува врска, и навистина, го дефинира и воспоставува Интернетот. Овој слој ги дефинира адресирачките и насочувачките структури кои се користат за TCP/IP протокол suite. Примарниот протокол во овој опсег е Интернет протоколот, кој ги дефинира IP-адресите. Неговата функција во насочувањето е да ги транспортира датаграмите до следниот IP насочувач кој има врска со мрежа која е поблиску до конечното одредиште на податоците.
• Линк слој (домаќин-до-мрежа): Овој слој ги дефинира методите на вмрежување со опсегот на линкот на локалната мрежа на кој домаќините комуницираат без посредство на насочувачи. Овој слој опишува протоколи кои се користат за опишување на топологијата на локалната мрежа и интерфејсите кои се потребни за да влијаат на преносот на датаграмите на Интернет слојот на следните соседни домаќини. (Сп. OSI слојот на податочната врска).

Интернет протоколот Suite и дизајнот на множество од протоколи биле користени пред OSI моделот да биде воспоставен. Од тогаш, TCP/IP моделот се споредува со OSI моделот во книги и училници, што често резултира во конфузија, бидејќи двата модели користат различни претпоставки, вклучувајќи ја и релативната важност на строгото раслојување.

Слоеви на TCP/IP моделот

Слоевите во близина на врвот се логично поблиску до корисничката апликација, додека оние кои се во близина на дното се логично поблиску до физичкиот пренос на податоци. Гледањето на слоевите како обезбедување или конзумирање на услуга е метод на апстракција да се изолира горниот слој протоколи од основните детали за пренесување на битовите, на пример, Етернет и детекција на колизија, додека пониските слоеви ја избегнуваат обврската да ги знаат сите детали на секоја апликација и нејзиниот протокол.
Оваа апстракција исто така дозволува горните слоеви да обезбедат услуги кои пониските слоеви не можат, или избираат да не ги обезбедат. Повторно, оригиналниот OSI Референтен модел бил проширен за да вклучи услуги без врска (OSIRM CL). На пример, IP не е дизајниран да биде сигурен и е протокол за најдобар напор испорака. Ова значи дека сите имплементации на Транспортниот слој мора да изберат дали треба или не да се обезбеди сигурност и до кој степен. UDP обезбедува интегритет на податоците (преку проверка) но не гарантира испорака; TCP обезбедува и интегритет на податоците и гаранција за испорака (со постојано ретрансмитирање сè додека примателот не го признае приемот на пакет).
На овој модел му недостасува формализмот на OSI референтниот модел и придружните документи, но IETF не користи формален модел и не го смета ова како ограничување, како што кажува во својот коментар, Давид Д. Кларк, "Одбиваме: кралеви, претседатели и гласање. Ние веруваме во: груб консензус и извршен код". Критиките на овој модел, кои се направени во однос на OSI Референтен модел, често не ги сметаат подоцнeжните ISO екстензии за тој модел.

1. За повеќепристапни врски со сопствени адресни системи (на пример, Етернет) потребен е протокол за мапирање адреси. Ваквите протоколи може да се сметаат дека се под IP но над постојаниот линк систем. Додека IETF не ја користи оваа терминологија, ова е подмрежно зависен објект за конвергенција според продолжеток на OSI моделот, Внатрешната организација на мрежниот слој (IONL).
2. ICMP и IGMP работат на врвот на IP но не пренесуваат податоци како UDP или TCP. Оваа функционалност постои како слој за управување со додатоците на OSI моделот, во својата рамка за управување (OSIRM MF)
3. SSL / TLS библиотеката функционира над транспортниот слој (користи TCP) но под апликациските протоколи. Меѓутоа, од страна на дизајнерите на овие протоколи, немало намера да се усогласат со OSI архитектурата.
4. Линкот овде е третиран како црна кутија. Ова е во ред за дискутирање на IP-адреса (бидејќи целата поента на IP е дека ќе работи на речиси ништо). IETF експлицитно нема намера да разговара за преносни системи, што е помалку академска, но практична алтернатива на ISO Референтен модел.

Следново е опис на секој слој на TCP/IP мрежниот модел почнувајќи од најниско ниво.

Линк слој (Мрежен пристап или Домаќин-Мрежа)

Линк слој е мрежниот обем на локалната мрежна врска на која домаќинот е приклучен. Овој режим е наречен линк во интернет литературата. Ова е најнискиот составен слој од интернет протоколите, бидејќи TCP/IP е дизајниран да биде независен од хардвер. Како резултат на ова TCP/IP е имплементиран на врвот на речиси секоја хардверска мрежна технологија во постоење.
Линк слојот се користи за движење на пакети помеѓу интерфејси на Интернет Слој на два различни домаќини на истиот линк. Процесите на пренесување и примање пакети на даден линк може да се контролираат во драјверот на софтверскиот уред за мрежната картичка, како и специјализирани множества од чипови. Овие ќе извршат податочни линк функции како додавање на еден заглавје пакет за да се подготви за пренос, а всушност рамката ќе биде пренесена преку физички медиум. TCP/IP моделот ги вклучува спецификациите за преведување на мрежните адресирачки методи кои се користат во интернет протокол за податочно линк адресирање, како што е Контрола на медиумски пристап (MAC), но сепак, сите други аспекти под тоа ниво се претпоставува дека имплицитно постојат во Линк слојот, но не се експлицитно дефинирани.
Линк слојот е слој каде пакетите може да бидат избрани да бидат испратени преку виртуелна приватна мрежа, или друг мрежен тунел. Во ова сценарио, податоците на Линк слојот може да се сметаат за апликациски податоци кои преминуваат друга инстантација на множество IP за пренос или прием преку друга IP врска. Таква врска, или виртуелен линк, може да се воспостави со протокол за транспорт или дури и апликациски обем протокол кој служи како тунел во Линк слојот на множеството протоколи. Така, TCP/IP моделот не диктира строга хиерархиска херметичка низа.

Интернет слој

Интернет слојот го решава проблемот за испраќање на пакети низ една или повеќе мрежи. Оваа врска бара испраќање на податоци од изворната мрежа до мрежата која е одредиште. Овој процес се нарекува насочување.
Во Интернет протоколот Suite, Интернет протоколот врши две основни функции:

• Адресирање на домаќинот и идентификација: Ова е постигнато со хиерархиски систем за адресирање (види IP-адреси).
• Насочување на пакети: Ова е основната задача на пренесување на пакети со податоци (датаграми) од изворот до одредиштето со нивно испраќање до следниот мрежен јазол (насочувач) кој е поблизок до конечното одредиште.

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-адреса со користење на портно пренасочување, и е речиси насекаде одлика на модерните домашни широкопојасни насочувачи).

Имплементацијa на хардвер и софтвер

Нормално, апликациските програмери се занимаваат само со интерфејси во Апликацискиот слој, а често и во Транспортниот слој, додека пониските слоеви се услуги обезбедени од страна на TCP/IP множеството во оперативниот систем. Микроконтролер во мрежниот адаптер обично се справува со линк прашања, поддржан од драјверски софтвер во оперативниот систем. Не-програмабилна аналогна и дигитална електроника вообичаено е задолжена за физичките компоненти во Линк слојот, обично со користење на чипсет со специфично за апликацијата интегрално коло (ASIC) за секој мрежен интерфејс или друг физички стандард.
Сепак, имплементација на хардвер или софтвер не е наведена во протоколите или слоевитиот референтен модел. Насочувачите со високи перформанси се во голема мера засновани на брза не-програмабилна дигитална електроника, која го спроведува префрлањето на линк нивото.

Разлики во слоевите помеѓу OSI и TCP/IP

Три горни слоеви на 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]

Исто така погледнете

• BBN Извештај 1822

Наводи

1. ^ Architectural Principles of the Internet, RFC 1958, B. Carpenter, June 1996
2. ^ Rethinking the design of the Internet: The end to end arguments vs. the brave new world, Marjory S. Blumenthal, David D. Clark, August 2001
3. ^ p.23 INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION September 1981 Jon Postel Editor
4. ^ Requirements for Internet Hosts -- Communication Layers p.13 October 1989 R. Braden, Editor
5. ^ [ OSI: Reference Model Addendum 1: Connectionless-mode Transmission,ISO7498/AD1],ISO7498/AD1, May 1986
6. ^ Internal Organization of the Network Layer, ISO 8648
7. ^ Open Systems Interconnection -- Basic Reference Model -- Part 4: Management framework, ISO 7498/4
8. ^ IP Packet Structure
9. ^ TCP/IP Illustrated: the protocols, ISBN 0-201-63346-9, W. Richard Stevens, February 1994
10. ^ Framework and taxonomy of International Standardized Profiles, ISO 10000, October 1998
11. ^ James F. Kurose, Keith W. Ross, Computer Networking: A Top-Down Approach, 2008, ISBN 0-321-49770-8
12. ^ a b Behrouz A. Forouzan, Data Communications and Networking
13. ^ a b Douglas E. Comer, Internetworking with TCP/IP: Principles, Protocols and Architecture, Pearson Prentice Hall 2005, ISBN 0-13-187671-6
14. ^ Charles M. Kozierok, "The TCP/IP Guide", No Starch Press 2005
15. ^ a b William Stallings, Data and Computer Communications, Prentice Hall 2006, ISBN 0-13-243310-9
16. ^ Andrew S. Tanenbaum, Computer Networks, Prentice Hall 2002 ISBN 0-13-066102-3
17. ^ Mark Dye, Mark A. Dye, Wendell, Network Fundamentals: CCNA Exploration Companion Guide, 2007, ISBN 1-58713-208-7
18. ^ a b R. Bush; D. Meyer (December 2002), Some Internet Architectural Guidelines and Philosophy Архивирано на 27 ноември 2007 г., Internet Engineering Task Force, retrieved 2007-11-20

Надворешни врски

• Understanding Cisco TCP/IP Архивирано на 19 декември 2008 г.