Руководство по выживанию веб-девелопера основы DNS


Оглавление (нажмите, чтобы открыть):

Архитектура веба: основы для начинающих разработчиков

Рассказывает Jonathan Fulton, VP Engineering в StoryblocksCo

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

Пользователь ищет в Google «Strong Beautiful Fog And Sunbeams In The Forest». Первый результат отправляет его на Storyblocks. Пользователь нажимает на ссылку, которая перенаправляет его браузер на страницу с изображением. Тем временем браузер отправляет запрос на DNS-сервер, чтобы установить соединение со Storyblock, и, получив ответ, отправляет запрос на сайт.

Запрос попадает на балансировщик нагрузки, который случайным образом выбирает для обработки запроса один из десяти (или около того) веб-серверов, на которых запущен сайт. Веб-сервер достаёт некоторую часть информации об изображении из службы кэширования, а остальное — из основной базы данных. Если цветовой профиль для изображения ещё не был вычислен, задача «определить цветовой профиль» будет добавлена в очередь заданий. Эти задания серверы обрабатывают асинхронно и соответствующим образом обновляют базу данных с результатами.

Затем происходит поиск похожих фотографий: в службу полнотекстового поиска отправляется запрос с заголовком фотографии в качестве входных данных. Если пользователь авторизовался в Storyblocks, информация о его учётной записи загружается из базы данных учётных записей. Наконец, данные о просмотре страницы отправляются в firehose-хранилище для последующей записи в облачную систему хранения. В конечном счёте, эти данные будут загружены в хранилище данных, которое аналитики используют для обработки.

14 ноября в 10:00, Санкт-Петербург, беcплатно

Теперь сервер рендерит страничку в HTML и отправляет её обратно браузеру пользователя, проходя сначала через балансировщик нагрузки. Страница содержит Javascript- и CSS-файлы, которые загружены в облачную систему хранения, подключённую к CDN, поэтому браузер связывается с CDN для получения содержимого. Наконец, браузер отображает страницу пользователю.

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

1. DNS

DNS расшифровывается как «Domain Name System» (система доменных имён). Это базовая технология, которая делает возможной работу интернета. На самом базовом уровне DNS обеспечивает поиск пары из доменного имени и IP-адреса (например, google.com и 85.129.83.120), что позволяет компьютеру отправить запрос на соответствующий сервер. По аналогии с телефонными номерами разница между доменным именем и IP-адресом такая же, как и между вызовом Джону Доу и звонком по номеру 201-867-5309. Для поиска номера Джона нужна телефонная книга, а для поиска IP-адреса домена — DNS. Таким образом, можно считать DNS телефонной книгой интернета.

2. Балансировщик нагрузки

Прежде чем начать обсуждение балансировки нагрузки, нужно сделать шаг назад, чтобы обсудить горизонтальное и вертикальное масштабирование приложений. Что это и в чём разница? Эта тема хорошо объяснена в посте на StackOverflow: «горизонтальное» масштабирование характеризуется добавлением новых машин в пул ресурсов, тогда как «вертикальное» подразумевает, что наращивается мощность (например, увеличивается CPU или RAM) существующей машины.

В веб-разработке проект масштабируется горизонтально как минимум потому, что всё ломается. Серверы падают по непонятным причинам. Сети деградируют. В некоторых ЦОД-ах время от времени отключается свет. Несколько серверов позволит переживать незапланированные отключения без нарушения работы приложения. Другими словами, приложение становится «отказоустойчивым». Горизонтальное масштабирование позволяет минимально связывать разные части проекта (веб-сервер, базу данных и т. д.), потому что каждая из них запускается на разных серверах. Наконец, может наступить такой момент, когда вертикальное масштабирование более невозможно, так как в мире нет достаточно мощного компьютера для выполнения всех вычислений приложения. Поисковая платформа Google является типичным примером, хотя это относится и к компаниям с гораздо меньшими масштабами. Например, Storyblocks обычно использует от 150 до 400 AWS-машин EC2 в любой момент времени. Было бы сложно получить всю эту вычислительную мощность с помощью вертикального масштабирования.

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

Вот и всё. Концептуально балансировщики нагрузки довольно просты и понятны.

3. Серверы веб-приложений

Если смотреть издалека, серверы веб-приложений относительно просты. Они выполняют основную бизнес-логику, которая обрабатывает запрос пользователя и отправляет HTML обратно браузеру. Чтобы выполнять свою работу, они обычно общаются с различными бэкэнд-инфраструктурами, такими как базы данных, серверы кэширования, очереди заданий, службы поиска и т. д. Как упоминалось выше, обычно есть как минимум два, а то и больше, сервера, подключённых к балансировщику нагрузки для обработки пользовательских запросов.

