Table Of ContentTHE TCP/IP GUIDE
Charles M. Kozierok
Editor
William Pollock
Copyright © 2005
For information on book distributors or translations, please contact No Starch Press, Inc. directly:
No Starch Press, Inc.
555 De Haro Street, Suite 250, San Francisco, CA 94107
phone: 415.863.9900; fax: 415.863.9950;
reason. Who plays a more important role in the life of an author than his or her
spouse? Robyn is my partner—the person who is always there and the one who
shares my life in so many ways. The expression about a great woman being behind
every good man is true, yet my wife is deserving of recognition for reasons that go
far beyond the usual one of being "supportive."
She agreed to take on a regular working position to make it possible for me to
spend time on a very long project with an uncertain payoff. She took on most of
the tasks of taking our children to school and dealing with their needs, to give me
time to write. She also gracefully agreed to "do without" many things that many
other wives would not have been too happy about forgoing.
But most of all, she deserves a world of credit for putting up with me. For
constantly reassuring me that it was okay that I was spending years on a project
that might not be successful. For listening to me talk for countless hours, and for
giving her opinions on many portions of my writing, all on a subject that really
doesn't interest her. And most important, for encouraging me when I felt this was a
waste of time, and even kicking me in the butt when I felt like giving up. Without
Robyn, this book simply would not exist. Thanks, R.
My three boys deserve credit for similar reasons, but to a lesser extent. They have
had to put up with my constantly sitting at the computer, trying to tune them out so
I could concentrate; my too-frequent grouchy moods; and my reluctance to spend
time with them when I had work on my plate. I am sure there were many times
that they wished I just had a regular "day job."
Ryan, my big boy, has been very patient in waiting for me to finish this project so
we can resume several activities that we used to engage in regularly. Matthew, my
fun-loving and rambunctious middle son, has also had to deal with me not being
able to spend as much time as I would have liked with him. And little Evan has had
a father working on a long-term project for his entire life! All three of my boys
have been very understanding and provided me with much-needed joy and laughter
at times when I needed them most.
ABOUT THE AUTHOR
I was born in 1966 in Windsor, Ontario, Canada and raised in nearby Toronto. I
married my wife Robyn in 1990; we now live in southern Vermont with our three
sons, Ryan (12), Matthew (9), and Evan (4).
I have had an interest in the field of computers ever since my early years, starting
at the age of 14 when I received my first computer, an Apple ][, a gift from my
parents. Since that time, I have worked in various computer-related fields in
hardware and software. In 1989, I obtained a Bachelor of Applied Science from
the University of Waterloo, in Waterloo, Ontario, Canada. I completed my formal
education in 1993 with two master's degrees, in management and in electrical
engineering and computer science (EECS), from MIT.
After a brief "conventional" technical career, I created and published The PC
Guide, an extensive online reference work on personal computers, and in 1998, I
decided to devote myself to my writing projects full time. The TCP/IP Guide was
part of a larger networking project that I spent time on earlier this decade. I
continue to work in the technical writing and editing field on various projects, for
myself and other companies.
You may have noticed something missing here: no impressive listings of
credentials. No, I'm not a New York Times best-selling author; I haven't been a
professor at a prestigious Ivy League university for a quarter century; neither am I
a top executive at a Silicon Valley giant. In some ways, I am a student of
technology, just as you are. And my experience over the years has shown me that
many of the people who know the most about how technology works have rather
limited success in explaining what they know in a way that will allow me to
understand it. My interests, and I believe my skills, lie not in being an expert, but
in serving as an educator, presenting complex information in a form that is
sensible, digestible, and fun to read.
When I'm not working—all too rare these days—I spend time with my family and
enjoy the peaceful quiet and natural beauty of the state of Vermont. I am also an
avid amateur photographer, with interests particularly in nature and landscapes.
ACKNOWLEDGMENTS
I dedicated this book to my wife and children to reflect the important role they
have played in my life in general terms, and in accomplishing this book in
particular. However, many others also contributed to the completion of this
document, and I'd like to take a moment to acknowledge them.
I want to thank my "original" family: my father, Leon, and sisters, Cari and Cindy,
for being supportive and lending a helpful ear about various issues during the time
I've been engaged in this project. Thanks also to my "adoptive" family: Eli, Marge,
Larry, and Steven. And I definitely want to thank the small group of close friends
who have helped with ideas, advice, and much-needed laughs.
I would also like to specifically acknowledge the following individuals and
organizations for their assistance:
Bill Pollock, president and publisher of No Starch Press, for constantly
expressing his faith in my abilities as an author, for being a sounding board, and
for agreeing to publish this book. My thanks also to Susan Berge, Riley
Hoffman, and everyone else at No Starch for putting up with me during this
long project and helping make this book a reality.
Adobe Systems Incorporated, for providing this relatively unknown author with
two important pieces of software that I used in creating this book. First, Adobe
FrameMaker, one of the best desktop publishing programs around, which was
used to format and publish this document. Second, Adobe Photoshop, the
industry-standard program for photo and graphics editing, which was used for
processing graphics and other tasks.
Frank Stearns, creator of the IXgen tool for FrameMaker. Without IXgen, it
would have taken ten times longer to make the index for this book, and Frank
himself was very generous with his time in answering questions from a newbie
indexer (me!).
SmartDraw.com, for the excellent SmartDraw diagramming software that was
used to create most of the more than 300 illustrations that appear in this book.
Fernando Gont and Barry Margolin, for their excellent technical review of The
TCP/IP Guide, and their corrections and suggestions for improvement to the
book.
Tcat Houser, author and instructor, whose generosity, positive attitude, and
enthusiasm for my writing helped boost my confidence as I worked to complete
this project.
All the regulars at The PC Guide Discussion Forums, for creating a fun
community, keeping the site active, and agreeing to provide opinions on my
writing. In fact, everyone who has supported The PC Guide and my other
websites, financially and otherwise, helped make it possible for me to spend
time on this project.
I've probably missed a few people who should be on this list; I hope all who are
deserving of my appreciation will forgive their omission and accept my thanks.
INTRODUCTION
Goals of The TCP/IP Guide
Every author who sets out to write a book or other document has certain objectives
that he or she hopes to accomplish when the work is completed. This is why you
can go into a library or bookstore, pick up several books that cover the same
subject, and discover that they are surprisingly different—not just in their content
or scope, but in their entire approach to the material.
I, too, had a number of goals when I set out to write this book. You certainly don't
need to know them in order to read and appreciate the material, but understanding
what I had in mind while I was writing may help you while you are reading. And if
you are reading this information prior to buying The TCP/IP Guide, knowing what
I strove for in writing the book may help you decide if this is the right resource for
you.
My overall goal in writing this book was to create a resource that would allow
anyone to obtain a deep understanding of how TCP/IP technologies really work. To
accomplish this, I had a number of specific objectives that guided my writing
efforts:
Comprehensiveness Like most authors writing a resource that covers a large
subject, I wanted The TCP/IP Guide to be comprehensive. Of course, no single
document can cover everything, so I have needed to limit the scope of the material.
However, I feel I cover more about TCP/IP as a whole than any other single book
or other resource.
Comprehensibility Creating a resource that is comprehensive is important, but I
felt that it was even more important that the book be comprehensible. Over the
past few years, I've had the opportunity to review many hundreds of books, guides,
websites, and papers related to networking. I have found that even though most of
them are generally high in quality, too many use unexplained technical jargon or
assume extensive prior knowledge of networking concepts and technologies on the
part of the reader. I worked very hard to ensure that my descriptions, even of very
complex concepts, can be understood by almost every student of networking.
Rationale It's certainly important to know how every TCP/IP protocol functions.
However, to gain a true understanding of complex material, one also needs to
understand the reasons behind why things are what they are. In writing this
material, I have always tried to explain not just the what, but also the why of
TCP/IP. I have anticipated and answered questions that I believe might commonly
arise in the mind of someone learning about this technology.
Illustrations A picture is worth a thousand words, as they say. There are many
concepts that no amount of verbiage will adequately explain, while a simple
illustration will do the trick. For this reason, I spent many months creating more
than 300 diagrams (some simple and some not so simple!) to complement the
written material in The TCP/IP Guide.
User-friendliness I have intentionally broken many of the rules of conventional
book authorship, in creating a document that uses a conversational, first-person
style, and no small amount of humor where appropriate. My intention was to make
you feel at home while you read material that can be quite technically difficult. I
want you to think of me as a friend sitting next to you at your computer explaining
how TCP/IP works, rather than a professor preaching at you from a podium.
Organization Many networking books consist of dozens of subjects just listed one
after the other, leaving the reader to wonder how everything fits together. When I
first began this book, I spent weeks just organizing it, with the result being a
structure that indicates clearly how subjects are interrelated. I also carefully laid out
each individual section to ensure that it covered its topic in a way that made sense.
Multiple levels of detail I realize that some people reading a TCP/IP book might
want only a quick summary of the operation of its constituent protocols, while
others want to learn all the nuances of how everything works. I have provided the
full details that most readers will want, while also including overview topics in each
chapter that summarize each technology for quick perusal. This gives you the
option of either skimming the surface or "diving deep," as you choose.
Platform independence I have endeavored whenever possible to avoid describing
TCP/IP in terms specific to any hardware or software platform. Even though I use
a PC for most of my computing and UNIX for some tasks, most of the material is
not particular to any type of device or operating system (though I do focus more on
networks of smaller computers than larger ones).
How successful was I in achieving these goals? I'd like to think I did a pretty good
job, but ultimately, you will be the judge!
Scope of The TCP/IP Guide
The first step to dealing with a problem is recognizing that you have one. So, I
have to come clean with you, my reader. I have a problem: an addiction to …
detail. Every time I set out to write about a particular protocol, technology, or
concept, I start with a modest goal regarding how much I want to write. I always
begin knowing that I really need to control myself, to prevent my project from
going on forever. But as I explore each subject, I learn more and more, and I start
to say to myself things like, "This is important. I simply must include coverage for
it," and, "If I'm going to cover subject #1, I also should cover subject #2, because
they are related." This is how I turn six-month projects into multiyear ordeals.
However, even though self-control in this area is a weakness for me, even I realized
I could not possibly cover everything related to TCP/IP in this book. Consider that
the TCP/IP suite contains dozens of protocols and technologies, each written about
in thick books. I was willing to spend years on this project, but not decades! Thus,
I had to limit the scope of this book somewhat, both to preserve what remains of
my sanity and to spare you from having to wade through a ridiculously large
document.
Here are a few different points that will help explain decisions that I made to limit
the scope of The TCP/IP Guide:
Theory versus practice This is primarily a reference resource on the TCP/IP
protocol suite. The material here is designed to allow a student to learn the nuts
and bolts of how TCP/IP works. I do discuss quite a number of "real-world"
practical issues related to how TCP/IP internetworks operate, but this is not my
primary focus here. If you want to really understand what TCP/IP is and what
makes it work, you've come to the right place. If all you want is simple instructions
on how to connect a few PCs together in your home using TCP/IP, this probably
isn't the book for you.
Current versus future protocols Most of the emphasis in this book is on the
present state of the art in TCP/IP. The suite is always changing, new protocols are
constantly being written, and revisions to existing protocols continue to be
published. I have not provided extensive coverage of technologies still in
development, to try to keep the size of the book manageable and to prevent the
