Network Protocols

Network Communication

It's important to understand how machines establish networks to communicate with one another. Here, we'll briefly discuss a general overview of how connections are created, and discuss them in the context of the HTTP protocol.

Application Layer

With HTTP being used as our example, a network protocol defines rules and conventions for communication between network devices. There can be many layers and parts to a protocol - the application layer, IP layer, TCP, UDP and sockets, to name a few. With the application layer using HTTP as our example, our browser (the Application Layer Program here) sends a “letter” or a request to a server based on a URL (Uniform Resource Locator) typed in. It may say “dear server, please send me this page that I’m requesting.” This is application to application communication - the browser may send specifications in its letter such as “give me some cookies info, like the login info we exchanged last time. Also, you can compress the files in this particular format, I can accept HTML or text…”. The server can then customize a response. The browser passes off the request to the operating system, which connects to the server. The OS makes a holding area called a “socket” where it places the server response upon receipt. The browser can look to the socket and read the response just like a file. 

IP Layer

For the OS to send off the browser request, it has to look up the IP address for the website using DNS. An IP address is how requests find their way to the right place - there are many requests using the same network lines at the same time. An IP packet is like a letter with an address and a return address. Once an OS has the IP address for the website, it puts the browser HTTP request in an IP packet to send it off - it is possible that the request is too big to fit in one packet, and in that case, it goes into several packets. 

Packets get sent to “sorting stations” called routers. These routers look at destination addresses and try to get the request there. Sometimes they may not know how to get there, but know that other routers close to the destination may have a better idea of how to get there. Routers can break down, they can get overflowed with requests, they can run out of space…when that happens, it starts throwing away packets without telling anyone. We need some kind of delivery confirmation system, then; we do this in the form of the TCP layer. We wrap our HTTP request in a TCP layer before putting it into an IP packet. 

Transport Layer

TCP stands for transfer control protocol - first, the client and the server (our OS and a website server, in this case) establish a connection. Then they send and receive packets to each other - as one side receives a packet, it sends a confirmation message saying “I’ve received 5/5 IP packets so far”. If the request sending party doesn’t receive confirmation after a period of time, it assumes the request/packets were lost and resends them. 

Confirming receipt has a big drawback - it slows things up. UDP (user datagram protocol) is sometimes used instead of TCP. TPC is connection-oriented - once a connection is established, data can be sent in either direction. UDP is connectionless, where multiple messages are sent as packets in chunks. One program sends a group of IP packets to another program and that is the end of the relationship. TCP is thus more suited to systems that need high reliability, and where transmission time is less important - UDP, on the other hand, is suitable for applications that need faster transmission (such as games). Since UDP is also stateless, it is useful for servers that answer small queries in extremely high volume. HTTP, in our case, uses TCP. UDP doesn’t order packets as they are considered independent of one another - TCP arranges data packets in the order specified. 

Both TCP and UDP add a piece of important information to our network request: a port number. IP protocols only contain addresses that specify computers, not the applications running on those computers. Our HTTP request may contain an IP packet that knows the address of the machine running the website server, but there could be other servers running on that machine. The port number included in the network request tells the target OS which program to send the request to (port 80 is often used to mean a request for a web server). The same goes in reverse, where the server response will contain a port number that the client OS will use to direct the response to the proper program. This number is based on the socket that the client OS originally set up.

There are four things that uniquely identify a socket - Destination IP, Destination Port, Source IP, Source Port. You can have multiple sockets open to the same Destination IP and Port, as long as they have a different Source Port. Firefox tab 3 and Firefox tab 4 would have different Source Ports, so you could load the exact same website on both tabs. 

The general flow of things can summarized as such: Application Layer Request (HTTP in our case) -> Wrapped in the TCP/UDP layer which includes port number -> Wrapped in IP Packet -> Client OS sends request to target machine and Application Layer Program -> Server OS uses Port to send request to proper Application Layer Program -> Sends response using Source IP and Port -> Client OS receives response and stores in a socket, which the client Application Layer Program can read from. 

 

***A URL contains information such as the protocol type, host, port, resource path, and query.

(protocol)http://(host)www.amazon.com(port)80/(resourcepath)store/electronics/resource(query)?a=by8v&x

 

A Note on Server Responses - 

Request responses contain status codes that tell the client how to interpret the response:

1xx contain informational messages and are purely provisional.

2xx contain success messages (202 = accepted, 204 = no content, 205 = reset content, 206 = partial content in response)

3xx contain redirection messages (301 = moved permanently aka. resource is at a different URL, 303 = see other aka resource is temporarily at a different URL, 304 = not modified aka server says resource hasn’t changed and the client should use a cached copy)

4xx contain client error messages (we all know 404 not found, but there is also 400 = bad request, 401 = unauthorized, 403 = forbidden)

5xx contain server error messages

There is plenty more to learn just about the HTTP protocol, so feel free to continue reading up on it!