Cобсеседованиями собеседуй собеседник HTTP 1, 2, 3 QUIC

проверьте себя и вы

Не ну я завалил сразу

Не ну я завалил сразу

Не кокетничайте, вы бы не завалили. В вас я верю.

HTTP 3 основан на новом протокол QUIC который основан на UDP.

на вникал в вашу вебщину, но поверх негарантированной доставки всегда можно накалякать протокол гарантированной доставки. так што скорее всего он там и есть.

Вроде кажется простой вопрос, но со временем забывается. Работаем то в парадигме вопрос ответ, тип ответа, парсинг заголовка, работа с телом ответа.

Такие вещи как HOL (head-of-line) в HTTP 1.1 или streams HTTP 2. Они ускользают от внимания.

На деле HTTP 1.1 - последоватлеьный, HTTP 2 - параллельный, HTTP 3 - параллельный на транспортном уровне.

https://blog.bytebytego.com/p/http-10-http-11-http-20-http-30-quic

На собеседованиях спрашивают про разницу протоколов HTTP разных версий

Собеседований на кого?

QUIC разрботан для смартфонов, когда пользователь меняет сети. В UDP нет гарантированной доставки, в QUIC - конечно есть.

на вникал в вашу вебщину,

Это еще не вебщина. Это чистые сети: транспортный уровень системы OSI.

Собеседований на кого?

На повара-кондитера.

И так, что мы имеем.

• HTTP 1 TCP соединение на отправку каждого ресурса, текстовый протокол.
• HTTP 1.1 постоянное TCP содинение, возможность отсылать множество запросов, ответы приходят последовательно. Пока не пришел ответ на запрос №1, ответы на запрос №2, №3 и №4 не придут. Также текстовый проткол.
• HTTP 2 протокол бинарный, также существует на постоянном TCP соединение, создана концепция стримов: параллельная загрузка ресурсов в рамках одного TCP соденинения.
• HTTP 3 бинарнаый проткол на QUIC, потоки уже реализованы на уровне UDP. Сам QUIC расшифровывается «Quiq UDP internter connection», является UDP с встроенным TLS.

Вообще keep-alive был ещё в первом http, так что первый ответ не корректен

Вообще keep-alive был ещё в первом http, так что первый ответ не корректен

Keep-alive появился в версии HTTP 1.1 в 1997 году. В версии HTTP 1.0 1996 года его небыло. А в весрии HTTP 0.9 1991 года был всего один тип запроса GET.

А 1.0 и 1.1 рассматриваются в вопросе отдельно?

А 1.0 и 1.1 рассматриваются в вопросе отдельно?

Вы что это как борьбу рассматриваете? Какая разница. Оба ответа верные. Если вдаваться в подробности, то из-за последовательности протокола HTTP 1.1 браузеры создавали несколько TCP соединений для формирования многопоточности. Эмулировали HTTP 2/3 по средствам TCP и HTTP 1.x.

UPD:

Т.е. сначала фактически создали HTTP 2 на HTTP 1 эксплуатируя TCP. Потом уже существующую практику переоформили в HTTP 2, превратив текстовый проткол в бинарный (видимо, чтоб склеивать разные фрагметы потоков). И уже в конце все переписали начисто в HTTP 3 и QUIC под смартфоны и переключение сетей, чтоб не обращать внимание на потерянные кусочки данных, при переходе из одной сети в другую.

В конце не хватает тестового задания аля «реализуйте поддержку protobuf сообщений для QUIC протокола, и обязательно чтобы на Rust». Аля:

use std::fs::File;
use std::io::BufWriter;
use std::path::Path;
use crate::errors::Result;
use crate::reader::BytesReader;
use crate::writer::{Writer, WriterBackend};

pub trait MessageWrite: Sized {
    fn write_message<W: WriterBackend>(&self, _: &mut Writer<W>) -> Result<()> {
        Ok(())
    }

    fn get_size(&self) -> usize {
        0
    }

