Linux 下的行程間通訊：套接字和訊號 | Linux 中國

本篇是 Linux 下行程間通訊（IPC）系列的第三篇同時也是最後一篇文章。第一篇文章聚焦在透過共享儲存（檔案和共享記憶體段）來進行 IPC，第二篇文章則透過管道（無名的或者命名的）及訊息佇列來達到相同的目的。這篇文章將目光從高處（套接字）然後到低處（訊號）來關註 IPC。程式碼示例將用力地充實下麵的解釋細節。

套接字

正如管道有兩種型別（命名和無名）一樣，套接字也有兩種型別。IPC 套接字（即 Unix 套接字）給予行程在相同裝置（主機）上基於通道的通訊能力；而網路套接字給予行程執行在不同主機的能力，因此也帶來了網路通訊的能力。網路套接字需要底層協議的支援，例如 TCP（傳輸控制協議）或 UDP（使用者資料報協議）。

與之相反，IPC 套接字依賴於本地系統內核的支援來進行通訊；特別的，IPC 通訊使用一個本地的檔案作為套接字地址。儘管這兩種套接字的實現有所不同，但在本質上，IPC 套接字和網路套接字的 API 是一致的。接下來的例子將包含網路套接字的內容，但示例伺服器和客戶端程式可以在相同的機器上執行，因為伺服器使用了 localhost（127.0.0.1）這個網路地址，該地址表示的是本地機器上的本地機器地址。

套接字以流的形式（下麵將會討論到）被配置為雙向的，並且其控制遵循 C/S（客戶端/伺服器端）樣式：客戶端透過嘗試連線一個伺服器來初始化對話，而伺服器端將嘗試接受該連線。假如萬事順利，來自客戶端的請求和來自伺服器端的響應將透過管道進行傳輸，直到其中任意一方關閉該通道，從而斷開這個連線。

一個迭代伺服器（只適用於開發）將一直和連線它的客戶端打交道：從最開始服務第一個客戶端，然後到這個連線關閉，然後服務第二個客戶端，迴圈往複。這種方式的一個缺點是處理一個特定的客戶端可能會掛起，使得其他的客戶端一直在後面等待。生產級別的伺服器將是併發的，通常使用了多行程或者多執行緒的混合。例如，我臺式機上的 Nginx 網路伺服器有一個 4 個工人worker的行程池，它們可以併發地處理客戶端的請求。在下麵的程式碼示例中，我們將使用迭代伺服器，使得我們將要處理的問題保持在一個很小的規模，只關註基本的 API，而不去關心併發的問題。

最後，隨著各種 POSIX 改進的出現，套接字 API 隨著時間的推移而發生了顯著的變化。當前針對伺服器端和客戶端的示例程式碼特意寫的比較簡單，但是它著重強調了基於流的套接字中連線的雙方。下麵是關於流控制的一個總結，其中伺服器端在一個終端中開啟，而客戶端在另一個不同的終端中開啟：

1. Listening on port 9876 for clients...
2. War and Peace
3. Pride and Prejudice
4. The Sound and the Fury

示例 1. 使用套接字的客戶端程式

1. #include <string.h>
2. #include <stdio.h>
3. #include <stdlib.h>
4. #include <unistd.h>
5. #include <sys/types.h>
6. #include <sys/socket.h>
7. #include <netinet/tcp.h>
8. #include <arpa/inet.h>
9. #include "sock.h"
11. void report(const char* msg, int terminate) {
12. perror(msg);
13. if (terminate) exit(-1); /* failure */
14. }
16. int main() {
17. int fd = socket(AF_INET, /* network versus AF_LOCAL */
18. SOCK_STREAM, /* reliable, bidirectional: TCP */
19. 0); /* system picks underlying protocol */
20. if (fd < 0) report("socket", 1); /* terminate */
22. /* bind the server's local address in memory */
23. struct sockaddr_in saddr;
24. memset(&saddr, 0, sizeof(saddr)); /* clear the bytes */
25. saddr.sin_family = AF_INET; /* versus AF_LOCAL */
26. saddr.sin_addr.s_addr = htonl(INADDR_ANY); /* host-to-network endian */
27. saddr.sin_port = htons(PortNumber); /* for listening */
29. if (bind(fd, (struct sockaddr *) &saddr, sizeof(saddr)) < 0)
30. report("bind", 1); /* terminate */
32. /* listen to the socket */
33. if (listen(fd, MaxConnects) < 0) /* listen for clients, up to MaxConnects */
34. report("listen", 1); /* terminate */
36. fprintf(stderr, "Listening on port %i for clients...\n", PortNumber);
37. /* a server traditionally listens indefinitely */
38. while (1) {
39. struct sockaddr_in caddr; /* client address */
40. int len = sizeof(caddr); /* address length could change */
42. int client_fd = accept(fd, (struct sockaddr*) &caddr, &len); /* accept blocks */
43. if (client_fd < 0) {
44. report("accept", 0); /* don't terminated, though there's a problem */
45. continue;
46. }
48. /* read from client */
49. int i;
50. for (i = 0; i < ConversationLen; i++) {
51. char buffer[BuffSize + 1];
52. memset(buffer, '\0', sizeof(buffer));
53. int count = read(client_fd, buffer, sizeof(buffer));
54. if (count > 0) {
55. puts(buffer);
56. write(client_fd, buffer, sizeof(buffer)); /* echo as confirmation */
57. }
58. }
59. close(client_fd); /* break connection */
60. } /* while(1) */
61. return 0;
62. }

