第 7 章 套接字

客户端和服务器都使用的一个函数是socket(2)。它的声明方式如下

返回值与open的类型相同，一个整数。FreeBSD从与文件句柄相同的池中分配其值。这就是允许套接字像文件一样处理的原因。

domain参数告诉系统你希望它使用什么**协议族**。许多协议族存在，有些是特定于供应商的，有些则非常常见。它们在sys/socket.h中声明。

对于UDP、TCP和其他互联网协议（IPv4），请使用PF_INET。

type参数定义了五个值，同样在sys/socket.h中。它们都以“SOCK_”开头。最常见的是SOCK_STREAM，它告诉系统你正在请求**可靠的流交付服务**（当与PF_INET一起使用时，它是TCP）。

如果你请求了SOCK_DGRAM，则表示你正在请求**无连接的数据报交付服务**（在我们的例子中，是UDP）。

如果你想负责低级协议（例如IP）甚至网络接口（例如以太网），则需要指定SOCK_RAW。

最后，protocol参数取决于前两个参数，并不总是具有意义。在这种情况下，请使用0作为其值。

套接字系列的各种函数都期望内存中一个小区域的地址（或指针，使用C术语）。sys/socket.h中的各种C声明将其称为struct sockaddr。此结构在同一文件中声明

请注意sa_data字段声明的**模糊性**，它只是一个14字节的数组，注释暗示可能存在超过14个字节。

这种模糊性是经过深思熟虑的。套接字是一个非常强大的接口。虽然大多数人可能认为它只不过是互联网接口——而且如今大多数应用程序可能都用它来实现这一点——但套接字几乎可以用于**任何**类型的进程间通信，其中互联网（或更准确地说，IP）只是一种。

sys/socket.h将套接字将处理的各种类型的协议称为**地址族**，并在sockaddr的定义之前列出它们。

用于IP的是AF_INET。它是常量2的符号。

正是sockaddr的sa_family字段中列出的**地址族**决定了sa_data的模糊命名字节将如何使用。

具体来说，每当**地址族**为AF_INET时，我们都可以在期望sockaddr的任何地方使用netinet/in.h中找到的struct sockaddr_in。

我们可以这样可视化它的组织结构

三个重要的字段是sin_family（结构的第1个字节）、sin_port（在第2和第3个字节中找到的16位值）和sin_addr（IP地址的32位整数表示形式，存储在第4-7个字节中）。

现在，让我们尝试填写它。假设我们正在尝试为**日期时间**协议编写一个客户端，该协议简单地指出其服务器将写入一个表示当前日期和时间的文本字符串到端口13。我们希望使用TCP/IP，因此我们需要在地址族字段中指定AF_INET。AF_INET定义为2。让我们使用192.43.244.18的IP地址，它是美国联邦政府的时间服务器（time.nist.gov）。

顺便说一句，sin_addr字段声明为struct in_addr类型，该类型在netinet/in.h中定义。

此外，in_addr_t是一个32位整数。

192.43.244.18只是通过列出其所有8位字节（从**最高有效位**开始）来表达32位整数的一种方便的表示法。

到目前为止，我们已经将sockaddr视为一个抽象概念。我们的计算机不将short整数存储为单个16位实体，而是存储为2个字节的序列。类似地，它将32位整数存储为4个字节的序列。

假设我们编写了类似以下内容的代码

结果会是什么样子呢？

好吧，这当然取决于情况。在Pentium®或其他基于x86的计算机上，它将如下所示

在不同的系统上，它可能如下所示

在PDP上，它可能看起来又有所不同。但是以上两种是当今最常用的方式。

通常，为了编写可移植的代码，程序员会假装这些差异不存在。并且他们能够做到这一点（除非他们用汇编语言编写代码）。唉，在为套接字编写代码时，你无法轻易地做到这一点。

为什么？

因为在与另一台计算机通信时，你通常不知道它是否将数据存储为**最高有效字节**（MSB）或**最低有效字节**（LSB）优先。

你可能想知道，“那么，套接字不会帮我处理这个问题吗？”

不会。

虽然这个答案一开始可能会让你感到惊讶，但请记住，通用的套接字接口只理解sockaddr结构的sa_len和sa_family字段。你无需担心那里的字节顺序（当然，在FreeBSD上，sa_family只有1个字节，但许多其他UNIX®系统没有sa_len，并使用2个字节表示sa_family，并期望数据以计算机的本机顺序排列）。

但对于套接字而言，其余数据只是sa_data[14]。根据**地址族**的不同，套接字会将其数据转发到其目标。

确实，当我们输入端口号时，是因为我们希望另一台计算机知道我们请求的服务是什么。而且，当我们是服务器时，我们读取端口号以便知道另一台计算机期望我们提供什么服务。无论哪种方式，套接字都只需要将端口号作为数据转发。它不会以任何方式解释它。

