Week 9: Day 027 - TCP/IP Basics #1

Finally, the time has come! Today I will be starting the chapter on the basics of the widely used TCP/IP. Let's go!

Back in the day there were an innumerable amount of standards set. Many people wanted their standards to be the ultimate one, and it made it really hard for those who wanted to run a network, or even more, a cross-platform one. The OSI model was being interpreted in many standards and many ways, and people were getting annoyed at this. In the end, TCP/IP won, as you can imagine.

Firstly, when it comes to TCP/IP protocol suite, I will be focusing on th top three layers which are "Internet, Transport, and Application". In an IP packet there are some parts of it that flawlessly fit into one of the respective layers of TCP/IP. All the parts consists of headers, and data to go with it. The payload of the packet can be a TCP segment with data from layers above and a sequence number. The higher up the model, more headers are removed until all that's left is the data.

The Internet Protocol (IP) is in the Internet layer, as you would expect. It takes the data from the transport layer, adds some addresses, and creates the final IP packet. Now let's see how it does it. The textbook gives good examples.

Most people have seen IP addresses like this:
192.168.1.115

That type of address has four values which range from 0 to 255, between three dots or rather periods. Officially this is known as IPv4 addresses, but I already knew that! However, soon we'll run out of those IPs so we'll need something new, and that is called IPv6.

These addresses are extremely long and are like this:
2001:0:4137:9e76:43e:2599:3f57:fe9a

But these aren't the only protocols that do stuff in this layer. Some applications test basic issues at that layer, such as identifying IP addresses. Those applications use ICMP (Internet Control Message Protocol). Those programs are rarely started up by TCP/IP users, but most of the ICMP features automatically start on demand of the applications, and you won't ever know. One widely used program that runs ICMP is the "venerable ping utility". You can run the ping command (from cmd I assume) and do da ting. The ping tester displays the RTT (round trip time or real transfer time) of the the ICMP packet, which takes seconds, or so it should. If ping can't find host, it will time out.

The important protocols of the Internet Layer to remember is:
- IPv4
- IPv6
- ICMP

The full IP packet has 14 fields, according to my textbook. Here is some basic information about the important ones:

- Version: The version (Ver) defines the IP address type: 4 for IPv4, 6 for IPv6
- Header Length: The total size of the IP portion of the packet in words (32-bits) is displayed in the header length field.
- Differentiated Services Code Point (DSCP): The DSCP field contains data used by bandwidth-sensitive applications like Voice over IP
- Time to Live: Routers on the Internet are not perfect and sometimes create loops. The Time to Live (TTL) field prevents an IP packet from indefinitely spinning through the Internet by using a counter that decrements by one every time a packet goes through a router. This number cannot start higher than 255; many applications start at 128.
- Protocol: In the vast majority of cases, the protocol field is either TCP or UDP.

Next, there's the transport layer protocols. This is responsible for identifying whether an application is connection-oriented or not. As I said in the past, in TCP/IP the TCP (Transmission Control Protocol) protocol is the connection oriented on, while UDP (User Datagram Protocol) is connectionless. Also quick not, you don't get to choose the protocol, the developers of the application do! For example, something like HTTP is built on TCP, and that will never change. Now, over 95% of applications use TCP, which is why it's called TCP/IP and not UDP/IP. What TCP does is, move an applications data from one system to another, completely and effectively. Because of this, it comes with rules on communication, that need both systems (receiving and sending) to acknowledge when they send/receive the data. This processs is called ACK/NACK or ACK. What TCP does as well, is split data into segments, then giving them a sequencing number, and verifies that the said segments were received properly. If one is missing, they send the missing piece. A simplified TCP header will contain 4 things "Source port", "Destination Port", "Sequence Number", and "ACK". So what's a port? I already bloody know, but I'll go over it. The port numbers range from 1 to 65535, and are used by systems to find out what application needs what to properly receive data. Web servers use port 80, as we all know, specifically HTTP, and there's also port 110 used for e-mail. So let's look at the TCP header. The header contains this:

- Sequence Number: Used to assemble/disassemble data.
- ACK number: Tracks readiness of two systems to send/receive data.
- Flags: Individual bits, give detailed info about connection status.
- Checksum: Checks TCP header for errors.

Then we got UDP, which isn't as important in the TCP/IP protocol suite. The UDP datagram doesn't have the extra data checks to make sure the data was not corrupted. Basically, UDP is great to use if you don't have data that needs to be sent in perfect state. For example, in a VoIP call it would be fine. The UDP protocol is very fast compared to TCP.

Finally, there's the Application Layer protocols. It's job is literally just as you would think, to move data between clients and servers, which are applications, on the network. The textbook gives an example of the most popular application protocol, HTTP. The header is a "response with a segment from the web server, telling the remote system that the last set of data transfers is complete." The header begins with the value, which is "HTTP/1.1" and the number "200" followed by "OK\r\n", it means "OK, go to the next line". That was probably confusing without actually looking at the figure, so I'll refer myself to look at pg. 184 of the textbook to see the figure. Anyways, that was all the covered on how the TCP/IP protocols fit into the model. Next time, I'll be going back to the Internet Layer for some more IP addressing exploration. Thanks for reading, and goodbye!