You'll never know everything, and I think it's ok to have a high-level understanding of these things until you actually need more detail to solve a real problem (it's hard to learn the real nitty-gritty stuff without a concrete problem to apply it to anyway).

To take the topics you mentioned as examples, probably this is about as much as you need to know off the top of your head until proven otherwise:

Marshalling/Unmarshalling--this is just about how you encode data structures as binary data to send over a network connection, and reconstruct them on the other end (IE, the data is converted to a "serialized" byte representation as opposed to a potentially non-contiguous representation in some data structure in the program memory). Think of it like, how do you convert a linked list or a hash map to some blob of bytes that you can send over a TCP connection, and how can the other end get back the original data structure from the blob. More important I think is the concept of IPC (inter-process communication), aka message passing, in general...marshaling data is usually an implementation detail some framework you're using has already solved for you.

Buffers - Some memory where you stick stuff temporarily before you actually copy/read it somewhere else. Buffers have uses in many contexts. One is to enable asynchronous behavior, where a queues is written to by 'producers' and read by 'consumers'; the queue lets you decouple reads and writes, so the writer doesn't have to 'block' waiting for the reader, and vice-versa. You can just write to the buffer and continue on, and the reader can read from the buffer at their leisure (within reason...the buffer can fill up).

Streams - This is an overloaded term that means a lot of things in a lot of different contexts so I think you'd need to be more specific.

So, see, that's not really a ton of high-level context. You can probably internalize that level of detail in 10 minutes. There's a lot of directions you could go in to follow these topics deeper of course, these explanations aren't ultimately satisfying...feel free to google around to satisfy your curiosity, but don't get existential about it. Again, you'll *always* have some layer that you haven't understood yet. If you just keep endlessly peeling back layers with no motivating context, you'll probably become overwhelmed and confused and ask yourself "when would I use this?", "why am I too dumb to see how this fits together?", etc...not productive and liable to make you feel bad. Probably better, when given a problem at work, to ask yourself "has this problem been solved before? If so, what are the best practices?". As you work on more interesting problems, you will naturally come into contact with these things if you can accurately define what challenges you're facing and seek out resources that address those challenges.