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 запроса)

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

Ответ простой. Всем конторам в РФ указано в iptables исключить забугорные IP Кроме конечно веба.

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

Попробуй поднять у себя на 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 ★★★★★
()
Ответ на: комментарий от annulen

ipref хорошая штука. Я два раза предьявлял претензии к ростелекому от его показаний. Показывает где идет затык по определенному порту.

Boatmen
()

При этом 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
() автор топика

Понизить MSS не пробовали?

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

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

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

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

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

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

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

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

Так размеры пакетов-то какие? Выше про mss хороший совет дали, может на каком-то промежуточном узле проблемы с фрагментацией.

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

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

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

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

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

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

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

У трассировки ещё window другое (win+wscale). Как менять его (и порты) в курле не знаю.

firkax ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.