Для реализации сервера приложений требуется выбрать конкретный язык (Node.js, Ruby, PHP, Scala, Java, C#, .NET и т. д.) и MVC-фреймворк для этого языка (Express для Node.js, Ruby on Rails, Play для Scala, Laravel для PHP и т. д.).

4. Сервер баз данных

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

Здесь стоит упомянуть SQL и NoSQL.

SQL расшифровывается как «Structured Query Language» (язык структурированных запросов). Он был изобретён в 1970-х годах, чтобы создать стандартный способ запросов к реляционным наборам данных, доступных широкой аудитории. SQL-базы данных хранят данные в таблицах, которые связаны между собой общими ключами. Такие ключи обычно представлены целыми числами.

Рассмотрим типичный пример хранения информации об истории адресов пользователей. Получатся две таблицы — user и user_addresses, — связанные друг с другом идентификатором пользователя (id в таблице user). Их можно увидеть на изображении ниже. Таблицы связаны, потому что столбец user_id в user_addresses является «внешним ключом» в столбце id в таблице users.

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

NoSQL расшифровывается как «не-SQL» и представляет собой более новый набор технологий баз данных. Он был разработан для обработки очень больших объёмов информации, которые могут генерироваться крупномасштабными веб-приложениями. Большинство вариантов SQL плохо масштабируются горизонтально, а масштабироваться вертикально могут только до определённого момента. Если вы ничего не знаете о NoSQL, рекомендуем начать знакомство со следующих статей:

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

5. Кэширование

Служба кэширования предоставляет простое хранилище данных в формате ключ-значение, которое позволяет хранить и искать информацию за время, близкое к линейному (O(1)). Обычно приложения используют функции кэширования, чтобы сохранять результаты дорогостоящих вычислений и воспользоваться ими позже из кэша, а не пересчитывать их еще раз. Приложение может кэшировать результаты запроса в базы данных, результаты обращения к внешним службам, HTML для заданного URL-адреса и многое другое. Вот некоторые примеры из реального мира:

  • Google кэширует результаты поиска для популярных поисковых запросов, таких как «собака» или «Тейлор Свифт», а не ищет их каждый раз заново;
  • Facebook кэширует большую часть данных, которые вы видите при входе в систему, например, списки постов или друзей. Подробнее, о технологии кэширования используемого в Facebook, можно почитать в этой статье на Medium;
  • Storyblocks кэширует HTML-страницы от React, результаты поиска и другое.

Двумя наиболее распространёнными технологиями кэширования являются Redis и Memcache.

6. Очереди задач

Большинству веб-приложений требуется выполнять некоторую работу, напрямую не связанную с ответом на запросы пользователей, асинхронно, в фоновом режиме. Например, Google должен сканировать и индексировать весь интернет, чтобы возвращать релевантные результаты поиска. Он не делает это при каждом запросе, а сканирует сеть асинхронно, обновляя поисковые индексы «по пути».

Выполнять асинхронную работу позволяют разные архитектуры, но наиболее распространённой является архитектура «очередь задач». Она состоит из двух компонентов: очереди «заданий», которые необходимо выполнить, и одного или нескольких рабочих серверов (часто называемых «работниками»), которые обрабатывают задания из очереди.

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

Например, в Storyblocks очередь заданий используется для выполнения многих скрытых работ, необходимых для поддержания проекта: кодирование видео и фотографий, обработка CSV-файлов для тегов метаданных, агрегирование статистики пользователей, отправка писем с паролями для сброса и т. д. Со временем проект отказался от простой очереди FIFO в пользу приоритетной очереди, чтобы операции с фиксированным временем выполнения, такие как отправка писем о сбросе пароля, были завершены как можно скорее.

Сервера заданий выполняют задания из очереди. Они запрашивают её, чтобы определить, есть ли работа, и если есть, — приступают к выполнению.

7. Полнотекстовый поиск

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

В этом примере три заголовка документов преобразуются в инвертированные индексы, что облегчает поиск по определённому ключевому слову среди документов с этим ключевым словом в заголовке. Обратите внимание, что обычные слова, также называемые стоп-словами («in», «the», «with» и т. д.), обычно не включаются в инвертированный индекс.

В действительности можно выполнять полнотекстовый поиск непосредственно из некоторых баз данных (например, его поддерживает MySQL), но обычно принято запускать отдельную службу, которая вычисляет и сохраняет инвертированные индексы и предоставляет интерфейс для запросов. Самая популярная полнотекстовая поисковая платформа сегодня — Elasticsearch, хотя есть и другие варианты, такие как Sphinx или Apache Solr.

8. Службы

Когда приложение достигает определённого масштаба, как правило, появляются определённые «службы», созданные специально для запуска в виде отдельных приложений. Они не выставлены на всеобщее обозрение, но приложение и другие службы взаимодействуют с ними. Например, в Storyblocks имеются несколько операционных и плановых служб:

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

9. Хранилище данных

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

  1. Приложение отправляет данные в «firehose»-хранилище, которое обеспечивает потоковый интерфейс для поглощения и обработки данных. Как правило, это информация о действиях пользователей. Часто необработанные данные преобразуются или дополняются и передаются в другие «firehose»-хранилища. Наиболее распространённые технологии для этого процесса — AWS Kinesis и Kafka.
  2. Исходные, а также окончательно преобразованные и дополненные данные сохраняются в облачном хранилище. AWS Kinesis предлагает сервис под названием Firehose, который позволяет сохранять необработанные данные в облачном хранилище (S3), которое чрезвычайно просто в настройке.
  3. Преобразованные и дополненные данные загружаются в хранилище данных для анализа. Типичным примером является AWS Redshift, им пользуется большинство стартапов, хотя крупные компании предпочитают решения от Oracle или другие проприетарные технологии хранения. Если наборы данных достаточно велики, то для анализа может потребоваться технология NoSQL MapReduce, например, Hadoop.

На диаграмме не изображён ещё один шаг: загрузка данных из приложения и баз данных различных служб в хранилище. Например, Storyblocks каждую ночь загружает VideoBlocks, AudioBlocks, Storyblocks, службу учётных записей и базы данных портала разработчиков в Redshift. Это даёт аналитикам целостное представление, так как основные бизнес-данные и данные действий пользователей хранятся в одном и том же месте.

10. Облачное хранилище

«Облачное хранилище — простой и масштабируемый способ для хранения и обмена данными через интернет». Такое определение дано AWS. Его можно использовать для хранения и доступа к чему угодно, что можно хранить в локальной файловой системе, пользуясь преимуществами RESTful API через HTTP. Решение от Amazon S3 на сегодняшний день является самым популярным облачным хранилищем, и его широко используют в Storyblocks для хранения видео-, фото- и аудиофайлов, CSS- и JavaScript-файлов, данных действий пользователей и многого другого.

11. CDN

CDN расшифровывается как «Content Delivery System» (система доставки контента). Эта технология позволяет намного быстрее, чем с исходного сервера, отправлять статические HTML-, CSS-, JavaScript-файлы и изображения. Она распространяет контент из многих «конечных» серверов по всему миру, чтобы пользователи загружали различные ресурсы из них вместо исходного сервера. Например, на изображении ниже пользователь из Испании запрашивает веб-страницу с сайта, серверы которого находятся в Нью-Йорке, но статические ресурсы для этой страницы загружаются с «конечного» сервера CDN в Англии, предотвращая медленные кросс-атлантические HTTP-запросы.

Для более полного понимания принципов работы современного веба вы можете также ознакомиться с другими нашими материалами:

Как стать веб-разработчиком – руководство для начинающих

Мы живем в мире, где многие « традиционные » навыки больше не пользуются спросом. Если вы будете следовать инструкциям из этой статьи, то сможете стать web программистом намного быстрее. Но это все равно потребует от вас много усилий!

Кто такой веб-разработчик?

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

Обязанности и требования к веб-разработчикам:

  • Создание веб-страниц с помощью различных языков разметки;
  • Создание качественных макетов и прототипов;
  • Создание сайтов на WordPress с нуля;
  • Понимание HTML и CMS ;
  • Понимание UI и UX ;
  • Разработка функционала и дизайна сайтов и веб-приложений;
  • Обслуживание и улучшение сайта.

Если говорить о специализации web программистов, то выделяют три основных направления:

  • Разработка front-end . « Front-end » означает элементы на сайте, которые вы видите и с которым взаимодействуете, например, меню, выпадающие списки и т. д.;
  • Разработка back-end . « Back-end » похож на подводную часть айсберга. Без него сайт не может функционировать. Back-end связан с такими вещами, как серверы, приложения и базы данных;
  • Разработка полного стека . Это комбинация разработки back-end и fron-tend .

Зачем становиться веб-разработчиком?

Веб-разработка — это отрасль, которая точно не умрет в ближайшее время. Бюро статистики трудовых ресурсов США предсказало 27% рост количества рабочих мест в сфере веб-разработки к 2024 году.

Вот пять основных причин стать web программистом и обучиться с нуля:

  1. Вы можете работать удаленно;
  2. Вы можете работать самостоятельно. Заниматься фрилансом или начинать свой бизнес;
  3. Вы выходите на прибыльный технологичный рынок. Веб-разработка — это билет в мир высоких технологий. У большинства технологичных стартапов есть потребность в веб-разработчиках, поэтому это может быть ваш путь к успеху.

Как стать веб-разработчиком

  1. Изучите основы HTML, CSS и Javascript

Это гайки и болты любого сайта, с ними вы будете работать ежедневно.

  • HTML задает структуру;
  • CSS делает ее визуально привлекательной;
  • Javascript заставляет ее функционировать.

Перед тем, как стать web программистом, рассмотрим каждый из этих аспектов.

HTML

HTML означает Hypertext MarkUp Language . Это один из основных компонентов любого сайта и один из так называемых front-end языков. Он формирует базовую структуру сайта, делается это в основном с помощью тегов.

Ниже приведены некоторые базовые HTML-теги , с которыми вам следует ознакомиться:

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

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

CSS

CSS — это каскадные таблицы стилей и то, что должен знать web программист обязательно.

Они задают стиль HTML-структуры . В принципе без CSS , HTML будет скучным, а в результате и веб-страница будет скучной.

Вот как они сочетаются: в HTML-коде вы ссылаетесь на таблицу стилей CSS .

Ниже приводится пример того, как выглядит CSS в действии:

Пример CSS

Javascript

Javascript — это язык программирования, который позволяет реализовать интерактивные элементы на веб-страницах. Например, интерактивные карты, 2D / 3D-графика и многое другое, что знает даже web программист стажер.

  1. Изучите руководства по WordPress

Чтобы стать веб-разработчиком, вам нужно будет ознакомиться с WordPress . 25% всех сайтов в интернете работают на этом движке.

  1. Изучите основы UI и UX

UI ( пользовательский интерфейс ) и UX ( опыт взаимодействия пользователя ) — это основа разработки пользовательского интерфейса.

Большинство разработчиков не являются экспертами по дизайну — это две разные сферы. Но, изучив основы построения пользовательского опыта, вы сможете лучше понять, как должен работать сайт.

Чтобы узнать больше об основах проектирования сайта, рекомендую изучить Adobe Creative Suite . Photoshop должен быть первым, за что вы возьметесь, так как он подходит для самых серьезных дизайнеров. Если junior web программисту не нравится Adobe , можно также изучить Sketch , который является восходящей звездой.

  1. Изучите SQL и PHP (более продвинутые навыки)

SQL — это система управления базами данных. А PHP — это язык « скриптов », который помещает или извлекает данные из базы.

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

PHP — это то, что делает любой WordPress-сайт динамичным, взаимодействуя с этими элементами, и обновляя базу данных по мере развития сайта.

Узнав больше о том, как работают SQL и PHP , вы сможете досконально освоить разработку сайтов на базе WordPress . Этот вид услуг востребован.

Вы не освоите все это за неделю или две. Но со временем, по мере приобретения опыта и навыков, сможете значительно повысить свою конкурентоспособность на рынке в качестве web программиста.

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

В SEO структура и код сайта также играют определенную роль. Например, тэги тайтлов ( HTML ) чрезвычайно важны. Они сообщают поисковым системам, что действительно важно на сайте.

Должны ли вы стать экспертом в области SEO ? Определенно, нет. Но вы обязательно должны изучить основы SEO и учитывать их при разработке сайтов. Таким образом созданный вами сайт будет иметь больше шансов на успех.

Вот несколько советов по SEO для веб-разработчиков :

  • Оптимизируйте метатеги. В поисковой выдаче метатеги сообщают браузерам, о чем ваш сайт;
  • Убедитесь, что теги заголовков находятся в определенном порядке. H1 должен быть основным заголовком, а затем необходимо опускаться вниз по иерархии заголовков ( то есть H2, H3, H4 и т. д .). Это упрощает поисковым системам сканирование сайта;
  • Убедитесь, что тег тайтла правильно описывает веб-страницу.

Посвятите хотя бы 3-5 часов изучению основ SEO . Это позволит эффективнее разрабатывать сайты и позитивно отразится на зарплате web программиста.

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

Как найти своего первого клиента на веб-разработку (или стать фрилансером)

Теперь, у вас как у веб-разработчика, есть два варианта. Вы можете: 1) попытаться получить постоянную работу в компании или 2) пойти путем фриланса и искать заказы онлайн.

Я рекомендую фриланс. Хотя он не дает такую же гарантированную оплату, что и полная занятость, у этого вида работы есть три преимущества:

  • Свобода : больше нет начала рабочего дня и конца рабочего дня. Вы все еще можете работать в те же часы ( или больше ), но ваш график, местонахождение и условия жизни полностью зависят от вас;
  • Деньги : как только вы станете хорошим фрилансером, у вас будет больше шансов заработать больше денег ( и не ждать ежемесячного трехпроцентного повышения );
  • Престиж : со временем у вас будет возможность развить личный бизнес и бренд настолько, что в конечном итоге это гарантирует постоянный приток новых клиентов.
Мастер Йода рекомендует:  Стали известны имена двух главных кандидатов на должность главы Microsoft

В этом разделе мы сосредоточимся на том, как web программисту стажеру получить свой первый фриланс-заказ…

  1. Используйте биржи вакансий

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

Качество клиентов там может варьироваться. Некоторые могут быть замечательными. Другие — нет.

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

Сильная зависимость от бирж не оставит вам возможности начать создавать свой собственный бренд. Привлечение «входящего» внимания к вашей работе в конечном итоге даст лучших ( и самых платежеспособных ) клиентов.

Но это неплохой вариант для начала.

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

Также довольно легко начать работу на досках объявлений… Ниже приведен скриншот поиска по UpWork :

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

Вот несколько советов по созданию сайта-портфолио:

  • Используйте отзывы от своих предыдущих и текущих клиентов . Это даст посетителям уверенность в том, что вы отлично работали в прошлом и что другие были рады работать с вами.
  • Подчеркните свои преимущества . В чем вы хороши, что отличает вас от других?
  • Опубликуйте важные данные о себе — имя, короткую версию истории о том, как и почему вы стали веб-разработчиком.
  • Ответьте на вопрос «Что веб-разработка значит для меня?» . Опишите преимущества работы с вами.
  1. Нетворкинг

Старайтесь каждый месяц посещать, по крайней мере, 2-3 мероприятия. Если вы живете недалеко от большого города, это не должно составить труда.

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

Заключение