上面的伺服器端程式執行典型的 4 個步驟來準備回應客戶端的請求，然後接受其他的獨立請求。這裡每一個步驟都以伺服器端程式呼叫的系統函式來命名。

上面的 socket 呼叫的完整形式為：

1. int sockfd = socket(AF_INET,      /* versus AF_LOCAL */
2.                     SOCK_STREAM,  /* reliable, bidirectional */
3.                     0);           /* system picks protocol (TCP) */

第一個引數特別指定了使用的是一個網路套接字，而不是 IPC 套接字。對於第二個引數有多種選項，但 SOCK_STREAM 和 SOCK_DGRAM（資料報）是最為常用的。基於流的套接字支援可信通道，在這種通道中如果發生了資訊的丟失或者更改，都將會被報告。這種通道是雙向的，並且從一端到另外一端的有效載荷在大小上可以是任意的。相反的，基於資料報的套接字大多是不可信的，沒有方向性，並且需要固定大小的載荷。socket 的第三個引數特別指定了協議。對於這裡展示的基於流的套接字，只有一種協議選擇：TCP，在這裡表示的 0。因為對 socket 的一次成功呼叫將傳回相似的檔案描述符，套接字可以被讀寫，對應的語法和讀寫一個本地檔案是類似的。

對 bind 的呼叫是最為複雜的，因為它反映出了在套接字 API 方面上的各種改進。我們感興趣的點是這個呼叫將一個套接字和伺服器端所在機器中的一個記憶體地址進行系結。但對 listen的呼叫就非常直接了：

1. if (listen(fd, MaxConnects) < 0)

第一個引數是套接字的檔案描述符，第二個引數則指定了在伺服器端處理一個拒絕連線錯誤之前，有多少個客戶端連線被允許連線。（在頭檔案 sock.h 中 MaxConnects 的值被設定為 8。）

accept 呼叫預設將是一個阻塞等待：伺服器端將不做任何事情直到一個客戶端嘗試連線它，然後進行處理。accept 函式傳回的值如果是 -1 則暗示有錯誤發生。假如這個呼叫是成功的，則它將傳回另一個檔案描述符，這個檔案描述符被用來指代另一個可讀可寫的套接字，它與 accept 呼叫中的第一個引數對應的接收套接字有所不同。伺服器端使用這個可讀可寫的套接字來從客戶端讀取請求然後寫回它的回應。接收套接字只被用於接受客戶端的連線。

在設計上，伺服器端可以一直執行下去。當然伺服器端可以透過在命令列中使用 Ctrl+C 來終止它。

示例 2. 使用套接字的客戶端

