COSCED

Стек протоколов TCP/IP — набор сетевых протоколов передачи данных, используемых в сетях, включая сеть Интернет. Название TCP/IP происходит из двух наиважнейших протоколов семейства — Transmission Control Protocol (TCP) и Internet Protocol (IP), которые были разработаны и описаны первыми в данном стандарте.

Протоколы работают друг с другом в стеке (англ. stack, стопка) — это означает, что протокол, располагающийся на уровне выше, работает «поверх» нижнего, используя механизмы инкапсуляции. Например, протокол TCP работает поверх протокола IP.

Протоколы этих уровней полностью реализуют функциональные возможности модели OSI. На стеке протоколов TCP/IP построено всё взаимодействие пользователей в IP-сетях. Стек является независимым от физической среды передачи данных.

Теперь рассмотрим подробнее эти уровни.

Канальный

Канальный уровень описывает, каким образом передаются пакеты данных через физический уровень, включая кодирование (то есть специальные последовательности бит, определяющих начало и конец пакета данных). Ethernet, например, в полях заголовка пакета содержит указание того, какой машине или машинам в сети предназначен этот пакет.

Примеры протоколов канального уровня — Ethernet, IEEE 802.11 Wireless Ethernet, SLIP, Token Ring, ATM.

Кроме того, канальный уровень описывает среду передачи данных (будь то коаксиальный кабель, витая пара, оптическое волокно или радиоканал), физические характеристики такой среды и принцип передачи данных (разделение каналов, модуляцию, амплитуду сигналов, частоту сигналов, способ синхронизации передачи, время ожидания ответа и максимальное расстояние).

Сетевой

Сетевой уровень изначально разработан для передачи данных из одной (под)сети в другую. С развитием концепции глобальной сети в уровень были внесены дополнительные возможности по передаче из любой сети в любую сеть, независимо от протоколов нижнего уровня, а также возможность запрашивать данные от удалённой стороны.

Транспортный

Протоколы транспортного уровня могут решать проблему негарантированной доставки сообщений («дошло ли сообщение до адресата?»), а также гарантировать правильную последовательность прихода данных. В стеке TCP/IP транспортные протоколы определяют, для какого именно приложения предназначены эти данные.

Протоколы автоматической маршрутизации, логически представленные на этом уровне (поскольку работают поверх IP), на самом деле являются частью протоколов сетевого уровня.

TCP — «гарантированный» транспортный механизм с предварительным установлением соединения, предоставляющий приложению надёжный поток данных, дающий уверенность в безошибочности получаемых данных, перезапрашивающий данные в случае потери и устраняющий дублирование данных.

TCP позволяет регулировать нагрузку на сеть, а также уменьшать время ожидания данных при передаче на большие расстояния. Более того, TCP гарантирует, что полученные данные были отправлены точно в такой же последовательности. В этом его главное отличие от UDP.

UDP протокол передачи датаграмм без установления соединения. Также его называют протоколом «ненадёжной» передачи, в смысле невозможности удостовериться в доставке сообщения адресату, а также возможного перемешивания пакетов. В приложениях, требующих гарантированной передачи данных, используется протокол TCP.

UDP обычно используется в таких приложениях, как потоковое видео и компьютерные игры, где допускается потеря пакетов, а повторный запрос затруднён или не оправдан, либо в приложениях вида запрос-ответ (например, запросы к DNS), где создание соединения занимает больше ресурсов, чем повторная отправка.

И TCP, и UDP используют для определения протокола верхнего уровня число, называемое портом.

Прикладной

На прикладном уровне работает большинство сетевых приложений. Эти программы имеют свои собственные протоколы обмена информацией, например, HTTP (протокол передачи гипертекста) для WWW (World Wide Web), FTP (передача файлов), SMTP (электронная почта), SSH (безопасное соединение с удалённой машиной), DNS (преобразование символьных имён в IP-адреса) и многие другие. В массе своей эти протоколы работают поверх TCP или UDP и привязаны к определённому порту.

Сравнение с моделью OSI

Существуют разногласия в том, как вписать модель TCP/IP в модель OSI, поскольку уровни в этих моделях не совпадают.

