TCP/IP and Internet Primer - Detlef Pleiss, Apr-10-1997

The Internet is the Internet because it is inter the nets ...
huh? With "inter" meaning "between" it means that the Internet and the
Internet Protocol (IP) is designed to be used across different networks, using
different network connection hardware, connecting them to each other, to build
the one big ... Internet.

The first point to keep in mind is that the Internet consists of connections
between computers based on different types of hardware. The Internet Protocol
(IP) does not name a special sort of hardware, but is a protocol which can be
run on a diversity of different hardware. To understand all the
different acronyms and protocol names involved it is important to understand
to which level of networking each one belongs.

The basic level for each network is the hardware involved. Some sort of
hardware to connect two or more computers to each other is always involved, be
it Ethernet cards and cables, fiber optics, a modem connection or a nullmodem
cable. On the hardware level there are hardware related protocols at work,
like on an Ethernet you have a protocol which decides what data packets to
deliver to which computer on the local Ethernet. This protocol is implemented
in the hardware, insofar each network card has a distinct network address
built into its hardware and it only forwards data packets sent to its address
up to the software driver. On top of whatever protocol the hardware uses,
different network protocols may be implemented by the software, be it IPX or
TCP/IP or whatever. Different such software network protocols can run over the
same hardware, often at the same time.

As mentioned above the Ethernet hardware sends packets of data over the line,
speak a bunch of bytes which belong to each other somehow. When it comes to
serial lines, modem or nullmodem connections, the hardware itself defines a
protocol to deliver a stream of data over the line - speaking about bytesize,
start- and stop-bits here. Here the hardware itself does not deliver packets
of data but a stream of data. To get functionality comparable to a packet
oriented network like Ethernet over serial lines, protocols have been designed
for packet delivery over serial lines. Although realized in software these are
on a level comparable to what's in the hardware of a network card. Speaking
about the Internet two such protocols are important, SLIP (Serial Line IP)
and PPP (Point to Point Protocol). Like with a network card, these protocols
deliver packets of data to the higher software levels, while they translate
these, so they can be sent over a serial line's byte stream. While SLIP is the
older of them both, nowadays mostly PPP is spoken when it comes to Internet
connection over serial lines. (Not true for SLIP, but) Just like said before
about Ethernets, a variety of software protocols can be transmitted over a PPP
line, one of them being TCP/IP.

So, IP (Internet Protocol) is a software protocol to deliver packets of data
from one host to another. A protocol which is not related to some special kind
of hardware, but which is used over different networks based on different
hardware (PPP serial links being one of them). While taking care of other
issues (like checksumming data), the most important aspect of IP is the
addressing of data packets, in that there are fields for a source and a
destination address. Those are the famous IP addresses!

IP addresses consist of four bytes, normally written as aaa.bbb.ccc.ddd,
where aaa (and, you guessed it, bbb ...) is the decimal value of one of those
bytes. As the value of a byte can range from 0 to 255, IP addresses range from
0.0.0.0 to 255.255.255.255. In IP, the IP addresses define where a packet came
from and where it has to go to. That's why IP addresses have to be unique over
the internet, as they decide to which computer a packet gets delivered in the
end. To guarantee this uniqueness for the Internet there's a central authority
assigning IP addresses, the Network Information Center (NIC). They normally
don't assign every single IP but give out the rights to use a range of IP
address inside a network. The person maintaining this range of IP's may then
give out (a subrange of) IP's to others. For example your ISP has a range of
IP's registered with NIC (or another instance in between) and the IP you get
when calling there is one of those IP's registered for your ISP's network.

