LINUX.ORG.RU
ФорумAdmin

Потери при POST запросе

 , ,


0

2

Добрый день. Сразу предупрежу, я не очень опытный, сильно не пинайте) Пробелма следующая: Есть VPS сервер в Германии, при отправке POST запросов с своего домашнего провайдера (СПБ - Ростелеком) примерно в половине случаев они отваливаются по таймауту curl: (28) Failed to connect to xxx port 80 after 21014 ms: Couldn’t connect to server

При этом во второй половине случаев они успешно доставляются и сервер на них отвечает.

Если запрос отваливается по таймауту - то на сервере в логах апача нет никаких следов коннекта (т.е. до сервера вероятнее всего запрос не доходит)

При этом GET запросы доходят до сервера в 100% случаев (ошибок с этим нету)

Пробовал на фоне запускать ping -t - посмотреть есть ли анамалии в момент когда POST запросы теряются - никаких аномалий нет (потерь нет, пинг стабилен)

Запущенная на фоне ssh сессия тоже не рвётся.

Если переключится на другого провайдера - пробелма пропадает. Если на Ростелекоме подключится к соседнему серверу по VPN - то тоже запросы корректно доходят (до проблемного сервера)

Т.е. вероятнее всего кто то по пути режет запрос Вопросы от нуба:

  1. Почему только POST запросы отваливаются? (а всё остальное норм работает)
  2. Почему только половина запросов отваливается? (запросы одинаковые)
  3. И самое главное: Можно ли как то отследить на каком этапе (скачке) «зависает» post запрос? (по типу tracert-а но только для post запроса)

Весь день гуглил, ответ не нашёл (хотя может не там искал)

Попробуй поднять у себя на VPS https и делать POST через него. Может провайдер фильтрует запросы, когда они идут открытым текстом.

masa
()

Проверь tcpdump-ом что он и куда шлёт и найди разницу между всегда работающими запросами и этими POST-ами.

(28) Failed to connect to xxx port 80 after 21014 ms: Couldn’t connect to server

Эта ошибка означает таймаут подключения на tcp-уровне, никаких GET/POST там ещё к этому времени нет и отличить их на этом этапе нельзя. Вероятно, ты GET и POST шлёшь разным софтом и он как-то по-разному подключается.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Можно ли как то отследить на каком этапе (скачке) «зависает» post запрос? (по типу tracert-а но только для post запроса)

traceroute умеет использовать вместо пингов TCP SYN (ключ -T), или даже полностью устанавливать TCP-соединение (-M tcpconn)

annulen ★★★★★
()

При этом GET запросы доходят до сервера в 100% случаев (ошибок с этим нету)

Судя по ошибке, вам просто повезло — GET’ы тоже должны работать только временами: у вас не устанавливается соединение с портом, которое происходит еще до отправки какого-либо запроса.

Трафик, случаем, не через Мегафон транзитом идёт?

В трёх случах из трёх проблема появляется при транзите трафика через Мегафон Поволжье/Волга. Последние хопы с трёх каналов: 83.169.204.90 и 85.26.205.119.

https://ntc.party/t/3-tcp-udp/4680/7
https://ntc.party/t/3-tcp-udp/4680/31

ValdikSS ★★★★★
()
Последнее исправление: ValdikSS (всего исправлений: 1)
Ответ на: комментарий от firkax

Да, действительно GET запросы тоже отваливаются

tcpdump-ом не очень понятно на что смотреть с помощью curl отправляю один и тот же запрос, каждую секунду в цикле 10 проходит потом 10 не проходит (в выводе tcpdump-а меняется только порт у моего компа с которого соединение устаналивается) в эту соторону копать?

можно как то отправить GET запрос, чтобы соединение (на ПК отправления) на заданном порте установилось? (или не этом проблема?)

JohnnyHazz
() автор топика
Ответ на: комментарий от JohnnyHazz

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

К сожалению провадера сменить не удасться (пока что) Хочу всё таки найти причину (виновника) ошибки

запутил трасировку по tcp - и сколько бы раз я её не запускал - она всегда проходит корректно

единсвенная разница которую вижу с «обычными» tcp запросами: трасировка идёт с портов 10000-40000 (не поднимаясь выше 40к порта) а curl идёт на 56000-61000 портах (так же не выходя с этих пределов)

можно как то curl-у задать другие начальные порты? (или может быть как-то трасировку именно на этих портах запустить?)

JohnnyHazz
() автор топика
Ответ на: комментарий от imul

mss 1460 (у трасировки, и обычного тестового GET запроса (с которым есть пробелмы)

не разобрался, можно ли тут размещать картинки, но вот: https://ibb.co/nDpmpgH

красным выделил трасировку (проходит корректно)

синим выделил проблемный GET запрос (отвалился по таймауту)

зелёным выделил тот же самый GET запрос (который дошёл корректно)

JohnnyHazz
() автор топика