Основы сетей и протоколов интернет

Стандарты (протокола) обмена информацией

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

• приёмы реализации по контролю;
• структура, по которой удалось построить базы данных и т. д.

Обратите внимание! Надёжность передачи информации повышается, если элементы достаточно сложные. Но скорость обработки из-за этого может уменьшаться

Какой протокол является базовым в Интернете — будет рассмотрено далее.

Важно! Практически каждый разработчик может использовать свои собственные решения. Но подобные системы доступны только ограниченному числу пользователей

Интеграция в сложные сетевые процессы обмена информацией становится недоступной.

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

Протоколы уровня 5 Session layer (Сеансовый уровень)

5-й уровень модели отвечает за поддержание сеанса связи, что позволяет приложениям взаимодействовать между собой длительное время. Сеансовый уровень управляет созданием/завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений. Синхронизация передачи обеспечивается помещением в поток данных контрольных точек, начиная с которых возобновляется процесс при нарушении взаимодействия.

• 9P — протокол распределённой файловой системы, разработанный как часть Plan 9
• NCP NetWare Core Protocol
• NFS — Network File System сетевая файловая система
• SMB Server Message Block
• SOCKS «SOCKet Secure»

Протоколы удаленного доступа

В состав операционных систем Windows входит служба Routing and Remote Access Service (RRAS), которая позволяет удаленным клиентам прозрачно подключаться к удаленному серверу. Служба RRAS поддерживает три протокола удаленного доступа:

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

Serial Line Internet Protocol (SLIP) — простой протокол, не располагающий средствами обнаружения ошибок, возникающих при передаче данных, и позволяющий использовать только протокол сетевого уровня IP, что делает его малоэффективным.

Asynchronous NetBEUI (AsyBEUI) — протокол службы удаленного доступа Microsoft, известный также как асинхронный NetBEUI. Применяется устаревшими клиентами удаленного доступа под управлением Windows NT, Windows 3.1, Windows for Workgroups, MS-DOS и LAN Manager.

Обзор OSI и TCP / IP

Сетевая архитектура OSI и TCP / IP — две известные эталонные модели сети. Модель OSI была разработана Международной организацией по стандартизации (ISO). В 1984 году она была принята в качестве эталонной модели. Модель OSI в основном определяет семиуровневый канал связи между системой. Эти уровни функционируют таким образом, чтобы предоставлять услуги более высокому уровню. Функции этих уровней кратко описаны ниже:

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

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

Сетевой уровень — отвечает за маршрутизацию пакетов данных в двух разных сетях с использованием IP (Интернет-протокола). Уровень канала данных направляет данные только в локальную сеть.

Транспортный уровень — транспортный уровень обеспечивает надежную и прозрачную передачу данных между сквозными устройствами. Помимо сегментации данных, транспортный уровень определяет тип услуги, которая должна быть предоставлена ​​вышележащим и нижним уровням.

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

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

Уровень приложения — он содержит различные службы связи, такие как передача файлов, SMTP, SSH, FTP и электронная почта. Он действует как интерфейс между пользовательскими приложениями, такими как браузеры, удаленный вход и т.д.

TCP / IP — это комбинация двух протоколов: протокола управления передачей и Интернет-протокола. Это основа современного Интернета. Целью TCP является обеспечение надежной передачи пакетов данных путем предоставления механизма контроля ошибок и проверки доставки пакетов данных в последовательности. TCP использует IP для разделения больших потоков данных на более мелкие пакеты и маршрутизации этих пакетов. Есть небольшие различия между уровнями модели OSI и модели TCP / IP. Например, уровни представления и сеанса объединены в его прикладной уровень в TCP / IP. Интернет-уровень соответствует сетевому уровню в модели OSI. Протокол IP является основной частью этого уровня. Кроме того, TCP / IP объединяет канал передачи данных OSI и физические уровни в один уровень, называемый уровнем доступа к сети.

Функциональность

