The italic part is a question from the reader
After reading Richard Stevens’ TCP/IP Protocol Volume 1: Detailed Explanation for a long time, I feel that it is quite difficult to read. How should I learn what the TCP/IP protocol is really about? What can I do after understanding the TCP/IP protocol? I would appreciate any guidance.
Update Section
Some readers asked me to recommend introductory textbooks, those that are easy to understand. Frankly speaking, such textbooks do not exist; network technology has a certain threshold that one must be aware of.
Steven’s book is very well written, but it is indeed a bit difficult for beginners. So what should beginners do? Since it is difficult, they should find some basic introductory courses to study, such as CCNA tutorials, to at least understand what a collision domain, broadcast domain, the process of a network card sending and receiving frames, subnet masks, gateways, and ARP are.
Once you have a basic understanding, you can return to this English book, as the earlier sections are still quite understandable. Do not be greedy and rush in; learning should be gradual. It is also expected that beginners will not understand the later parts about TCP. As for how to learn TCP, I have written many articles about TCP on Zhihu, which can be considered my personal notes. I will slowly update them on my public account; interested readers can accumulate knowledge gradually. Time is the best friend!
In simple terms, TCP/IP as a whole is very similar to modern logistics/courier companies. The courier company acts as an agent for the user, fully responsible for delivering a package from the point of origin to the destination; all transportation details are the courier company’s responsibility, and the user only needs to receive and send packages.
TCP/IP is also the logistics company in network communication. The application only needs to submit the data that needs to be transmitted to TCP/IP, and TCP/IP can package the data and send it to the destination. The application does not need to worry about the transmission details, allowing it to be liberated from the lowest-level transmission details and focus more on processing the application data itself.
However, whether you are a network engineer or a software engineer, you should spend some time studying the TCP/IP protocol itself. As a large logistics company, TCP/IP contains many functional departments. For example, IP is specifically responsible for finding the destination on the Internet and delivering the package there.
Readers may wonder, since IP can deliver the package to its destination, what is the role of TCP?
If we compare IP to the truck and driver of the logistics company, then TCP is the dispatch center of the logistics company. If the logistics company/driver falls into a river, causing the package to be lost, TCP as the dispatch center can analyze and determine the situation, then activate the emergency mechanism, reassigning a new truck and driver to transport the customer’s package until confirmation is received from the receiving logistics company.
The only difference between this scenario and real life is that in real life, if a package is lost, it is lost; how can it be retransmitted? Does the logistics company perform magic to create a new one?
However, in TCP/IP protocol communication, making a copy of the user’s data is very simple. Once a loss is detected, TCP, as the dispatch center, can simply retransmit it.
Main Text
Let’s start with the automotive industry. With the popularization of family cars, more and more people are starting to use cars. Among them, 99% of people may only know how to drive and do not know how to repair cars or understand their internal structure (details), but this does not affect our use of cars.
For automotive repair engineers, it is evident that they must be proficient in the internal structure of cars. Very experienced engineers can locate faults by the sound of the car, relying on years of experience. For young engineers just entering the field, merely reading the car repair manual, even if they read it a thousand times, may not enable them to repair cars. Often at a 4S shop, you see mechanics disassembling severely damaged cars, sometimes with experienced workers guiding them. Through these hands-on operations, along with the master’s guidance, and referring to the repair manual, it doesn’t take long for them to become proficient in repairing cars. This model: hands-on + theory + master guidance is also applicable to learning computer networks.
For 99% of users, there is no need to understand computer networks; computers and mobile phones can automatically connect to the Internet. Even if there are problems, unplugging and plugging the cables, restarting the computer, or rebooting the wireless router can solve over 90% of issues. However, as a network professional, one needs to be proficient in the principles of computer networks, as understanding these principles can help non-professionals provide professional services.
The TCP/IP protocol is not the entirety of computer networks, but it covers the third layer and fourth layer of the OSI reference model, namely the network layer and transport layer. TCP/IP is not just TCP and IP; it is a collective term for the protocol stack, which also includes ARP, ICMP, IGMP, UDP, as well as DNS, which makes domain name access possible, and DHCP, which allows computers and mobile phones to automatically obtain IP addresses. Of course, there are also various application layer protocols such as HTTP, SMTP, FTP, etc.
Returning to the question itself, “Detailed Explanation of TCP/IP Protocol Volume 1” is a very good textbook, but is it useful to just read the book? The effect is very poor because this book is somewhat difficult. Not engaging in hands-on practice leads to a lack of perceptual understanding, and readers become increasingly confused by abstract concepts, finding it more and more boring, ultimately throwing the book away. I have done this many times before, then picked it up again after a while…
If just reading the book is boring, then let’s get hands-on. At that time, I was working in a state-owned enterprise, where the company’s network was isolated from the Internet, and QQ could not be used. So I followed the Visual C++ tutorial to write a chat program (based on TCP socket) and gave this program to my colleague downstairs. When we were bored, we would chat, such as when to go for lunch or when to leave work. When the program started, I began to capture packets to see how the chat content was encapsulated and how many packets were needed to complete the sending task.
Encapsulation was quite simple, but I was surprised that a single message actually consumed 9 packets in both directions. I was puzzled, as it was just a call to connect() to establish a connection, a call to send(), and then the program exited.
TCP Connection EstablishmentSo I went back to the book, this time with a specific focus, directly flipping to the TCP protocol section to see how TCP establishes a connection. I found that establishing a connection requires the interaction of three packets, which should be completed by connect().
TCP Sending DataThen I saw that my message content was one packet, and the other party had no data, only an ACK confirmation, which is two packets, triggered by send().
TCP Connection ReleaseThen the system exited automatically. Although my program did not call any functions, the system automatically called the close() function for me, thus triggering the TCP connection closure, which accounted for four packets.
So I added up the exchanges of these three stages: 3 + 2 + 4 = 9. Oh, so this is how it works! Through this small program, I found it very interesting to look at the book with a specific focus.
Later, I tried to write a chat program using UDP socket, and it could be done simply by calling the Sendto() function (using IP access). Upon capturing packets, I saw that one message was one packet, and there was no confirmation from the other party. UDP just sends it out with an encapsulation header, requiring no connection establishment and thus no connection closure.
Later, I needed to write a simulation program that mimics a GPS receiver sending GPS latitude and longitude information to a navigation device every 100ms. The interface was Ethernet, and the navigation device had an embedded operating system that supported the TCP/IP protocol stack. With previous hands-on experience, I quickly wrote simulation software based on TCP socket, and it worked normally. However, sometimes there would be delays in sending data, sometimes fast, sometimes slow, and sometimes it would stop sending. So I began analyzing the network. The office network was connected from the switch port to the wall, and then used a HUB to split more ports for everyone to share bandwidth. This made me think of the CSMA/CD mechanism. The computers operated in half-duplex mode, needing to listen to the network before sending data. When the network was busy, everyone would compete, causing significant delays.
So I wrote the same software using UDP socket, and the delay phenomenon improved a lot. Later, I analyzed that because UDP packets have no self-restraint mechanism, calling the sendto() function just sends the data to IP, which sends it to the network card. The network card has the CSMA/CD mechanism, which will wait, possibly causing delays, or due to conflicts, packets may be discarded and retransmitted, or poor line quality may cause CRC errors leading to discards. But my program did not care; it still sent a group of data every 100 milliseconds. Therefore, I ultimately chose UDP for the transmission mechanism. Losing one or a few groups of data does not matter much, as long as the latitude and longitude data can be transmitted.
The stories I wrote aim to express that learning protocols must involve hands-on practice, preferably in conjunction with projects. Then, one needs to supplement the necessary theories and refer to the books with a specific focus. For every unfamiliar protocol, one must capture packets and analyze them. Do not be lazy; you reap what you sow.