К тому же, модель OSI не использует дополнительный уровень — «Internetworking» — между транспортным и сетевым уровнями.

Сетевая модель OSI (англ. open systems interconnection basic reference model — базовая эталонная модель взаимодействия открытых систем) — сетевая модель стека сетевых протоколов OSI/ISO.

В связи с затянувшейся разработкой протоколов OSI, в настоящее время основным используемым стеком протоколов является TCP/IP, он был разработан ещё до принятия модели OSI и вне связи с ней.

Уровни модели OSI

Любой протокол модели OSI должен взаимодействовать либо с протоколами своего уровня, либо с протоколами на единицу выше и/или ниже своего уровня. Взаимодействия с протоколами своего уровня называются горизонтальными, а с уровнями на единицу выше или ниже — вертикальными. Любой протокол модели OSI может выполнять только функции своего уровня и не может выполнять функций другого уровня, что не выполняется в протоколах альтернативных моделей.

Прикладной уровень

Прикладной уровень (уровень приложений; англ. application layer) — верхний уровень модели, обеспечивающий взаимодействие пользовательских приложений с сетью.

Позволяет приложениям использовать сетевые службы:

• удалённый доступ к файлам и базам данных,
• пересылка электронной почты;
• отвечает за передачу служебной информации;
• предоставляет приложениям информацию об ошибках;
• формирует запросы к уровню представления.

Протоколы прикладного уровня: RDP (Remote Desktop Protocol), HTTP (HyperText Transfer Protocol), SMTP (Simple Mail Transfer Protocol), SNMP (Simple Network Management Protocol), POP3 (Post Office Protocol Version 3), FTP (File Transfer Protocol) и другие.

Представительский уровень

Представительский уровень (уровень представления; англ. presentation layer) обеспечивает преобразование протоколов и шифрование/дешифрование данных. Запросы приложений, полученные с прикладного уровня, на уровне представления преобразуются в формат для передачи по сети, а полученные из сети данные преобразуются в формат приложений. На этом уровне может осуществляться сжатие/распаковка или кодирование/декодирование данных, а также перенаправление запросов другому сетевому ресурсу, если они не могут быть обработаны локально.

Уровень представлений обычно представляет собой промежуточный протокол для преобразования информации из соседних уровней. Это позволяет осуществлять обмен между приложениями на разнородных компьютерных системах прозрачным для приложений образом. Уровень представлений обеспечивает форматирование и преобразование кода. Форматирование кода используется для того, чтобы гарантировать приложению поступление информации для обработки, которая имела бы для него смысл. При необходимости этот уровень может выполнять перевод из одного формата данных в другой.

Уровень представлений имеет дело не только с форматами и представлением данных, он также занимается структурами данных, которые используются программами. Таким образом, уровень 6 обеспечивает организацию данных при их пересылке.

Сеансовый уровень

Сеансовый уровень (англ. session layer) модели обеспечивает поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений.

Протоколы сеансового уровня: ADSP (AppleTalk Data Stream Protocol), ASP (AppleTalk Session Protocol), H.245 (Call Control Protocol for Multimedia Communication) и другие.

Транспортный уровень

Транспортный уровень (англ. transport layer) модели предназначен для обеспечения надёжной передачи данных от отправителя к получателю. При этом уровень надёжности может варьироваться в широких пределах. Существует множество классов протоколов транспортного уровня, начиная от протоколов, предоставляющих только основные транспортные функции (например, функции передачи данных без подтверждения приема), и заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в надлежащей последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных. Например, UDP ограничивается контролем целостности данных в рамках одной датаграммы и не исключает возможности потери пакета целиком или дублирования пакетов, нарушения порядка получения пакетов данных; TCP обеспечивает надёжную непрерывную передачу данных, исключающую потерю данных или нарушение порядка их поступления или дублирования, может перераспределять данные, разбивая большие порции данных на фрагменты и, наоборот, склеивая фрагменты в один пакет.

Протоколы транспортного уровня: ATP (AppleTalk Transaction Protocol), CUDP (Cyclic UDP), DCCP (Datagram Congestion Control Protocol), FCP (Fiber Channel Protocol) и другие.

