Linux网络内核深度探索：C语言实现网络协议

5星 · 超过95%的资源需积分: 34 107 浏览量更新于2024-07-23 收藏 18.17MB PDF 举报

"深入理解Linux网络技术内幕" 这本书旨在帮助读者深入理解Linux操作系统的网络协议栈，特别是对于那些想要用C语言实现网络功能的开发者。虽然书中内容对具有TCP/IP基础知识的读者更有帮助，但即使是初学者也能通过本书学习到网络协议本身以及大量实用的应用信息。书中的内容组织有序，涵盖了从基础术语、编程模式到关键数据结构、用户空间与内核接口、系统初始化等多个方面。作者在编写时遵循了一定的约定，如代码示例的使用，并鼓励读者提供反馈。 Part I: General Background 部分介绍了网络技术的基础知识，包括： 1.1. Basic Terminology: 定义了网络技术中的一些基本术语，这对于理解和交流至关重要。 1.2. Common Coding Patterns: 描述了在处理网络编程时常见的代码模式，有助于读者构建自己的网络应用程序。 1.3. User-Space Tools: 讨论了用于网络分析和调试的用户空间工具，这些工具是开发者诊断问题和优化性能的必备武器。 1.4. Browsing the Source Code: 指导读者如何浏览和理解Linux内核的网络部分源代码，这对于深入学习非常有用。 1.5. When a Feature Is Offered as a Patch: 解释了当一个功能作为补丁提供时的情况，这在开源社区中很常见。 Part II 进一步深入到系统初始化和相关机制： Chapter 2. Critical Data Structures: 详细解析了网络子系统中的关键数据结构，如socket buffer (sk_buff) 和 net_device 结构，这些都是理解网络数据传输和设备管理的基础。 Chapter 3. User-Space-to-Kernel Interface: 介绍了用户空间与内核交互的各种方法，如procfs、sysctl、ioctl和Netlink，这些接口用于配置网络参数和控制内核行为。 3.1. Overview: 给出了一个总体的接口概览。 3.2. procfs Versus sysctl: 比较了procfs和sysctl两种不同的内核调用方式。 3.3. ioctl: 解析了ioctl函数如何用于设备控制和配置。 3.4. Netlink: 介绍了Netlink协议，它是用户空间和内核空间通信的一种有效手段。 3.5. Serializing Configuration Changes: 讨论了如何序列化配置更改，以确保系统稳定和一致性。 Chapter 4. Notification Chains: 探讨了通知链的概念，这是Linux网络子系统中处理事件通知的关键机制。 4.1. Reasons for Notification Chains: 阐述了为何需要通知链来协调和同步网络子系统的不同组件。 4.2. Overview: 提供了通知链的概述。 4.3. Defining a Chain: 说明了如何定义一个通知链。 4.4. Registering with a Chain: 解释了如何将对象注册到通知链中。 4.5. Notifying Events on a Chain: 描述了如何在链上触发和传播事件。 4.6. Notification Chains for the Networking Subsystems: 展示了通知链在不同网络子系统中的应用。 4.7. Tuning via /proc File System: 提到了通过/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页未读，继续阅读

geeleechao

粉丝: 0
资源: 1

Linux网络内核深度探索：C语言实现网络协议

深入理解LINUX网络技术内幕.pdf

深入理解LINUX网络技术内幕

深入理解Linux网络技术内幕

深入理解LINUX网络技术内幕2

深入理解LINUX网络技术内幕3

深入理解LINUX网络技术内幕02

深入理解linux网络技术内幕 pdf

数据挖掘（三）相关数据集资源

《GNU_Linux环境高级编程》.pdf

人工智能-基于kinect的人体动作识别系统源码（毕业设计）

最新资源