Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Gaperton, вы писали:
G>> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно. S>Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же. S>А вот админам свинью подкладываете, да. Не жалуйтесь потом что админы вас не уважают.
Если бы в нефункциональных требованиях было бы принято отражать пункт, мол "шоб админы уважали", рынок ПО бы давно рухнул.
G>> Одна из причин — он хорошо проходит через файрволы, не требуя дополнительной конфигурации. Просто работает. И все. S>Вот за это надо отстреливать конечности по частям, с неделей таймаута между выстрелами.
Извини, но то, что оно хорошо проходит через файрволы и при этом просто работает — это твоя, как админа проблема, а не разработчиков. Не надо с больной головы на здоровую проблемы эксплуатации перекладывать.
Здравствуйте, Smooky, Вы писали:
S>Ну к нам в контору вообще нельзя попасть, незная общеканальную сигнализацию (ОКС№7), и знания межстанционных протоколов начиная от LapB (ходит под TCP) и до TCAP/RANAP/BSSAP/... и заканчивая протоколами прикладного уровня HTTP/FTP/...(хотя в принципе они нафиг не нужны, так, для общего развития). S>Ну и по крайней мере хотя бы быть знакомым с рекомендациями Motorola (Q.XXX).
А у нас в конторе у всех мужиков длинее чем у ваших.
H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
Однобайтные кодировки должны умереть!!
Руки бы обрывал за их использование сейчас.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sheridan, Вы писали:
S>(типа запрета чатицца в рабочее время).
Запрет "чатицца" в рабочее время несет исключительно административный характер. Это вопрос трудовой дисциплины, а не, скажем, информационной безопасности. И решаться он должен административно, а не технически.
Иными словами, до тех пор, пока будут применяться технические запреты, сотрудники будут искать способы их обходить. Но ровно до того момента, пока к ним не будут применены административные меры.
Хотя подобные запреты, на мой взгляд, полный идиотизм на пустом месте.
S>>(типа запрета чатицца в рабочее время).
KV>Запрет "чатицца" в рабочее время несет исключительно административный характер. Это вопрос трудовой дисциплины, а не, скажем, информационной безопасности. И решаться он должен административно, а не технически.
KV>Иными словами, до тех пор, пока будут применяться технические запреты, сотрудники будут искать способы их обходить. Но ровно до того момента, пока к ним не будут применены административные меры.
Вот, хоть кто-то умную мысль сказал. Никакие административные проблемы техническими решениями нормально и эффективно решены быть не могут.
KV>Хотя подобные запреты, на мой взгляд, полный идиотизм на пустом месте.
Отож. Обычно такие запреты бывают в конторах, в которых эффективность сотрудников измеряется в жопочасах, мотивации никакой, и начальство, будучи полным импотентом в вопросах повышения эффективности труда, закручивает гайки, запрещая все и вся, наивно полагая(это мое предположение, я лично логики в таких действиях не вижу), что от нечего делать сотрудники начнут работать. Сотрудники же от таких мер вместо уважения начинают испытывать неприязнь к своим руководителям, и стартует холодная война "кто кого больше на#бет". На работу, ессно, времени уже не остается. По сути, такие ситуации — целиком и полностью плод некомпетенции управленцев.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Приветствую, legogogo, вы писали:
l> Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. l> Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)?
Да просто для того, чтобы имели представление о том как все работает, и использовали бы свои знания, создавая соответствующий ситуации протокол. А то развелось, блин, народа, которые к месту и не к месту лепят обмен данными через http.
l>> Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. l>> Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)?
S>Да просто для того, чтобы имели представление о том как все работает, и использовали бы свои знания, создавая соответствующий ситуации протокол. А то развелось, блин, народа, которые к месту и не к месту лепят обмен данными через http.
Это у тебя какие-то сексуальные фантазии на тему такого народа
Здравствуйте, Sheridan, Вы писали:
G>> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно. S>Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же. S>А вот админам свинью подкладываете, да.
Это вы, админы, нам регулярно свиней подкладываете.
S>Не жалуйтесь потом что админы вас не уважают.
А мы и не жалуемся. Просто используем HTTP, и все.
G>> Одна из причин — он хорошо проходит через файрволы, не требуя дополнительной конфигурации. Просто работает. И все. S>Вот за это надо отстреливать конечности по частям, с неделей таймаута между выстрелами.
Ну разумется. Только дай вам, админам, волю — и все будет для окружающих максимально через жопу, зато — удобно вам. Вы ж такие.
Только не дают. Ибо админы — обслуживающий персонал, и вокруг них мир не вертится.
h>> Это не аргументы. Наличие данного файла не отвечает на поставленный мною вопрос: h>>
Какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
S>Я уже 100500 раз отвечал: тем, что по факту там не www, а данные для приложения (веб, не-веб — не важно).
www — это тоже данные для приложения Просто веб-браузер умеет абсолютную белиберду трансформировать в воспринимаемый хуманами вид.
При этом тот самый www может отдавать что угодно:
— неформатированый текст
— форматированый текст в разных форматах (HTML, XML, JSON, CSV...)
— двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.)
Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п.
Чем это отличается от любых других данных — :хз: То есть всем понятно, что вообще ничем не отличается. Главное — чтобы принимающая сторона знала, что с этими данными делать. И только Шеридан свято верит в сферовакуумный www.
Здравствуйте, Sheridan, Вы писали:
G>> S>А вот админам свинью подкладываете, да. G>> Это вы, админы, нам регулярно свиней подкладываете. S>С каимито неправильными админами ты работал. С малолетками небось, возомнившими себя богами? Таких да, надо учить.
Всякие попадались. Попадались и нормальные, которые не пытаются учить программеров жизни, а просто делают свою работу, и делают ее очень хорошо. Таких мало. Попадались в большом количестве ленивые, некомпетентные, тупые, самодовольные, нихрена не хотящие ничего делать.
G>> S>Не жалуйтесь потом что админы вас не уважают. G>> А мы и не жалуемся. Просто используем HTTP, и все. S>А по нормальному надо бы прийти к томуже админу и посоветоваться.
С какой стати? Нормальный разработчик распределенных сетевых приложений куда компетентнее в сетевых технологиях и архитектуре этих приложений, чем админ. Что бы последним не казалось.
Другое дело, если рядом есть квалифицированный сетевой инженер, скажем, CCIE. С ним полезно проконсультироваться в сложных ситуациях, но до них обычным "админам" как до луны. И разумеется, никто не будет отвлекать сетевого инженера глупостями, вроде того — какой протокол прикладного уровня ему использовать.
G>> S>Вот за это надо отстреливать конечности по частям, с неделей таймаута между выстрелами. G>> Ну разумется. Только дай вам, админам, волю — и все будет для окружающих максимально через жопу, зато — удобно вам. Вы ж такие. G>> Только не дают. Ибо админы — обслуживающий персонал, и вокруг них мир не вертится. S>Стопудово работал ты только с малолетними админами. Ну или с такими, которым на своих пользователей насрать.
Ну вот, например — ты так уверен, что админская служба транснациональной компании CQG, обладающей глобальной сетью передачи данных для трансляции котировок с бирж всего мира в реальном времени — состоит из малолетних админов?
Знаешь, насколько там хорошие админы? Косвенным критерием является то — что я даже не помню, как их зовут, ибо
1) У них почему-то просто "все работает", и все. Их не надо дергать, и нет повода к ним ходить и как-то специально знакомится с ними. Когда надо — они быстро и четко выполняют запрос, поставленный через систему. И все.
2) Они при этом не лезут учить жизни разработчиков распределенного ПО из собственного R&D центра, указывая им, какие по их мнению стеки протоколов им надо использовать для своих задач, а какие нет. Что уже говорит очень о многом.
Здравствуйте, kochetkov.vladimir, Вы писали:
k> И, кстати у меня никакого udp нет: k> Что будем делать с этой маленькой разницей? Давай определим голосованием, чей файл эталоннее?
Здравствуйте, Sheridan, Вы писали:
S>Подмена портов работает на малом количестве народа, до 100 человек по моим ощущениям. Им можно сообщить. А когда народа много пользуется сервисом — у тебя просто проблема взлома сменится на проблему "у меня непашет, строчнопочените!!!111"
Налицо полное непонимание устройства интернета. И, в частности, популярных протоколов.
К примеру, сменить порт outgoing MTA — это одно. Сменить порт incoming MTA — совсем другое. В частности, потому, что RFC974 никаким образом не регламентирует способ узнать порт, на котором висит почтовик. Так что он вынужден висеть на 25м порту за отсутствием средств коммуникации.
Зато вот RFC3263 предписывает SIP-агентам пользоваться SRV-записями, в которых номер порта прописан явно. Благодаря этому, SIP-сервер совершенно не обязан висеть на 5061м порту. Независимо от количества народа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
h>>> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S>>Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
M>Что такое левые данные относительно порта 80? M>Что такое левые данные относительно какого-либо порта вообще?
The Well Known Ports are those from 0 through 1023.
DCCP Well Known ports SHOULD NOT be used without IANA registration.
The registration procedure is defined in [RFC4340], Section 19.9.
The Registered Ports are those from 1024 through 49151
DCCP Registered ports SHOULD NOT be used without IANA registration.
The registration procedure is defined in [RFC4340], Section 19.9.
=========
Хорошо известные порты — это порты 0-1023
Хорошо известные порты нежелательно использовать (но возможно — прим. мое) без регистрации приложения в IANA
Зарегистрированные порты — это порты 1024-49151
Зарегистрированные порты нежелательно использовать (но возможно — прим. мое) без регистрации приложения в IANA
Более того:
* 2. ASSIGNMENT OF A PORT NUMBER DOES NOT IN ANY WAY IMPLY AN *
* ENDORSEMENT OF AN APPLICATION OR PRODUCT, AND THE FACT THAT NETWORK *
* TRAFFIC IS FLOWING TO OR FROM A REGISTERED PORT DOES NOT MEAN THAT *
* IT IS "GOOD" TRAFFIC. FIREWALL AND SYSTEM ADMINISTRATORS SHOULD *
* CHOOSE HOW TO CONFIGURE THEIR SYSTEMS BASED ON THEIR KNOWLEDGE OF *
* THE TRAFFIC IN QUESTION, NOT WHETHER THERE IS A PORT NUMBER *
* REGISTERED OR NOT. *
=========
2. Назначение порта не означает рекламу какого-либо прилоения или продукта, а сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
Регистрация порта — это всего лишь рекомендация, облегчающая взаимодействие гетерогенных систем, не более. Такого понятия, как «левые данные», для порта не существует. Порту вообще пофиг, какие данные передавать.
Здравствуйте, legogogo, Вы писали:
L>Это для программиста требование?
Ну не для комбайнёра же
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Приветствую, Gaperton, вы писали:
G> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно.
Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же.
А вот админам свинью подкладываете, да. Не жалуйтесь потом что админы вас не уважают.
G> Одна из причин — он хорошо проходит через файрволы, не требуя дополнительной конфигурации. Просто работает. И все.
Вот за это надо отстреливать конечности по частям, с неделей таймаута между выстрелами.
Здравствуйте, Sheridan, Вы писали:
k>> А назло работающий (еще и через файрволы, а что еще важнее, через всяческие NAT'ы) HTTP, дискредитирует здесь точку зрения Шеридана, что нет ничего более разумного, нежели разрабатывать на каждый чих свой собственный протокол с хэндшейком и куками, исключительно ради некоей оптимизации трафика, быстродействия и чего-то там еще.
S>Именно. Я конечно понимаю что всем лениво, но настаиваю и буду настаивать на этом. В крайнем случае, хрен с вами, пользуйте http, но, тля, уйдите с 80 порта!
Будем ради твоего каприза по двадцать пять экземпляров веб и application серверов на одной машине разворачивать? Внесем путаницу в свои веб-сервисы, и заставим админов по всему миру менять настройки проксей и файрволов для наших сервисов? И поставим раком все оффлайновые веб-приложения, которые полагаются на same origin security policy, и тупо откажутся работать?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Gaperton, вы писали:
G>> Скайп его использует не всегда, а тока в крайнем случае, когда не может нормальным способом пролезть через настроенный криворукими админами прокси. Ты знал, нет?
G>> Не от хорошей жизни он использует, а для борьбы с вами, админами. Ибо — когда гонишь голос через HTTP имеешь нихреновый jitter, и никто, имея выбор из других вариантов, так поступать не будет. Для телефонии предназначены SIP и RTP поверх UDP. Хотя конкретно Скайп ими и не пользуется — у него проприетарные протоколы.
S>Что, правда, чтоле?
The Skype protocol seems to prefer the use of UDP for voice transmission as much as possible.
S>А мужики то не знают, надо же
Теперь знают. Skype — необычайно адаптивен к сетевому окружению, и если не может войти в дверь — лезет в окно. Благодаря этому своему свойству, он и оказался популярен.
S>А вот бороться с нами не надо. С нами надо общаться. А то бывает смотришь — человек тунель роет, кнему подойдешь этак — спрашиваешь , мол "зачем, мил человек, тунель сквозь icmp копаешь?" — а он — "а вы сволочи все прикрыли доступ к жабберу". И ведь не подойдет никто, не попросит чтототам открыть, все копать начинают. А казалось бы — чего стоит то попросить? Откроют конечно, если сие не противоречит политикам организации (типа запрета чатицца в рабочее время). Думаете от хорошей жизни приходится на сплошном -j DROP сидеть и даже себе открывать порты по необходимости? S>Так что не стесняйтесь, ходите и просите. Если отказывается — то спросите причину отказа. Если чтото типа "так надо" — то вперед к начальству, ибо у вас возомнивший себя богом админ засел, а таких надо обучать, и обучать жестоко.
Не просто роют, — а как мы видим на примере скайпа — роют автоматизированно, и в промышленных масштабах. Все почему? Потому, что вы, админы, шибко сильно такие админы.
Открой у себя скайпу прямую дорожку, короче, и он сразу же начнет вести себя прилично .
M>> Я вот перевел себе ssh с 22-го порта на 23-й, исчезло много левого трафика на сайт. Пойду резать себе пальцы по методу Шеридана.
S>А я каждый час сканирую логи и дропаю на неделю файрволом зарвавшихся личностей. S>Твой подход лишь отметает роботов, которые не знают про nmap и тупо долбятся по известным портам
Но мне все равно надо отрубать пальцы, я так понимаю. Я же нарушил Главную Заповедь Шеридана: не возжелай себе порта ближнего своего
Здравствуйте, Sheridan, Вы писали:
G>> S>Что, правда, чтоле?
G>> Правда.
S>Ды тействительно поверил, что я этого не знаю?
Мне совершенно пофиг, на самом деле, или не на самом деле ты этого не знаешь. Это мало того, что проверить невозможно, так это знание для меня еще и совершенно бесполезно.
Но если тебе интересно мое мнение — выше ты показал настолько вопиющую безграмотность в куда более простых и открытых протоколах, что теперь нет оснований предполагать, что ты вообще хоть в чем-то разбираешься.
Еще и других учить пытаешься. Таким образом, по классификации Омара Хайяма — ты относишься к типу "не знает, и не знает, что он не знает", т.е. дурак, общения с которым следует избегать.
G>>>> Правда.
S>>>Ды тействительно поверил, что я этого не знаю?
G>>Еще и других учить пытаешься. Таким образом, по классификации Омара Хайяма — ты относишься к типу "не знает, и не знает, что он не знает", т.е. дурак, общения с которым следует избегать.
G>Ничего личного, кстати. Я не испытываю никакой радости от того, что ты позоришься на всю сеть, trust me. Ибо ты делаешь это грустно и уныло. Я даже тебе материалы для самообразования привел.
Не ты первый и не в первый раз. И, опять же не ты последний, и не в последний раз. Шеридан приводимые ему ссылки не чиатет принципиально.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Gaperton, Вы писали:
G>>SHALL — это не MUST. Соблюдать его не обязательно.
G>>Учимся читать rfc: www.ietf.org/rfc/rfc2119.txt
G>
G>1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
G> definition is an absolute requirement of the specification.
Хм. Ну да, похоже, перепутал с should. Надо же, все таки облажался. Надо было глянуть в rfc. Виноватдуракисправлюсь.
Здравствуйте, hattab, Вы писали:
S>> k> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
S>> То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее. S>> Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
H>А-а-а, так ты работать не хочешь? Горе-админы такие горе-админы...
Этот "тезис" отлично разворачивается в обратную сторону — на горе-программистов, которым лень оторвать попу и пошевелить пальцем, чтобы за счёт легко определяемых признаков (таких, как номер порта) сделать администрирование менее проблемным.
Здравствуйте, Gaperton, Вы писали:
G>При этом, архитектура на основе REST (Representational State Transfer) обладает целым рядом преимуществ, не только перед RPC поверх HTTP, но и перед RPC вообще. См. диссертацию: G>http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Ну сколько можно эти городские легенды повторять?
Архитектура чего? Каким рядом преимуществ?
Если рассматривать на основе критерия loose coupling, REST — тот же RPC, вид сбоку.
Здравствуйте, Sheridan, Вы писали:
S> h> S> Прсто выделяйте порты для сервисов.
S> h> Это не решение. Юзер может настроить прилагу на какой угодно порт.
S> А по умолчанию — какой? Ибо он и будет в 90% случаев использоваться. S> Более того, речь идет о юзерском софте или всетаки о серверном софте?
Совершенно неважно какой порт стоит по умолчанию. Совершенно не важно о каком, серверном/клиентском, софте речь. Если юзер захочет пользоваться службой и не сможет, он начнет искать способы решения своей проблемы, и будь уверен он их найдет. Да ты и сам осведомлен, похоже
Например, жаббер оржидается на 5222 или 5223 портах. Прикрываем их стеной, никто в жаббер не может вылезти, красота. Но тут находится перец, который дома поднимает сервер на 80 порту, который открыт политиками. В итоге имеем грубое нарушение правил, причем намеренное. Причем админ останется невиновным только при достаточно вменяемом начальстве.
S> h> В коде номер порта (окромя дефолтного, разумеется) задают только очень недалекие товарищи. Мы им уподобляться не будем.
S> Что по умолчанию стоит?
А о чем речь? Наверняка, большинство веб-сервисов сидит на 80-ом порту, что не удивительно
S> h> S> h> Да не смеши меня. http://www.example.com:123/
S> h> S> Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться?
S> h> Выше ответил.
S> При чем тут юзеры? Речь про серверный софт, про сервисы. А не про клиентские части.
Разницы никакой. Что первый настраивается, что второй
Здравствуйте, legogogo, Вы писали:
L>Здравствуйте, Smooky, Вы писали:
S>>Ну к нам в контору вообще нельзя попасть, незная общеканальную сигнализацию (ОКС№7), и знания межстанционных протоколов начиная от LapB (ходит под TCP) и до TCAP/RANAP/BSSAP/... и заканчивая протоколами прикладного уровня HTTP/FTP/...(хотя в принципе они нафиг не нужны, так, для общего развития). S>>Ну и по крайней мере хотя бы быть знакомым с рекомендациями Motorola (Q.XXX).
L>Это для программиста требование?
Это же Smooky. Тот самый, который в Праге с Жужжаной. Теперь у него ОКС№7 в Праге завелся... Меньше уши развешивайте, батенька
M>> Не ты первый и не в первый раз. И, опять же не ты последний, и не в последний раз. Шеридан приводимые ему ссылки не чиатет принципиально.
S>Мамут, с чего ты взял что не читаю?
Опыт общения с тобой. Если бы ты читал хоть что-нибудь, в твоих текстах хоть что-нибудь когда-нибудь менялось бы.
S>Туже лецию, чтобы понять о чем оно — я читал. Не всю конечно, на всю меня не хватит, так как язык там вражеский.
M>> Да, это облегчает жизнь, но это не является абсолютным императивом.
S>Я вот как раз об этом разговор и веду.
Нет. Ты говоришь, что, грубо говоря, никто никогда ни при каких условиях просто не имеет права занимать никакие порты, потому что нельзя, чтобы там был левый трафик
Что такое левый трафик по отношению к портам, ты так и не объяснил.
Почему нельзя занимать порты, ты так и не объяснил. Более того, ты попрекаешь нам, что мы не следум стандартам, но при этом стандарт напрямую противоречит тебе и говорит, что занимать порты всего лишь нежелательно.
А началось все с какого-то внутрикорпоративного софта, который решил работать по 80-му порту. Так пусть себе работает, нет никаких причин на то, чтобы он там не работал.
Здравствуйте, Sheridan, Вы писали:
S> h> S> h> И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
S> h> Вариантов масса. Сервис может отдать админку с мордой на Flex'е, может отдать доку с описанием методов сервиса и их параметров, может просто редиректить на правильный эндпоинт.
S> Уговорил. В таком варианте вполне приемлемо. Только я бы все равно перенес на другой порт, ибо по сути это не web.
XML-RPC это XML over HTTP. По дефолту HTTP ходит на 80 порт. Но ты бы все равно перенес... Кто нибудь может мне логику сего объяснить?
S> h> А теперь ты на вопрос (выделил) ответишь?
S> Если без того, что ты описал, то нарушает здравый смысл.
Вот видишь, по сути ты ничего не можешь возразить, а еще пальцы стрелять порывался.
Приветствую, Mamut, вы писали:
M> /etc/services появился там не просто так. Он является всего лишь копией некоего документа под названием Port Numbers от наивысшего органа стандартизации, IANA. Что написано в этому документе, тебе уже было сказано
. Но, блин, это же надо читать и вникнуть, но ты этого физиологически не умеешь.
Еще недавно ты ругал меня за то, что я руководствуюсь этим документом. Теперь ты сам на него ссылаешься. Что изменилось?
M> Ну и вопросы: M> — Что значит левые данные по отношению к порту? Где вообще прописано отношение данных к порту?
Как ни странно, в том самом документе, на который ты ссылаешься.
Например,
domain 53/tcp Domain Name Server
domain 53/udp Domain Name Server
Какие данные там ходят по твоему? Какой софт пользуется портом? Что будет, если мы решим на этом порту поднять например nntp?
M> — Что произойдет с товим сервисом на порту, скажем, 14 (unassigned), если я заполню форму регистрации порта и захапаю его себе?
Я буду вынужден поменять порт и форсировать его регистрацию в iana. Ваш, К.О.
M> — Почему я не могу использовать порты, которые зарегистрированы на сервисы, которых в природе уже не существует (Finger, Xyplex, OCBinder, Remote-KIS)?
Судя по iana, они существуют. Не существует например, 81
# 81 Unassigned (Removed on 2007-09-06)
M> — Почему RSS и SOAP поверх 80-го порта — это нормально по-твоему, а все остальное ненормально?
По моему и это — ненормально. Мне просто уже надоедает этот разговор, и близок момент, когда я соглашусь только потому, что вы меня задолбали.
Здравствуйте, Mamut, Вы писали:
E__>>Скажем так, ни я, ни кто-либо из моих знакомых/сотрудников/прочих собеседников не видел ни разу ни одной адекватной госконторы. Везде одинаково: по куче причин(бюрократия, копеечные зп, имбецильное начальство, непрофессионализм — да тысячи их, все долго перечислять) эффективность выполняемой работы не то что болтается в конце приоритетов, а вообще отсутствует в этом списке. Все делается "на отъ#бись". Об адекватности в таких условиях даже говорить не приходится. E__>>Я говорю, понятное дело, про госконторы в пост-ссср. Если ты знаешь обратные примеры, приведи их, пожалуйста. E__>>ЗЫ решение "закрыть нахер все порты, в том числе и www" — это как раз то самое "сделать на отъ#бись". M>Ну, вообще-то в госконторах нафиг не нужны никакие порты кроме рабочих. 80-й к ним явно не относится
Понимаешь, я лично убежден, что
а. Полезность сотрудника в количестве и качестве результатов работы, а не в жопочасах*
б. Для эффективной работы человеку нужно иногда отдыхать
в. Постоянный прессинг, надзор, тотальные запреты со стороны начальства очень плохо влияют на эффективность работы
Да, в госконторе если открыть 80, то сотрудники тупо засядут на вконтакты и пр., забив еще более крупный болт на работу, чем сейчас. Потому как они не мотивированы на работу, у них нет никакого смысла работать вообще, и уж тем более хорошо. Если бы клерк(хотя не, клерк это на западе, у нас это "противная тетка в окошке") получал с каждого принятого посетителя определенную сумму, и при этом штрафовался на 5 таких сумм за каждого недовольного, он(она) работал бы быстро, с улыбкой на лице, и открытый 80-й порт работе бы не мешал, так как он лазил бы по инету только в свободное время. Но в гос котнорах все по-другому через жопу, так что...
* У нас в госконторах(и не только) частенько практикуется вообще совершенно упоротый подход: полезность измеряется в мифическом количестве работы(см. анек под катом, осторожно, мат). То есть, не важно, что никто не производит ничего полезного. Главное, чтобы все подчиненные работали в поте лица. С точки зрения здравого смысла это полный нонсенс, но у нас это бывает частенько.
Скрытый текст
Берите лом. Метите плац! Отсюда и до вечера!!!
Тов. майор... Так мы ж не подметём!
А я и не хочу, чтоб вы подмели! Я хочу, чтобы вы заебались!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Sheridan, Вы писали:
M>> При этом тот самый www может отдавать что угодно: M>> — неформатированый текст S>Ничего удивительного, это для него html без тегов, можно сказать — вырожденый html
Ты разрабатывал браузеры?
M>> — форматированый текст в разных форматах (HTML, XML, JSON, CSV...) M>> — двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.) S>И много из этого показывает не браузер, а ole-объекты, которые браузер вызывает и встраивает в себя S>так или иначе браузер подтягивает нужный софт и показывает с помощью его, а не самостоятельно
А какая разница? Пусть хоть господь бог показывает, от этого траффик с RSS (который таки XML и отлично отображается в браузере) перестает быть www?
Или ты считаешь что www = http = html?
M>> Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п. S>Все верно. И в рамках страницы, на которой все это внедрено — без проблем, показывайте. S>Но не суйте туда того, чего там быть не должно. Не суйте туда rpc вне рамок веб-приложений, не суйте туда чтото по типу скайпа итд.
А если скайп резко начнет работать в браузере, то ему можно будет?
Таким образом ты не можешь определить тип трафика по его свойствам, ты его определяешь по потребителю.
Значит и контролировать ты должен не сам трафик (порты), а потребителя (программы).
Включи мозг уже, а то сам начинаешь доказывать что неправ.
Здравствуйте, hattab, Вы писали:
n>> n>> Этот "тезис" отлично разворачивается в обратную сторону — на горе-программистов, которым лень оторвать попу и пошевелить пальцем, чтобы за счёт легко определяемых признаков (таких, как номер порта) сделать администрирование менее проблемным. n>> H>Номера портов часто бывают настраиваемыми в софте (и это правильно) т.ч. не аргумент вообще. n>> "т.ч." это "таким чином" или что-то другое? H>"так что"
Хм, непривычное сокращение.
n>> Тут уже звучал принципиальный тезис Гапертона про то, что всё пускать через порт 80 — правильно и чуть ли не единственно правильно. Поэтому речь не о возможности настройки, а о принципиальной позиции. H>Тезис Гапертона следует обсуждать с Гапертоном, я думаю :xz:
Зачем же так себя лимитировать?;)
H> Шеридан тут вообще сказал, что 80 порт он только для WWW, а не HTTP в целом (не буквально так, но это следует из его реплик). Я тут, собственно, только об этом спорю.
Ну в общем по нормативам IANA так оно и есть — 80 оно для WWW. Другой вопрос, что считать WWW и почему. Их спор, если исключить эмоциональные составляющие и давнюю историю махания красными тряпками перед быком, сводится к поиску оптимального баланса между нетривиальными выборами с обеих сторон, отягощёнными наследственностью решений и политик, и в общем-то не имеет никакого общего смысла — только частный для конкретных условий.
Здравствуйте, hattab, Вы писали:
n>> n>> Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
n>> H>Очевидно, что решая проблему средствами которыми она не решается, вы ее не решите никогда :xz:
n>> Вот ты и подписался под тем, чтобы дать средства, которые позволят решить задачу. То есть — разделить по портам.
H>Это не решение, ибо на это вы повлиять никак не можете.
Если "вы" это "админы", то тривиально. Пишется докладная записка — в связи с невозможностью разделить XXX, предлагаю три варианта решения
1) покупается железяка за ZZZK$$
2) запрещается всё
3) разрешается всё
и если выбран вариант (2) — а это очень вероятно — то следующая очередь страдать будет уже за авторами сайта.
Здравствуйте, Mamut, Вы писали:
S>>Налицо полное непонимание устройства интернета. И, в частности, популярных протоколов. S>>К примеру, сменить порт outgoing MTA — это одно. Сменить порт incoming MTA — совсем другое. В частности, потому, что RFC974 никаким образом не регламентирует способ узнать порт, на котором висит почтовик. Так что он вынужден висеть на 25м порту за отсутствием средств коммуникации.
M>При этом никто не мешает их менять, как это делает, например, Google: http://mail.google.com/support/bin/answer.py?hl=en&answer=13287 И ничего, все довольны.
По ссылке речь идёт об outgoing MTA. Для входящей почты гугл, как и все, использует 25. Я же говорю — есть различия.
Но чтобы в этом разбираться, надо быть хотя бы хорошим админом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>The Well Known Ports are those from 0 through 1023.
M>DCCP Well Known ports SHOULD NOT be used without IANA registration. M>The registration procedure is defined in [RFC4340], Section 19.9.
M>The Registered Ports are those from 1024 through 49151
M>DCCP Registered ports SHOULD NOT be used without IANA registration. M>The registration procedure is defined in [RFC4340], Section 19.9.
M>=========
M>Хорошо известные порты — это порты 0-1023
M>Хорошо известные порты нежелательно использовать (но возможно — прим. мое) без регистрации приложения в IANA
Вообще-то тут требование даже слабее. Ты почему-то при переводе на русский скромно выбросил слово "DCCP" из этих фраз. Это не слово-связка, как "%ля":), это Datagram Congestion Control Protocol. Это я к тому, что вообще-то по крайней мере в этом документе нет ни слова регулировки (по типу SHOULD) использования этих портов применительно к TCP, UDP, SCTP и почти всему остальному, что имеет порты.
M>Регистрация порта — это всего лишь рекомендация, облегчающая взаимодействие гетерогенных систем, не более. Такого понятия, как «левые данные», для порта не существует. Порту вообще пофиг, какие данные передавать.
Угу. Более того, диапазон этих registered многие воспринимают совершенно иначе. Например, в Linux по умолчанию область свободного динамического выделения — 32768-61000. А не 49152-65535. А вот во FreeBSD — именно последняя.
Здравствуйте, legogogo, Вы писали:
L>Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. L>Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт или знание их физического устройства и реализации на текущей платформе, и умения применять при написание софта? Проще говоря, подразумевает ли это знание реализации устройства сетевого стека в ядре?
Ну к нам в контору вообще нельзя попасть, незная общеканальную сигнализацию (ОКС№7), и знания межстанционных протоколов начиная от LapB (ходит под TCP) и до TCAP/RANAP/BSSAP/... и заканчивая протоколами прикладного уровня HTTP/FTP/...(хотя в принципе они нафиг не нужны, так, для общего развития).
Ну и по крайней мере хотя бы быть знакомым с рекомендациями Motorola (Q.XXX).
Только Путин, и никого кроме Путина! О Великий и Могучий Путин — царь на веки веков, навсегда!
Смотрю только Соловьева и Михеева, для меня это самые авторитетные эксперты.
КРЫМ НАШ! СКОРО И ВСЯ УКРАИНА БУДЕТ НАШЕЙ!
Здравствуйте, Mamut, Вы писали:
l>>> Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. l>>> Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? S>>Да просто для того, чтобы имели представление о том как все работает, и использовали бы свои знания, создавая соответствующий ситуации протокол. А то развелось, блин, народа, которые к месту и не к месту лепят обмен данными через http. M>Это у тебя какие-то сексуальные фантазии на тему такого народа
это он просто не знает, как прикрыть этот траффик :3
сейчас часто http используется в качестве транспорта для своего протокола.. так работают многие онлайн-игры (в основном соц-казуалки)..
G>> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно. S>Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же.
Шеридан, завязывай с оскорблениями. Система, построенная поверх HTTP или поверх него же с использованием REST-подходов может быть на несколько порядков сложнее всего, что ты когда-либо сделал в жизни.
Думать не надо, ага. Ты бы хоть раз в жизни подумал, ага.
L>Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт
Да. Это значит умение сочинять TCP/IP приложения, используя существующий стек. Если требуется умение сочинить стек самому, то пишут что-то вроде "навыков реализации TCP/IP стека". Ну, в идеальном мире, конечно. В реальном мире это может означать умение пользоваться интернет эксплорером
S>>>Да просто для того, чтобы имели представление о том как все работает, и использовали бы свои знания, создавая соответствующий ситуации протокол. А то развелось, блин, народа, которые к месту и не к месту лепят обмен данными через http.
M>>Это у тебя какие-то сексуальные фантазии на тему такого народа
PD>Ну это ты зря. До сих пор помню, как Синклер мне рекомендовал HTTP, абсолютно ничего не зная о моей задаче
Ну, он исходил из своих представлений о твоей задачи. Человеку свойственно ошибаться
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, kochetkov.vladimir, вы писали:
k>> А назло работающий (еще и через файрволы, а что еще важнее, через всяческие NAT'ы) HTTP, дискредитирует здесь точку зрения Шеридана, что нет ничего более разумного, нежели разрабатывать на каждый чих свой собственный протокол с хэндшейком и куками, исключительно ради некоей оптимизации трафика, быстродействия и чего-то там еще.
S>Именно. Я конечно понимаю что всем лениво, но настаиваю и буду настаивать на этом.
Лень — одно из наиболее ценных качеств, присущих человеку, благодаря которому наша цивилизация находится хотя бы там, где она есть сейчас, если ты не знал.
S>В крайнем случае, хрен с вами, пользуйте http, но, тля, уйдите с 80 порта!
А может быть тебе стоит перестать лениться и чуточку больше времени посвятить работе, чтобы фильтровать именно на 80-ом порту то, что тебе неугодно?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Gaperton, вы писали:
G>> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно. S>Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же. S>А вот админам свинью подкладываете, да. Не жалуйтесь потом что админы вас не уважают.
Здравствуйте, Sheridan, Вы писали:
G>> S>Мда... Казалось бы, чего сложного реализовать свой протокол?
G>> Его в принципе не будут кэшировать стандартные прокси, S>Почему ты считаешь, что твои данные кешируются?
Потому, что знаю принципы построения HTTP и REST-интерфейсов.
S>Если ты отправляешь каждый раз одни и теже данные, то нафига их вообще отправлять? Можно просто отправиить флаг "данные не изменились" — и пользовательские деньги сбережешь (многие через hdspa сидят, а оно нынче дорогое), и будет впечатление у пользователя что софтина быстрее работает.
Стандартное поведение метода HTTP Conditional GET. При этом, результаты запроса имеют хорошие шансы откешироваться на веб-проксе, что съэкономит тебе внешний трафик, и ускорит работу всех клиентов на твоем сайте, так как позволит забрать их из кэша другим пользователям того же домена. Более того, это позволяет мне поставить на своей ферме reverse-прокси, снять с нее часть нагрузки и поднять реактивность. С другим протоколом я этого просто так не получу.
S>Напротив, если ты каждый раз отправляешь новые данные, то что будет кешировать прокси? S>
Ликвидируй свою безграмотность, и почитай про REST, а потом уже лезь со своими умными мыслями к разработчикам. А лучше, вообще не лезь — позоришься только.
G>> для него всем надо будет также специально открывать порты, S>Да уж лучше я порт специально открою. К томуже юзерские файрволы довольно удобные в этом отношени. Всплывают красивые окошечки с описанием какая софтина куда хочет пойти...
Ты откроешь, другим для каждого приложения порты открывать — в лом.
S>Да какбы при разработке тцп\ип и предполагалось, что различный софт будет пользовать различные порты, не?
FYI, RPC-протоколы при этом спокон веков как бы работают как бы по одному порту. В том числе как бы предполагающийся RFC-1831 от IETF, который не только предполагает, но и располагает.
HTTP в веб-сервисах используется в качестве транспорта для осуществления RPC.
G>>к ним вообще невозможно будет доступаться из веб-браузеров (т.е. не только оффлайн приложения отвалятся). S>Назачем доступ к данным из веб-браузера? Для тестов?
Для AJAX веб-приложений.
S>А чем телнет не подходит? Сложно, чтоли?
Из браузера не работает.
G>>И — радикально усложнится задача использования сервиса сторонними разработчиками. S>ггг, ну это вообще смешно. Я nmea с обычного gpsd разбирал, читая ман и рядом в сеансе телнета тутже эксперементируя.
Это именно что не смешно. Не суди о том, о чем не имеешь ни малейшего понятия.
G>> Я тебе картинку "тимуровцы добывают кумыс" показывал? S>Вот уж воистину тимуровцы, ага.
Вообще-то она про тебя. Так показывал, или нет? Показать?
И все они работают поверх HTTP. Понятно, что там предполагалось инженерами Internet Engineering Task Force, нет?
При этом, архитектура на основе REST (Representational State Transfer) обладает целым рядом преимуществ, не только перед RPC поверх HTTP, но и перед RPC вообще. См. диссертацию: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Впрочем, что тебе объяснять — только портить. Удивительно, что я вообще тебе что-то объясняю. Давно пора бы в жопу послать.
Здравствуйте, Gaperton, Вы писали:
G> G>> С gzip-ом ты уже на гигабитной сетке упрешься в процессор. Вообще — у XML и без gzip довольно неприятный оверхэд на парсинг.
G> H>Парсинг XML (при использовании SAX) мало чем отличается от парсинга JSON
G> Тебе надо матчить именованные парные теги. А не тупо искать односимвольные лексемы в тупой скобочной грамматике. Разница, однако.
Разница конечно есть, но она не столь велика на самом деле. SAX он вообще матчингом не занимается, это делается в момент построения объектной модели и решается одним условным оператором. Кстати, я тут попробовал gzip погонять: на 3.3Ghz Феноме, однопоточное сжатие дает ~80Mb/sec, т.е. пара ядер, из четырех имеющихся, легко справятся с гигабитной сеткой (130Mb/sec вроде).
M>> Шеридан, завязывай с оскорблениями. Система, построенная поверх HTTP или поверх него же с использованием REST-подходов может быть на несколько порядков сложнее всего, что ты когда-либо сделал в жизни. S>И что? Это должно означать чтобы я молчал в тряпочку?
Именно
S>А когда я увижу судью, избивающего моего друга, мне тоже развернуться и уйти, так как судья о законах думает больше меня?
Причем тут эта аналогия, вообще непонятно
M>> Думать не надо, ага. Ты бы хоть раз в жизни подумал, ага. S>Думать как раз таки надо Мамут. И не только в сторону "а хрен с ним, прикрутим http"
Шеридан, завязывай с оскорблениями. Система, построенная поверх HTTP или поверх него же с использованием REST-подходов может быть на несколько порядков сложнее всего, что ты когда-либо сделал в жизни.
Здравствуйте, hattab, Вы писали:
G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
Да ну, брось. Отлично жуется любая кодировка. Никаких фундаментальных причин на то, что должна быть именно юникод — нет. Точно так же, как и для веб-страниц. Может, для JSON-RPC это в стандарте и прописано (что странно, и на что в своем решении ты можешь без особого ущерба подзабить), но в случае с REST меня это точно не волнует.
Здравствуйте, Mamut, Вы писали:
G>>Ничего личного, кстати. Я не испытываю никакой радости от того, что ты позоришься на всю сеть, trust me. Ибо ты делаешь это грустно и уныло. Я даже тебе материалы для самообразования привел.
M>Не ты первый и не в первый раз. И, опять же не ты последний, и не в последний раз. Шеридан приводимые ему ссылки не чиатет принципиально.
Ну, я-то действую исходя из собственных понятий, а не мнения окружения . И по ним сейчас полагалось привести ссылки, не зависимо от того, имел он раньше обыкновение их читать, или нет. Просто, потому, что так правильно.
Здравствуйте, Mamut, Вы писали:
h>>> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S>>Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
M>Что такое левые данные относительно порта 80? M>Что такое левые данные относительно какого-либо порта вообще?
Ну, как. Вот заходишь ты, скажем, по ssh, и начинаешь файло гонять. Или базааровский репозиторий синхронизировать, вместо того, чтобы неострелляными пальцами в удаленный терминал тыкать. Или еще чего. Левые данные? Левые.
h>>>> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S>>>Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
M>>Что такое левые данные относительно порта 80? M>>Что такое левые данные относительно какого-либо порта вообще?
G>Ну, как. Вот заходишь ты, скажем, по ssh, и начинаешь файло гонять. Или базааровский репозиторий синхронизировать, вместо того, чтобы неострелляными пальцами в удаленный терминал тыкать. Или еще чего. Левые данные? Левые.
У меня все хуже У меня помимо файло и git'а (вместо bazaar'а) еще отягчающий факт в виде ssh не на 22-м порту, а на 23-м
Я уже умолчу про то, что erlanger.ru висит на самом деле на порту 9090, и на него проксируется nginx'ом Про апач на 81-м порту говорить, пожалуй, не стану И mysql я, вроде, переносил с 3306 на другой порт, но не факт
Здравствуйте, netch80, Вы писали:
n> H>Тезис Гапертона следует обсуждать с Гапертоном, я думаю
n> Зачем же так себя лимитировать?
Отвечаю только за свой базар
n> H> Шеридан тут вообще сказал, что 80 порт он только для WWW, а не HTTP в целом (не буквально так, но это следует из его реплик). Я тут, собственно, только об этом спорю.
n> Ну в общем по нормативам IANA так оно и есть — 80 оно для WWW. Другой вопрос, что считать WWW и почему.
WWW без HTTP(S) не бывает (и в документах IANA оно значится, как World Wide Web HTTP). Значит говорим о протоколе. Возможности протокола позволяют использовать его в качестве транспорта для других служб (не WWW). Возможности штатные. Стандарт не нарушается. В чем проблема? Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, gandjustas, вы писали:
g>> Есть хоть одна адекватная контора, где перекрыт весь www трафик? S>Пенсионный фонд, равно как и все государственные организации.
К сожалению все госструктры не являются адекватными в принципе.
g>> Ты понимаешь что если всем пользователям компании перекрыть нафиг гугл, про производительность может упасть в разы? g>> А если понимаешь, то почему не можешь объяснить это начальству? S>Я как раз и хочу оставить 80 порт открытым, но прибить все остальное, которое пользует этот 80й порт, но не является http://www
Ты сам описал условие фильтра на прокси
Хотя я уверен что ты что-то другое хотел сказать.
S>Вот об этом тут разговор, а не про "закрыть все нафик"
Просто формализуй что пускать, а что не пускать и сделай такие правила на прокси.
g>> А вообще такая задача решается прозрачной аутентификацией на прокси, домен windows + isa server (ныне TMG) так умеют. g>> Тот софт который должен ходить через www просто работает под специально созданной учетной записью. S>Понимаешь, при адекватной разработке некоторого софта — это бы не понадобилось поднимать.
Настройка доступа с помощью учетной записи и заголовков HTTP гораздо гибче, чем портами. Например в своем кастомном протоколе ты в жизни не сможешь сделать ограничение доступа в сеть по имени хоста или пользователю. Поэтому использование HTTP дает гораздо больше возможностей реализации корпоративной политики, чем тупо фильтры по портам и IP адресам. Это как раз является более адекватным с точки зрения разработки.
Использование www по-умолчанию позволяет размещать в сети сервер и не требовать настройки клиентских машин и сетей. Задумайся об этом.
S>А я тут смотрю, использование http://www для своих нужд очень в моде.
Если уж так сильно тебя напрягает, то вполне можно направить HTTP трафик по другому порту, если клиент и сервер тебе доступны. Благо чуть менее чем весь софт это позволяет.
ЗЫ Вообще я начинаю сомневаться в твоей квалификации админа. Точнее как технический спец ты может и не плох, но как архитектор не очень совсем.
Лучше изучи работу HTTP и всего что работает поверх (ссылку на дисер филдинга тебе давали), это сильно расширит твой кругозор.
M>> S>Я вижу не только лень чтото делать, но еще и убежденность в своей правоте.
M>> Интересно, что ты себя именно так и ведешь (см. свой же спор про /etc/services несмотря на приведенный документ от IANA)
S>На моей стороне общемировая практика. И тут вдруг оказывается — что все вокруг дураки, раз договариваются о том, на каком порту чему висеть, и все оказывается надо на 80 порт переводить.
Во-первых, никто не говорит о том, что все надо переводить на 80-й порт. Свои сексуальные фантазии оставь при себе.
Во-вторых, про то, что это общемировая практика, я сам тебе говорил, и не раз:
Регистрация порта — это всего лишь рекомендация, облегчающая взаимодействие гетерогенных систем, не более.
Регистрация портов существует только для облегчения взаимодействия гетерогенных систем.
Но ты же любишь сдушать только голоса в своей голове
В-третьих, общемировая практика говорит, что перевод любого софта на любой другой порт — это общемировая практика. И, прикинь, ничто не ломается, все работает, как работало дальше (при условии, что все службы, работающие с этим софтом так же переведены на другой порт). Было бы это не так, у тебя бы не было опций для смены порта в практически любом софте.
M>> h>> Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет.
M>> S>Прсто выделяйте порты для сервисов.
M>> 1. Сервисов в мире больше, чем портов — это во-первых. S>И все они будут одновременно подняты на одном сервере?
Учитывая, что в сеть вылазит все больше и больше программ, то почему бы и нет Тем более, что, судя по твоей логике, даже веб-сервисы надо переводить на разные порты.
M>> 2. Порты являются всего лишь соглашением между производителями софта, не более. S>Зачем нарушать эти соглашения? Есть общемировая практика (жаббер — 5222 итд) — ЗАЧЕМ делать по другому?
За печкой. Может быть миллион причин — вплоть до «обеспечить работу приложения даже в условиях, когда закрыты все порты, кроме 80 и 5222». Примеры тебе привели в «сетях».
M>> 3. NAT + кастомный порт — это зло S>С чего это?
Кто этот порт будет открывать? Да никто. А 80-й открыт в 99.9% случаев. Тебя же не смущает, что Flash работает? Хотя у него вообще какой-то свой протокол, но работает поверх 80-го порта.
M>> S>Что вызывает меньше трудозатрат? M>> Неверная оценка трудозатрат S>Ты подумал перед тем как описать? Опиши свой ход мыслей.
Конечно подумал. Благо, работаю по професси долго.
M>> S>Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться? M>> И не только браузер. Софту пофиг, в какой порт стучаться.
S>Конечно пофиг.
M>> Порт не определяет данные, которые по нему идут. Это, блин, черным по белому написано даже в регулирующем документе. Не говоря уже о том, что это, блин, понятно безо всяких документов. S>Мамут, не пытайся показать меня идиотом. Я не говорю о том, что данные нельзя пустить по другому порту. Я говорю о том, что это НЕ НАДО делать.
Не НЕ НАДО, а нежелательно. За тебя IANA уже все сказала. Ты у нас требовал, чтобы все следовали стандартам? Так вот, изволь, получи и распишись
Именно. «Не надо» и «нежелательно» — это вообще абсолютно разные вещи.
M>> Если ты, как админ, полагаешься на номера портов, то грош тебе цена, как админу. S>Если ты программист, и не можешь понять до сих пор — о чем разговор, то грош тебе цена как программисту.
Я прекрасно понимаю, о чем разговор. Это ты не понимаешь.
Здравствуйте, Sheridan, Вы писали:
S> M> S>Мамут, с чего ты взял что не читаю?
S> M> Опыт общения с тобой. Если бы ты читал хоть что-нибудь, в твоих текстах хоть что-нибудь когда-нибудь менялось бы.
S> Я привык не подстраиваться под общее мнение, а придерживаться того, что считаю правильным. Поэтому ни реклама на меня не действует, ни нлп, ни твои попытки. S> Когда же я действительно неправ — я это признаю. Но сейчас, в этом разговоре про порты — я прав.
И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
M>>>> Когда ты наконец-то поймешь, что софт, работающий по 80-му порту может быть не халтурой?
S>>>Я не говорю, что софт — халтура, я говорю о том, что халтурно сделана сетевая прослойка в плане того, на каком порту висеть сервису.
M>>А у тебя, видмо, есть прямо таки железобетонные аргументы, почему выбор такого способа коммуникации, — это халтура? Хотелось бы их услышать. M_>ну хотя бы одно уже то, что авторы захардкодили номер сетевого порта для работы — уже признак халтуры.
Где? Если действительно захардкодили, то это — халтура вне зависимости от порта
Приветствую, Mamut, вы писали:
M> Ну а теперь не пытаются. Я перешел на порт 23, от этого вдруг сломался SSH? Нет. Бог убил котенка? Нет. К чему все твои стенания по поводу портов?
Понимаешь, ты — не показатель. Представь, что с те-же проблемы у mail.ru, их постоянно ломают. Не ssh конечно ломают, а smtp — спам рассылать и pop3 — почту утянуть.
И теперь представь что будет, если умный типа тебя там возьмет и поменяет pop3\smtp порты.
Подмена портов работает на малом количестве народа, до 100 человек по моим ощущениям. Им можно сообщить. А когда народа много пользуется сервисом — у тебя просто проблема взлома сменится на проблему "у меня непашет, строчнопочените!!!111"
Здравствуйте, Sheridan, Вы писали:
S> h> И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
S> Тупо: пользователь, который залез в туда браузером — поймет что там творится? Что это не www, а просто служебная инфа, к www отношения не имеющая?
Вариантов масса. Сервис может отдать админку с мордой на Flex'е, может отдать доку с описанием методов сервиса и их параметров, может просто редиректить на правильный эндпоинт. А теперь ты на вопрос (выделил) ответишь?
M>> Ну а теперь не пытаются. Я перешел на порт 23, от этого вдруг сломался SSH? Нет. Бог убил котенка? Нет. К чему все твои стенания по поводу портов?
S>Понимаешь, ты — не показатель. Представь, что с те-же проблемы у mail.ru, их постоянно ломают. Не ssh конечно ломают, а smtp — спам рассылать и pop3 — почту утянуть. S>И теперь представь что будет, если умный типа тебя там возьмет и поменяет pop3\smtp порты.
Гугл поменял. И? Пишется дока для пользователей по настройке мэйл-клиентов. Обрати внимание, что даже на mail.ru указывается, какие порты вписывать. К чему бы это?
S>Подмена портов работает на малом количестве народа, до 100 человек по моим ощущениям. Им можно сообщить. А когда народа много пользуется сервисом — у тебя просто проблема взлома сменится на проблему "у меня непашет, строчнопочените!!!111"
А я, что-то говорил против этого? Шеридан, включаешь млзг, раскрываешь глаза и начинаешь читать то, что тебе пишут. И, желательно, прилашаешь хотя бы минимальные усилия к тому, чтобы понять, что тебе пишут.
Здравствуйте, Sheridan, Вы писали:
S> h> Вот видишь, по сути ты ничего не можешь возразить, а еще пальцы стрелять порывался.
S> Между прочим я до сих пор придерживаюсь политике отстреливания пальцев. Мне просто надоел этот никчемный спор. Вы не хотите ничего понимать и просто идете по легчайшему пути.
Чудно. Ни одного внятного аргумента, но при этом полная убежденность в собственной правоте. Это прекрасно тебя характеризует.
Все глупцы упрямы, и все упрямцы глупы
Б. Грасиан
Упрямство — это исчадие скудоумия, невежества и самонадеяности
Ф. Ларошфуко
Упрямство и неистовство мнения — самые верные доказательства глупости
Здравствуйте, Sheridan, Вы писали:
S> Перцы, вы какбы начинаете из пушки по воробьям. Я всего лишь пытаюсь вам доказать то, что какбы незря придумали порты. Какбы пытаюсь вам рассказать, что надо бы всетаки сервисы разносить по портам. Ибо, как минимум, когда сообщество принимает что порт xxx числится за таким-то сервисом — это говорит о его зрелости. S> А вы как дети малые...
Когда пытаются доказать, приводят аргументы, а не свое вИдение в качестве оных.
Здравствуйте, Sheridan, Вы писали:
S> h> Когда пытаются доказать, приводят аргументы, а не свое вИдение в качестве оных.
S> Вот тебе аргументы: наличие файла /etc/services в дистрибутивах линуха S> Будешь оспаривать?
Это не аргументы. Наличие данного файла не отвечает на поставленный мною вопрос:
Какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
E>> g>> Есть хоть одна адекватная контора, где перекрыт весь www трафик? E>> S>Пенсионный фонд, равно как и все государственные организации. E>> Взаимоисключающие параграфы.
S>В лужу п..л, или я смею ожидать более развернутый ответ?
Скажем так, ни я, ни кто-либо из моих знакомых/сотрудников/прочих собеседников не видел ни разу ни одной адекватной госконторы. Везде одинаково: по куче причин(бюрократия, копеечные зп, имбецильное начальство, непрофессионализм — да тысячи их, все долго перечислять) эффективность выполняемой работы не то что болтается в конце приоритетов, а вообще отсутствует в этом списке. Все делается "на отъ#бись". Об адекватности в таких условиях даже говорить не приходится.
Я говорю, понятное дело, про госконторы в пост-ссср. Если ты знаешь обратные примеры, приведи их, пожалуйста.
ЗЫ решение "закрыть нахер все порты, в том числе и www" — это как раз то самое "сделать на отъ#бись".
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Mamut, Вы писали: M>И таких примеров можно накопать десятки. Это плохо? Нет. Никто не гарантирует, что на 80-м порту будет www. А софт, который с такими сервисами работает, знает, какие данные оттуда получать. И получает дополнительные плюшки, связанные с HTTP-протоколом нашару.
Ну зачем вы это делаете?
Человек уже трижды на вопрос "какие стандарты нарушаются" отвечает чушью типа "авотпользователь". Это явно показывает ортогональность его мышления плоскости ваших вопросов.
Вы же видите — для него 80 == "www". Что такое "www" мы всё равно никогда не узнаем — потому что неспособность данного персонажа работать с определениями нам известна уже лет пять тому. Это всё из той же области, что и "сетевые приложения".
А потому и заморачиваться не стоит. Всё равно мы бы не смогли задокументировать никакой стандарт "совместимый с Шериданом", тем более следовать такому стандарту.
Благо, весь остальной мир благополучно существует без Шеридана и без его наркоманских мировоззрений. Где наличие etc/services приравнивается к Слову Божьему, при том, что это — всего лишь вспомогательный файл, который нужен только для упрощённого запуска telnet не по номеру порта, а по имени протокола. (Этак я возьму дефолтный список букмарков IE и объявлю его Каноническим Списком Сайтов) Где нет никакого понимания, зачем вообще введена концепция портов в протоколах TCP и UDP, и для чего IANA их распределяет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sheridan, Вы писали:
S> h> Что значит "там не WWW"? А что там должно быть, чтоб было "там WWW"? (маразм крепчал).
S> Подумай внимательно. Сам. Но чтото мне говорит — думать ты не будешь.
Я, конечно, могу подумать, что у тебя в голове творится, и на основе это попытаться сделать вывод, но думается мне это не станет ответом на мой вопрос. Мне стоит надеяться на внятное определение WWW, или ты, как всегда, будешь гнать пургу о своем вИдении?
E>> Нене, я просил не это. Я имел ввиду пример ситуации, когда требуется техническое и только техническое решение, и другого способа нет. Причем желательно в адекватной конторе, где начальство не кретинические имбецилы с комплексом власти.
S>Например закрыть smtp наружу, чтобы из организации не шел спам (на случай если антивирь пропустит нового трояна). Почту же пустить через корпоративный postfix, на котором поднять антиспам и обязательную авторизацию. S>Ты эту проблему решишь административно?
А проблема-то чисто техническая. Спам — это не внутренняя проблема, как, например, какой-то используемый компанией сервис, который ходит через какие-то там порты. Техническая проблема тех средствами и должна решаться.
ЗЫ Я о проблеме спама забыл давно, с того времени, как перешел на гмыло. Вообще, почта через smtp — каменный век, веб-доступ рулит безбожно. И пусть о проблеме спама у гугла голова болит, у него средств борьбы с ним в разы больше. Кстати, это уже тенденция(собственные почтовики потихоньку отмирают). У нас почтовый сервер есть, но его используют в основном для внутренних целей, как то эхо багтрекера. Для других целей в разы удобнее веб вариант.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
S>> h> Что значит "там не WWW"? А что там должно быть, чтоб было "там WWW"? (маразм крепчал).
S>> Подумай внимательно. Сам. Но чтото мне говорит — думать ты не будешь.
H>Я, конечно, могу подумать, что у тебя в голове творится, и на основе это попытаться сделать вывод, но думается мне это не станет ответом на мой вопрос. Мне стоит надеяться на внятное определение WWW, или ты, как всегда, будешь гнать пургу о своем вИдении?
E__>>>Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
M>>В приложении открывается моментально, потому что оно уже закачано на диск
E__>Я имею ввиду то, тот же ворд грузится секунд пять, а дока скачивается за 2-3.
И потом ворд все равно открывается еще 5 секунд Не говоря уже о том, что может вмешаться, например, антивирус. Или обрыв связи
E__>Смысл в том, что разицы при хорошем инете между диском и вебом почти нет(и вообще, заливая кому-то что-то на флешку с инета, понимаешь, что скорость ограничена флешкой, а не соединением...).
А при чем тут флешка? Разница с инетом пока еще ощутима.
E__>>>При этом никто не мешает прикрутить оффлайн клиент к тому же гмылу там, где он им пользуется чаще всего, и пользоваться вебом из других мест.
M>>Для этого надо настраивать одинаковые правила (более 200 у того человека) что в аутлуке, что в гмыле, а это практически нереально
E__>Ну, тут может быть. Если человек настолько хардкорно пользуется почтой, то да. У меня правил вообще 0. Зато критична безгеморройная доступность с любого устройства с выходом в сеть.
Это есть такое. Для себя я нашел ответ в IMAP, но у меня правил что-то около 10-и и не надо синхронизировать такие вещи, как метки/флаги сообщений.
Приветствую, Eugeny__, вы писали:
E> Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
Понимаешь, быстрый инет чуть менее чем полностью сосредоточен в пределах мкада. Я например за мегабит плачу 1к рублей. В соседнем городе есть 10 мегабит, но он только по оптике (прикиньте стоимость подключения), и стоит 2400 рублей.
Здравствуйте, Sheridan, Вы писали:
HB>> S>Что будет, если мы решим на этом порту поднять например nntp?
HB>> Там будут группы новостей и не будет DNS сервера. Ваш КО.
S>Спасибо, К.О.
Я имел в виду, что никаких негативных последствий не будет — если, конечно, мы не будем указывать адрес этого компьютера в качестве DNS сервера.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Там вообще-то английским по белому написано, для чего нужна регистрация портов.
Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port.
Перевожу: "для того, чтобы неизвестные (в том смысле, что он не может заранее сообщить им номер порта) серверу клиенты знали, на каком порту искать тот или иной сервис". Всё. Не для удобства админов. Не для того, "чтобы было правильно". Только для того, чтобы почтовый сервер отправителя знал, что почтовый сервер получателя ждёт писем на 25-м порту.
Если мы не ожидаем "unknown callers" (как Мамут с его ssh), мы спокойно можем поменять номер порта.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
h>> Пацталом.
S>Так вылазь и поправь меня. Потому как я вижу, что браузер встраивает в себя акробат, если открывается pdf или там oowriter, если открывается docx
Но при этом по www отсылаются абсолютно «левые» (по твоему определению) данные: файлы разных форматов, аудио, видео. И тебя это не смущает почему-то
Здравствуйте, Sheridan, Вы писали:
S> h> Пацталом.
S> Так вылазь и поправь меня. Потому как я вижу, что браузер встраивает в себя акробат, если открывается pdf или там oowriter, если открывается docx
Поправлять тебя? Да тут все только этим и занимаются. А мне уже надоело с ветряком воевать
. Ты все больше подтверждаешь мою убежденность, что ты споришь ради спора.
Не то, чтобы я был большим знатоком, по-моему автору того поста изначально нужно было делать обмен данными по хорошо изученному HTTP, а не изобретать проблемы себе на голову.
Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос.
Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт или знание их физического устройства и реализации на текущей платформе, и умения применять при написание софта? Проще говоря, подразумевает ли это знание реализации устройства сетевого стека в ядре?
Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Здравствуйте, legogogo, Вы писали:
L>Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. L>Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт или знание их физического устройства и реализации на текущей платформе, и умения применять при написание софта? Проще говоря, подразумевает ли это знание реализации устройства сетевого стека в ядре?
Чаще всего это означает что надо знать возможности принципы работы протоколов, а также прикладную библиотеку в требуемом языке для работы с этими протоколами.
Хотя почему тема в КСВ? Где наброс?
Или специально сделано чтобы Sheridan ответил?
Здравствуйте, Smooky, Вы писали:
S>Ну к нам в контору вообще нельзя попасть, незная общеканальную сигнализацию (ОКС№7), и знания межстанционных протоколов начиная от LapB (ходит под TCP) и до TCAP/RANAP/BSSAP/... и заканчивая протоколами прикладного уровня HTTP/FTP/...(хотя в принципе они нафиг не нужны, так, для общего развития). S>Ну и по крайней мере хотя бы быть знакомым с рекомендациями Motorola (Q.XXX).
Это для программиста требование?
Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы (c) Алан Кокс
Здравствуйте, neFormal, Вы писали:
M>>Это у тебя какие-то сексуальные фантазии на тему такого народа
F>это он просто не знает, как прикрыть этот траффик :3 F>сейчас часто http используется в качестве транспорта для своего протокола.. так работают многие онлайн-игры (в основном соц-казуалки)..
HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно.
Одна из причин — он хорошо проходит через файрволы, не требуя дополнительной конфигурации. Просто работает. И все.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Извини, но то, что оно хорошо проходит через файрволы и при этом просто работает — это твоя, как админа проблема, а не разработчиков. Не надо с больной головы на здоровую проблемы эксплуатации перекладывать.
Я вот понять не могу, в чем его проблема-то? В том, что работает? Типа — не порядок, не должно? Может быть, в том, что благодаря REST-семантике, кешируются ответы на корпоративной проксе, уменьшая внешний трафик? Или в том, что работает вопреки его усилиям, а не благодаря?
KV>>Извини, но то, что оно хорошо проходит через файрволы и при этом просто работает — это твоя, как админа проблема, а не разработчиков. Не надо с больной головы на здоровую проблемы эксплуатации перекладывать.
G>Я вот понять не могу, в чем его проблема-то? В том, что работает? Типа — не порядок, не должно? Может быть, в том, что благодаря REST-семантике, кешируются ответы на корпоративной проксе, уменьшая внешний трафик? Или в том, что работает вопреки его усилиям, а не благодаря?
У Шеридана есь манечка — сокеты. Каждое, абсолютно каждое, приложение, которое ломится в сеть, должно работать только одном, строго определенном и желательно зарегистрированном в IANA. Иначе — отрубать пальцы. Несмотря на то, что это — всего лишь данные, ну и дальше по тексту
Здравствуйте, Mamut, Вы писали:
M>Я вот перевел себе ssh с 22-го порта на 23-й, исчезло много левого трафика на сайт. Пойду резать себе пальцы по методу Шеридана.
Не надо. Давай лучше Шеридану отрежем. Печатать медленнее будет. ?!! PROFIT!
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>Извини, но то, что оно хорошо проходит через файрволы и при этом просто работает — это твоя, как админа проблема, а не разработчиков. Не надо с больной головы на здоровую проблемы эксплуатации перекладывать.
G>Я вот понять не могу, в чем его проблема-то? В том, что работает? Типа — не порядок, не должно? Может быть, в том, что благодаря REST-семантике, кешируются ответы на корпоративной проксе, уменьшая внешний трафик? Или в том, что работает вопреки его усилиям, а не благодаря?
А назло работающий (еще и через файрволы, а что еще важнее, через всяческие NAT'ы) HTTP, дискредитирует здесь точку зрения Шеридана, что нет ничего более разумного, нежели разрабатывать на каждый чих свой собственный протокол с хэндшейком и куками, исключительно ради некоей оптимизации трафика, быстродействия и чего-то там еще.
Здравствуйте, Mamut, Вы писали:
S>>Да просто для того, чтобы имели представление о том как все работает, и использовали бы свои знания, создавая соответствующий ситуации протокол. А то развелось, блин, народа, которые к месту и не к месту лепят обмен данными через http.
M>Это у тебя какие-то сексуальные фантазии на тему такого народа
Ну это ты зря. До сих пор помню, как Синклер мне рекомендовал HTTP, абсолютно ничего не зная о моей задаче
Здравствуйте, Vamp, Вы писали:
L>>Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт V>Да. Это значит умение сочинять TCP/IP приложения, используя существующий стек. Если требуется умение сочинить стек самому, то пишут что-то вроде "навыков реализации TCP/IP стека". Ну, в идеальном мире, конечно. В реальном мире это может означать умение пользоваться интернет эксплорером
Что-то песня вспоминается про девушку, о которой вначале говорится, что она знает в совершенстве английский и иврит, а в конце выясняется. что в совершенстве она знает только английский алфавит
Приветствую, Mamut, вы писали:
M> Я вот перевел себе ssh с 22-го порта на 23-й, исчезло много левого трафика на сайт. Пойду резать себе пальцы по методу Шеридана.
А я каждый час сканирую логи и дропаю на неделю файрволом зарвавшихся личностей.
Твой подход лишь отметает роботов, которые не знают про nmap и тупо долбятся по известным портам
Приветствую, Gaperton, вы писали:
G> S>А вот админам свинью подкладываете, да. G> Это вы, админы, нам регулярно свиней подкладываете.
С каимито неправильными админами ты работал. С малолетками небось, возомнившими себя богами? Таких да, надо учить.
G> S>Не жалуйтесь потом что админы вас не уважают. G> А мы и не жалуемся. Просто используем HTTP, и все.
А по нормальному надо бы прийти к томуже админу и посоветоваться.
G> S>Вот за это надо отстреливать конечности по частям, с неделей таймаута между выстрелами. G> Ну разумется. Только дай вам, админам, волю — и все будет для окружающих максимально через жопу, зато — удобно вам. Вы ж такие. G> Только не дают. Ибо админы — обслуживающий персонал, и вокруг них мир не вертится.
Стопудово работал ты только с малолетними админами. Ну или с такими, которым на своих пользователей насрать.
Приветствую, Mamut, вы писали:
M> Шеридан, завязывай с оскорблениями. Система, построенная поверх HTTP или поверх него же с использованием REST-подходов может быть на несколько порядков сложнее всего, что ты когда-либо сделал в жизни.
И что? Это должно означать чтобы я молчал в тряпочку?
А когда я увижу судью, избивающего моего друга, мне тоже развернуться и уйти, так как судья о законах думает больше меня?
M> Думать не надо, ага. Ты бы хоть раз в жизни подумал, ага.
Думать как раз таки надо Мамут. И не только в сторону "а хрен с ним, прикрутим http"
Приветствую, kochetkov.vladimir, вы писали:
k> А назло работающий (еще и через файрволы, а что еще важнее, через всяческие NAT'ы) HTTP, дискредитирует здесь точку зрения Шеридана, что нет ничего более разумного, нежели разрабатывать на каждый чих свой собственный протокол с хэндшейком и куками, исключительно ради некоей оптимизации трафика, быстродействия и чего-то там еще.
Именно. Я конечно понимаю что всем лениво, но настаиваю и буду настаивать на этом. В крайнем случае, хрен с вами, пользуйте http, но, тля, уйдите с 80 порта!
L>Часто встречается в вакансиях требование знания сетевых протоколов, отсюда вопрос. L>Что значит знание сетевых протоколов (например HTTP, SMTP, DNS, FTP, SOCKS4/5)? Знание их API на текущей платформе и имение писать софт или знание их физического устройства и реализации на текущей платформе, и умения применять при написание софта? Проще говоря, подразумевает ли это знание реализации устройства сетевого стека в ядре?
Знание протоколов в моем понимании означает умение программера реализовать клиента/сервера указанных протоколов на каком либо апи, предоставляющем интерфейс к tcp/ip. К примеру на берклиевских сокетах
Как дополнительно — знание текстовых протоколов, таких как HTTP, SMTP, FTP — означае, что человек, будучи посаженным за консоль telnet'а, сможет ручками загрузить страничку сайта, отправить письмо, скачать файл с фтп сервера соответственно.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Sheridan, Вы писали:
M>> Думать не надо, ага. Ты бы хоть раз в жизни подумал, ага. S>Думать как раз таки надо Мамут. И не только в сторону "а хрен с ним, прикрутим http"
А как? Возьмем голый TCP и/или UDP и сделаем на нем свой прикладной протокол? Или возьмем IP и навесим на него свой транспорт? Или выбросим на фиг Ethernet и свои сети создадим?
Приветствую, Privalov, вы писали:
P> А как? Возьмем голый TCP и/или UDP и сделаем на нем свой прикладной протокол? Или возьмем IP и навесим на него свой транспорт? Или выбросим на фиг Ethernet и свои сети создадим?
Здравствуйте, Sheridan, Вы писали:
G>> Щаз. Не дождешься.
S>Мда... Казалось бы, чего сложного реализовать свой протокол?
Не сложно. Но будет еще хуже, чем переползти на другой порт. Его в принципе не будут кэшировать стандартные прокси, для него всем надо будет также специально открывать порты, к ним вообще невозможно будет доступаться из веб-браузеров (т.е. не только оффлайн приложения отвалятся). И — радикально усложнится задача использования сервиса сторонними разработчиками.
Я тебе картинку "тимуровцы добывают кумыс" показывал?
Приветствую, Gaperton, вы писали:
G> Здравствуйте, Sheridan, Вы писали:
G> G>> Щаз. Не дождешься.
G> S>Мда... Казалось бы, чего сложного реализовать свой протокол?
G> Его в принципе не будут кэшировать стандартные прокси,
Почему ты считаешь, что твои данные кешируются?
Если ты отправляешь каждый раз одни и теже данные, то нафига их вообще отправлять? Можно просто отправиить флаг "данные не изменились" — и пользовательские деньги сбережешь (многие через hdspa сидят, а оно нынче дорогое), и будет впечатление у пользователя что софтина быстрее работает.
Напротив, если ты каждый раз отправляешь новые данные, то что будет кешировать прокси?
G> для него всем надо будет также специально открывать порты,
Да уж лучше я порт специально открою. К томуже юзерские файрволы довольно удобные в этом отношени. Всплывают красивые окошечки с описанием какая софтина куда хочет пойти...
Да какбы при разработке тцп\ип и предполагалось, что различный софт будет пользовать различные порты, не?
G>к ним вообще невозможно будет доступаться из веб-браузеров (т.е. не только оффлайн приложения отвалятся).
Назачем доступ к данным из веб-браузера? Для тестов? А чем телнет не подходит? Сложно, чтоли? Или "консоль ненавистная"? Ну так скачай какой-ть superIPUtilities с телнетом в окошках...
G>И — радикально усложнится задача использования сервиса сторонними разработчиками.
ггг, ну это вообще смешно. Я nmea с обычного gpsd разбирал, читая ман и рядом в сеансе телнета тутже эксперементируя.
G> Я тебе картинку "тимуровцы добывают кумыс" показывал?
Вот уж воистину тимуровцы, ага.
Здравствуйте, Sheridan, Вы писали:
S>Так ты про веб — приложения? Нет, тут веб-приложения не обсуждаются. Ясен фиг, что оно только по хттп нормально работать и будет.
Нет-нет. Я про все приложения.
Если я делаю сервис — я не вижу ни единой причины закрывать к нему доступ из AJAX веб-приложений. Это во-первых.
И даже если таковые не планируются, и не будут основными клиентами — преимущества архитектуры Representational State Transfer, которые я получу, полагаясь на RESTful HTTP интерфейс, будут отнюдь не лишними.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Gaperton, вы писали:
G>> И все они работают поверх HTTP. Понятно, что там предполагалось инженерами Internet Engineering Task Force, нет?
S>Это что, руководство к действию? Требование все писать также, забыть про все остальное и пользовать только http?
Приветствую, Gaperton, вы писали:
G> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm G> Читай. Потом возвращайся спорить.
Нафига мне эту рекламу реста читать? Ясен пень что там будет написано о том, насколько он крутой и как хорошо с ним работать. Будут описаны преимущества реста перед остальными технологиями. Но нигде не будет упоминаний в каких случаях рест лучше не использовать, в каих случаях надо использовать ту или иную технологию.
Это же диссертация о рест, а не о разработке сетевых приложений, не так ли?
Здравствуйте, Sheridan, Вы писали:
S> Тебе же советую почитать это
А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
Приветствую, hattab, вы писали:
h> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
Здравствуйте, Gaperton, Вы писали:
G> G>> XML RPC — спецификация IETF: http://www.ietf.org/rfc/rfc3529.txt
G> H>Это XML-RPC in BEEP
G> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
Мне XML-RPC нравится сильно больше У JSON-RPC вообще спека мутная до ужаса, версий куча, идентификаторы запросов-ответов... Брррр. Оверхед лечится gzip'ом, который и для первых двух лишним не бывает.
Здравствуйте, hattab, Вы писали:
G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
H>Мне XML-RPC нравится сильно больше У JSON-RPC вообще спека мутная до ужаса, версий куча, идентификаторы запросов-ответов... Брррр. Оверхед лечится gzip'ом, который и для первых двух лишним не бывает.
С gzip-ом ты уже на гигабитной сетке упрешься в процессор. Вообще — у XML и без gzip довольно неприятный оверхэд на парсинг.
Мне вообще RPC не нравится, раз уж на то пошло. REST с JSON-данными. И все. Та же хрень, только в профиль, имеет наименьший оверхэд, и поддерживает семантику кеширования HTTP.
Здравствуйте, Sheridan, Вы писали:
S> h> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S> Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
Не пользуюсь Скайпом. Если я правильно понимаю, Скайп может использовать HTTP-прокси для создания туннеля. В этом случае все законно, спека HTTP это разрешает.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, hattab, вы писали:
h>> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S>Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
Скайп его использует не всегда, а тока в крайнем случае, когда не может нормальным способом пролезть через настроенный криворукими админами прокси. Ты знал, нет?
Не от хорошей жизни он использует, а для борьбы с вами, админами. Ибо — когда гонишь голос через HTTP имеешь нихреновый jitter, и никто, имея выбор из других вариантов, так поступать не будет. Для телефонии предназначены SIP и RTP поверх UDP. Хотя конкретно Скайп ими и не пользуется — у него проприетарные протоколы.
Здравствуйте, Gaperton, Вы писали:
G> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
G> H>Мне XML-RPC нравится сильно больше У JSON-RPC вообще спека мутная до ужаса, версий куча, идентификаторы запросов-ответов... Брррр. Оверхед лечится gzip'ом, который и для первых двух лишним не бывает.
G> С gzip-ом ты уже на гигабитной сетке упрешься в процессор. Вообще — у XML и без gzip довольно неприятный оверхэд на парсинг.
Парсинг XML (при использовании SAX) мало чем отличается от парсинга JSON
G> Мне вообще RPC не нравится, раз уж на то пошло. REST с JSON-данными. И все. Та же хрень, только в профиль, имеет наименьший оверхэд, и поддерживает семантику кеширования HTTP.
Приветствую, Gaperton, вы писали:
G> Скайп его использует не всегда, а тока в крайнем случае, когда не может нормальным способом пролезть через настроенный криворукими админами прокси. Ты знал, нет?
G> Не от хорошей жизни он использует, а для борьбы с вами, админами. Ибо — когда гонишь голос через HTTP имеешь нихреновый jitter, и никто, имея выбор из других вариантов, так поступать не будет. Для телефонии предназначены SIP и RTP поверх UDP. Хотя конкретно Скайп ими и не пользуется — у него проприетарные протоколы.
Что, правда, чтоле?
А мужики то не знают, надо же
А вот бороться с нами не надо. С нами надо общаться. А то бывает смотришь — человек тунель роет, кнему подойдешь этак — спрашиваешь , мол "зачем, мил человек, тунель сквозь icmp копаешь?" — а он — "а вы сволочи все прикрыли доступ к жабберу". И ведь не подойдет никто, не попросит чтототам открыть, все копать начинают. А казалось бы — чего стоит то попросить? Откроют конечно, если сие не противоречит политикам организации (типа запрета чатицца в рабочее время). Думаете от хорошей жизни приходится на сплошном -j DROP сидеть и даже себе открывать порты по необходимости?
Так что не стесняйтесь, ходите и просите. Если отказывается — то спросите причину отказа. Если чтото типа "так надо" — то вперед к начальству, ибо у вас возомнивший себя богом админ засел, а таких надо обучать, и обучать жестоко.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Gaperton, Вы писали:
G>> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
G>> H>Мне XML-RPC нравится сильно больше У JSON-RPC вообще спека мутная до ужаса, версий куча, идентификаторы запросов-ответов... Брррр. Оверхед лечится gzip'ом, который и для первых двух лишним не бывает.
G>> С gzip-ом ты уже на гигабитной сетке упрешься в процессор. Вообще — у XML и без gzip довольно неприятный оверхэд на парсинг.
H>Парсинг XML (при использовании SAX) мало чем отличается от парсинга JSON
Тебе надо матчить именованные парные теги. А не тупо искать односимвольные лексемы в тупой скобочной грамматике. Разница, однако.
G>> Мне вообще RPC не нравится, раз уж на то пошло. REST с JSON-данными. И все. Та же хрень, только в профиль, имеет наименьший оверхэд, и поддерживает семантику кеширования HTTP.
H>А мне RPC ближе
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Gaperton, Вы писали:
G>> G>> С gzip-ом ты уже на гигабитной сетке упрешься в процессор. Вообще — у XML и без gzip довольно неприятный оверхэд на парсинг.
G>> H>Парсинг XML (при использовании SAX) мало чем отличается от парсинга JSON
G>> Тебе надо матчить именованные парные теги. А не тупо искать односимвольные лексемы в тупой скобочной грамматике. Разница, однако.
H>Разница конечно есть, но она не столь велика на самом деле. SAX он вообще матчингом не занимается, это делается в момент построения объектной модели и решается одним условным оператором.
Возможно. Честно говоря, я не мерял и тестов не видел.
H>Кстати, я тут попробовал gzip погонять: на 3.3Ghz Феноме, однопоточное сжатие дает ~80Mb/sec, т.е. пара ядер, из четырех имеющихся, легко справятся с гигабитной сеткой (130Mb/sec вроде).
Справится. Только ты при этом на потоке легких запросов серьезно просадишь производительность сервера. Учти, кстати, что исходящий XML также надо жать .
А у меня при использовании REST легкие запросы закэшируются на reverse proxy :P.
Здравствуйте, Gaperton, Вы писали:
G> H>Кстати, я тут попробовал gzip погонять: на 3.3Ghz Феноме, однопоточное сжатие дает ~80Mb/sec, т.е. пара ядер, из четырех имеющихся, легко справятся с гигабитной сеткой (130Mb/sec вроде).
G> Справится. Только ты при этом на потоке легких запросов серьезно просадишь производительность сервера. Учти, кстати, что исходящий XML также надо жать .
Пусть сервер работает, чего ему простаивать
G> А у меня при использовании REST легкие запросы закэшируются на reverse proxy :P.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Gaperton, Вы писали:
G>> H>Кстати, я тут попробовал gzip погонять: на 3.3Ghz Феноме, однопоточное сжатие дает ~80Mb/sec, т.е. пара ядер, из четырех имеющихся, легко справятся с гигабитной сеткой (130Mb/sec вроде).
G>> Справится. Только ты при этом на потоке легких запросов серьезно просадишь производительность сервера. Учти, кстати, что исходящий XML также надо жать .
H>Пусть сервер работает, чего ему простаивать
Энергию жрет зазря. Способствуя глобальному потеплению. Нефига.
G>> А у меня при использовании REST легкие запросы закэшируются на reverse proxy :P.
H>Дополнительное железо.
Nginx на фронте по любому не повредит, чтобы нагрузку на кластер балансировать, и даже без кластера кешировать статику, разгрузив web application server от всякой хрени.
Здравствуйте, Gaperton, Вы писали:
G> G>> H>Кстати, я тут попробовал gzip погонять: на 3.3Ghz Феноме, однопоточное сжатие дает ~80Mb/sec, т.е. пара ядер, из четырех имеющихся, легко справятся с гигабитной сеткой (130Mb/sec вроде).
G> G>> Справится. Только ты при этом на потоке легких запросов серьезно просадишь производительность сервера. Учти, кстати, что исходящий XML также надо жать .
G> H>Пусть сервер работает, чего ему простаивать
G> Энергию жрет зазря. Способствуя глобальному потеплению. Нефига.
Разгрузи сервер — спаси льдинку
G> G>> А у меня при использовании REST легкие запросы закэшируются на reverse proxy :P.
G> H>Дополнительное железо.
G> Nginx на фронте по любому не повредит, чтобы нагрузку на кластер балансировать, и даже без кластера кешировать статику, разгрузив web application server от всякой хрени.
Балансер не нужен, мы за умные ноды HTML-статика не нужна, мы за rich UI (flash forever )
Здравствуйте, Sheridan, Вы писали:
G>>к ним вообще невозможно будет доступаться из веб-браузеров (т.е. не только оффлайн приложения отвалятся). S>Назачем доступ к данным из веб-браузера?
Именно . Когда приложение работает на ферме — это еще и заметно дешевле получается.
G>> H>Дополнительное железо.
G>> Nginx на фронте по любому не повредит, чтобы нагрузку на кластер балансировать, и даже без кластера кешировать статику, разгрузив web application server от всякой хрени.
H>Балансер не нужен, мы за умные ноды HTML-статика не нужна, мы за rich UI (flash forever )
Балансер все равно не повредит, даже для умных нодов. Уменьшит количество балансировочных редиректов. При желании, можно организовать кэширование динамики. И конечно, Flash must die, HTML5 forever!
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Gaperton, вы писали:
G>> S>Что, правда, чтоле?
G>> Правда.
S>Ды тействительно поверил, что я этого не знаю?
Здравствуйте, Gaperton, Вы писали:
G>>> Правда.
S>>Ды тействительно поверил, что я этого не знаю?
G>Еще и других учить пытаешься. Таким образом, по классификации Омара Хайяма — ты относишься к типу "не знает, и не знает, что он не знает", т.е. дурак, общения с которым следует избегать.
Ничего личного, кстати. Я не испытываю никакой радости от того, что ты позоришься на всю сеть, trust me. Ибо ты делаешь это грустно и уныло. Я даже тебе материалы для самообразования привел.
Здравствуйте, Gaperton, Вы писали:
G> G>> XML RPC — спецификация IETF: http://www.ietf.org/rfc/rfc3529.txt
G> H>Это XML-RPC in BEEP
G> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
Здравствуйте, Gaperton, Вы писали:
G> G>> Энергию жрет зазря. Способствуя глобальному потеплению. Нефига.
G> H>Разгрузи сервер — спаси льдинку
G> Именно . Когда приложение работает на ферме — это еще и заметно дешевле получается.
Ну так простои сервера будут компенсироваться нагрузкой на прокси, разницы никакой в принципе, просто нагрузка переедет с одного узла на другой.
G> G>> H>Дополнительное железо.
G> G>> Nginx на фронте по любому не повредит, чтобы нагрузку на кластер балансировать, и даже без кластера кешировать статику, разгрузив web application server от всякой хрени.
G> H>Балансер не нужен, мы за умные ноды HTML-статика не нужна, мы за rich UI (flash forever )
G> Балансер все равно не повредит, даже для умных нодов. Уменьшит количество балансировочных редиректов. При желании, можно организовать кэширование динамики. И конечно, Flash must die, HTML5 forever!
Количество редиректов уменьшит вряд ли, т.к. у него будет не больше информации о наргрузке, чем у нодов. Все виденные мною HTML интерфейсы вчистую сливают Flex'у.
Здравствуйте, hattab, Вы писали:
G>> Именно . Когда приложение работает на ферме — это еще и заметно дешевле получается.
H>Ну так простои сервера будут компенсироваться нагрузкой на прокси, разницы никакой в принципе, просто нагрузка переедет с одного узла на другой.
Прокси тупее, и тратит меньше тактов и энергии, чтобы достать нечто из кэша. Она тупо матчит адрес ресурса, ей XML для этого парсить и выполнять твой код не надо.
G>> H>Балансер не нужен, мы за умные ноды HTML-статика не нужна, мы за rich UI (flash forever )
G>> Балансер все равно не повредит, даже для умных нодов. Уменьшит количество балансировочных редиректов. При желании, можно организовать кэширование динамики. И конечно, Flash must die, HTML5 forever!
H>Количество редиректов уменьшит вряд ли, т.к. у него будет не больше информации о наргрузке, чем у нодов.
Уменьшит, даже если ты случайно по серверам входящие запросы разбросаешь. Отлуп редиректом будет редкий. Без прокси — наоборот, будет штатной ситуацией.
H>Все виденные мною HTML интерфейсы вчистую сливают Flex'у.
В пятом HTML есть Canvas, OpenGL, и прочее. Посмотри демки. Кроме того — не составляет труда и на современном HTML не сильно слить Flex-y, ибо на нем отлично делаются AJAX и оффлайновые (с gears) приложения, есть анимация, и интерпретаторы JavaScript стали весьма и весьма шустры. Практическая разница будет незначительна.
Здравствуйте, Eugeny__, Вы писали:
KV>>Иными словами, до тех пор, пока будут применяться технические запреты, сотрудники будут искать способы их обходить. Но ровно до того момента, пока к ним не будут применены административные меры.
E__>Вот, хоть кто-то умную мысль сказал. Никакие административные проблемы техническими решениями нормально и эффективно решены быть не могут.
Просто у меня большой опыт общения на эту тему с руководителями различных уровней, которые считают иначе
h>> А что там читать-то (я читал)? Как программить сокеты под Юниксом? Так на вопросы о практической применимости протоколов эта книга ответов не дает. Ты лучше подумай, почему куча софта, линуксячьего в том числе, использует для управления JSON-RPC и XML-RPC, а не собственные велосипеды.
S>Ты еще не понял, что я по большому счету не против использования протокола http, а против использования 80 порта для левых данных? Ну типа как скайп использует.
Что такое левые данные относительно порта 80?
Что такое левые данные относительно какого-либо порта вообще?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Gaperton, Вы писали:
G>> G>> XML RPC — спецификация IETF: http://www.ietf.org/rfc/rfc3529.txt
G>> H>Это XML-RPC in BEEP
G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
Unicode это чаще всего UTF-8, где 80% текста латиница и числа — однобайтовые.
Сравни
<element>Мама мыла раму</element>
и
{element:"Мама мыла раму"}
Поэтому средний оверхед UTF-8 JSON_а против Win1251 xml_я будет меньше 20 процентов за счет минимального синтаксиса jsona.
Только с случаях передачи больших объемов текста будет, но текст можно просто пихать в ответ, без оборачивания в формат. Также стоит поступать и с бинарными данными.
Здравствуйте, Gaperton, Вы писали:
G> G>> Именно . Когда приложение работает на ферме — это еще и заметно дешевле получается.
G> H>Ну так простои сервера будут компенсироваться нагрузкой на прокси, разницы никакой в принципе, просто нагрузка переедет с одного узла на другой.
G> Прокси тупее, и тратит меньше тактов и энергии, чтобы достать нечто из кэша. Она тупо матчит адрес ресурса, ей XML для этого парсить и выполнять твой код не надо.
Если мы говорим о легких запросах, то там парсинг XML растворится на фоне других операций. В любом случае, разница вряд ли будет существенной
G> G>> H>Балансер не нужен, мы за умные ноды HTML-статика не нужна, мы за rich UI (flash forever )
G> G>> Балансер все равно не повредит, даже для умных нодов. Уменьшит количество балансировочных редиректов. При желании, можно организовать кэширование динамики. И конечно, Flash must die, HTML5 forever!
G> H>Количество редиректов уменьшит вряд ли, т.к. у него будет не больше информации о наргрузке, чем у нодов.
G> Уменьшит, даже если ты случайно по серверам входящие запросы разбросаешь. Отлуп редиректом будет редкий. Без прокси — наоборот, будет штатной ситуацией.
Я подумал мы уже о чистом балансере. С прокси да, уменьшит. Но опять же вопрос, насколько это будет критично
G> H>Все виденные мною HTML интерфейсы вчистую сливают Flex'у.
G> В пятом HTML есть Canvas, OpenGL, и прочее. Посмотри демки. Кроме того — не составляет труда и на современном HTML не сильно слить Flex-y, ибо на нем отлично делаются AJAX и оффлайновые (с gears) приложения, есть анимация, и интерпретаторы JavaScript стали весьма и весьма шустры. Практическая разница будет незначительна.
В демках HTML5 не видел гуя вроде Flex HTML демки гуев видел, Мамут тут постил неоднократно (попробую ссылку найти) — адъ и Израиль, в Опере 10.60 тормоза чудовищные.
Здравствуйте, Gaperton, Вы писали:
G> G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
G> H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
G> Да ну, брось. Отлично жуется любая кодировка. Никаких фундаментальных причин на то, что должна быть именно юникод — нет. Точно так же, как и для веб-страниц. Может, для JSON-RPC это в стандарте и прописано (что странно, и на что в своем решении ты можешь без особого ущерба подзабить), но в случае с REST меня это точно не волнует.
Из RFC 4627:
A string is a sequence of zero or more Unicode characters
и
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
В RFC ни слова не сказано об использовании не юникод-кодировок.
Кроме того, JSON не имеет мета-информации о кодировке. Если при передаче по HTTP еще можно указать Content-Type с указанием чарсета, то при сохранении в файл декларировать это негде Тут явная нестыковка указывающая на то, что JSON всегда должен быть юникод-кодированным.
Здравствуйте, gandjustas, Вы писали:
g> G>> G>> XML RPC — спецификация IETF: http://www.ietf.org/rfc/rfc3529.txt
g> G>> H>Это XML-RPC in BEEP
g> G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
g> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
g> H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
g> Unicode это чаще всего UTF-8, где 80% текста латиница и числа — однобайтовые.
Ничего, что я русскоязычный форум в пример привел?
g> Сравни
g>
g> <element>Мама мыла раму</element>
g>
g> и
g>
g> {element:"Мама мыла раму"}
g>
g> Поэтому средний оверхед UTF-8 JSON_а против Win1251 xml_я будет меньше 20 процентов за счет минимального синтаксиса jsona.
На подобных примерах возможно, но на реальных данных нет.
g> Только с случаях передачи больших объемов текста будет, но текст можно просто пихать в ответ, без оборачивания в формат. Также стоит поступать и с бинарными данными.
Посмотри на размеры постов на RSDN. Я же реальный пример привел.
Здравствуйте, Eugeny__, Вы писали:
E> H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
E> Однобайтные кодировки должны умереть!! E> Руки бы обрывал за их использование сейчас.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, Gaperton, Вы писали:
G>> G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G>> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
G>> H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
G>> Да ну, брось. Отлично жуется любая кодировка. Никаких фундаментальных причин на то, что должна быть именно юникод — нет. Точно так же, как и для веб-страниц. Может, для JSON-RPC это в стандарте и прописано (что странно, и на что в своем решении ты можешь без особого ущерба подзабить), но в случае с REST меня это точно не волнует.
H>Из RFC 4627: H>
A string is a sequence of zero or more Unicode characters
H>и H>
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
H>В RFC ни слова не сказано об использовании не юникод-кодировок.
H>Кроме того, JSON не имеет мета-информации о кодировке. Если при передаче по HTTP еще можно указать Content-Type с указанием чарсета, то при сохранении в файл декларировать это негде Тут явная нестыковка указывающая на то, что JSON всегда должен быть юникод-кодированным.
SHALL — это не MUST. Соблюдать его не обязательно.
Здравствуйте, hattab, Вы писали:
h> В демках HTML5 не видел гуя вроде Flex HTML демки гуев видел, Мамут тут постил неоднократно (попробую ссылку найти) — адъ и Израиль, в Опере 10.60 тормоза чудовищные.
Здравствуйте, Gaperton, Вы писали:
G> G>> G>> А. Ну да. Впрочем, один хрен этот XML-RPC старье.
G> G>> G>> REST и JSON-RPC гораздо годнее. И оверхед меньше, да и фичи у обоих поприятнее.
G> G>> H>Кстати, я тут еще про оверхед JSON'а вспомнил JSON поддерживает только юникод кодировки, в то время, как XML допускает использование любых, в том числе однобайтовых, кодировок. Например, RSDN — форум с контентом на русском языке. Предположим, стоит задача написать оффлайн-клиента. Символы кириллицы представленные в JSON будут занимать минимум 2 байта, в то время, как в XML при использовании encoding="windows-1251" кириллица будет однобайтовой. Итого, оверхед JSON будет равен 100%.
G> G>> Да ну, брось. Отлично жуется любая кодировка. Никаких фундаментальных причин на то, что должна быть именно юникод — нет. Точно так же, как и для веб-страниц. Может, для JSON-RPC это в стандарте и прописано (что странно, и на что в своем решении ты можешь без особого ущерба подзабить), но в случае с REST меня это точно не волнует.
G> H>Из RFC 4627: G> H>
A string is a sequence of zero or more Unicode characters
G> H>и G> H>
JSON text SHALL be encoded in Unicode. The default encoding is UTF-8.
G> H>В RFC ни слова не сказано об использовании не юникод-кодировок.
G> H>Кроме того, JSON не имеет мета-информации о кодировке. Если при передаче по HTTP еще можно указать Content-Type с указанием чарсета, то при сохранении в файл декларировать это негде Тут явная нестыковка указывающая на то, что JSON всегда должен быть юникод-кодированным.
G> SHALL — это не MUST. Соблюдать его не обязательно.
G> Учимся читать rfc: www.ietf.org/rfc/rfc2119.txt
Учимся следовать своим советам:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.
Здравствуйте, gandjustas, Вы писали:
g> H>Посмотри на размеры постов на RSDN. Я же реальный пример привел.
g> На RSDN встаки unicode, как и на других форумах.
g> Вот тебе доказательство: 證明 הוכחה
Ты меня не понял. Основной контент русскоязычных форумов кириллический.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> H>Посмотри на размеры постов на RSDN. Я же реальный пример привел.
g>> На RSDN встаки unicode, как и на других форумах.
g>> Вот тебе доказательство: 證明 הוכחה
H>Ты меня не понял. Основной контент русскоязычных форумов кириллический.
И что? Это даете тебе право передавать его в однобайтной кодировке?
Все равно будет unicode и xml все равно оказывается в проигрыше, по сравнению с json.
У xml другие положительные качества есть, но оптимальность хранения к ним не относится вообще никак.
Здравствуйте, gandjustas, Вы писали:
g> g>> H>Посмотри на размеры постов на RSDN. Я же реальный пример привел.
g> g>> На RSDN встаки unicode, как и на других форумах.
g> g>> Вот тебе доказательство: 證明 הוכחה
g> H>Ты меня не понял. Основной контент русскоязычных форумов кириллический.
g> И что? Это даете тебе право передавать его в однобайтной кодировке? g> Все равно будет unicode и xml все равно оказывается в проигрыше, по сравнению с json.
Конечно это дает мне возможность передавать данные в однобайтовой кодировке т.к. это просто эффективнее. Основной объем 99.99% русскоязычных форумов это латиница и кириллица. Логично, что выгоднее кодировать (на момент передачи/приема только) эти данные в однобайтовую кодировку т.к. это уменьшает их объем. Юникод-символы непредставимые в 1251 будут эскейпиться согласно спеке XML.
Здравствуйте, hattab, Вы писали:
E>> Однобайтные кодировки должны умереть!! E>> Руки бы обрывал за их использование сейчас.
H>Если грамотно готовить, все нормально.
Пример "грамотной готовки" в студию. Я придумать не могу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, Eugeny__, Вы писали:
E> E>> Однобайтные кодировки должны умереть!! E> E>> Руки бы обрывал за их использование сейчас.
E> H>Если грамотно готовить, все нормально.
E> Пример "грамотной готовки" в студию. Я придумать не могу.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
g>> g>> H>Посмотри на размеры постов на RSDN. Я же реальный пример привел.
g>> g>> На RSDN встаки unicode, как и на других форумах.
g>> g>> Вот тебе доказательство: 證明 הוכחה
g>> H>Ты меня не понял. Основной контент русскоязычных форумов кириллический.
g>> И что? Это даете тебе право передавать его в однобайтной кодировке? g>> Все равно будет unicode и xml все равно оказывается в проигрыше, по сравнению с json.
H>Конечно это дает мне возможность передавать данные в однобайтовой кодировке т.к. это просто эффективнее.Основной объем 99.99% русскоязычных форумов это латиница и кириллица. Логично, что выгоднее кодировать (на момент передачи/приема только) эти данные в однобайтовую кодировку т.к. это уменьшает их объем. Юникод-символы непредставимые в 1251 будут эскейпиться согласно спеке XML.
Интересно, а почему этим никто не занимается?
Здравствуйте, gandjustas, Вы писали:
g> H>Конечно это дает мне возможность передавать данные в однобайтовой кодировке т.к. это просто эффективнее.Основной объем 99.99% русскоязычных форумов это латиница и кириллица. Логично, что выгоднее кодировать (на момент передачи/приема только) эти данные в однобайтовую кодировку т.к. это уменьшает их объем. Юникод-символы непредставимые в 1251 будут эскейпиться согласно спеке XML.
g> Интересно, а почему этим никто не занимается?
Ты говоришь применительно к RSDN, или вообще? Если вообще, то это довольно распространенная практика (и ничего странного в этом нет), а если применительно к RSDN... ну хз, админов спроси
E>> E>> Однобайтные кодировки должны умереть!! E>> E>> Руки бы обрывал за их использование сейчас.
E>> H>Если грамотно готовить, все нормально.
E>> Пример "грамотной готовки" в студию. Я придумать не могу.
H>Я уже ответил
Здравствуйте, Mamut, Вы писали:
M> E>> E>> Однобайтные кодировки должны умереть!! M> E>> E>> Руки бы обрывал за их использование сейчас.
M> E>> H>Если грамотно готовить, все нормально.
M> E>> Пример "грамотной готовки" в студию. Я придумать не могу.
M> H>Я уже ответил
Приветствую, Mamut, вы писали:
M> Не ты первый и не в первый раз. И, опять же не ты последний, и не в последний раз. Шеридан приводимые ему ссылки не чиатет принципиально.
Мамут, с чего ты взял что не читаю? Туже лецию, чтобы понять о чем оно — я читал. Не всю конечно, на всю меня не хватит, так как язык там вражеский.
Мамут, ты похоже чисто по русски делаешь "не запрещено (не рекоммендуется, нежелательно) — значит разрешено", так? Тебе похоже наплевать на тотже /etc/services, да?
Здравствуйте, Mamut, Вы писали:
M> У меня все хуже У меня помимо файло и git'а (вместо bazaar'а) еще отягчающий факт в виде ssh не на 22-м порту, а на 23-м
Вот за это надо бы тебя попинать. Безопасности подобное не добавляет, трафика подбиратели паролей кушают минимум, а прописывать в консольке порт — убивать котенка каждый раз.
Приветствую, kochetkov.vladimir, вы писали:
k> А на основании чего /etc/services должен считаться эталоном?
На основании того, что он есть.
k>процитируй-ка что там по поводу 80 порта написано?
http 80/tcp www www-http # World Wide Web HTTP
http 80/udp www www-http
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, kochetkov.vladimir, вы писали:
k>> А на основании чего /etc/services должен считаться эталоном? S>На основании того, что он есть.
Ну коли ты привел столь веский аргумент, то я могу лишь предложить тебе удалить его у себя нафиг и не больше не парить людям мозги. На основании того, что его теперь нет
k>>процитируй-ка что там по поводу 80 порта написано?
S>
http 80/tcp www www-http # World Wide Web HTTP
S>http 80/udp www www-http
Он уже не соответствует действительности, т.к. помимо www в исключительно кошерных целях (в твоем понимании) 80-ый порт используется еще и в intranet-системах. Поэтому не стоит говорить, что он может быть эталоном.
Или предлагаешь, для интранет-сайтов завести отдельный порт?
Приветствую, kochetkov.vladimir, вы писали:
k> k>> А на основании чего /etc/services должен считаться эталоном? k> S>На основании того, что он есть. k> Ну коли ты привел столь веский аргумент, то я могу лишь предложить тебе удалить его у себя нафиг и не больше не парить людям мозги. На основании того, что его теперь нет
Стало быть я его удалю у себя, а ты из всех остальных дистрибутивов линуха и юникса? Потянешь?
k> Он уже не соответствует действительности, т.к. помимо www в исключительно кошерных целях (в твоем понимании) 80-ый порт используется еще и в intranet-системах. Поэтому не стоит говорить, что он может быть эталоном. k> Или предлагаешь, для интранет-сайтов завести отдельный порт?
Еще одна крайность. Я смотрю тут хобби — в крайности бросаться.
Приветствую, kochetkov.vladimir, вы писали:
k> И, кстати у меня никакого udp нет: k> Что будем делать с этой маленькой разницей? Давай определим голосованием, чей файл эталоннее?
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, kochetkov.vladimir, вы писали:
k>> k>> А на основании чего /etc/services должен считаться эталоном? k>> S>На основании того, что он есть. k>> Ну коли ты привел столь веский аргумент, то я могу лишь предложить тебе удалить его у себя нафиг и не больше не парить людям мозги. На основании того, что его теперь нет S>Стало быть я его удалю у себя, а ты из всех остальных дистрибутивов линуха и юникса? Потянешь?
Как ты мог заметить, против некоего "некошерного" использования 80-го порта здесь ратуешь исключительно ты. Поэтому удалить этот сомнительный файл из твоей копии дистрибутива будет более чем достаточно.
k>> Он уже не соответствует действительности, т.к. помимо www в исключительно кошерных целях (в твоем понимании) 80-ый порт используется еще и в intranet-системах. Поэтому не стоит говорить, что он может быть эталоном. k>> Или предлагаешь, для интранет-сайтов завести отдельный порт? S>Еще одна крайность. Я смотрю тут хобби — в крайности бросаться.
В крайности бросился ты с первых же сообщений в этой теме. Остальные лишь подыгрывают тебе, чтобы ты со стороны увидел как выглядят твои же изречения
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, kochetkov.vladimir, вы писали:
k>> И, кстати у меня никакого udp нет: k>> Что будем делать с этой маленькой разницей? Давай определим голосованием, чей файл эталоннее?
S>разговор не о tcp/udp а о портах.
Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
Приветствую, kochetkov.vladimir, вы писали:
k> S>Стало быть я его удалю у себя, а ты из всех остальных дистрибутивов линуха и юникса? Потянешь? k> Как ты мог заметить, против некоего "некошерного" использования 80-го порта здесь ратуешь исключительно ты. Поэтому удалить этот сомнительный файл из твоей копии дистрибутива будет более чем достаточно.
Я правильно вижу тут сарказм?
k> S>Еще одна крайность. Я смотрю тут хобби — в крайности бросаться. k> В крайности бросился ты с первых же сообщений в этой теме. Остальные лишь подыгрывают тебе, чтобы ты со стороны увидел как выглядят твои же изречения
Я не бросаюсь в крайности, я лишь прошу не пихать все сервисы через один порт. Вполне разумное требование.
Приветствую, kochetkov.vladimir, вы писали:
k> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее.
Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
Здравствуйте, Sheridan, Вы писали:
S> k> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
S> То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее. S> Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
А-а-а, так ты работать не хочешь? Горе-админы такие горе-админы...
Здравствуйте, netch80, Вы писали:
n> S>> k> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
n> S>> То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее. n> S>> Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
n> H>А-а-а, так ты работать не хочешь? Горе-админы такие горе-админы...
n> Этот "тезис" отлично разворачивается в обратную сторону — на горе-программистов, которым лень оторвать попу и пошевелить пальцем, чтобы за счёт легко определяемых признаков (таких, как номер порта) сделать администрирование менее проблемным.
Номера портов часто бывают настраиваемыми в софте (и это правильно) т.ч. не аргумент вообще.
Здравствуйте, hattab, Вы писали:
n>> S>> k> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
n>> S>> То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее. n>> S>> Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
n>> H>А-а-а, так ты работать не хочешь? Горе-админы такие горе-админы...
n>> Этот "тезис" отлично разворачивается в обратную сторону — на горе-программистов, которым лень оторвать попу и пошевелить пальцем, чтобы за счёт легко определяемых признаков (таких, как номер порта) сделать администрирование менее проблемным.
H>Номера портов часто бывают настраиваемыми в софте (и это правильно) т.ч. не аргумент вообще.
"т.ч." это "таким чином" или что-то другое?
Тут уже звучал принципиальный тезис Гапертона про то, что всё пускать через порт 80 — правильно и чуть ли не единственно правильно. Поэтому речь не о возможности настройки, а о принципиальной позиции.
Здравствуйте, netch80, Вы писали:
n> n>> Этот "тезис" отлично разворачивается в обратную сторону — на горе-программистов, которым лень оторвать попу и пошевелить пальцем, чтобы за счёт легко определяемых признаков (таких, как номер порта) сделать администрирование менее проблемным.
n> H>Номера портов часто бывают настраиваемыми в софте (и это правильно) т.ч. не аргумент вообще.
n> "т.ч." это "таким чином" или что-то другое?
"так что"
n> Тут уже звучал принципиальный тезис Гапертона про то, что всё пускать через порт 80 — правильно и чуть ли не единственно правильно. Поэтому речь не о возможности настройки, а о принципиальной позиции.
Тезис Гапертона следует обсуждать с Гапертоном, я думаю Шеридан тут вообще сказал, что 80 порт он только для WWW, а не HTTP в целом (не буквально так, но это следует из его реплик). Я тут, собственно, только об этом спорю.
Здравствуйте, hattab, Вы писали:
H>WWW без HTTP(S) не бывает (и в документах IANA оно значится, как World Wide Web HTTP). Значит говорим о протоколе. Возможности протокола позволяют использовать его в качестве транспорта для других служб (не WWW). Возможности штатные. Стандарт не нарушается. В чем проблема? Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку.
Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
И это, к сожалению, не категорический императив Кристобаля Хунты — тот хоть можно было обойти, а тут мы имеем неумолимые внешние условия, задаваемые факторами, которые таки техническими средствами никак не решаются:(
Каждый админ сталкивался с подобными ситуациями, и потому в принципе не может принять позицию программиста "надо мной не каплет, мне так удобно, а проблемы администрирования меня не волнуют". Я лично сужу по своему опыту пребывания на обеих сторонах этой идиотской самопальной баррикады, и сам факт такого противостояния меня ой не радует.
h> Возможности протокола позволяют использовать его в качестве транспорта для других служб (не WWW). Возможности штатные. Стандарт не нарушается. В чем проблема?
Проблема в том, что вы делаете очень сложным определение — что за траффик ходить по 80 порту.
h> Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку.
Решаются, еще как решаются. Если по нормальному писать, выделяя порты, а не все тупо сувать сквозь 80й порт.
Здравствуйте, netch80, Вы писали:
n> Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
Очевидно, что решая проблему средствами которыми она не решается, вы ее не решите никогда
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, netch80, Вы писали:
n>> Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
H>Очевидно, что решая проблему средствами которыми она не решается, вы ее не решите никогда :xz:
Вот ты и подписался под тем, чтобы дать средства, которые позволят решить задачу. То есть — разделить по портам.
Здравствуйте, Sheridan, Вы писали:
S> h> WWW без HTTP(S) не бывает (и в документах IANA оно значится, как World Wide Web HTTP). Значит говорим о протоколе.
S>
Я тоже обозначил HTTPS, что с того? Сути это не меняет.
S> h> Возможности протокола позволяют использовать его в качестве транспорта для других служб (не WWW). Возможности штатные. Стандарт не нарушается. В чем проблема?
S> Проблема в том, что вы делаете очень сложным определение — что за траффик ходить по 80 порту.
Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет.
S> h> Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку.
S> Решаются, еще как решаются. Если по нормальному писать, выделяя порты, а не все тупо сувать сквозь 80й порт.
Здравствуйте, netch80, Вы писали:
n> n>> Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
n> H>Очевидно, что решая проблему средствами которыми она не решается, вы ее не решите никогда
n> Вот ты и подписался под тем, чтобы дать средства, которые позволят решить задачу. То есть — разделить по портам.
Это не решение, ибо на это вы повлиять никак не можете.
Приветствую, hattab, вы писали:
h> Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет.
Прсто выделяйте порты для сервисов.
Что вызывает меньше трудозатрат?
Вам в одном месте софтины, в коде, немного другое число ниаписать,
или
Админам поднивать реверс-прокси, анализировать траффик...
а?
h> S> h> Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку. h> S> Решаются, еще как решаются. Если по нормальному писать, выделяя порты, а не все тупо сувать сквозь 80й порт. h> Да не смеши меня. http://www.example.com:123/
Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться?
Здравствуйте, netch80, Вы писали:
n> n>> n>> Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
n> n>> H>Очевидно, что решая проблему средствами которыми она не решается, вы ее не решите никогда
n> n>> Вот ты и подписался под тем, чтобы дать средства, которые позволят решить задачу. То есть — разделить по портам.
n> H>Это не решение, ибо на это вы повлиять никак не можете.
n> Если "вы" это "админы", то тривиально.
Да, "вы" это "админы".
n> Пишется докладная записка — в связи с невозможностью разделить XXX, предлагаю три варианта решения n> 1) покупается железяка за ZZZK$$ n> 2) запрещается всё n> 3) разрешается всё n> и если выбран вариант (2) — а это очень вероятно — то следующая очередь страдать будет уже за авторами сайта.
Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
Здравствуйте, Sheridan, Вы писали:
S> h> Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет.
S> Прсто выделяйте порты для сервисов.
Это не решение. Юзер может настроить прилагу на какой угодно порт.
S> Что вызывает меньше трудозатрат? S> Вам в одном месте софтины, в коде, немного другое число ниаписать, S> или S> Админам поднивать реверс-прокси, анализировать траффик... S> а?
В коде номер порта (окромя дефолтного, разумеется) задают только очень недалекие товарищи. Мы им уподобляться не будем.
S> h> S> h> Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку.
S> h> S> Решаются, еще как решаются. Если по нормальному писать, выделяя порты, а не все тупо сувать сквозь 80й порт.
S> h> Да не смеши меня. http://www.example.com:123/
S> Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться?
Приветствую, hattab, вы писали:
h> Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
Тоесть для того, чтобы программисты не перетрудились придумывать цифру — какой порт будет использовать программа, клиентам предлагается
а) Тратить дцать килобаксов
б) Запретить вооообще все, кроме действительно нужного (и тратить время на постоянное отслеживание и правку списков)
в) Забить гвоздь на политики и безопасность воообще
h> S> Прсто выделяйте порты для сервисов. h> Это не решение. Юзер может настроить прилагу на какой угодно порт.
А по умолчанию — какой? Ибо он и будет в 90% случаев использоваться.
Более того, речь идет о юзерском софте или всетаки о серверном софте?
h> В коде номер порта (окромя дефолтного, разумеется) задают только очень недалекие товарищи. Мы им уподобляться не будем.
Что по умолчанию стоит?
h> S> h> Да не смеши меня. http://www.example.com:123/ h> S> Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться? h> Выше ответил.
При чем тут юзеры? Речь про серверный софт, про сервисы. А не про клиентские части.
Здравствуйте, Sheridan, Вы писали:
S> h> Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
S> Тоесть для того, чтобы программисты не перетрудились придумывать цифру — какой порт будет использовать программа, клиентам предлагается S> а) Тратить дцать килобаксов S> б) Запретить вооообще все, кроме действительно нужного (и тратить время на постоянное отслеживание и правку списков) S> в) Забить гвоздь на политики и безопасность воообще
S> Прграммисты тааакие программисты...
Я вижу ты так и не понял, что техническими мерами эту проблему не решить. Чтож, бывает.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, kochetkov.vladimir, вы писали:
k>> Ок, давай о портах. Чем именно тебя, как админа, ущемляет некошерное использование 80-го порта? Каковы четкие критерии этой некошерности?
S>То, что когда однажды меня шеф попросит прикрыть пользюкам www, я могу прикрыть и еще кучу софта горе-программистов. Когда это выяснится, мне придется извернуться уже поинтереснее. S>Тоесть в этом случае следование корпоративным политикам (а точнее их реализация) становится не в пример труднее.
Есть хоть одна адекватная контора, где перекрыт весь www трафик?
Ты понимаешь что если всем пользователям компании перекрыть нафиг гугл, про производительность может упасть в разы?
А если понимаешь, то почему не можешь объяснить это начальству?
Или ты реально действуешь по принципу "ты начальных, я дурак"?
А вообще такая задача решается прозрачной аутентификацией на прокси, домен windows + isa server (ныне TMG) так умеют.
Тот софт который должен ходить через www просто работает под специально созданной учетной записью.
Приветствую, gandjustas, вы писали:
g> Есть хоть одна адекватная контора, где перекрыт весь www трафик?
Пенсионный фонд, равно как и все государственные организации.
g> Ты понимаешь что если всем пользователям компании перекрыть нафиг гугл, про производительность может упасть в разы? g> А если понимаешь, то почему не можешь объяснить это начальству?
Я как раз и хочу оставить 80 порт открытым, но прибить все остальное, которое пользует этот 80й порт, но не является http://www
Вот об этом тут разговор, а не про "закрыть все нафик"
g> А вообще такая задача решается прозрачной аутентификацией на прокси, домен windows + isa server (ныне TMG) так умеют. g> Тот софт который должен ходить через www просто работает под специально созданной учетной записью.
Понимаешь, при адекватной разработке некоторого софта — это бы не понадобилось поднимать. А я тут смотрю, использование http://www для своих нужд очень в моде.
Здравствуйте, hattab, Вы писали:
H>Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
И ты хочешь сказать, что тебя устраивает то, что песец настанет всему, что вы (программисты) делали?
Здравствуйте, Sheridan, Вы писали:
S> h> Я вижу ты так и не понял, что техническими мерами эту проблему не решить. Чтож, бывает.
S> Я вижу, ты так и не понял, что проблема решается техническими средствами при условии, что программисты не пишут халтуру.
Ох, ну ты и... Шеридан... Сам же написал, как легко обходятся стандартные порты жаббера, и снова талдычишь о технических мерах. Блин, и эти люди запрещают мне ковыряться в носу
Приветствую, hattab, вы писали:
h> Ох, ну ты и... Шеридан... Сам же написал, как легко обходятся стандартные порты жаббера, и снова талдычишь о технических мерах. Блин, и эти люди запрещают мне ковыряться в носу
Поднять дома собственный сервант жаббера, настроить его, итд итп — это по твоему легко?
Нет, я уверен что ты сможешь это сделать. А как насчет офисного планктона? Смогут?
Здравствуйте, netch80, Вы писали:
n> H>Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
n> И ты хочешь сказать, что тебя устраивает то, что песец настанет всему, что вы (программисты) делали?
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, netch80, Вы писали:
n>> H>Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
n>> И ты хочешь сказать, что тебя устраивает то, что песец настанет всему, что вы (программисты) делали?
H>С чего бы ему настать? Я уже озвучивал решение
Здравствуйте, Sheridan, Вы писали:
S> h> Ох, ну ты и... Шеридан... Сам же написал, как легко обходятся стандартные порты жаббера, и снова талдычишь о технических мерах. Блин, и эти люди запрещают мне ковыряться в носу
S> Поднять дома собственный сервант жаббера, настроить его, итд итп — это по твоему легко? S> Нет, я уверен что ты сможешь это сделать. А как насчет офисного планктона? Смогут?
Достаточно банального прокси-редиректора Планктон поищет на форумах, какая нибудь добрая душа из числа преодолевших ему все расскажет и все.
Здравствуйте, netch80, Вы писали:
n> n>> H>Браво! Именно об этом способе решения было сказано Шеридану дважды. Сперва в "Сети, сокеты, протоколы" об административном способе решения написал я, потом тут, в КСВ, об этом же написал kochetkov.vladimir.
n> n>> И ты хочешь сказать, что тебя устраивает то, что песец настанет всему, что вы (программисты) делали?
n> H>С чего бы ему настать? Я уже озвучивал решение
.
n> Вот оно и будет применяться — только в обратную сторону. Отказом от готового софта, от использования сервисов, разгоном наёмных прогеров.
Ага, разгонят программеров решающих задачи бизнеса в угоду юзерам зырящим порнуху. Да-да, именно так и будет Будет по другому: найдут админа способного решать поставленную задачу.
Здравствуйте, hattab, Вы писали:
n>> Вот оно и будет применяться — только в обратную сторону. Отказом от готового софта, от использования сервисов, разгоном наёмных прогеров. H>:)) Ага, разгонят программеров решающих задачи бизнеса в угоду юзерам зырящим порнуху.
Это допущение необоснованно и некорректно.
H> Да-да, именно так и будет :))) Будет по другому: найдут админа способного решать поставленную задачу.
Практика показывает, что 50/50. Причём когда очень толстая контора говорит другой конторе "мы отказываемся от вашего сервиса потому, что он неконтролируем", другая вдруг шустро начинает шевелиться и делать как должно...
Здравствуйте, netch80, Вы писали:
n> n>> Вот оно и будет применяться — только в обратную сторону. Отказом от готового софта, от использования сервисов, разгоном наёмных прогеров.
n> H> Ага, разгонят программеров решающих задачи бизнеса в угоду юзерам зырящим порнуху.
n> Это допущение необоснованно и некорректно.
В полном соответствии с твоим
n> H> Да-да, именно так и будет Будет по другому: найдут админа способного решать поставленную задачу.
n> Практика показывает, что 50/50. Причём когда очень толстая контора говорит другой конторе "мы отказываемся от вашего сервиса потому, что он неконтролируем", другая вдруг шустро начинает шевелиться и делать как должно...
Знаешь, когда админ начинает ныть о трудозатратах (при том, что хардкодить адреса и порты нельзя):
Что вызывает меньше трудозатрат?
Вам в одном месте софтины, в коде, немного другое число ниаписать,
или
Админам поднивать реверс-прокси, анализировать траффик...
а?
Это очень сильно символизирует. Я привел, вполне себе, рабочий вариант: реверс-прокси + анализатор HTTP трафика + контролировать адреса для метода CONNECT. Но это конечно сложнее, чем тупо закрыть порт
S>Мамут, ты похоже чисто по русски делаешь "не запрещено (не рекоммендуется, нежелательно) — значит разрешено", так? Тебе похоже наплевать на тотже /etc/services, да?
Это не по-русски. Это так везде и во всем. Не запрещено значит разрешено. Повторю в пятидесяты раз. Регистрация портов существует только для облегчения взаимодействия гетерогенных систем.
То есть:
— ssh по умолчанию ожидает сервис на 22-м порту
— ftp по умолчанию ожидает сервис на 21-м порту
— браузер по умолчанию ожидает ответ от веб-сервера на 80-м порту
и т.п.
При этом никто не запрещает тебе перенести их на любой другой порт, если это надо тебе.
Не знаю, что такое /etc/services и чем оно лучше, чем документ от IANA
M>> У меня все хуже У меня помимо файло и git'а (вместо bazaar'а) еще отягчающий факт в виде ssh не на 22-м порту, а на 23-м
AB>Вот за это надо бы тебя попинать. Безопасности подобное не добавляет, трафика подбиратели паролей кушают минимум, а прописывать в консольке порт — убивать котенка каждый раз.
У меня почему-то достаточно много трафика на этот порт шло — хз, почему
h>> Я вижу ты так и не понял, что техническими мерами эту проблему не решить. Чтож, бывает.
S>Я вижу, ты так и не понял, что проблема решается техническими средствами при условии, что программисты не пишут халтуру.
Когда ты наконец-то поймешь, что софт, работающий по 80-му порту может быть не халтурой?
h>> Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет. S>Прсто выделяйте порты для сервисов.
1. Сервисов в мире больше, чем портов — это во-первых.
2. Порты являются всего лишь соглашением между производителями софта, не более.
3. NAT + кастомный порт — это зло
S>Что вызывает меньше трудозатрат? S>Вам в одном месте софтины, в коде, немного другое число ниаписать, S>или S>Админам поднивать реверс-прокси, анализировать траффик... S>а?
Неверная оценка трудозатрат
h>> S> h> Шеридану уже неоднократно говорили, что означенные им проблемы техническими средствами не решаются, а он упорно заводит старую пластинку. h>> S> Решаются, еще как решаются. Если по нормальному писать, выделяя порты, а не все тупо сувать сквозь 80й порт. h>> Да не смеши меня. http://www.example.com:123/ S>Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться?
И не только браузер. Софту пофиг, в какой порт стучаться. Порт не определяет данные, которые по нему идут. Это, блин, черным по белому написано даже в регулирующем документе. Не говоря уже о том, что это, блин, понятно безо всяких документов.
Если ты, как админ, полагаешься на номера портов, то грош тебе цена, как админу.
Приветствую, Mamut, вы писали:
M> S>Мамут, с чего ты взял что не читаю? M> Опыт общения с тобой. Если бы ты читал хоть что-нибудь, в твоих текстах хоть что-нибудь когда-нибудь менялось бы.
Я привык не подстраиваться под общее мнение, а придерживаться того, что считаю правильным. Поэтому ни реклама на меня не действует, ни нлп, ни твои попытки.
Когда же я действительно неправ — я это признаю. Но сейчас, в этом разговоре про порты — я прав.
Приветствую, Mamut, вы писали:
M> S>Твои ответы напоминают: M> S>
- Почему так?
M> S>- ПАТАМУШТА!!!1
M> S>Я вижу не только лень чтото делать, но еще и убежденность в своей правоте.
M> Интересно, что ты себя именно так и ведешь (см. свой же спор про /etc/services несмотря на приведенный документ от IANA)
На моей стороне общемировая практика. И тут вдруг оказывается — что все вокруг дураки, раз договариваются о том, на каком порту чему висеть, и все оказывается надо на 80 порт переводить.
Приветствую, Mamut, вы писали:
M> h>> Ставь реверс-прокси и будешь уверен, что ходит только HTTP. А уж анализ HTTP делать проблем не составляет вообще Только это тебя все равно не спасет.
M> S>Прсто выделяйте порты для сервисов.
M> 1. Сервисов в мире больше, чем портов — это во-первых.
И все они будут одновременно подняты на одном сервере?
M> 2. Порты являются всего лишь соглашением между производителями софта, не более.
Зачем нарушать эти соглашения? Есть общемировая практика (жаббер — 5222 итд) — ЗАЧЕМ делать по другому?
M> 3. NAT + кастомный порт — это зло
С чего это?
M> S>Что вызывает меньше трудозатрат? M> Неверная оценка трудозатрат
Ты подумал перед тем как описать? Опиши свой ход мыслей.
M> S>Что ты этим хочешь сказать? Что браузер можно попросить не на 80 порт стучаться?
Конечно пофиг.
M> И не только браузер. Софту пофиг, в какой порт стучаться. Порт не определяет данные, которые по нему идут. Это, блин, черным по белому написано даже в регулирующем документе. Не говоря уже о том, что это, блин, понятно безо всяких документов.
Мамут, не пытайся показать меня идиотом. Я не говорю о том, что данные нельзя пустить по другому порту. Я говорю о том, что это НЕ НАДО делать.
Разные вещи.
M> Если ты, как админ, полагаешься на номера портов, то грош тебе цена, как админу.
Если ты программист, и не можешь понять до сих пор — о чем разговор, то грош тебе цена как программисту.
Приветствую, Mamut, вы писали:
M> S>Мамут, ты похоже чисто по русски делаешь "не запрещено (не рекоммендуется, нежелательно) — значит разрешено", так? Тебе похоже наплевать на тотже /etc/services, да?
M> Это не по-русски. Это так везде и во всем. Не запрещено значит разрешено. Повторю в пятидесяты раз. Регистрация портов существует только для облегчения взаимодействия гетерогенных систем.
Даже если так — то зачем специально усложнять? Почему ты защищаешь это самое усложнение?
M>> S>Мамут, с чего ты взял что не читаю? M>> Опыт общения с тобой. Если бы ты читал хоть что-нибудь, в твоих текстах хоть что-нибудь когда-нибудь менялось бы.
S>Я привык не подстраиваться под общее мнение, а придерживаться того, что считаю правильным. Поэтому ни реклама на меня не действует, ни нлп, ни твои попытки.
Идиот. Это не реклама. Это докторская диссертация одного из разработчиков HTTP.
S>Когда же я действительно неправ — я это признаю. Но сейчас, в этом разговоре про порты — я прав.
Угу, и при этом у тебя нет ни одного аргумента в защиту своей «правоты» кроме «я так вижу». Хотя тебе уже даже стандарты привели, опровергающие твою позицию
Здравствуйте, netch80, Вы писали:
N>Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
Можно примерчик?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>> Когда ты наконец-то поймешь, что софт, работающий по 80-му порту может быть не халтурой?
S>Я не говорю, что софт — халтура, я говорю о том, что халтурно сделана сетевая прослойка в плане того, на каком порту висеть сервису.
А у тебя, видмо, есть прямо таки железобетонные аргументы, почему выбор такого способа коммуникации, — это халтура? Хотелось бы их услышать.
Здравствуйте, Sheridan, Вы писали:
g>> Есть хоть одна адекватная контора, где перекрыт весь www трафик? S>Пенсионный фонд, равно как и все государственные организации.
Взаимоисключающие параграфы.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
S> M> S>Я вижу не только лень чтото делать, но еще и убежденность в своей правоте.
S> M> Интересно, что ты себя именно так и ведешь (см. свой же спор про /etc/services несмотря на приведенный документ от IANA)
S> На моей стороне общемировая практика. И тут вдруг оказывается — что все вокруг дураки, раз договариваются о том, на каком порту чему висеть, и все оказывается надо на 80 порт переводить.
Общемировая практика, как раз таки, не на твоей стороне Посмотри на блоги, их API торчит на 80-ом порту, а это совсем даже не WWW. Аналогично и с другими веб-сервисами.
M>> S>Мамут, ты похоже чисто по русски делаешь "не запрещено (не рекоммендуется, нежелательно) — значит разрешено", так? Тебе похоже наплевать на тотже /etc/services, да?
M>> Это не по-русски. Это так везде и во всем. Не запрещено значит разрешено. Повторю в пятидесяты раз. Регистрация портов существует только для облегчения взаимодействия гетерогенных систем.
S>Даже если так — то зачем специально усложнять? Почему ты защищаешь это самое усложнение?
Где я его защищаю? И где ты видишь усложнение? Я просто говорю: если софт хочет/может работать по 80-му порту, да пожалуйста. Если система, которая работает с этим софтом, знает, на каком порту его искать — да пожалуйста, в чем проблема-то? В том, что там теоретически может быть веб-сервер? А кто сказал, что он там обязан быть? Да никто.
Еще раз повторю:
— у меня SSH работает не по 22-му порту, а по 23-ему. Что-то плохое вдруг произошло? SSH перестал работать? Я к нему не могу подсединиться? Нет.
— у меня MySQL может работать не по 3306-му порту. Что-то плохое вдруг произойдет? MySQL перестанет работать? Я к нему не смогу подсединиться? Нет.
— у меня FTP может работать не по 21-му порту. Вопросы те же. Ответ тот же.
Порты — это только соглашение и не более. То, что по английски называется "sane defaults", «разумные значения по умолчанию». При этом никто не обязывает тебя эти умолчания оставлять. Да, это облегчает жизнь, но это не является абсолютным императивом.
Здравствуйте, Mamut, Вы писали:
M>>> Когда ты наконец-то поймешь, что софт, работающий по 80-му порту может быть не халтурой?
S>>Я не говорю, что софт — халтура, я говорю о том, что халтурно сделана сетевая прослойка в плане того, на каком порту висеть сервису.
M>А у тебя, видмо, есть прямо таки железобетонные аргументы, почему выбор такого способа коммуникации, — это халтура? Хотелось бы их услышать.
ну хотя бы одно уже то, что авторы захардкодили номер сетевого порта для работы — уже признак халтуры.
Приветствую, Mamut, вы писали:
M> Идиот. Это не реклама. Это докторская диссертация одного из разработчиков HTTP.
Диссертация — это реклама себя перед ученым советом для получения бонусов.
Плюс к тому там скорее будут рассматриваться только "полезные" вопросы, чтобы создавать впечатление о том, что тема полезная, хорошая, и автор, откопавший сей алмаз — заслуживает всяческих почестей.
M> Угу, и при этом у тебя нет ни одного аргумента в защиту своей «правоты» кроме «я так вижу». Хотя тебе уже даже стандарты привели, опровергающие твою позицию
Она не опровергают. Более того, они указывают на то, что стороны договариваются о том какой порт что значит. По факту мы эту договоренность уже имеем (http:80, smtp:25 итд), и ВНЕЗАПНО, исходя из вашего тут понаписанного, оказывается что все вокруг дураки.
Приветствую, hattab, вы писали:
h> И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
Тупо: пользователь, который залез в туда браузером — поймет что там творится? Что это не www, а просто служебная инфа, к www отношения не имеющая?
Приветствую, Eugeny__, вы писали:
E> Здравствуйте, netch80, Вы писали:
E> N>Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
E> Можно примерчик?
iptables -A INPUT -i ppp0 -m multiport --dports 110,25 -j DROP
или там...
iptables -P OUTPUT DROP
iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
Приветствую, Eugeny__, вы писали:
E> g>> Есть хоть одна адекватная контора, где перекрыт весь www трафик? E> S>Пенсионный фонд, равно как и все государственные организации. E> Взаимоисключающие параграфы.
В лужу п..л, или я смею ожидать более развернутый ответ?
M>> Идиот. Это не реклама. Это докторская диссертация одного из разработчиков HTTP.
S>Диссертация — это реклама себя перед ученым советом для получения бонусов.
S>Плюс к тому там скорее будут рассматриваться только "полезные" вопросы, чтобы создавать впечатление о том, что тема полезная, хорошая, и автор, откопавший сей алмаз — заслуживает всяческих почестей.
Ты все же удивительно недалекий человек. Человек прдеставил аритектуру приложений, построенную с учетом особенностей HTTP. Как там у тебя было, «я админ, всегда могу открыть интернет, почитать». Ну почитай хотя бы введение на русском, что ли.
M>> Угу, и при этом у тебя нет ни одного аргумента в защиту своей «правоты» кроме «я так вижу». Хотя тебе уже даже стандарты привели, опровергающие твою позицию S>Она не опровергают. Более того, они указывают на то, что стороны договариваются о том какой порт что значит. По факту мы эту договоренность уже имеем (http:80, smtp:25 итд), и ВНЕЗАПНО, исходя из вашего тут понаписанного, оказывается что все вокруг дураки.
Шеридан, завязывай с голосами в своей голове. ВНЕЗАПНО что-то происходит только в твоем мозге.
Приветствую, hattab, вы писали:
h> S> h> И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
h> Вариантов масса. Сервис может отдать админку с мордой на Flex'е, может отдать доку с описанием методов сервиса и их параметров, может просто редиректить на правильный эндпоинт.
Уговорил. В таком варианте вполне приемлемо. Только я бы все равно перенес на другой порт, ибо по сути это не web.
h> А теперь ты на вопрос (выделил) ответишь?
Если без того, что ты описал, то нарушает здравый смысл.
h>> И с чего ты решил, что прав? Вот скажи, аргументированно, какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту? S>Тупо: пользователь, который залез в туда браузером — поймет что там творится? Что это не www, а просто служебная инфа, к www отношения не имеющая?
Ну пусть заходит Пользователю никто не гарантирует, что на 80-м порту будет www. Более того, могу удивить:
И таких примеров можно накопать десятки. Это плохо? Нет. Никто не гарантирует, что на 80-м порту будет www. А софт, который с такими сервисами работает, знает, какие данные оттуда получать. И получает дополнительные плюшки, связанные с HTTP-протоколом нашару.
Приветствую, hattab, вы писали:
h> Вот видишь, по сути ты ничего не можешь возразить, а еще пальцы стрелять порывался.
Между прочим я до сих пор придерживаюсь политике отстреливания пальцев. Мне просто надоел этот никчемный спор. Вы не хотите ничего понимать и просто идете по легчайшему пути.
h>> Вот видишь, по сути ты ничего не можешь возразить, а еще пальцы стрелять порывался.
S>Между прочим я до сих пор придерживаюсь политике отстреливания пальцев. Мне просто надоел этот никчемный спор. Вы не хотите ничего понимать и просто идете по легчайшему пути.
Перцы, вы какбы начинаете из пушки по воробьям. Я всего лишь пытаюсь вам доказать то, что какбы незря придумали порты. Какбы пытаюсь вам рассказать, что надо бы всетаки сервисы разносить по портам. Ибо, как минимум, когда сообщество принимает что порт xxx числится за таким-то сервисом — это говорит о его зрелости.
А вы как дети малые...
Приветствую, hattab, вы писали:
h> Когда пытаются доказать, приводят аргументы, а не свое вИдение в качестве оных.
Вот тебе аргументы: наличие файла /etc/services в дистрибутивах линуха
Будешь оспаривать?
h>> Когда пытаются доказать, приводят аргументы, а не свое вИдение в качестве оных. S>Вот тебе аргументы: наличие файла /etc/services в дистрибутивах линуха S>Будешь оспаривать?
Буду.
/etc/services появился там не просто так. Он является всего лишь копией некоего документа под названием Port Numbers от наивысшего органа стандартизации, IANA. Что написано в этому документе, тебе уже было сказано
. Но, блин, это же надо читать и вникнуть, но ты этого физиологически не умеешь.
Ну и вопросы:
— Что значит левые данные по отношению к порту? Где вообще прописано отношение данных к порту?
— Что произойдет с товим сервисом на порту, скажем, 14 (unassigned), если я заполню форму регистрации порта и захапаю его себе?
— Почему я не могу использовать порты, которые зарегистрированы на сервисы, которых в природе уже не существует (Finger, Xyplex, OCBinder, Remote-KIS)?
— Почему RSS и SOAP поверх 80-го порта — это нормально по-твоему, а все остальное ненормально?
E>> N>Проблема в том, что регулярно возникают ситуации, когда проблемы можно решать только техническими средствами, несмотря на то, что, как ты говоришь, они техническими средствами не решаются.
E>> Можно примерчик?
S>iptables -A INPUT -i ppp0 -m multiport --dports 110,25 -j DROP S>или там... S>iptables -P OUTPUT DROP S>iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
Нене, я просил не это. Я имел ввиду пример ситуации, когда требуется техническое и только техническое решение, и другого способа нет. Причем желательно в адекватной конторе, где начальство не кретинические имбецилы с комплексом власти.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E>>> g>> Есть хоть одна адекватная контора, где перекрыт весь www трафик? E>>> S>Пенсионный фонд, равно как и все государственные организации. E>>> Взаимоисключающие параграфы.
S>>В лужу п..л, или я смею ожидать более развернутый ответ?
E__>Скажем так, ни я, ни кто-либо из моих знакомых/сотрудников/прочих собеседников не видел ни разу ни одной адекватной госконторы. Везде одинаково: по куче причин(бюрократия, копеечные зп, имбецильное начальство, непрофессионализм — да тысячи их, все долго перечислять) эффективность выполняемой работы не то что болтается в конце приоритетов, а вообще отсутствует в этом списке. Все делается "на отъ#бись". Об адекватности в таких условиях даже говорить не приходится. E__>Я говорю, понятное дело, про госконторы в пост-ссср. Если ты знаешь обратные примеры, приведи их, пожалуйста.
E__>ЗЫ решение "закрыть нахер все порты, в том числе и www" — это как раз то самое "сделать на отъ#бись".
Ну, вообще-то в госконторах нафиг не нужны никакие порты кроме рабочих. 80-й к ним явно не относится
ЗЫ. А если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо.
Приветствую, Eugeny__, вы писали:
E> Нене, я просил не это. Я имел ввиду пример ситуации, когда требуется техническое и только техническое решение, и другого способа нет. Причем желательно в адекватной конторе, где начальство не кретинические имбецилы с комплексом власти.
Например закрыть smtp наружу, чтобы из организации не шел спам (на случай если антивирь пропустит нового трояна). Почту же пустить через корпоративный postfix, на котором поднять антиспам и обязательную авторизацию.
Ты эту проблему решишь административно?
Приветствую, Eugeny__, вы писали:
E> Я говорю, понятное дело, про госконторы в пост-ссср. Если ты знаешь обратные примеры, приведи их, пожалуйста.
ПФР не из их числа. У нас стремятся к более высокой автоматизации процессов. Например прошедший прием сведений уже принимали полностью в автоматическом режиме. Были конечно проблемы, но они составляли едва ли 15% всего трафика сведений.
Приветствую, Mamut, вы писали:
M> Ну, вообще-то в госконторах нафиг не нужны никакие порты кроме рабочих. 80-й к ним явно не относится
Ты неправ. У нас в ПФР например наблюдается смещение в сторону веб-приложений.
M> ЗЫ. А если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо.
Работникам (в том числе и автоматизаторам) запрещено поднимать самостоятельно воообще какие-либо сервисы.
Приветствую, Sinclair, вы писали:
S> Благо, весь остальной мир благополучно существует без Шеридана и без его наркоманских мировоззрений. Где наличие etc/services приравнивается к Слову Божьему, при том, что это — всего лишь вспомогательный файл, который нужен только для упрощённого запуска telnet не по номеру порта, а по имени протокола. (Этак я возьму дефолтный список букмарков IE и объявлю его Каноническим Списком Сайтов) Где нет никакого понимания, зачем вообще введена концепция портов в протоколах TCP и UDP, и для чего IANA их распределяет.
Здравствуйте, Sheridan, Вы писали:
S>Что будет, если мы решим на этом порту поднять например nntp?
Там будут группы новостей и не будет DNS сервера. Ваш КО.
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
M>> /etc/services появился там не просто так. Он является всего лишь копией некоего документа под названием Port Numbers от наивысшего органа стандартизации, IANA. Что написано в этому документе, тебе уже было сказано
. Но, блин, это же надо читать и вникнуть, но ты этого физиологически не умеешь. S>Еще недавно ты ругал меня за то, что я руководствуюсь этим документом. Теперь ты сам на него ссылаешься. Что изменилось?
Ты меня с кем-то перепутал.
M>> Ну и вопросы: M>> — Что значит левые данные по отношению к порту? Где вообще прописано отношение данных к порту? S>Как ни странно, в том самом документе, на который ты ссылаешься. S>Например, S>
S>domain 53/tcp Domain Name Server
S>domain 53/udp Domain Name Server
S>Какие данные там ходят по твоему?
Не по-моему, а по стандарту:
сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
Блин, я его тебе даже перевел, но блин, читать что-либо — это для лохов, видимо.
S>Какой софт пользуется портом?
сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
S>Что будет, если мы решим на этом порту поднять например nntp?
сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
Если мы на том порту решим поднять nntp ничего не произойдет и мир не перевернется. У меня ssh на 23-м порту, никто не умер.
M>> — Что произойдет с товим сервисом на порту, скажем, 14 (unassigned), если я заполню форму регистрации порта и захапаю его себе? S>Я буду вынужден поменять порт и форсировать его регистрацию в iana. Ваш, К.О.
Нафига?
M>> — Почему я не могу использовать порты, которые зарегистрированы на сервисы, которых в природе уже не существует (Finger, Xyplex, OCBinder, Remote-KIS)? S>Судя по iana, они существуют. Не существует например, 81 S>
# 81 Unassigned (Removed on 2007-09-06)
Судя по IANA они просто зарегистрированы. А существуют они или нет — это слегка вне компетенции IANA.
M>> — Почему RSS и SOAP поверх 80-го порта — это нормально по-твоему, а все остальное ненормально? S>По моему и это — ненормально. Мне просто уже надоедает этот разговор, и близок момент, когда я соглашусь только потому, что вы меня задолбали.
Мы от тебя хотим четких ответов на четко поставленные вопросы. Ты же пока не приводишь никаких аргументов кроме «я так вижу». Мы же, в отличие от тебя, опираемся на те самые стандарты, о которых ты жаловался, что мы не соблюдаем.
M>> Ну, вообще-то в госконторах нафиг не нужны никакие порты кроме рабочих. 80-й к ним явно не относится S>Ты неправ. У нас в ПФР например наблюдается смещение в сторону веб-приложений.
Чем отличается веб-приложение от любого другого?
M>> ЗЫ. А если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо. S>Работникам (в том числе и автоматизаторам) запрещено поднимать самостоятельно воообще какие-либо сервисы.
Объясни мне по пунктам, с чем ты не согласен в моем ответе. Ответ заново приведен полностью ниже:
h>> Это не аргументы. Наличие данного файла не отвечает на поставленный мною вопрос: h>>
Какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
S>Я уже 100500 раз отвечал: тем, что по факту там не www, а данные для приложения (веб, не-веб — не важно).
www — это тоже данные для приложения Просто веб-браузер умеет абсолютную белиберду трансформировать в воспринимаемый хуманами вид.
При этом тот самый www может отдавать что угодно:
— неформатированый текст
— форматированый текст в разных форматах (HTML, XML, JSON, CSV...)
— двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.)
Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п.
Чем это отличается от любых других данных — :хз: То есть всем понятно, что вообще ничем не отличается. Главное — чтобы принимающая сторона знала, что с этими данными делать. И только Шеридан свято верит в сферовакуумный www.
S>> Благо, весь остальной мир благополучно существует без Шеридана и без его наркоманских мировоззрений. Где наличие etc/services приравнивается к Слову Божьему, при том, что это — всего лишь вспомогательный файл, который нужен только для упрощённого запуска telnet не по номеру порта, а по имени протокола. (Этак я возьму дефолтный список букмарков IE и объявлю его Каноническим Списком Сайтов) Где нет никакого понимания, зачем вообще введена концепция портов в протоколах TCP и UDP, и для чего IANA их распределяет.
S>http://www.iana.org/assignments/port-numbers тоже для телнета?
S>>Подмена портов работает на малом количестве народа, до 100 человек по моим ощущениям. Им можно сообщить. А когда народа много пользуется сервисом — у тебя просто проблема взлома сменится на проблему "у меня непашет, строчнопочените!!!111"
S>Налицо полное непонимание устройства интернета. И, в частности, популярных протоколов. S>К примеру, сменить порт outgoing MTA — это одно. Сменить порт incoming MTA — совсем другое. В частности, потому, что RFC974 никаким образом не регламентирует способ узнать порт, на котором висит почтовик. Так что он вынужден висеть на 25м порту за отсутствием средств коммуникации.
E__>ЗЫ Я о проблеме спама забыл давно, с того времени, как перешел на гмыло. Вообще, почта через smtp — каменный век, веб-доступ рулит безбожно.
Я так думал, пока не увидел человека с 12 гигами почты, которому периодически приходят письма с аттачменатми (презентации и т.п.) от 3 до 20 мегабайт. Для него возможен только оффлайн,
Шеридан, ты заколебал. Я не согласен с тем, что вы возводишь в ранг нерушимого эталона именно назначение портов, всячески игнорируя то, что в стандарте написано черным по белому: http://rsdn.ru/forum/flame.comp/3908391.aspx
E__>>ЗЫ Я о проблеме спама забыл давно, с того времени, как перешел на гмыло. Вообще, почта через smtp — каменный век, веб-доступ рулит безбожно.
M>Я так думал, пока не увидел человека с 12 гигами почты, которому периодически приходят письма с аттачменатми (презентации и т.п.) от 3 до 20 мегабайт. Для него возможен только оффлайн,
Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
При этом никто не мешает прикрутить оффлайн клиент к тому же гмылу там, где он им пользуется чаще всего, и пользоваться вебом из других мест.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>>>ЗЫ Я о проблеме спама забыл давно, с того времени, как перешел на гмыло. Вообще, почта через smtp — каменный век, веб-доступ рулит безбожно.
M>>Я так думал, пока не увидел человека с 12 гигами почты, которому периодически приходят письма с аттачменатми (презентации и т.п.) от 3 до 20 мегабайт. Для него возможен только оффлайн,
E__>Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
В приложении открывается моментально, потому что оно уже закачано на диск
E__>При этом никто не мешает прикрутить оффлайн клиент к тому же гмылу там, где он им пользуется чаще всего, и пользоваться вебом из других мест.
Для этого надо настраивать одинаковые правила (более 200 у того человека) что в аутлуке, что в гмыле, а это практически нереально
Здравствуйте, Mamut, Вы писали:
E__>>Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
M>В приложении открывается моментально, потому что оно уже закачано на диск
Я имею ввиду то, тот же ворд грузится секунд пять, а дока скачивается за 2-3. Смысл в том, что разицы при хорошем инете между диском и вебом почти нет(и вообще, заливая кому-то что-то на флешку с инета, понимаешь, что скорость ограничена флешкой, а не соединением...).
E__>>При этом никто не мешает прикрутить оффлайн клиент к тому же гмылу там, где он им пользуется чаще всего, и пользоваться вебом из других мест.
M>Для этого надо настраивать одинаковые правила (более 200 у того человека) что в аутлуке, что в гмыле, а это практически нереально
Ну, тут может быть. Если человек настолько хардкорно пользуется почтой, то да. У меня правил вообще 0. Зато критична безгеморройная доступность с любого устройства с выходом в сеть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
E__>>Смысл в том, что разицы при хорошем инете между диском и вебом почти нет(и вообще, заливая кому-то что-то на флешку с инета, понимаешь, что скорость ограничена флешкой, а не соединением...).
M>А при чем тут флешка? Разница с инетом пока еще ощутима.
Ну, может, у меня старая флешка. На нее запись 5-7 МБ/сек, скачивание с нета достигает 9-11 метров в секунду. Отаки пироги.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Приветствую, Mamut, вы писали:
M> Чем отличается веб-приложение от любого другого?
Об это мы копья ломали еще в флейме про ведгу. Просто вспомни. Я своего мнения не поменял.
M> M>> ЗЫ. А если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо. M> S>Работникам (в том числе и автоматизаторам) запрещено поднимать самостоятельно воообще какие-либо сервисы. M> Я где-то говорил про самостоятельно?
А я и не опровергал твои слова
Приветствую, Hobot Bobot, вы писали:
HB> S>Что будет, если мы решим на этом порту поднять например nntp?
HB> Там будут группы новостей и не будет DNS сервера. Ваш КО.
Приветствую, Mamut, вы писали:
M> Не по-моему, а по стандарту: M>
M> сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
Абсолютно верно, Маут И именно благодаря таким как тут (воспиринмающим распределение портов, как рекоммендации) и всяким злоумышленникам и приходится определять — чтоже это за хрень например на порту 110 сидит — pop3 или очередная задумка аффтара.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Eugeny__, вы писали:
E>> Это почему? Не, если у него медленный инет, и при этом на почту он заходит всегда с одного места — может быть. А так, 20 метров качается быстрее, чем открывается в приложении.
S>Понимаешь, быстрый инет чуть менее чем полностью сосредоточен в пределах мкада. Я например за мегабит плачу 1к рублей. В соседнем городе есть 10 мегабит, но он только по оптике (прикиньте стоимость подключения), и стоит 2400 рублей.
Да ладно . Украина за пределами МКАД? Я плачу около 400 рублей за 100 мегабит в Киеве. В других городах доступно как миимум 24 мегабита за примерно 800 российских рублей(правда, там исходящая всего 3).
Конечно, это печально, что в России с этим местами еще не очень, о ведь ситуация постояно улучшается, как я понимаю.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
M>>Главное — чтобы принимающая сторона знала, что с этими данными делать.
S>Спасибо, ты озвучил мое мнение насчет "правильности" данных.
Вообще-то, это то, о чем мы тебе талдычим, а не наоборот.
S>А теперь вспомни с чего вооообще этот флейм начинался, еще не в ксв. Вспомнишь?
Эээ нет. Попрошу твои возражения по пунктам. Потому что ты со мной не согласился, даже минус поставил. Повторю:
h>> Это не аргументы. Наличие данного файла не отвечает на поставленный мною вопрос: h>> Какие стандарты нарушает XML-RPC сервис работающий на 80-ом порту?
S>Я уже 100500 раз отвечал: тем, что по факту там не www, а данные для приложения (веб, не-веб — не важно).
www — это тоже данные для приложения Просто веб-браузер умеет абсолютную белиберду трансформировать в воспринимаемый хуманами вид.
При этом тот самый www может отдавать что угодно:
— неформатированый текст
— форматированый текст в разных форматах (HTML, XML, JSON, CSV...)
— двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.)
Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п.
Чем это отличается от любых других данных — :хз: То есть всем понятно, что вообще ничем не отличается. Главное — чтобы принимающая сторона знала, что с этими данными делать. И только Шеридан свято верит в сферовакуумный www.
Что за привычка такая делать вид, что не замечешь вопросов? Какие у тебя возражения против моего ответа? Желательно по пунктам. Болеее того, добавлю еще один вопрос: что такое www по-твоему, и что именно должно быть на 80-м порту?
M>> Чем отличается веб-приложение от любого другого? S>Об это мы копья ломали еще в флейме про ведгу. Просто вспомни. Я своего мнения не поменял.
Да ничем оно не отличается. Оно так же гоняет данные туда-сюда. Причем совершенно произвольные данные.
M>> M>> ЗЫ. А если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо. M>> S>Работникам (в том числе и автоматизаторам) запрещено поднимать самостоятельно воообще какие-либо сервисы. M>> Я где-то говорил про самостоятельно? S>А я и не опровергал твои слова
Ты мне их приписал или дополнил, но они этого не требовали. Повторю еще раз:
если какая-то софтина и требует 80-й порт, то дать разрешение только ей никакой сложности не представляет, имхо.
M>> сам факт наличия трафика в зарегистрированный порт или из него не означает, что это — «хороший» трафик. Сисадмины должны выбирать конфигурацию своих систем, исходя из своих знаний об этом трафике, а не опираясь на номер порта, будь он зарегистрирован или нет.
S>Абсолютно верно, Маут И именно благодаря таким как тут (воспиринмающим распределение портов, как рекоммендации)
А это и есть рекомендация, который ты, как админ обязан следовать. А ты начинаешь ныть и даловаться на то, как тебя, админа, обидели.
S>и всяким злоумышленникам и приходится определять — чтоже это за хрень например на порту 110 сидит — pop3 или очередная задумка аффтара.
Ну определяй, кто тебе мешает-то? Благо, анализаторов трафика — как собак нерезаных. Все твои «ой, а что будет, если порт поменять» — это ничем не подкрепленная истерия на чистом месте.
M> S>А теперь вспомни с чего вооообще этот флейм начинался, еще не в ксв. Вспомнишь? M> Эээ нет. Попрошу твои возражения по пунктам. Потому что ты со мной не согласился, даже минус поставил.
Эээ нет, давай вспомним. Это ключ к моим возражениям.
M> При этом тот самый www может отдавать что угодно: M> — неформатированый текст
Ничего удивительного, это для него html без тегов, можно сказать — вырожденый html
M> — форматированый текст в разных форматах (HTML, XML, JSON, CSV...)
И много из этого показывает не браузер, а ole-объекты, которые браузер вызывает и встраивает в себя
M> — двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.)
так или иначе браузер подтягивает нужный софт и показывает с помощью его, а не самостоятельно
M> Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п.
Все верно. И в рамках страницы, на которой все это внедрено — без проблем, показывайте.
Но не суйте туда того, чего там быть не должно. Не суйте туда rpc вне рамок веб-приложений, не суйте туда чтото по типу скайпа итд.
M> Чем это отличается от любых других данных — :хз: То есть всем понятно, что вообще ничем не отличается. Главное — чтобы принимающая сторона знала, что с этими данными делать. И только Шеридан свято верит в сферовакуумный www.
Мамут, ты умный человек, но иногда тебя клинит, и ты не можешь понять о чем тебе говорят. Вспомни с чего все начиналось и может поймешь.
M> что такое www по-твоему, и что именно должно быть на 80-м порту?
Нечто, что поймет и сумеет отобразить браузер. Читабельно, правильно отобразит. А то с тебя станется — покажешь как браузер отображает бинарный файлик в виде мусора.
Еще раз повторяю: вспомни с чего начинался это бесполезный флейм?
M>> S>А теперь вспомни с чего вооообще этот флейм начинался, еще не в ксв. Вспомнишь? M>> Эээ нет. Попрошу твои возражения по пунктам. Потому что ты со мной не согласился, даже минус поставил. S>Эээ нет, давай вспомним. Это ключ к моим возражениям.
M>> При этом тот самый www может отдавать что угодно: M>> — неформатированый текст S>Ничего удивительного, это для него html без тегов, можно сказать — вырожденый html
Ничего подобного.
M>> — форматированый текст в разных форматах (HTML, XML, JSON, CSV...) S>И много из этого показывает не браузер, а ole-объекты, которые браузер вызывает и встраивает в себя
Какая разница? Правильно — никакой. Это все равно какие-то данные, которые браузер толком отображать-то и не умеет, но они посылаются по тому самому www
M>> — двоичные данные в разных форматах (изображения, видео, аудио, flash, doc, pdf и т.п.) S>так или иначе браузер подтягивает нужный софт и показывает с помощью его, а не самостоятельно
Какая разница? Правильно — никакой. Это все равно какие-то данные, которые браузер толком отображать-то и не умеет, но они посылаются по тому самому www
M>> Просто принимающая сторона (обычно браузер) знает, что с этими данными делать. И то — не всегда. Браузеры надо учить понимать PDF, Flash и т.п. S>Все верно. И в рамках страницы, на которой все это внедрено — без проблем, показывайте. S>Но не суйте туда того, чего там быть не должно.
А что там должно быть?
S>Не суйте туда rpc вне рамок веб-приложений, не суйте туда чтото по типу скайпа итд.
А какая разница? Это — всего лишь данные. О чем четко, ясно и неоднозначно говорит IANA
M>> Чем это отличается от любых других данных — :хз: То есть всем понятно, что вообще ничем не отличается. Главное — чтобы принимающая сторона знала, что с этими данными делать. И только Шеридан свято верит в сферовакуумный www. S>Мамут, ты умный человек, но иногда тебя клинит, и ты не можешь понять о чем тебе говорят. Вспомни с чего все начиналось и может поймешь.
Почему же, помню. «АЯЯЯЯЙЙЙЙЙ!!! НИЗЗЯ НИЗЗЯ НИЗЗЯ НИЗЗЯ НИЗЗЯ НИЗЗЯ НИЗЗЯ ничего на 80-й порт». Без единого аргумента
M>> что такое www по-твоему, и что именно должно быть на 80-м порту? S>Нечто, что поймет и сумеет отобразить браузер. Читабельно, правильно отобразит.
Какой браузер? Что значит «правильно»?
— lynx не отобразит ни видео ни изображений
— firefox не отобразит VRML
— ie 5 не отобразит html 5
— браузер с отключенным яваскриптом не отобразит основной интерфейс gmail'а
Более того, где написано, что на 80-м порту обязано быть то, что «читабельно, правильно отобразит браузер»?
S>А то с тебя станется — покажешь как браузер отображает бинарный файлик в виде мусора.
S>Еще раз повторяю: вспомни с чего начинался это бесполезный флейм?
Легко:
G> HTTP очень многие используют как транспорт. Например — Скайп. А многие — используют его "родную" семантику. RESTful интерфейс называется. Удобно.
Это как раз и плохо. Удобно для программистов, согласен — ничего не надо придумывать. Да и лень думать к тому-же.
А вот админам свинью подкладываете, да. Не жалуйтесь потом что админы вас не уважают.
1. Ты походя, не задумываясь, направо и налево оскорбляешь программистов. Ну, это дело такое, на глупцов за такое не обижаются, хоть и начинает доставать
2. Ты начал плакаться, что, мол, бедные админы. Причем ты продолжил плакаться даже когда тебя ткнули носом в стандарт
и продолжил нести всякую чушь про «обязаны», «должно» и т.п., несмотря на то, что тебя раз за разом тыкали носом все в тот же стандарт (я одну и ту же ссылку привел тебе раз пять, но понять ты ее так и не смог). Но зачем понимать? Зачем вообще думать над какими-то там стандартами, можно же себе нафантазировать все, что угодно.
3. Ты начал извиваться, как уж на сковороде, задавая «умные» вопросы типа «что у тебя одного смена портов может и будет работать, а что будет, если так сделает большой сервис с миллионами пользователей». Ну так эта, ты же у нас «админ, который всегда может посмотреть в интернете», не? Поинтересуйся, какие сервисы зарегистрированы на порты 465 и 587, по которым Gmail раздает POP миллионам пользователей. Почему-то ни у кого никаких проблем это не вызывает, с чего бы это? Но зачем что-то искать, узнавать и учить, если это все можно заменить фантазиями?
4. Не говоря уже о «на 80-м должно висеть что-то, что должно показываться браузером», хотя две секунды работы мозга разбивают этот «аргумент» в пух и прах. Но зачем тебе работать мозгом, верно? У тебя же есть фантазия!
Здравствуйте, Sheridan, Вы писали:
S> M> — форматированый текст в разных форматах (HTML, XML, JSON, CSV...)
S> И много из этого показывает не браузер, а ole-объекты, которые браузер вызывает и встраивает в себя
HB>Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port.
HB>Перевожу: "для того, чтобы неизвестные (в том смысле, что он не может заранее сообщить им номер порта) серверу клиенты знали, на каком порту искать тот или иной сервис". Всё. Не для удобства админов. Не для того, "чтобы было правильно". Только для того, чтобы почтовый сервер отправителя знал, что почтовый сервер получателя ждёт писем на 25-м порту.
HB>Если мы не ожидаем "unknown callers" (как Мамут с его ssh), мы спокойно можем поменять номер порта.
Или использовать порт «не по назначению», как, например, GMail с его POP по 465-му порту.
Ты заканчивай умничать и вспомни наконец — с чего начался базар.
До тех пор я из этого топика ухожу, так как не вижу спмысла по 30му разу повторять что мнения не изменю и все что ты говоришь — это лишь попытки оправдать то, о чем было сказано в самом начале базара.
S>Ты заканчивай умничать и вспомни наконец — с чего начался базар.
А ты заканчивай тупить и начинай работать мозгом. То, с чего начался спор, я тебе процитировал
S>До тех пор я из этого топика ухожу, так как не вижу спмысла по 30му разу повторять что мнения не изменю и все что ты говоришь — это лишь попытки оправдать то, о чем было сказано в самом начале базара.
Приветствую, Mamut, вы писали:
M> S>Так вылазь и поправь меня. Потому как я вижу, что браузер встраивает в себя акробат, если открывается pdf или там oowriter, если открывается docx
M> Но при этом по www отсылаются абсолютно «левые» (по твоему определению) данные: файлы разных форматов, аудио, видео. И тебя это не смущает почему-то
Ты просто не пытаешься даже понять о чем я говорю. Тебя задевает что я до сих пор с тобой спорю.
Приветствую, Privalov, вы писали:
P> Не то, чтобы я был большим знатоком, по-моему автору того поста изначально нужно было делать обмен данными по хорошо изученному HTTP, а не изобретать проблемы себе на голову.
И там дальше я с ним соглачился, что в его случае по другому никак.
Здравствуйте, Hobot Bobot, Вы писали:
HB>Там вообще-то английским по белому написано, для чего нужна регистрация портов.
HB>
HB>Ports are used in the TCP [RFC793] to name the ends of logical connections which carry long term conversations. For the purpose of providing services to unknown callers, a service contact port is defined. This list specifies the port used by the server process as its contact port.
Сама по себе идея смотреть RFC793, а не более новые рекомендации по этому поводу, вообще-то уже ущербна. Это специфика практики IETF — они никогда не вводят редакции своих документов и у них нет, например, RFC0793-2010, которое хотя бы содержало список рекомендаций последних практик в области TCP. В старых RFC, хоть они и сохраняют часто статус стандартов, есть множество устарелостей. Например, RFC791 (IP) упоминает классы сетей (давно отменённые) и TOS (заменённый на DSCP).
Поэтому, всё, что может отражать содержание такого документа — это что про порты думали в момент его издания, а это сентябрь 1981-го года. Напомнить, чем тогда был Internet и чем он стал сейчас, или сам догадаешься?;)
Если какой-то документ и может означать практику последнего времени в этом вопросе, то изданный не более 10 лет назад, а лучше — 5.
HB>Если мы не ожидаем "unknown callers" (как Мамут с его ssh), мы спокойно можем поменять номер порта.
Да, само по себе это верно. Но не учитывает множество обстоятельств, связанных именно с особенностями современных сетей и их функционированием.
Здравствуйте, Eugeny__, Вы писали:
E__>Здравствуйте, Sheridan, Вы писали:
S>>Понимаешь, быстрый инет чуть менее чем полностью сосредоточен в пределах мкада. E__>Да ладно :). Украина за пределами МКАД?
Не обращай внимания, у них даже Питер считается пустыней;)
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Mamut, вы писали:
M>> S>Так вылазь и поправь меня. Потому как я вижу, что браузер встраивает в себя акробат, если открывается pdf или там oowriter, если открывается docx
M>> Но при этом по www отсылаются абсолютно «левые» (по твоему определению) данные: файлы разных форматов, аудио, видео. И тебя это не смущает почему-то
S>Ты просто не пытаешься даже понять о чем я говорю.
А ты пытаешься хоть что-то объяснить? На вопрос про левые данные ты ни разу не дал ответа, который бы выдержал хоть одного дополнительного вопроса. Ладно, не отвечай. Ты уже наотвечался в отдельном топике.
Здравствуйте, Eugeny__, Вы писали:
E__>Да ладно . Украина за пределами МКАД? Я плачу около 400 рублей за 100 мегабит в Киеве. В других городах доступно как миимум 24 мегабита за примерно 800 российских рублей(правда, там исходящая всего 3).
Гы... 12-14 предел
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Про апач на 81-м порту говорить, пожалуй, не стану 
)
