Есть мнение, что централизованный мессенджер и P2P-мессенджер — это две практически полностью различные задачи, имеющие минимальное пересечение. По сути, общее у них — только UX клиентов, поскольку всё остальное — суть, гарантированная доставка сообщений, звонков и файлов — будет кардинально отличаться (и в случае P2P будет сложнее на порядок). Пример Skype, в принципе, это подтверждает.
То есть P2P-Telegram, по сути, придётся с нуля писать.
Какая разница, чиновник, не чиновник? Есть журналистская этика. Записанное интервью принято отсылать на правку интервьюируемому, где интервьюируемый может выкинуть часть текста, вплоть до 100%. Никаких ограничений на личность интервьюируемого здесь нет, это просто правила, позволяющие разделять нормальную прессу и бульварную.
Ну вот недавно была история с Алексиевич, когда она в самом конце интервью запретила его публиковать. Журналист опубликовал, его уволили. Так что, видимо, может.
Никто не собирался блокировать Телеграм. По плану, Жаров должен был написать открытое письмо, которое Дуров гордо проигнорирует. После чего Ампелонский сделает вид, будто Телеграм подчинился, и всё продолжит работать. Так уже было с Threema и Imo, но сейчас что-то пошло не так.
Но всё равно — коммерческая компания, нацеленная на получение прибыли и ответственная за прибыль перед акционерами. Всё немного сложнее (см. конфликт по линии ВТБ).
Теоретически, можно отвязать частоты от операторов.
Установить официальную ставку на пользование сотовой инфраструктурой.
Не очень рыночный метод, ну так у нас тут и не рынок совершенно, а хронический картельный сговор на ограниченном ресурсе, так уж сложилось. В такой ситуации явное госрегулирование как раз показано, потому что в условиях неявного будет постоянно возникать место для коррупционной составляющей (вот прекратит сейчас ФАС расследование — и пойди пойми, почему), а без регулирования вообще это всё покатится под откос.
Обязать операторов предоставлять инфраструктуру для MVNO по установленным ставкам.
Это позволит повысить конкуренцию за клиента, а также позволит небольшим компаниям проверять тарифные и инвестиционные гипотезы без чрезмерных начальных капитальных вложений.
Ещё вариант — через Минкомсвязи и Ростелеком влиять на Tele2 и проталкивать адекватные тарифы явочным порядком на основе конкуренции. Но это сложно.
А написанный код, с учётом блокировки всех ресурсов Яндекса (для внутрикорпоративных и VPN в Указе исключений не сделано), пересылать Гмейлом? Или самолётом?
Единственный правильный шаг — это убрать свои сивые политические лапти от глобальной сети, которая была написана DARPA 50 лет назад в расчёте на устойчивость к атомной войне и в которой современные политики и политологи не смыслят ни зги. Вот просто признать свою некомпетентность и не трогать тут вообще ничего.
Не извиню, потому что это не я пишу глупости, это вы читаете не написанное мной, а что-то из своей головы.
Для разбора бинарных протоколов нужно меньше памяти, чем для разбора текстовых. Они по определению компактнее.
Заявление про «компактность по определению» в общем случае фактически неверно. Простой пример: запись числа «ноль» в текстовом протоколе JSON («0») занимает 1 байт, в то время как в его бинарной версии BSON она занимает 11 байт.
Поэтому рассмотрим не общий случай, а случай HTTP/2.
В современном WWW тела HTTP-ответов (то есть, контент) весят на порядки больше, чем заголовки. Web-страница, на которой мы сейчас общаемся, весит около 3,5 мегабайт и формируется 65 HTTP-запросами, что даёт нам около 55 килобайт на каждый ответ (и около 15 килобайт в среднем после gzip-сжатия), в то время как заголовки каждого что запроса, что ответа весят примерно 200-400 байт. И в доброй половине случаев это именно текст: HTML, CSS, Javascript, JSON, XML. С точки зрения памяти, бинаризация заголовков — это экономия на спичках.
Некоторая экономия могла бы быть разве что на стороне контент-сервера, который не парсит данные (включая тела POST- и других запросов), но вот беда: HTTP/2 на самом деле не вмешивается в сами заголовки, ограничиваясь сжатием и бинаризацией лишь формата передачи старого доброго текста. Ввиду этого что на сервере, что на клиенте памяти требуется ровно столько же, сколько и в HTTP/1. Более того, HTTP/2 добавляет обязательный overhead на хранение TLS-сессии, так что памяти требуется даже больше, чем в HTTP/1.
В обмен на эту экономию HTTP/2 нельзя диагностировать и отлаживать из обычной консоли tcpdump'ом, нужно, по совету его авторов, брать GUI-приложение. Это уже не говоря о том, что де-факто обязательное шифрование делает эту отладку ещё более трудоёмкой, а в ряде случаев вообще невозможной. То есть это не просто экономия на спичках, это, знаете, как в Советском Союзе: когда газ в квартирах оплачивался фиксированной суммой без счётчиков, люди, чтобы не тратить спички, просто не тушили конфорки и весь день жгли газ.
И да: можно было бы использовать для контента сжатие, но вот беда: ввиду всё того же шифрования и атак на него глава про сжатие в спецификации HTTP/2 написана эзоповым языком, предъявляет к реализациям протокола требование отличать конфиденциальные данные от неконфиденциальных (что вообще непонятно, как делать) и изобилует термином MUST NOT, что на практике будет в большинстве случаев приводить либо к отсутствию сжатия там, где оно надо, либо к компрометации данных там, где их нужно было защищать.
современный мир [..] требует шифрования
«Современный мир» не требует шифрования, его требуют определённые прикладные задачи, в то время как ряд других задач шифрования не требует. Именно по этой причине авторы HTTP/2 в конечном счёте не стали включать требования к шифрованию в спецификацию. Отсутствие поддержки HTTP/2 over TCP — это самодеятельность корпораций, выпускающих браузеры, что также многое говорит нам о характере развития протоколов в последние годы.
не только правительство, но и каждый вшивый провайдер желает посмотреть, чего я там по сети гоняю
Помните эту картинку?
Если правительство страны, где вы живёте, захочет узнать, чем вы занимаетесь, оно это узнает. Если вам это не нравится, вам нужно либо выбрать другое правительство, либо изменить род деятельности, либо сменить страну проживания. Повальное внедрение шифрования приводит к компрометации этого самого шифрования и на выходе обеспечивает лишь, в лучшем случае, невозможность тайного досмотра. В качестве побочного эффекта от неуклюжих действий правительства страдают невинные люди.
А по поводу IPv6 вам, очевидно, просто нечего было сказать.
Бинарный гипертекстовый протокол, не умеющий нормально работать с reverse proxy и не работающий без шифрования? Было бы неплохо, если бы мы его ещё лет 30 не увидели.
Современные программисты — а в большей степени их менеджеры — очень любят вдохновляться тем фактом, что во время оно оперативной памяти было 640 Кб, а сейчас 8 Гб. В результате чего даже на телефонах 1 Гб — это уже слишком мало, а на серверах память уже терабайтами начинают считать. А делают все эти устройства все примерно то же самое, только в тысячу раз неэффективнее.
Старые протоколы создавались в расчете на эффективность, а новые — в расчете на закон Мура. И в результате в IPv6 снова приходится в случае необходимости заблокировать доступ с одного адреса банить всю сеть, потому что а) SLAAC и б) таблица отдельных IPv6-адресов ни в какую таблицу в памяти не влезет никогда. При этом в IPv4 банить подсетями стало не модно ещё 10-15 лет назад. Легко видеть, что с теоретико-протокольной точки зрения у нас должен был быть прогресс, а с точки зрения решаемых практических задач случился регресс.
В этом и проблема современных протоколов: когда инженеры, задолбавшиеся ловить утечки памяти и воображающие себе гигабайты RAM, пишут протоколы с расчетом реализовывать их потом на Java и C#, в итоге каждый из десятка этих протоколов начинает требовать эти гигабайты себе единолично, а задачи по этому решает все те же, что и старый добрый протокол 1979 года о 2 мбайт памяти. И еще хорошо, если решает не хуже.
То есть P2P-Telegram, по сути, придётся с нуля писать.
Не очень рыночный метод, ну так у нас тут и не рынок совершенно, а хронический картельный сговор на ограниченном ресурсе, так уж сложилось. В такой ситуации явное госрегулирование как раз показано, потому что в условиях неявного будет постоянно возникать место для коррупционной составляющей (вот прекратит сейчас ФАС расследование — и пойди пойми, почему), а без регулирования вообще это всё покатится под откос.
Это позволит повысить конкуренцию за клиента, а также позволит небольшим компаниям проверять тарифные и инвестиционные гипотезы без чрезмерных начальных капитальных вложений.
Ещё вариант — через Минкомсвязи и Ростелеком влиять на Tele2 и проталкивать адекватные тарифы явочным порядком на основе конкуренции. Но это сложно.
Какая ещё репутация прахом. Менеджмент большинства клиентов не поймет всех этих объяснений. Rees легко смогут заболтать этот случай.
Заявление про «компактность по определению» в общем случае фактически неверно. Простой пример: запись числа «ноль» в текстовом протоколе JSON («0») занимает 1 байт, в то время как в его бинарной версии BSON она занимает 11 байт.
Поэтому рассмотрим не общий случай, а случай HTTP/2.
В современном WWW тела HTTP-ответов (то есть, контент) весят на порядки больше, чем заголовки. Web-страница, на которой мы сейчас общаемся, весит около 3,5 мегабайт и формируется 65 HTTP-запросами, что даёт нам около 55 килобайт на каждый ответ (и около 15 килобайт в среднем после gzip-сжатия), в то время как заголовки каждого что запроса, что ответа весят примерно 200-400 байт. И в доброй половине случаев это именно текст: HTML, CSS, Javascript, JSON, XML. С точки зрения памяти, бинаризация заголовков — это экономия на спичках.
Некоторая экономия могла бы быть разве что на стороне контент-сервера, который не парсит данные (включая тела POST- и других запросов), но вот беда: HTTP/2 на самом деле не вмешивается в сами заголовки, ограничиваясь сжатием и бинаризацией лишь формата передачи старого доброго текста. Ввиду этого что на сервере, что на клиенте памяти требуется ровно столько же, сколько и в HTTP/1. Более того, HTTP/2 добавляет обязательный overhead на хранение TLS-сессии, так что памяти требуется даже больше, чем в HTTP/1.
В обмен на эту экономию HTTP/2 нельзя диагностировать и отлаживать из обычной консоли tcpdump'ом, нужно, по совету его авторов, брать GUI-приложение. Это уже не говоря о том, что де-факто обязательное шифрование делает эту отладку ещё более трудоёмкой, а в ряде случаев вообще невозможной. То есть это не просто экономия на спичках, это, знаете, как в Советском Союзе: когда газ в квартирах оплачивался фиксированной суммой без счётчиков, люди, чтобы не тратить спички, просто не тушили конфорки и весь день жгли газ.
И да: можно было бы использовать для контента сжатие, но вот беда: ввиду всё того же шифрования и атак на него глава про сжатие в спецификации HTTP/2 написана эзоповым языком, предъявляет к реализациям протокола требование отличать конфиденциальные данные от неконфиденциальных (что вообще непонятно, как делать) и изобилует термином MUST NOT, что на практике будет в большинстве случаев приводить либо к отсутствию сжатия там, где оно надо, либо к компрометации данных там, где их нужно было защищать.
«Современный мир» не требует шифрования, его требуют определённые прикладные задачи, в то время как ряд других задач шифрования не требует. Именно по этой причине авторы HTTP/2 в конечном счёте не стали включать требования к шифрованию в спецификацию. Отсутствие поддержки HTTP/2 over TCP — это самодеятельность корпораций, выпускающих браузеры, что также многое говорит нам о характере развития протоколов в последние годы.
Помните эту картинку?
Если правительство страны, где вы живёте, захочет узнать, чем вы занимаетесь, оно это узнает. Если вам это не нравится, вам нужно либо выбрать другое правительство, либо изменить род деятельности, либо сменить страну проживания. Повальное внедрение шифрования приводит к компрометации этого самого шифрования и на выходе обеспечивает лишь, в лучшем случае, невозможность тайного досмотра. В качестве побочного эффекта от неуклюжих действий правительства страдают невинные люди.
А по поводу IPv6 вам, очевидно, просто нечего было сказать.
Современные программисты — а в большей степени их менеджеры — очень любят вдохновляться тем фактом, что во время оно оперативной памяти было 640 Кб, а сейчас 8 Гб. В результате чего даже на телефонах 1 Гб — это уже слишком мало, а на серверах память уже терабайтами начинают считать. А делают все эти устройства все примерно то же самое, только в тысячу раз неэффективнее.
Старые протоколы создавались в расчете на эффективность, а новые — в расчете на закон Мура. И в результате в IPv6 снова приходится в случае необходимости заблокировать доступ с одного адреса банить всю сеть, потому что а) SLAAC и б) таблица отдельных IPv6-адресов ни в какую таблицу в памяти не влезет никогда. При этом в IPv4 банить подсетями стало не модно ещё 10-15 лет назад. Легко видеть, что с теоретико-протокольной точки зрения у нас должен был быть прогресс, а с точки зрения решаемых практических задач случился регресс.
В этом и проблема современных протоколов: когда инженеры, задолбавшиеся ловить утечки памяти и воображающие себе гигабайты RAM, пишут протоколы с расчетом реализовывать их потом на Java и C#, в итоге каждый из десятка этих протоколов начинает требовать эти гигабайты себе единолично, а задачи по этому решает все те же, что и старый добрый протокол 1979 года о 2 мбайт памяти. И еще хорошо, если решает не хуже.