同样，我们输入IP地址是为了告诉沿途的所有人将我们的数据发送到哪里。套接字再次将其仅作为数据转发。

这就是为什么我们（**程序员**，而不是**套接字**）必须区分计算机使用的字节顺序和发送到另一台计算机的约定字节顺序。

我们将计算机使用的字节顺序称为**主机字节顺序**或简称**主机顺序**。

有一种约定是通过IP以**MSB优先**的方式发送多字节数据。我们将此称为**网络字节顺序**或简称**网络顺序**。

现在，如果我们为基于Intel的计算机编译了上述代码，我们的**主机字节顺序**将产生

但**网络字节顺序**要求我们先存储MSB。

不幸的是，我们的**主机顺序**与**网络顺序**完全相反。

我们有几种方法可以处理它。一种是在代码中**反转**值

这将“欺骗”我们的编译器以**网络字节顺序**存储数据。在某些情况下，这正是执行此操作的方式（例如，在用汇编语言编程时）。但是，在大多数情况下，这可能会导致问题。

假设，你用C编写了一个基于套接字的程序。你知道它将在Pentium®上运行，因此你以反向方式输入所有常量并强制它们使用**网络字节顺序**。它运行良好。

然后，有一天，你信任的旧Pentium®变成了一个生锈的旧Pentium®。你用一个**主机顺序**与**网络顺序**相同的系统替换它。你需要重新编译所有软件。你所有的软件都继续运行良好，除了你编写的那一个程序。

你已经忘记了你曾将所有常量强制为**主机顺序**的反面。你花了一些时间扯头发，叫喊你曾经听过（以及一些你编造的）所有神灵的名字，用软弹枪击打你的显示器，并执行所有其他试图弄清楚为什么以前运行良好的东西突然完全无法运行的传统仪式。

最终，你弄明白了，说了一些脏话，然后开始重写你的代码。

幸运的是，你不是第一个遇到这个问题的人。其他人已经创建了htons(3)和htonl(3) C函数，分别将short和long从**主机字节顺序**转换为**网络字节顺序**，以及ntohs(3)和ntohl(3) C函数，用于反向转换。

在**MSB优先**系统上，这些函数什么也不做。在**LSB优先**系统上，它们将值转换为正确的顺序。

所以，无论您的软件在哪个系统上编译，如果您使用这些函数，您的数据最终都将按正确的顺序排列。

一旦客户端创建了一个套接字，它需要将其连接到远程系统上的特定端口。它使用 connect(2)

s 参数是套接字，即 socket 函数返回的值。name 是指向 sockaddr 的指针，这是我们已经广泛讨论过的结构。最后，namelen 通知系统我们的 sockaddr 结构中有多少字节。

如果 connect 成功，它将返回 0。否则，它将返回 -1 并将错误代码存储在 errno 中。

connect 失败的原因有很多。例如，尝试进行 Internet 连接时，IP 地址可能不存在，或者可能已关闭，或者太忙，或者可能在指定的端口上没有监听的服务器。或者它可能会完全拒绝对特定代码的任何请求。

我们现在已经了解了足够的信息来编写一个非常简单的客户端，它将从 192.43.244.18 获取当前时间并将其打印到 stdout。

继续，在您的编辑器中输入它，将其保存为 daytime.c，然后编译并运行它。

在这种情况下，日期是 2001 年 6 月 19 日，时间是 02:29:25 UTC。当然，您的结果会有所不同。

端口就像电话线的扩展：拨打号码后，拨打分机号码以连接到特定的人或部门。

有 65535 个 IP 端口，但服务器通常只处理来自其中一个端口的请求。这就像告诉电话接线员我们现在上班了，并且可以在特定的分机号码上接听电话。我们使用 bind(2) 来告诉套接字我们想要服务哪个端口。

除了在 addr 中指定端口外，服务器还可以包含其 IP 地址。但是，它可以使用符号常量 INADDR_ANY 来指示它将服务所有对指定端口的请求，而不管其 IP 地址是什么。此符号以及几个类似的符号在 netinet/in.h 中声明。

假设我们正在为 TCP/IP 上的日期时间协议编写服务器。回想一下，它使用端口 13。我们的 sockaddr_in 结构将如下所示

继续我们的办公室电话类比，在您告诉电话总机接线员您将在哪个分机号码后，您现在走进您的办公室，并确保您自己的电话已插入并且铃声已打开。此外，您确保您的呼叫等待已激活，以便即使您正在与某人交谈也能听到电话铃声。

服务器使用 listen(2) 函数确保所有这些。

在这里，backlog 变量告诉套接字在您忙于处理上一个请求时接受多少个传入请求。换句话说，它决定了挂起连接队列的最大大小。

