For instance, when connecting to a webserver on a given port, is it up to the kernel to take packets of data and assemble them into ... streams (? - not sure about the correct term here) that the server can then read and process? For some time I had the incorrect idea that a connection to a webserver would ultimately get its own port on the server side. In reality the only port that is randomly assigned is on the client side (from what I understand).
Based on the above, when a server does not use threading to process multiple incoming streams (?), the kernel is, I guess, buffering up data from multiple clients while waiting for the server process to read and process the one stream the kernel has assembled for it?
Or I am still completely a dunce about how this works and the above is still wildly incorrect. I would like to better understand but honestly I don't know where to start.
On a very low level even on a threaded server that can receive and process multiple HTTP requests how exactly is the incoming data on the single server socket turned into something that each thread uses for a particular client? Especially in the context of something like http smuggling... I just don't understand the fundamental mechanism of multiple tcp connects on a single server port are turned into individual http requests... With http smuggling it makes it sound like all of the data is actually just a single stream. But if that is the case, how does threaded processing of http requests even happen?