    fn write_file<P: AsRef<Path>>(&self, p: P) -> Result<()> {
        let file = BufWriter::new(File::create(p)?);
        let mut writer = Writer::new(file);
        self.write_message(&mut writer)
    }
}

pub trait MessageRead<'a>: Sized {
    fn from_reader(r: &mut BytesReader, bytes: &'a [u8]) -> Result<Self>;
}

pub trait MessageInfo {
    const PATH: &'static str;
}

В версии HTTP 1.0 1996 года его небыло.

Кстати еще момент, в стандарте не было, но браузеры поддерживали нестандартное расширение

поверх негарантированной доставки всегда можно накалякать протокол гарантированной доставки

Можно. Но тот, кто так делает - идиот.

Можно. Но тот, кто так делает - идиот.

Почему? Мне кажется, что это будет намного быстрее. По крайней мере в Greenplum для передачи интерконнект трафика используется UDPIFC и скорость там намного выше, а надежность такая же как у TCP.

sre?

Ну может ноки какие-то, может быть просто разрабы. Так-то базовые вещи товарищ говорит.

sre!

слова интервьюируемого скорее «элиты не препятствуют самообыдлячиванию 98%»

https://www.youtube.com/watch?v=1kjgLc27a3Q

база такая что

квадратные уравнения это кокет-сциенс для посетителя пятёрочки

ибо метод ложного положения как деды завещали более сподручен в

Ну для SRE в этом разбираться нужно. Особенно с нынешними приколами с блокировками, VPN и проксированиями трафика. Бывает, что нужно запретить использовать какой-либо из протоколов, чтобы пользователям стало лучше.

Ну может ноки какие-то, может быть просто разрабы. Так-то базовые вещи товарищ говорит.

Если это не разработчик веб сервера (nginx and co.), то 99% ему никогда не понадобиться это.

Ну может ноки какие-то,

Кто такие ноки?

sre?

Любое собеседование на BackEnd разработчика. Конкретно этот вопрос взят с собеседования разработчика на Golang. В принципе, от языка не зависит.

Потому что сколько вы не выблёвываете свой мозг на бумагу, ничего лучше TCP вы не сделаете.

то 99% ему никогда не понадобиться это.

Такие спорные сентенции: это не понадобиться, то не понадобиться. Алгоритмы не надо, устройство сети не надо, сильно вдаваться в теории ООП не надо, архитектуру UNIX не надо.

Чем это все заканчивается?

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

Потому что сколько вы не выблёвываете свой мозг на бумагу, ничего лучше TCP вы не сделаете.

SCTP.

Чем это все заканчивается?

Уже закончилось на самом деле. Вот так спрашиваешь, продолжите ряд: бело-оранжевый, оранжевый, бело-зеленый, синий… А в ответ тишина и чистые, пустые глаза. При этом в резюме 15+ лет в ИТ.

Вот так спрашиваешь, продолжите ряд: бело-оранжевый, оранжевый, бело-зеленый, синий…

Сидел раза 4 перечитал, это же последовательности для обжима витой пары. Дак откуда это помнить, если обжимают раз в 10 лет, а то и реже?

TCP соединение на отправку каждого ресурса

Я еще когда в подгузнике ползал, уже офигевал от тупости этого решения. Это ж надо было ради экономии сокета создать целой индустрии геморрой на многие миллионы баксов.

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

это же последовательности для обжима витой пары

Это достаточный ответ.

обжимать отвёрткой

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

Кто хочет, кому надо - разберется. А 99% это просто не нужно. Всегда офигевал от пары экранов требований к разработчикам - типа это минимальные знания, а, по факту, формочки на php или java клепать нужно.

Работа с такими полиглотами, на позиции разработчика, а не лида, у меня заканчивалась одинаково всегда - оверинжиниринг, потом выбрасывание кода и переписывание его нормально с уменьшением объемов и сложности раза в три.

