пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ CDR
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Пятая часть тут.
Когда транспортные протоколы «мечтают», они «мечтают» о приложениях? Скорее всего они должны это делать, поскольку основная цель сети - поддержка приложений, а основным ресурсом, который требуется приложениям из сети, являются данные, перемещаемые из одного процесса (или процессора) в другой. Но как можно передавать данные по проводу, по воздуху или по оптическому кабелю?
Пожалуй, лучше всего начать с более привычного примера: человеческого языка. Данные лекции написаны с использованием форматирования, языка и слов, позволяющего вам читать и понимать представленную информацию. Какие проблемы нужно преодолеть языку, чтобы общение, письменность и чтение стали возможными?
Мысли должны быть записаны в форме, которая позволяет их воспринимать получателем.
В человеческих языках информация упаковывается в слова, предложения, абзацы, главы и книги. Каждый уровень этого подразделения предполагает определенную единицу информации и определенную организационную систему. Например, звуки или идеи инкапсулируются в буквы или символы; звуки или идеи затем объединяются в слова; слова объединяются в предложения и т. д. Предложения следуют определенной грамматической форме, поэтому вы можете расшифровать значение символов. Такое кодирование мыслей и информации в символы, которое позволяет читателю (получателю) восстановить исходное значение, будет называться маршалингом данных в этих лекциях. Одним из аспектов маршалинга является определение-процесс привязки одного набора символов к определенному значению. Метаданные, или данные о данных, позволяют понять, как интерпретировать информацию в потоке.
Должен быть какой-то способ управления ошибками при передаче или приеме.
Предположим, у вас есть домашняя собака, которая любит гоняться за мячиком. Однажды мяч улетает на улицу. Собака мчится за мячиком и, кажется, она попадет под движущийся автомобиль. Что вы делаете? Возможно, вы кричите ей «Стоп!» — а потом, может быть, «Нет!» — и, возможно, «Остановись!». Использование нескольких команд, которые должны привести к одному и тому же действию - собака должна остановиться перед тем, как выбежать на улицу, - чтобы убедиться, что собака правильно получила и поняла сообщение. Вы надеетесь, что, если вы отправите несколько сообщений, вы убедитесь в том, что вы говорите, поймет собака, и у вас с ней нет недопонимания.
Это, по сути, форма исправления ошибок. Существует много видов исправления ошибок, встроенных в человеческий язык. Человеческие языки более точно определяют информацию, которую они содержат, поэтому несколько пропущенных букв не приводят к потере всего сообщения. Эта избыточная спецификация может рассматриваться как форма прямого исправления ошибок. Однако это не единственная форма исправления ошибок, которую содержат человеческие языки. Они также содержат вопросы, которые могут быть заданы для проверки, подтверждения или получения недостающих битов или контекста информации, ранее «переданной» через язык.
Должен быть какой—то способ поговорить с одним человеком или небольшой группой людей в большой толпе, используя единственную среду—воздух.
Это не редкость, когда нужно поговорить с одним человеком из комнаты, полной людей. Человеческий язык создал способы решения этой проблемы во многих ситуациях, например, называя чье-то имя или говоря достаточно громко, чтобы быть услышанным человеком, с которым вы непосредственно сталкиваетесь (другими словами, реализация языка может быть направленной). Способность говорить с одним человеком среди многих или с определенным подмножеством людей — это мультиплексирование.
Наконец, должен быть какой-то способ контролировать ход разговора.
С книгой все просто: писатель создает текст по частям, которые затем собираются в формат, который читатель может читать и перечитывать в совершенно ином темпе. Не многие люди думают о книге как о форме управления потоком, но перевод мыслей в письменную форму — это эффективный способ отключить скорость отправителя (скорость письма) от скорости получателя (скорость чтения). Разговорная речь имеет другие формы управления потоком, и остекленевший взгляд в глазах слушателя, когда он потерял линию рассуждения, за которой следует говорящий, или даже физические жесты, указывающие, что говорящий должен замедлиться.
Подводя итог, успешные системы связи должны решить четыре проблемы:
Упорядочивание данных; преобразование идей в символы и грамматику, понятную получателю
Управление ошибками, чтобы идеи правильно передавались от отправителя к получателю
Мультиплексирование или предоставление возможности использовать общую среду или инфраструктуру для разговоров между различными парами отправителей и получателей.
Управление потоком, или возможность убедиться, что получатель действительно получает и обрабатывает информацию, прежде чем отправитель передаст больше данных.
Начало 2019 года продолжило тренд на массовые утечки учетных данных. Если вы еще не знаете, то буквально в январе в сети была обнаружена крупнейшая база, содержащая более 773 миллионов уникальных email адресов и более 21 миллиона уникальных паролей. По оценкам специалистов, эта база была сформирована благодаря порядка 2000 известным взломам различных ресурсов, но источники около 140 миллионов email адресов и примерно 10 миллионов паролей – не удалось отнести ни к одной зафиксированной утечке. До недавнего времени, это была самая большая утечка учетных данных, когда-либо происходившая в Интернете. Данная база получила название Collection #1. По информации от человека ее обнаружевшего, количество строк в ней равняется 2,692,818,238, а весит она 87.18Gb.
Человека, который рассказал широкой общественности о данной проблеме, зовут Трой Хант (Troy Hunt). Он создатель ресурса Have I Been Pwned? (HIBP) и мы хотим, чтобы о нем узнало как можно большее количество людей!
Ресурс, созданный Троем, позволяет узнать – скомпрометирован ли адрес Вашей электронной почты, другими словами – замечен ли он в каких-либо известных утечках или нет. Просто введите адрес своей электронной поты в строку поиска и посмотрите, что ответит сайт!
Если ответ будет такой – поздравляем! Ваш email не замечен ни в одной известной утечке, пока… Почитайте советы о том как усилить безопасность.
А если после ввода своего адреса Вы увидите на экране такое:
То это значит, что пароль от вашего аккаунта, который зарегистрирован на данный почтовый ящик, на одном из взломанных ресурсов, может быть известен кому-то ещё кроме Вас, и что его необходимо срочно сменить. Кстати, в случае компрометации, сервис также покажет, в утечке на каком именно ресурсе был замечен Ваш email, а также время когда это произошло. В нашем примере таких утечек 5:
Кто-то может сказать - "Ну и что, что меня взломали, я например уже не давно пользуюсь этим аккаунтом". Опасность тут в том, что многие люди используют один и тот же пароль на всех ресурсах, а это значит, что если скомпрометирован один, то могут быть скомпрометированы все. Если Вы используете разные пароли на разных ресурсах - Вы восхитительны! Только делайте их сложными и устойчивыми к взлому. В этом Вам может помочь наш генератор устойчивых паролей.
Помимо этого, на ресурсе Троя можно также узнать скомпрометирован ли Ваш пароль, настроить уведомления о новых утечках и автоматической проверке Вашего email на предмет наличия в них, проверить есть ли скомпрометированные почтовые адреса в Вашем домене и даже - автоматизировать процесс проверки скомпрометированных учетных данных с помощью API!
Важно отметить, что HIBP не ставит соответствие email’а и пароля. Поэтому если Вы найдете скомпрометированный почтовый ящик, то не сможете узнать пароль от него и наоборот.
PS: Кстати, как оказалось потом, Collection #1 это лишь верхушка айсберга. В конце января 2019 года были обнаружены базы Collection #2-#5, а также AP MYR&ZABYGOR #2 и ANTIPUBLIC #1 общим весом 964,23 GB. После фильтрации дубликатов, исследователи пришли к выводу, что эти базы содержат объем данных, более чем в 3 раза превосходящий Collection #1. Это порядка 25 миллиардов записей email/пароль. Надеемся, то в скором времени и эта утечка появится на HIBP.
Седьмая часть тут.
Поля фиксированной длины - самый простой из описанных в словаре механизмов. Протокол определяет набор полей, какие данные содержит каждое поле и насколько велико каждое поле. Эта информация «встроена» в определение протокола, поэтому каждая реализация построена в соответствии с этими же спецификациями и, следовательно, может взаимодействовать друг с другом. Рисунок 1 иллюстрирует кодирование поля фиксированной длины, используемое в протоколе Open Shortest Path First (OSPF), взятом из RFC2328.
Ряд чисел в верхней части рисунка 1 указывает отдельные биты в формате пакета; каждая строка содержит 32 бита информации. Первые 8 битов указывают номер версии, вторые 8 битов всегда имеют номер 5, следующие 16 битов содержат общую длину пакета и так далее Каждое из этих полей дополнительно определяется в спецификации протокола с видом информации, переносимой в поле и как оно закодировано. Например:
Поле номера версии кодируется как целое число без знака. Это метаданные, указывающие словарь и грамматику, используемые для этого пакета. Если формат пакета необходимо изменить, номер версии может быть увеличен, что позволяет передатчикам и получателям использовать правильный словарь и грамматику при кодировании и декодировании информации в пакете
Число 5 указывает тип пакета в протоколе; это часть словаря, определенного в другом месте в документе стандартов, поэтому он просто вставляется как фиксированное значение на этом рисунке. Этот конкретный пакет является пакетом подтверждения состояния канала (Link State Acknowledgment Packet).
Длина пакета кодируется как целое число без знака, указывающее количество октетов (или наборов из 8 битов), содержащихся в полном пакете. Это позволяет размеру пакета варьироваться по длине в зависимости от объема передаваемой информации.
Формат поля фиксированной длины имеет несколько преимуществ. Прежде всего, местоположение любого фрагмента информации в пакете будет одинаковым для каждого пакета, что означает, что легко оптимизировать код, предназначенный для кодирования и декодирования информации вокруг формата пакета. Например, обычным способом обработки формата пакета фиксированной длины является создание структуры данных в памяти, точно соответствующей формату пакета; когда пакет считывается с провода, он просто копируется в эту структуру данных. Поля в пакете могут быть прочитаны напрямую.
Форматы фиксированной длины имеют тенденцию быть несколько компактными. Метаданные, необходимые для кодирования и декодирования данных, передаются «вне протокола» в форме спецификации протокола. Сами пакеты содержат только значение и никогда не содержат никакой информации о значениях. С другой стороны, форматы фиксированной длины могут тратить много места на буферизацию полей, чтобы они всегда были одинаковой длины. Например, десятичное число 1 может быть представлено одной двоичной цифрой (один бит), тогда как десятичное число 4 требует 3 двоичных цифры (три бита); если поле фиксированной длины должно быть в состоянии представить любое число от 0 до 4, оно должно быть длиной не менее 3 битов, даже если два из этих битов иногда «теряются» при представлении меньших десятичных чисел.
Форматы фиксированной длины также часто занимают место, выравнивая размеры полей по общим границам памяти процессора, чтобы повысить скорость обработки. Поле, которое должно принимать значения от 0 до 3, даже если для представления полного набора значений требуется только два бита, может быть закодировано как 8-битовое поле (полный октет), чтобы обеспечить всегда выравнивание следующего поля на границе октета для более быстрой обработки в памяти.
Гибкость - то, где кодирование фиксированной длины часто сталкивается с проблемами. Если какое-либо поле определено как 8-битное значение (один октет) в исходной спецификации, нет очевидного способа изменить длину поля для поддержки новых требований. Основной способ решения этой проблемы в схемах кодирования с фиксированной длиной - через номер версии. Если длина поля должна быть изменена, номер версии изменяется в форматах пакетов, поддерживающих новую длину поля. Это позволяет реализациям использовать старый формат, пока все устройства в сети не будут обновлены для поддержки нового формата; после того как все они обновлены, вся система может быть переключена на новый формат, будь то больше или меньше.