A stream is also intended to be read from a data source, as yet not all data has been received. This applies to Request.InputStream . Others, such as MemoryStream , directly carry a buffer in memory.
Where exactly the data is stored depends on the type of stream. At the Socket level, there is a buffer where the data can be stored until it is read, or perhaps IIS will buffer it for you.
The buffer is deleted when you (or .NET in this case) destroy Stream, or when the garbage collector does it for you. The socket layer, of course, only frees its buffer after the connection is closed. Disposing a stream does not always delete the underlying buffer.
Streams are designed so that you can work with this - a Stream data - without having to worry about basic buffers. A general rule for those responsible for deleting a stream is: Do you create one? You dispose of it.
In response to your changes: if you store the stream in a variable, for example, in an ASP.NET session, .NET will destroy the stream anyway if the Request object is no longer needed. Your variable will still contain a reference to this stream, but reading from it will raise an ObjectDisposedException .
Pay attention to the difference between Stream and the buffer - a Stream provides access to read and / or write to any type of buffer - even a virtual buffer containing "data that has not yet been received. Attempting to read from this buffer blocks the current stream until (some of) the data will not be received (or until an error occurs).
And to complete the confusion, you can have a stream that reads from multiple buffers, multiple threads read from the same buffer, and stream flows around it.