Спрашивать такие тонкости конечно можно, но с тем же успехом можно спросить чем вариатор от автомата отличается, на собеседовании разработчика. Ну а чо - инженер же, должен разбираться.

Я к чему - если нанимаешь разработчика, то спрашивай то с чем он будет сталкиваться 99% времени. А с 1% проблем должен лид разбираться или DevOps.

Работа с такими полиглотами, на позиции разработчика, а не лида, у меня заканчивалась одинаково всегда - оверинжиниринг, потом выбрасывание кода и переписывание его нормально с уменьшением объемов и сложности раза в три.

Вы втираете какую-то дичь. Образованный человек, он на то и образованный, чтобы делать то, что от него требуется. Если начался оверинжиниринг, значит, человек не образован в области культуры написания кода и дизайна приложения.

Для выявления таких людей и существует трехэтапное собеседование с системным дизайном на втором этапе.

Полиглотами становятся не от зубрежки, а от досконального понимания абстракций, из которых состоят языки программирования: массивы, интерфейсы, first-class functions и так далее, а также основных парадигм.

В общем, это очередная разновидность доказательства «Leetcode не нужен», но уже более прогрессивное «знать, что такое HTTP/2 — лишнее».

QUIC расшифровывается «Quiq UDP internter connection»

Ну не ваше нести ликбез в массы, не ваше это.

Кто хочет, кому надо - разберется. А 99% это просто не нужно.

Не разберется без досконально изученного фундамента. Сам я «парень от сохи», начинал с поверхностного ознакомления с фреймворками. И эти сказки про «99% не нужно» мне не нравятся, они лживые и вредные.

Что такое программирование без понимания азов, мне известно на собственной шкуре, когда весь мир вокруг пронизан «магией», и не понятно, что и как происходит. И продуктивность тоже известна. Поэтому я с таким уважением отношусь к истории UNIX и академической теории. Эта теория позволяет за день разобраться в новой технологии которая подключается к реальному проекту.

И в принципе, по этому я прощаю Столярову все его выходки: он дает основополагающий фундамент для новичков.

Вы втираете какую-то дичь. Образованный человек, он на то и образованный, чтобы делать то, что от него требуется. Если начался оверинжиниринг, значит, человек не образован в области культуры написания кода и дизайна приложения.

Реальный мир состоит из людей которые не могут всего знать хорошо. Пойнт - вместо того, чтобы приобретать знания которые хорошо если в 1% задач потребуются нужно приобретать знания которые нужны хотя бы в 80% задач (и учиться думать, но с этим совсем грустно в целом).

Полиглотами становятся не от зубрежки, а от досконального понимания абстракций, из которых состоят языки программирования: массивы, интерфейсы, first-class functions и так далее, а также основных парадигм.

Полиглоты не нужны, нужны профессионалы. Вот тред про веб. А в вебе гигантское кол-во кода без ООП даже, про фпп вообще молчу. И полезно людям знать не QUIC, а что запрос в 10500 джойнов будет медленно работать или и навык прикидывания, будет этот запрос медленным или быстрым, или когда стоит кешировать, а когда можно и забить.

Вот придет новичок в тред через полгода, почитает и такой - пойду разбираться как QUIC работает. Вместо того, чтобы sql подтянуть, разобраться зачем нужен инмемори кеш, когда нужно поставить очередь сообщений или почему для коллбеков обязательно нужно ретрай полиси делать. Подумает же - о сколько про QUIC обсуждают, ну точно спросят значит. А это бред и надо ребят которые такое спрашивают у разраба (не DevOps/SRE или тех лида) отправлять куда подальше (напомню, что я пишу это только про разработчиков, не про лидов и не про ops’ов).

Вот так спрашиваешь, продолжите ряд: бело-оранжевый, оранжевый, бело-зеленый, синий… А в ответ тишина и чистые, пустые глаза. При этом в резюме 15+ лет в ИТ.

По вашему мнению работа в ИТ должна в обязательном порядке включать в себя обжим витухи?

