TCP/IP on the transport level

Question

I'm trying to understand what happens when I send a packet using a socket on the transport level. Do all packets which leave my computer go first to a geographical location designated by my ISP? Then is my packet transferred by tunnels owned by my ISP until it gets to one linked directly to the origin server? At what stage does it reach a DNS? If the domain isn't translated into an IP until it leaves my home, how does my router know to contain packets intended for a LAN transfer?

Please excuse me if I sound naive, I'm just reading through the RFC specification of HTTP and I'm trying to tie the characters on my screen with real events. All the guesses I am making are inferences with no grounding in actual understanding. Simple language would be preferred, metaphors would be outstanding :)

Answer 1

This is more of a transport-layer question. The details can be explained a little more by understanding the OSI-model. I make this distinction because the OSI model has a physical layer, so when you ask "...on a physical level", those words have a specific meaning in networking technology that perhaps you're not aware of, and might lead to some confusion if you posed this question to, say, a network admin.

The short answer to your question is that it leaves your house, and travels through a series of routers (the first one at your house, followed by some at your ISP, and then some on other networks), finally arriving at your destination. It's pretty much all routers between you and your destination, like a series of stops along a UPS package delivery, getting your packet "closer" to its destination, one step (or "hop") at a time. Precisely which routers handle, and help deliver a given packet is determined as the packet is being transmitted, and can change at any time. It should also be said that the meaning of "getting your packet closer with each hop" is just a best-effort sort of thing, and isn't necessarily guaranteed - TCP just tries to be as efficient as it can be during transmission.

Now, this is an over-simplification of how it actually works, but there's a lot more to this topic than what can be easily answered within a couple paragraphs.

Therefore, I point you to a great, and quite detailed (assumes no knowledge) explanation of TCP as a series of Security Now! episodes, which I would recommend as a great introduction, and overview on the topic:

• Episode 317: TCP part 1
• Episode 323: Attacking TCP
• Episdoe 325: Necessary refinements

These episodes start with an explanation of how TCP works, followed by some of the issues, challenges, and possible future changes/refinements that may need to be made. All three episodes together are a good 3-5 hours of listening, but I'd say that's what it's going to take to really answer your question somewhat in-depth. Listen as much (or as little) as you deem interesting.

Answer 2

DNS gets involved primarily in answering something like gethostbyname (i.e., finding the numeric address that goes with a given host name). In a few cases your computer's own IP stack will answer such questions without consulting a DNS, typically by getting the address from your local HOSTS file. This was common at one time, but has long since become relatively rare (HOSTS files are still of some use in testing, as well as being used by some malware to re-direct some requests to a machine of the malware author's choosing).

When you send to that address, your computer's IP stack will sort out where to sent it from there. First it uses the subnet mask to figure out whether the address is "local" or not. If it's local, it'll use ARP to find the Ethernet MAC address (or whatever, but nowadays mostly Ethernet) to which to send the packet. If the address isn't local, it'll send it to the default gateway address.

Assuming it's not local, the default gateway will normally be your router. Your router will send it on to the ISP's router, which will then send it on to another and another until it gets where it's supposed to be going. There are some protocols (RIP, RIPv2, etc.) for routers to tell each other how to get packets from one place to another. For a typical home router, things are simple: anything that isn't local goes to one place. For a larger router at an ISP, things are a little more complex -- it'll frequently have several other places it could sent your packet. RIP (and friends) give it enough information to pick the "right" one (i.e., the one that's likely the best choice).

If you want to see where your packets go, most systems provide a program named tracert that will trace the route from your machine to another you specify.

I see @normalocity has posted an answer already. I'd be cautious about one thing though: he mentions the router getting your packet closer to its destination. This is true, but only in a rather virtual sense, not a physical one. Just for example, at one time I used tracert to trace the route from my machine at home to a machine downtown, about 5 miles away or so. Even though both machines were in Colorado Springs, Colorado, my packets were routed to Denver, and then on to San Jose before coming back and getting to another reasonably local machine.

Answer 3

There are too many parts to your question. I'm going to attempt to answer each briefly. You'll have to dig deeper into each of these to understand more.

DNS: All packets don't go to a DNS. Your OS already knows the IP address of a DNS server (through your ISP's configuration) and translates FQDNs to IP addresses by contacting that DNS server.

HTTP: So when you type in www.foo.com in your browser,

1. Your OS resolves www.foo.com to an IP address by contacting its known DNS server IP address
2. Connects to www.foo.com's IP address over TCP port 80 and sends a HTTP request

Routing: How a packet reaches another IP address is IP routing. Read about packet switched networks to understand hop-by-hop routing. Both HTTP (TCP) and DNS traffic are routed identically (routers don't care about the payload). Just that the destinations would be different.

Answer 4

How Routing Works

• Receive or generate packet, get its destination IP
• Go through each entry in Forwarding Information Base (FIB) (i.e. route table) and find most specific entry that matches. more specific here means highest CIDR subnet notation. i.e. the FIB entry 192.168.2.1/28 will be chosen over 192.168.2.1/24 if both exist.
• If there are two exact entries in the FIB, the one with the lower metric is chosen.
• If we find an entry that matches, get that entry's gateway IP and send the packet to that IP.
• Didn't find any? Send packet to the IP that's the default gateway.
• More than one default gateway? Round robin between them, or use first one and keep using it until we find out it doesn't work, then use second one (failover)
• No default gateway? Drop packet.

Note that:

• If a packet is destined for something on the same subnet, no need to route. So if your PC at 192.168.2.1/24 sends a packet to 192.168.2.2/24, it won't send it through the default gateway, or any router at all.
• Any interface gives us a free route by way of being directly connected. So if you have an interface that's set to 192.168.2.1/24 (i.e. subnet mask 255.255.255.0), you get a free route.
• Localhost is directly connected for the purposes of this.
• If you run things like RIP, OSPF, BGP they may update your FIB.

Your ISP's carrier grade routers have FIBs and the process is the same. Jumping router to router, going through the same process, until the destination is reached or the packet is dropped. Typically the "higher" up you go, the larger the FIB will be, and more routes will come from things like BGP and such.