Сетевой уровень

Сетевой уровень (англ. network layer) модели предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и «заторов» в сети.

Протоколы сетевого уровня маршрутизируют данные от источника к получателю. Работающие на этом уровне устройства (маршрутизаторы) условно называют устройствами третьего уровня (по номеру уровня в модели OSI).

Протоколы сетевого уровня: IP/IPv4/IPv6 (Internet Protocol), IPX (Internetwork Packet Exchange, протокол межсетевого обмена), X.25 (частично этот протокол реализован на уровне 2), CLNP (сетевой протокол без организации соединений), IPsec (Internet Protocol Security). Протоколы маршрутизации — RIP (Routing Information Protocol), OSPF (Open Shortest Path First).

Канальный уровень

Канальный уровень (англ. data link layer) предназначен для обеспечения взаимодействия сетей по физическому уровню и контролем над ошибками, которые могут возникнуть. Полученные с физического уровня данные, представленные в битах, он упаковывает в кадры, проверяет их на целостность и, если нужно, исправляет ошибки (формирует повторный запрос поврежденного кадра) и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием.

Спецификация IEEE 802 разделяет этот уровень на два подуровня: MAC (англ. media access control) регулирует доступ к разделяемой физической среде, LLC (англ. logical link control) обеспечивает обслуживание сетевого уровня.

На этом уровне работают коммутаторы, мосты и другие устройства. Эти устройства используют адресацию второго уровня (по номеру уровня в модели OSI).

В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой. Это не новый уровень, а просто реализация модели для конкретной ОС.

Примеры таких интерфейсов: ODI, NDIS, UDI.

Физический уровень

Физический уровень (англ. physical layer) — нижний уровень модели, который определяет метод передачи данных, представленных в двоичном виде, от одного устройства (компьютера) к другому. Составлением таких методов занимаются разные организации, в том числе: Институт инженеров по электротехнике и электронике, Альянс электронной промышленности, Европейский институт телекоммуникационных стандартов и другие. Осуществляют передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов.

На этом уровне также работают концентраторы, повторители сигнала и медиаконвертеры.

Функции физического уровня реализуются на всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером или последовательным портом. К физическому уровню относятся физические, электрические и механические интерфейсы между двумя системами. Физический уровень определяет такие виды сред передачи данных как оптоволокно, витая пара, коаксиальный кабель, спутниковый канал передач данных и т. п.

Протоколы физического уровня: IEEE 802.15 (Bluetooth), IRDA, EIA и другие.

Критика

В конце 90-х годов семиуровневая модель OSI критиковалась отдельными авторами. В частности, в книге «UNIX. Руководство системного администратора» Эви Немет (англ. Evi Nemeth) писала:

Пока комитеты ISO спорили о своих стандартах, за их спиной менялась вся концепция организации сетей и по всему миру внедрялся протокол TCP/IP.

И вот, когда протоколы ISO были наконец реализованы, выявился целый ряд проблем:

• эти протоколы основывались на концепциях, не имеющих в современных сетях никакого смысла;
• их спецификации были в некоторых случаях неполными;
• по своим функциональным возможностям они уступали другим протоколам;
• наличие многочисленных уровней сделало эти протоколы медлительными и трудными для реализации.

Сейчас даже самые ярые сторонники этих протоколов признают, что OSI постепенно движется к тому, чтобы стать маленькой сноской на страницах истории компьютеров.

Ответ на этот вопрос немножечко двоякий. Можно сказать, и «Да» и «Нет» и быть правдивым и в том и в другом случае.

Давайте посмотрим почему люди верят, что математика нужна всем программистам и нужна им всегда. Дело в том, что компьютерная наука как таковая весьма молодая наука. Поэтому исторически так получилось, что когда университеты создавали кафедры компьютерной науки или кафедры для инженера-программиста, компьютерные инженерии и так далее, то они создавали их на базе одной из двух кафедр. Это было либо – кафедра математики, либо – кафедра инженерии.

