По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда речь заходит о веб-фреймворках на Python, то можно смело сказать, что Django и Flask – это два самых популярных.
Мы уже писали про фреймворк Django, так что теперь давайте посмотрим на его младшего (но не менее мощного) брата.
Итак, что же такое Flask? Flask – это микофреймворк для разработчиков, который позволяет им быстро и просто создавать и масштабировать веб-приложения. Выяснение того, как они это делают, займет чуть больше времени.
Для начала мы кратко рассмотрим основные способы использования Python веб-разработчиками в цифровых системах, а затем поговорим о самом микрофреймворке Flask.
А далее мы рассмотрим некоторые плюсы и минусы его использования и сравним Flask с его более известным собратом Django.
Как разработчики используют Python?
Язык программирования Python – это область деятельности не только для ученых и аналитиков данных. Его гибкость – одна из ключевых причин, по которой огромное количество веб-разработчиков изучают его и профессионально используют во всех видах проектов.
Преимущественно они используют его для создания мощных серверных веб-приложений, которые могут быстро обрабатывать данные. Они также используют его для таких областей, как сбор данных, машинное обучение и искусственный интеллект.
Разработчикам нравится простота использования и эффективность Python, поскольку он позволяет создавать быстро загружаемые и безопасные веб-сайты. Еще до этапа развертывания – Python идеально подходит для проектирования и тестирования прототипов, позволяя выполнять итерации и разработку, быстро достигая финального этапа разработки готового продукта.
Если вам нужны более конкретные примеры, то мы нашли некоторые из наиболее известных примеров использования Python от таких компаний, как Netflix, Uber и Spotify.
На самом деле есть очень много преимуществ изучения и использования Python для веб-разработки. Когда речь заходит о разработке веб-приложения на Python, то тут есть много разных вариантов, но наверху этого списка находятся именно Django и Flask.
А сейчас давайте продолжим и узнаем поподробнее о втором – о Flask.
Что такое Flask?
Flask входит в топ-20 самых востребованных веб-фреймворков согласно опросу Stack Overflow 2022 года – неплохо для микрофреймворка.
Откуда такое признание? В основном от того, что для своей работы он не полагается на какие-либо другие инструменты или программные библиотеки. Flask, которому уже немного больше 11 лет, примерно того же возраста, что и более известный веб-фреймворк Django.
Из-за того, что язык Python был назван в честь комедийной труппы Monty Python, то и весь проект Flask изначально задумывался как первоапрельская шутка. Однако Армин Ронахер, создатель, понял, что то, что задумывалось как шутка, может действительно превратиться во что-то реально полезное – подходящую основу для создания веб-приложений. Его название – это обыгрывание названия более раннего веб-фреймворка Bottle.
Flask – это то, что известно как фреймворк WSGI. Оно произносится как «виски» и обозначает Web Server Gateway Interface (интерфейс шлюза веб-сервера). По сути, это способ для веб-серверов передавать запросы веб-приложениям или платформам. Flask использует для работы внешнюю библиотеку WSGI, а также шаблонизатор Jinja2.
Это готовый фреймворк, что означает, что вы можете без проблем перейти на работу с ним – это одно из его основных преимуществ.
Итак, теперь мы знаем, что такое Flask, а значит, пришло время посмотреть, как его используют разработчики.
Преимущества и недостатки Flask
Преимущества Flask:
Масштабируемость
Размер – это все, и статус Flask в качестве микрофреймворка означает, что вы можете использовать его для невероятно быстрого развития технического проекта, такого как веб-приложения. Если вы планируете создать приложение, которое будет начинаться с малого формата, но при этом будет иметь потенциал быстрого роста в том числе и в тех направлениях, которые вы еще не полностью проработали, то Flask – идеальный выбор для вас. Его простота использования и малое количество зависимостей позволяют ему работать бесперебойно даже при масштабировании.
Гибкость
Это основная функция Flask и одно из его самых больших преимуществ. Перефразируя один из принципов дзэн Python, простота лучше сложности, так как ее можно легко перераспределить и переместить.
Это полезно не только с точки зрения того, что ваш проект можно легко продвигать в другом направлении, но это также гарантирует, что структура проекта не рухнет при изменении какой-либо ее части. Минималистичность Flask и его способность разрабатывать небольшие веб-приложения означают, что он даже более гибкий, чем Django.
Легкость в использовании
Как и в случае с Django, способность быстро ориентироваться помогает веб-разработчикам сосредотачиваться только на написании кода, а не на попытках разобраться, как и что работает. Микрофреймворк прост для понимания, и не только экономит веб-разработчикам их время и усилия, но и позволяет им максимально контролировать их код и все, что только можно.
Простота
Когда этот термин используется в отношении какого-либо инструмента или фреймворка, то речь идет о его конструкции – есть несколько составных частей, которые необходимо собирать и собирать повторно, и он не зависит от большого количества программных расширений для функционирования. Такая конструкция дает веб-разработчикам определенный уровень контроля.
Flask также поддерживает модульное программирование, в котором его функциональность можно разделить на несколько взаимозаменяемых модулей. Каждый модуль действует как независимый строительный блок, который может выполнять какую-то часть функциональных возможностей. В общем это означает, что все составные части структуры являются гибкими, подвижными и тестируемыми сами по себе.
Документация
Согласно теории создателя о том, что «хороший план разработки документации на самом деле заставляет вас писать документацию», пользователи Flask могут найти большое количество структурированных примеров и рекомендаций. Это создает хорошие условия для того, чтобы разработчики использовали фреймворк, так как они могут легко ознакомиться с различными аспектами и возможностями инструмента. Документацию Flask можно найти на их официальном сайте.
Недостатки Flask:
Небольшое количество инструментов
Конечно же есть и некоторые недостатки в простоте этого микрофреймворка. Главный из них заключается в том, что, в отличие от Django, в Flask нет такого большого количества различных инструментов. Это значит, что разработчикам придется вручную добавлять программные расширения, такие как библиотеки. А при добавлении большого количества таких расширений приложение может начать тормозить из-за большого количества запросов.
Трудность ознакомления с большими приложениями
Из-за того, что разработка приложения с использованием Flask может иметь множество различных тонкостей, веб-разработчик, пришедший к проекту на полпути, может столкнуться с трудностями во время ознакомления с тем, как оно было разработано. Модульная структура микрофреймворка, о которой мы упоминали ранее, может усложнять работу программистов, которым нужно ознакомиться с каждой составной частью.
Затраты на техническое обслуживание
Поскольку Flask является гибким с точки зрения использования технологий, с которыми он может взаимодействовать, то довольно часто компании, использующие Flask, несут дополнительные расходы на поддержку этих технологий. Например, если технология, взаимодействующая с вашим приложением, устареет или перестанет существовать, то компании придется искать новую технологию, которая будет также совместима с вашим приложением. Чем сложнее приложение, тем выше потенциальные затраты на обслуживание и внедрение.
Flask vs Django
Скорее всего, вы уже поняли, что эти двое много чем похожи. Все чаще они упоминаются в одном ряду. И Flask, и Django предназначены для того, чтобы разработчикам было легче начать работу с проектами, а также легче масштабировать их в приложения. Они оба просты в развертывании, оба очень просто проводят модульное тестирование и идут вместе с документацией.
Предоставление веб-разработчикам возможности более продуктивно писать код именно на Python, а не на других языках, во многом объясняет их популярность. Опрос Python-разработчиков, проведенный JetBrains в 2021 году, показал, что Django и Flask находятся в тупиковой ситуации с точки зрения популярности. Так чем же они отличаются?
Применение
Полезный совет, позволяющий понять, что и когда использовать, заключается в следующем: Django подходит для больших проектов и для небольших, которые так и останутся ими, а Flask – для небольших приложений, у которых есть перспектива стать больше.
Django – это монолит, что значит, что он старается быть полноценным универсальным механизмом для вас и ваших потребностей. Из-за такой своей требовательности это может оказаться не очень оптимально для некоторых разработчиков. В качестве альтернативы, как микрофреймворк, Flask может легко и гибко взаимодействовать с другими инструментами, даже с теми, с которыми вы изначально не планировали работать. С Django вам необходимо будет определить масштаб проекта заранее.
Общественная поддержка
Flask имеет гораздо меньшее и менее сплоченное сообщество пользователей в сравнении с Django, поэтому, если у вас возник тот или иной вопрос, то у вас гораздо меньше шансов найти ответ на форуме, так как меньше активных пользователей, которые обращаются за помощью.
Простой способ проверить - зайти на главный веб-форум Stack Overflow. Проверка форума показала, что против 46 966 вопросов с тегом Flask выступают 273 775 вопросов с тегом Django. Это ни в коем случае не означает, что сообщество Flask полностью мертво. Это лишь значит, что это немного более молодой фреймворк, а, соответственно, и его сообщество.
Безопасность
В то время как Django может похвастаться отличными функциями аутентификации и входа в систему для пользователей, Flask не может себе такого позволить. Тем не менее, микрофреймворк поддерживает безопасные cookie-файлы на клиентской стороне. В целом, Django считается «полностью укомплектованным» фреймворком и более безопасным.
Доступ к базе данных
Еще одно ключевое отличие для разработчиков, работающих с базами данных, - насколько Django и Flask поддерживают к ним доступ, в основном объектно-реляционное управление (ORM - Object Relational Management). Объектно-реляционное управление позволяет API легко получать доступ к данным без необходимости писать SQL-команды.
Django поддерживает ORM, что позволяет писать сложные запросы. А вот Flask-разработчикам, к сожалению, придется писать все свои SQL-операторы самостоятельно, что, конечно, может добавить лишней работы.
Стоимость
Flask более гибкий из-за его относительной поворотливости, тогда как Django в целом считается более дешевым в обслуживании с точки зрения эксплуатационных расходов. Мало того, что для работы с Flask требуется дополнительная поддержка из-за ряда технологий, с которыми он работает, так и разработчиков, имеющих опыт работы с ним, найти сложнее, чем тех, кто имел дело с Django.
Если говорить о сравнении и принятии решения как предприятием, так и технической командой, что использовать и для какого проекта, то это действительно зависит от специфики и масштаба самого проекта. Но если вы веб-разработчик, который работает с Python, и пытается решить, с каким фреймворком ему лучше познакомиться, то почему бы не сразу с обоими?
Знания и опыт развертывания проектов с использованием как Django, так и Flask могут значительно повысить ценность ваших навыков (и потенциально повысить вашу зарплату разработчика полного цикла).
Итоги
Итак, вот оно: введение в микрофреймворк Flask, включая то, как его использовать, а также плюсы и минусы. Крайне важно, чтобы технические команды знали и понимали, для каких проектов лучше всего подходит Flask, а какие проекты – это работа для более крупного веб-фреймворка Django. В любом случае, любой веб-разработчик, работающий с Python, должен знать, как работать хотя бы с одним из этих двух популярных инструментов.
Сегодня, в этой статье, вы узнаете, как формируются соседства BGP внутри автономной системы, между автономными системами и даже между маршрутизаторами, которые не связаны напрямую. Кроме того, мы рассмотрим аутентификацию BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Видео: Основы BGP за 7 минут
BGP-пиринг
Учитывая, что BGP является протоколом маршрутизации AS-to-AS, вполне логично, что внешний BGP (т.е. eBGP) является ключевым компонентом в его операциях. Самое первое, что нам нужно учитывать при работе с eBGP, - это то, что стандарты построены таким образом, что требуется прямое подключение. Это требование конечно можно обойти, но этот момент необходимо рассмотреть. Поскольку предполагается прямое соединение, протокол BGP выполняет две вещи:
Он будет проверять значение времени жизни (TTL), и что значение time-to-live установлено в 1. Это означает прямую связь между одноранговыми узлами EBGP.
Осуществляется проверка, что два устройства находятся в одной подсети.
Еще один важный момент рассмотрения пирингов eBGP - это TCP-порты, которые будут использоваться. Это особенно важно для конфигураций брандмауэров, которые защищают автономные системы. Первый спикер BGP, который инициирует изменения состояния, приходящие по мере формирования соседства, будет получать трафик из случайного TCP-порта, а конечным портом будет TCP-порт 179. Отвечающий спикер BGP будет получать трафик с TCP-порта 179, а порт назначения будет случайным портом. Брандмауэры должны быть перенастроены с учетом изменений в коммуникации. На основе этих изменений спикер BGP инициирует сеанс, и это, вносит изменения для будущего сеанса. Некоторые администраторы даже создают механизмы для обеспечения того, чтобы сформированные пиринги были получены из известного направления.
А как насчет IPv6? Ну, как было сказано ранее в предыдущей статье, BGP очень гибок и работает с IPv6, поскольку протокол был изначально спроектирован с учетом IPv6. Вы можете формировать пиринги eBGP (и iBGP) с использованием IPv6- адресации, даже если вы используются префиксы IPv4 для информации о достижимости сетевого уровня.
Чтобы сформировать в нашей сети пиринг eBGP, необходимо выполнить следующие действия:
Запустите процесс маршрутизации для BGP и укажите локальный AS (router bgp local_as_number).
Предоставить удаленному спикеру eBGP IP- адрес и удаленному AS номер (neighbor ip-_of_neighbor remote-as remote_as_number).
Пример 1 демонстрирует конфигурацию и проверку EBGP пиринга между маршрутизаторами TPA1 и ATL.
Пример 1: Настройка пиринга eBGP
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 30.30.30.1 remote-as 110
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 30.30.30.2 remote-as 220
TPA1(config-router)#end
TPA1#
TPAl#show ip bgp summary
BGP router identifier 30.30.30.1, local AS number 110
BGP table version is 4, main routing table version 4
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 320 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
30.30.30.2 4 220 413 414 4 0 0 06:12:46 1
TPA1#
Примечание: чтобы облегчить понимание BGP, вы можете включить функцию debug ip bgp, при настройке пиринга. Это позволит увидеть переходные состояния в соседстве. Кроме того, чтобы получить больше информации о соседствах, вы можете использовать команду show ip bgp neighbors.
Создание eBGP пиринга, на основе IPv6, выполняется также очень просто, как и на основе IPv4. Единственное изменение заключается в том, что мы заменяем адресацию в IPv4 на IPv6 и активируем соседство. Семейства адресов в маршрутизаторах Cisco для BGP позволяют запускать множество различных схем информирования о достижимости сетевого уровня (NLRI) в рамках одного и того же общего процесса BGP. Пример 2 демонстрирует подход к пирингу IPv6.
Пример 2: конфигурация пиринга EBGP с использованием IPv6
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 2201:1212:1212::2 remote-as 110
ATL(config-router-af)#neighbor 2201:1212:1212::2 activate
ATL(config-router-af)#end
ATL#
iBGP-пиринг
Если вы внимательно посмотрите на топологию, вы можете заметить, что что-то выглядит необычно. Видно, что есть iBGP-пиринг. Почему существует пиринг iBGP, созданный между TPA1 и TPA2? Это выглядит совершенно неуместно. В данном случае, как говорится, внешность может быть обманчива. Главное, что вы должны усвоить относительно BGP, является тот факт, что существует нечто, называемое правилом разделения горизонта (Split Horizon Rule) iBGP. Это правило гласит, что ни один спикер iBGP не может принять обновление и затем отправить это же обновление другому узлу iBGP. Так же в требовании говориться, о полном объединении наших спикеров iBGP для обеспечения полной осведомленности о префиксах.
Еще одним важным аспектом, связанным с iBGP, является избыточность. Мы хотим установить несколько физических связей между устройствами, но что произойдет, если связь, используемая для BGP, прервется? Как мы автоматически переключимся к пирингу, используя альтернативное подключение?
Простой способ решить эту проблему заключается в реализации loopback-адресов и использовании этих адресов для однорангового соединения. Это то, что мы часто делаем с нашими пирингами BGP, и это может потребовать, дополнительной настройки при использовании подключения к провайдеру. Например, в Cisco мы должны специально указать, что источником пиринга является loopback IP- адрес.
Примечание: еще одним важным аспектом при пиринге между петлевыми адресами в iBGP является то, что loopback-адреса фактически доступны между спикерами BGP. Именно здесь очень удобно использовать протокол внутреннего шлюза (IGP), такой как OSPF или EIGRP.
Пример 3 показывает конфигурацию пиринга iBGP между устройствами TPA и TPA1. Обратите внимание, что мы используем петлевой подход в том случае, если мы хотим добавить избыточные связи между устройствами в будущем.
Пример 3: Настройка пиринга iBGP
TPA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA(config)router bgp 110
TPA(config-router)#neighbor 8.8.8.8 remote-as 110
TPA(config-router)#neighbor 8.8.8.8 update-source loopbackO
TPA(config-router)#end
TPA#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#router bgp 110
TPA1(config-router)#neighbor 5.5.5.5 remote-as 110
TPA1(config-router)#neighbor 5.5.5.5 update-source loopbackO
TPA1(config-router)#end
TPA1#
eBGP Multihop
В разделе eBGP-пиринг этой статьи, обсуждалось, что ваши соседи будут связаны напрямую. В разделе iBGP мы обсуждали преимущество пиринга между loopback для избыточности. Теперь пришло время ответить на вопрос: Что делать, если ваши спикеры eBGP не подключены напрямую? На самом деле, если мы хотим пиринговать между loopback с eBGP, чтобы воспользоваться потенциальной избыточностью. Как сделать это, поскольку интерфейсы loopback не связаны напрямую друг с другом?
BGP решает эту проблему с помощью опции eBGP multihop. С помощью настройки eBGP multihop вы указываете максимальное количество допустимых прыжков. Это пропускает проверку BGP для TTL на значение равное 1, рассмотренное ранее в этой статье. Но как насчет требования прямого подключения? BGP отключает эту проверку в фоновом режиме автоматически, при использовании функции eBGP multihop. Пример 4 демонстрирует настройку eBGP multihop между TPA1 и ATL. Здесь нужен multihop, потому что мы настраиваем пиринг между loopback устройств.
Пример 4: eBGP Multihop
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
TPA1(config-router)#end
TPA1#
BGP аутентификация
Большинство организаций сегодня добавляют аутентификацию в свои настройки BGP, чтобы защитить их от различного рода атак. По общему признанию, аутентификацию немного сложнее настроить на BGP, чем с на других протоколах маршрутизации, поскольку конфигурация — пирингов- это ручной процесс, который должен выполнен на обоих устройствах. Даже с учетом вышесказанного, аутентификация устройств (eBGP или даже iBGP) - отличная идея.
В Cisco настройка аутентификации осуществляется просто. Необходимо задать пароль (т.е. общий секрет) на каждое устройство, настроенное для пиринга. Обязательно усвойте, что этот пароль будет отображаться в открытом виде (по умолчанию) внутри вашей сети. Можно использовать команду service password-encryption для выполнения по крайней мере простого шифрования тех незашифрованных текстовых паролей, которые появляются в конфигурации маршрутизатора.
Аутентификация с шифрованием Message Digest 5 (MD5) – это результат простого задания пароля на устройствах. Пример 5 отображает аутентификацию, добавленную в конфигурации для TPA1 и ATL.
Пример 5. Настройка аутентификации для BGP-пиринга
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#neighbor 8.8.8.8 password MySuperSecret121
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
ATL(config-router)#neighbor 7.7.7.7 password MySuperSecret121
TPA1(config-router)#end
TPA1#
Почитайте предыдущую статью из цикла про установление и прекращение соединения в 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 меньше работы.
Приложения 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. Что еще более важно для понимания, обратите внимание, что текст перед :// определяет протокол, используемый для подключения к серверу, текст между // и / идентифицирует сервер по имени, а текст после / идентифицирует веб-страницу.
В этом случае используется протокол передачи гипертекста (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-адрес и начинает отправлять пакеты на веб сервер.
Шаги, показанные на рисунке, следующие:
Пользователь вводит 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-запрос для www.exemple.com на известный ему DNS-сервер, который является корпоративным DNS-сервером.
(Рекурсивный) корпоративный DNS-сервер еще не знает ответа, но он не отклоняет DNS-запрос клиента. Вместо этого он следует повторяющемуся (рекурсивному) процессу (показанному как шаги 2, 3 и 4), начиная с DNS-запроса, отправленного на корневой DNS-сервер. Корень также не предоставляет адрес, но он предоставляет IP-адрес другого DNS-сервера, ответственного за домен верхнего уровня .com.
Рекурсивный корпоративный DNS-сервер отправляет следующий DNS-запрос DNS-серверу, полученному на предыдущем шаге, - на этот раз DNS-серверу TLD для домена .com. Этот DNS также не знает адреса, но знает DNS-сервер, который должен быть официальным DNS-сервером для домена exemple.com, поэтому он предоставляет адрес этого DNS-сервера.
Корпоративный DNS отправляет другой DNS-запрос DNS-серверу, адрес которого был получен на предыдущем шаге, снова запрашивая разрешение имени www.exeple.com. Этот DNS-сервер, официальный сервер exemple.com, предоставляет адрес.
Корпоративный 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 показана общая идея, когда браузер получает первый файл, а затем два других.
В этом случае, после того, как веб-браузер получает первый файл - тот, который в URI называется "/go/ccna", браузер читает и интерпретирует этот файл. Помимо частей веб-страницы, файл ссылается на два других файла, поэтому браузер выдает два дополнительных запроса HTTP GET. Обратите внимание, что, даже если это не показано на рисунке, все эти команды проходят через одно (или, возможно, несколько) TCP-соединение между клиентом и сервером. Это означает, что TCP обеспечит исправление ошибок, гарантируя доставку данных.
Как принимающий хост определяет правильное принимающее приложение
Эта лекция завершается обсуждением процесса, с помощью которого хост при получении любого сообщения по любой сети может решить, какая из множества своих прикладных программ должна обрабатывать полученные данные.
В качестве примера рассмотрим хост A, показанный слева на рисунке 15. На хосте открыто три разных окна веб-браузера, каждое из которых использует уникальный TCP-порт. На хосте A также открыт почтовый клиент и окно чата, оба из которых используют TCP. И электронная почта, и чат-приложения используют уникальный номер TCP-порта на хосте 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