Почему бы не освоить навыки, которые позволят без труда находить работу в обозримом будущем? В этом одно из основных преимуществ web программирования. Следуя приведенным советам, вы можете начать свой путь становления в качестве веб-разработчика.

Данная публикация представляет собой перевод статьи « How to Become a Web Developer » , подготовленной дружной командой проекта Интернет-технологии.ру

Основы работы со службой DNS

Общая информация

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

Бесплатный DNS-хостинг

  • Надёжные DNS-сервера
  • Автоматическая миграция
  • API

DNS (Domain Name System — система доменных имен) представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более адаптированных для человеческого восприятия символьных имен. Предоставление информации об IP-адресах хостов по символьному адресу — не единственная задача DNS. Система работает с разными типами ресурсных записей, позволяющими реализовывать весьма широкий круг задач: переадресация между доменными именами, балансировка нагрузки между хостами, привязка специфических сервисов (напр., эл. почты) к домену.

Система доменных имен является одной из фундаментальных технологий современной интернет-среды, так как информация об IP-адресе запрашиваемого узла — обязательное условие получения ответа на любой интернет-запрос. Но IP-адрес представляет собой числовое значение вида «1.23.45.67», неподходящее для комфортного восприятия человеком. К тому же основной принцип распределения IP-адресов в сети — уникальность. Важно и то, что сетевой адрес — не самый устойчивый параметр. Он может изменяться (напр., при смене хоста, обслуживающего запрашиваемый узел, смене хостинг-провайдера, и т.п.). Все перечисленные особенности делают систему навигации по сетевым адресам сложной для человека.

DNS обеспечивает преобразование запрашиваемого клиентом символьного имени домена в IP-адрес (адреса) обслуживающего эту доменную зону сервера (серверов). Изначально, до разрастания сети интернет, адреса преобразовывались согласно содержимому файла «hosts», составлявшегося централизованно и автоматически рассылавшегося на каждую из машин в сети. По мере роста глобальной сети такой метод перестал оправдывать себя — появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом.

Ключевыми характеристиками DNS являются:

  • Распределенность хранения и управления — каждый DNS-сервер обязан хранить информацию только по делегированным ему доменам, а ответственность за различные узлы дерева доменных имен несут разные лица
  • Кэширование данных — DNS-сервер может временно хранить некоторое количество информации о неделегированных ему доменах для уменьшения уровня общей нагрузки
  • Иерархическая структура — узел, ответственный за доменную зону, может самостоятельно делегировать нижестоящие узлы другим DNS-серверам
  • Резервирование — хранение и обработка информации об одних и тех же узлах обычно обеспечивается несколькими DNS-серверами, изолированными физически и логически. Такой подход обеспечивает доступность информации даже при сбое одного или нескольких узлов.

Иерархия и делегирование доменных имен

Домен представляет собой именованную ветвь в дереве имен, включающую в себя сам узел (напр., домен первого уровня «.com»), а также подчиненные ему узлы (напр., домен второго уровня «example.com», домен третьего уровня «mail.example.com» и т.д.). Для обозначения иерархической принадлежности доменных имен принято использовать понятие «уровень» — показатель положения узла в дереве доменов. Чем ниже значение уровня, тем выше иерархическое положение домена

  • «.» — домен нулевого уровня
  • «.ru» — домен первого (верхнего) уровня
  • «example.com» — домен второго уровня
  • «mail.example.com» — домен третьего уровня
  • Этот список можно продолжать

Обратите внимание на домен нулевого уровня «.» (dot — точка), также называемый корневым. На практике точку обычно не указывают («example.com» вместо «example.com.»), т.е. указание корневого домена не является обязательным условиям разрешения IP-адреса. Большинство клиентских программ (интернет-браузеров и т.д.) добавляют домен нулевого уровня автоматически и не отображают его пользователю. Доменное имя, не включающее обозначение домена нулевого уровня называется относительным, включающее же точку на конце — полностью определенным (FQDN — Fully Qualified Domain Name).

Доменная зона — часть иерархического дерева доменных имен (напр. «.ru»), целиком переданная на обслуживание определенному DNS-серверу (чаще нескольким) с целью делегирования другому лицу ответственности за этот и все подчиненные домены («anyaddress.ru», «any.anyaddress.ru»).

Делегирование — передача ответственности за определенную ветвь дерева доменных имен другому физическому или юридическому лицу. Именно эта процедура практически реализует важный принцип работы DNS — распределенность хранения записей и обработки запросов. Сам процесс делегирования представляет собой добавление в ресурсные записи родительской зоны («.ru»), так называемых «склеивающих» («glue») NS-записей для делегируемой дочерней зоны («example.com»), указывающих на DNS-сервера принимающей домен стороны (например, DNS-сервера нашей компании). С этого момента все ресурсные записи домена второго уровня «example.com» и всех его дочерних доменов (например, «mail.example.com» и т.д.) хранятся на DNS-серверах этой компании, а родительская зона «.ru» хранит только указывающие на эти сервера NS-записи.

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

DNS-клиент — набор программных средств для работы с DNS. Сам DNS-сервер периодически также выступает в качестве клиента.

Основные типы ресурсных записей

Ресурсная запись (RR — Resource Record) — единица хранения и передачи информации в DNS, включающая в себя следующие элементы (поля):

  • Имя (Name) — имя домена, к которому относится запись
  • TTL (Time To Live) — допустимое время хранения записи неответственным сервером
  • Тип (Type) — параметр, определяющий назначение и формат записи в поле данных (Rdata)
  • Класс (Class) — тип сети передачи данных (подразумевается возможность DNS работать с типами сетей, отличных от TCP/IP)
  • Длина поля данных (Rdlen)
  • Поле данных (Rdata) — содержание и формат поля зависят от типа записи

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

  • A (IPv4 Address Record — адресная запись) — связывает доменное имя с IPv4-адресом хоста
  • AAAA (IPv6 Address Record) — связывает доменное имя с IPv6-адресом хоста (аналогично А-записи)
  • CNAME (Canonical Name Record — каноническая запись имени) — используется для перенаправления на другое доменное имя
  • MX (Mail Exchange — почтовый обменник) — ссылается на почтовый сервер, обслуживающий домен
  • NS (Name Server — сервер имен) — ссылается на DNS-сервер, ответственный за домен
  • TXT — текстовое описание домена. Зачастую требуется для выполнения специфических задач (например, подтверждения права собственности на домен при привязке его к почтовому сервису)
  • PTR (Point to Reverse — запись указателя) — связывает ip-адрес машины с доменом, используется преимущественно для проверки сторонними почтовыми сервисами отправляемых через эту машину электронных писем на отношение к домену, указанному в параметрах почтового сервера. При несоответствии этих параметров письмо проверяется более тщательно по другим критериям.

Рекурсивные и нерекурсивные DNS-запросы

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

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

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

Основы веб-разработки: правила хорошего тона


Дата публикации: 2020-10-01

От автора: тысячи людей в мире ежедневно делают свои первые шаги в веб-разработке. Но если пренебречь догмами на старте обучения или профессиональной карьеры, можно так никогда и не стать толковым девелопером, который знает, как создать правильный дизайн с хорошим юзабилити. Сегодня мы расскажем о некоторых моментах, которые помогут выбрать курс развития не только «падаванам» web, но и тем, кто считает себя «джедаем».

Их не обойти!

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

Мода в каждой сфере

И веб-девелопмент не является исключением. Однако модные веяния имеют логическую подоплеку (высокая мода не в счет ). В мире одежды тренды обусловлены географическими координатами и культурой, в то время как в разработке веб-продуктов решающим фактором являются пользовательские девайсы, которые будут отображать результат веб-разработки.

Делай легко и красочно

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

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

Когда Интернет был молод, соединение медленным, а ПК малопроизводительными, контент в сети должен был быть соответствующим. Если вы помните, в том же далеком 2005-м, скорость соединения в 1 Мб/c считалась роскошью. Сейчас, даже мобильные операторы могут предложить значительно больше, не говоря уже об оптоволоконном соединении.

Да, сегодня с уверенностью можно сказать, что стало модным делать красочные сайты и веб-приложения. И чем ярче и интерактивнее будут результаты разработки, тем более привлекательным будет продукт в целом.

Но не стоит и пренебрегать одним из базовых правил: «Чем меньше, тем лучше». Современные страницы могут весить до 3-х мегабайт (усредненное значение) — но, если вы оптимизируете контент до 1–1.5, то пользователь с куда большим энтузиазмом посетит ее в первый и второй раз. Тем более, что медленное соединение еще встречается повсеместно.

В этой статье мы не будем рассматривать приемы, которые можно использовать, чтобы элементы вашего продукта весили меньше. Просто запомните одну простую истину: «Где можно оптимизировать — оптимизируйте». Впрочем, на крутые сайты заходят, мирясь с их объемами, а неинтересные страницы игнорируют, даже несмотря на их ничтожный размер.

Конкурент всегда впереди

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

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

Знание — сила!

Чтобы быть хорошим девелопером, одних только принципов, конечно же, мало. Фундамент составляют знания, добывать которые приходится трудом и усидчивостью. Говорят, что кто-то более предрасположен к разработке, кто-то менее. Но практика показывает, что в среднем, новички тратят равное количество часов на получение того или иного навыка.

Так что, если у вас уходит масса времени на решение какой-либо проблемы или усвоение материала, то знайте — вокруг вас миллионы таких же, как и вы. Что же нужно знать каждому веб-девелоперу:

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

графические редакторы. Как бы ни были популярны верстальщики, нужен человек, который создает веб-дизайн. Именно благодаря начальному макету создается будущий внешний вид страницы и приложения. Если вы хотите развиваться как веб-разработчик, вам не обойти такую преграду, как Photoshop или Illustrator. Они будут преследовать вас, потому лучше приспособиться, чем сопротивляться;

старый добрый HTML/CSS. Сколько бы ни создавали конструкторов для «чайников», нормальный продукт на них не создашь. Нужно понимать, по каким принципам браузер отображает информацию, и как встраивать в нее определенные решения. Потому, если вы только на начале пути, то без разметки и таблиц стилей вам не обойтись (а если вы уже профессионал, который процветает без этих знаний, то обязательно свяжитесь с нами — реликтовый вид нужно задокументировать );

