По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Управление кэш-памятью определяет поведение кэширования для веб-сайта, давая браузерам понять, как часто следует обновлять локально хранящиеся ресурсы. Что такое cache-control? Cache-control – это HTTP-заголовок, который определяет поведение браузера при кэшировании. Проще говоря, когда кто-то посещает веб-сайт, то его браузер сохраняет определенные ресурсы, такие как изображения и данные веб-сайта, в хранилище, которое называется кэш. Когда пользователь вновь посещает этот веб-сайт, то cache-control диктует правила, которые определяют, будут ли эти ресурсы загружены из локального кэша данного пользователя, или браузер должен отправить запрос на сервер для получения новых ресурсов. Для более глубокого понимания, что такое cache-control необходимо базовое понимание того, что такое кэширование в браузере и что такое HTTP-заголовки. Что такое кэширование в браузере? Как уже было описано выше, кэширование в браузере – это когда веб-браузер сохраняет ресурсы веб-сайта, чтобы не запрашивать их вновь с сервера. Например, фоновое изображение веб-сайта может быть сохранено локально в кэше, чтобы при повторном посещении пользователем данного веб-сайта изображение загружалось из локальных файлов пользователя, и тем самым страница загружалась бы быстрее. Браузеры хранят эти ресурсы в течение определенного периода времени, известного как время жизни информации (TTL - Time To Live). Если пользователь запросит кэшированный ресурс после истечения TTL, то браузеру придется снова обратиться к серверу, чтобы загрузить новую копию ресурса. Как браузеры и веб-серверы узнают TTL для каждого ресурса? Вот здесь в игру вступают HTTP-заголовки. Что такое HTTP-заголовки? Протокол передачи гипертекста (HTTP - Hypertext Transfer Protocol) представляет собой синтаксис для обмена данными во Всемирной паутине, и этот обмен данными состоит из запросов от клиентов к серверам и ответов от серверов к клиентам. Каждый из HTTP-запросов и ответов содержит ряд пар «ключ-значение», которые называют заголовками. Заголовки содержат большое количество важной информации о каждом сообщении. Например, заголовок запроса обычно содержит: Информацию о том, какой ресурс запрашивается Информацию о том, какой браузер использует клиент Информацию о том, какие форматы данных примет клиент Заголовки ответов обычно содержат информацию о: Успешности выполнения запроса Языке и формате любых ресурсов в теле ответа Заголовок cache-control может использоваться как в HTTP-запросах, так и в HTTP-ответах. Что находится внутри заголовка cache-control? Заголовки состоят из пар «ключ-значение», разделенных двоеточием. Для cache-control «ключ», или часть слева от двоеточия, - это всегда «cache-control». «Значение» - это то, что находится справа от двоеточия. Значений для cache-control может быть несколько, или оно может быть одно. Если их несколько, то они разделяются запятыми. Эти значения называются директивами, и они определяют, кто может кэшировать ресурс, а также как долго эти ресурсы могут быть кэшированными, прежде чем их необходимо будет обновить. Давайте рассмотрим несколько наиболее распространенных директив cache-control: cache-control: private Ответ с директивой private может быть кэширован только клиентом, но никак не посредником, таким как CDN или прокси-сервером. Часто сюда относятся ресурсы, которые содержат личные данные, например, веб-сайт, отображающий личную информацию пользователя. cache-control: public Здесь наоборот, директива public говорит о том, что ресурс может хранится в любом кэше. cache-control: no-store Ответ с директивой no-store нельзя кэшировать нигде и никогда. Это означает, что при каждом запросе пользователем этих данных, требуется отправить запрос на исходный сервер для их получения. Эта директива, как правило, используется для ресурсов, содержащих конфиденциальные данные, например, информацию о банковском счете. cache-control: no-cache Эта директива означает, что кэшированные версии запрошенного ресурса нельзя использовать без предварительной проверки наличия обновленной версии. Обычно это делается с помощью ETag. ETag – это еще один HTTP-заголовок, который содержит маркер, уникальный для версии ресурса на момент его запроса. Этот маркер меняется на исходном сервере при каждом обновлении ресурса. Когда пользователь возвращается на страницу с ресурсом под директивой no-cache, клиенту всегда придется подключаться к исходному серверу и сравнивать ETag на кэшированном ресурсе с ETag на сервере. Если они совпадают, то кэшированный ресурс предоставляется пользователю. В противном случае, это означает, что ресурс был обновлен, и клиенту необходимо загрузить обновленную версию, чтобы иметь возможность предоставить его пользователю. Этот процесс гарантирует, что пользователь всегда будет получать самую последнюю версию ресурса без ненужных постоянных загрузок. cache-control: max-age Эта директива определяет время жизни информации, или, иными словами, сколько секунд ресурс может находиться в кэше после его загрузки. Например, если max-age установлен на 1800, то это значит, что в течение 1800 секунд (30 минут) после того, как ресурс был впервые запрошен с сервера, пользователю будет предоставляться кэшированная версия этого ресурса при последующих запросах. Если пользователь запросит этот ресурс снова по истечении этих 30 минут, то клиенту необходимо будет запросить новую копию с исходного сервера. Директива s-maxage предназначена специально для общих кэшей, таких как CDN. Она определяет, как долго эти общие кэши могут продолжать обслуживать ресурс из кэша. Эта директива отменяет действие директивы max-age для некоторых клиентов. Почему cache-control так важен? Кэширование в браузере – это отличный способ сохранить ресурсы и, тем самым, улучшить процесс взаимодействия с пользователем в Интернете, но без cache-control этот процесс не был бы столь надежным. Все ресурсы на всех сайтах будут использовать одни и те же правила кэширования, а это значит, что конфиденциальная информация будет кэшироваться также, как и общедоступная информация, а ресурсы, которые часто обновляются, будут кэшироваться на то же время, что и ресурсы, которые редко обновляются. Cache-control добавляет гибкости, которая делает кэширование в браузере действительно полезным, позволяя разработчикам определять, как будет кэшироваться каждый ресурс. Этот заголовок также позволяет разработчикам устанавливать определенные правила для посредников, что является причиной, по которой сайты, которые используют CDN, как правило, работают лучше, чем сайты, которые этого не делают.
img
Разработка и тестирование (QA). Это безусловно крутое и востребованное направление, а спецов по ним на рынке разбирают как горячие пирожки. Но есть аспекты . без которых вся история с мобильными приложениями, сервисами в интернете, размещенными в облаках и продаваемая по модели SaaS/PaaS или любое другая программная сущность, к которой так или иначе подключаются удаленные пользователи - не заработает. Поговорим про роль человека, который разбирается в принципах построения сетей, коммутации, маршрутизации данных, о серверных инженерах, спецам по контактным центрам и так далее. Эти ребята не пишут код в IDE и не имеют тимлида. Но именно от их работы зависит то, будет ли "хрипеть" разговор в трубке телефона в компании, как быстро будут передаваться чувствительные к задержкам данные, и именно они спасут сеть на 10 000 человек от петли маршрутизации и широковещательного шторма. Цена ошибки таких людей - высока, от этого и ценность шарящего сетевика также высокая. В статье я расскажу об этом направлении, как в него попасть, сколько получают "сетевики", и за кем будущее в этой отрасли. МТУСИ Итак, свою историю я начну с прекрасного университета - МТУСИ (Московский технический университет связи и информатики). И именно этот университет посчастливилось закончить мне и большой части нашей команды. Вообще, как написано в википедии "Московский технический университет связи и информатики - российский отраслевой университет в области информационных технологий, телекоммуникаций, информационной безопасности и радиотехники." Теоретически, да и практически, львиную долю кадров будущих инженеров связи готовят именно тут. В какой компании не бывал, с кем не общался, будь то провайдер, банк или интегратор - мтусишники везде. Занимаются сетями передачи данных, телефонией, архитектурой систем передачи или информационной безопасностью. Университет - прекрасный. Преподавательский состав - прекрасный. Но материал, которому нас учили на 5 курсе университета в 2015 году был о том, как работает декадно шаговая АТС. Чтобы вы понимали, декадно шаговые АТС появились в СССР сразу после второй мировой войны. Забавно, но это была в прямом смысле громкая станция - там щетки скользили по специальным ламелям и издавали звуки. И вот спустя 70 лет, выпускаясь из университета, мы изучаем декадно - шаговый искатель. Кстати, вот он: Тогда как телефонные системы, которые на тот момент существовали в энтерпрайзе, с которыми нам реально предстояло работать выглядели вот так: В формате гибких программных приложений, в которых работают цифровые стандарты на базе IP протокола. Они имеют графический интерфейс на английском языке, а также программную консоль для более хардового управления, если хочется действительно залезть под капот. Само собой, проблема известная и касается не только университета связи. Вы смотрели интервью Юрия Дудя с экономистом Сергеем Гуриевым? Вы наверное помните, что там Дудь приводит цитату Гуриева, что он как - то сказал, что, "Российских студентов учат непонятно чему". На что Гуриев сказал, что рынок труда и российская система образования не связана, что плохо. И это правда. Выходя из стен университета, ты имеешь отличный разговорный навык, но не актуальный знания, которые ждет от тебя работодатель и рынок. Тут мы получили вывод №1: Курсы Cisco CCNA Я стал осознавать это примерно в конце второго курса, когда немного поработал в технической поддержке одного из интернет - провайдеров, который оказывал услуги для юридических лиц - это были каналы связи, услуги виртуальных частных сетей (VPN), телефонные номера. Это был клевый опыт, а особенно, я помню одного из ведущих инженеров - это был дядька, который также закончил МТУСИ. На 70 - 75% он состоял из русского мата, но привыкнув, из его поучительных речей, когда он заходил к нам в поддержку, я понял главное - знания, полученные уже, и те, которые предстоит получить в ближайшие 3 года обучения - мне не пригодятся. Кстати, здесь хорошо подходит старый мем (они даже немного похожи): Уже на стартовой позиции сотрудника технической поддержки меня окружали вендорные решения, то есть решения конкретных производителей: мультиплексоры Eltex, биллинговые системы, SFP модули, коммутаторы доступа, софт свичи, вендор Cisco. И тут к нам плавно пришло осознание: Что чтобы попасть во флоу, в рынок и в тренды, нужно учиться работать решениями, которые есть на рынке - то есть с решениями конкретных производителей. Причем не просто уметь кнопки нажимать и давать команды в консоли - а знать теория и глубоко понимать логику их работы. Вообще, учеба в МТУСИ проходит в двух зданиях - первые 2 года мы учились на октябрьском поле, а оставшееся время на Авиамоторной. Так вот, переехав на новую территорию к третьему году обучения, мы стали обращать внимание - в здании есть несколько учебных центров. Там был вендор Alcatel и Cisco. Решение учиться решениям вендора было принято сразу, вопрос был лишь в том - куда пойти - тут включились ассоциации: Алькатель ассоциировался с: А Cisco с городом Сан - Франциско: Через год обучения мы закончили курс Cisco CCNA (Cisco Certified Network Associate) по маршрутизации и коммутации - это наиболее распространённый сертификат из всей линейки сертификации Cisco. Еще через 2 месяца мы подтвердили свои знания и сдали экзамен на получение сертификата и к концу 3 курса уже смогли трудоустроиться на работу в системные интеграторы на полставки на базовые инженерные позиции. На самом деле, как я говорил раньше, наши ассоциации при выборе учебного центра нас не подвели. В энтерпрайзе (корпоративных ИТ инфраструктурах) решения на базе Cisco встречаются часто. Да и сама циска один из самых крупных вендоров телеком отрасли, а годных специалистов в России, которые могли бы работать с линейкой продуктов не так много. Тут мы получили вывод №2: Подвиды Поговорим про то, какие бывают ребята из отрасли обслуживания инфраструктур: Инженер по обслуживанию корпоративных систем связи - он же VoIP инженер. Этот человек хорошо разбирается в IP - телефонии, протоколах, знает стеку стека протоколов TCP/IP - зарплата от 50к на старте Инженер по обслуживанию инфраструктуры информационных систем - он же серверный инженер. Этот человек хорошо разбирается в серверной начинке, знает наизусть Linux Based и Windows системы, отличит первый рейд массив от пятого, знаком с Chef, Ansible и Puppet, и докером - зарплата от 65 - 70 тыр. на старте Инженер по обслуживанию корпоративной сетевой инфраструктуры - он же сетевик. Разбудив его ночью, он расскажет вам все про модель OSI, знает, как работают коммутаторы и маршрутизаторы нескольких вендоров, а на обеде расскажет вам все о протоколах маршрутизации трафика - от 50к на старте Это три основные направления в отрасли - безусловно их больше и всех перечислить не получится - обслуживание информационных систем (ПО, разный софт), филд инженер, который работает руками и монтирует железо, инженеры поддержки пользователей и так далее. С сетевиками и в целом, с этой категорией ребят все хорошо и они в тренде. Есть и будут еще долго. Но предлагаю смотреть дальше. DevOPS инженер Будущее за кросс-функциональными ребятами, которые не "заточены" под один продукт, а имеют широкий кругозор и знания. Именно тут появляется методология DevOps, которая является акронимом от development и operations - то есть от разработка и эксплуатация. Девопс инженер сочетает в себе множество знаний из смежных отраслей, которые особенно актуальны для компаний, занимающихся разработкой софта и управлением большим количество серверов. Дело в том, что при разработке, могут возникать случаи, когда что-то не работает, или работает не так, как хотелось бы: В таком случае разработчик говорит: Сетевик говорит: И понеслась. Вообще, системные администраторы или сетевые инженеры в одно время базово научились программировать, подарив миру такие продукты как Chef, Puppet или Ansible, которые служат для автоматизации работы серверов. Но так случилось не со всеми - кто то остаётся хардовым сетевым инженером, который на пальцах объяснит вам как работает протокол BGP, но совершенно не понимает в программировании. Решив проблему понимания между разработчиком и инфраструктурщиком. Тем самым, при достижении уровня понимания между этими ролями, компании могут достичь таких метрик как: Сокращение времени для выхода на рынок; Снижение частоты отказов новых релизов; Сокращение времени выполнения исправлений; Уменьшение количества времени на восстановления (в случае сбоя новой версии или иного отключения текущей системы). Итак, попробую сформулировать, по пунктам, что же должен уметь прекрасный DevOps инженер будущего: Легко ориентируется в Windows и Linux based системах. Знает инструменты для управления конфигурацией и автоматизации серверов Chef, Puppet, Ansible. Умеет писать скрипты. Минимум - на пайтоне Знает сетевые технологии на уровне Cisco CCNA Этого достаточно, чтобы уже получать в среднем по РФ 100-200 тысяч рублей. Что забавно: есть город, и это не Москва, где девопс получает получает 160-360 тысяч рублей в месяц. Как думаете какой? Правильный ответ - Питер. Именно там девопс оценивается больше всего. Связано ли это с климатом, подвернутыми штанами или очками с Толстой черной оправой - ответить сложно. Итоги Итак, мы поговорили о пути инженера по телекоммуникациями, сетевой инфраструктуре, системам связи и инфраструктуры информационных систем. Затронули наиболее быстрые пути развития, обсудили зарплаты на старте и поговорили о том, как стать прекрасным DevOps инженером будущего. Мы поняли, что ни один вуз не сделает из вас готового к рынку спеца, а чтобы быть таковым - нужно уметь работать с решениями конкретных вендоров, а проще всего это сделать с помощью авторизованных учебных центров. Задавайте вопросы в комментариях - помогу :)
img
Настройка RIPv2 (Routing Information Protocol v2) - крайне простой процесс и состоит из трех шагов: включения протокола глобальной командой router rip сменой версии протокола на вторую version 2 выбор сетей, которые протокол будет «вещать», для чего используется команда(ы) network; Первые две команды очевидны, но последняя команда требует объяснения: с помощью network вы указываете интерфейсы, которые будут участвовать в процессе маршрутизации. Данная команда берет классовую сеть как параметр и включает RIP на соответствующих интерфейсах. Пример настройки RIPv2 В нашей топологии у маршрутизаторов R1 и R2 есть напрямую подключенные подсети. Нам нужно включить данные подсети в процесс динамической маршрутизации RIP. Для этого нам сначала нужно включить RIP на обоих маршрутизаторах и затем «вещать» данные сети с помощью команды network. На маршрутизаторе R1 переходим в глобальный режим конфигурации и вводим следующие команды: router rip verison 2 network 10.0.0.0 network 172.16.0.0 Немного пояснений – сначала мы включаем протокол динамической маршрутизации, затем меняем версию на вторую, затем используем команду network 10.0.0.0 для включения интерфейса Fa0/1 на маршрутизаторе R1. Как мы уже говорили, команда network берет классовую сеть, так что каждый интерфейс с подсетью, начинающейся на 10 будет добавлен в RIP процесс. К примеру, если на другом интерфейсе будет адрес 10.1.0.1, то он тоже будет добавлен в процесс маршрутизации. Также нам необходимо соединить два маршрутизатора в RIP, для этого добавляем еще одну команду network – с адресом 172.16.0.0 IP-адреса начинающиеся на 10, по умолчанию принадлежат к классу «А» и имеют стандартную маску подсети 255.0.0.0. На R2 настройка выглядит похожей, только с другой подсетью – т.к к маршрутизатору R2 напрямую подключена подсеть 192.168.0.0. router rip verison 2 network 192.168.0.0 network 172.16.0.0 Как проверить таблицу маршрутизации? Для проверки, необходимо ввести команду show ip route - вы должны увидеть подсеть 192.168.0.0/24 на R1 и подсеть 10.0.0.0/24 на R2 отмеченных буквой R – то есть это RIP маршрут. Также там будет видна административная дистанция и метрика для данного маршрута. Административная дистанция – это некая степень доверия к протоколу, и у RIP данный показатель равен 120. В качестве метрики у RIP выступает число хопов между подсетями.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59