У первых математика вообще является очевидным: математика – это то, что они изучают. Естественно, получилось так, что большинство преподавателей преподавали программирование исходя из математики. Они говорили про математические модели, они выстраивали математические формулы, даже подходили к разработке программного обеспечения с точки зрения математика, а не с точки зрения программиста. С другой стороны, если они делали их на базе инженерии, то там математика все равно была везде, потому что инженерия как вы понимаете для математика – теоретическая, прикладная и так далее. Но всем математика была нужна и если спросить: «Нужна ли математика инженеру?» звучало весьма странно. Естественно нужна. Даже посмотрите на само слово «Инженер-программист». То есть по какой-то причине исторически так получилось, что программистов приписали к инженерам.

Но ведь это не совсем правильно. Если мы подумаем об этом, то можно было бы приписать их ко многим другим. К примеру, я могу сказать, что лингвистика очень сильно помогает программисту. Именно в этом есть ключ. Нужна ли программисту математика? Да, она нужна, если мы говорим о том, что, если она поможет программисту в решении определенных задач. Какие задачи вам поможет решить математика? В основном задачи, которые решены за вас какими-то библиотеками. Например, вы хотите написать на ассемблере для самого процессора какую ту библиотеку, к примеру библиотеку, которая будет высчитывать вам что-то. Естественно, вам нужна математика. В процессоре ограниченное количество операций и вам нужно все остальные операции суметь выразить теми операциями, которые делает процессор. У процессора нет квадратного корня и многих других задач. Вам нужно выразить одну вещь которую вы уже знаете, к который вы привыкли, как например на калькуляторе, она занимает всего лишь одну кнопку. Здесь вам придется ее выражать другими какими-то возможностями этого процессора. Поэтому вам нужна математика и какие-то ее знания. Или, например, вам надо занимать чем-либо, что связанно с 3D-графикой. Это проекция 3D-мира из одно геометрии в другую. Геометрия – это часть математики. Таким образом в этом случае вам нужна математика. В том случае, если вы не находитесь в первых рядах тех людей, которые делают что-то, что еще не было решено конкретными библиотеками, то в этом случае математика вам не нужна. Ведь все, что вы будете делать – это вызывать уже готовые библиотеки.

Возьмем, например, процедуры шифрования. Вам не стоит их реализовывать, потому что скорее всего вы программисты, вы не математики. Вы не знаете всех нюансов математических функций. Намного лучше вызвать уже написанную функцию за вас, а потом использовать результат того, что вы получаете обратно. Математика вам будет не нужна. Вам нужно будет знать, как программисту то, какие функции использовать, в какой последовательности. Вам нужно просто знать, что что-то там есть в этой библиотеке. Вам нужно знать, что шифрование без одностороннего ключа обратить нельзя. Вам нужно понимать, что есть слабое, сильное шифрование. Вы знаете, эти вещи, но реализовывать вы их не будете, потому что, математика вам не нужна. Таким образом, нужна ли математика программисту? Да, математика вам может помочь. Нет, математика вам не обязательна.

Тем не менее есть одна вещь, где математика помогает всем программистам. Это, например, математика, которая связана со сложностью алгоритма. Но что происходит там? Она там настолько простая, что если вы закончили шесть классов школы, то вы уже должны понять ее. Зачем вам изучать всю математику, если она вам не нужна? Естественно, ее понимание вам поможет. Если сказать, что вы знаете всю математику, то она вам поможет. Это тоже самое, если вы знаете лингвистику, то она вам поможет в программировании. Если вы знаете что-нибудь, например, о строении человеческого глаза и вы делаете обработки рисунков, то вам это поможет. Естественно это вам поможет. Любые знания вам помогут. Любые знания — это хорошо, но это не обязательные знания. Вы сможете построить, не зная всей математики, модель перевода из одной координаты в другую и создание проекции. В любом случае, если вы можете, вам стоит продвигаться вперед. Каким-то образом изучать математику. Каким-то образом изучать другие науки, если это вам интересно, оно вам поможет. Если вы считаете, например, что вам нужно знать всю математику, чтобы программировать обычные веб-приложения скорее всего вы сами себя обманываете. Вам намного лучше потратить немножечко времени на изучение парадигм программирования, разных способов программирования, разных способов создания прототипов и так далее. Вам это поможет лучше.