Why Practice and Implementation Matter in Learning Computer Networks

Hello everyone, I’m Fei. In the Internet era, networking is arguably the most important technology, yet both students and working engineers often suffer from two problems in learning networks.

1. Insufficient Emphasis on Practice

Most computer‑science curricula focus heavily on theory, leading many to stop at reading without actually writing code or running tests. According to Edgar Dale’s 1946 Pyramid Learning Theory, passive learning yields about 10% retention, while hands‑on practice can exceed 75%.

The proper approach is to combine theory with practice. Practice can be divided into two categories: using command‑line tools for observation and writing programs for verification.

For students, start with a Linux machine (most engineers already use Linux). Linux provides many mature networking tools such as curl , tcpdump , systemtap , and perf . Use these to observe packet flows, connection handshakes, and kernel behavior.

For example, launch an Nginx server (or write a simple server), use curl to initiate TCP connections, and capture packets with tcpdump . Advanced users can explore systemtap or perf for deeper insights.

Programming exercises can start with a basic TCP client/server, then progress to an FTP server/client or a simple web server serving static files. You can also build a tiny network library based on projects like Libevent, Redis, or Sogou WorkFlow, or even implement a packet‑capture tool similar to tcpdump (see my referenced article for a demo).

Engineers should also test performance differences, such as comparing read/write loops with sendfile , measuring zero‑copy benefits, or evaluating QPS with raw epoll versus Go’s net package.

Through such experiments, you gain a qualitative boost in performance understanding.

2. Insufficient Emphasis on Implementation

Most networking textbooks focus on protocols but rarely explain how they are implemented inside the OS. Without this knowledge, developers struggle with real‑world issues and performance tuning.

Key implementation questions include why a server must call listen before accept , how many TCP connections a machine can sustain, and how a network packet travels from the NIC to a process.

Understanding these details enables you to diagnose problems like long TCP handshakes, high memory consumption per connection, or why synchronous blocking I/O is slower than epoll‑based I/O.

I have written several articles dissecting these topics, such as why servers call listen , how client port numbers are chosen, and deep dives into the three‑way handshake.

Why Server Programs Must Call listen First?

How Is the Client Port Determined in a TCP Connection?

Understanding the Three‑Way Handshake Deeply

I also authored articles on how Linux receives and sends network packets, illustrated with dozens of diagrams.

Diagram of Linux Packet Reception Process

25 Diagrams, 10k Words: Dissecting Linux Packet Transmission

Understanding Localhost (127.0.0.1) Communication

Additional articles cover synchronous blocking I/O versus epoll, explaining why epoll improves performance.

Deep Dive into Synchronous Blocking Network I/O

How epoll Implements I/O Multiplexing

All these resources are available under the “Inner Kung Fu” menu of my public account, and the source code is hosted on GitHub at https://github.com/yanfeizhang/coder-kung-fu . I also compiled a PDF titled “Understanding Implementation Before Discussing Network Performance”; feel free to contact me on WeChat for a copy.

Hope everyone’s technical abilities keep rising.