深入理解Linux网络内核机制

1星需积分: 9 104 浏览量更新于2024-07-19 收藏 17.76MB PDF 举报

"理解Linux网络内部机制" 本书《理解Linux网络内部机制》深入探讨了Linux内核网络协议的具体实现细节，适合对操作系统内核和网络编程感兴趣的读者，特别是那些希望了解Linux网络栈工作原理的开发者和系统管理员。书中通过详细的章节划分，逐步揭示了Linux网络系统的基础、关键数据结构、用户空间到内核接口以及系统初始化等核心概念。在第一部分“一般背景”中，第一章介绍了基础知识。1.1节讲解了网络术语，如套接字、协议、端口等基本概念。1.2节阐述了常见的编码模式，帮助读者理解代码设计思路。1.3节提到了一些用户空间工具，如tcpdump和ping，这些工具在分析网络行为时非常有用。1.4节指导读者如何浏览Linux内核源码，以便于学习和调试。1.5节讨论了当新特性以补丁形式提供时的情况，解释了如何评估和应用这些补丁。第二章“关键数据结构”是理解内核网络处理的核心。2.1节深入剖析了socket缓冲区sk_buff结构，它是数据包在内核中传输的主要数据结构。2.2节介绍了net_device结构，它表示网络设备并在内核中管理网络接口。这两个数据结构在处理网络数据包的收发过程中起到关键作用。第三章“用户空间到内核接口”详细介绍了多种通信方式。3.1节概述了这些接口的重要性。3.2节对比了procfs和sysctl两种系统调用接口，它们允许用户空间程序读写内核状态。3.3节讲述了ioctl命令，用于设备控制。3.4节介绍了Netlink，一种在用户空间和内核之间传递复杂消息的机制。3.5节讨论了配置变更的序列化，确保了在网络配置更改时的一致性。第二部分“系统初始化”中，第四章“通知链”是关于网络子系统启动和配置的重要部分。4.1节指出了为何需要通知链，即在系统启动或配置更改时确保正确执行操作。4.2节给出了通知链的概览。4.3节和4.4节分别介绍了定义和注册通知链的步骤。4.5节描述了在链上触发事件的方法，4.6节则详细阐述了网络子系统的通知链如何工作。最后，4.7节提到了通过/proc文件系统进行性能调整的可能性。通过这本书，读者将能够深入理解Linux内核如何处理网络通信，掌握关键的数据结构和接口，并了解系统初始化过程中的关键组件。这不仅有助于提高故障排查能力，也有助于开发更高效、更稳定的网络应用程序。

task. Because of that, it is common for a lookup routine to increase the reference

count on the matching element, and let the caller release it when necessary.

When the last reference to a data structure is released, it may be freed because it is not

needed anymore, but not necessarily.

The introduction of the new sysfs filesystem has helped to make a good portion of the kernel

code more aware of reference counts and consistent in its use of them.

1.2.4. Garbage Collection

Memory is a shared and limited resource and should not be wasted, particularly in the kernel

because it does not use virtual memory. Most kernel subsystems implement some sort of

garbage collection to reclaim the memory held by unused or stale data structure instances.

Depending on the needs of any given feature, you will find two main kinds of garbage

collection:

Asynchronous

This type of garbage collection is unrelated to particular events. A timer that expires

regularly invokes a routine that scans a set of data structures and frees the ones

considered eligible for deletion. The conditions that make a data structure eligible

for deletion depend on the features and logic of the subsystem, but a common

criterion is the presence of a null reference count.

Synchronous

There are cases where a shortage of memory, which cannot wait for the

asynchronous garbage collection timer to kick in, triggers immediate garbage

collection. The criteria used to select the data structures eligible for deletion are not

necessarily the same ones used by asynchronous cleanup (for instance, they could be

more aggressive). See Chapter 33 for an example.

In Chapter 7, you will see how the kernel manages to reclaim the memory used by

initialization routines and that is no longer needed after they have been executed.

1.2.5. Function Pointers and Virtual Function Tables (VFTs)

Function pointers are a convenient way to write clean C code while getting some of the

benefits of the object-oriented languages. In the definition of a data structure type (the

object), you include a set of function pointers (the methods). Some or all manipulations of

the structure are then done through the embedded functions. C-language function pointers in

