While building a toy HTTP server, it is possible to easily identify things that can impact its performance: how we read a file and send it through a socket is one of those things. There are many, many more variables to that equation if we are dealing with a real world server, but we at least get the basics right while we have only a toy server.
The use of packets in the TCP/IP connection made possible for multiple transfers of data to happen at the same time. A packet is very small and so many of them can be transferred on the same wire. And, of course, servers can accept more than one connection at a time. This is often done with the use of Threads.
Understanding how to develop a server that is able to receive a simple GET request and send a simple response is relatively easy. There are tons of good resources to help us with that. Testing the server is the most difficult part.
The server has a socket that listens for connections at a port of a given number. When that socket is created and bound to a port, it starts accepting connections. It does it by creating yet another socket, that will process requests and responses. Wait. What?
In the Internet Protocol Suite (TCP/IP — subject of the previous post), the application layer on the client side writes to a stream that is then passed to the transport layer. On the server side, the layer reads from a stream after data is reassembled by the transport layer. But what is that stream thing?