Networking post WIP

DHCP.md

DHCP {#dhcp}

DHCP stands for "dynamic host control protocol". It is the method for which machines on a local network automatically retrieve an IP address in order to identiy itself. It requires both a server and a client to work as-expected. This process includes 4 steps:

1. A client that requires an IP address sends a UDP packet to the local network, asking if there are any DHCP servers on the network. This step is called DHCPDiscover

1a) This request is then ignored by anything that isn't a DHCP server

2. The DHCP Server responds with an IP address suggestion. It doesn't know where to send it back to, since the requester does not have an IP address yet it will respond using UDP to every machine on the network. This step is called DHCPOffer

2a) Any machine that has not requested an IP via DHCPDiscover will ignore this packet

2b) Interestingly, if there is more than one DHCP server, all DHCP servers will respond with their own DHCPOffers.

3. The client that has requested via DHCPDiscover acknoledges the request, and tells the server (again, via UDP) that it will accept that address via the DHCPRequest step

3a) Once again, any non-DHCP server will ignore the request.

3b) If there is more than one DHCP server, whichever packet is recieved by the client first is handled and others are disregarded. As a result, only the first DHCP server will recieve the relevant DHCPRequest packet, and the other servers will ignore said request

4. The server will respond with a DHCPACK packet, acknoledging the IP address utilization, but include including a date and time that the IP address lease will expire

4a) Becuase the server has no way of knowing when the client shuts down, it needs to include a date and time that the IP address will be available to the network once again. Otherwise, IP addresses would no longer ever be available and the pool would be quickly exhausted due to the lack of available addresses.

DNS.md

DNS {#dns}

When you or I go to a website, we typically start with a URL. Type unicorn-utterances.com into your browser and you'll be brought to this site. Makes sense, but what if I told you that computers don't have an innate sense of website naming? When your browser visits a webpage, it must know the server's IP address in order to communicate; it cannot do so using the domain name alone. If this is true, then how are we able to access the server and therefore a website's contents using only a domain name?

This is where DNS, or "Domain Name Service", comes into play. DNS is the method in which you're able to discover a remote machine's IP address from a URL.

This process has a few steps to it:

1. You first connect to a resolver. This resolver knows how to connect to the next stage in the process

2. The resolver then connects to a root server. This root server does not know where

3. TLD name server

4. Authoritative name server

7When you connect to DNS, you connect to another machine

Root Servers

12 organizations host these root servers. When you connect to the internet, you connect to 13 different root servers. These 13 root servers are called alphabetically (A-M).

Server Name	Server Maintainer
A	Verisign
B	Information Sciences Institute
C	Cogent Communications
D	University of Maryland
E	NASA Ames Research Center
F	Internet Systems Consortium
G	U.S DOD Network Information Center
H	U.S. Army Research Lab
I	Netnod
J	Verisign
K	RIPE NCC
L	ICANN
M	WIDE Project

For each of these server names, there may be various geo-sparse, redundant machines behind any of them. This ensures consistent and fast internet for various areas of the globe.

This means that if you're trying to connect to the D server, your machine will run a query and find the closest server that the University of Maryland has setup in your geoarea (despite the name, they run over 100 servers in a myriad of places for the D server)

Geo-sparce redundant

Resolvers to the root servers

Root server will redirect to TLD server

TLD server will redirect to authoritative name servers

HTTP-routing.md

HTTP Routing {#http-routing}

HTML is simply a text string that the browser then turns into a visual display. Being XML-like (because they're both based off the same foundation), there's nothing that HTML does to know what is happening when a user clicks on a link; that's the server's job.

When the user clicks on a link, it's a URL like unicorn-utterances.com/posts/understanding-the-dom. That URL then gets passed to your ISP (Internet Service Provider) (Comcast/ ATT/ Etc)'s servers to "lookup" the related server's IP address through something called "DNS" (aka Domain Name Service). If you're on Windows, do ping unicorn-utterances.com and watch all of the IP addresses show up. This is the process that your browser talks to a various number of servers until it finally finds that right server for a given website.

Then, that server returns some text (HTML) that is then parsed by your browser.

This is a really long-hand way of saying: The server handles the pathing, not the HTML. This is why you can open an HTML file from your local machine (save a file to index.html and watch as it opens on Chrome despite not being hosted on a domain).

While links are absolutely an integral part of "the internet" that mass public knows and relates to, I'd mention that it's not handled by HTML, but rather the servers that host HTML

REST.md

RESTful Services {#rest}

When building a server to match REST architecture, the HTTP methods construct a CRUD (create, read, update, destroy) methodology for handling and updating assets.

Method Name	Short Description For Typical Usage
GET	Retreiving information about an asset or running an action
HEAD	Request the headers that would usually be returned during a GET (often for time-saving in very large requests)
PUT	Updating an existing asset with a complete data swap with new data
PATCH	Updating an existing asset with a partial update given new data
DELETE	Removing or deleting an asset
CONNECT	Start of a two-way communciation, often used to open a tunnel
OPTIONS	Recieve the options on a given route available for future communications
TRACE	Debug the communication with a given route

While every method has their usage, the most common of these methods to be ran manually would be the GET, PUT, PATCH, and DELETE methods.

Many of these options may be ran automatically by your browser before another request. For example, when using CORS (Cross-origin resource sharing) - an additional safegaurd for ensuring XSS (cross-side-scripting) attacks are mitigated - the browser will run an OPTIONS request prior to any POST request to make sure that the route can be accessed from that domain.

TCP.md

TCP {#tcp}

Unlike UDP, TCP (Transmission Control Protocol), TCP ensures the delivery of your packets is delivered and provides various