If you've ever wondered how Linux carries out the complicated tasks assigned to it by the IP protocols -- or if you just want to learn about modern networking through real-life examples -- Understanding Linux Network Internals is for you. Like the popular O'Reilly book, Understanding the Linux Kernel, this book clearly explains the underlying concepts and teaches you how to fol...
If you've ever wondered how Linux carries out the complicated tasks assigned to it by the IP protocols -- or if you just want to learn about modern networking through real-life examples -- Understanding Linux Network Internals is for you. Like the popular O'Reilly book, Understanding the Linux Kernel, this book clearly explains the underlying concepts and teaches you how to follow the actual C code that implements it. Although some background in the TCP/IP protocols is helpful, you can learn a great deal from this text about the protocols themselves and their uses. And if you already have a base knowledge of C, you can use the book's code walkthroughs to figure out exactly what this sophisticated part of the Linux kernel is doing. Part of the difficulty in understanding networks -- and implementing them -- is that the tasks are broken up and performed at many different times by different pieces of code. One of the strengths of this book is to integrate the pieces and reveal the relationships between far-flung functions and data structures. Understanding Linux Network Internals is both a big-picture discussion and a no-nonsense guide to the details of Linux networking. Topics include: * Key problems with networking * Network interface card (NIC) device drivers * System initialization * Layer 2 (link-layer) tasks and implementation * Layer 3 (IPv4) tasks and implementation * Neighbor infrastructure and protocols (ARP) * Bridging * Routing * ICMP Author Christian Benvenuti, an operating system designer specializing in networking, explains much more than how Linux code works. He shows the purposes of major networking features and the trade-offs involved in choosing one solution over another. A large number of flowcharts and other diagrams enhance the book's understandability.
NETDEV_TX_OK*
The transmission succeeded. The buffer is not released yet (kfree_skb is not
issued). We will see in the section “Processing the NET_TX_SOFTIRQ: net_tx_
action” that the driver does not release the buffer itself but asks the kernel to do
so by means of the NET_TX_SOFTIRQ softirq. This provides more efficient memory
handling than if each driver did its own freeing. (查看原文)
• The root bridge is the only bridge that generates BPDUs. The other bridges
transmit BPDUs only when they receive one (i.e., they revise the information
they receive by simply updating a couple of fields).
• The root bridge makes sure each bridge in the network comes to know about a
topology change when one occurs (see the section “Topology Changes”). (查看原文)
“The function consists of a wrapper that grabs the lock, does its work by invoking a function whose name begins with two underscores, and releases the lock.”翻译成：此函数内有一个包裹函数会取得回转锁，然后调用一个以两个下划线符号开头命名的函数，接着再释放...
(展开)
342页图15-15中listening状态若是否下一个判断是否learning,图中出现两个listening 350页图15-20中,bpdu报文格式有问题,mac源地址在前,目的mac在后,和业界惯例不符,英文原版就是如此,不知道为什么. 还有一处笔误,在273页，原文是“ And a similar choice must be made going ...
(展开)
One important detail to keep in mind is that Scatter/Gather I/O is independent from IP data fragmentation. Scatter/Gather I/O simply allows the code and hardware to work on nonadjacent memory areas as if they were adjacent. Nevertheless, each frag- ment must still respect the limit on its maximum size (the PMTU). This means that even if PAGE_SIZE is bigger than the PMTU, a new sk_buff will be c...
2013-01-03 23:23
One important detail to keep in mind is that Scatter/Gather I/O is independent from
IP data fragmentation. Scatter/Gather I/O simply allows the code and hardware to
work on nonadjacent memory areas as if they were adjacent. Nevertheless, each frag-
ment must still respect the limit on its maximum size (the PMTU). This means that
even if PAGE_SIZE is bigger than the PMTU, a new sk_buff will be created when the
data in sk_buff (pointed to by skb->data) plus the ones referenced with frags reaches
the PMTU.
Note also that the same page can hold fragments of data for different IP fragments, as
shown in Figure 21-8. Each fragment of data added to the memory page increments
the page’s reference count. When the IP fragments are finally sent out and the data
fragments in the page are released, the reference count is decreased accordingly and
the memory page is released (see skb_release_data, which is called indirectly by
kfree_skb).
引自第490页
The minimum MTU associated with a route is in fact 68, which comes from RFC 791. Since the IP header can be up to 60 bytes long (20+40) and the minimum frag- ment length (with the exception of the last one) is 8 bytes, it follows that every IP router must be able to forward an IP packet of 68 bytes without any further fragmentation.
2013-01-01 11:29
The minimum MTU associated with a route is in fact 68, which comes from RFC
791. Since the IP header can be up to 60 bytes long (20+40) and the minimum frag-
ment length (with the exception of the last one) is 8 bytes, it follows that every IP
router must be able to forward an IP packet of 68 bytes without any further
fragmentation.引自第449页
Few C programmers like the goto statement. Without getting into the history of the goto (one of the longest and most famous controversies in computer programming), I'll summarize some of the reasons the goto is usually deprecated, but why the Linux kernel uses it anyway. Any piece of code that uses goto can be rewritten without it. The use of goto statements can reduce the readability of the co...
2011-11-16 16:08
Few C programmers like the goto statement. Without getting into the history of the goto (one of the longest and most famous controversies in computer programming), I'll summarize some of the reasons the goto is usually deprecated, but why the Linux kernel uses it anyway.
Any piece of code that uses goto can be rewritten without it. The use of goto statements can reduce the readability of the code, and make debugging harder, because at any position following a goto you can no longer derive unequivocally the conditions that led the execution to that point.
Let me make this analogy: given any node in a tree, you know what the path from the root to the node is. But if you add vines that entwine around branches randomly, you do not always have a unique path between the root and the other nodes anymore.
However, because the C language does not provide explicit exceptions (and they are often avoided in other languages as well because of the performance hit and coding complexity), carefully placed goto statements can make it easier to jump to code that handles undesired or peculiar events. In kernel programming, and particularly in networking, such events are very common, so goto becomes a convenient tool.
I must defend the kernel's use of goto by pointing out that developers have by no means gone wild with it. Even though there are more than 30,000 instances, they are mainly used to handle different return codes within a function, or to jump out of more than one level of nesting.引自第8页
NETDEV_TX_OK* The transmission succeeded. The buffer is not released yet (kfree_skb is not issued). We will see in the section “Processing the NET_TX_SOFTIRQ: net_tx_ action” that the driver does not release the buffer itself but asks the kernel to do so by means of the NET_TX_SOFTIRQ softirq. This provides more efficient memory handling than if each driver did its own freeing. 这也是为什么在...
2012-12-18 15:17
NETDEV_TX_OK*
The transmission succeeded. The buffer is not released yet (kfree_skb is not
issued). We will see in the section “Processing the NET_TX_SOFTIRQ: net_tx_
action” that the driver does not release the buffer itself but asks the kernel to do
so by means of the NET_TX_SOFTIRQ softirq. This provides more efficient memory
handling than if each driver did its own freeing.引自第248页
• The root bridge is the only bridge that generates BPDUs. The other bridges transmit BPDUs only when they receive one (i.e., they revise the information they receive by simply updating a couple of fields). • The root bridge makes sure each bridge in the network comes to know about a topology change when one occurs (see the section “Topology Changes”).
2012-12-23 21:48
• The root bridge is the only bridge that generates BPDUs. The other bridges
transmit BPDUs only when they receive one (i.e., they revise the information
they receive by simply updating a couple of fields).
• The root bridge makes sure each bridge in the network comes to know about a
topology change when one occurs (see the section “Topology Changes”).引自第317页
One important detail to keep in mind is that Scatter/Gather I/O is independent from IP data fragmentation. Scatter/Gather I/O simply allows the code and hardware to work on nonadjacent memory areas as if they were adjacent. Nevertheless, each frag- ment must still respect the limit on its maximum size (the PMTU). This means that even if PAGE_SIZE is bigger than the PMTU, a new sk_buff will be c...
2013-01-03 23:23
One important detail to keep in mind is that Scatter/Gather I/O is independent from
IP data fragmentation. Scatter/Gather I/O simply allows the code and hardware to
work on nonadjacent memory areas as if they were adjacent. Nevertheless, each frag-
ment must still respect the limit on its maximum size (the PMTU). This means that
even if PAGE_SIZE is bigger than the PMTU, a new sk_buff will be created when the
data in sk_buff (pointed to by skb->data) plus the ones referenced with frags reaches
the PMTU.
Note also that the same page can hold fragments of data for different IP fragments, as
shown in Figure 21-8. Each fragment of data added to the memory page increments
the page’s reference count. When the IP fragments are finally sent out and the data
fragments in the page are released, the reference count is decreased accordingly and
the memory page is released (see skb_release_data, which is called indirectly by
kfree_skb).
引自第490页
The minimum MTU associated with a route is in fact 68, which comes from RFC 791. Since the IP header can be up to 60 bytes long (20+40) and the minimum frag- ment length (with the exception of the last one) is 8 bytes, it follows that every IP router must be able to forward an IP packet of 68 bytes without any further fragmentation.
2013-01-01 11:29
The minimum MTU associated with a route is in fact 68, which comes from RFC
791. Since the IP header can be up to 60 bytes long (20+40) and the minimum frag-
ment length (with the exception of the last one) is 8 bytes, it follows that every IP
router must be able to forward an IP packet of 68 bytes without any further
fragmentation.引自第449页
心动
飞公爵
中国电力出版社2009版
Melo
中国电力出版社2009版
jam lin
东南大学出版社2006版
0 有用 optman 2014-05-30
很翔实，我主要看了Neighboring子系统，没想到ARP可以讲这么多。
0 有用 Firo 2013-08-27
在看网桥， 说理还好， 就是啰嗦。。。。纰漏亦不少。。可以一看
0 有用 xc 2012-12-20
网桥相关（占了书200页）实现没看，不包含tcp协议。
1 有用 kiven 2013-10-16
介绍的是3层以下的协议和实现。如果想看TCP等上层协议的实现，不建议看这本，这本应该写给路由器开发人员的。
0 有用 UnHombre 2020-10-31
要是基于5.x内核就更棒了！
0 有用 UnHombre 2020-10-31
要是基于5.x内核就更棒了！
0 有用 optman 2014-05-30
很翔实，我主要看了Neighboring子系统，没想到ARP可以讲这么多。
1 有用 kiven 2013-10-16
介绍的是3层以下的协议和实现。如果想看TCP等上层协议的实现，不建议看这本，这本应该写给路由器开发人员的。
0 有用 Firo 2013-08-27
在看网桥， 说理还好， 就是啰嗦。。。。纰漏亦不少。。可以一看
0 有用 xc 2012-12-20
网桥相关（占了书200页）实现没看，不包含tcp协议。