First off, a bit of essential knowledge. I imagine most people reading this can skip the next three paragraphs.
Computers connected to the internet (or any kind of network) aren't referenced by names such as "bob" or "steve," they are referenced by IP addresses. An IP address is a string of numbers separated by periods, such as, say, 127.0.0.1 (this is actually called the "loopback address," as it always references the computer attempting to make a connection). There are other articles out there that go into more detail about IP addresses, so if you need any more help on this subject, look at them or google.
Ports. They allow more than one connection to be active at any one time (otherwise, programs would get very confused about what data is theirs, and what is another program's). Ports aren't actual physical ports, but rather they're "virtual," meaning, as far as the computer's concerned, they actually exist physically, and are different from each other. Computers have 65536 possible port numbers (0 to 65535).
Packets. They're what a computer actually sends when communicating to another computer. They contain the IP of the destination computer, the destination port number, the actual data, and some other things (some of which are specific to the TCP protocol).
Now, on to the TCP portion of TCP/IP.
TCP stands for "Transmission Control Protocol." Basically, it's the general-use protocol, used for things like web browsing (mostly), and playing games (mostly).
So, how is a TCP connection established?
Well, let's say Computer A wants to connect to Comptuer B. Computer A sends a SYN packet to Computer B. That SYN packet is basically like A saying to B, "Hey, I want to make a connection with you." B sends A a SYN/ACK packet, acknowledging the request. "OK, I'm fine with that." Then, because the nature of TCP is to lose as few packets as possible, A sends B a ACK packet. "OK, I'm connecting."
The connection is established, and A and B start communicating, and you get your porn, or whatever.
An interesting thing about TCP is EVERY packet is acknowledged. It also supports the ability to send and receive "fragmented packets," or packets that are too large to be sent at once. In fact, because every fragment of a packet might not follow the same path to it's destination, every fragment packet is numbered, and, once every packet reaches it's destination, the original packet is reconstructed. This can actually be exploited, but I won't go into that.
"But," you say, "I don't know how a packet is actually constructed!"
Actually, it's not that complicated. Well, not to me, anyway.
The first 16 bits are used to identify the source port.
Bits 17-31 contains the destination port.
32-63 are reserved for the packet's sequence number (remember the fragmented packet?).
64-95 is the acknowledgment number (if the ACK flag is set, this is the sequence number of the packet the sender expects to receive next).
96-99 is the data offset, or how big the header (the start of the packet, providing information and such, like the heading of a paper) is. This is needed so the receiving computer doesn't think some of the header is actually data.
100-107 is reserved (meaning there's nothing there, yet).
108-111 is where the flags are set (flags are what determines whether the packet is a SYN packet, an ACK packet, and so on).
112-127 is the window field. That basically means how much data can be received before another packet that is sent won't be received, or even acknowledged.
128-143 are the checksum, which is used for error-checking of both the header and the data itself.
144-159 is the urgent pointer.
160-191 can either be options, or the start of the data. If it is data, then the rest of the packet also contains data. If not, the data starts at bit 192.
OK, maybe it's a little bit more complicated than I let on, but, for the most part, you don't need to memorize what each and every bit is for.
Downsides of the TCP Protocol
As I said before, the sequence number of a packet can be set to a number the program it's being sent to isn't expecting, and, if you do it right, can lead to a DoS (Denial of Service) attack. Of course, as per the TCP protocol, you'd have to send another packet crafted to do the exact same thing in less then four minutes since the packet before it, otherwise the program you DoS'd will just stop waiting for another packet,
TCP is also very easy to flood with so many packets it just can't handle it. TCP really isn't streamlined enough to be able to handle a large amount of packets, it was built with data stream integrity in mind.
Advantages of the TCP Protocol
Even if a packet is lost in transit, the receiver will know, and is able to request JUST that lost packet be sent again. This means actually losing data is extremely rare, if it can even happen at all.
The fact it has to establish a connection, instead of just sending data along with all the other packets being sent to a given computer, means it's impossible for data to accidentally be taken as someone else's. Of course, it's possible to craft a packet to SEEM to come from someone else.
I hope you actually understood at least most of that, I tend to expect a lot from people.
Hoping to do a more in-depth (yes, even more so) article at some point.
(edited by Hitekrednek just for a few typos and one sentence extension)
Cast your vote on this article 10 - Highest, 1 - Lowest
Comments: Published: 23 comments.
HackThisSite is is the collective work of the HackThisSite staff, licensed under a CC BY-NC license.
We ask that you inform us upon sharing or distributing.