1. #include <string.h>
2. #include <stdio.h>
3. #include <stdlib.h>
4. #include <unistd.h>
5. #include <sys/types.h>
6. #include <sys/socket.h>
7. #include <arpa/inet.h>
8. #include <netinet/in.h>
9. #include <netinet/tcp.h>
10. #include <netdb.h>
11. #include "sock.h"
13. const char* books[] = {"War and Peace",
14. "Pride and Prejudice",
15. "The Sound and the Fury"};
17. void report(const char* msg, int terminate) {
18. perror(msg);
19. if (terminate) exit(-1); /* failure */
20. }
22. int main() {
23. /* fd for the socket */
24. int sockfd = socket(AF_INET, /* versus AF_LOCAL */
25. SOCK_STREAM, /* reliable, bidirectional */
26. 0); /* system picks protocol (TCP) */
27. if (sockfd < 0) report("socket", 1); /* terminate */
29. /* get the address of the host */
30. struct hostent* hptr = gethostbyname(Host); /* localhost: 127.0.0.1 */
31. if (!hptr) report("gethostbyname", 1); /* is hptr NULL? */
32. if (hptr->h_addrtype != AF_INET) /* versus AF_LOCAL */
33. report("bad address family", 1);
35. /* connect to the server: configure server's address 1st */
36. struct sockaddr_in saddr;
37. memset(&saddr, 0, sizeof(saddr));
38. saddr.sin_family = AF_INET;
39. saddr.sin_addr.s_addr =
40. ((struct in_addr*) hptr->h_addr_list[0])->s_addr;
41. saddr.sin_port = htons(PortNumber); /* port number in big-endian */
43. if (connect(sockfd, (struct sockaddr*) &saddr, sizeof(saddr)) < 0)
44. report("connect", 1);
46. /* Write some stuff and read the echoes. */
47. puts("Connect to server, about to write some stuff...");
48. int i;
49. for (i = 0; i < ConversationLen; i++) {
50. if (write(sockfd, books[i], strlen(books[i])) > 0) {
51. /* get confirmation echoed from server and print */
52. char buffer[BuffSize + 1];
53. memset(buffer, '\0', sizeof(buffer));
54. if (read(sockfd, buffer, sizeof(buffer)) > 0)
55. puts(buffer);
56. }
57. }
58. puts("Client done, about to exit...");
59. close(sockfd); /* close the connection */
60. return 0;
61. }

客戶端程式的設定程式碼和伺服器端類似。兩者主要的區別既不是在於監聽也不在於接收，而是連線：

1. if (connect(sockfd, (struct sockaddr*) &saddr, sizeof(saddr)) < 0)

對 connect 的呼叫可能因為多種原因而導致失敗，例如客戶端擁有錯誤的伺服器端地址或者已經有太多的客戶端連線上了伺服器端。假如 connect 操作成功，客戶端將在一個 for 迴圈中，寫入它的請求然後讀取傳回的響應。在會話後，伺服器端和客戶端都將呼叫 close 去關閉這個可讀可寫套接字，儘管任何一邊的關閉操作就足以關閉它們之間的連線。此後客戶端可以退出了，但正如前面提到的那樣，伺服器端可以一直保持開放以處理其他事務。

從上面的套接字示例中，我們看到了請求資訊被回顯給客戶端，這使得客戶端和伺服器端之間擁有進行豐富對話的可能性。也許這就是套接字的主要魅力。在現代系統中，客戶端應用（例如一個資料庫客戶端）和伺服器端透過套接字進行通訊非常常見。正如先前提及的那樣，本地 IPC 套接字和網路套接字只在某些實現細節上面有所不同，一般來說，IPC 套接字有著更低的消耗和更好的效能。它們的通訊 API 基本是一樣的。

訊號

訊號會中斷一個正在執行的程式，在這種意義下，就是用訊號與這個程式進行通訊。大多數的訊號要麼可以被忽略（阻塞）或者被處理（透過特別設計的程式碼）。SIGSTOP （暫停）和 SIGKILL（立即停止）是最應該提及的兩種訊號。這種符號常量有整數型別的值，例如 SIGKILL 對應的值為 9。

訊號可以在與使用者互動的情況下發生。例如，一個使用者從命令列中敲了 Ctrl+C 來終止一個從命令列中啟動的程式；Ctrl+C 將產生一個 SIGTERM 訊號。SIGTERM 意即終止，它可以被阻塞或者被處理，而不像 SIGKILL 訊號那樣。一個行程也可以透過訊號和另一個行程通訊，這樣使得訊號也可以作為一種 IPC 機制。

考慮一下一個多行程應用，例如 Nginx 網路伺服器是如何被另一個行程優雅地關閉的。kill 函式：

1. int kill(pid_t pid, int signum); /* declaration */

可以被一個行程用來終止另一個行程或者一組行程。假如 kill 函式的第一個引數是大於 0的，那麼這個引數將會被認為是標的行程的 pid（行程 ID），假如這個引數是 0，則這個引數將會被視作訊號傳送者所屬的那組行程。

kill 的第二個引數要麼是一個標準的訊號數字（例如 SIGTERM 或 SIGKILL），要麼是 0 ，這將會對訊號做一次詢問，確認第一個引數中的 pid 是否是有效的。這樣優雅地關閉一個多行程應用就可以透過向組成該應用的一組行程傳送一個終止訊號來完成，具體來說就是呼叫一個 kill 函式，使得這個呼叫的第二個引數是 SIGTERM 。（Nginx 主行程可以透過呼叫 kill 函式來終止其他工人行程，然後再停止自己。）就像許多庫函式一樣，kill 函式透過一個簡單的可變語法擁有更多的能力和靈活性。

示例 3. 一個多行程系統的優雅停止

