Таким образом кто угодно, когда угодно может участвовать в сети, просто придумав себе приватный ключ (это просто очень-очень большое число). [...] Прикол в том, что это не просто учётная запись, это учетная запись в блокчейне и у пользователя на руках сохранён приватный ключ (в виде парольной фразы).
ЩИТО?! Вы явно не понимаете, что такое приватный ключ.
Видимо тогда Николай Дуров, гениальный (как минимум исключительно опытный в создании сетевых проектов) математик и программист решил сделать свой блокчейн. И теперь можно сказать — у него получается.
Спасибор, поржал. Протокол Telegram вызывает кучу фейспалмов у специалистов. Даже с точки зрения чистой математики и криптографии, взять хоть 2FA — зачем они хэшат выхлоп PBKDF2? Зачем они хэшат пароль перед pbkdf2? Они думают, что если навернуть еще два хэширования, станет лучше?..
Я, на всякий случай, напомню, как выглядел вконтактик при Дурове. Для многих он был синонимом интернета, [...]
В то же время, в 2014 году, началась разработка мессенджера Telegram, который, как ни странно, снова попытался стать альтернативой интернету. Помимо банального мессенджера, в нём появились и активно продвигались боты, реализующие практически любой функционал, медиа-файлы, музыка и видео, которые мог загрузить кто угодно и скачать кто угодно, добавился сервис для анонимной публикации статей
Глупость какая. То, что для многих необразованных людей с ограниченным набором интересов он «стал синонимом», не означает, что он таковым являлся, или что мессенджер «попытался стать».
Децентрализация
По факту — нет. На данный момент из имеющихся сведений выходит «у нас больше одной ноды пока не получается». Да и Proof of Stake предрасполагает к концентрации в руках владельцев.
Я уже рассказывал в прошлой статье, насколько круто всё задумано, насколько сильно это похоже на собственную версию интернета
Итого — слишком религиозного характера пиар для технического ресурса.
Зачем все эти споры, низкого или высокого уровня? Раз с одного конца он смотрится эдак, а с другого наоборот, совершенно логично из этого вытекает, что Си — язык СРЕДНЕГО уровня.
Я так понял, alatobol про то, что если в каком-то одном стриме потеряется SSN, то на принимающей стороне отправка «наверх» по данному стриму приостановится, пока этот SSN не дойдет.
Ну так внутри потока эта проблема будет для любого протокола, который ориентирован на собственно поток — ведь верхний уровень «дырку» не поймёт. Но не заблокируются соседние потоки, в отличие от мультиплексирования всех потоков в одном TCP-соединении.
Если протокол приложения таков, что это действительно составляет проблемы, тогда надо:
Уменьшать размер фрейма, до «меньше типичного MTU»
Использовать Unordered-фреймы (в SCTP есть), им пофиг
Не уверен, но вроде тоже был какой-то драфт про «сброс» стрима, т.е. забыть, что что-то потерялось и продолжать, как будто бы чанк с этим SSN дошел.
Сброс стримов тоже был (уже RFC 6525, не драфт), но Вы, судя по всему, о Partial Reliability, т.е. разрешать потерю некоторых пакетов (для гейминга, скажем) — да, такое в SCTP тоже есть (RFC 3758).
До этого была система идентификации по рисунку вен на ладони. Это прямо классический случай, и мы уже в который раз приходим переделывать за такими системами… Всё гораздо интереснее: у электрика с точки зрения системы просто не было этого самого рисунка. Мы не знаем, как он добился такого уровня анонимизации, но сыграл один из двух факторов: либо то, что он постоянно скручивал провода голыми руками, либо то, что эти самые скрутки довольно регулярно били его током в пальцы в ответ
Вот тут комментарий врача хотелось бы. Наверняка рисунок вен (вен? не отпечаток пальцев?) таки был, а проблемы в системе или методе их обнаружения.
Да что там допиливать-то, всё уже есть. Разве что новые congestion control те же… Главное, что от их размеров было бы толково — популяризация, а значит включение поддержки остальными, и тогда протоколом смогли бы пользоваться большинство разработчиков.
Websocket — отличный пример протокола-костыля, который не нужен от слова «совсем», работай оно всё поверх SCTP. Да и сейчас-то, на TCP, он тоже вызывает кривую физиономию…
реально какой-то поток (кроме файлов есть что-то еще?),
Развёрнуто там уже на пачку документов в Standards Track, я только некоторые по теме сказанных перечислю:
— нет IP-migration
Непонятно, что alatobol имел в виду под миграцией, то ли смену адресов на ходу, то ли миграцию а-ля IPv4 -> IPv6, но в SCTP позаботились об обеих проблемах, потому два:
RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
— на старте соединение нужно указать кол-во потоков
RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
Про 4-way надо отдельно пояснить, оно типа «вроде бы правда» — на самом деле, нет, это защита от SYN flood (то, что в TCP с ограниченным успехом делают syn cookies). И такое требование, защиты от пира, которого вы еще не знаете, будет неизбежно для любого протокола. В том числи и для QUIC (и даже особенно для QUIC ввиду легкости спуфинга UDP). Зато в SCTP передача данных идет штатно уже на третьем пакете — то, что из TCP когда-то выкидывали, а сейчас пытаются возродить в виде TFO.
То есть, почувствуйте разницу и тонкость манипуляции: 4-way handshake в первый раз vs 0-RTT потом (и то вовсе не при любых условиях).
Но самое наглое вранье, конечно, про head-of-line-blocking — SCTP именно в том числе для того создавался, чтоб потеря пакета в одном потоке не тормозила остальные.
В целом, что касается современных драфтов IETF — мне попадался уже один, предлагавший API BSD-сокетов заменить, где автор плавал в теме. Так что качеству драфта от Гугла, тем более преследующего цель показать свой продукт в выгодном свете, я уже не удивляюсь.
Вот взять хотя бы один из ключевых вопросов архитектуры: мы, типа, решили в QUIC оставить семантику потока байт. А где обоснование, НАХЕРА?.. Большое количество протоколов поверх TCP вынуждено изобретать свой фрейминг, например. Что, говорите, так в HTTP было?.. Тогда тут же возникают уже 2 вопроса:
— если у вас частное решение для HTTP, тогда сравнение с общим протоколом имеет мало смысла
— если вы всё равно новую версию протокола делаете, не пора ли отойти от втискивания всего во всё тот же старый концепт безразмерного потока байт?..
И т.д.
Вовсе не всегда (пример — malloc в ядре, частные решения ухудшают жинь другим подсистемам).
Нет, нельзя сравнивать, вариант без апдейта миддлбоксов существует.
Ну вот, опять. Да сколько ж можно. Опять эти велосипедисты видят мир в бинарной дихотомии TCP vs UDP. Опять и опять они изобретают очередной велосипед поверх UDP для решения какой-то своей частной задачи, не думая об остальной сети (в комментах уже упомянули). Опять и опять они приносят в жертву долгосрочную стабильность своим сиюминутным изменениям версий…
И всё это при том, что не просто «надо придумать новый протокол», как думают авторы пунктов опроса, а давно уже есть SCTP, который вот это всё умеет — и несколько «соединений» внутри одной ассоциации, и разные наборы IP-адресов/multipath, и много чего еще. А главное — не просто реализован в ядрах FreeBSD и Linux, но есть и юзерспейсные драйвера, и даже режим «поверх UDP» для решения проблемы «файрволы не знают новый протокол».
Либертарианцы ей в принципе плохо владеют, что заметно любому, хорошо знакомому с психологией — как, впрочем, и любые другие политические идеологии (читай, религии).
ЩИТО?! Вы явно не понимаете, что такое приватный ключ.
Спасибор, поржал. Протокол Telegram вызывает кучу фейспалмов у специалистов. Даже с точки зрения чистой математики и криптографии, взять хоть 2FA — зачем они хэшат выхлоп PBKDF2? Зачем они хэшат пароль перед pbkdf2? Они думают, что если навернуть еще два хэширования, станет лучше?..
Глупость какая. То, что для многих необразованных людей с ограниченным набором интересов он «стал синонимом», не означает, что он таковым являлся, или что мессенджер «попытался стать».
По факту — нет. На данный момент из имеющихся сведений выходит «у нас больше одной ноды пока не получается». Да и Proof of Stake предрасполагает к концентрации в руках владельцев.
Итого — слишком религиозного характера пиар для технического ресурса.
Ну так внутри потока эта проблема будет для любого протокола, который ориентирован на собственно поток — ведь верхний уровень «дырку» не поймёт. Но не заблокируются соседние потоки, в отличие от мультиплексирования всех потоков в одном TCP-соединении.
Если протокол приложения таков, что это действительно составляет проблемы, тогда надо:
Сброс стримов тоже был (уже RFC 6525, не драфт), но Вы, судя по всему, о Partial Reliability, т.е. разрешать потерю некоторых пакетов (для гейминга, скажем) — да, такое в SCTP тоже есть (RFC 3758).
Вот тут комментарий врача хотелось бы. Наверняка рисунок вен (вен? не отпечаток пальцев?) таки был, а проблемы в системе или методе их обнаружения.
Нуу… подумал и придумал рафинированный пример: несжатый 8-битный PCM audio :)
А про Cubic — так это не противоречит моим словам, скорее наоборот.
Непонятно, что alatobol имел в виду под миграцией, то ли смену адресов на ходу, то ли миграцию а-ля IPv4 -> IPv6, но в SCTP позаботились об обеих проблемах, потому два:
RFC 5061 Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
RFC 6525 Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
Про 4-way надо отдельно пояснить, оно типа «вроде бы правда» — на самом деле, нет, это защита от SYN flood (то, что в TCP с ограниченным успехом делают syn cookies). И такое требование, защиты от пира, которого вы еще не знаете, будет неизбежно для любого протокола. В том числи и для QUIC (и даже особенно для QUIC ввиду легкости спуфинга UDP). Зато в SCTP передача данных идет штатно уже на третьем пакете — то, что из TCP когда-то выкидывали, а сейчас пытаются возродить в виде TFO.
То есть, почувствуйте разницу и тонкость манипуляции: 4-way handshake в первый раз vs 0-RTT потом (и то вовсе не при любых условиях).
Но самое наглое вранье, конечно, про head-of-line-blocking — SCTP именно в том числе для того создавался, чтоб потеря пакета в одном потоке не тормозила остальные.
В целом, что касается современных драфтов IETF — мне попадался уже один, предлагавший API BSD-сокетов заменить, где автор плавал в теме. Так что качеству драфта от Гугла, тем более преследующего цель показать свой продукт в выгодном свете, я уже не удивляюсь.
Вот взять хотя бы один из ключевых вопросов архитектуры: мы, типа, решили в QUIC оставить семантику потока байт. А где обоснование, НАХЕРА?.. Большое количество протоколов поверх TCP вынуждено изобретать свой фрейминг, например. Что, говорите, так в HTTP было?.. Тогда тут же возникают уже 2 вопроса:
— если у вас частное решение для HTTP, тогда сравнение с общим протоколом имеет мало смысла
— если вы всё равно новую версию протокола делаете, не пора ли отойти от втискивания всего во всё тот же старый концепт безразмерного потока байт?..
И т.д.
Нет, нельзя сравнивать, вариант без апдейта миддлбоксов существует.
И всё это при том, что не просто «надо придумать новый протокол», как думают авторы пунктов опроса, а давно уже есть SCTP, который вот это всё умеет — и несколько «соединений» внутри одной ассоциации, и разные наборы IP-адресов/multipath, и много чего еще. А главное — не просто реализован в ядрах FreeBSD и Linux, но есть и юзерспейсные драйвера, и даже режим «поверх UDP» для решения проблемы «файрволы не знают новый протокол».
“I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” —Alan Kay
Все эти 3 распиаренных слова не являются ключевыми для ООП.