А в вебе гигантское кол-во кода без ООП даже, про фпп вообще молчу.

Дальше можно не читать.

Вот придет новичок в тред через полгода, почитает и такой - пойду разбираться как QUIC работает.

Не передгивайте, как QUIC работает разбираться не надо, тут самые базовые определения. Самых базовых протоколов веба.

Не разберется без досконально изученного фундамента. Сам я «парень от сохи», начинал с поверхностного ознакомления с фреймворками. И эти сказки про «99% не нужно» мне не нравятся, они лживые и вредные.

В скольки серверах настраивал QUIC специально?

Это никакие не азы, это специфичный нюанс работы веб сервера (как включение и выключение TLS 1.3 в современных реалиях).

Не нужно рассказывать сказки, в разработке с QUIC можно столкнуться в очень специфических условиях. Эта штука которая работает в окружении, а не в веб сервере в подавляющем большинстве случаев.

Проверил себя сам, проверьте себя и вы.

Я, конечно, посмотрел спойлеры, но запоминать я это не хочу.

В скольки серверах настраивал QUIC специально?

Вы передергиваете. В треде описываются базовые определения по версиям протокола HTTP. Вы ведете разговор так, как-будто программиста просят начерить cхему UDP дейтограммы побайтно.

Не нужно рассказывать сказки, в разработке с QUIC можно столкнуться в очень специфических условиях.

Точно также как и TCP, надеюсь вы не будете спорить, что понимание стека TCP/IP необходимо бекендеру.

Кто хочет, кому надо - разберется. А 99% это просто не нужно. Всегда офигевал от пары экранов требований к разработчикам - типа это минимальные знания, а, по факту, формочки на php или java клепать нужно.

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

По вашему мнению работа в ИТ должна в обязательном порядке включать в себя обжим витухи?

Если у человека в резюме 15+ лет опыта и первые места работы еще «сисадмин в бла бла бла», то незнание того что это выглядит немного странно, не находите? Это базовая проверка того насколько сильно человек приукрасил свое резюме, у специалиста вообще не будет проблем с ответом на этот вопрос.

Это вопрос не для джаваскриптизеров.

Вот придет новичок в тред через полгода, почитает и такой - пойду разбираться как QUIC работает.

Новичок через пол года еле-еле будет писать цикл for. А человек на уровне выпускника техникума/вуза, т.е. 3-4 года опыта, уже должен (прежде всего самоу себе) прекрасно ориентироваться в общих схемах базовых протоколов.

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

И он это должен знать, чтобы понимать что ему в управляющем софте пишет. Например, если что-то забивает сеть - нужно понимать как искать, что должно быть запущено, а что нет, что генерит трафик и тд. Для них это база. Повторюсь - я про разработчиков говорю, не про *ops’ов.

Повторюсь - я про разработчиков говорю, не про *ops’ов.

Вообще-то DevOPS т.е. SRE ни чем от разработчика по базовой подготовке не отличается. SRE это разработчик который занимается настройкой внутренних механизмов компании.

Тем более минимально различия между SRE и BackEnd девелопером, их практически нет.

Тем более минимально различия между SRE и BackEnd девелопером, их практически нет.

Они гигантские. Вообще разные области знаний. Из общего - знание языка программирование какого-нибудь.

Точно также как и TCP, надеюсь вы не будете спорить, что понимание стека TCP/IP необходимо бекендеру.

Всё зависит от того, что подразумевается под бэкендером, имхо в большинстве случаев это не нужно.

Они гигантские. Вообще разные области знаний. Из общего - знание языка программирование какого-нибудь.

Конкретезируйте, в чем они гиганские?

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

Но фактически, там где изобретен термин SRE и в комапниях сопоставимого масштаба и квалификации сотрудников - различий нет.

https://sre.google/sre-book/introduction/

What exactly is Site Reliability Engineering, as it has come to be defined at Google? My explanation is simple: SRE is what happens when you ask a software engineer to design an operations team.

In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s)