Эталонная модель связи открытых систем устанавливает 7 уровней, на которых функционируют сетевые протоколы. OSI содержит набор протоколов для межсетевого взаимодействия и соединения между устройствами. Большинство сетевых протоколов распределяют задачи по разным уровням. Стек протоколов состоит из набора протоколов, которые выполняют задачи на каждом уровне и коллективно создают полностью функционирующую сеть. Уровни OSI следующие:

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

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

Локальная сеть

Абонент соединяется с использованием сети LAN Ethernet и при этом отсутствуют дополнительные подключения.

Просто компьютер подсоединяется одним из двух видов кабеля:

Необходимо отметить, что этот вид подключения имеет два следующих подвида:

1. Динамический – DHCP, который можно отнести к простым видам, так как у пользователя нет необходимости во вводе параметров настроек. Достаточно вставить провод в ПК и все нужные характеристики поступят в автоматическом режиме.
2. Статический – IP. В этом случае IP-адрес фиксированный и нужно вручную ввести параметры сети. Настройки прописаны в контрактных документах поставщика услуг связи с клиентом. Нужно указать следующие обязательные характеристики конфигурации: IP, маску подсети, ДНС и шлюз.

В компьютере на операционной системе Windows эти параметры вводятся в «Свойствах протокола Интернета» версии 4.

В этом меню можно легко изменить характеристики в соответствии с указанными в договоре с провайдером данными.

Примечание: Нередко в этих двух подвидах применяется привязка по адресу «МАС».

Сегодня кабельный тип подключения к интернету через WAN разъем пока занимает лидирующую позицию в рейтинге популярности среди пользователей.

Главное достоинство – высокая скорость при сравнительно низких ценах на тарифы обслуживающей компании.

Провайдеры подключают клиентов в этом случае следующими способами:

а) с использованием оптоволоконного кабеля;

б) через витую пару.

Протоколы уровня 3 Network layer (Сетевой уровень)

3-й уровень сетевой модели OSI, предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и заторов в сети. На этом уровне работает такое сетевое устройство, как маршрутизатор.

• CLNP Сетевой протокол без установки соединения
• EGP протокол внешнего шлюза (устарел)
• EIGRP Enhanced Interior Gateway Routing Protocol
• ICMP Internet Control Message Protocol
• IGMP Internet Group Management Protocol
• IGRP Interior Gateway Routing Protocol
• IPv4 Internet Protocol version 4
• IPv6 Internet Protocol version 6
• IPsec Internet Protocol Security
• IPX Internetwork Packet Exchange
• SCCP Signalling Connection Control Part
• AppleTalk DDP

TCP

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

Во времена расцвета RTMP/Flash, 12—15 лет назад, технологии на базе HTTP вообще не могли обеспечить полноценный стриминг, а только загрузку видео последовательными фрагментами с началом проигрывания после получения определенного количества фрагментов. Сегодняшние протоколы на базе HTTP, по сути, работают по тому же принципу, с той лишь разницей, что после множества оптимизаций это практически перестало быть заметно конечным пользователям. В хорошо отлаженных коммерческих сетях, использующих CDN в комбинации с небольшими кластерами доступа, видео доставляется с минимальными колебаниями качества. Поэтому современные технологии доставки видео на базе HTTP — HLS и MPEG-DASH — имеют полное право считаться стриминговыми.

Оптимизация проводилась по нескольким направлениям. Первое — сокращение цикла отправка/подтверждение за счет появления и оптимизации режима скользящего окна в протоколе TCP. Второе — введение адаптивной передачи. На уровне HTTP адаптивность реализована добавлением в клиентские устройства постоянного мониторинга качества видеопотока и возможности на лету запрашивать другой профиль видео. Этому способствует и совершенствование систем компрессии, в том числе появление новых ABR-кодеров, в которых профили видео формируются не по формальным параметрам потока, а по уровню качества картинки.