javascript — без него, как без рук. Он создает не только интерактивные моменты, но способен на гораздо большее. С помощью скриптов можно автоматизировать процессы и сделать сложное легко. Также удачно применимы и другие современные языки программирования, такие как Python, PHP и C#. Это как с размером страницы, только наоборот: чем больше, тем лучше;

методология БЭМ. Здесь все просто: любую единицу веб-дизайна можно описать как «блок», «элемент» или «модификатор». Вы должны были слышать об этой методологии — сегодня современные страницы создают по этому принципу;

работа с версиями. Хоть разработчики софта зачастую недолюбливают своих web-коллег, воркфлоу у них очень похож. Особенно это касается версий готового продукта. Вместо того чтобы постоянно исправлять, можно просто создать вариант. Таким образом редактура доступна на любой стадии разработки;

софт. Этот пункт мог бы быть невероятно большим, ведь для каждого веб-разработчика свои методы хороши. Это и всем известный Bootstrap, и Visual Studio, и другие фреймворки. Решая конкретные задачи, вы сами поймете, какие средства вам необходимы, какие более удобны и так далее.

Тимлид, как призвание

Как говорится в старой армейской поговорке: «Плох тот джун, что не хочет стать тимлидом». Это правило должен взять себе за кредо каждый начинающий и уже действующий разработчик. Если вы не развиваетесь, то ваш скилл устаревает и становится дешевле на рынке труда. Но если саморазвитие взято за основу, то рано или поздно вы должны возглавить команду таких же разработчиков, как и вы сами.

Работа тимлида хорошо оплачивается — примерно в полтора раза выше, чем рядового сотрудника. Однако, быть начальником программистов, это не то же самое, что быть командиром воинского подразделения: вы действительно должны быть на голову выше в профессиональном плане и иметь реальный авторитет. Что же нужно знать руководителю?

В первую очередь, тимлид — это неоспоримый Full Stack хотя бы в том направлении, в котором работает команда. Его опыт и умения должны служить процессу даже тогда, когда участники не знают, как решить проблему. Более того, лидер должен уметь замечать неверные решение своих подопечных, регулярно инспектируя код и видимые результаты работы.

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

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

На этом мы заканчиваем наше короткое наставничество для маленьких и больших. Впереди мы еще не раз коснемся темы — правил намного больше, чем кажется. Кроме того, есть еще большой объем знаний, с которыми нужно ознакомиться для того, чтобы успешно работать в web!

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

React JS с Нуля до Профи

React JS. Полное руководство для современной веб-разработки

Подробное руководство по настройке TTL для записей DNS

Система DNS — это фундаментальный технологический продукт. Обработка практически всех сетевых запросов верхнего уровня и поисковых запросов в Интернете, пересылка интернет-трафика и электронной почты, а также многие другие операции становятся возможными благодаря установке определенных соответствий при поиске DNS (преобразованию таких имен, как some.domain.org, в IP-адреса или имена других доменов).

Мы решили написать о времени жизни (Time To Live, TTL) данных, поскольку большинству системных администраторов не приходится каждый день работать с конфигурациями DNS и значительная часть информации об этом параметре — это полузабытые байки, передаваемые системными администраторами из поколения в поколение.

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

Отгадайте загадку! Что означает аббревиатура TTL, когда речь идет о системе DNS?

18:43 26 окт. 2020 г.
4 % Граница терминальной передачи
85 % Время жизни
8 % Телеметрическая транспортная линия
3 % Список доверенных технологий
26 голосов • Окончательный результат
Ретвит 1 Отметка «Нравится» 1

Чтобы внести ясность, мы рассмотрим следующие темы.

1. Общие сведения о системе DNS и параметре TTL
2. Устранение проблем с TTL в записях DNS
3. Рекомендации по управлению изменениями в записях DNS
4. Инструменты DNS
5. Дальнейшие действия

1. ОБЩИЕ СВЕДЕНИЯ О СИСТЕМЕ DNS

Что такое запись DNS?

Запись сервера доменных имен (Domain Name Server, DNS) содержит два важных параметра:
адресацию (установку соответствия) запросов для той или иной записи;
время актуальности записи при кэшировании — именно это значение получило зловещее название «время жизни» (TTL).

Зачем кэшируются записи DNS?

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

Время жизни (TTL) представляет собой продолжительность кэширования записи *каждым звеном* цепочки установки соответствий DNS. Это значение измеряется в секундах (важность этого будет объяснена ниже).

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

Каково стандартное значение TTL для записей DNS?

Значение TTL всегда выражается в секундах. Большинство служб настройки конфигурации DNS содержат готовый список значений для записей.
300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»

Как осуществляется поиск DNS?

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

1. Кэширована ли нужная запись?
2. Если да, действительно ли ее значение TTL?

Если на какой-либо из этих вопросов получен ответ «Нет», запрос перемещается на следующее звено цепочки.

Почему в основе системы DNS лежат сетевые подключения, а не устройства?

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

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

• к основной домашней сети Wi-Fi/кабельной сети;
• к мобильному телефону при недоступности кабельной сети;
• оба варианта выше, но с подключением через VPN.

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

Такое часто случается в корпоративных сетях, где имя домена Active Directory совпадает с адресом веб-сайта компании. На внешнем сервере DNS (уровень поставщика Интернета) хранится запись DNS, направляющая адрес www.example.com к верному IP-адресу/CNAME веб-сервера, но на внутреннем сервере DNS, используемом службой Active Directory, записи не дублируются.

Сразу же начнется паника: «Веб-сервер не работает!», «Это конец света!», «Где мои брюки?». Но, приступив к устранению проблемы, вы обнаружите, что ее причиной стало незакрытое подключение через VPN.

2. УСТРАНЕНИЕ ПРОБЛЕМ С TTL В ЗАПИСЯХ DNS

Сколько времени требуется на обновление записи DNS?

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

Например, если значение TTL составляет 3600 секунд (1 час), а цепочка DNS состоит из 5 звеньев, полное распространение изменений должно занять не более 18 000 секунд (5 часов).
Но если бы все было так просто.

Каковы затраты на поиск DNS?

Когда речь заходит о «затратах» на поиск DNS, обычно имеются в виду не денежные, а временные затраты. В зависимости от численности интернет-гремлинов в глобальной сети на выполнение запроса DNS обычно уходит 100–200 миллисекунд.

Это очень небольшое время, но представьте себе веб-страницу. Соответствие между именем и IP-адресом в системе DNS необходимо настроить для всех изображений, файлов CSS и файлов активов JavaScript, доступных по ссылкам на странице. Без кэширования время загрузки заметно увеличится.

Упрощенная схема расчета затрат на поиск DNS

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

(30 файлов изображений x 50 мс на загрузку каждого файла) + (100 мс на выполнение одного поиска DNS с последующим кэшированием) = 1600 мс

(30 файлов изображений x 50 мс на загрузку каждого файла) + (30 x 100 мс на каждый поиск DNS) = 3000 мс

Почему мои записи DNS не обновляются?

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

Мастер Йода рекомендует:  Подборка видео по Python, которые стоит посмотреть

• Веб-браузеры самостоятельно кэшируют записи DNS и хранят их в течение некоторого времени без учета TTL, что якобы повышает скорость их работы. Например, современные версии Internet Explorer по умолчанию кэшируют записи DNS на 30 минут (до версии IE 4 это время составляло 24 часа) и игнорируют более низкие значения TTL.
• Поставщики мобильного Интернета могут пытаться уменьшить общий объем передаваемого трафика путем увеличения времени TTL, что снижает частоту запросов.
• Сложные внутренние сети с большим числом сервером DNS, чем предполагалось, обновляются дольше по очевидным причинам.

Именно поэтому во многих службах можно встретить следующее заявление: «Полное распространение изменений в записях DNS может занять несколько дней, поэтому планируйте свои действия соответствующим образом».

Можно ли как-нибудь принудить клиент удаленно обновить запись DNS?

Этот вопрос обычно задается в следующем контексте: «После обновления записей DNS клиент не может получить доступ к некоторым сайтам. Как выполнить обновление принудительно?»
К сожалению, единственный ответ на этот вопрос: «Никак». В системе DNS нет команды, позволяющей принудительно выполнить раннее обновление данных для клиентов более низкого уровня.

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

Лучше всего изменить значения TTL в своих записях заблаговременно.

3. РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ В ЗАПИСЯХ DNS

Какие значения TTL лучше: маленькие или большие?

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

Атака DDOS, способная на 12 часов остановить работу корневых серверов DNS или аналогичных серверов поставщика Интернета, меньше скажется на сайтах с очень высоким значением TTL. В таких случаях клиенты будут работать даже при выключении или перегрузке сервера DNS.
Однако, если при переключении узлов Интернета или электронной почты вы случайно сделаете ошибку, 12 часов без какой-либо возможности устранить ее — это последнее, что вам будет нужно. Именно поэтому некоторые администраторы считают, что время жизни не должно превышать 1 минуты.

Лично я стараюсь указывать для записей DNS малое значение TTL (меньше 1 часа/3600 секунд).

Как узнать, когда клиент запросит обновленную запись DNS?

Определить, когда все клиенты обновят данные, очень сложно.
Время жизни — это *не* срок годности. Не стоит сравнивать значение TTL в записи DNS с рекомендуемой датой употребления, указанной, например, на несвежем хлебе: это не определенное время, при наступлении которого запись станет недействительной и потребует замены.

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

Создание «плана» или «стратегии» для выполнения относительно простых задач, к которым относится изменение одной записи в домене, может казаться перегибом, но, учитывая колоссальное влияние сбоев DNS на доступность ваших данных, определенную осторожность проявить все же стоит. Как говорится в старой пословице: «Предотвратить легче, чем лечить».
Есть простой способ свести ошибки к минимуму: никогда не обновляйте запись DNS и значение TTL для этой записи одновременно. В идеале у вас должен быть реализован следующий процесс.

