Устранение неполадок и анализ неполных параметров, иногда получаемых Tomcat при получении запросов POST

задняя часть

1 Описание проблемы

Недавно я участвовал в ежемесячной лотерейной деятельности, и параллельный объем также был намного выше, чем обычно.Сопутствующие проблемы - это некоторые проблемы, с которыми мы обычно не сталкиваемся. Это тоже приятно. Вы можете расти, только если у вас есть проблемы. Если у вас нет проблем, вы тратите свою жизнь впустую.

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

45 Обычный сбор параметров POST сервера приложений:

2016-05-19 15:45:15 INFO :request param : body=[{"appDevice":{"qdPlatform":"weixin","qdVersion":"1.4.1"},"activityId":80,"curPlanId":381,"memberId":"ff808081547ef0b401549f64e6cb2ecb","projectId":"31605061701144","prizeIds":[437,436,435,440,439,438],"planIds":[370,371,372,373,374,375,376,377,378,379,380,381,382]}]

45 Сервер приложений: неправильное получение параметра POST:

2016-05-19 16:03:16 INFO :request param : 7D,"activityId":80,"curPlanId":381,"memberId":"ff80808150f0fdd401510f83cae413a9","projectId":"708","prizeIds":[437,436,435,440,439,438][370,371,372,373,374,375,376,377,378,379,380,381,382][370,371,372,373,374,375,376,377,378,379,380,381,382]=[]

2 Устранение проблемы

Перед устранением проблемы сначала уточните архитектуру службы, как показано на рисунке:

理清服务架构

Прежде чем приступить к устранению неполадок, кратко сформулируйте несколько принципов самостоятельного устранения неполадок (только для справки):

  1. Воспроизведите проблему: сначала обязательно воспроизведите проблему Любая проблема, которую невозможно воспроизвести, не является проблемой. Точно так же любые существующие проблемы неизбежно повторятся снова.

  2. От ближнего к дальнему: сначала подтвердите, что нет проблем с вашим собственным кодом, а затем подтвердите, что нет проблем с внешним кодом (например: код фреймворка, сторонний код и т. д.).

  3. Снаружи внутрь: программа представляет собой IPO с вводом (например, параметры, среда и т. д.) и выводом (например, результаты, исключения и т. д.), вывод Out — это внешний вид проблемы, сначала подтвердите, что внешний фактор Ввод - нет проблем, а затем подтвердите Нет проблем с логикой программного кода.

  4. От мелкого к глубокому: на самом деле, от простого к сложному, сверху вниз, сначала проверьте проблемы из приложения верхнего уровня, такие как: API верхнего уровня, прикладной уровень, передача HTTP и т. д., а затем подтвердите базовое приложение для проверки проблем, таких как: API нижнего уровня, сетевой уровень, системный уровень, байт-код, JVM и т. д.;

  1. Подтвердите, есть ли проблема параллелизма или логическая ошибка в коде, выводимом приведенным выше журналом:
Map<String, String[]> parameterMap = request.getParameterMap();
Set<String> keySet = parameterMap.keySet();
StringBuilder sb = new StringBuilder();

for(String key : keySet) {
    sb.append(key).append("=").append(Arrays.toString(parameterMap.get(key))).append(",");
}

log.info("request param : " + sb.toString()) ;

На основе двух приведенных выше выходных данных журнала и анализа приведенного выше кода можно сделать следующие выводы:

  1. Приведенный выше код не имеет проблем параллелизма и логических ошибок.POST-параметры получены из исходного запроса.

  2. Судя по аномальному выводу лога и приведенной выше логике кода, в параметрах, полученных из request.getParameterMap(), ключ "body" утерян, а также частично утеряно значение value, а Key-Val в ParameterMap сбит с толку;

  1. Подтвердите, существует ли ограничение длины параметра tomcat POST/GET, ограничение длины параметра nginx POST/GET, что приводит к усечению параметра запроса:

Эта возможность была быстро исключена, так как неполные параметры генерировались спорадически.Если параметры запроса были усечены из-за ограничения длины параметра, это должно быть 100% проблема неполных параметров.

  1. В соответствии с приведенной выше схемой архитектуры службы и принципом снаружи внутрь, через tcpdump и Wireshark проанализировать, являются ли параметры запроса, поступающие на внешний сервер Nginx, неполными:

Wireshark抓包分析

Можно подтвердить, что параметры запроса POST были потеряны до того, как запрос пользователя будет отправлен из браузера в Nginx;

Примечание. Дополнительные сведения об использовании tcpdump и анализа Wireshark см.Разговор об анализе перехвата пакетов tcpdump и Wireshark.

3 Решение проблем

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

4 сводных вопроса

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

Категории