По IP-адресам. Компрометация любого узла провайдера автоматически откроет доступ ко всем чайникам в его зоне ответственности. Куда уж проще чем посмотреть source-ip
Хорошо, я могу и нормально закрытый фаервол и даже statefull DHCPv6. Только почему надо рассказывать, что эта свистопляска для пользователей удобнее, безопаснее и благостнее классической архитектуры?
тебе кто-то мешает раздать все адреса сразу?
Т.е. если у меня два провайдера и в офисе несколько сотен устройств, то каждое должно иметь адреса из двух префиксов и самостоятельно решать проблему доступности дефолта? И это не является усложнением? Или может это более безопасно?
Да, прямое сканирование IPv6 сети невозможно. Но пассивный наблюдатель прекрасно будет видеть, сколько чайников в вашей сети. Поверхность атаки меньше, но отнюдь не нулевая.
А насчёт фаервола, внимание вопрос: если на домашних маршрутизаторах фаервол по умолчанию будет всё запрещать и для общения с внешним миром надо отдельно проковыривать порты, то...чем это лучше по сравнению с NAT? Что там нужна настройка для доступа извне, что здесь. IPv6 - это же типа чтобы всё было просто и безопасно. Что стало проще и что стало безопаснее?
И как вы на фаерволе будете прописывать разрешения на доступ для устройств с рандомным адресом, которые появились в ответ на SLAAC?
А вы точно хотите, чтобы каждое пользовательское устройство, каждое тупое реле ворот, каждый умный чайник (не видевший апдейтов никогда в жизни), каждая виндовая шара в домохозяйстве стали "сервером распределённой архитектуры сети"? Да ещё и со скачущим рандомным адресом из-за бреши в приватности, которую пробил SLAAC.
Узколобые в своей идеалистичности разработчики IPv6 удалили NAT. А не нужон он им теперь, адресов же много! В результате: 1. SLAAC полностью убивает приватность устройств, поэтому надо генерировать узлу второй рандомный адрес и следить, чтобы это работало. А с рандомным адресом написание правил для МСЭ становится поистине увлекательным 2. Переключение офиса без AS на резервного провайдера становится тем ещё квестом, так как надо единомоментно во всей сети поменять адреса. Или хранить на каждом устройстве пул адресов двух провайдеров. В корпоративной сети на тысячи машин это бред. Есть конечно Preffix Address Translation. Но тогда опять же возвращаемся к неоднозначным правилам для МСЭ
Бред какой-то. Два жутких костыля в очень непродуманный протокол. IPv4 на его фоне гораздо разумнее.
A/B очень чувствителен к подготовке выборки. Одно дело, когда результаты убедительны: 5, 10, 15%. Но 1% говорит о том, что у вас прям эталонное разделение, в котором вы обеспечили идеальную репрезентативность пользователей в обоих группах. Т.е. если бы повторяли снова А/Б тестирование, но уже в котором группа А и группа Б не отличаются технически, то вы получили бы разницу между группами менее 1%. Да возможно ли это вообще?))
Я вообще не хочу спорить с тем, что уменьшение времени загрузки увеличивает конверсию. Но приведённая цифра вызывает сомнение.
В начале статьи грубая маркетинговая ошибка: "Ethernet - 50 Мбит/с". Это даже не средняя скорость доступа, а вообще непонятно что. Зато у GPON - указан гигабит. Так-то обычный 4-х парный Ethernet тоже может на дешёвом оборудовании давать гигабит. Это черезвычайно живучее и неприятное заблуждение. Меня недавно менеджер ростелекома уверял, что гигабит по оптике это более прогрессивный и современный гигабит, чем гигабит по меди.
И ещё, разве RTT так сильно зависит от скорости среды и расстояния? Какжется всё-таки надо учитывать ещё количество транзитных переходов. Скорость на них всё-таки отличается от скорости среды заметно.
А как вы посчитали прирост просмотров в районе 1%? Для трафика соц сетей это должна быть какая-то статистическая погрешность. Особенно в последние 2 года, когда профиль трафика уже не определяется днём недели, временем года и временем суток, а зависит от эпидемиологической и геополитической ситуации в конкретных странах? Например отправили школьников на дистант в 15 областях из всей страны - вот вам и прирост. Вывели с дистанта - вот вам и убыль. Речь-то всего об 1% идёт. Мало ли там факторов может быть, кроме формата картинок.
Согласен. Я почему-то подумал про константы. Но для оценки сложности они, пожалуй, не подходят. И если брать голый ассемблер, то он и не будет оперировать десятичными числами. Про девятки он не знает. Тогда зависимость будет минимальной.\
Я по привычке про оптимизацию алгоритмов на ЯВУ подумал)
А как влияет культурный код на колмогоровскую сложность? Вот, например, программа для записи 999999999999 очевидна для нас, привыкших к десятеричной системе счисления. В двоичной системе сложность записи повышается. Помимо системы счисления наверняка есть и другие вещи, позволяющие оптимизировать запись в зависимости от багажа знаний записывающего. Древние люди, например, число e не знали. Только pi.
А почему для ведения логов использовался SMTPHandler , а здесь другая библиотека? Вроде и та и та отправляют письма по SMTP: не ясно, зачем автор использует разные библиотеки. Разница никак не прокомментирована.
Зачем наворачивать такой сложный токен с подписью, если можно было бы просто создать временную таблицу токенов, связанную с таблицей пользователей по id. Там токеня и ссылки были бы куда короче и красивее. 8 символов, живущих 10 минут было бы "достаточно всем"(С).
Там ещё одно гигантское замедление есть: сначала полностью выполняется запрос своих постов, потом полностью подписных, затем делается юнион и только потом выбираются страницы. А ведь размер первых двух таблиц может быть очень большим. Тогда как при нормально построенном запросе с одной таблицей без юнион поиск бы остановился сразу по достижении необходимого числа записей на странице.
Вместо простого запроса "SELECT COUNT(*) FROM folowers WHERE folower_id=? AND folowed_id=? LIMIT 1;" такой трэш и угар. Судя по всему в предложенной версии зачем-то сначала составляется список всех подписанных пользователей, и потом по нему прогоняется отдельный запрос для нужного юзера.
Да и в поиске постов можно было прекрасно обойтись без union. Сдаётся мне, что с таким конструированием запросов не только падает наглядность, но и растёт время их выполнения.
Протокол REP, конечно, хорош. Но утверждения типа «В случае со Spanning-Tree это действительно так. Этот протокол в кольцевой топологии может отрабатывать до 30 секунд, что часто неприемлемо для сетей, обслуживающих производственные процессы» — взят из древних-древних скрижалей. Кто ж STP-то в классической версии настраивать в 2021 году будет? Там и portfast, и uplinkfast, и RSTP и всякое такое. Это если сеть «из коробки» развернуть и не настраивать 30 секунд будет.
"Поменять основную метрику - пусть это будет не оценка от преподавателей, а сколько проект смог заработать. Мне кажется, что если ориентировать студентов на прибыльность их проекта, то они лучше разберутся в том как устроен ИТ рынок и научатся работать с реальными потребителями."
Это - не инженерная задача. Раньше был такой термин инженер-экономист. Видимо сейчас все такими должны быть в вашем представлении. Это не так. Представляю себе, как конструктор блока вертикальной ориентации ракеты думает как на нём заработать вместо того, чтобы думать о том, как его улучшить.
По IP-адресам. Компрометация любого узла провайдера автоматически откроет доступ ко всем чайникам в его зоне ответственности. Куда уж проще чем посмотреть source-ip
У вас фобия именно на трансляцию? Хорошо, мы не будем думать о NAT, зато будем думать о нормально закрытом фаерволе, SLAAC, privacy extension и пр.
И вместо того, чтобы ковырять ненавистный всем сторонникам IPv6 NAT для проброса порта будет ковырять нормально закрытый МСЭ
А админ будет заботиться о двойной адресации в офисе.
Все наработались, всё с ног на голову перевернули, зато победили мерзкий NAT.
Осталось только найти в нём какую-то пользу, кроме разрядности адресации
Хорошо, я могу и нормально закрытый фаервол и даже statefull DHCPv6. Только почему надо рассказывать, что эта свистопляска для пользователей удобнее, безопаснее и благостнее классической архитектуры?
Т.е. если у меня два провайдера и в офисе несколько сотен устройств, то каждое должно иметь адреса из двух префиксов и самостоятельно решать проблему доступности дефолта? И это не является усложнением? Или может это более безопасно?
Да, прямое сканирование IPv6 сети невозможно. Но пассивный наблюдатель прекрасно будет видеть, сколько чайников в вашей сети. Поверхность атаки меньше, но отнюдь не нулевая.
А насчёт фаервола, внимание вопрос: если на домашних маршрутизаторах фаервол по умолчанию будет всё запрещать и для общения с внешним миром надо отдельно проковыривать порты, то...чем это лучше по сравнению с NAT? Что там нужна настройка для доступа извне, что здесь. IPv6 - это же типа чтобы всё было просто и безопасно. Что стало проще и что стало безопаснее?
И как вы на фаерволе будете прописывать разрешения на доступ для устройств с рандомным адресом, которые появились в ответ на SLAAC?
А вы точно хотите, чтобы каждое пользовательское устройство, каждое тупое реле ворот, каждый умный чайник (не видевший апдейтов никогда в жизни), каждая виндовая шара в домохозяйстве стали "сервером распределённой архитектуры сети"?
Да ещё и со скачущим рандомным адресом из-за бреши в приватности, которую пробил SLAAC.
Узколобые в своей идеалистичности разработчики IPv6 удалили NAT. А не нужон он им теперь, адресов же много! В результате:
1. SLAAC полностью убивает приватность устройств, поэтому надо генерировать узлу второй рандомный адрес и следить, чтобы это работало. А с рандомным адресом написание правил для МСЭ становится поистине увлекательным
2. Переключение офиса без AS на резервного провайдера становится тем ещё квестом, так как надо единомоментно во всей сети поменять адреса. Или хранить на каждом устройстве пул адресов двух провайдеров. В корпоративной сети на тысячи машин это бред. Есть конечно Preffix Address Translation. Но тогда опять же возвращаемся к неоднозначным правилам для МСЭ
Бред какой-то. Два жутких костыля в очень непродуманный протокол. IPv4 на его фоне гораздо разумнее.
Интересно, по железу это не родственник DCN?
A/B очень чувствителен к подготовке выборки. Одно дело, когда результаты убедительны: 5, 10, 15%. Но 1% говорит о том, что у вас прям эталонное разделение, в котором вы обеспечили идеальную репрезентативность пользователей в обоих группах. Т.е. если бы повторяли снова А/Б тестирование, но уже в котором группа А и группа Б не отличаются технически, то вы получили бы разницу между группами менее 1%. Да возможно ли это вообще?))
Я вообще не хочу спорить с тем, что уменьшение времени загрузки увеличивает конверсию. Но приведённая цифра вызывает сомнение.
В начале статьи грубая маркетинговая ошибка: "Ethernet - 50 Мбит/с". Это даже не средняя скорость доступа, а вообще непонятно что. Зато у GPON - указан гигабит. Так-то обычный 4-х парный Ethernet тоже может на дешёвом оборудовании давать гигабит. Это черезвычайно живучее и неприятное заблуждение. Меня недавно менеджер ростелекома уверял, что гигабит по оптике это более прогрессивный и современный гигабит, чем гигабит по меди.
И ещё, разве RTT так сильно зависит от скорости среды и расстояния? Какжется всё-таки надо учитывать ещё количество транзитных переходов. Скорость на них всё-таки отличается от скорости среды заметно.
А как вы посчитали прирост просмотров в районе 1%? Для трафика соц сетей это должна быть какая-то статистическая погрешность. Особенно в последние 2 года, когда профиль трафика уже не определяется днём недели, временем года и временем суток, а зависит от эпидемиологической и геополитической ситуации в конкретных странах? Например отправили школьников на дистант в 15 областях из всей страны - вот вам и прирост. Вывели с дистанта - вот вам и убыль. Речь-то всего об 1% идёт. Мало ли там факторов может быть, кроме формата картинок.
Согласен. Я почему-то подумал про константы. Но для оценки сложности они, пожалуй, не подходят. И если брать голый ассемблер, то он и не будет оперировать десятичными числами. Про девятки он не знает. Тогда зависимость будет минимальной.\
Я по привычке про оптимизацию алгоритмов на ЯВУ подумал)
А как влияет культурный код на колмогоровскую сложность? Вот, например, программа для записи 999999999999 очевидна для нас, привыкших к десятеричной системе счисления. В двоичной системе сложность записи повышается. Помимо системы счисления наверняка есть и другие вещи, позволяющие оптимизировать запись в зависимости от багажа знаний записывающего. Древние люди, например, число e не знали. Только pi.
А почему для ведения логов использовался SMTPHandler , а здесь другая библиотека? Вроде и та и та отправляют письма по SMTP: не ясно, зачем автор использует разные библиотеки. Разница никак не прокомментирована.
Зачем наворачивать такой сложный токен с подписью, если можно было бы просто создать временную таблицу токенов, связанную с таблицей пользователей по id. Там токеня и ссылки были бы куда короче и красивее. 8 символов, живущих 10 минут было бы "достаточно всем"(С).
Не нашли ответ?)
Там ещё одно гигантское замедление есть: сначала полностью выполняется запрос своих постов, потом полностью подписных, затем делается юнион и только потом выбираются страницы. А ведь размер первых двух таблиц может быть очень большим. Тогда как при нормально построенном запросе с одной таблицей без юнион поиск бы остановился сразу по достижении необходимого числа записей на странице.
Какой ужас этот ORM.
Вместо простого запроса "SELECT COUNT(*) FROM folowers WHERE folower_id=? AND folowed_id=? LIMIT 1;" такой трэш и угар. Судя по всему в предложенной версии зачем-то сначала составляется список всех подписанных пользователей, и потом по нему прогоняется отдельный запрос для нужного юзера.
Да и в поиске постов можно было прекрасно обойтись без union. Сдаётся мне, что с таким конструированием запросов не только падает наглядность, но и растёт время их выполнения.
Радиофак УПИ всегда готовил инженеров.
"Поменять основную метрику - пусть это будет не оценка от преподавателей, а сколько проект смог заработать. Мне кажется, что если ориентировать студентов на прибыльность их проекта, то они лучше разберутся в том как устроен ИТ рынок и научатся работать с реальными потребителями."
Это - не инженерная задача. Раньше был такой термин инженер-экономист. Видимо сейчас все такими должны быть в вашем представлении. Это не так. Представляю себе, как конструктор блока вертикальной ориентации ракеты думает как на нём заработать вместо того, чтобы думать о том, как его улучшить.