чо такой дерзкий

HTTP, FTP

Предлагаю отметить, что оба - просто «TP». Просто один предназначался для F вообще, второй - для частного случая HT. Но зло не в способе передачи, а в содержимом. В FTP можно официально засунуть больше разного зла (т.к. «всё есть файл»), но HT давно не только гипертекст, т.ч. разница только в популярности и натоугодности.

Ты про хидеры забыл. Через FTP очень неудобно передавать служебную информацию.

Ты про хидеры забыл. Через FTP очень неудобно передавать служебную информацию

Наоборот, в FTP для этого целый отдельный канал. HTTP всяко сложнее и тормознее, даже в первой версии.

Наоборот, в FTP для этого целый отдельный канал.

Нет, в FTP отдельный канал как раз для передачи данных. И нет, ты не можешь прицепить хидеры к команде STORE.

HTTP всяко сложнее и тормознее, даже в первой версии.

Пруфца бы.

Можешь тыкнуть не туда и слить всю свою историю броузинга и мало ли что еще через все эти дыры/отаке.

И взамен ты предлагаешь непонятно откуда качать бинарники и запускать. Это просто восхитительно.
А можешь хоть одну дыру вспомнить связанную с безопасностью а не с фингерпринтингом и прочей паранойей?

А можешь хоть одну дыру вспомнить связанную с безопасностью а не с фингерпринтингом и прочей паранойей?

Подставные SSL сертификаты, JS-эксплоиты, атаки на веб-движки браузеров.

Пруфца бы

IMO очевидно.

Чем меньше разнообразие данных в одном канале, тем протокол проще; http суёт в канал минмиум 4 синтаксиса(запрос/ответ, заголовки, данные одним куском или кусками), в ftp минимум данные отдельно, уже делить на 2. -> сложнее.

Любой transfer encoding потребляет ресурсы. У FTP данные могут ходить отдельным потоком без всяких рамок и перекодирований, в http - только если сильно повезёт (размер известен заранее и неизменен, или можно позволить close в конце). -> в «общем случае» тормознее.

Нет, в FTP отдельный канал как раз для передачи данных

Нет, в FTP «отдельные каналы» для передачи данных, а «отдельный канал» - для всяких команд и метаданных.

твоих вообще никто не видел, что наводит на мысль...

это протокол прикладного уровня...

Мне вот кажется что Тим Бернерс-Ли просто выполнил политический заказ
Лучше бы он производителей смартфонов и Microsoft разругал за товоизацию и секюрбут.
А производителей процессоров за ОС в гипервизоре и цифровую подпись биоса.

Хидеров-то все равно нету :)

Хидеров-то все равно нету

Есть такое слово: "ненужно"!

А на самом деле: ничего не мешает добавить по новой FTP-команде на каждый полезный HTTP-заголовок запроса, и будет выглядеть даже проще(':' не нужна) и эффективнее(особенности клиента прокачиваются 1 раз на сессию). Заголовки ответов тоже, на первый взгляд, легко засовываются например в 1xx ответы.

Т.ч. недостатоков совсем не видно. да, кроме натов и фиреволов.

В итоге ты получишь HTTP/2.

«Сперва добейся» это ужасный аргумент, в том числе тут.

В оригинальной статье старик продемонстрировал порицание действий корпораций, а у тса какое-то «the leather club is two blocks down».

А на самом деле: ничего не мешает добавить по новой FTP-команде на каждый полезный HTTP-заголовок запроса, и будет выглядеть даже проще

УПРЛСЯ? На каждую команду ответ нужен. И свой TCP пакет.

Нужен DRM наоборот - когда компания покупает у пользователя его данные или обменивает их на услуги. Причем доступ к ним не постоянен и может быть прерван пользователем в любой момент времени. Его SOLID вроде как про это. И законы докрутить так что сбор/обработка данных пользователя без его явного на то согласия (в том числе и косвенных) - преступление за которое можно схватить штраф. А вот отучить людей от социоблядства пожалуй не выйдет, 95% продолжат писать о себе всё и всем.

«разбить эти технические титаны» — это нагреватели воды? иначе должно быть «этих технических титанов».

А вот отучить людей от социоблядства пожалуй не выйдет, 95% продолжат писать о себе всё и всем.

А что в этом плохого?

Плохого? Громко сказано. Это просто информационный мусор забивающий каналы обмена. А ещё это относительно удобный для рынка (и государств) способ мониторить обстановку (в целом так и персонифицировано) - т.е. ещё один способ залезть в карман к тем кто падок на всякую «халяву».