1. #include <stdio.h>
2. #include <signal.h>
3. #include <stdlib.h>
4. #include <unistd.h>
5. #include <sys/wait.h>
7. void graceful(int signum) {
8.   printf("\tChild confirming received signal: %i\n", signum);
9.   puts("\tChild about to terminate gracefully...");
10.   sleep(1);
11.   puts("\tChild terminating now...");
12.   _exit(0); /* fast-track notification of parent */
13. }
15. void set_handler() {
16.   struct sigaction current;
17.   sigemptyset(&current.sa_mask);         /* clear the signal set */
18.   current.sa_flags = 0;                  /* enables setting sa_handler, not sa_action */
19.   current.sa_handler = graceful;         /* specify a handler */
20.   sigaction(SIGTERM, &current, NULL);    /* register the handler */
21. }
23. void child_code() {
24.   set_handler();
26.   while (1) {   /` loop until interrupted `/
27.     sleep(1);
28.     puts("\tChild just woke up, but going back to sleep.");
29.   }
30. }
32. void parent_code(pid_t cpid) {
33.   puts("Parent sleeping for a time...");
34.   sleep(5);
36.   /* Try to terminate child. */
37.   if (-1 == kill(cpid, SIGTERM)) {
38.     perror("kill");
39.     exit(-1);
40.   }
41.   wait(NULL); /` wait for child to terminate `/
42.   puts("My child terminated, about to exit myself...");
43. }
45. int main() {
46.   pid_t pid = fork();
47.   if (pid < 0) {
48.     perror("fork");
49.     return -1; /* error */
50.   }
51.   if (0 == pid)
52.     child_code();
53.   else
54.     parent_code(pid);
55.   return 0;  /* normal */
56. }

上面的停止程式模擬了一個多行程系統的優雅退出，在這個例子中，這個系統由一個父行程和一個子行程組成。這次模擬的工作流程如下：

下麵是一次執行的輸出：

1. % ./shutdown
2. Parent sleeping for a time...
3.         Child just woke up, but going back to sleep.
4.         Child just woke up, but going back to sleep.
5.         Child just woke up, but going back to sleep.
6.         Child just woke up, but going back to sleep.
7.         Child confirming received signal: 15  ## SIGTERM is 15
8.         Child about to terminate gracefully...
9.         Child terminating now...
10. My child terminated, about to exit myself...

對於訊號的處理，上面的示例使用了 sigaction 庫函式（POSIX 推薦的用法）而不是傳統的 signal 函式，signal 函式有移植性問題。下麵是我們主要關心的程式碼片段：

使用訊號來作為 IPC 的確是一個很輕量的方法，但確實值得嘗試。透過訊號來做 IPC 顯然可以被歸入 IPC 工具箱中。

這個系列的總結

在這個系列中，我們透過三篇有關 IPC 的文章，用示例程式碼介紹瞭如下機制：

甚至在今天，在以執行緒為中心的語言，例如 Java、C# 和 Go 等變得越來越流行的情況下，IPC 仍然很受歡迎，因為相比於使用多執行緒，透過多行程來實現併發有著一個明顯的優勢：預設情況下，每個行程都有它自己的地址空間，除非使用了基於共享記憶體的 IPC 機制（為了達到安全的併發，競爭條件在多執行緒和多行程的時候必須被加上鎖），在多行程中可以排除掉基於記憶體的競爭條件。對於任何一個寫過即使是基本的透過共享變數來通訊的多執行緒程式的人來說，他都會知道想要寫一個清晰、高效、執行緒安全的程式碼是多麼具有挑戰性。使用單執行緒的多行程的確是很有吸引力的，這是一個切實可行的方式，使用它可以利用好今天多處理器的機器，而不需要面臨基於記憶體的競爭條件的風險。

當然，沒有一個簡單的答案能夠回答上述 IPC 機制中的哪一個更好。在程式設計中每一種 IPC 機制都會涉及到一個取捨問題：是追求簡潔，還是追求功能強大。以訊號來舉例，它是一個相對簡單的 IPC 機制，但並不支援多個行程之間的豐富對話。假如確實需要這樣的對話，另外的選擇可能會更合適一些。帶有鎖的共享檔案則相對直接，但是當要處理大量共享的資料流時，共享檔案並不能很高效地工作。管道，甚至是套接字，有著更複雜的 API，可能是更好的選擇。讓具體的問題去指導我們的選擇吧。

儘管所有的示例程式碼（可以在我的網站上獲取到）都是使用 C 寫的，其他的程式語言也經常提供這些 IPC 機制的輕量包裝。這些程式碼示例都足夠短小簡單，希望這樣能夠鼓勵你去進行實驗。