Последнее направление оптимизации, на котором сейчас сфокусированы усилия разработчиков, — сокращение времени от запроса услуги до начала воспроизведения видео. Этот вопрос сейчас решается в рамках стандарта CMAF, процесс подробно описан в статье
. Цель разработчиков — довести стартовую задержку до 3 секунд, что сопоставимо с задержкой в вещательных сетях. Сегодня она может составлять 40 секунд и более. Отметим, что проблема связана именно со спецификой стандарта HTTP. В RTMP/Flash стартовая задержка на уровне вещательных сетей обеспечивалась без дополнительных усилий.

Требования для протокола HTTPS

Для правильной работы протокола HTTPS на основе пакета NetX Web HTTP требуется, чтобы были установлены NetX Duo 5.10 или более поздней версии и NetX Secure TLS 5.11 или более поздней версии. Кроме того, должен быть создан экземпляр IP, для которого включено использование протокола TCP для работы с протоколом TLS. Сеанс TLS необходимо будет инициализировать с помощью соответствующих криптографических процедур и сертификата доверенного ЦС. Кроме того, потребуется выделить пространство для сертификатов, которые будут предоставляться удаленными узлами сервера во время подтверждения TLS. Этот процесс показан в демонстрационном файле в разделе «Пример небольшой системы HTTPS» главы 2.

Для HTTPS-клиента из пакета NetX Web HTTP больше нет дополнительных требований.

Но HTTPS-сервер из пакета NetX Web HTTP определяет еще несколько дополнительных требований. Во-первых, ему требуется полный доступ к известному TCP-порту 443 для обработки всех HTTPS-запросов клиента (как и в случае протокола HTTP без шифрования, приложение может изменить этот порт). Во-вторых, потребуется инициализировать сеанс TLS с помощью соответствующих криптографических процедур и сертификата удостоверения сервера (или общего ключа). HTTPS-сервер также разработан для работы с внедренной файловой системой FileX. Если система FileX недоступна, пользователь может перенести используемые разделы FileX в собственную среду. Использование FileX рассматривается в последующих разделах этого руководства.

Дополнительные сведения о параметрах конфигурации TLS см. в документации по NetX Secure.

Если не указано иное, все функции HTTP, описанные в этом документе, также относятся к протоколу HTTPS.

Виды протоколов

Существует несколько типов протоколов, которые создаются на основе конкретной функции. К ним относятся

1. Сетевые протоколы
2. Протоколы аутентификации
3. Безопасные протоколы
4. IP-протоколы голоса
5. Протоколы сетевых услуг
6. Протоколы многоадресной передачи
7. Протоколы управления сетью
8. Протоколы маршрутизации
9. Протоколы перевода имени
10. Протоколы управления хостами
11. Протоколы электронной почты
12. Протоколы каталога
13. Протоколы групп новостей
14. Протоколы Всемирной паутины
15. Передача файловых протоколов
16. Сетевые протоколы дозвона и удаленного доступа

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

Ссылки [ править ]

1. ОЭСР (2014-11-06). . Документы ОЭСР по цифровой экономике. DOI .
2. Чарльз М. Козиерок,
3. . www.eitc.org . Проверено 4 декабря 2020 .
4. Cerf, V .; Кан Р. (1974). . Транзакции IEEE по коммуникациям . 22 (5): 637–648. DOI . ISSN . Авторы хотели бы поблагодарить ряд коллег за полезные комментарии во время ранних обсуждений международных сетевых протоколов, особенно Р. Меткалфа, Р. Скантлбери, Д. Уолдена и Х. Циммермана; Д. Дэвис и Л. Пузин, конструктивно прокомментировавшие проблемы фрагментации и учета; и С. Крокер, который прокомментировал создание и разрушение ассоциаций.
5. ^ Стивен Коти (11.02.2011). .
6. Rob Thormeyer (2006-06-16). . GCN . Архивировано из на 2006-07-01.
7. Маллиган, Джефф. . О’Рейли . O’Reilly Media. Архивировано из 5 июля 2015 года . Проверено 4 июля 2015 года .
8. . www.iana.org . Проверено 25 июля 2019 .
9. RFC Историческая перспектива использования IP версии 9 . 1 апреля 1994 г. 
10. Росс Каллон (июнь 1992 г.). . DOI . RFC .
11. . hfhr.pl . Проверено 4 декабря 2020 .
12. RFC раздел 6.2
13. RFC
14. Rishabh, Ананд (2012). . С. Чанд Паблишинг. ISBN 978-81-219-4055-9.
15. Сиян, Каранджит. Inside TCP / IP , New Riders Publishing, 1997. ISBN 1-56205-714-6. 
16. Билл Cerveny (2011-07-25). . Arbor Networks . Проверено 10 сентября 2016 .
17. Паркер, Дон (2 ноября 2010 г.). . symantec.com . Symantec . Дата обращения 4 мая 2014 .
18. Фернандо Гонт (июль 2008 г.), , CPNI , заархивировано из 11 февраля 2010 г.
19. F. Gont (июль 2011 г.). . DOI . RFC .

