{re-write}
Not that I got your attention…
(really I just got my own) and yes, I had to look up names of supermodels to come up with two. I am not that much of a follower of supermodels. Never really gave a shit.
Now we start on the first meat and potatoes blog, TCP/IP and OSI models.
Note the re-write at the top. It seems that I waited too long earlier to hit the save button and I lost 2 pages of crap I wrote. Maybe this CMS isn’t the greatest blog software. (grrrr!)
Anyway…
We are talking chapter 2 of book 1 which has to do with the TCP/IP and OSI Models.
I am going to skip the whole talk about what the fuck a model is. If you don’t know, go to a hobby shop or get a dictionary..tard.
I will mention that the standardization of the the models come from the writings of Snoody Socialites known as the RFC (Request For Comments). Bizarre name for standardization documentation, but whatever. Shit has to have names.
Specifically we deal with the 802.1. Which is one number representing damn near an entire library of shit that all this is created out of.
There is some history crap also that I am skipping because the meat and potatoes is mainly the two models that we deal with which is the TCP/IP and OSI models.
TCP/IP was developed by the military through DARPA along with Universities and OSI was developed by the IOS (Internation Organization for Standardization) which isn’t very fucking helpful considering how much shit uses the abbreviation IOS (Apple, Cisco and now OSI).
So no matter what they say, I think that the reason TCP/IP became the norm is that they were the ones with the guns.
Anyway,
TCP/IP or the Transmission Control Protocol / Internet Protocol won in the contest of of “who is the badass network model” even though OSI (Open System Interconnection) is the more logical choice.
TCP/IP has the original model that had 4 layers and the updated version that has 5. Which helps because it becomes more like the OSI model. After being in networking awhile I can tell you matter of factly that we talk more in OSI than we do in TCP/IP.
We spend so much time going back and forth it will absolutely hurt your brain.
So with TCP/IP, the first model had:
4. Application
3. Transport
2. Internet
1. Network Access
The updated model broke up layer 1 into 2:
5. Application
4. Transport
3. Internet
2. Data Link
1. Physical
We always go top to bottom this way but number from the bottom to top. Cause we are crazy like that!!
Actually, it’s how shit hits us. I comes in the Physical, then goes to Data Link, then Internet, then Transport finally ending up on Application which what you start to see on your pretty little screen.
Also, we keep Physical on the bottom because its so heavy! lol
So a quick idea of what is happening at each layer:
Application – HTTP, POP3, SMTP
Transport – TCP, UDP
Internet – IP
Network Access – Ethernet, PPP, T/1
For some of you, you will know what all that is. For the rest of us, it will come up later.
Next, we go into a quick HTTP overview (Hyper Text Transfer Protocol) Why hyper? I don’t know. Maybe it didn’t take its meds.
Berners-Lee came up with all this crap, blame him. (Father of HTTP)
Really, I am just going to cover a quick couple of bits about HTTP. First, http headers are important as this is where the protocol puts information for itself to use. So this is where we get the 200, 300 and so on codes in HTTP. For example 200 is ok and 404 is “not found”. Always a sad thing to see when you are cruising the web and you go to that awesome site with all the cat videos.
Next, we jump to the Transport layer to talk a little bit about TCP and UDP. Now UDP (User Datagram Protocol) isn’t something we have talked too much about yet. So I will describe one of my favorite examples.
Basically, with TCP, if we were to throw a ball to someone, we would first say “Hey Bill! Can I throw you a ball?” He would respond with “Yeah, throw me that ball” and I would respond with “OK buddy, here’s the ball!”
This is the SYN-ACK-SYN/ACK or aka the Three way handshake.
With UDP, I just throw Bill the ball and don’t really give a shit if he catches it or not.
It’s important to note that there is also a SEQ or sequence number that is included in the TCP header so that each side knows the order in which the data is supposed to be received and also to know if one didn’t make it.
So when a developer is trying to figure out how to transfer data, they need to determine how important that all the data makes it and that it arrives in the correct order. Obviously, there is not many times when we use UDP, but it is damn faster as it doesn’t fuck around with all the chatter for the connection itself.
So, after this basic introduction of HTTP, we go into understanding the difference of Adjacent Layer and Same Layer interactions.
Basically, there is a lot written just to say that Adjacent layer is how data transfers through the different layers. Whereas Same Layer pertains to the interaction of data between the same layer on two different machines or locations.
Pretty short huh? Don’t know why they write so much crap about that.
So the Application layer basically pertains to the software that you are using. So like your web browser uses the application layer (particularly http). The transport layer does all the TCP / UDP work.
Next, we get into the Internet layer. Which to make life simple, is where the IP stuff comes into play. IP = Internet. DONE!
Seriously, I think we all get the concept that an IP address is like a phone number for your computer. Not to be confused with dial up which is different. Plus, who still uses dial-up?
There will be so much talk about how the IP address is used to forward packets, there really isn’t any reason to go that deep into it now.
Finally we have the network access layer. Now keep in mind that in the update version we split Data Link and Physical.
This basically is about how we physically connect the stuff together. But since both Data Link and Physical are together on the same layer with the old version, both get jammed together in this.
First off, a concept I haven’t talked about yet is encapsulation. As our data that we are trying to transfer all over the place goes through each layer, it gets encapsulated. I like to look at it this way. We are packing a lunch. In the lunch we are going to have a sandwich, a pudding snack (my favorite) and some chips. The food itself is the data from the Application layer. We “encapsulate” each item in its own container so that it doesn’t make a mess or more to the point, I don’t get chips in my pudding and pudding all over my sandwich. This would be Transport layer encapsulation. Then we put it all in a paper bag so that I can grab it really quick when it is time for lunch (the Internet layer) then I put it in my briefcase or backpack so I can actually take the thing to work (Network access layer).
The encapsulation has headers and trailers to help define what is in the encapsulation and how big the data contained within is. Basically where the sandwich data ends and the pudding data begins.
Sometimes to get it to fit into the containers that I have, I have to break it down into smaller pieces. Say, if I don’t have a big enough bag for all the chips I’m gonna eat, I will split them up into 2 separate bags. Yay! Now we understand Fragmentation!
Now my lunch in my paper bag would be considered a packet. When I am talking about my lunch, I am talking packets. But when we get to actually putting it into my backpack, this is when I start referring to it as a frame. This analogy will help a lot in the future because we will see that the larger the frame, the bigger the packet I can send. In other words, the larger the backpack, the more food I can pack to gorge myself on.
The Network Access layer is also how we get into talking about MAC addresses again. This is addressing that is used at the LAN level. This exists because we have in the past had a lot of different protocols for connecting shit together on a network. And for awhile, everybody was using different shit to send the same shit.
If you had a mac, it used one protocol for connecting together, which was different than say Windows or SPARC (For all you really really techy fucks).
More to the point, you could have a network connected with BCN cables (like cables you use for your TV but slightly different) or you can use what we refer to now as Ethernet cables. ANYWAY we needed to have a way to identify the computer on a Local Area Network and then a way to identify that same computer on a wider scale.
But we will get more into MAC addresses versus IP addresses later. Really we just want to close out this Model comparison so we can close out this fucking blog.
So, Just with what we described, we can see why the updated version broke out the Network Access layer into 2 pieces. One to handle the different ways we are connecting computers at the electronic level and another to address the actual physical connection (type of cable, boxes we use to connect them with, etc)
SOOOOOOOOOOOOOOOOO…………….
Now we get into the OSI Model.
Since we went through all the shit with TCP/IP, this will actually make OSI pretty easy.
First off, the difference? Well OSI is like a really good Bean dip…it has 7 layers.
the added two layers basically break up what TCP/IP has as one layer we have been calling the Application layer into the Application, Presentation and Session layers.
Also, in OSI, we change the term Internet layer into the network layer. As an aid, the book starts referring to the layer in TCP/IP is Internetwork and the OSI as Network.
So, with OSI we have the following
7. Application
6. Presentation
5. Session
4. Transport
3. Network
2. Data Link
1. Physical
Pretty fucking easy now, isn’t it?
Now, to be a cool network person, you don’t ever refer to something by its name, but by its layer. So when you are talking about a switch that does not look at the IP, its not a “Data Link” Switch, it’s a “Layer 2” Switch.
A “Layer 3” issue, is an IP issue. That kind of crap.
Now you may be wondering what the two new layers do. For the most part, we kind of don’t get a shit. As network people, we start to not give a fuck after layer 4 but we use the OSI model more for terminology than we do TCP/IP. Plus, there are rare times where shit comes up.
Particularly with Layer 5, Session. The Session layer defines how to start, control and end conversations (sessions). We see this at the server level when we set timeouts for how long a connection is to remain open. In load balancing we use Session Persistence so that when another computer connects to a cluster of web servers acting as one, that they are able to stay connected to the same individual server while they are connected to a site instead of a different one each time they send data.
The presentation layer really just sets up data formats. So it is basically looking at the data and determining if it is a picture (jpeg, png, etc), text (ASCII, Binary) or something else. Basically ponying up the data so that the application layer or “application” can use it.
So we generally don’t give two shits normally about layers 5, 6 and 7. But we need to know it anyway.
One other difference is that in TCP/IP we talked about Packets and Frames. There is also a “Segment” which is used by the Transport layer. But with OSI, we just refer to all the crap as just PDU’s or “Protocol Data Units”. Also, with TCP/IP when we talk about a packet, it is generally referred to as the data within and the headers and trailers are what they are. With PDU’s, the whole thing is considered a PDU. The only way to distinguish each is by the layer. AKA Layer 3 PDU or Layer 2 PDU.
And that’s about it!
I would have had 2 of these done today if it weren’t for the whole “autosave” fail.
Anyway, coming up next…Fundamentals of LANs… Weeee!!!!