Плохого? Громко сказано. Это просто информационный мусор забивающий каналы обмена.

Щито? Не хочешь читать чужой вконтактик — не читай.

А ещё это относительно удобный для рынка (и государств) способ мониторить обстановку (в целом так и персонифицировано) - т.е. ещё один способ залезть в карман к тем кто падок на всякую «халяву».

Как желание написать о себе коррелирует с залезанием в карман?

А я и не читаю. Зато других дятлов смотрящих друг у друга фоточки/видео из жанра «что я ел» и «как посрал» миллионы.

Как желание написать о себе коррелирует с залезанием в карман?

Анализ данных и контекстная реклама. А ещё треки передвижений если ты ССЗБ с геолокацией или опсос мудак. Не прикидывайся будто ты не знаешь как это работает.

А я и не читаю. Зато других дятлов смотрящих друг у друга фоточки/видео из жанра «что я ел» и «как посрал» миллионы.

И почему это забивает каналы обмена тогда? oO

Анализ данных и контекстная реклама.

Ну контекстная реклама по _моему_ кошельку никак не ударяет, что за бред.

А ещё треки передвижений если ты ССЗБ с геолокацией или опсос мудак.

Путаешь теплое с мягким. «Смотрите, как я круто на гитаре играю» и «давайте следить за юзером из утюга» — разные вещи.

И почему это забивает каналы обмена тогда? oO

Так каналы то делить приходится. Вот ломанулись вечером хомячки фоточки и ютуб смотреть и рраз - а сеть едва шевелится. Понятное дело что в договоре «доступ на скорости до ... Мбит/с», но все равно раздражает.

«Смотрите, как я круто на гитаре играю» -> значит можно выпихнуть рекламу музыкальных инструментов или другой сопутствующей фигни. Если мозги есть то конечно не поведешься, а другой может и купить. А в цену входит в том числе затраты на рекламу (не всегда напрямую, но тем не менее). Чем не попытка влезть в карман? Фиг с ним что с тобой не работает, все равно тех кто ведется на это слишком много. И это много подстегивает компании следить за всеми даже через туалетную бумагу (привет хлаоми).

На каждую команду ответ нужен

Как раз заголовки ответа будет куда совать:)

И свой TCP пакет

Нет. FTP использует поточную часть tcp, и про пакеты ничего не знает.

В итоге ты получишь HTTP/2

Именно! Люди поигрались в HTTP, поняли, что получилось не очень, и начали переизобретать FTP(*) - но внутри HTTP.

(*) да, это изрядное преувеличение - скорее то, чем мог бы стать FTP в альтернативной вселенной, где люди были бы слегка более предусмотрительными, и развивали бы более подходящее для будущих задач решение.

Как раз заголовки ответа будет куда совать:)

То есть вместо одной команды будет двадцать? Лол, это точно все ускорит.

Нет. FTP использует поточную часть tcp, и про пакеты ничего не знает.

Лол. От этого пакеты перестают ходить и все начинает работать через астрал?

Ты просто натягиваешь любимую сову на глобус. Если добавить все нужное в FTP, это уже будет не FTP.

Так каналы то делить приходится. Вот ломанулись вечером хомячки фоточки и ютуб смотреть и рраз - а сеть едва шевелится. Понятное дело что в договоре «доступ на скорости до ... Мбит/с», но все равно раздражает.

Этот якобы ненужный контент дает развитие технологий и дешевый интернет. Так что кто чью полосу еще занимает...

«Смотрите, как я круто на гитаре играю» -> значит можно выпихнуть рекламу музыкальных инструментов или другой сопутствующей фигни. Если мозги есть то конечно не поведешься, а другой может и купить. А в цену входит в том числе затраты на рекламу (не всегда напрямую, но тем не менее). Чем не попытка влезть в карман? Фиг с ним что с тобой не работает, все равно тех кто ведется на это слишком много.

Ничем не попытка. Мальчик с флаерами на улице тоже в карман лезет?

И это много подстегивает компании следить за всеми даже через туалетную бумагу (привет хлаоми).

Жажда наживы всегда подстегивала. Но мы придумали законы, запрещающие убивать других людей ради профита. Осталост придумать законы, запрещающие шпионить.

То есть вместо одной команды будет двадцать

