LINUX.ORG.RU

http запрос


0

1

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

Ответ на: комментарий от anonimous

Это такой интерфейс общения между программами и процессами, в рамках операционной системы.

Ну а если не ёрничать - задачу вы поставили как-то слишком некорректно.

запрос не открывая порт

в это время слушает порт

В речи это оксюморон, если мне не изменяет память.

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

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

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

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

UPD: прочитал заголовок... Почему нельзя порт открывать? Отловить его сложно - пока будешь сканировать открытый на время передачи порт для небольшого количества данных, он уже сменится

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

Почему нельзя порт открывать

Потому что я пытаюсь реализовать что-то вроде сканера диапазона адресов на предмет существования. Я пытался реализовать с помошью Curl, но операционка не дает открыть сразу много экземпляров, приходится ограничиваться пятью (примерно) одновременно запущеных. Слишком медленно происходит сканирование.

anonimous ()

сделать HTTP - запрос не открывая порт
одна программа отсылает запрос, а другая в это время слушает порт и принимает ответ

?? Это что-то из разряда "пожарить яичницу, не разбив яйца"?

Anon ()

если в рамках локального компьютера, то может и можно, однако и клиент и сервер должны быть «подключены» к unix сокету или вообще работать через pipe в консоле, однако в рамках tcp/ip это разумеется невозможно, поскольку чтобы началась передача чего-либо поверх tcp/udp надо для начала установить соединение.

сделать HTTP - запрос не открывая порт

вы наверно имели в виду «не открывая соединение», на серверной стороне порт всегда открыт и слушается веб сервером, на клиентской стороне порт никто не открывает, на клиентской стороне инициируется открытие соединения.

IvanR ★★★ ()
Последнее исправление: IvanR (всего исправлений: 2)
Ответ на: комментарий от minakov

Почему нельзя порт открывать?

Если он не откроет порт, хрена с два он приконнектится ☺

Помню, когда-то давно я долго мучился, пытаясь понять, почему у меня мультикасты не проходят. Пока не почитал матчасть и не пофиксил iptables.

Anon ()

неважно, установлено соединение или нет, важно только удостовериться что сервер вернул 200

Чтобы сервер вернул тебе 200 (перед этим выслушав твой GET|POST|HEAD|Whatever), тебе нужно установить с ним соединение. Тисипи, как говорят французы.

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

важно только удостовериться что сервер вернул 200, дальше можно выйти

Тебе нужен HTTP метод HEAD. Это как GET, но сервер возвращает только заголовок, без тела.

i-rinat ★★★★★ ()
Ответ на: комментарий от anonimous

Я так понимаю/предполагаю, что в низкоуровневом запросе к серверу есть информация, на какой порт отсылать ответ. И я подумал, что теоритически можно было бы построить такую модель: прога открывает порт, слушает его, а другая прога «знает», какой порт слушает первая и отсылает запрос к серверу с «просьбой» отослать ответ на этот самый порт, и не дожидаяь ответа посылает запрос следующему серверу, а та, первая, считывает ответы тем временем. Тут еще наверное, нужно как то организовывать очередь ответов, ведь они могут приходить асинхронно. Вот и спросил, возможна ли такая модель?

anonimous ()
Ответ на: комментарий от thesis

Чтобы сервер вернул тебе 200 (перед этим выслушав твой GET|POST|HEAD|Whatever), тебе нужно установить с ним соединение. Тисипи, как говорят французы.

Спасибо большое, значит это невозможно. Огромное спасибо, ответ прямо в точку.
и благодарю всех откликнувшихся!

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

А мне надо чтобы одна прога отправила запрос (для этого ведь порт открывать не нужно? какими средствами отправляется запрос?) и ушла.

Клиент тоже открывает порт на который он потом получает ответ сервера, просто этот порт берется рандомно.
До отправки http запроса у тебя еще происходит установление tcp соединение. Что то типо:
Клиент: привет
Сервер: привет
Клиент: походу соединение надежное, начинаю отправку данных
Клиент: http запрос.

В этом принципиальное отличие tcp от udp.