1. За несколько дней до переключения укажите для параметра TTL записи DNS низкое значение, например 300 секунд.
2. Установите для записи дату переключения.
3. Через несколько дней после переключения задайте более высокое значение TTL.
Как лучше всего добавлять новые записи DNS?
Добавить новую запись проще, чем изменить существующую.
1. Добавьте запись с низким значением TTL.
2. Проверьте, все ли работает, и увеличьте значение TTL.

Какое значение TTL наиболее распространено?

Мнения относительно *правильного* значения TTL настолько расходятся, что мы предприняли попытку определить его на основе статистики. Список из 500 самых важных веб-сайтов по версии Moz показался нам отличным срезом Интернета. Кроме того, на этом ресурсе был доступен готовый файл CSV с перечнем сайтов, вошедших в итоговый список.

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

Анализ значений TTL для 500 важнейших интернет-доменов по версии Moz

Вы можете просмотреть или изменить этот сценарий либо загрузить его и выполнить анализ самостоятельно: gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b
Посмотреть список и загрузить его в формате CSV можно по адресу moz.com/top500

Минимальное значение TTL: 1
Максимальное значение TTL: 129 540
Домены с установленным соответствием: 485
Среднее арифметическое значение TTL: 6468
Медианное значение TTL: 300

Минимальные значения были получены от доменов, которые очень часто изменяют записи DNS в целях балансировки нагрузки. Максимальные значения соответствовали доменам, которые не обновлялись в течение длительного времени (да-да, python.org, это я про вас).

При необходимости обосновать свое решение об установке низкого (в пределах 1 часа, 3600 секунд) значения TTL вы можете предоставить медианное значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирическое доказательство правильности своего выбора.

4. ИНСТРУМЕНТЫ ПЛАТФОРМЫ DNS

Как проверить значение TTL для записи DNS в Windows?

Для проверки записей DNS в Windows проще всего использовать служебную программу nslookup: technet.microsoft.com/en-us/library/bb490950.aspx.
Пример: C:\>nslookup -type=cname -debug www.varonis.com

Значение TTL указывается в нижней части выходных данных. Фраза Non-authoritative answer (Не заслуживающий доверия ответ) указывает на значение TTL, полученное от клиента (2 минуты 11 секунд до проверки локальным клиентом следующего уровня в цепочке DNS).

Как проверить значение TTL для записи DNS в Unix/Linux/Mac?

В системе Unix (и ее производных) для устранения проблем с DNS используется команда dig.
Пример: dig www.varonis.com

Значение TTL обведено красным цветом.

Как проверить запись DNS через Интернет?

Иногда бывает так, что вам необходимо проверить запись DNS без компьютера под рукой. Удобная (и бесплатная) версия команды dig доступна в инструментах Google по следующему адресу: toolbox.googleapps.com/apps/dig.

Значение TTL обведено красным цветом.

Как убедиться в распространении TTL для записи DNS?

Если вам необходимо выяснить, обновлены ли на конкретном сервере DNS параметры записи DNS, то в любом инструменте DNS (dig, nslookup и т. д.) вместо локальной настройки по умолчанию можно выбрать сервер DNS, на котором будет выполнен запрос.

Для получения полной картины изменений я рекомендую ресурс whatsmydns.net, который позволяет проверить множество серверов DNS верхнего уровня (уровень поставщика Интернета) и выявить возможные проблемы.

ДАЛЬНЕЙШИЕ ДЕЙСТВИЯ ПО НАСТРОЙКЕ TTL ДЛЯ ЗАПИСЕЙ DNS

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

Если вам понравилась эта статья, я рекомендую также ознакомиться с нашим курсом, посвященным основам веб-безопасности. Это поможет вам лучше защитить сайт или приложение, для которого вы только что настроили запись DNS. Курс бесплатный и очень информативный.

Архитектура веба: основы для начинающих разработчиков

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

Пользователь ищет в Google «Strong Beautiful Fog And Sunbeams In The Forest». Первый результат отправляет его на Storyblocks. Пользователь нажимает на ссылку, которая перенаправляет его браузер на страницу с изображением. Тем временем браузер отправляет запрос на DNS-сервер, чтобы установить соединение со Storyblock, и, получив ответ, отправляет запрос на сайт.

Запрос попадает на балансировщик нагрузки, который случайным образом выбирает для обработки запроса один из десяти (или около того) веб-серверов, на которых запущен сайт. Веб-сервер достаёт некоторую часть информации об изображении из службы кэширования, а остальное — из основной базы данных. Если цветовой профиль для изображения ещё не был вычислен, задача «определить цветовой профиль» будет добавлена в очередь заданий. Эти задания серверы обрабатывают асинхронно и соответствующим образом обновляют базу данных с результатами.

Затем происходит поиск похожих фотографий: в службу полнотекстового поиска отправляется запрос с заголовком фотографии в качестве входных данных. Если пользователь авторизовался в Storyblocks, информация о его учётной записи загружается из базы данных учётных записей. Наконец, данные о просмотре страницы отправляются в firehose-хранилище для последующей записи в облачную систему хранения. В конечном счёте, эти данные будут загружены в хранилище данных, которое аналитики используют для обработки.

Теперь сервер рендерит страничку в HTML и отправляет её обратно браузеру пользователя, проходя сначала через балансировщик нагрузки. Страница содержит Javascript- и CSS-файлы, которые загружены в облачную систему хранения, подключённую к CDN, поэтому браузер связывается с CDN для получения содержимого. Наконец, браузер отображает страницу пользователю.

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

1. DNS

DNS расшифровывается как «Domain Name System» (система доменных имён). Это базовая технология, которая делает возможной работу интернета. На самом базовом уровне DNS обеспечивает поиск пары из доменного имени и IP-адреса (например, google.com и 85.129.83.120), что позволяет компьютеру отправить запрос на соответствующий сервер. По аналогии с телефонными номерами разница между доменным именем и IP-адресом такая же, как и между вызовом Джону Доу и звонком по номеру 201–867–5309. Для поиска номера Джона нужна телефонная книга, а для поиска IP-адреса домена — DNS. Таким образом, можно считать DNS телефонной книгой интернета.

2. Балансировщик нагрузки

Прежде чем начать обсуждение балансировки нагрузки, нужно сделать шаг назад, чтобы обсудить горизонтальное и вертикальное масштабирование приложений. Что это и в чём разница? Эта тема хорошо объяснена в посте на StackOverflow: «горизонтальное» масштабирование характеризуется добавлением новых машин в пул ресурсов, тогда как «вертикальное» подразумевает, что наращивается мощность (например, увеличивается CPU или RAM) существующей машины.

В веб-разработке проект масштабируется горизонтально как минимум потому, что всё ломается. Серверы падают по непонятным причинам. Сети деградируют. В некоторых ЦОД-ах время от времени отключается свет. Несколько серверов позволит переживать незапланированные отключения без нарушения работы приложения. Другими словами, приложение становится «отказоустойчивым». Горизонтальное масштабирование позволяет минимально связывать разные части проекта (веб-сервер, базу данных и т. д.), потому что каждая из них запускается на разных серверах. Наконец, может наступить такой момент, когда вертикальное масштабирование более невозможно, так как в мире нет достаточно мощного компьютера для выполнения всех вычислений приложения. Поисковая платформа Google является типичным примером, хотя это относится и к компаниям с гораздо меньшими масштабами. Например, Storyblocks обычно использует от 150 до 400 AWS-машин EC2 в любой момент времени. Было бы сложно получить всю эту вычислительную мощность с помощью вертикального масштабирования.

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

Вот и всё. Концептуально балансировщики нагрузки довольно просты и понятны.

3. Серверы веб-приложений

Если смотреть издалека, серверы веб-приложений относительно просты. Они выполняют основную бизнес-логику, которая обрабатывает запрос пользователя и отправляет HTML обратно браузеру. Чтобы выполнять свою работу, они обычно общаются с различными бэкэнд-инфраструктурами, такими как базы данных, серверы кэширования, очереди заданий, службы поиска и т. д. Как упоминалось выше, обычно есть как минимум два, а то и больше, сервера, подключённых к балансировщику нагрузки для обработки пользовательских запросов.

