Телеграмм чат группы qa

Скорее стримом, но да

17:07пожаловаться #1

Wazicar in QA — Load & Performance

Или там другим чем

17:07пожаловаться #2

а, ну да

17:07пожаловаться #3

ну а после передачи соединение закрывается

17:07пожаловаться #4

я это в целом и имел ввиду

17:07пожаловаться #5

Wazicar in QA — Load & Performance

17:07пожаловаться #6

Через ~20 секунда где-то

17:07пожаловаться #7

А тот же браузер, потом не сможет переиспользовать это соединение для другого запроса?

17:07пожаловаться #8

Если есть Keep Alive хедер

17:07пожаловаться #9

Без него тушит сразу

17:08пожаловаться #10

Да все верно.

17:08пожаловаться #11

С ним

17:08пожаловаться #12

Artem Rozhkov

А тот же браузер, потом не сможет переиспользовать это соединение для другого запроса?

это вроде так не работает, если верить RFC

Ιωάννης Τσεκούρι in QA — Load & Performance

17:08пожаловаться #13

ΙΤ

Anton Kramarev

Без него тушит сразу

в 1.1 должно соединение же оставаться

17:08пожаловаться #14

может вы имеете виду WS?

17:08пожаловаться #15

Тогда вопрос. Запросы браузер шлёт последовательно в соединение или может не дожидаясь ответов ещё запулить запрос?

17:09пожаловаться #16

второе

Ιωάννης Τσεκούρι in QA — Load & Performance

17:10пожаловаться #17

ΙΤ

https://tools.ietf.org/html/rfc7230#section-6.3

17:10пожаловаться #18

если только это не тотже самый ресурс, на один и тотже ресурс он не будет слать паралельный запрос, только если это логикой фронтовой не прописано

17:11пожаловаться #19

в целом вы же можите глянуть по вотерфолу в браузерном нетворкинге, как че у вас там запрашивается и в какой момент