@Nikolay37

Почему GET запрос быстрее POST?

Отправляю 2 одинаковых запроса на сайт, один в виде GET, другой POST (один в виде строки (подразумевается ссылка), другой - с form data) В итоге быстрее ответ приходит на GET. Какую опасность представляет GET запрос, если в ссылке есть важные данные?
  • Вопрос задан
  • 1780 просмотров
Решения вопроса 1
@MadridianFox
Web-программист, многостаночник
А как вы измеряли скорость ответа?
Если вы не написали бенчмарк, который на сотне тысяч итераций доказывает что один метод быстрее другого, то разница во времени ответа может быть случайностью.
Важен ещё способ получения времени ответа, ведь можно измерять как время обработки запроса сервером, так и полное время отправки и получения ответа.

Вообще чисто теоретически разница в скорости может происходить из того факта, что методом POST данные отправляются в другом виде, соответственно может быть затрачено разное время на формирование запроса, на отправку большего объёма данных и на чтение данных на сервере.
Ну например, данные закодированные в multipart/form-data однозначно по размеру больше чем в query string.

Но даже если допустить, что POST реально медленнее, то это не повод отказываться от него в пользу GET.
Это какая-то преждевременная оптимизация получается. Какая там разница? 10 миллисекунд какие-нибудь? Для вас это настолько критично? Никто и не заметит. Вот когда упрётесь в скорость ответа, и когда эта небольшая разница будет решающей, тогда можно будет задуматься.

Про важные данные - опасность есть ровно одна - те данные, которые указаны в query string вашего запроса, они попадут в историю браузера, в логи разных серверов, которые передают данные.
Например вы отправляете форму входа методом GET.
Ну и что что у пользователя в адресной строке мелькнёт его пароль - он же сам его и ввёл. А вот на сервере в логах apache или nginx появится строчка типа /login?user=vasya&pass=12345
Само по себе это не очень страшно - ну логи, чё мне с них, у меня вся БД с пользователями под рукой.
Но если кто-то найдёт уязвимость на вашем сайте и как-то прочитает логи, то будет плохо.
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
Robur
@Robur
Знаю больше чем это необходимо
видимо этот конкретный сервер get обрабатывает быстрее чем post, почему- кто ж знает.
Вообще get и post это два совершенно несвязанных запроса, даже по одному урлу и они могут делать абсолютно разные вещи.

Какую опасность представляет GET запрос, если в ссылке есть важные данные?

ссылки могут сохраняться во всевозможных логах и кешах, в случае с post данные обычно передаются в теле запроса и чаще всего никуда не сохраняется, в случае с get вероятность больше.
Надо понимать что если вы с post что-то передаете в ссылке - то проблемы все те же самые что с get.
Если хотите важные данные передавать, то post+https.
Ответ написан
melodyn
@melodyn
Лучше нативная смерть, чем фреймворковая жизнь.
1. Вероятно, form-data передаёт больше данных, чем просто строка;
2. Возможно, на сервере механизм обработки get проще, чем post;
3. А у вас настолько высоконагруженный проект и это самое узкое место в системе? optimization.guide
Ответ написан
@floydback
Скорость выполнения http запроса не зависит от того, get он или post. Вы либо передаёте разные данные, и от этого разная скорость, либо на бекенде какая-то разная логика обработки для разных запросов.
Ответ написан
@Vitsliputsli
А какова разница? В цифрах.
Post обычно подразумевает отправку данных в теле, а get в адресе. В принципе на размер запроса это не особо влияло бы, но обычно данные шлют в формате form-data, и используют громадные разделители, поэтому запрос в лёгкую может вырасти раза в 2 по сравнению с get. Второй момент, на другой стороне это все нужно ещё распарсить. Но, конечно, совсем не обязательно данные передавать как form-data.
Т.е. теоретически - да, post медленней, практически - не думаю, что эта разница сколько-нибудь существенна. И как правильно заметили, адрес не предназначен для передачи конфиденциальных данных, т.к. попадает в логи.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы