ѕодпишитесь на наш Telegram-канал Ѕудьте в курсе последних новостей 👇 😉 ѕодписатьс€
ѕоддержим в трудное врем€ —пециальное предложение на техническую поддержку вашей »“ - инфраструктуры силами наших экспертов ѕодобрать тариф
ѕоставка оборудовани€ √аранти€ и помощь с настройкой. —кидка дл€ наших читателей по промокоду WIKIMERIONET  упить
»нтерфейс статистики Merion Mertics показывает ключевые диаграммы и графики по звонкам, а также историю звонков в формате, который легко поймет менеджер ѕопробовать бесплатно
¬недрение
офисной телефонии
Ўаг на пути к созданию доступных унифицированных коммуникаций в вашей компании ¬недрить
»нтеграци€ с CRM ѕомогаем навести пор€док с данными
и хранить их в единой экосистеме
ѕодключить
»“ Ѕезопасность ”мна€ информационна€ безопасность дл€ вашего бизнеса «аказать
ћерион Ќетворкс

12 минут чтени€

ѕочитайте предыдущую статью из цикла про установление и прекращение соединени€ в TCP.

UDP предоставл€ет приложени€м сервис дл€ обмена сообщени€ми. ¬ отличие от TCP, UDP не требует установлени€ соединени€ и не обеспечивает надежности, работы с окнами, переупор€дочивани€ полученных данных и сегментации больших фрагментов данных на нужный размер дл€ передачи. ќднако UDP предоставл€ет некоторые функции TCP, такие как передача данных и мультиплексирование с использованием номеров портов, и делает это с меньшим объемом служебных данных и меньшими затратами на обработку, чем TCP.

ѕередача данных UDP отличаетс€ от передачи данных TCP тем, что не выполн€етс€ переупор€дочевание или восстановление. ѕриложени€, использующие UDP, толерантны к потер€нным данным, или у них есть какой-то прикладной механизм дл€ восстановлени€ потер€нных данных. Ќапример, VoIP использует UDP, потому что, если голосовой пакет потер€н, к тому времени, когда потер€ может быть замечена и пакет будет повторно передан, произойдет слишком больша€ задержка, и голос будет неразборчивым.  роме того, запросы DNS используют UDP, потому что пользователь будет повтор€ть операцию, если разрешение DNS не удаетс€. ¬ качестве другого примера, сетева€ файлова€ система (NFS), приложение удаленной файловой системы, выполн€ет восстановление с помощью кода уровн€ приложени€, поэтому функции UDP приемлемы дл€ NFS.

Ќа рисунке 10 показан формат заголовка UDP. —амое главное, обратите внимание, что заголовок включает пол€ порта источника и назначени€ дл€ той же цели, что и TCP. ќднако UDP имеет только 8 байтов по сравнению с 20-байтовым заголовком TCP, показанным на рисунке 1-1. UDP требует более короткого заголовка, чем TCP, просто потому, что у UDP меньше работы.

«аголовок UDP

ѕриложени€ TCP / IP

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

¬семирна€ паутина (WWW) состоит из всех подключенных к »нтернету веб-серверов в мире, а также всех подключенных к »нтернету хостов с веб-браузерами. ¬еб-серверы, которые состо€т из программного обеспечени€ веб-сервера, запущенного на компьютере, хран€т информацию (в виде веб-страниц), котора€ может быть полезна дл€ разных людей. ¬еб-браузер, представл€ющий собой программное обеспечение, установленное на компьютере конечного пользовател€, предоставл€ет средства дл€ подключени€ к веб-серверу и отображени€ веб-страниц, хран€щихс€ на веб-сервере. ’от€ большинство людей используют термин "веб-браузер" или просто "браузер", веб-браузеры также называютс€ веб-клиентами, потому что они получают услугу с веб-сервера.

„тобы этот процесс работал, необходимо выполнить несколько определенных функций прикладного уровн€. ѕользователь должен каким-то образом идентифицировать сервер, конкретную веб-страницу и протокол, используемый дл€ получени€ данных с сервера.  лиент должен найти IP-адрес сервера на основе имени сервера, обычно использу€ DNS.  лиент должен запросить веб-страницу, котора€ на самом деле состоит из нескольких отдельных файлов, а сервер должен отправить файлы в веб-браузер. Ќаконец, дл€ приложений электронной коммерции (электронной коммерции) передача данных, особенно конфиденциальных финансовых данных, должна быть безопасной. ¬ следующих подразделах рассматриваетс€ кажда€ из этих функций.