Для реализации сервера приложений требуется выбрать конкретный язык (Node.js, Ruby, PHP, Scala, Java, C#, .NET и т. д.) и MVC-фреймворк для этого языка (Express для Node.js, Ruby on Rails, Play для Scala, Laravel для PHP и т. д.).

4. Сервер баз данных

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

Здесь стоит упомянуть SQL и NoSQL.

SQL расшифровывается как «Structured Query Language» (язык структурированных запросов). Он был изобретён в 1970-х годах, чтобы создать стандартный способ запросов к реляционным наборам данных, доступных широкой аудитории. SQL-базы данных хранят данные в таблицах, которые связаны между собой общими ключами. Такие ключи обычно представлены целыми числами.

Рассмотрим типичный пример хранения информации об истории адресов пользователей. Получатся две таблицы — user и user_addresses, — связанные друг с другом идентификатором пользователя (id в таблице user). Их можно увидеть на изображении ниже. Таблицы связаны, потому что столбец user_id в user_addresses является «внешним ключом» в столбце id в таблице users.

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

NoSQL расшифровывается как «не-SQL» и представляет собой более новый набор технологий баз данных. Он был разработан для обработки очень больших объёмов информации, которые могут генерироваться крупномасштабными веб-приложениями. Большинство вариантов SQL плохо масштабируются горизонтально, а масштабироваться вертикально могут только до определённого момента. Если вы ничего не знаете о NoSQL, рекомендуем начать знакомство со следующих статей:

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

5. Кэширование

Служба кэширования предоставляет простое хранилище данных в формате ключ-значение, которое позволяет хранить и искать информацию за время, близкое к линейному (O(1)). Обычно приложения используют функции кэширования, чтобы сохранять результаты дорогостоящих вычислений и воспользоваться ими позже из кэша, а не пересчитывать их еще раз. Приложение может кэшировать результаты запроса в базы данных, результаты обращения к внешним службам, HTML для заданного URL-адреса и многое другое. Вот некоторые примеры из реального мира:

  • Google кэширует результаты поиска для популярных поисковых запросов, таких как «собака» или «Тейлор Свифт», а не ищет их каждый раз заново;
  • Facebook кэширует большую часть данных, которые вы видите при входе в систему, например, списки постов или друзей. Подробнее, о технологии кэширования используемого в Facebook, можно почитать в этой статье на Medium;
  • Storyblocks кэширует HTML-страницы от React, результаты поиска и другое.

Двумя наиболее распространёнными технологиями кэширования являются Redis и Memcache.

6. Очереди задач

Большинству веб-приложений требуется выполнять некоторую работу, напрямую не связанную с ответом на запросы пользователей, асинхронно, в фоновом режиме. Например, Google должен сканировать и индексировать весь интернет, чтобы возвращать релевантные результаты поиска. Он не делает это при каждом запросе, а сканирует сеть асинхронно, обновляя поисковые индексы «по пути».

Выполнять асинхронную работу позволяют разные архитектуры, но наиболее распространённой является архитектура «очередь задач». Она состоит из двух компонентов: очереди «заданий», которые необходимо выполнить, и одного или нескольких рабочих серверов (часто называемых «работниками»), которые обрабатывают задания из очереди.

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

Например, в Storyblocks очередь заданий используется для выполнения многих скрытых работ, необходимых для поддержания проекта: кодирование видео и фотографий, обработка CSV-файлов для тегов метаданных, агрегирование статистики пользователей, отправка писем с паролями для сброса и т. д. Со временем проект отказался от простой очереди FIFO в пользу приоритетной очереди, чтобы операции с фиксированным временем выполнения, такие как отправка писем о сбросе пароля, были завершены как можно скорее.

Сервера заданий выполняют задания из очереди. Они запрашивают её, чтобы определить, есть ли работа, и если есть, — приступают к выполнению.

7. Полнотекстовый поиск

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

В этом примере три заголовка документов преобразуются в инвертированные индексы, что облегчает поиск по определённому ключевому слову среди документов с этим ключевым словом в заголовке. Обратите внимание, что обычные слова, также называемые стоп-словами («in», «the», «with» и т. д.), обычно не включаются в инвертированный индекс.

В действительности можно выполнять полнотекстовый поиск непосредственно из некоторых баз данных (например, его поддерживает MySQL), но обычно принято запускать отдельную службу, которая вычисляет и сохраняет инвертированные индексы и предоставляет интерфейс для запросов. Самая популярная полнотекстовая поисковая платформа сегодня — Elasticsearch, хотя есть и другие варианты, такие как Sphinx или Apache Solr.

8. Службы

Когда приложение достигает определённого масштаба, как правило, появляются определённые «службы», созданные специально для запуска в виде отдельных приложений. Они не выставлены на всеобщее обозрение, но приложение и другие службы взаимодействуют с ними. Например, в Storyblocks имеются несколько операционных и плановых служб:

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

9. Хранилище данных

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

  1. Приложение отправляет данные в «firehose»-хранилище, которое обеспечивает потоковый интерфейс для поглощения и обработки данных. Как правило, это информация о действиях пользователей. Часто необработанные данные преобразуются или дополняются и передаются в другие «firehose»-хранилища. Наиболее распространённые технологии для этого процесса — AWS Kinesis и Kafka.
  2. Исходные, а также окончательно преобразованные и дополненные данные сохраняются в облачном хранилище. AWS Kinesis предлагает сервис под названием Firehose, который позволяет сохранять необработанные данные в облачном хранилище (S3), которое чрезвычайно просто в настройке.
  3. Преобразованные и дополненные данные загружаются в хранилище данных для анализа. Типичным примером является AWS Redshift, им пользуется большинство стартапов, хотя крупные компании предпочитают решения от Oracle или другие проприетарные технологии хранения. Если наборы данных достаточно велики, то для анализа может потребоваться технология NoSQL MapReduce, например, Hadoop.

На диаграмме не изображён ещё один шаг: загрузка данных из приложения и баз данных различных служб в хранилище. Например, Storyblocks каждую ночь загружает VideoBlocks, AudioBlocks, Storyblocks, службу учётных записей и базы данных портала разработчиков в Redshift. Это даёт аналитикам целостное представление, так как основные бизнес-данные и данные действий пользователей хранятся в одном и том же месте.

10. Облачное хранилище

«Облачное хранилище — простой и масштабируемый способ для хранения и обмена данными через интернет». Такое определение дано AWS. Его можно использовать для хранения и доступа к чему угодно, что можно хранить в локальной файловой системе, пользуясь преимуществами RESTful API через HTTP. Решение от Amazon S3 на сегодняшний день является самым популярным облачным хранилищем, и его широко используют в Storyblocks для хранения видео-, фото- и аудиофайлов, CSS- и JavaScript-файлов, данных действий пользователей и многого другого.

11. CDN

CDN расшифровывается как «Content Delivery System» (система доставки контента). Эта технология позволяет намного быстрее, чем с исходного сервера, отправлять статические HTML-, CSS-, JavaScript-файлы и изображения. Она распространяет контент из многих «конечных» серверов по всему миру, чтобы пользователи загружали различные ресурсы из них вместо исходного сервера. Например, на изображении ниже пользователь из Испании запрашивает веб-страницу с сайта, серверы которого находятся в Нью-Йорке, но статические ресурсы для этой страницы загружаются с «конечного» сервера CDN в Англии, предотвращая медленные кросс-атлантические HTTP-запросы.

Страница

Библиотека программиста


1 488 записей Показать все записи

Подборка материала по web разработке

​Руководство по выживанию веб-девелопера: основы DNS
https://proglib.io/p/dns-basic

​Элементы CSS: селекторы и позиционирование c примерами
https://proglib.io/p/css-handbook

​8 самых распространенных ошибок веб-разработчика
https://proglib.io/p/top-webdev-error

​Мастер отзывчивого дизайна за 5 минут: 4 секретные техники
https://proglib.io/p/responsive-design

​Список лучших CSS фреймворков для фронтенд-разработки
https://proglib.io/p/css-frameworks

Вебхуки: как получать данные без промедления и опросов API

Простыми словами объясняем, чем вебхуки отличаются от API, как их безопасно использовать и создавать на примере GitHub.

Используете ли вы в своей практике вебхуки?

Верстка сайта на Grid. Быстрый старт

В данном видеоуроке вы познакомитесь с макетом, который в последующих уроках будет сверстан.

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

Modern Web Development on the JAMstack (2020)
Автор: Mathias Biilmann

Целевая аудитория: опытные пользователи и разработчики.

Запуск веб-проектов без единого сервера возможен с помощью JAMstack. Эта книга о современной архитектуре веб-разработки для развертывания быстрых, масштабируемых сайтов и приложений, для которых не требуется традиционная исходная инфраструктура.

В книге рассматриваются следующие темы:
методы решения задач веб-разработки;
почему более чистая архитектура JAMstack устраняет необходимость масштабирования сайтов заранее;
как отделение внешнего интерфейса от процесса сборки облегчает обслуживание;
лучшие практики для принятия JAMstack в вашей организации;
тематическое исследование, в котором рассматривается, как Smashing Magazine применил JAMstack для коммерции, аутентификации и членства, а также публикации в масштабе.

Преимущества:
хорошее введение в основы;
актуальный материал по теме.

Руководство по выживанию веб-девелопера: основы DNS

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

Как выжить в лесу, если заблудился? Топ 7 базовых советов.

Вы когда-нибудь были одни в лесу? Представьте, что вы любуетесь дикими цветами или верхушками деревьев? И вдруг вы внезапно осознали, что не знаете, где вы находитесь, и вокруг никого.

4 вещи, которые вам нужно знать о химической атаке

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

Какую собаку завести выживальщику? 7 лучших пород собак в постапокалипсис.

Собаки были первым животным, которое было одомашнено, и в течение последних 20 000 лет или около того верой и правдой служили другом и хорошим помощником человеку. За это время путем кропотливой селекции человек вывел тысячи различных пород под разные задачи.

10 советов как выжить при массовом расстреле

Стрельба в местах массового скопления людей, к сожалению, перестала быть исключительно американской историей. Трагедия в Керчи заставила всех говорить о усилении контроля над оружием, как обычно бывает после таких происшествий. Массовые расстрелы ужасают. Они случаются неожиданно и пострадать может каждый.

Мастер Йода рекомендует:  Покажем, как использовать docker-compose для Python и Jupyter

Мелаллоискатель. Польза для Выживальщика.

У многих начинающих и не очень выживальщиков может возникнуть вопрос, может ли быть полезен для выживания металлоискатель? И стоит ли тратить деньги на его покупку при подготовке к БП или от менее глобальных угроз?

14 пунктов подготовки к грядущему финансовому кризису

Финансовые кризисы в условиях капиталистического устройства экономики – это неизбежность. Дефолт 1998-го года в России унес больше жизней, чем все чеченские войны вместе взятые. Курс рубля за несколько месяцев упал к доллару на 400%, инфляция, падение производства, безработица и тотальная нищета – настоящий экономический апокалипсис.

8 угроз с которыми вы столкнетесь в городе во время БП.

Начнем с мрачного заявления: если вы живете в мегаполисе, таком как, например, Москва, ваши шансы на выживание относительно низки в случае крупномасштабной катастрофы. Думаете, я преувеличиваю?

Теракт в Метро. Несколько советов по выживанию!

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

Что делать, если провалился под лёд?

Основной причиной возникновения чрезвычайной ситуации на льду можно назвать нарушение техники безопасности!

Полное руководство по настройке DNS TTL (Перевод)

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

Ниже представлен перевод статьи для «самых маленьких» администраторов https://blog.varonis.com/definitive-guide-to-dns-ttl-settings/. А после статьи моё послесловие и несколько полезных ссылок.

Примечание к переводу: (DNS) lookup и request должны переводится по разному, но в русском варианте обычно используется только слово запрос. Слово resolve, имеющее перевод разрешать выглядит дико (разрешить ребёнку взять пирожок с полки? при этом «разрешающая способность» звучит вполне привычно), поэтому перевожу как возвращать или обрабатывать, хотя большинство инженеров использует прямое прочтение резолвить.

Введение

DNS является основополагающей частью [любой] технологии. Почти каждый сетевой запрос на уровне приложений, весь интернет трафик, веб поиск, электронная почта и т.д. полагаются на способность [службы] DNS возвращать ответы на запросы (переводить имена, такие как some.domain.org, в IP адреса или другие домены).

Мы хотели написать о Time To Live (TTL), так как большинство системных администраторов ежедневно не взаимодействуют с конфигурациями DNS, и большая часть информации, которая там есть, основана на полузабытых холиварах, полученных в наследство от предыдущих поколений системных администраторов.

Мы спросили в Твиттере, и некоторые системные администраторы даже не были точно уверены в том, что означает TTL (хотя большинство, к счастью, знали).

Riddle me this! With respect to DNS, what does TTL stand for?

Чтобы помочь в этой ситуации, мы рассмотрим:

  1. Основы DNS и TTL
  2. Траблшутинг DNS TTL
  3. Лучшие практики для изменения DNS записей
  4. Инструменты DNS
  5. Следующие шаги

1. Основы DNS

Что такое DNS запись?

Записи сервера доменных имен (DNS) определяют две важные вещи:

Куда должны указывать (где обрабатываться) запросы к записи.
Как долго запись может быть кэширована до ее повторного запроса – это зловеще называется Time To Live (TTL) записи.

Почему DNS кэшируется?

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

Что такое TTL?

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

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

Каковы типичные интервалы TTL для DNS записей?

Значения TTL всегда представлены в секундах. Большинство служб настройки конфигурации DNS предоставляют вам предварительно заданный список значений для использования в записях.

300 секунд = 5 минут = «Очень короткий»
3600 секунд = 1 час = «Короткий»
86400 секунд = 24 часа = «Длинный»
604800 секунд = 7 дней = «Безумие»

Как работают DNS запросы?

Когда вы вводите URL адрес в своём браузере, создается целая серия запросов:

На каждом этапе этого процесса задаются следующие вопросы: (часто шагов больше, чем перечислено здесь)

  1. У нас есть эта запись в кэше?
  2. Если она кэширована, остается ли TTL действительным?

Если ответ на любой из этих вопросов «нет», то запрос перемещается на следующий шаг вверх по цепочке.

Почему DNS относится к сетевым подключениям, а не к устройствам

Устранение неполадок DNS сложно не только потому, что TTL и система кэширования вносят сложности, а потому, что многие современные устройства подключаются через разные сети и цепочки DNS серверов.

Рассмотрим обычный портативный компьютер. Мой более или менее «приклеен» к столу, и хотя он не двигался неделями, я подключился к:

  • Моей обычной домашней Wi-Fi / кабельной сети;
  • Моему сотовому телефону, когда кабельная сеть не работала;
  • Оба вышеуказанных способа, но с подключенным VPN.

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

Это часто происходит в корпоративных сетях, где домен Active Directory совпадает с веб сайтом компании. Внешний DNS сервер (на уровне ISP) имеет DNS запись, которая указывает «www.example.com» на правильный IP адрес веб сервера / CNAME, но на внутреннем сервере DNS, используемом Active Directory, записи не были зеркалированы.

Так что вы получите паникующих людей. «Веб сервер не работает!», «Небо падает», «Где мои штаны?»… и когда вы начнете устранять неполадки, вы обнаружите, что на самом деле произошло то, что они оставили свою VPN сеть подключенной (прим. пер.: “The webserver is down!” – посмотрите это видео, “the sky is falling” – своего рода «игра», когда вы говорите своему другу «небо падает», и тут же ударяете его кулаком по голове, “where are my pants?” – фобия остаться без штанов в публичном месте и приколы и игры основанные на ней).

Прим. пер.: почитайте про утечку DNS в Windows https://habrahabr.ru/post/264503/

2. Траблшутинг DNS TTL

Траблшутинг – поиск и устранение неполадок.

Сколько времени займет обновление моего DNS?

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

Так что, если ваш TTL составляет 3600 секунд (1 час), и есть 5 шагов, он не должен занимать более 18 000 секунд (5 часов), чтобы изменения полностью распространились.

Сколько стоит DNS запрос?

Когда вы спрашиваете, сколько DNS запрос «стоит», вы обычно не беспокоитесь о деньгах. Вы беспокоитесь о времени. В зависимости от остального зоопарка сетевых уродцев, запрос DNS обычно занимает от 100 до 200 миллисекунд.

Хотя это очень небольшое количество времени, рассмотрим веб страницу. Для каждого изображения, файла css и файла ресурсов javascript, на которые ссылается страница, необходимо вернуть их DNS записи. Без кэширования вы бы значительно увеличили время загрузки.

Наивные вычисления стоимости DNS

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

С кэшированием
(30 файлов изображений * 50 мс для загрузки каждого из них) + (100 мс одно время запроса DNS, который затем кэшируются) = 1600 мс

Без кэширования
(30 файлов изображений * 50 мс для загрузки каждого из них) + (30 * 100 мс время запроса DNS) = 3000 мс

Почему мое обновление DNS не выполняется?

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

  • Веб браузеры внутренне кэшируют DNS записи для периодов времени, не контролируемых TTL, чтобы казаться «быстрее». Например, современные версии Internet Explorer кэшируют DNS на 30 минут по умолчанию (до IE 4 это было 24 часа) и будут игнорировать TTL ниже этого значения.
  • Мобильные интернет провайдеры могут стремиться уменьшить общий трафик за счет увеличения времени TTL, уменьшая частоту выполнения запросов.
  • Сложные внутренние сети с бóльшим количеством DNS серверов, чем вы ожидали, естественно, потребуют больше времени для обновления.

Вышеупомянутое является причиной, по которой большинство служб содержат что-то вроде: «Для того, чтобы изменения DNS полностью распространились, может потребоваться несколько дней, планируйте соответственно».

Есть ли способ заставить клиента обновлять свои DNS записи удаленно?

Обычно этот вопрос задают в контексте: «Я обновил мои DNS записи, и теперь клиент не может связаться с каким-либо сайтом, как я могу принудительно выполнить обновление?»

К сожалению, ответ «нет». Не существует команды конфигурации DNS, которую вы можете ввести для принудительного досрочного обновления у нижестоящих клиентов.

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

Ваш лучший выбор – изменить TTL для ваших записей заранее.

3. Лучшие практики для изменения DNS записей

Что лучше: короткий или длинный TTL?

Разработчики долгое время ведут холивары по поводу того, должны ли отступы в коде быть табуляторами или пробелами. Я обнаружил, что сетевые администраторы испытывают нечто похожее по отношению к величине TTL.

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

DDOS атака, которая нарушает работу DNS серверов на корневом / ISP серверах в течение 12 часов, будет иметь меньшее влияние на сайты с очень длинным TTL. Длинный TTL позволяет клиентам продолжать работать, даже когда DNS сервер находится в оффлайне или перегружен.

Но если вы надумали переключить веб узел или сервер электронной почты, и изменили DNS запись, то последнее, что вы хотите, это получить ситуацию, когда изменения заморозятся на 12 часов. И потому есть люди, которые отстаивают TTL со значением в минуту.

Мое личное предпочтение – иметь короткие (менее 1 часа / 3600 секунд) интервалы TTL.

Как узнать, когда клиент запросит обновленную DNS запись?

Очень сложно оценить когда все клиенты будут обновлены.

Смотрите, TTL – это не «дата свежести». Не рассматривайте DNS TTL как дату «годен до» на несвежей буханке хлеба – это не исключительное время, когда запись превращается из хорошей в плохую и нуждается в замене.

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

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

Затем в момент, отмеченный ярко-красным цветом, у нас обновляется DNS запись, записи в остальных кэшах становятся неактуальными и обновление начинает распространяться вниз по цепочке в сторону клиента.

Какова наилучшая практика для изменения DNS записи?

Для чего-то относительно простого, например, для изменения одной записи в домене, может показаться излишним иметь «план» или «стратегию», но, учитывая очень серьезную критичность DNS, необходимо проявлять осторожность. Это как старая поговорка: «щепотка загодя стоит пуда после» (прим. пер.: русский аналог – «предотвратить легче, чем лечить», или «дорого яичко ко христову дню»).

Есть простой способ ограничить свои ошибки: никогда не обновляйте одновременно DNS запись и TTL для этой записи. В идеале у вас будет следующий процесс:

  1. Уменьшите TTL для DNS записи до очень низкого значения за пару дней до того, как вам действительно нужно будет сделать переключение. Например: 300 секунд;
  2. Измените фактическую запись в день переключения;
  3. Через несколько дней после того, как вы сделали переключение, увеличьте TTL до более высокого значения.

Какова лучшая практика для добавления новой DNS записи?

Добавление новых записей проще, чем изменение существующих.

  1. Добавьте запись с низким TTL.
  2. После того, как вы убедитесь, что все работает, увеличьте значение TTL.

Какое значение TTL самое распространенное?

Так много споров вокруг того, какими должны быть ваши настройки TTL, что мы подумали, что попытаемся сформировать какие-то жесткие данные. Сайты Moz Top 500 представляют собой отличное сечение веб сайтов, и они уже проделали большую работу, поместив их все в CSV файл.

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

Анализ TTL Top 500 Moz доменов

Посмотреть / изменить сценарий или загрузить и запустить его самостоятельно: https://gist.github.com/mbuckbee/79b2e76bd9271bea38487defd8a9138b

Посмотреть список и загрузить CSV: https://moz.com/top500

Самый низкий TTL: 1
Самый высокий TTL: 129 540
Количество доменов: 485
Средний TTL: 6468
Медиана TTL: 300

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

С точки зрения необходимости отстаивать решение о том, чтобы иметь короткий (менее 1 часа, 3600 секунд) TTL, вы можете указать на среднее значение 300 секунд (5 минут) и уверенно заявить, что у вас есть эмпирические данные о том, каким должно быть значение.

4. Инструменты платформы DNS

Как проверить TTL DNS записи в Windows?

Утилита nslookup https://technet.microsoft.com/ru-ru/library/bb490950.aspx это самый простой способ проверки DNS записей в Windows

Пример: nslookup -type=cname -debug www.varonis.com

TTL указан в нижней части вывода. «Non-authoritative answer» (не авторитетный ответ) указывает, что это TTL, как его видно от клиента (у нас есть 2 минуты и 11 секунд, пока локальный клиент не проверит следующий уровень в DNS).

Как проверить TTL DNS-записи на Unix / Linux / Mac?

В Unix (и производных) систем для поиска неисправностей используется команда dig (хотя nslookup обычно тоже в наличии).

Пример: dig www.varonis.com

Значение TTL выделено красным цветом.

Как проверить DNS запись из Интернета?

Вы не всегда имеете доступ к своему компьютеру когда вам нужно проверить DNS запись. Удобная (и бесплатная) версия dig доступна в Интернете с помощью Google по адресу: https://toolbox.googleapps.com/apps/dig/

Значение TTL выделено красным цветом.

Прим. пер.: гугл почему-то убрал возможность выбора сервера для запросов, хотя во всплывающей подсказке упоминание об этом осталось, поэтому используйте альтернативные сервисы, например: https://www.kloth.net/services/dig.php или https://www.logicalpackets.com/NSLookup/Nslookup.asp

Как проверить распространение DNS TTL?

Если вы пытаетесь выяснить, произошло ли обновление ваших настроек DNS на определенном сервере, все перечисленные инструменты (dig, nslookup и др.) позволяют указать, к какому DNS серверу вы хотите выполнять запросы вместо локальных настроек по умолчанию.

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

5. Следующие шаги

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

Послесловие

Что меня бесило в начале знакомства с DNS:

  • В статьях тема DNS (S = system) обычно неразрывно связана с DNS server, причем эти темы переплетаются и люди сходу начинают рассказывать как настроить сервак, вместо рассказа про систему доменных имён.
  • DNS сервер это в 99% BIND (он же Named). По нему много документации, и как следствие, есть очень много противоречивых интерпретаций и мнений, поэтому советую читать оригинальную документацию https://www.zytrax.com/books/dns/ или наиболее близкие к ней переводы, например https://www.bog.pp.ru/work/dns_info.html и https://www.bog.pp.ru/work/bind.html.
  • Огромное количество вариаций конфигов для разных видов DNS серверов (Master, Slave, Cache, Stealth, Root https://info.nic.ru/st/8/out_256.shtml). Суть – разные виды серверов являются одним сервером с разными кейсами (сценариями) использования и как следствием – конфигом. Понимание сценария ведёт к пониманию того, что нужно подкрутить/добавить/убавить. Что если у вас нет понимания где брать типовые конфиги для данного сценария? Сложно сказать на счет русскоязычных источников, я обычно редко смотрю в закладки и каждый раз гуглю с чистого листа, но всё же рекомендую https://www.zytrax.com/books/dns/ch4/.
  • Люто, бешено бесило бесконечное описание различий параметров в разных версиях BIND в https://www.bog.pp.ru/work/bind.html. Даже не заморачивайтесь, открывайте документацию ТОЛЬКО к своей версии, а сомнительные опции либо игнорируйте, либо вычитывайте в оригинальных доках.

Типичная схема работы DNS из гуглокартинок:

  • Используйте этот классный пост Лучшие практики DNS для телекома, большинство пунктов не теряют свою актуальность.
  • Да и других интересных вещей там много: «Ультимативный DNS-дайджест»
  • Повторяя мысли из поста, добавлю, сначала добейтесь работоспособности вашего решения в самом общем виде, потом прикручивайте опции для защиты сервиса, а потом уже тюнингуйте.
  • Дизайн вашего решения, как взаимодействия нескольких серверов, так и содержания их конфигов должен быть достаточно прозрачен и логичен.
  • Никогда не применяйте изменения в нескольких разделах конфига сразу, быстро оценить изменения в работе сервиса довольно сложно. А неработающий DNS это автоматически неработающий интернет для 99% пользователей, или как минимум какой-нибудь сервис для части пользователей. Можно легко получить ситуацию, когда не будет работать какая-то отдельная комбинация из внешних/внутренних клиентов и типов запросов.
  • Используйте с осторожностью опции, относящиеся к безопасности, включайте логирование, следите за ресурсами сервера, прикрутите мониторинг к физическом серверу и DNS серверу (в смысле сервису). Кстати, у Fail2Ban есть шаблоны для DNS серверов.
  • Есть много статей по поводу тюнинга DNS серверов, сравнений между различными серверами и т.п. Имейте в виду что:
    • Серверы отличные от BIND/Named часто хуже документированы и менее надёжны в долгосрочной перспективе, либо узкоспециализированы.
    • Если у вас есть или планируется веб хостинг с панелью или DNS сервер используется внутри провайдера – ответ тот же, не надо пытаться использовать неправильный инструмент. А вот если у вас тестовый стенд, домашний сервак или маленькая конторка, то ради б-га.

Как работает Веб

На этой странице

Как работает Веб даст упрощенное представление о том, что происходит при просмотре веб-страницы в браузере на вашем компьютере или телефоне.

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

Клиенты и серверы

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

  • Клиенты являются обычными пользователями, подключенными к Интернету посредством устройств (например, компьютер подключен к Wi-Fi, или ваш телефон подключен к мобильной сети) и программного обеспечения, доступного на этих устройствах (как правило, браузер, например, Firefox или Chrome).
  • Серверы — это компьютеры, которые хранят веб-страницы, сайты или приложения. Когда клиентское устройство пытается получить доступ к веб-странице, копия страницы загружается с сервера на клиентский компьютер для отображения в браузере пользователя.

Остальные части панели инструментов

Клиент и сервер, о которых мы рассказали выше, не расскрывают всю суть. Есть много других компонентов, и мы опишем их ниже.

А сейчас давайте представим, что Веб — это дорога. Одна сторона дороги является клиентом, который представляет собой ваш дом. Другая сторона дороги является сервером, который представляет собой магазин. Вы хотите что-то купить в нём.

Помимо клиента и сервера, мы также должны уделить внимание:

  • Ваше Интернет-подключение: Позволяет отправлять и принимать данные по сети. Оно подобно улице между домом и магазином.
  • TCP/IP: Протокол Управления Передачей и Интернет Протокол являются коммуникационными протоколами, которые определяют, каким образом данные должны передаваться по сети. Они как транспортные средства, которые позволяют сделать заказ, пойти в магазин и купить ваши товары. В нашем примере, это как автомобиль или велосипед (или собственные ноги).
  • DNS: Система Доменных Имён напоминает записную книжку для веб-сайтов. Когда вы вводите веб-адрес в своем браузере, браузер обращается к DNS, чтобы найти реальный адрес веб-сайта, прежде чем он сможет его получить. Браузеру необходимо выяснить, на каком сервере живет сайт, поэтому он может отправлять HTTP-сообщения в нужное место (см. Ниже). Это похоже на поиск адреса магазина, чтобы вы могли попасть в него.
  • HTTP: Протокол Передачи Гипертекста — это протокол, который определяет язык для клиентов и серверов, чтобы общаться друг с другом. Он, как язык, который вы используете, чтобы заказать ваш товар.
  • Файлы компонентов: сайт состоит из нескольких различных файлов, которые подобны различным отделам с товарами в магазине. Эти файлы бывают двух основных типов:
    • Файлы кода: сайты построены преимущественно на HTML, CSS и JavaScript, хотя вы познакомитесь с другими технологиями чуть позже.
    • Материалы: это собирательное название для всех других вещей, составляющих сайт, такие как изображения, музыка, видео, документы Word и PDF.

Что же на самом деле происходит?

Когда вы вводите веб-адрес в свой браузер (для нашей аналогии — посещаете магазин):

  1. Браузер обращается к DNS серверу и находит реальный адрес сервера, на котором «живет» сайт (Вы находите адрес магазина).
  2. Браузер посылает HTTP запрос к серверу, запрашивая его отправить копию сайта для клиента (Вы идёте в магазин и заказываете товар). Это сообщение и все остальные данные, передаваемые между клиентом и сервером, передаются по интернет-соединению с использованием протокола TCP/IP.
  3. Если запрос клиента корректен, сервер отправляет клиенту статус «200 ОК», который означает: «Конечно, вы можете посмотреть на этот сайт! Вот он», а затем начинает отправку файлов сайта в браузер в виде небольших порций, называемых пакетными данными (магазин выдает вам ваш товар или вам привозят его домой).
  4. Браузер собирает маленькие куски в полноценный сайт и показывает его вам (товар прибывает к вашей двери — новые вещи, потрясающе!).

Реальные веб-адреса — неудобные, незапоминающиеся строки, которые Вы вводите в адресную строку, чтобы найти ваши любимые веб-сайты. Эти строки состоят из чисел, например: 63.245.215.20.

Такой набор чисел называется IP-адресом и представляет собой уникальное местоположение в Интернете. Впрочем, его не очень легко запомнить, правда? Вот почему изобрели DNS. Это специальные сервера, которые связывают веб-адрес, который вы вводите в браузере (например, «mozilla.org»), с реальным IP-адресом сайта.

Сайты можно найти непосредственно через их IP-адреса. Попытайтесь зайти на сайт Mozilla, набрав 63.245.215.20 в адресной строке на новой вкладке браузера.

Пакеты

Ранее мы использовали термин «пакеты», чтобы описать формат, в котором данные передаются от сервера к клиенту. Что мы имеем в виду? В основном, когда данные передаются через Интернет, они отправляются в виде тысячи мелких кусочков, так что множество разных пользователей могут скачивать один и тот же сайт одовременно. Если бы сайты отправлялись одним большим куском, тогда бы только один пользователь мог скачать его за один раз, и это, очевидно, сделало бы пользование интернетом не эффективным и не очень радостным.

Добавить комментарий