Ещё раз: DNS это протокол-справочник. Вы запрашиваете у сервера какое-то абстрактное значение по ключу. Это может быть какой-то ip, это может быть почтовый адрес, просто строка, да что угодно. Вы спросили значение, вам прислали ответ. Ответ вам присылают не на какой-то там ip адрес, указанный в application level запроса, а на ip тот адрес, который увидел сетевой стек ОС. Тут не нарушается никакая вложенность слоёв стека. Содержимое — просто какое-то содержимое, оно не влияет на выбор адреса назначения, маршрута и исходящего интерфейса.
В плохом протоколе для ответа используют не тот адрес, который увидел сетевой стек ОС в поле адреса источника, а тот адрес, что вам прислали внутри application level. И это совершенно, абсолютно неправильно. В нормальной ситуации приложение, использующее для запроса открытый через системный вызов сокет, понятия не имеет о том, какой в итоге маршрут
(а следовательно и src ip адрес) будет позже выбран сетевым стеком системы. Поэтому и нарушаются базовые принципы разделения уровней стека — приложение должно знать какой
адрес позже будет выбран системой (я уже молчу о том, что адрес может в процессе передачи пакета по сети попросту поменяться). Да в конце концов в таком протоколе может быть прописано вообще что угодно совершенно умышленно.
Если вы разницы не видите, то пардон, мы с вами общего языка не найдём.
ЗЫ: DHCP — вполне себе application level. Да, он, казалось бы, знает мак интерфейса, но протокол предполагает жесткую привязку каждого инстанса к конкретному интерфейсу и работу только в пределах широковещательного домена. Поэтому мы точно можем определить какой мак взять.
Так ни они, ни, скажем, FB ничего и не стирают, а только помечают как удалённое и версионированием данных пользуются. Вполне официально вроде бы даже. Потому что, по их же словам, «Стирать данные долго и накладно. И вообще вдруг пользователь удалит учётку, а потом восстановить захочет?». Это правда лишь отчасти, конечно же. Главная причина — никто не будет стирать данные о пользователях, потому что это и есть товар.
Сколько-сколько у нас там на весь мир производителей чипсетов с фирмварью для WIFI или мобильных сетей последних поколений трёх? 3? 5? А сколько из них процентов 90-95 рынка держат? Ещё меньше? А сколько протоколов завязано на то, какого именно там внизу стандарта беспроводная сеть? Ноль? К слову тот же WIFI как раз таки тащит на себе, в качестве основополагающего принципа, безумную гору обратной совместимости, которая прямо ну очень сильно всё портит и мешает спать разработчикам. На уровне «Мы сделали канальную скорость больше в десять раз, но реальный прирост скорости передачи полезной нагрузки получился меньше двух».
А теперь давайте подумаем сколько у нас производителей сетевого железа? Домашних роутеров? Операционных систем? Десятки? Сотни? Протоколов сколько завязано, от банальных SIP-RTSP до всяческого из мира mp-bgp и mpls?
Как вы думаете в какой ситуации нормальное внедрение всеми производителями будет проще?
В масштабе всего мира и вовлечённых отраслей разница в сложности перехода, вот честно, просто колоссальная. И у операторов дело далеко не в сложности продажи. Клиентам в основном пофигу какой-там-ай-пи-номер, ему нормальная работа связи нужна, а её по ряду причин нельзя вот так взять и гарантировать. Как минимум, оператору нужно по ряду причин ставить практически всем клиентам свои CPE и гарантировать работу до выхода трафика из этих CPE. А это значит перенастроить и обойти ногами огромную кучу пользователей. Если бы вам стандарт сотовой сети меняли с необходимостью вызова техника, не знаю даже на 2G или на 3G сейчас бы сидело большинство.
Вы мешаете всё в кучу. Ни DNS ни bittorrent для нормальной работы не полагаются на правильность вложенных в appilcation level ip адресов. У DNS это просто текстовый payload, в который условный сервер с key-value базой вкладывает значение, соответствующее запрошенному ключу. У Bittorrent поле с ip вообще не используется, трекер адрес клиента берёт из сетевого стека при получении announce и его же отдаёт другим клиентам в ответ на scrape.
А вот ни RTSP ни остальные не заведутся без ALG, потому что идиотия стандарта предписывает делать соединения с адресом, который в application level положен, пофиг что там и откуда сетевой стек получил.
Не получим и не перейдем. Потому что абсолютно точно так же придется менять горы железа и софта у операторов, клиентская часть годами будет кое-как и с багами подтягиваться, но так и не будет работать как положено и написано в стандарте, а про проблемы с роутингом и оверхедом на операции на транзитном железе я даже думать боюсь.
Нет, серьёзно, вот на v6 стандарты разжеваны, вдоль и поперёк задокументированы и лежат в открытом доступе даже не годами, а натурально десятилетиями. И что как? Реализовано как положено везде? Нет? А почему вы считаете, что с другим стандартом будет всё иначе?
Как ни встраивай нативно мультикаст в ipv6, всё равно на типичном и не сильно умном l2 железе это добро будет радостно рассылаться широковещательно и лететь на каждый хост в широковещательном домене. Ну отбросили вы полученный пакет чуть пораньше, увидев, ещё на уровне разборки ip-адреса, что этот мультикаст не вам, и что? Профит в реальности достаточно призрачный.
А с NAT что не так? NAT 1:1 один чёрт нужен для ряда ситуаций. Историй боли и простоев работы от изменения адресации на всей инфраструктуре из-за
смены провайдера и при отсутствии PI адресов я видел уже немало.
Что, к слову, является камнем в огород разработчиков протокола. RTSP, FTP, SIP, вот это вот всё великолепие, в котором разработчики грубейшим образом нарушили принцип уровней стека протоколов. Ну не должен application layer ничего про ip адреса из ip layer знать в принципе, иначе вот такие костыли как ALG и будут необходимы.
Вы же понимаете, что глючность изделия касается не конкретно этого шлюза, а серии вообще, инженеры наверняка более-менее в курсе, но менеджмент требует выпускать уже сейчас и начинать продавать?
NAT is not a security feature.
Серьёзно. Закрывать лампочки от внешнего мира — не задача NAT, и он её не решает совершенно. Какой-нибудь вполне нередкий full-cone и весь интернет сможет увидеть голый сокет вашей лампочки, радостно свисающий наружу. Закрывать должен (и закрывает) фаервол, желательно stateful. Точка.
Кроме того достаточно дико выглядит сама идея найти ваши лампочки даже в условной /64, которую получит их сегмент сети в вашем жилище. Это просто охренеть, не встать, сколько адресов нужно перебрать при условии случайного распределения ip адресов девайсов в подсети.
Единственное применение (впрочем кажущееся мне весьма востребованным в теории) — избавление от необходимости менять всю адресацию в инфраструктуре абстрактной фирмы при смене оператора. Потому что PI всем получать — маразм, а пиринг с каждым ООО "Вектор" провайдеры откажутся поднимать.
Теория симулированной Вселенной штука неоднозначная. Вроде как и критикуется научным сообществом. А вроде как и вполне себе описывает многие странные моменты типа той же квантовой запутанности или дискретности в микромире. К сожалению, подтвердить или опровергнуть её пока что нереально, хотя сам способ более-менее понятен.
Теория большого взрыва и горячей вселенной подтверждается целым рядом наблюдений. Как общеизвестный минимум, можно назвать реликтовое излучение, которое было предсказано в рамках модели теории большого взрыва, в том числе с оценкой ряда характеристик этого излучения. И, обнаруженное после, оно полностью вписывалось в предсказания.
Вообще чуть ли ни единственная реальная проблема заключается в расхождении теоретической и наблюдаемой изотропности/однородности Вселенной.
В связи с подтёртостью поста ничего не понятно. Речь про обычную витую пару а-ля UTP с каким-нибудь бытовым интернетом или телефоном? Если да, то чем вам не нравится абстрактная плотная, скрученная плоскогубцами, а не пальцами скрутка? Что-то мне подсказывает о том, что в таком случае точки соприкосновения жил тоже (в смысле "как и во врезных соединениях") атмосферному воздействию не подвергаются.
Ну и да, ЧСВ у мсье много, но в его оправдание скажу что он хотя бы в курсе того, что в панельных домах нельзя штробить горизонтально стены и вообще нельзя потолки)
Не пользуюсь услугами компании, в которой работает автор, но, как я понял, она вполне себе коммерческая и её клиенты вполне добровольно и осознанно голосуют рублём.
Так вот: любая коммерческая компания имеет право продавать и перепродавать что угодно и купленное у кого и как угодно. Если это будет говно вместо товара, то рынок быстро расставит всё по местам, а большинство населения это никак финансово не затронет.
Но вот когда за счёт моих налогов очередная импортозамещающая контора решает вот так вот подзаработать, то лично мне уже хочется испить немного крови. Проталкивали бы, говоря честно про то, что это Китай, и не получив сначала гранты на разработку (а их же получали, не так ли?) — вопросов не было бы. Разработали бы сами и производство отдали бы в Китай — вопросов не было бы. Да хоть прошивку собрали бы сами с нуля к готовому железу.
Но нет же. Попилить, наврать, из бюджета украсть.
Вооще, создавать ракету через MVP и «небольшие улучшения» — далеко не самое умное решение. Добавляет еще сомнений в реальности проекта.
Ну приехали.
Приблизительно таким образом разрабатывались ракеты в СССР. Делаем максимально дешево, но чтобы в принципе могло отрабатывать задачу. Проводим ряд тестовых запусков, устраняем причины, вызвавшие аварии, устраняем другие найденные недочёты, выводим в эксплуатацию. И, если мне не изменяет рассудок, этот подход работал.
Нормальные и ожидаемые. Инстаграм конторе как-то же нужно продвигать. Вопросы, которые задают прямо в процессе стрима требуют относительной интерактивности и странно было бы отвечать на них в конце по остаточному принципу. Ну а комменты на вообще стороннем ресурсе как раз никакой спешки не требуют, на них можно отвечать максимально «асинхронно».
Кроме того к моменту вопросов с Хабра подоспеют максимально подвыпитые и философские ответы)
Как бы и да. Но я всё-таки свои личные так и оставлю работать, а сам ходить через них продолжу. Потому что как разблокировали совершенно на ровном месте, так завтра и заблокируют. Снова разблокируют и опять заблокируют.
Если подключать к питанию, но не перезаписывать данные время от времени принудительным образом, то они тоже теряются. Не встречал пока ещё флешек, которые самостоятельно занимаются обновлением заряда транзисторов, зато видел вагон таких, которые годами были воткнуты куда-то, имели питание, но рано или поздно начинали бить давно записанные данные.
Система защиты от протечек нужна однозначно. Исключение — вы живёте в частном доме или на первом этаже многоэтажки и своё добро вам не жалко. Потому что практически каждое жильё рано или поздно сталкивается с прорывом трубы/гибкой подводки/фильтра/<подставить нужное>. Если вам повезёт, то вы окажетесь дома, перекроете ввод и через пару лет будете вспоминать этот случай только при разговорах с друзьями на подобные темы. Если нет — будете платить много денег владельцам квартир под вами. Защита от протечек стоит гораздо дешевле.
Вообще я лично недоумеваю почему в многоэтажных домах домах не делают банальный аварийный сток воды в ту же канализацию в ванной комнате и туалете (а как правило стояки проходят там и большинство протечек тоже там). Бетонное «корытце» в этих помещениях на полу делают, а фактически бесплатный слив, решающий большинство проблем с протечками — нет.
А почему это полисить то L3 connected не выйдет при ipv6 вдруг?
Ещё раз: DNS это протокол-справочник. Вы запрашиваете у сервера какое-то абстрактное значение по ключу. Это может быть какой-то ip, это может быть почтовый адрес, просто строка, да что угодно. Вы спросили значение, вам прислали ответ. Ответ вам присылают не на какой-то там ip адрес, указанный в application level запроса, а на ip тот адрес, который увидел сетевой стек ОС. Тут не нарушается никакая вложенность слоёв стека. Содержимое — просто какое-то содержимое, оно не влияет на выбор адреса назначения, маршрута и исходящего интерфейса.
В плохом протоколе для ответа используют не тот адрес, который увидел сетевой стек ОС в поле адреса источника, а тот адрес, что вам прислали внутри application level. И это совершенно, абсолютно неправильно. В нормальной ситуации приложение, использующее для запроса открытый через системный вызов сокет, понятия не имеет о том, какой в итоге маршрут
(а следовательно и src ip адрес) будет позже выбран сетевым стеком системы. Поэтому и нарушаются базовые принципы разделения уровней стека — приложение должно знать какой
адрес позже будет выбран системой (я уже молчу о том, что адрес может в процессе передачи пакета по сети попросту поменяться). Да в конце концов в таком протоколе может быть прописано вообще что угодно совершенно умышленно.
Если вы разницы не видите, то пардон, мы с вами общего языка не найдём.
ЗЫ: DHCP — вполне себе application level. Да, он, казалось бы, знает мак интерфейса, но протокол предполагает жесткую привязку каждого инстанса к конкретному интерфейсу и работу только в пределах широковещательного домена. Поэтому мы точно можем определить какой мак взять.
А теперь давайте подумаем сколько у нас производителей сетевого железа? Домашних роутеров? Операционных систем? Десятки? Сотни? Протоколов сколько завязано, от банальных SIP-RTSP до всяческого из мира mp-bgp и mpls?
Как вы думаете в какой ситуации нормальное внедрение всеми производителями будет проще?
В масштабе всего мира и вовлечённых отраслей разница в сложности перехода, вот честно, просто колоссальная. И у операторов дело далеко не в сложности продажи. Клиентам в основном пофигу какой-там-ай-пи-номер, ему нормальная работа связи нужна, а её по ряду причин нельзя вот так взять и гарантировать. Как минимум, оператору нужно по ряду причин ставить практически всем клиентам свои CPE и гарантировать работу до выхода трафика из этих CPE. А это значит перенастроить и обойти ногами огромную кучу пользователей. Если бы вам стандарт сотовой сети меняли с необходимостью вызова техника, не знаю даже на 2G или на 3G сейчас бы сидело большинство.
А вот ни RTSP ни остальные не заведутся без ALG, потому что идиотия стандарта предписывает делать соединения с адресом, который в application level положен, пофиг что там и откуда сетевой стек получил.
Не получим и не перейдем. Потому что абсолютно точно так же придется менять горы железа и софта у операторов, клиентская часть годами будет кое-как и с багами подтягиваться, но так и не будет работать как положено и написано в стандарте, а про проблемы с роутингом и оверхедом на операции на транзитном железе я даже думать боюсь.
Нет, серьёзно, вот на v6 стандарты разжеваны, вдоль и поперёк задокументированы и лежат в открытом доступе даже не годами, а натурально десятилетиями. И что как? Реализовано как положено везде? Нет? А почему вы считаете, что с другим стандартом будет всё иначе?
Как ни встраивай нативно мультикаст в ipv6, всё равно на типичном и не сильно умном l2 железе это добро будет радостно рассылаться широковещательно и лететь на каждый хост в широковещательном домене. Ну отбросили вы полученный пакет чуть пораньше, увидев, ещё на уровне разборки ip-адреса, что этот мультикаст не вам, и что? Профит в реальности достаточно призрачный.
А с NAT что не так? NAT 1:1 один чёрт нужен для ряда ситуаций. Историй боли и простоев работы от изменения адресации на всей инфраструктуре из-за
смены провайдера и при отсутствии PI адресов я видел уже немало.
Что, к слову, является камнем в огород разработчиков протокола. RTSP, FTP, SIP, вот это вот всё великолепие, в котором разработчики грубейшим образом нарушили принцип уровней стека протоколов. Ну не должен application layer ничего про ip адреса из ip layer знать в принципе, иначе вот такие костыли как ALG и будут необходимы.
Вы же понимаете, что глючность изделия касается не конкретно этого шлюза, а серии вообще, инженеры наверняка более-менее в курсе, но менеджмент требует выпускать уже сейчас и начинать продавать?
NAT is not a security feature.
Серьёзно. Закрывать лампочки от внешнего мира — не задача NAT, и он её не решает совершенно. Какой-нибудь вполне нередкий full-cone и весь интернет сможет увидеть голый сокет вашей лампочки, радостно свисающий наружу. Закрывать должен (и закрывает) фаервол, желательно stateful. Точка.
Кроме того достаточно дико выглядит сама идея найти ваши лампочки даже в условной /64, которую получит их сегмент сети в вашем жилище. Это просто охренеть, не встать, сколько адресов нужно перебрать при условии случайного распределения ip адресов девайсов в подсети.
Единственное применение (впрочем кажущееся мне весьма востребованным в теории) — избавление от необходимости менять всю адресацию в инфраструктуре абстрактной фирмы при смене оператора. Потому что PI всем получать — маразм, а пиринг с каждым ООО "Вектор" провайдеры откажутся поднимать.
Теория симулированной Вселенной штука неоднозначная. Вроде как и критикуется научным сообществом. А вроде как и вполне себе описывает многие странные моменты типа той же квантовой запутанности или дискретности в микромире. К сожалению, подтвердить или опровергнуть её пока что нереально, хотя сам способ более-менее понятен.
Теория большого взрыва и горячей вселенной подтверждается целым рядом наблюдений. Как общеизвестный минимум, можно назвать реликтовое излучение, которое было предсказано в рамках модели теории большого взрыва, в том числе с оценкой ряда характеристик этого излучения. И, обнаруженное после, оно полностью вписывалось в предсказания.
Вообще чуть ли ни единственная реальная проблема заключается в расхождении теоретической и наблюдаемой изотропности/однородности Вселенной.
В связи с подтёртостью поста ничего не понятно. Речь про обычную витую пару а-ля UTP с каким-нибудь бытовым интернетом или телефоном? Если да, то чем вам не нравится абстрактная плотная, скрученная плоскогубцами, а не пальцами скрутка? Что-то мне подсказывает о том, что в таком случае точки соприкосновения жил тоже (в смысле "как и во врезных соединениях") атмосферному воздействию не подвергаются.
Ну и да, ЧСВ у мсье много, но в его оправдание скажу что он хотя бы в курсе того, что в панельных домах нельзя штробить горизонтально стены и вообще нельзя потолки)
Не пользуюсь услугами компании, в которой работает автор, но, как я понял, она вполне себе коммерческая и её клиенты вполне добровольно и осознанно голосуют рублём.
Так вот: любая коммерческая компания имеет право продавать и перепродавать что угодно и купленное у кого и как угодно. Если это будет говно вместо товара, то рынок быстро расставит всё по местам, а большинство населения это никак финансово не затронет.
Но вот когда за счёт моих налогов очередная импортозамещающая контора решает вот так вот подзаработать, то лично мне уже хочется испить немного крови. Проталкивали бы, говоря честно про то, что это Китай, и не получив сначала гранты на разработку (а их же получали, не так ли?) — вопросов не было бы. Разработали бы сами и производство отдали бы в Китай — вопросов не было бы. Да хоть прошивку собрали бы сами с нуля к готовому железу.
Но нет же. Попилить, наврать, из бюджета украсть.
Простите, накипело.
Ну приехали.
Приблизительно таким образом разрабатывались ракеты в СССР. Делаем максимально дешево, но чтобы в принципе могло отрабатывать задачу. Проводим ряд тестовых запусков, устраняем причины, вызвавшие аварии, устраняем другие найденные недочёты, выводим в эксплуатацию. И, если мне не изменяет рассудок, этот подход работал.
Кроме того к моменту вопросов с Хабра подоспеют максимально подвыпитые и философские ответы)
:)
Но лучше уж заплатить конкретный счёт в условные 100к за воду, чем непонятные, но наверняка бо́льшие, суммы соседям. Нервы целее будут.
Вообще я лично недоумеваю почему в многоэтажных домах домах не делают банальный аварийный сток воды в ту же канализацию в ванной комнате и туалете (а как правило стояки проходят там и большинство протечек тоже там). Бетонное «корытце» в этих помещениях на полу делают, а фактически бесплатный слив, решающий большинство проблем с протечками — нет.