”нифицированные идентификаторы ресурсов

„тобы браузер отображал веб-страницу, он должен идентифицировать сервер, на котором находитс€ эта веб-страница, а также другую информацию, котора€ идентифицирует конкретную веб-страницу. Ѕольшинство веб-серверов имеют множество веб-страниц. Ќапример, если вы используете веб-браузер дл€ просмотра www.cisco.com и щелкаете по этой веб-странице, вы увидите другую веб-страницу. ўелкните еще раз, и вы увидите другую веб-страницу. ¬ каждом случае щелчок идентифицирует IP-адрес сервера, а также конкретную веб-страницу, при этом детали в основном скрыты от вас. (Ёти интерактивные элементы на веб-странице, которые, в свою очередь, перевод€т вас на другую веб-страницу, называютс€ ссылками.)

ѕользователь браузера может идентифицировать веб-страницу, когда вы щелкаете что-либо на веб-странице или когда вы вводите унифицированный идентификатор ресурса (URI) в адресную область браузера. ќба варианта - щелчок по ссылке и ввод URI - относ€тс€ к URI, потому что, когда вы щелкаете ссылку на веб-странице, эта ссылка фактически ссылаетс€ на URI.

Ѕольшинство браузеров поддерживают какой-либо способ просмотра скрытого URI, на который ссылаетс€ ссылка. ¬ некоторых браузерах наведите указатель мыши на ссылку, щелкните правой кнопкой мыши и выберите "—войства". ¬о всплывающем окне должен отображатьс€ URI, на который будет направлен браузер, если вы нажмете эту ссылку.

¬ просторечии многие люди используют термины веб-адрес или аналогичные св€занные термины Universal Resource Locator (или Uniform Resource Locator [URL]) вместо URI, но URI действительно €вл€етс€ правильным формальным термином. ‘актически, URL-адрес используетс€ чаще, чем URI, уже много лет. ќднако IETF (группа, определ€юща€ TCP / IP) вместе с консорциумом W3C (W3.org, консорциум, разрабатывающий веб-стандарты) предприн€ли согласованные усили€ по стандартизации использовани€ URI в качестве общего термина.

— практической точки зрени€, URI, используемые дл€ подключени€ к веб-серверу, включают три ключевых компонента, как показано на рисунке 11. Ќа рисунке показаны формальные имена полей URI. „то еще более важно дл€ понимани€, обратите внимание, что текст перед :// определ€ет протокол, используемый дл€ подключени€ к серверу, текст между // и / идентифицирует сервер по имени, а текст после / идентифицирует веб-страницу.

—труктура URI, используемого дл€ получени€ веб-страницы

¬ этом случае используетс€ протокол передачи гипертекста (HTTP), им€ хоста - www.certskills.com, а им€ веб-страницы - blog.


ѕоиск веб-сервера с помощью DNS

’ост может использовать DNS дл€ обнаружени€ IP-адреса, соответствующего определенному имени хоста. ¬ URI обычно указываетс€ им€ сервера - им€, которое можно использовать дл€ динамического изучени€ IP-адреса, используемого этим же сервером. ¬еб-браузер не может отправить IP-пакет на им€ назначени€, но он может отправить пакет на IP-адрес назначени€. »так, прежде чем браузер сможет отправить пакет на веб-сервер, браузеру обычно необходимо преобразовать им€ внутри URI в соответствующий IP-адрес этого имени.

