How the Internet Really Works

The Internet is a packet-switched, fault-tolerant network. Packet switching means that information is broken down into small packets (usually a few bytes or kilobytes in size) and sent from point A to point B by traversing a weblike server structure (which we commonly call cyberspace). By saying the Internet is fault-tolerant, we mean that packets are sent using paths that adapt to network circumstances, errors, server malfunctions, and so on. If a server goes down, packets will use alternative paths to reach their destination. As a corollary of both these principles, a large block of information sent between two communicating peers does not necessarily need to follow a unique route. Some packets might use different paths to take advantage of the network's status.

Packet-switched networks differ from circuit-based networks. In circuit-based networks, we "own" a private communication circuit from the origin to the destination, which we access exclusively. In a circuit system, we have a path from the origin to the destination, and we simply transfer all the information as a single block. A classic example of such systems is the "traditional" (nondigital) telephone system.

It is very intuitive to picture the Internet as a large factory. On one end of the communication pipeline, a machine breaks data into smaller pieces, so it can be transferred efficiently. These packets of information are then numbered and sent through a vast network of Internet servers, sometimes using separate routes. Once these packages reach their destination (probably not in the correct order), a second factory looks at the serial numbers and puts the data back together in a meaningful way.

Clearly, there are two tasks taking place at very high speeds. First, data is fragmented and reassembled. Second, individual packets are routed through the Internet. These two tasks are performed by two protocols working in parallel. Transmission Control Protocol (TCP) is the data separator and assembler, and Internet Protocol (IP) takes care of the routing. So now you know what TCP/IP is about: dividing data into blocks so it's easier to transfer and then routing it efficiently.

In network programming jargon, TCP is said to be a connection-oriented protocol. In other words, the protocol keeps a permanent connection open between two (or more) peers. Notice how this does not necessarily imply a dedicated, fixed communication channel. Because IP performs dynamic routing, some data might follow different courses in order to reach its destination. But TCP works on top of IP, providing a logical end-to-end connection that can be used at any time.

TCP/IP is recommended for "traditional" networking. Connection-based protocols guarantee FIFO operation (data arrives in the right order) and ensure that all data sent from one end of the TCP stream will reach its destination. A variety of mechanisms allow the receiver to detect lost packets, re-request them, and thus make sure all the data is received (in the right order). However, there is a downside: Connection-based protocols are slow. They need to wait for several packets to arrive to rebuild the initial sequence, and they check for lost packets. As a result, they provide secure transmission at the cost of reduced performance.

Another protocol exists that can be used to replace the TCP in TCP/IP. It's a very lightweight protocol that sacrifices some of the "slower" features for the sake of speed. It is the User Datagram Protocol (UDP), and because it does not require an active connection, it is said to be a connectionless protocol. UDP allows us to send fixed-size packages of information between two endpoints. These packages might or might not reach their destination (although they almost always do). Additionally, they might not arrive in sequential order. A package might be routed through a faster server path, thus passing other packages emitted before it. But UDP offers very good performance. Table 10.1 lists the differences between TCP and UDP.

Table 10.1. Differences Between TCP and UDP

TCP	UDP
Keeps connection	Does not keep connection
Variable-size packets	Fixed-size packets
Guarantees reception	Does not guarantee reception
FIFO	Not necessarily FIFO
Slow	Fast

However, it would be wrong to think of UDP as "good" and TCP as "bad" per se. The protocol you choose depends on what you are trying to code. If you need to code a strategy game where lags are acceptable but each move is essential for the sake of the game, TCP is still the way to go. It is a slower protocol, but the pacing of your game will be able to handle that well. If you need to code something like a first-person shooter running at 60 fps on today's networks, TCP will most likely be too slow for you, and UDP's packet loss will be a minor inconvenience.

For the remainder of this chapter, we will discuss both protocols in detail, showing examples of both in use and exposing potential pitfalls, so you can make an informed decision about which one to use.