Протокол IPv4 в эталонной модели сетевого взаимодействия OSI 7

Модель OSI описывает общие принципы взаимодействия сетевых устройств по иерархическому признаку, состоящему из семи уровней: физического, канального, сетевого, транспортного, сеансового, представления, прикладного.

Как видим, протокол интернета TCP/IPv4 относится к третьему по счету уровню, сетевому. На этом уровне модели OSI происходит формирование оптимальных маршрутов и путей передачи данных между устройствами с учетом нагрузки на узлы сети. Здесь же происходит процесс трансляции – преобразования логических сетевых адресов в физические и наоборот. На программно-физическом уровне эту задачу выполняют роутеры, установленные у провайдеров и в конечной точке подключения интернета. Каждый уровень взаимодействует с верхним и нижним в обе стороны, выполняя определенную функцию обработки и передачи данных. Так третий уровень модели OSI, получив закодированную информацию от четвертого, делит ее на фрагменты, добавляя служебную информацию, и передает на второй уровень. Либо наоборот, при поступлении данных со второго сегмента на сетевом уровне происходит обработка и объединение пакетов, их передача на вышестоящий по иерархической цепочке модели OSI.

Данную модель не зря называют идеальной, так как она описывает общие принципы сетевого взаимодействия. На момент ее появления весь мир уже активно использовал стек протоколов IPv4. Причем модель TCP/IP более точно и правильно описывает существующие процессы передачи данных по сетям взаимодействия.  

Любопытно. Разделением и присвоением IP-адресов занимаются четыре некоммерческих организации, разделенные по региональному принципу: RIPE NCC отвечает за Европу, ARIN действует на территории Америки, APNIC – в Азии и Тихоокеанском регионе, LACNIC – в Латинской Америке и на Карибах. Причем Россию отнесли в данной классификации к европейской RIPE. На самом деле полномочия выдачи ip-адресов делегированы локальным интернет-регистраторам (LIR), коими являются наиболее крупные провайдеры. Именно они работают с конечными пользователями в этом вопросе, в том числе финансово содержат вышестоящего регистратора за счет роялти.

Обратный вызов проверки подлинности HTTP

Как уже упоминалось, проверка подлинности HTTP является необязательной, то есть используется не при любой передаче данных через Интернет. Кроме того, проверка подлинности обычно зависит от конкретного ресурса. Один и тот же сервер может требовать проверку подлинности для доступа к некоторым ресурсам и не требовать для доступа к другим. Пакет HTTP-сервера Неткс позволяет приложению указать (с помощью вызова nx_web_http_server_create ) подпрограммы обратного вызова проверки подлинности, которая вызывается в начале обработки каждого HTTP-запроса клиента.