Now, how does it work that over the internet I can contact computers all
over the world? That's because there are routers and gateways in between.
Those are computers with multiple network interfaces, forwarding packets
between them. They follow a set of rules (routing table) to decide, based on
the destination IP address of a packet, which is the right network interface to
forward the packet through ... either to the next router or to the local
(let's say) Ethernet if the packet happened to be destined to a computer
directly connected to this router. So each router has some sort of "knowledge"
about packets with which IP addresses to pick up for the local network or, if
it's not destined to the local network, to send the packet to the next router,
which either "knows" where to deliver the packet or forwards it to the
next router and so forth ...

So, when it is said that your computer has this and that IP address, it
means that IP data packets with your IP address as destination get
delivered to your computer (if everything works well) and that IP data packets
originating from your computer have your IP address as source address. Packets
with your IP address as destination get delivered to your computer from
everywhere in the world, because the router at your ISP "knows" to send such
packets over the network interface where you're connected, be that an Ethernet
or a PPP dial-in. Some other router "before" your ISP's router "knows" that
each packet within the range of IP addresses that belong to your ISP have to go
to your ISP's router, while other packages may go to other ISP's routers. This
way, packets get delivered between computers on the Internet, based on their
IP addresses.

Talking about IP addresses, I wasn't exactly correct in saying they range from
0.0.0.0 to 255.255.255.255. A zero in an IP stands for the whole network, so
there's no host with a trailing zero in it's IP address. Equally the 255 is
reserved for broadcast addresses, which refer not to one host alone but to a
network in general. Additionally there are some special IP addresses:
The network 127.0.0.0 (the zeroes standing for whatever byte) always refers to
your local machine. Normally the IP 127.0.0.1 addresses the so called loopback
interface, where the TCP/IP software sends packets just back to itself.
For example, using this IP address typed into a web browser you can contact a
web server running on your own machine without actually being connected to the
net and without any packages going back and forth through network interfaces.
There are also ranges of IP's reserved for private use: 10.0.0.0 and
192.168.0.0. These may safely be used on a private network, even if connected
to the internet, without registration at NIC. They do not collide with other
computer's IP addresses (on different networks) as packets to or from these
addresses do not get forwarded by Internet routers. Thus, there is no host on
the Internet with an address in the named range(s).

IP itself doesn't care about wether a package really reaches its destination -
it may get lost in between! It's a so called unreliable protocol. How can that
be, you say, how can I transfer files when the packets get lost in between?
That's where TCP (Transmission Control Protocol) comes into play. TCP is a
reliable protocol on top of IP. Compare it to i.e. ZModem: While the serial
line itself is not reliable, due to line noise or whatever, ZModem adds
checksums and a retransmission mechanism, so that a file transfered via ZModem
most reliably is the same at the receiving end like it was at the sending end.
That's exactly what TCP does, when a connection between computers via TCP gets
established, they exchange TCP/IP (TCP on top of IP) packets like this:
A) Hey I want to connect to you!
B) OK, come in!
A) Great, I have received your OK!
   Hey, BTW, here's some data for you!
B) Yup, got your data and the checksum seems ok, send me more!
A) Eat this!
B) Wait a minute, there was something wrong with that package, resend it!
A) OK, here we go again ...
   BTW that was the last package to be sent over our connection, let's close
   down
B) Oh well, see you later ...
Everywhere in that process packets may get lost, but most likely this will be
recognized by the TCP protocol and either data gets resent or the connection
gets closed down.

There's another new concept that comes into play with TCP: The concept of port
numbers. Where IP only says "this package is destined to IP address
aaa.bbb.ccc.ddd" (so to which computer / network interface it has to go in the
end), TCP adds: "... and it goes to port number xxx on that machine". What's a
port number? Well, down to the bits it's just a 16 bit word in the TCP
protocol header. I say it this way, so you understand that it's not related to
hardware in any way. The basic role of port numbers is that specific server
software waits for packets destined to a specific port number - one says the
server software is "listening" on that port.

While the IP address decides to which machine on the net a packet gets
delivered, the port number decides which application software on that machine
finally receives that packet for processing.

There's a bunch of standard port numbers for standard services defined, you
find these definitions in your "services" file (for Windows machines it's in
the "\windows" directory, on Unix it's in "/etc"). For example the standard
for FTP servers is port 21, so if you run a FTP server, it listens on port 21
and if someone connects to your FTP server he connects to port 21 on your IP
address. The standard port for HTTP (world wide web) services is 80, so if this
someone connects to your port 80 instead, he would be connecting to your web
server - if you run one. If someone connects to a port number on your machine
where there is no server software listening, no connection is established. As
you might have guessed, only one server software on one computer can listen on
a specific port. No two programs can listen on the same port at the same time.

The named standard ports are just conventions. You can instruct a FTP server
to listen on port 2000 instead, then someone connecting to your machine's IP
on port 2000 (written as aaa.bbb.ccc.ddd:2000 - aaa.bbb.ccc.ddd being
your IP address) would connect to your FTP server.

TCP is not the only protocol on top of IP. The next important one is UDP
(User Datagram Protocol). UDP, like IP itself, is not reliable. Data packets
(also called datagrams) are just sent out and either arrive ... or not. Sounds
crazy, but is not. As UDP has much less overhead compared to TCP it's faster
than TCP. You wouldn't want to use UDP for file transfer, but it's the
protocol of choice for i.e. audio transmission over the net, where it's
important that data gets delivered quickly, but not so important if a packet
or two get lost in between. As for TCP, with UDP you have 16 bit port numbers
and software listening on specific ports. TCP and UDP ports are
distinct from each other, so to be exact only one program can listen on one
TCP port, while another software can listen on the same
port for UDP (and vice versa). In fact there exists software that listens on
the same ports for TCP and UDP at the same time.

Now, you say, when I go surfing, I don't type in IP addresses, I use names like
"some.host.com". Yes, that's because some genius invented DNS (Domain Name
System). This is one service (like FTP or HTTP) with servers listening on UDP
port 53. Your ISP runs a name server. What happens when you connect to an
address like HTTP://some.name.com is that a part of your TCP/IP software
(the so called resolver) sends out an UDP packet to your ISP's name server
(port 53), asking "Hey, could you please tell me how to reach some.name.com?
I need the IP address!". If your ISP's name server knows it, it sends a packet
back with the requested information. If it doesn't know the given name it
goes asking other name servers until maybe finally the name server which is
"authoritative" for the "name.com" domain says - here's the IP address for
"some" or - there is no "some" in "name.com".  Or the name server for the
"com" domain says - there is no "name" within "com" or it says - go ask the
name server at IP address aaa.bbb.ccc.ddd, if you want to know what's up at
"name.com". Hope you get the picture. Here's a little quiz: When you tell your
TCP/IP software what name server to use, why do you have to type in the IP
address and not just "dns.myprovider.com"?