data structures look like this:

struct sock {

...

void (*sk_state_change)(struct sock *sk);

6 Part I: General Background

void (*sk_data_ready)(struct sock *sk, int bytes);

...

};

A key advantage to using function pointers is that they can be initialized differently

depending on various criteria and the role played by the object. Thus, invoking

sk_state_change may actually invoke different functions for different sock sockets.

Function pointers are used extensively in the networking code. The following are only a few

examples:

When an ingress or egress packet is processed by the routing subsystem, it initializes

two routines in the buffer data structure. You will see this in Chapter 35. Refer to

Chapter 2 for a complete list of function pointers included in the sk_buff data

structure.

•

When a packet is ready for transmission on the networking hardware, it is handed to

the hard_start_xmit function pointer of the net_device data structure. That

routine is initialized by the device driver associated with the device.

•

When an L3 protocol wants to transmit a packet, it invokes one of a set of function

pointers. These have been initialized to a set of routines by the address resolution

protocol associated with the L3 protocol. Depending on the actual routine to which

the function pointer is initialized, a transparent L3-to-L2 address resolution may take

place (for example, IPv4 packets go through ARP). When the address resolution is

unnecessary, a different routine is used. See Part VI for a detailed discussion on this

interface.

•

We see in the preceding examples how function pointers can be employed as interfaces

between kernel components or as generic mechanisms to invoke the right function handler at

the right time based on the result of something done by a different subsystem. There are

cases where function pointers are also used as a simple way to allow protocols, device

drivers, or any other feature to personalize an action.

Let's look at an example. When a device driver registers a network device with the kernel, it

goes through a series of steps that are needed regardless of the device type. At some point, it

invokes a function pointer on the net_device data structure to let the device driver do

something extra if needed. The device driver could either initialize that function pointer to a

function of its own, or leave the pointer NULL because the default steps performed by the

kernel are sufficient.

A check on the value of a function pointer is always necessary before executing it to avoid

NULL pointer dereferences, as shown in this snapshot from register_netdevice:

if (dev->init && dev->init(dev) != 0) {

...

}

Function pointers have one main drawback: they make browsing the source code a little

harder. While going through a given code path, you may end up focusing on a function

pointer call. In such cases, before proceeding down the code path, you need to find out how

the function pointer has been initialized. It could depend on different factors:

Part I: General Background 7

When the selection of the routine to assign to a function pointer is based on a

particular piece of data, such as the protocol handling the data or the device driver a

given packet is received from, it is easier to derive the routine. For example, if a

given device is managed by the drivers/net/3c59x.c device driver, you can derive the

routine to which a given function pointer of the net_device data structure is

initialized by reading the device initialization routine provided by the device driver.

•

When the selection of the routine is based instead on more complex logic, such as

the state of the resolution of an L3-to-L2 address mapping, the routine used at any

time depends on external events that cannot be predicted.

•

A set of function pointers grouped into a data structure are often referred to as a virtual

function table (VFT). When a VFT is used as the interface between two major subsystems,

such as the L3 and L4 protocol layers, or when the VFT is simply exported as an interface to

a generic kernel component (set of objects), the number of function pointers in it may swell

to include many different pointers that accommodate a wide range of protocols or other

features. Each feature may end up using only a few of the many functions provided. You will

see an example in Part VI. Of course, if this use of a VFT is taken too far, it becomes

cumbersome and a major redesign is needed.

1.2.6. goto Statements

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.

1.2.7. Vector Definitions

In some cases, the definition of a data structure includes an optional block at the end. This is

an example:

8 Part I: General Background

剩余1051页未读，继续阅读

jeep_lqh

粉丝: 0
资源: 2

深入理解Linux网络内核机制

Understanding linux network internals

understanding linux network internals.pdf

understanding-linux-network-internals

Understanding Linux Network Internals

Understanding Linux Network Internals.rar

Understanding Linux Network Internals(英文版)

深入理解Linux网络内幕(Understanding Linux Network Internals)

深入理解Linux 内核网络内幕(Understanding Linux Network Internals)

understanding linux network internals pdf

深入理解LINUX网络技术内幕 原书名： Understanding Linux Network Internals

最新资源

深入理解LINUX网络技术内幕原书名： Understanding Linux Network Internals