Эта подпрограмма обратного вызова предоставляет серверу NetX Web HTTP строковые значения имени пользователя, пароля и области, которые связаны с конкретным ресурсом, и возвращает необходимый тип проверки подлинности. Если для ресурса не требуется проверка подлинности, обратный вызов проверки подлинности должен возвращать значение NX_WEB_HTTP_DONT_AUTHENTICATE. Если для указанного ресурса требуется обычная проверка подлинности, эта подпрограмма должна возвращать NX_WEB_HTTP_BASIC_AUTHENTICATE. Наконец, если требуется дайджест-проверка подлинности MD5, подпрограмма обратного вызова должна возвращать NX_WEB_HTTP_DIGEST_AUTHENTICATE. Если ни для одного из ресурсов, предоставляемого HTTP-сервером, не требуется проверка подлинности, обратный вызов можно не указывать, передав в вызов для создания HTTP-сервера пустой указатель.

Формат подпрограммы обратного вызова проверки подлинности для приложения достаточно прост и определен ниже.

Входные параметры определяются следующим образом.

• request_type: указывает запрос HTTP-клиента, который может иметь одно из следующих значений:
  • NX_WEB_HTTP_SERVER_GET_REQUEST
  • NX_WEB_HTTP_SERVER_POST_REQUEST
  • NX_WEB_HTTP_SERVER_HEAD_REQUEST
  • NX_WEB_HTTP_SERVER_PUT_REQUEST
  • NX_WEB_HTTP_SERVER_DELETE_REQUEST
• resource: запрашиваемый ресурс.
• name: указатель на требуемое имя пользователя.
• password: указатель на требуемый пароль.
• realm: указатель на область определения приложений для данной проверки подлинности.

Возвращаемое значение подпрограммы проверки подлинности указывает, требуется ли проверка подлинности. Указатели на имя, пароль и область определения приложения не используются, если подпрограмма обратного вызова проверки подлинности возвращает значение NX_WEB_HTTP_DONT_AUTHENTICATE. В противном случае разработчик HTTP-сервера должен убедиться, что значения NX_WEB_HTTP_MAX_USERNAME и NX_WEB_HTTP_MAX_PASSWORD, определенные в файле nx_web_http_server.h, достаточно велики для размещения имени пользователя и пароля, указанных в обратном вызове проверки подлинности. По умолчанию оба значения равны 20 символам.

Взаимодействие по протоколу HTTP

Как упоминалось ранее, HTTP-сервер принимает запросы от клиентов через известный TCP-порт 80 (или порт 443 для HTTPS) . HTTP-клиенты могут использовать любой доступный TCP-порт для исходящих подключений. Общая последовательность событий HTTP выглядит следующим образом.

HTTP-запрос GET

1. Клиент отправляет запрос на TCP-подключение к порту 80 сервера (или 443 для HTTPS).
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос GET ресурс HTTP/1.1 и другие сведения заголовка.
4. Сервер создает сообщение HTTP/1.1 200 OK с дополнительной информацией, за которой следует содержимое запрошенного ресурса (при наличии).
5. Сервер отключается от клиента (протокол TLS завершает работу, если используется протокол HTTPS).
6. Клиент отключается от сокета (протокол TLS завершает работу после оповещения об отключении от сервера).

HTTP-запрос PUT

1. Клиент отправляет запрос на TCP-подключение к порту 80 (или 443) сервера.
2. Если используется протокол HTTPS, то после установления TCP-подключения следует подтверждение TLS, чтобы проверить подлинность сервера и установить безопасный канал.
3. Клиент отправляет запрос PUT HTTP/1.1 и другие сведения заголовка, за которыми следует содержимое ресурса.
4. Сервер создает сообщение «HTTP/1.1 200 OK» с дополнительной информацией, за которой следует содержимое запрошенного ресурса.
5. Сервер разрывает подключение.
6. Клиент разрывает соединение.

Примечание

Как уже упоминалось, HTTP-сервер может изменить стандартный порт подключения (80 или 443) на любой другой порт с помощью службы nx_web_http_client_set_connect_port() , что позволяет веб-серверам, использующим альтернативные порты, подключаться к клиентам.

Некоторые порты могут использоваться для чего угодно, в то время как другие имеют давно установленные цели

