5 марта 2021 года Роскомнадзор сообщил, что ведомство подготовило и отправило в суд протоколы об административных правонарушениях на социальные сети Facebook, Instagram, Twitter, TikTok, «ВКонтакте», «Одноклассники», Telegram и видеохостинг YouTube.

12 мая 2021 года мировой судья Таганского района Москвы назначил Telegram два штрафа на основе протоколов Роскомнадзора на общую сумму 5 млн рублей. Административные наказания были наложены за неудаление мессенжером запрещенного в России контента по требованию РКН, в том числе публикаций с призывами к подросткам выйти на несанкционированные уличные акции в конце января этого года.

12 мая в мировой суд Таганского района Москвы поступили еще четыре новых протокола Роскомназора об административных правонарушениях в отношении Telegram. Суд все их рассмотрит 10 июня.

Сегодня хочу рассказать о том, как я начинал изучать основы HTTP протокола, прибегая к мануалам только в крайних случаях. Точно уже и не помню с какой целью мне понадобилось узнать как же все работает на самом деле, то ли я хотел заспамить какой-то провинившийся форум, то ли у меня были более благородные цели (хотя что может быть благороднее чем заспамить неугодный форум?). Так или иначе, в моей голове созрела мысль: нужно узнать, как работает HTTP протокол.

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

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

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

1. Создаеть небольшой скрипт на PHP, который будет запускаться на локальной машине для прослушки 80-го порта. Особенность скрипта в том, что он вываливает все полученные данные на экран, ничего не утаивая от моего пытливого взора;
2. В браузере открыть страницу с интересующей нас веб-формой ( это должно быть что-то на подобии www.some-url.com/webform.html);
3. Заполнить все поля формы;
4. Открыть файл hosts (в ОС Linux данный файл находится по адресу /ets/hosts, а в Windows ищите сами, бог знает куда ушлые ребята из Мелкософта могли его засунуть. Кто найдет, может отписаться в комментарии! :-))) ). В конец файла нужно дописать: 127.0.0.1 www.some-url.com
5. Вернуться в браузер и нажать кнопку “Отправить” (или какая там кнопка предусмотрена для отправки формы)

Собственно это все! В результате, наивный браузер отправит форму не на www.some-url.com, а нашему скрипту, который, в свою очередь, все отобразит на экране. Нам останется только проанализировать полученные данные (тут уж без мануала не обойтись, но, согласитесь, гораздо проще посмотреть пару тройку параметров, чем шерстить несколько десятков страниц).

Вероятно вы зададите вопрос, есть ли другие способы получить заголовки? Конечно есть, например, можно использовать снифер, или, скажем, специальные плагины для любимого барузера. Но мой метод тоже очень хорош, и вот почему:
1. Он простой! Даже первоклассник без труда сможет проделать все описываемые процедуры;
2. Он независим от браузера, в конечном итоге не браузерами одними жив HTTP протокол, есть еще RSS-ридеры и другие подобные программы;
3. Он кросплатформенный, безусловный плюс!
4. Он позволяет получить заголовки “как есть” и перенести в свою программу простым копи-пастом;
5. Он открывает обширные возможности для анализа и экспериментирования.

Собственно, это все.

— Оригинал HTTP протокол — это просто

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

SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи электронной почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.

Сразу отмечу, что в настоящее время SMTP в чистом виде практически не используется, т.к. он даже не поддерживает элементарно авторизацию… Используется ESMTP. Когда/если вы отправляете почту почтовым клиентом (Outlook, Thunderbird, Evolution, TheBat) происходит работа именно по этому протоколу.

Все началось с того, что стал падать мемкеш, вернее мемкешДб. И падал он как-то хитро. Переустановка мемкеш+мемкешДб+BerkeleyDb ничего не дала. После некоторых эмперических вычислений стало понятно, что падает на методе MultiGet, при том очень интересен тот факт, что падение зависит от порядка задания ключей и кол-во ключей должно быть более 3х.

Спасибо хабраюзеру hardex за публикацию первоначальной статьи, а также всем, кто плюсанул в карму для возможности моей собственноручной публикации. Теперь дополненная версия с учетом пожеланий и дополнений. Добро пожаловать под кат.

Уважаемые хабровчане, я хочу рассказать вам о сетях пакетной коммутации, построенных на основе протокола передачи данных ITU-T X.25. Мне посчастливилось заниматься сопровождением и развитием одной корпоративной сети X.25 на протяжении нескольких лет.

