Resource: что из себя представляю потоки в php?

Question

[topuserman]

Хочу разобраться, что из себя представляют потоки (streams) в php.
Например, когда мы вызываем функцию fopen, то в результате мы получаем ресурс, который в себе содержит дескриптор файла, и далее мы уже можем работать с этим файлом не считывая его полностью в память.
Как я понимаю, через потоки.. но что это за потоки ? где именно про них почитать ? это какие-то механизмы операционной системы ?

В php очень много сущностей, которые работают с потоками.

Например при открытии socket-соединения - также получаем в ответ ресурс, и можем с ним работать как с потоками.

Тоже самое с функция работы с изображениями и т.д.

Неужели на техническом уровне - это все одни и те же потоки ?

А самое сложное, для понимания:
Очень часто http-клиенты ответы от запросов возвращают в виде потока данных.
Например, так регламентирует PSR-7: HTTP message interfaces.
основная идея этого подхода, чтобы весь ответ, который получает клиент не записывать сразу в память, а работать как с потоком.

Мне не понятно, где тогда хранится весь ответ клиента, если не в памяти ? Ведь запрос сделан и получен ответ - куда он делся? Создаётся какой-то временный файл на диске и возвращается тот же дескриптор ? Или все это время держится открытое соединение с сервером до тех пор, пока не будет все считано?

Ранее уже задавал подобный вопрос, но так и не разобрался.

Answer 1

[Ипатьев]

Я значительно переработал этот ответ, поскольку мне самому не нравились некоторые моменты плюс я обратил внимание на конкретные примеры из вопроса.

В первую очередь, не надо путать потоки как принцип, абстракцию, и потоки как конкретную реализацию этого принципа в виде механизма потоков в РНР. При этом даже в этой конкретной реализации есть много нюансов, которые не всегда очевидны. Скажем, врапперы в РНР можно разделить на встроенные и пользовательские. Причем даже встроенные могут значительно отличаться по своей реализации.

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

Вот даже здесь, поскольку fopen работает поверх абстракции, нельзя говорить о едином подходе.
Если у нас самый простой случай - локальный файл - то РНР оборачивает функции для работы с файлами языка С в свою собственную абстракцию. Но ниже - на уровне этих самых функций языка С - никаких потоков нет. Есть обращение к функциям операционной системы, которые просто позволяют прочитать выбранный кусок файла.
Тут никаких вопросов нет, всё честно - если мы прочитали из файла 5 килобайт - значит потратили ровно 5 килобайт памяти.
Но работаем мы с файлом не считывая его весь в память не потому что поток, а потому что так устроена файловая система. А поток этой возможностью только пользуется.

Если же мы открываем не файл, а URL, то РНР начинает извращаться, пытаясь предоставить те же самые инструменты, какие мы используем для работы с файлами, для доступа к ресурсам совершенно другого типа.
И здесь возможны нюансы. Я не знаю, как реализован HTTP wrapper, но в теории HTTP позволяет чтение произвольного объема данных через заголовок Range:. То есть РНР вполне может читать и из НТТР кусками, а не целиком.

В общем поток - это абстракция. Подход. Интерфейс. Способ работы с массивом информации не забирая её всю в память.
При этом реализация конкретного инструмента, использующего этот подход, может быть совершенно самостоятельной, никак с другими не связанной. Мне кажется, что именно этот момент является для вас камнем преткновения: на техническом уровне это совсем не обязательно одни и те же потоки. Но вполне могут быть.
При этом важно не смешивать сам поток и его получатель (получатель вполне может накапливать всю информацию из потока).

А упомянутый в вопросе PSR-7 вообще никакого отношения к потокам в РНР не имеет. Это совершенно отдельная реализация принципа потоков, которая не имеет отношения к потокам в РНР.

Answer 2

[ThunderCat]

Официальная дока же вполне нормально объясняет. Если коротко - это общий интерфейс к последовательному набору данных, который позволяет читать, писать и искать в этих данных (как в файле). И все это в едином стиле. Интерфейс такой, типа. Грубо говоря нечто вроде юниксовского подхода "все на свете это файл".

Мне не понятно, где тогда хранится весь ответ клиента, если не в памяти ?

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

Comments

[topuserman]

Официальная дока же вполне нормально объясняет.

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

В памяти конечно, но так как это оболочка над данными