听到电话铃声后，您通过接听电话来接听电话。您现在已与您的客户端建立连接。此连接保持活动状态，直到您或您的客户端挂断电话。

服务器使用 accept(2) 函数接受连接。

请注意，这次 addrlen 是一个指针。这是必要的，因为在这种情况下，是套接字填写 addr，即 sockaddr_in 结构。

返回值是整数。实际上，accept 返回一个新的套接字。您将使用此新套接字与客户端通信。

旧套接字会发生什么？它继续监听更多请求（记住我们传递给 listen 的 backlog 变量？）直到我们 close 它。

现在，新套接字仅用于通信。它已完全连接。我们不能再次将其传递给 listen，尝试接受其他连接。

我们的第一个服务器将比我们的第一个客户端复杂一些：我们不仅有更多套接字函数可以使用，而且需要将其编写为守护进程。

最好在绑定端口后创建子进程来实现这一点。然后，主进程退出并将控制权返回给 shell（或调用它的任何程序）。

子进程调用 listen，然后启动一个无限循环，该循环接受连接、为其提供服务，并最终关闭其套接字。

我们首先创建一个套接字。然后我们在 sa 中填写 sockaddr_in 结构。请注意 INADDR_ANY 的条件使用情况

它的值为 0。由于我们刚刚对整个结构使用了 bzero，因此再次将其设置为 0 将是多余的。但是，如果我们将我们的代码移植到其他系统（其中 INADDR_ANY 可能不是零），我们需要将其分配给 sa.sin_addr.s_addr。大多数现代 C 编译器都足够聪明，可以注意到 INADDR_ANY 是一个常量。只要它是零，它们就会将整个条件语句从代码中优化掉。

成功调用 bind 后，我们就可以成为守护进程了：我们使用 fork 创建一个子进程。在父进程和子进程中，s 变量都是我们的套接字。父进程将不需要它，因此它调用 close，然后它返回 0 以通知其自己的父进程它已成功终止。

同时，子进程在后台继续工作。它调用 listen 并将其 backlog 设置为 4。它不需要在这里使用较大的值，因为日期时间不是许多客户端一直请求的协议，并且因为它可以立即处理每个请求。

最后，守护进程启动一个无限循环，执行以下步骤

我们可以概括这一点，并将其用作许多其他服务器的模型

此流程图适用于顺序服务器，即一次只能服务一个客户端的服务器，就像我们能够使用日期时间服务器一样。只有在客户端和服务器之间没有真正的“对话”时才有可能：一旦服务器检测到与客户端的连接，它就会发送一些数据并关闭连接。整个操作可能需要纳秒，并且已完成。

此流程图的优点是，除了父进程fork之后和它退出之前的那一小段时间外，始终只有一个进程处于活动状态：我们的服务器不会占用太多内存和其他系统资源。

请注意，我们在流程图中添加了初始化守护进程。我们不需要初始化我们自己的守护进程，但这是在程序流程中设置任何signal处理程序、打开我们可能需要的任何文件等的好地方。

流程图中的几乎所有内容都可以在许多不同的服务器上逐字使用。服务条目是例外。我们将其视为一个“黑盒”，即专门为您的服务器设计的内容，只需“将其插入其余部分”。

并非所有协议都那么简单。许多协议接收来自客户端的请求，对其进行回复，然后接收来自同一客户端的另一个请求。因此，他们事先不知道将为客户端服务多长时间。此类服务器通常为每个客户端启动一个新进程。当新进程正在为其客户端提供服务时，守护进程可以继续监听更多连接。

现在，继续，将上述源代码保存为 daytimed.c（习惯上以字母d结尾守护进程的名称）。编译完成后，尝试运行它。

这里发生了什么？您会记得，日期时间协议使用端口 13。但所有低于 1024 的端口都保留给超级用户（否则，任何人都可以启动一个守护进程，假装服务一个常用的端口，从而造成安全漏洞）。

再试一次，这次以超级用户身份尝试。

什么……什么也没有？让我们再试一次

每个端口一次只能被一个程序绑定。我们的第一次尝试确实成功了：它启动了子守护进程并静默返回。它仍在运行，并将继续运行，直到您终止它，或其任何系统调用失败，或您重新启动系统。

好的，我们知道它在后台运行。但它工作了吗？我们怎么知道它是一个正确的daytime服务器？很简单

telnet尝试了新的IPv6，并失败了。它使用IPv4重试并成功了。守护进程工作正常。

如果您可以通过telnet访问另一个UNIX®系统，则可以使用它来测试远程访问服务器。我的电脑没有静态IP地址，所以我做了以下操作

同样，它成功了。使用域名会工作吗？

顺便说一句，在我们的守护进程关闭套接字后，telnet会打印Connection closed by foreign host消息。这向我们表明，确实，在我们代码中使用fclose(client);可以按预期工作。