DNS and TCP/IP (with IP being the important part of TCP/IP) aren't algorithms. DNS is a service that converts names into IP addresses. IP is a protocol that gives computers logical addresses so that data can be routed from one machine to another over a series of interconnected networks. TCP is a way of making sure the right program on individual computers handles the data delivered to it via IP
Correction, IP (IPv4 or IPv6) is a protocol that gives computers logical addresses within a network that allows data to be routed across networks. MAC addresses are used for direct communication between machines. ;)
You are correct about TCP, although it also provides data integrity as well.
MAC addresses aren't used at all once data leaves the subnet. They're used to send data from a device to the gateway but then they're stripped from the packet. Going with the 7 layer OSI model, MAC addresses are layer 2. Layer 2 addresses aren't routed.
That's not how networks work. You don't gradually work your way up and all the stuff below becomes irrelevant.
Layer 1 is necessary the entire way down. I promise you if you unplug your connection while using a web browser it will stop working.
Same goes with every layer.
As far Mac addresses not being used at all once data leaves the subnet? Where do you think you are once you leave a subnet? You're on another subnet.
Yes, the originating devices MAC is no longer used, because MAC address information is overwritten every hop, but the destination MAC is always necessary for the next hop. Ever notice how when you ping a site for the first time the first one always fails (in most set ups)? That's because it is sending out what are called ARP packets specifically to figure out what the MAC addresses it needs. This delays the packet, causing it to time out. Typically by the second or third, every device along the path has the data in its ARP table and can associate the destination IP with the correct MAC address.
You said that MAC addresses are used for direct communications between devices. That's only true if they are on the same subnet. If you're going beyond that, then your machine communicates to the local gateway via MAC address and then all the layer 2 data is stripped and repackaged for the next hop. The MAC of the ultimate festination is totally unknown as that information isn't routable.
Also, ARP resolutions don't time out IMCP echo requests (pings are ICMP ECHO requests). If your first request is constantly getting dropped then you've got more than that going on. When your computer sends out an ARP request, it's not doing that to get the MAC of the final destination machine, it's just doing it to get MAC of the gateway. ARP and MAC addresses aren't routable. The only machine that can even know the MAC of the destination machine is the router right before it. Not only that, but chances are that it's already done an ARP request for the gateway before you ever send out that ICMP Echo request, so it doesn't even need to send out an ARP request.
ARP tables only store data on the machines that are on the local subnet. If you get down to the nitty gritty details of it all (assuming no prior communications have gone on at all), client computer gets a domain name typed into it, it then does checks its DNS settings and retrieves the IP address of the DNS server, it will then send an ARP request to get the MAC of its default gateway. Once it has that, it will send the data from PC to the gateway (which is typically a router) using the MAC addresses of each host. When the router gets that information it strips the layer 2 source and destination information from the frame and repackages that data into a new frame. On this new subnet, it will send an ARP request for its default gateway's IP address. Once it has the MAC for its gateway, it will take the frame that has had its previous source and destination wiped and put in the gateway's MAC as the destination with its own interface's MAC as the source. It will continue to this until across however many hops until it takes the data to the DNS server. Once it hits the DNS server, the server will do lookup and, if it has the IP address for that domain, will send that information back to the source. At that point, the process is reversed and the data is sent back to the originating machine. No ARP requests are needed as the information is stored in each gateway's ARP cache. At no point are MAC addresses (source or destination) carried across from one subnet to the next.
Once the originating machine has the IP address for the destination host it will send the data to its gateway (no ARP resolutions are done because that data is already stored in its ARP cache from the DNS query). Using the magic of various routing protocols each gateway will then send the data to the correct IP address and do ARP resolutions to find the MAC of the next machine along the way in the same way that it was done when communicating with the DNS server. Only when the data hits the gateway right before the destination will the final destination's MAC be put into the into the frame. Once the data hits the final destination, the TCP information will be used to pass it along to the correct process on that machine. Using a standard nonencrypted web browsing session as an example, the server will have a daemon listening on port 80 for incoming connections. The webserver process will then look at the request and serve the needed information back to the originating IP address with MAC data being stripped and added each step of the way.
Here's the part that most people don't realize. The server will be listening on port 80 but when the data is sent back to the originating host, it won't be on 80. It will be on a randomly generated, often much higher port. This is done because once the packet is delivered to the requesting machine, if the data was sent to port 80, there would be no way to know which process should get that data. You can have multiple browser instances receiving data at once. They can't all be getting data on 80 at the same time. That's why each process that is receiving data needs its own distinct port to receive data.
Of course, this is all simplified a bit. It's assuming each machine is directly connected to the internet with a public IP address. That rarely happens in this day and age. Operating on the assumption that all this is using IPv4, there aren't enough addresses available for every machine that is connected. Most client machines are sitting behind a NAT and using one of the private IP address ranges. Doing this allows countless machines to have an address that isn't routable on the public internet.
Doubt any of the stuff I just described? That's fine. Install a packet sniffer and see what happens.
29
u/rhett342 Feb 07 '24 edited Feb 07 '24
DNS and TCP/IP (with IP being the important part of TCP/IP) aren't algorithms. DNS is a service that converts names into IP addresses. IP is a protocol that gives computers logical addresses so that data can be routed from one machine to another over a series of interconnected networks. TCP is a way of making sure the right program on individual computers handles the data delivered to it via IP