Поймай, ради любопытства, дамп сессии ftp и http, и сравни потоки. Что-то мне подсказывает, что ты увидишь не так много отличий в «запросной» части - в обоих случаях последовательность строк типа «ключ значение», только в FTP «ключи» короче. В «ответной» - ты увидишь, что FTP-сервер отвечает раньше(собственно, на каждый «ключ»). Т.ч. ничем тут http не лучше.

это точно все ускорит

Если клиент будет ждать ответа на каждую строку будет медленнее, но для этого даже слово специальное придумали - ССЗБ.

От этого пакеты перестают ходить

Ну, это же ты придумал, что ftp-команды пакетов хотят.

Обмен информацией в интернете не нужен.

Нужен. Потому что GitLab; AUR.

натягиваешь любимую сову на глобус

Это тебе показалось. Я ни разу не люблю FTP. Но наблюдение за развитием HTTP напоминает фразу «круг замкнулся». Хотя это должна быть окружность.

Если добавить все нужное в FTP

Будет FTP с расширенным набором команд. Отметь, у http с 91го года 4 версии, у ftp с 80го(если не 71 - оно ещё до TCP было) одна. Что намекает на продуманную расширябельность. Или ненужность.

Ты сам предложил сделать хидеры через команды, лол. Команда подразумает ответ.

Будет FTP с расширенным набором команд.

Бгг. Эталонный случай NIH. Кстати, а куда параметры URL пихать?

Команда подразумает ответ

Но его не обязательно ждать.

куда параметры URL пихать

В имя файла же. Так же, как и в http - только со спецсимволом '/', чтобы с каталогами не путаться.

Эталонный случай NIH

Эталонный случай неправильного использования неизвестного слова.

Но его не обязательно ждать.

Даже отодвинув вопрос асинхронных FTP команд — а если хидер невалидный, то что в итоге будет? :)

Так... а в чем отличие от HTTP-то в итоге будет?

если хидер невалидный, то что в итоге будет?

Очевидно же - получим пачку ответов (типа OK,OK,OK,ERR,OK,ERR,...), посчитаем, на какие команды приходится ERR, и либо отошлём ABORT и нарисуем клиенту «Ой,всё!», либо продолжим работать в «режиме совместимости», в зависимости от [не]приемлемости оного для текущей задачи.

Как сервер должен обрабатывать эти команды? В HTTP хидер относится к GET/PUT и модифицирует поведение. Как будет выглядеть обработка в данном случае? Как привязать хидер к STOR?

в чем отличие от HTTP-то в итоге будет

1. очевидная аутентифицированная сессия пользователя - безопаснее, дешевлее, и без кукишей. 2. Сервер может обрабатывать предпочтения клиента 1 раз на сессию, а не на каждый пиксель оформления странички. 3. Не нужно мультиплесировать потоки(http/2), уже есть tcp для этого.

Итого, проще = лучше

Как сервер должен обрабатывать эти команды?

По очереди.

хидер относится к GET/PUT и модифицирует поведение. Как будет выглядеть обработка в данном случае?

Как «cd» и «sudo» в твоём шеле.

Как привязать хидер к STOR?

Как «rm -rf» к "." - см. предшествовавшие «cd» и «sudo».

Скажи себе правду - сайтописцы наизнанку выворачиватся, чтобы обеспечить запоминание сервером состояния пользовательской сессии. Что тут просто бесплатно(пока tcp не рвётся), или крайне дёшево(клиент просто перепосылает в новое соединение «настроечные» команды прошлой сессии - типа как http но при каждом запросе).

То есть вместо одной HTTP команды, которых, благодаря HTTP/2, можно посылать сразу много, мы должны сделать странного вида стейтмашину, которая рассматривает одни команды как дополнительные данные к другим, и все это в строго сериализованной манере, иначе тебе придется еще дальше уходить от FTP и внедрять серийные номера запросов. И без возможности сервера послать данные без предварительного запроса.

Ну и кому этот урод нужен?

И это мы еще про CDN не говорили. И межсервисную аутентификацию в духе JWT. И обработку стейта при частых разрывах (в метро).

странного вида стейтмашину

В упор не понимаю, почему тебе кажется это странным. обычный shell с переменными окружения, каждый день в таком. Или вынос за скобки общих множителей в школьной арифметике ((a*b*c + a*b*d) == a*b*(c+d)) - обычнее же некуда.

без возможности сервера послать данные без предварительного запроса

И тут FTP тоже рулёзнее - ты, потенциально(этого нет в спеке, но добавление не cломает протокол, как в «кошерном»), можешь открыть сколько угодно слушающих портов для произвольных целей, в который сервер будет совать тебе что угодно когда захочет, например асинхронные уведомления о чём попало.