Now that we are talking about what your TCP/IP software needs to know before
it can work: I hope by now you understand that it needs to know its own IP
address and (in case of a point-to-point serial link) the IP address of the
other end, at your provider's (the gateway IP). If you want to use names
instead of IP addresses in your application software, it also needs to know the
IP address of a name server. Just to get the picture clear - the IP address of
whatever name server in the world would do the job (as the UDP packets to its
port 53 would reach it, hopefully), but it's preferable to use the IP address
of your ISP's name server, simply as you get the shortest response times from
there.

Getting back to PPP once more, it does not only do the "framing" of IP packets
so they can be sent over a serial link. Before PPP allows for delivery of IP
packets, there's a negotiation phase where exactly the information mentioned
above gets negotiated between the two ends involved: my IP address, your IP
address, maybe name server IP address and a couple of other options, like if
there have to be characters escaped over the link (XON/XOFF) or if
some compression protocol is to be used and last but not least a username /
password check if you are authorized to use that line. Both ends tell each
other about their capabilities and (hopefully) negotiate on the lowest common
denominator. This all happens automatically and has to happen before IP
packets can be sent over the link. It's one of the advantages of PPP over
SLIP, as with SLIP the user himself has to manually set all these parameters
and hopefully gets the correct ones, that work with the other end involved.

I did not yet mention it explicitly, but these other protocol acronyms you may
encounter like FTP, HTTP, IRC, Telnet, SMTP, POP, NNTP etc. are protocol
definitions on top of TCP/IP (speak utilizing TCP or UDP). These protocols are
one level higher, in that they define the protcols that server and
client application software use for their data exchange. While IP, TCP und UDP
deal with the format of the headers of packets sent over the link, these
protocols (FTP, HTTP etc.) deal with format of the data itself, the
content of the data packets that get exchanged, so that server and client
software understand each other.

Now, where does "Winsocket" fit in the picture?
In Unix, there's a programming interface for network functions, the Berkeley
Socket Library - The similar standard for Windows is the Winsocket definition,
a standard interface between the TCP/IP implementation and Windows application
software. The interface is realized in form of the winsock.dll (or
wsock32.dll for 32bit Windows), which is a common interface to applications.
The application software (server or client, doesn't matter) just loads
winsock.dll and uses its functions and thus doesn't need to know about the
underlying hardware. If you want to know what that "socket" talk is about: In
that programming interface, "socket" is the name for the combination of
protocol (UDP, TCP), IP address and port number. A socket defines the one end
of the communication, which takes place between two such sockets. I didn't
mention it before but there's always a port number involved on both ends of
the connection, not only the server side, but also the client side. Just only
the server side listens on specified standard ports, while the connecting
client end gets a port number assigned dynamically from the TCP/IP software.
The functions in the socket interface deal with creating sockets, making
them listen for and accept incoming connections or connect to sockets
listening on other machines. In order to use (Winsocket compatible) Windows
Internet software, you need one implementation of a winsock.dll (wsock32.dll).
There are different implementations (from different vendors and for different
hardware) around, but to the upper level of application software, these all
offer (more or less ...) the same interface.

One frequently asked question regarding Internet connections is if one can run
a multiplicity of software (or nodes in case of a BBS) over the same Internet
link / line. The answer is yes. The TCP/IP stack just delivers packets from one
IP/port combination to another IP/port combination. It doesn't care if these
come from one program alone or a multitude or programs. The only restrictions
are: No two programs on the same machine can listen for incoming connections
to the same port and: There is an implementation dependent maximum number of
sockets that can be open the same time (256 for Windows 95). In practice the
more important issue is that the bandwidth of your one connection gets shared
between all applications running packets over that line. You can have a FTP
client and a web browser running the same time, but if both of them retrieve
files at the same time over a 28.8k link, each of them will receive only 14.4k
(assuming there's no lag from the Internet itself). If one program is idle, of
course the other program can send / receive full speed.