тогда почему его используют http-клиенты чтобы все не держать в памяти ? если вы говорите, что они все равно в памяти будут.

[Ярослав Иванов]

Все файл? Не знал про это. А папки тоже файлы?

[ThunderCat]

Ярослав Иванов, https://en.wikipedia.org/wiki/Everything_is_a_file

[Ипатьев]

Ярослав Иванов, конечно. Уж к папкам-то какие вопросы? просто файл со списком других файлов. Вот "процесс - это файл" - тут репу почешешь.

[ThunderCat]

topuserman,

для меня какая-то черная магия, которая скрыта за интерфейсами. и из-за не полного понимая, не понимаю многих вещей связанных с потоками.

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

[Ипатьев]

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

[ThunderCat]

Ипатьев,

это, мне кажется, неверно.

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

[ThunderCat]

topuserman,

тогда почему его используют http-клиенты чтобы все не держать в памяти ? если вы говорите, что они все равно в памяти будут.

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

[topuserman]

ThunderCat, Ипатьев,
спасибо большое! многие прояснилось!

по http у меня все равно не понимание.
Для примера:

$ch = curl_init('https://promopult.ru/uploads/File/war_and_peace.txt');
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_exec($ch);
curl_close($ch);

Из-за того, что опция CURLOPT_RETURNTRANSFER по умолчанию = false, то данные сразу отдаются в поток вывода - STDOUT.

Из-за этого использования памяти составляет 0.4 мб.
Если попробовать записать этот результат в переменную, установив CURLOPT_RETURNTRANSFER = true, то использование памяти возрастает в разы.
до 4.5 мб..

Почему так получается ?
Т.е. делая http-запрос, php так или иначе получает ответ в виде headers + body, но куда они деваются, если не в память ? неужели, весь ответ сразу летит какой-нибудь временный файл, а потом уже происходит работа с ним ? но даже в таком случае, данные должны же где-то быть уже, ведь уже ответ от сервера пришел целиком.

[ThunderCat]

topuserman,

Из-за этого использования памяти составляет 0.4 мб.
Если попробовать записать этот результат в переменную, установив CURLOPT_RETURNTRANSFER = true, то использование памяти возрастит в разы.

Так оно в системной памяти лежит, а вы смотрите сколько скрипт съел. STDOUT он как бы не часть пхп...

[topuserman]

ThunderCat, спасибо!
понял, значит по сути в рамках сервера использование озу не меняется, просто меняется приложение, которое его использует.

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

[Ипатьев]

topuserman, вы определитесь, сразу отдаются в поток или происходит работа с ним :)

Если сразу уходит в поток, то РНР память не тратит, так же как не тратит, читая построчно обычный файл.

А если в пхп идёт какая-то работа, то разумеется, мы сначала сохраняем в переменную и имеем занятую память

[Ипатьев]

topuserman, да где ж он "держится"-то?
С чего вы вообще взяли, что что-то лежит в оперативке?
Если вы никак не используете данные, то они и места не занимают.

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

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

[Ипатьев]

topuserman,

ведь уже ответ от сервера пришел целиком.

ничего и никогда в компьютерах не бывает "целиком". В сети, например, как минимум всегда есть TCP пакет.

Сейчас вы ко всему прочему перепутали HTTР сервер, о котором говорили ранее, с НТТР клиентом.
У сервера - да, своя ситуация.

Но клиент, о котором вы говорите сейчас, curl, работает на более низком уровне. И ему никто не мешает обрабатывать данные по мере поступления. И когда мы говорим конкретно про curl (а не "http", как вы это называете, наваливая в кучу всё подряд - серверы, клиенты, конкретные реализации), эта библиотека выступает просто "насосом", перекачивая данные из источника в получатель. Насос может накачать бочку воды. Но это не значит, что насос должен быть размером с бочку.

Плюс вы смешали вместе сам curl и программу на РНР, которая её использует.

curl в любом случае выступает только насосом.
А дальнейшее поведение зависит от настроек:
- если данные перекачиваются с исходного сервера в файл на клиенте или, сразу передаются другому клиенту по сети, то разумеется, память не потребялется. ни curl-ом, ни РНР
- если РНР программа, использующая curl, хочет сохранить данные в своей памяти, то разумеется, РНР потребует память в размере получаемых данных. При этом сам curl так и останется насосом.

Я не понимаю, что можно не понять в этой простой схеме.