Протокол управления передачей (TCP) использует набор каналов связи, называемых портами, для управления системным обменом сообщениями между несколькими различными приложениями, работающими на одном физическом устройстве. В отличие от физических портов на компьютерах, таких как USB-порты или Ethernet-порты, TCP-порты являются виртуально программируемыми записями, пронумерованными от 0 до 65535.

Большинство портов TCP являются каналами общего назначения, которые могут вызываться при необходимости, но в остальном бездействуют. Однако некоторые порты с меньшими номерами предназначены для определенных приложений. Хотя многие TCP-порты принадлежат приложениям, которые больше не существуют, некоторые из них очень популярны.

TCP порт 0

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

TCP-порты 20 и 21

FTP-серверы используют TCP-порт 21 для управления своей стороной сеансов FTP. Сервер прослушивает команды FTP, поступающие на этот порт, и отвечает соответствующим образом. В активном режиме FTP сервер дополнительно использует порт 20 для инициирования передачи данных обратно клиенту FTP.

TCP-порт 22

Secure Shell использует порт 22. Серверы SSH прослушивают на этом порту входящие запросы на вход от удаленных клиентов. Из-за характера такого использования порт 22 любого общедоступного сервера часто проверяется сетевыми хакерами и является предметом тщательного изучения в сообществе по сетевой безопасности. Некоторые защитники рекомендуют администраторам перенести установку SSH на другой порт, чтобы избежать этих атак, в то время как другие утверждают, что это лишь незначительный обходной путь.

TCP-порт 23

Порт 23 управляет telnet , текстовой системой для входа в удаленные системы. Хотя современные подходы к удаленному доступу основаны на Secure Shell на порте 22, порт 23 остается зарезервированным для более старого и менее безопасного приложения telnet.

TCP-порты 25, 110 и 143

На принимающей стороне порт 110 управляет протоколом почтовой связи версии 3, а порт 143 выделен для протокола доступа к почте через Интернет. POP3 и IMAP контролируют поток электронной почты с сервера вашего провайдера на ваш почтовый ящик.

Безопасные версии SMTP и IMAP различаются в зависимости от конфигурации, но порты 465 и 587 являются общими.

UDP порты 67 и 68

Серверы протокола динамической конфигурации хоста используют UDP-порт 67 для прослушивания запросов, в то время как клиенты DHCP обмениваются данными через UDP-порт 68.

TCP-порты 80 и 443

Возможно, самый известный порт в Интернете – TCP-порт 80 – это значение по умолчанию, которое веб-серверы HyperText Transfer Protocol прослушивают для запросов веб-браузера.

Порт 443 по умолчанию для безопасного HTTP.

UDP-порты 161 и 162

По умолчанию простой протокол управления сетью использует UDP-порт 161 для отправки и получения запросов в управляемой сети. Он использует UDP-порт 162 по умолчанию для получения прерываний SNMP от управляемых устройств.

TCP-порт 194

Несмотря на то, что такие инструменты, как приложения для обмена сообщениями на смартфонах, такие как Slack и Microsoft Teams, стали использовать Internet Relay Chat, IRC по-прежнему пользуется популярностью среди людей по всему миру. По умолчанию IRC использует порт 194.

Порты выше 1023

Номера портов TCP и UDP между 1024 и 49151 называются зарегистрированными портами . Управление по присвоению номеров в Интернете ведет список услуг, использующих эти порты, чтобы минимизировать конфликты при использовании.

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

Стандарты (протокола) обмена информацией

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

• приёмы реализации по контролю;
• структура, по которой удалось построить базы данных и т. д.

Обратите внимание! Надёжность передачи информации повышается, если элементы достаточно сложные. Но скорость обработки из-за этого может уменьшаться

Какой протокол является базовым в Интернете — будет рассмотрено далее.

Важно! Практически каждый разработчик может использовать свои собственные решения. Но подобные системы доступны только ограниченному числу пользователей

Интеграция в сложные сетевые процессы обмена информацией становится недоступной.

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

Уровень приложения

