Getting my head round TCP/IP

Kua · 22 May 2010 at 23:22

I'm revising for a first year ug networking exam. HTTP is easier to get your head round, because its possible to view HTTP requests and responses.

TCP/IP less so.

So far as I understand it when a HTTP request is made from a client to a web server they must set up a Transmission Control Protocol 'connection' - a protocol by which they agree to exchange information. I know its at the transmission layer and its analagous to the delivery firm you choose to deliver a package.

Is it possible to see some kind of code that would firm up my understanding? As far as I know TCP is also a request/response type protocol, so it must send messages itself...

Networking seems so abstract! Anyway the plan is over summer to start using Linux - perhaps that'll help.

tntcoder · 23 May 2010 at 00:00

I suggest running Wireshark while you make a HTTP request to help visualize the layers. You can monitor the packets and different protocols in real time.

You are correct, and you need to think in a layered mind set. You have IP which encapsulates TCP. TCP basically amongst other things adds state to IP. Then the TCP payload contains HTTP.

So when you make a HTTP request, first a TCP connection is established (after DNS lookups) using the SYN, SYN|ACK, ACK packet handshake.

Then once a TCP connection is established, you're HTTP GET request gets sent (sent inside a TCP packets payload data section. TCP will ensure the safe delivery of packets, so after each packet you will get an acknowledgement to say it was received (this works using TCP sequence numbers).

It's quite tricky to explain clearly, but once you understand what each protocol does (learn ARP, IP, TCP & HTTP) then it will click in your mind and all fit together

Here's me connecting to OCUK and sending a HTTP get request.

You can see the initial TCP connection establishment, followed by the HTTP GET request which is encapsulated by TCP, which is further encapsulated by IP, which is further encapsulated/formatted inside an Ethernet Frame.

(Hope that makes some sense, it's getting late

)

Kua · 23 May 2010 at 19:33

Wow, that app is fantastic, better than I could've hoped for. Good explanation too. Thanks!

192.168.1.5 kind of acts as your own IP address, but isn't actually your IP address, presumably to keep it secret...

Also, am I correct in thinking that each line is an individual packet?

tntcoder · 23 May 2010 at 19:46

Kua said:
Wow, that app is fantastic, better than I could've hoped for. Good explanation too. Thanks!

192.168.1.5 kind of acts as your own IP address, but isn't actually your IP address, presumably to keep it secret...

Also, am I correct in thinking that each line is an individual packet?

Sorry yes, 192.168.1.5 is my actual internal IP address, it's just that im behind a NAT router.

Each line is an individual packet yep

Kua · 23 May 2010 at 20:02

Let me see if I've got this roughly right:

Packets 1-3: Are they to do with setting up the TCP?

Packet 4: Is the client sending a request to its domain name server to find the numerical IP address for the domain name I entered in the URL?

Packet 10: The TCP connections must be established because the client is able to send a GET HTTP request to the server.

First thing that strikes me is the amount of TCP packets the client sends and receives. I guess that's because every time we try to send an HTTP packet, there is a series of requests and acknowledgments between the client and server.

I need to read more into it... To be honest I think this is far more advance than I need but still its useful knowledge.

Do you work with networks tntcoder?

Kua · 23 May 2010 at 20:05

Don't worry if you don't have time to answer all these questions btw!

But why is it that after packet 7 we are contacting a different computer in the same domain?

Wait, actually its a different domain. 208.111.171.82 initially. Then 207.126.123.20

tntcoder · 23 May 2010 at 20:12

Packets 7,8,9 are the TCP connection setup, you can see the flags: syn, syn|ack and ack in each of the three packets. 1,2,3 look like there from another connection/active session.

You're correct packet 4 is the DNS request to covert the URL into an IP address, and packet 6 is the response from that request containing the IP address. So once it's got this IP in packet 6, it starts the TCP connection in packet 7.

And yep, you're correct on packet 10. The TCP connection is good to go from packet 9, so the HTTP stuff starts from 10 onwards. So the HTTP Get goes out in 10, followed by some fragmented responses which will be further followed by the actual HTML data inside HTTP packets.

It's good you picked up on the amount of packets involved, this is why TCP is often classed as slow. It is good at reliability, it sends lots of packets and handles retransmissions and packet loss very well but at the expense of extra bandwidth. UDP on the other hand is much quicker at the cost of reliability.

I don't work with networks no, just did a networking course on my undergrad degree and have experience messing around with them