编写一个TCP/IP栈1-以太网和ARP - 版本历史

2025年12月24日 (三) 09:31 Xlong

2025-12-24T09:31:19Z

←上一版本		2025年12月24日 (三) 09:31的版本
第89行：		第89行：
	一种便携且略显费力的方法,是手动对协议数据进行序列化。这样,编译器可以自由添加填充字节,以更好地满足不同处理器的数据对齐要求。		一种便携且略显费力的方法,是手动对协议数据进行序列化。这样,编译器可以自由添加填充字节,以更好地满足不同处理器的数据对齐要求。

	解析和处理传入的以太网帧的总体情况很简单:		解析和处理传入的以太网帧的总体情况很简单:<syntaxhighlight lang="c">
			if (tun_read(buf, BUFLEN) < 0) {
			print_error("ERR: Read from tun_fd: %s\n", strerror(errno));
			}

	~~<code>handle_frame</code>函数只是看<code>ethertype</code>以太网标头字段,并根据值决定下一步操作。~~		struct eth_hdr *hdr = init_eth_hdr(buf);

	= ~~解决协议~~ =		handle_frame(&netdev, hdr);
			</syntaxhighlight><code>handle_frame</code>函数只是看<code>ethertype</code>以太网标头字段,并根据值决定下一步操作。

			= 地址解析协议（Arp） =
	''Address Resolution Protocol''地址解析协议(ARP)用于动态地将48位以太网地址(MAC地址)映射到协议地址(例如IPv4 地址。关键是使用ARP,可以使用多种不同的L3协议:不仅使用IPv4,还可以使用其他协议,例如宣布16位协议地址的CHAOS。		''Address Resolution Protocol''地址解析协议(ARP)用于动态地将48位以太网地址(MAC地址)映射到协议地址(例如IPv4 地址。关键是使用ARP,可以使用多种不同的L3协议:不仅使用IPv4,还可以使用其他协议,例如宣布16位协议地址的CHAOS。

第100行：		第106行：
	ARP 数据包格式相对简单:		ARP 数据包格式相对简单:

	ARP头球(<code>arp_hdr</code>包含2-~~ctet~~<code>hwtype</code>确定所使用的链接层类型。这是我们的以太网,~~实际价值是~~<code>0x0001</code>。		ARP头球(<code>arp_hdr</code>包含2-octet<code>hwtype</code>确定所使用的链接层类型。这是我们的以太网,实际值是<code>0x0001</code>。

	~~两枚八胞胎~~<code>protype</code>字段表示协议类型。在我们的例子中,这是IPv4,它与值进行通信<code>0x0800</code>。		2-octet<code>protype</code>字段表示协议类型。在我们的例子中,这是IPv4,它与值进行通信<code>0x0800</code>。

	<code>hwsize</code>而且<code>prosize</code>字段大小均为1-八位,且分别包含硬件和协议字段的大小。在我们的情况下,这些地址为 MAC 地址为 6 字节,IP 地址为 4 字节。		<code>hwsize</code>和<code>prosize</code>字段大小均为1-octet,且分别包含硬件和协议字段的大小。在我们的情况下,这些地址为 MAC 地址为 6 字节,IP 地址为 4 字节。

	~~两八分位~~<code>opcode</code>声明 ARP 消息的类型。可以是 ARP 请求(1)、ARP 回复(2)、RARP 请求(3)或 RARP 回复(4)。		2-octe<code>opcode</code>声明 ARP 消息的类型。可以是 ARP 请求(1)、ARP 回复(2)、RARP 请求(3)或 RARP 回复(4)。

	<code>data</code>字段包含 ARP 消息的实际有效载荷,在我们的情况下,这将包含 IPv4 的特定信息:		<code>data</code>字段包含 ARP 消息的实际有效载荷,在我们的情况下,这将包含 IPv4 的特定信息:<syntaxhighlight lang="c">
			struct arp_ipv4
	~~这些领域相当自我解释。~~<code>~~smac~~</code>而且<code>dmac</code>分别包含发送方和接收方的6字节MAC地址。<code>sip</code>而且<code>dip</code>分别包含发送方和接收方的IP地址。		{
			unsigned char smac[6];
			uint32_t sip;
			unsigned char dmac[6];
			uint32_t dip;
			} __attribute__((packed));
			</syntaxhighlight><code>smac和</code><code>dmac</code>分别包含发送方和接收方的6字节MAC地址。<code>sip</code>而且<code>dip</code>分别包含发送方和接收方的IP地址。

	= 地址解析算法 =		= 地址解析算法 =
	~~original specification原始规范描述了这种用于地址解析的简单算法~~:		原始规范描述了用于地址解析的简单算法:<syntaxhighlight>
			?Do I have the hardware type in ar$hrd?
	即<code>translation table</code>用于存储 ARP 的结果,以便主机能够查看其缓存中是否已包含该条目。这可以避免为冗余的 ARP 请求发送网络垃圾邮件。		Yes: (almost definitely)
			[optionally check the hardware length ar$hln]
			?Do I speak the protocol in ar$pro?
			Yes:
			[optionally check the protocol length ar$pln]
			Merge_flag := false
			If the pair <protocol type, sender protocol address> is
			already in my translation table, update the sender
			hardware address field of the entry with the new
			information in the packet and set Merge_flag to true.
			?Am I the target protocol address?
			Yes:
			If Merge_flag is false, add the triplet <protocol type,
			sender protocol address, sender hardware address> to
			the translation table.
			?Is the opcode ares_op$REQUEST? (NOW look at the opcode!!)
			Yes:
			Swap hardware and protocol fields, putting the local
			hardware and protocol addresses in the sender fields.
			Set the ar$op field to ares_op$REPLY
			Send the packet to the (new) target hardware address on
			the same hardware on which the request was received.
			</syntaxhighlight>即<code>translation table</code>用于存储 ARP 的结果,以便主机能够查看其缓存中是否已包含该条目。这可以避免为冗余的 ARP 请求发送网络垃圾邮件。

	该算法在 arp.c 中实现。		该算法在 [https://github.com/saminiir/level-ip/blob/e9ceb08f01a5499b85f03e2d615309c655b97e8f/src/arp.c#L53 arp.c] 中实现。

	最后,实现ARP的最终测试是,它是否能正确回复ARP请求:		最后,实现ARP的最终测试是,它是否能正确回复ARP请求:<syntaxhighlight lang="shell">
			[saminiir@localhost lvl-ip]$ arping -I tap0 10.0.0.4
			ARPING 10.0.0.4 from 192.168.1.32 tap0
			Unicast reply from 10.0.0.4 [00:0C:29:6D:50:25] 3.170ms
			Unicast reply from 10.0.0.4 [00:0C:29:6D:50:25] 13.309ms

	内核的网络栈从我们的自定义网络堆栈中识别出ARP响应,随后通过输入我们的虚拟网络设备来填充其ARP缓存。成功!		[saminiir@localhost lvl-ip]$ arp
			Address HWtype HWaddress Flags Mask Iface
			10.0.0.4 ether 00:0c:29:6d:50:25 C tap0
			</syntaxhighlight>内核的网络栈从我们的自定义网络堆栈中识别出ARP响应,随后通过输入我们的虚拟网络设备来填充其ARP缓存。成功!

	= 结论 =		= 结论 =
	以太网帧处理和自动处理处理的实现非常简单,只需几行代码即可完成。相反,奖励因素相当高,因为你可以使用自己的支持性以太网设备来填充Linux主机的ARP缓存!		以太网帧处理和自动处理处理的实现非常简单,只需几行代码即可完成。相反,奖励因素相当高,因为你可以使用自己的支持性以太网设备来填充Linux主机的ARP缓存!

	~~该项目的源代码可在~~ GitHub 上找到。		该项目的[https://github.com/saminiir/level-ip 源代码]可在 GitHub 上找到。

	在下一篇文章中,我们将继续使用ICMP回声与回复(ping)以及IPv4数据包解析来实现。		在下一篇文章中,我们将继续使用ICMP回声与回复(ping)以及IPv4数据包解析来实现。

2025年12月24日 (三) 08:57 Xlong

2025-12-24T08:57:32Z

←上一版本		2025年12月24日 (三) 08:57的版本
第12行：		第12行：
	TUN/TAP 设备的优点在于在用户空间程序中易于设置,并且已在众多程序(如 OpenVPN)中使用。		TUN/TAP 设备的优点在于在用户空间程序中易于设置,并且已在众多程序(如 OpenVPN)中使用。

	由于我们希望从第2层向上构建网络栈,因此需要一个TAP设备。我们这样进行即时验证:		由于我们希望从第2层向上构建网络栈,因此需要一个TAP设备。我们这样进行即时验证:<syntaxhighlight lang="c" line="1">
			/*
			* Taken from Kernel Documentation/networking/tuntap.txt
			*/
			int tun_alloc(char *dev)
			{
			struct ifreq ifr;
			int fd, err;

	~~之后,返回的文件描述符<code>~~fd</~~code>可以用来<code>read<~~/~~code>而且<code>write~~</~~code>数据到虚拟设备的以太网缓冲区。~~		if( (fd = open("/dev/net/tap", O_RDWR)) < 0 ) {
			print_error("Cannot open TUN/TAP dev");
			exit(1);
			}

	旗帜<code>IFF_NO_PI</code>这里至关重要,~~否则我们最终会收到预设在以太网帧的不必要的数据包信息。你实际上可以查看隧道设备驱动程序的内核源代码~~,并自行验证。		CLEAR(ifr);

			/* Flags: IFF_TUN - TUN device (no Ethernet headers)
			* IFF_TAP - TAP device
			*
			* IFF_NO_PI - Do not provide packet information
			*/
			ifr.ifr_flags = IFF_TAP \| IFF_NO_PI;
			if( *dev ) {
			strncpy(ifr.ifr_name, dev, IFNAMSIZ);
			}

			if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
			print_error("ERR: Could not ioctl tun: %s\n", strerror(errno));
			close(fd);
			return err;
			}

			strcpy(dev, ifr.ifr_name);
			return fd;
			}
			</syntaxhighlight>之后,返回的文件描述符<code>fd</code>可以用来<code>read</code>而且<code>write</code>数据到虚拟设备的以太网缓冲区。

			旗帜<code>IFF_NO_PI</code>这里至关重要,否则我们最终会收到预设在以太网帧的不必要的数据包信息。你实际上可以查看隧道设备驱动程序的[https://github.com/torvalds/linux/blob/v4.4/drivers/net/tun.c#L1306 内核源代码],并自行验证。

	= 以太网帧格式 =		= 以太网帧格式 =
第27行：		第60行：
	不同的以太网标准由IEEE <sup>802.3</sup> 3工作组维护。		不同的以太网标准由IEEE <sup>802.3</sup> 3工作组维护。

	接下来,我们将查看以太网帧头。如下所示,可以将其声明为C结构:		接下来,我们将查看以太网帧头。如下所示,可以将其声明为C结构:<syntaxhighlight lang="c">
			#include <linux/if_ether.h>

	<code>dmac</code>而且<code>smac</code>是相当不言自明的领域。它们包含通信方的MAC地址(分别为目的地和来源)。		struct eth_hdr
			{
			unsigned char dmac[6];
			unsigned char smac[6];
			uint16_t ethertype;
			unsigned char payload[];
			} __attribute__((packed));
			</syntaxhighlight><code>dmac</code>而且<code>smac</code>是相当不言自明的领域。它们包含通信方的MAC地址(分别为目的地和来源)。

	超载的字段<code>ethertype</code>是一个2-~~ctet字段~~,根据其值表示有效载荷的长度或类型。具体来说,如果该字段的值大于或等于1536,则该字段包含有效载荷的类型(例如IPv4、ARP)如果值小于该值,则包含有效载荷的长度。		超载的字段<code>ethertype</code>是一个2-octet 字段,根据其值表示有效载荷的长度或类型。具体来说,如果该字段的值大于或等于1536,则该字段包含有效载荷的类型(例如IPv4、ARP)如果值小于该值,则包含有效载荷的长度。

	类型字段之后''tags'',以太网帧可能会出现多个不同的标签。''这些标签可用于描述帧的虚拟局域网''(VLAN)''或服务质量''(QoS)类型。以太网帧标签不在我们的实现中,因此相应的字段也不会显示在我们的协议声明中。		类型字段之后''tags'',以太网帧可能会出现多个不同的标签。''这些标签可用于描述帧的虚拟局域网''(VLAN)''或服务质量''(QoS)类型。以太网帧标签不在我们的实现中,因此相应的字段也不会显示在我们的协议声明中。

	田野<code>~~payload~~</code>包含指向以太网帧有效载荷的指针。在我们的情况下,这将包含一个ARP或IPv4数据包。如果有效载荷长度小于所需最小48字节(不含标签),则将空格字节附加到有效载荷的末尾,以满足要求。		<code>字段payload</code>包含指向以太网帧有效载荷的指针。在我们的情况下,这将包含一个ARP或IPv4数据包。如果有效载荷长度小于所需最小48字节(不含标签),则将空格字节附加到有效载荷的末尾,以满足要求。

	我们还包括<code>if_ether.h</code>Linux 头向提供 ethertypes 与其十六进制值之间的映射。		我们还包括<code>if_ether.h</code>Linux 头向提供 ethertypes 与其十六进制值之间的映射。
第43行：		第84行：
	= 以太网框架解析 =		= 以太网框架解析 =
	''packed''结构体声明中包含的属性是一个实现细节——它用于指示GNU <sup>4</sup>C编译器不要针对数据对齐进行填充字节4的结构体内存布局进行优化。使用此属性完全源于我们“解析”协议缓冲区的方式,该缓冲区只是使用正确协议结构对数据缓冲区进行的一种类型转换:		''packed''结构体声明中包含的属性是一个实现细节——它用于指示GNU <sup>4</sup>C编译器不要针对数据对齐进行填充字节4的结构体内存布局进行优化。使用此属性完全源于我们“解析”协议缓冲区的方式,该缓冲区只是使用正确协议结构对数据缓冲区进行的一种类型转换:

			struct eth_hdr hdr = (struct eth_hdr ) buf;

	一种便携且略显费力的方法,是手动对协议数据进行序列化。这样,编译器可以自由添加填充字节,以更好地满足不同处理器的数据对齐要求。		一种便携且略显费力的方法,是手动对协议数据进行序列化。这样,编译器可以自由添加填充字节,以更好地满足不同处理器的数据对齐要求。

Xlong：创建页面，内容为“编写自己的TCP/IP栈可能看起来是一项艰巨的任务。事实上,TCP在其三十多年的生命周期中积累了许多规范。然而,¹核心规范看似紧凑——重要的部分是TCP头解析、状态机、拥塞控制以及传输超时计算。最常见的第2层和第3层协议,分别是以太网和IP,与TCP的复杂性相形见绌。在本博客系列中,我们将实现一个适用于 Linux 的最小用户空间 TCP/IP 栈。…”

2025-12-24T08:50:24Z

创建页面，内容为“编写自己的TCP/IP栈可能看起来是一项艰巨的任务。事实上,TCP在其三十多年的生命周期中积累了许多规范。然而,1核心规范看似紧凑——重要的部分是TCP头解析、状态机、拥塞控制以及传输超时计算。最常见的第2层和第3层协议,分别是以太网和IP,与TCP的复杂性相形见绌。在本博客系列中,我们将实现一个适用于 Linux 的最小用户空间 TCP/IP 栈。…”

新页面

编写自己的TCP/IP栈可能看起来是一项艰巨的任务。事实上,TCP在其三十多年的生命周期中积累了许多规范。然而,1核心规范看似紧凑——重要的部分是TCP头解析、状态机、拥塞控制以及传输超时计算。

最常见的第2层和第3层协议,分别是以太网和IP,与TCP的复杂性相形见绌。在本博客系列中,我们将实现一个适用于 Linux 的最小用户空间 TCP/IP 栈。

这些帖子和生成软件的目的纯粹是教育性的——在更深层次上学习网络和系统编程。

*

= TUN/TAP 设备 =
为了拦截来自Linux内核的低级别网络流量,我们将使用Linux TAP设备。简而言之,TUN/TAP 设备经常被网络用户空间应用程序用于操作 L3/L2 流量。一个流行的例子是隧道,其中数据包被包裹在另一个数据包的有效载荷内。

TUN/TAP 设备的优点在于在用户空间程序中易于设置,并且已在众多程序(如 OpenVPN)中使用。

由于我们希望从第2层向上构建网络栈,因此需要一个TAP设备。我们这样进行即时验证:

之后,返回的文件描述符<code>fd</code>可以用来<code>read</code>而且<code>write</code>数据到虚拟设备的以太网缓冲区。

旗帜<code>IFF_NO_PI</code>这里至关重要,否则我们最终会收到预设在以太网帧的不必要的数据包信息。你实际上可以查看隧道设备驱动程序的内核源代码,并自行验证。

= 以太网帧格式 =
''多种不同的以太网网络技术是局域网''(LAN)中连接计算机的支柱。与所有物理技术一样,2以太网标准已从其1980年由数字设备公司、英特尔和施乐公司发布的首版2版大有演进。

以太网的首个版本在当今标准中较为缓慢——大约为10兆字节/秒,它采用了半双工通信技术,意味着您发送或接收数据,但并非同时进行。因此,''必须采用媒体访问控制''(MAC)协议来组织数据流。时至今日,如果在半双工模式下运行以太网接口,仍需要使用“载波感知”、带碰撞检测(CSMA/CD'')''的多重访问方式。

''100BASE-T''采用100BASE-T以太网标准,采用双绞线,实现全双工通信和更高的传输速度。此外,以太网交换机的普及程度同时增加,使得CSMA/CD基本过时。

不同的以太网标准由IEEE 802.3 3工作组维护。

接下来,我们将查看以太网帧头。如下所示,可以将其声明为C结构:

<code>dmac</code>而且<code>smac</code>是相当不言自明的领域。它们包含通信方的MAC地址(分别为目的地和来源)。

超载的字段<code>ethertype</code>是一个2-ctet字段,根据其值表示有效载荷的长度或类型。具体来说,如果该字段的值大于或等于1536,则该字段包含有效载荷的类型(例如IPv4、ARP)如果值小于该值,则包含有效载荷的长度。

类型字段之后''tags'',以太网帧可能会出现多个不同的标签。''这些标签可用于描述帧的虚拟局域网''(VLAN)''或服务质量''(QoS)类型。以太网帧标签不在我们的实现中,因此相应的字段也不会显示在我们的协议声明中。

田野<code>payload</code>包含指向以太网帧有效载荷的指针。在我们的情况下,这将包含一个ARP或IPv4数据包。如果有效载荷长度小于所需最小48字节(不含标签),则将空格字节附加到有效载荷的末尾,以满足要求。

我们还包括<code>if_ether.h</code>Linux 头向提供 ethertypes 与其十六进制值之间的映射。

最后,''Frame Check Sequence''以太网帧格式还包含了帧勾选句字段,''Cyclic Redundancy Check''该字段与循环冗余检查(CRC)配合使用,以检查帧的完整性。我们将在实现此字段时省略处理。

= 以太网框架解析 =
''packed''结构体声明中包含的属性是一个实现细节——它用于指示GNU 4C编译器不要针对数据对齐进行填充字节4的结构体内存布局进行优化。使用此属性完全源于我们“解析”协议缓冲区的方式,该缓冲区只是使用正确协议结构对数据缓冲区进行的一种类型转换:

一种便携且略显费力的方法,是手动对协议数据进行序列化。这样,编译器可以自由添加填充字节,以更好地满足不同处理器的数据对齐要求。

解析和处理传入的以太网帧的总体情况很简单:

<code>handle_frame</code>函数只是看<code>ethertype</code>以太网标头字段,并根据值决定下一步操作。

= 解决协议 =
''Address Resolution Protocol''地址解析协议(ARP)用于动态地将48位以太网地址(MAC地址)映射到协议地址(例如IPv4 地址。关键是使用ARP,可以使用多种不同的L3协议:不仅使用IPv4,还可以使用其他协议,例如宣布16位协议地址的CHAOS。

通常情况下,你了解局域网中某个服务的IP地址,但要建立实际通信,硬件地址(MAC)也需要被知晓。因此,ARP 用于广播和查询网络,要求 IP 地址的所有者报告其硬件地址。

ARP 数据包格式相对简单:

ARP头球(<code>arp_hdr</code>包含2-ctet<code>hwtype</code>确定所使用的链接层类型。这是我们的以太网,实际价值是<code>0x0001</code>。

两枚八胞胎<code>protype</code>字段表示协议类型。在我们的例子中,这是IPv4,它与值进行通信<code>0x0800</code>。

<code>hwsize</code>而且<code>prosize</code>字段大小均为1-八位,且分别包含硬件和协议字段的大小。在我们的情况下,这些地址为 MAC 地址为 6 字节,IP 地址为 4 字节。

两八分位<code>opcode</code>声明 ARP 消息的类型。可以是 ARP 请求(1)、ARP 回复(2)、RARP 请求(3)或 RARP 回复(4)。

<code>data</code>字段包含 ARP 消息的实际有效载荷,在我们的情况下,这将包含 IPv4 的特定信息:

这些领域相当自我解释。<code>smac</code>而且<code>dmac</code>分别包含发送方和接收方的6字节MAC地址。<code>sip</code>而且<code>dip</code>分别包含发送方和接收方的IP地址。

= 地址解析算法 =
original specification原始规范描述了这种用于地址解析的简单算法:

即<code>translation table</code>用于存储 ARP 的结果,以便主机能够查看其缓存中是否已包含该条目。这可以避免为冗余的 ARP 请求发送网络垃圾邮件。

该算法在 arp.c 中实现。

最后,实现ARP的最终测试是,它是否能正确回复ARP请求:

内核的网络栈从我们的自定义网络堆栈中识别出ARP响应,随后通过输入我们的虚拟网络设备来填充其ARP缓存。成功!

= 结论 =
以太网帧处理和自动处理处理的实现非常简单,只需几行代码即可完成。相反,奖励因素相当高,因为你可以使用自己的支持性以太网设备来填充Linux主机的ARP缓存!

该项目的源代码可在 GitHub 上找到。

在下一篇文章中,我们将继续使用ICMP回声与回复(ping)以及IPv4数据包解析来实现。

= 来源 =

# <nowiki>https://tools.ietf.org/html/rfc7414</nowiki> ↩↩
# <nowiki>http://ethernethistory.typepad.com/papers/EthernetSpec.pdf</nowiki> ↩
# <nowiki>https://en.wikipedia.org/wiki/IEEE_802.3</nowiki> ↩
# <nowiki>https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attrites.html#Common-Type-Attributes</nowiki> ↩
# <nowiki>https://github.com/chobits/tapip</nowiki> ↩