кому этот урод нужен

Вот именно. Почему уже не откопать почти готовый протокол, подходящий под задачи, вместо пихания невпихуемого в несовместимую саму с собой ошибку создателя?

про CDN не говорили.

Опять не вижу отличий.

межсервисную аутентификацию в духе JWT

С этим духом не знаком, увы. Однако, из общих соображений, пролезающее через заголовки гарантированно пролезет через команды(просто убери ":" и "-" и проигнорируй промежуточный ответ).

И обработку стейта при частых разрывах

О чём я и говорил - HTTPеры героически решают проблему, созданную применением избранного протокола вне области его предназначения(правда, для голых html-ей он был самое то). Впрочем, мода на REST намекает на то, что её решать не очень то и нужно.

В упор не понимаю, почему тебе кажется это странным. обычный shell с переменными окружения, каждый день в таком. Или вынос за скобки общих множителей в школьной арифметике ((a*b*c + a*b*d) == a*b*(c+d)) - обычнее же некуда.

Можно вообще по одному TCP соединению на заголовок. Только вот зачем?

И тут FTP тоже рулёзнее - ты, потенциально(этого нет в спеке, но добавление не cломает протокол, как в «кошерном»), можешь открыть сколько угодно слушающих портов для произвольных целей, в который сервер будет совать тебе что угодно когда захочет, например асинхронные уведомления о чём попало.

То есть пока весь мир борется со снижением количества TCP сессий, мы будем делать совершенно обратное? Зачем?

Вот именно. Почему уже не откопать почти готовый протокол, подходящий под задачи, вместо пихания невпихуемого в несовместимую саму с собой ошибку создателя?

Ээээ... HTTP решает задачу лучше, чем твой убогий монстр.

Опять не вижу отличий.

Ну как бы... любая следующая TCP сессия может быть обработана другим сервером. Если у тебя нет шареного state'а (привет, кукисы), то как ты будешь его шарить между серверами?

О чём я и говорил - HTTPеры героически решают проблему, созданную применением избранного протокола вне области его предназначения(правда, для голых html-ей он был самое то). Впрочем, мода на REST намекает на то, что её решать не очень то и нужно.

Эээ... Чо? Смари, ты предлагаешь хранить state в рамках TCP сессии (лол). Сессия рвется. Но поскольку кукисы ты не любишь... заново логиниться что ли? А все настройки сайта куда девать?

по одному TCP соединению на заголовок. Только вот зачем

Это не объясняет, каким образом тебе кажется странным использование сервером переданых в той же сессии клиентом предпочтений.

весь мир борется со снижением количества TCP

Это какй-то иной мир. Наш борется против:

1. задержек. На этом фронте http и появлися. И был героем, пока странички состояли из одного файла - ftp требовал целых 2 соединения. Появление «<img src=>» выравняло ситуацию, N+1 на фоне N выглядит совсем не плохо, особенно(как нынче модно) при N стремящейся к нецензурности. Но да, мы же можем переизобрести пакетную передачу данных, и засунуть её внутрь одного TCP-потока - велосипеды же экологичнее.

2. несанкционированного доступа. В скором времени оказалось, что не всем должно быть всё можно. Когда получение одного файла начала выглядеть как

- Дай.
- 407.
- Дай, я же свой!
- 401.
- Дай, это же я!
- Ну на.

HTTP решает задачу лучше

Получается - да, несомнено это и есть «решение задачи лучше». :-/

PS: too long, обним куском не пролезло

Если у тебя нет шареного state'а (привет, кукисы), то как ты будешь его шарить между серверами?

«шареный state» - это тормоза и простои. ты действительно этого хочешь?

заново логиниться что ли?

Ну, тебя же не беспокоит необходимость каждый раз куку в запрос упаковывать. Hint: это за нас UserAgent делает.

все настройки сайта куда девать

Ты передаёшь настройки сайта в заголовках? Это ничем не отличается от FTP команд(кроме лишних символов [-:] и передачи на каждый файлик). Или ты передаёшь «ID», ко которому сервер находит у себя твои настройки? Для этого в FTP с 71 года есть специальный хидер CWD - опять короче, только 1 раз на сессию и безопасно.

«шареный state» - это тормоза и простои. ты действительно этого хочешь?

Глупости. Шареный стейт это кукисы и JWT токены. Где тут тормоза и простои?