Потому что я пытаюсь реализовать что-то вроде сканера диапазона адресов на предмет существования. Я пытался реализовать с помошью Curl, но операционка не дает открыть сразу много экземпляров

Чем nmap не подходит? И с чего ты взял что ОС не дает открыть больше 5 курлов?
Если запросы не сложные, без всяких там shttp то забей на курл и делай через сокеты, http протокол это обычный текст, к веб серверу хоть по телнету можно подключаться.

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

Чем nmap не подходит

nmap я пробовал, мощная штука, но разве он может вернуть 200? он жа просто сканирует порты.

И с чего ты взял что ОС не дает открыть больше 5 курлов?

Я не помню там пять или больше, но на каком то количестве вылетала ошибка: слишком много открытых портов или процессов чтоли.

Если запросы не сложные, без всяких там shttp то забей на курл и делай через сокеты, http протокол это обычный текст, к веб серверу хоть по телнету можно подключаться.

Да наверное нужно смотреть в эту сторону. Я думаю что основные тормоза тут как раз в этом рукопожатии, неизбежное зло, пока ожидается ответ, процесс висит, а то бы можно было производить сканирование асинхронно с фантастической скоростью. Спасибо за ответ!

anonimous ()
Ответ на: комментарий от i-rinat

Только HEAD может возвращать не то что GET и вообще может не поддерживаться. Потому я бы HEAD не рекомендовал.

invy ★★★★★ ()
Ответ на: комментарий от i-rinat

Тебе нужен HTTP метод HEAD

Да это не важно вообще. Я же говорю, основные тормоза в ожидании ответа, а текст и так быстро передается, там существенной разницы не будет

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

Я же говорю, основные тормоза в ожидании ответа

Запускай запросы в отдельных нитях. Или делай как в nginx/lighttpd, обработкой сокетов пачками.

i-rinat ★★★★★ ()
Ответ на: комментарий от Anon

Дело во взаимном несоответствии вопросов. Вроде локальный софт, для которого порты и не нужны, а вроде и http. Хотя хз нужно ли для петли порты дергать - я профан тут

minakov ★★★★★ ()
Ответ на: комментарий от i-rinat

Запускай запросы в отдельных нитях

Есть же ограничение на количество нитей. Я хотел сделать полностью асинхронную реализацию чтобы ни один запрос не дожидался ответа. А обработка пачками не решит ничего, потому что все равно ограничение на кол-во пр-ссов. вся соль в том чтобы выкинуть ожидание, рукопожатие.

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

Спасибо большое, значит это невозможно.

Нда, и все же меня терзают сомнения, ведь аджакс как-то отсылает асинхронные запросы.

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