Я не ставлю целью рассказать именно о протоколе X.25, с ним можно ознакомиться в доступных источниках, я хочу поделиться своим опытом — что это было? зачем это было нужно? что из этого может пригодиться в будущем? Пишу по памяти, потому могу немного ошибаться или путать, что есть элементом стандарта, а что есть часть реализации

Как известно, Microsoft давно публикует протоколы и форматы данных своих серверных и прикладных программных продуктов. Сегодня в сеть выложены протоколы Microsoft Exchange Server 2010 SP1.

Для свободной загрузки доступно свыше 130 спецификаций протоколов используемых в Exchange Server 2010 SP1.

Кроме того, доступны для загрузки документы описывающие использование стандартов и RFC, таких как iCal, POP3, IMAP в Microsoft Exchange Server 2010 и Outlook 2010.

Сегодня обновлены и опубликованы спецификации на форматы файлов и протоколы продуктов Microsoft: Office и SharePoint.

Для загрузки доступны свыше 30 спецификаций форматов файлов Microsoft Office, около 70 протоколов Microsoft Office и около 230 спецификаций протоколов продуктов семейства SharePoint.

Ссылка

http://www.visualland.net/

Картинка

Примеры визуализаций

• Основы HSRP
• Основы DNS
• RFC2281 state table
• Dynamic NAT Basics

Все.

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

В этом посте я привожу интервью в несколько сокращенном виде, опуская моменты, по моему мнению не уместные на этом сайте.

— Как Вы пришли к идее создания BitTorrent? Это был плавный переход от работы над MojoNation или озарение?

— Нет, определенно не озарение.

— Нет?

— У меня уже был большой опыт сетевого программирования в MojoNation, да и до него тоже. Я в общем-то хотел совместить свои знания о том, что могло сработать и то что было интересным, но, как мне казалось, было сделано недостаточно правильно и должно было быть полностью переделано, с нуля. Я использовал весь этот опыт для создания BitTorrent, и сам по себе он не являлся одномоментным прозрением. В нем не было никакой “Wow!”-идеи. Это была просто комбинация достаточно прозаичных идей, собранных воедино и тщательно подготовленных, в итоге, вылившихся во что-то мощное.

Сообщество разработчиков Mozilla сейчас занимается разработкой новой системы авторизации пользователей на сайтах. По словам представителей команды разработчиков проекта BrowserID, пароли станут ненужными, если система получит широкое распространения. В общем-то, до «убийцы паролей» этот проект, вероятно, все же не дотягивает, но в качестве альтернативы OpenID платформа BrowserID представляет определенный интерес.

Проблемы высокоскоростной передачи данных

С ростом объёмов передаваемой по сети информации становится всё более актуальной проблема высокоскоростной передачи данных. Высокоскоростная передача данных, как правило, предполагает наличие между узлами сети канала связи с высокой пропускной способностью. При разработке канала с высокой пропускной способностью могут использоваться, как решения на основе медных электрических проводников, так и решения на основе оптических соединений. Любое соединение состоит из передатчика, передающего сигнал, и приёмника, принимающего сигнал. Сигнал по соединению может передаваться, как в одном, так и в двух направлениях. Так оптическое соединение может состоять, например, из оптического передатчика, оптического канала и оптического приёмника. В дуплексном режиме оптический приёмопередатчик обеспечивает, как передачу сигнала, так и приём сигнала по раздельным оптическим волокнам, находящимся, как правило, в одном оптоволоконном кабеле.

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

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

Какими свойствами и особенностями обладает хороший, годный грамотный, качественный протокол?

19 апреля 2012 г. в 16.00 Центр прикладных исследований компьютерных сетей при поддержке Кластера информационных технологий Сколково проводит семинар «Семейство алгоритмов Paxos».

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

Открытый протокол запросов OData базирующийся на REST, Atom/XML и JSON будет стандартизирован организацией OASIS, которая отвечает за утверждение промышленных стандартов в области веб-сервисов и передачи данных.

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

_http://services.odata.org/OData/OData.svc/Category(1)/Products?$top=2&$orderby=name

Просит выбрать из источника данных первые два продукта отсортированные по имени, которые принадлежат определенной категории товаров с идентификатором "1". Другой пример:

_http://services.odata.org/OData/OData.svc/ProductsByColor?color='red'

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

_http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=indexof(CompanyName, 'lfreds') eq 1

Вернет всех клиентов с именем компании, которая содержит подстроку "lfreds". И так далее. Подробное описание нотаций и самого протокола можно найти по адресу http://www.odata.org/documentation.