У меня возникли проблемы с пониманием того, как работает HTTP, когда несколько запросов отправляются параллельно (до получения ответа). Есть два случая:
1) С Connection: Keep-Alive.
Согласно спецификации HTTP:
Клиент, поддерживающий постоянные соединения, МОЖЕТ «конвейерно» передавать свои запросы (т. е. отправлять несколько запросов, не дожидаясь каждого ответа). Сервер ДОЛЖЕН отправлять свои ответы на эти запросы в том же порядке, в котором они были получены.
Такой способ кажется довольно сложным для реализации и обслуживания. Сервер должен отслеживать порядок запросов и отвечать в правильном порядке. Мало того, что это может быть непросто реализовать, но это удар по производительности: быстрые запросы должны ждать, пока не будут обработаны медленные запросы, если они были отправлены позже.
Кроме того, если мы говорим о балансировщике нагрузки, то прокси должен отслеживать, какой запрос был отправлен на какой сервер, чтобы, когда они возвращаются, он мог поставить их в очередь и ответить по порядку. Так почему бы не сделать это в первую очередь? т.е. звучит естественнее и проще, если клиент помещает (например) заголовок ID, сервер обрабатывает запрос и отвечает тем же заголовком ID, чтобы клиент мог сопоставить запрос с ответом. Это намного проще реализовать, и это не создает проблем с очередями запросов (клиент может отслеживать порядок запросов, если это необходимо).
Итак, вопрос: в чем причина указывать конвейерную обработку именно так, как она была указана?
2) Без Connection: Keep-Alive.
Я не смог найти никакой информации об этом случае. Допустим, клиент отправляет два запроса A и B. Без поддержки активности сервер закроет соединение после обработки запроса. Это, очевидно, вводит состояние гонки. Так как же он должен себя вести? Должен ли он отклонить второй запрос?