„тобы собрать воедино несколько концепций, на рисунке 12 показан процесс DNS, инициированный веб-браузером, а также некотора€ друга€ св€занна€ информаци€. — базовой точки зрени€ пользователь вводит URI (в данном случае http://www.exempel.com/go/learningnetwork), преобразует им€ www.exempel.com в правильный IP-адрес и начинает отправл€ть пакеты на веб сервер.

–азрешение DNS и запрос веб-страницы

Ўаги, показанные на рисунке, следующие:

  • ѕользователь вводит URI http://www.exempel.com/go/learningnetwork в адресную область браузера.
  •  лиент отправл€ет DNS-запрос на DNS-сервер. ќбычно клиент узнает IP-адрес DNS-сервера через DHCP. ќбратите внимание, что запрос DNS использует заголовок UDP с портом назначени€ 53-го известного порта DNS (см. таблицу 2 ранее в этой лекции, где приведен список попул€рных хорошо известных портов).
  • DNS-сервер отправл€ет ответ, в котором IP-адрес 198.133.219.25 указан как IP-адрес www.exemple.com. “акже обратите внимание, что ответ показывает IP-адрес назначени€ 64.100.1.1, IP-адрес клиента. ќн также показывает заголовок UDP с портом источника 53; исходный порт - 53, потому что данные получены или отправлены DNS-сервером.
  •  лиент начинает процесс установлени€ нового TCP-соединени€ с веб-сервером. ќбратите внимание, что IP-адрес назначени€ - это только что изученный IP-адрес веб-сервера. ѕакет включает заголовок TCP, потому что HTTP использует TCP. “акже обратите внимание, что TCP-порт назначени€ - 80, хорошо известный порт дл€ HTTP. Ќаконец, отображаетс€ бит SYN, как напоминание о том, что процесс установлени€ TCP-соединени€ начинаетс€ с сегмента TCP с включенным битом SYN (двоична€ 1).

ѕример на рисунке 12 показывает, что происходит, когда клиентский хост не знает IP-адрес, св€занный с именем хоста, но предпри€тие знает адрес. ќднако хосты могут кэшировать результаты DNS-запросов, так что какое-то врем€ клиенту не нужно запрашивать DNS дл€ разрешени€ имени. “акже DNS-сервер может кэшировать результаты предыдущих DNS-запросов; например, корпоративный DNS-сервер на рисунке 12 обычно не имеет настроенной информации об именах хостов в доменах за пределами этого предпри€ти€, поэтому в этом примере DNS-сервер кэшировал адрес, св€занный с именем хоста www.example.com.

 огда локальный DNS не знает адрес, св€занный с именем хоста, ему необходимо обратитьс€ за помощью. Ќа рисунке 13 показан пример с тем же клиентом, что и на рисунке 12. ¬ этом случае корпоративный DNS действует как рекурсивный DNS-сервер, отправл€€ повтор€ющиес€ DNS-сообщени€, чтобы идентифицировать авторитетный DNS-сервер.

–екурсивный поиск в DNS

Ўаги, показанные на рисунке, следующие:

  1.  лиент отправл€ет DNS-запрос дл€ www.exemple.com на известный ему DNS-сервер, который €вл€етс€ корпоративным DNS-сервером.
  2. (–екурсивный) корпоративный DNS-сервер еще не знает ответа, но он не отклон€ет DNS-запрос клиента. ¬место этого он следует повтор€ющемус€ (рекурсивному) процессу (показанному как шаги 2, 3 и 4), начина€ с DNS-запроса, отправленного на корневой DNS-сервер.  орень также не предоставл€ет адрес, но он предоставл€ет IP-адрес другого DNS-сервера, ответственного за домен верхнего уровн€ .com.
  3. –екурсивный корпоративный DNS-сервер отправл€ет следующий DNS-запрос DNS-серверу, полученному на предыдущем шаге, - на этот раз DNS-серверу TLD дл€ домена .com. Ётот DNS также не знает адреса, но знает DNS-сервер, который должен быть официальным DNS-сервером дл€ домена exemple.com, поэтому он предоставл€ет адрес этого DNS-сервера.
  4.  орпоративный DNS отправл€ет другой DNS-запрос DNS-серверу, адрес которого был получен на предыдущем шаге, снова запрашива€ разрешение имени www.exeple.com. Ётот DNS-сервер, официальный сервер exemple.com, предоставл€ет адрес.
  5.  орпоративный DNS-сервер возвращает DNS-ответ клиенту, предоставл€€ IP-адрес, запрошенный на шаге 1.

ѕередача файлов по HTTP

ѕосле того, как веб-клиент (браузер) создал TCP-соединение с веб-сервером, клиент может начать запрашивать веб-страницу с сервера. „аще всего дл€ передачи веб-страницы используетс€ протокол HTTP. ѕротокол прикладного уровн€ HTTP, определенный в RFC 7230, определ€ет, как файлы могут передаватьс€ между двум€ компьютерами. HTTP был специально создан дл€ передачи файлов между веб-серверами и веб-клиентами.

HTTP определ€ет несколько команд и ответов, из которых наиболее часто используетс€ запрос HTTP GET. „тобы получить файл с веб-сервера, клиент отправл€ет на сервер HTTP-запрос GET с указанием имени файла. ≈сли сервер решает отправить файл, он отправл€ет ответ HTTP GET с кодом возврата 200 (что означает ќ ) вместе с содержимым файла.

ƒл€ HTTP-запросов существует множество кодов возврата. Ќапример, если на сервере нет запрошенного файла, он выдает код возврата 404, что означает "файл не найден". Ѕольшинство веб-браузеров не показывают конкретные числовые коды возврата HTTP, вместо этого отобража€ ответ, такой как "страница не найдена", в ответ на получение кода возврата 404.

¬еб-страницы обычно состо€т из нескольких файлов, называемых объектами. Ѕольшинство веб-страниц содержат текст, а также несколько графических изображений, анимированную рекламу и, возможно, видео и звук.  аждый из этих компонентов хранитс€ как отдельный объект (файл) на веб-сервере. „тобы получить их все, веб-браузер получает первый файл. Ётот файл может (и обычно делает) включать ссылки на другие URI, поэтому браузер затем также запрашивает другие объекты. Ќа рисунке 14 показана обща€ иде€, когда браузер получает первый файл, а затем два других.

ћножественные запросы/ответы HTTP GET

¬ этом случае, после того, как веб-браузер получает первый файл - тот, который в URI называетс€ "/go/ccna", браузер читает и интерпретирует этот файл. ѕомимо частей веб-страницы, файл ссылаетс€ на два других файла, поэтому браузер выдает два дополнительных запроса HTTP GET. ќбратите внимание, что, даже если это не показано на рисунке, все эти команды проход€т через одно (или, возможно, несколько) TCP-соединение между клиентом и сервером. Ёто означает, что TCP обеспечит исправление ошибок, гарантиру€ доставку данных.


 ак принимающий хост определ€ет правильное принимающее приложение

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

¬ качестве примера рассмотрим хост A, показанный слева на рисунке 15. Ќа хосте открыто три разных окна веб-браузера, каждое из которых использует уникальный TCP-порт. Ќа хосте A также открыт почтовый клиент и окно чата, оба из которых используют TCP. » электронна€ почта, и чат-приложени€ используют уникальный номер TCP-порта на хосте A, как показано на рисунке.

ƒилемма: как хост A выбирает приложение, которое должно получать эти данные

¬ этой части лекции показано несколько примеров того, как протоколы транспортного уровн€ используют поле номера порта назначени€ в заголовке TCP или UDP дл€ идентификации принимающего приложени€. Ќапример, если значение TCP-порта назначени€ на рисунке 15 равно 49124, хост A будет знать, что данные предназначены дл€ первого из трех окон веб-браузера.

ѕрежде чем принимающий хост сможет проверить заголовок TCP или UDP и найти поле порта назначени€, он должен сначала обработать внешние заголовки в сообщении. ≈сли вход€щее сообщение представл€ет собой кадр Ethernet, который инкапсулирует пакет IPv4, заголовки выгл€д€т так, как показано на рисунке 16.

“ри ключевых пол€, с помощью которых можно определить следующий заголовок

ѕринимающему узлу необходимо просмотреть несколько полей, по одному на заголовок, чтобы идентифицировать следующий заголовок или поле в полученном сообщении. Ќапример, хост A использует сетевой адаптер Ethernet дл€ подключени€ к сети, поэтому полученное сообщение представл€ет собой кадр Ethernet. ѕоле типа Ethernet определ€ет тип заголовка, который следует за заголовком Ethernet - в данном случае со значением шестнадцатеричного значени€ 0800, заголовком IPv4.

«аголовок IPv4 имеет аналогичное поле, называемое полем протокола IP. ѕоле протокола IPv4 имеет стандартный список значений, которые идентифицируют следующий заголовок, с дес€тичным числом 6, используемым дл€ TCP, и дес€тичным числом 17, используемым дл€ UDP. ¬ этом случае значение 6 определ€ет заголовок TCP, следующий за заголовком IPv4.  ак только принимающий хост понимает, что заголовок TCP существует, он может обработать поле порта назначени€, чтобы определить, какой процесс локального приложени€ должен получить данные.

“еперь вас ждет материал про списки управлени€ доступом IPv4