DEV Community

JayZho
JayZho

Posted on • Updated on

Computer Networking: Intuitive Understanding of the Basics (updating...)

The 5-Layer Model

Application layer: Defines the meaning of the message. For example:

  • should we include the length of the message in bytes?
  • should we define a set of message types to indicate the purpose of the message? Something like "POST" and "GET" in HTTP
  • what Transport layer protocol should we choose? Do we care about the reliability a lot? Maybe UDP will do the job(instead of TCP) if missing packets are acceptable?

Transport layer: Defines the mechanism of the communication. Still programmable by software layer. For example, instead of using TCP, we could use the socket library in Python to totally implement our own transport layer protocol and apply it to both the client and server side to make it work.

Network layer: Defines the bigger picture of the network, in comparison to the Link Layer. Each IP address represents the entry to a local network, but the inside of each local area network is a black box for the Network Layer.

SSL (Secure socket layer)

Without any protection, the TCP layer transfers the message in cleartext, which could be dangerous. If you're interested enough, you could actually implement your own "SSL" by building a software that accepts data from the application layer, encoding it and passing it to TCP, on the receiving side simply do the opposite. By inserting this piece of software between the application layer and the TCP layer, you've got your own "SSL".
That's basically how SSL works and what SSL is.
HTTPS is an example that uses SSL to securely transfer data on top of traditional HTTP messages.

Cookie

Just a user profile created and stored on the server side:

  1. Sam visits Amazon.com via his browser for the first time
  2. Amazon's server: "Hey, a new guy is visiting us, let's create a profile for him with the unique identifier 'Sam001'". Then the server passes "cookie: Sam001" together with other response data back to the browser.
  3. The browser: "Oh, I see a cookie header, let's store it onto the computer so every following request to Amazon.com we'll include this cookie, then the server knows it's us and it'll give us customised content!"
  4. Sam continues browsing on Amazon.com, meanwhile the server tracks his activities like what types of products he's interested in, etc, storing this info in his profile on the server side.
  5. A week later, Sam visits Amazon.com on his computer again. The browser sends the request with his cookie to the server.
  6. Amazon's server: "Hey it's Sam001, according to our record in his profile here, he likes gaming a lot, let's send him some ads about our gaming product"
  7. Sam sees gaming product on Amazon's site, wondering how they know him so well and spend his money recklessly.

Web Cache

Just a proxy server normally installed by ISPs on their access points.

  1. A client requests for object "loneliness.com/hotgirl.png"
  2. The browser sends the request to a web cache server instead of the origin server.
  3. The web cache server checks if it has "loneliness.com/hotgirl.png" cached, if so it simply returns it to the browser; otherwise it requests the origin server, gets the object, cache it and also sends it back to the browser.

Note that some content might be outdated if cached for a relatively long time.
In this case, the Last-Modified: Wed, 7 Sep 2011 09:23:24 header in a response HTTP message would be used, and the next time a browser requests for the same object, the web caches server sends a requests to the origin server including If-modified-since: Wed, 7 Sep 2011 09:23:24. If it hasn't been modified on the origin server, it responses with 304 Not Modified with an empty body(saving some bandwidth), and the web cache is now reassured and happliy sends the cached content back to the browser.

DNS (Domain Name Service)

Just a translation from a human-prefered hostname to a computer-prefered IP address.

The process works as follows:

  1. You visit "www.amazon.com.au" on your browser
  2. Before sending the request to Amazon's server, the browser first extract the domain name "www.amazon.com.au" and send it to the DNS software installed in the browser.
  3. The DNS software(client side) sends the domain name over UDP to a DNS server. This DNS server is normally a local DNS server employed by your ISP or institution, sitting in the network somewhere very close to your LAN.
  4. The local DNS server now queries other DNS server(s) and eventually get back the IP address(es) for "www.amazon.com.au" and return it back to the DNS client software on your browser, which further give to back to your browser and your browser can now initiate a TCP connection with the server at that IP address and start the HTTP communication. Remember that if this "domain name" -> "IP" mapping happens to be cached in the local DNS server, it will immediately return it to your browser without the need to further querying other DNS servers.

Note that the process of querying other DNS servers to get the desired IP address is a bit more complicated than this, below is a brief discussion if you're interested:

The process of finding an IP address according to a domain name like "www.amazon.com" is typically an iterative process:

Since it's far too much data for storing all the "complete domain name" -> "IP address(es)" mappings, the DNS servers work in a distributed manner, each responsible for a (part of) certain hierarchy in the domain name. Intuitively, the highest tier domain like .com .net .edu don't have too many variations, hence there are not so many root level DNS servers globally in comparison to the number of DNS servers for lower levels.

When given a domain name to lookup at a local DNS server, the local DNS server first queries a root DNS server for the address of the next level DNS server. In this case, say "somedns.edu" is responsible for looking up all domain names ending with .com, then the root DNS server will pass back "somedns.edu" to the local DNS server, then the local DNS server further queries "somedns.edu", and "somedns.edu" sees that it's "(www).amazon(.com)", grabs an address in its record which is responsible for return the IP address for "*.amazon", and ... you get the idea.

Note that DNS servers could be widely used for load balancing purposes, since popular websites like Amazon has many servers all over the globe, when return the IP address for something like "amazon.com.au", the DNS server probably would have multiple valid IP addresses. What it does is that it rotates the list of all available IP addresses for Amazon servers every time a browser queries it, and since the browser normally would request for the first IP address it's given, this helps balacing the server's work load.

Understanding IP Addresses (Network Layer)

  • the home router (with NAT) doesn't look like a router to the outside networks, it simply looks like a device with a single interface(IP address) receiving and sending IP datagrams.
  • NAT is basically mapping (endDeviceIPAddressWithinTheSubnet, endDevicePortNum) to (publicIPAddressOfTheHomeRouter, homeRouterPortNum)
  • IP address is per interface, rather than per device.

Understanding MAC Addresses (Link Layer)

Top comments (0)