В данном контексте слово «асинхронный» вообще не о том. Это только для браузера этот запрос «асинхронный» (имеется в виду «не влекущий одновременное перерисовывание содержимого вкладки»), а в остальном - совершенно обычный обмен в рамках ранее установленного TCP-соединения (см. http://en.wikipedia.org/wiki/HTTP_persistent_connection и до кучи http://en.wikipedia.org/wiki/HTTP_pipelining, оно хоть и не про твою задачу, но знаний добавит).

Вся эта красота не отменяет необходимости осуществления TCP Handshake.
Пакет с огрызком HTTP вне установленного ранее TCP соединения будет проигнорирован стеком машины, на которой работает сервер, и до самого сервера (демона) вообще не дойдет.

Нельзя гонять протокол, работающий поверх TCP, игнорируя правила работы TCP. Все просто.

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

Спасибо. Значит надежды нет. А я блин, уже запостил тему про аджакс в вебдевелопмент. Поспешил мальца. А это что же получается, браузер средствами ОС устанавливает соединение при каждом аджакс запросе, значит обращение к ОС осуществляются в порядке очереди? Или нитями? Если нитями, получается, что возможна ошибка макс кол-ва одновременных соединений?

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

получается, что возможна ошибка макс кол-ва одновременных соединений?

Я ж написал: «в рамках ранее установленного TCP-соединения». Лимиты могут вылезти, когда ты захочешь гонять запросы к куче серверов разом.
Ну то есть как у тебя оно и обстоит.

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

А обработка пачками не решит ничего, потому что все равно ограничение на кол-во пр-ссов.

Настроенный nginx держит десятки (а то и сотни) тысяч запросов в секунду. Естественно они пересекаются по времени, и одновременно могут быть активны тысячи соединений. И всё одним процессом с одной нитью. Так что решит. Просто сделать аналог может оказаться нетривиальной задачей.

i-rinat ★★★★★ ()
Ответ на: комментарий от thesis

Понял спасибо, больше не буду бестолковиться. Извините еще раз.

anonimous ()
Ответ на: комментарий от fmap

работающий поверх TCP
работающий поверх TCP
работающий поверх TCP

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

Если не нужна проверка целостности, вроде UDP есть

Не, мне нужна проверка ответа сервера: 200 или нет.

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

Чтобы получить данные по tcp, по http, работающему поверх tcp, нужно установит содинение. Не обязательно для каждого соединения запускать свой curl, можно из одной программы установить кучу соединений, причём устанавливать их в не блокирующемся режиме, что соединения устанавливаются параллельно во времени, но это нужно самому писать код, достаточно много.

Ещё можно, приняв тяжёлые вещества, написать стек tcp в user-space, но это ещё больше кода.

Судя по вашим вопросам, вам нужно долго учить матчасть, прежде чем писать подобных код. Программирование на Си, man 2 connect, man 2 select.

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

Судя по вашим вопросам, вам нужно долго учить матчасть, прежде чем писать подобных код

Да, все так, и при этом я все равно не достигну главной цели - асинхронности запросов-ответов.

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

Вы настолько не уверены в себе, что не верите, что сможете написать работающую программу на Си?

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

Да, я си не знаю, и я так понял, что асинхронная реализация в принципе невозможна. Или я ошибаюсь? Если возможна, то как это должно выглядеть? Возможно я найду обходные пути, если пойму принцип возможной реализации.

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

Я не знаю, асинхронная это или нет, но возможно такая реализация. Приложение делает, допустим, 1000 сокетов в неблокирующемся режиме, всем им «одновременно» командует установить соединение, потом через select() отслеживает за именением состояни этих сокетов, пишет запросы и читает ответы. Пока один сокет находится в состоянии установления соединения, в другой может писаться запрос.

А так, я ещё добавлю, что отправляя запрос нужно всегда расчитывать на получении ответа, и запрос и ответ это пакеты/байты, поэтому нельзя просто так фигачить запросы с бесконечной скоростью, нужно думать, чтобы ответы успевали пролазить в канал ограниченной ширины. А, если это ещё запросы к одному серверу, то вобще можно бан по ip получить.

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

Спасибо большое, я подумаю над этим. Сейчас уже голова не соображает чтобы осмыслить.

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

Есть же ограничение на количество нитей.

Я непонимаю откуда ты берешь все эти ограничения? Программа работает под линуксом или виндой? Если под линуксом то попробуй запускать из под рута.

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

Какая нахрен асинхронная реализация - выкинь это говно, ибо это всё «ассинхронщина» уровня питушарского недовеба - тебе уже об этом выше сказали.

Что возможно? Попинать каждый порт? Да. Заслать гет и получить ответ? Тоже. Это строчек 50-100 лапши на сишке - иди осиливай.

То, что тебе пацаны рассказываю, типа вебсервер много кода и прочее - не слушай, ибо они анскильные. В их тормазных говнонгинксах 0.1% строк «вебсервера» - остальное - это http кастыли и прочее говно.

Тебе же на это класть - поклади.

anonymous ()

Начнем с простого - что ты понимаешь под открытием порта?

PS. Если забыть про хттп, то просканировать порты на удаленных машинах можно через RAW сокеты. Эта штука позволяет писать данные напрямую в эзернет. Т.е шлешь сразу много пакетов tcp с syn флагом и ждешь реакции.

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

началась передача чего-либо поверх tcp/udp надо для начала установить соединение.

udp

установить соединение

Что для udp значит установить соединение?

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