Делаю API для личного использования (не публичное). Страница обрабатывает запрос и отдаёт 0 или 1. Что бы не парсить страницу целиком можно поставить curl_setopt($main, CURLOPT_RETURNTRANSFER, 0); и получить только заголовки если я правильно помню... А можно ли отдающему скрипту поместить ответ в заголовок типа: header("YouRequest: 0");
И как этот заголовок считать принимающему скрипту если curl_getinfo получает только content_type, http_code, header_size т.е. не все.
Посчитайте количество символов. С отправкой тела ответа символов может быть столько же или даже меньше. Сравните листинги в чистом (текстовом) виде зайдя по telnet и сделав запрос вручную.
Oleg Shevelev: Олег что-то я не понял как именно на php вы предлагаете только к tcp обратится, ведь это сетевой протокол. Далее не понял совета про подсчёт количества символов. Зачем? Что он мне даст?
Oleg Shevelev: я о письме в заголовке. А о сокетах не хрена трудного. Главное понять как они работают на "нормальном" языке, а потом написать тоже под php пустяковое дело
1. на php что бы слушать сокет нужно создать сервер, а это тонна накладных расходов, задача отслеживать падения, отслеживать ресурсы и так далее - по этому я сразу сказал что это не простая задача и весь эффект может невилироваться.
2. с другой стороны если решить вопрос надёжности - появляется так же и постоянная память и сохранение контекста и прочие возможности запущенного приложения по сравнению с постоянно запускаемым и умираемым скриптом - но это уже очень сложная задача в рамках PHP, многие, кстати, её решают в той или иной степени в продакшине
3. http это тоже сетевой протокол
4. подсчёт символов даст вам ответ - есть ли польза от того что бы исключить тело ответа и ограничиться заголовками - вот тут вам уже точно нужно читать спецификацию протокола http и понять что разницы между заголовками и телом ответа нет никакого, и там и там текст, только заголовки в начале, а тело ответа в конце и между ними два перевода корретки и в общем-то вот и вся разница
5. curl - это библиотека которая работает с сокетом... убирая curl вы убираете прослойку, но все важные для бизнеса вещи (авторедирект, восстановления соединения, докачка и так далее) вам придётся дописать самому в зависимости от задачи.
Резюмируем:
- если задача сделать самый быстрый запрос и самый быстрый ответ
- если важно что бы передавалось минимум байтов через сеть
- если важно что бы не было лишних обменов пакетами
То:
- нужно смотреть на IP или TCP/IP (вам ведь UDP не нужен в данном случае)
- нужно понимать что PHP сам по себе медленный и скрипты при каждом запросе умирают
- нужно понимать что вам потребуется реально работающий сервер, а не скрипты
- нужно понимать что возможно вам больше подойдёт модуль к nginx который дёргает скрипты
- много всего ещё... хайлоад штука сложная. И почти никогда вам не смогу ничего подсказать другие - потому что точно таким же не занимаются.
safenoob: может им и не нужно?:) Естественный отбор:) Что бы сделать из этого полноценный ответ надо привести примеры, нужно так же указать модель взаимодействия клиента и сервера, например:
1. клиенты разные, подключаются, получают ответ, уходят, если заходят снова то работает кеш коннектов или keep-alive что по сути тоже самое, для https кеш хендшейков или вроде того (недавно попадалась статья на эту тему с Golang Meetup что был недавно в Москве в офисе Badoo)
2. клиенты известны, постоянные соединения, можно пулять 1 байт в одну сторону и 1 байт в другую... в самом лучшем случае, в худшем, делать echo где ответ будет содержать контрольный бит или сумму от запроса. Но так или иначе - это улучшит пропускную способность, весь вопрос в уровне надёжности и моделе использования.
При этом рассматривать что клиент или сервер будет на PHP - бессмысленно, разве что клиент на PHP, а сервер на чём-то другом более подходящем, хотя даже в этом случае есть куча других мест где в PHP можно тюнить.
Простой