Прикладной уровень включает в себя протоколы , используемые в большинстве приложений для предоставления услуг пользователя или обмена данных приложений за сетевые соединения , установленных протоколами нижнего уровня. Это может включать некоторые базовые службы поддержки сети, такие как протоколы маршрутизации и конфигурация хоста. Примеры протоколов прикладного уровня включают протокол передачи гипертекста (HTTP), протокол передачи файлов (FTP), простой протокол передачи почты (SMTP) и протокол динамической конфигурации хоста (DHCP). Данные, закодированные в соответствии с протоколами прикладного уровня, инкапсулируются в единицы протокола транспортного уровня (такие как потоки TCP или дейтаграммы UDP), которые, в свою очередь, используют протоколы нижнего уровня для фактической передачи данных.

Модель TCP / IP не учитывает специфику форматирования и представления данных и не определяет дополнительные уровни между прикладным и транспортным уровнями, как в модели OSI (уровни представления и сеанса). Согласно модели TCP / IP, такие функции являются областью библиотек и интерфейсов прикладного программирования . Прикладной уровень в модели TCP / IP часто сравнивают с комбинацией пятого (сеансовый), шестого (представление) и седьмого (приложения) уровней модели OSI.

Протоколы прикладного уровня часто связаны с конкретными клиент-серверными приложениями, а общие службы имеют хорошо известные номера портов, зарезервированные Internet Assigned Numbers Authority (IANA). Например, протокол передачи гипертекста использует порт сервера 80, а Telnet использует порт сервера 23. Клиенты, подключающиеся к службе, обычно используют эфемерные порты , т. Е. Номера портов , назначаемые только на время транзакции случайным образом или из определенного диапазона, настроенного в заявление.

На уровне приложений модель TCP / IP различает пользовательские протоколы и протоколы поддержки . Протоколы поддержки предоставляют услуги системе сетевой инфраструктуры. Пользовательские протоколы используются для реальных пользовательских приложений. Например, FTP — это протокол пользователя, а DNS — протокол поддержки.

Хотя приложения обычно осведомлены о ключевых качествах соединения транспортного уровня, таких как IP-адреса конечных точек и номера портов, протоколы прикладного уровня обычно рассматривают протоколы транспортного уровня (и более низких уровней) как черные ящики, которые обеспечивают стабильное сетевое соединение, через которое осуществляется обмен данными. . Транспортный уровень и уровни нижнего уровня не заботятся о специфике протоколов прикладного уровня. Маршрутизаторы и коммутаторы обычно не проверяют инкапсулированный трафик, а просто предоставляют для него канал. Однако некоторые брандмауэры и приложения для регулирования полосы пропускания используют глубокую проверку пакетов для интерпретации данных приложения. Примером может служить протокол резервирования ресурсов (RSVP). Также иногда необходимо учитывать полезную нагрузку приложения.

Настройка резервирования пространства имен

Резервирование пространства имен назначает права на часть пространства имен URL-адреса HTTP определенной группе пользователей. Резервирование предоставляет этим пользователям право создавать службы, которые ожидают передачи данных в указанной части пространства имен. Резервирования — это префиксы URL-адресов. Это означает, что резервирование охватывает все вложенные пути пути резервирования. Резервирования пространства имен позволяют использовать подстановочные знаки двумя способами. В документации по API HTTP-сервера описывается Порядок разрешения между утверждениями пространства имен, которые используют подстановочные знаки.

Запущенное приложение может создать аналогичный запрос для добавления регистраций пространства имен. Регистрации и резервирования конкурируют за части пространства имен. Резервирование может иметь приоритет над регистрацией в соответствии с порядком разрешения, указанным в порядке разрешения между утверждениями пространства имен, которые используют подстановочные знаки. В этом случае резервирование не позволяет запущенному приложению получать запросы.

В следующем примере используется средство Netsh.exe:

Эта команда добавляет резервирование URL-адресов для указанного пространства имен URL-адреса для учетной записи DOMAIN\user. Для получения дополнительных сведений об использовании команды netsh введите в командной строке и нажмите клавишу ВВОД.