前言

第4章節通過回聲服務示例講解了TCP服務器端/客戶端的實現方法。但這僅是從編程角度的學習，我們尚未詳細討論TCP的工作原理。因此，將詳細講解TCP中必要的理論知識，還將給出第4章節客戶端問題的解決方案。

一、回聲客戶端完美實現

第4章節分析過回聲客戶端存在的問題。如果大家不太理解，請復習第2章節的TCP傳輸特性和第4章節的內容哦。

1.回聲服務器端沒有問題，只有回聲客戶端有問題？

問題不在服務器端，而在客戶端。但只看代碼也許不太好理解，因為I/O中使用了相同的函數。先回顧一下回聲服務器端的I/O相關代碼，下面是echo_server.c的代碼。

while((str_len = read(cInt_sock, message, BUF_SIZE)) != 0)write(clnt_sock, message, str_len);

接著回顧回聲客戶端代碼，下面是echo_client.c的代碼。

write(sock, message, strlen(message));
str_len = read(sock, message, BUF_SIZE - 1);

二者都在循環調用read或write函數。實際上之前的回聲客戶端將100%接收自己傳輸的數據，只不過接收數據時的單位有些問題。擴展客戶端代碼回顧范圍，下面是echo_client.c中的代碼：

while(1)
{fputs("Input message(Q to quit): ", stdout);fGets(message,BUF_SIZE,stdin);......write(sock, message, strlen(message));str_len = read(sock, message, BUF_SIZE - 1);message[str_len] = 0;pRintf("Message from server: %s",message);
}

大家現在理解了吧？回聲客戶端傳輸的是字符串，而且是通過調用write函數一次性發送的。
之后還調用一次read函數，期待著接收自己傳輸的字符串。這就是問題所在。

– “既然回聲客戶端會收到所有字符串數據，是否只需多等一會兒?過一段時間后再
調用read函數是否可以一次性讀取所有字符串數據?” –
的確，過一段時間后即可接收，但需要等多久?要等10分鐘嗎?這不符合常理，理想的客戶端應在收到字符串數據時立即讀取并輸出。

2.回聲客戶端問題解決方法

我們說的回聲客戶端問題實際上是初級程序員經常犯的錯誤，其實很容易解決，因為可以提前確定接收數據的大小。若之前傳輸了20字節長的字符串，則在接收時循環調用read函數讀取20個字節即可。既然有了解決方法，接下來給出代碼。

// hello_client2.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include  <arpa/inet.h>
#include <sys/socket.h>
void error_handling(char* message);int main()
{int sock;char message[BUF_SIZE];int str_len, recv_len, recv_cnt;struct sockaddr_in serv_adr;if(argv != 3){printf("Usage : %s <IP> <port>\n", argv[0]);exit(1);}sock = socket(PF_INET, SOCK_STREAM, 0);if(sock == -1)error_handling("socket() error");memset(&serv_adr, 0, sizeof(serv_adr));serv_adr.sin_family = AF_INET;serv_adr.sin_addr.s_addr = inet_addr(argv[1]);serv_adr.sin_port. = htons(atoi(argv[2]));if(connect(sock, (struct sockaddr*)&serv_adr, sizeof(serv_adr)) == -1)error_handling("connect() error!");elseputs("Connected......");while(1){fputs("Input message(Q to quit): ", stdout);fgets(message, BUF_SIZE, stdin);if(!strcmp(message, "q\n") || !strcmp(message, "Q\n"))break;str_len = write(sock, message, strlen(message));// 這里開始recv_len = 0;while(recv_len < str_len){recv_cnt = read(sock, &message[recv_len], BUF_SIZE - 1);if(recv_len == -1)error_handling("read() error!");recv_len += recv_cnt;}message[recv_len] = 0;// 這里結束printf("Message from server: %s, message");close(sock);return 0 ;
}
}void error_handling(char* message)
{fputs(message, stderr);fputc('\n', stderr);exit(1);
}

以上代碼第43~53行是變更及添加的部分。之前的示例僅調用1次read函數，上述示例為了接收所有傳輸數據而循環調用read函數。另外，代碼第46行循環可以寫成如下形式，可能這種方式更容易理解。

while(recv_len != str_len)
{...
}

接收的數據大小應和傳輸的相同，因此，recv_len中保存的值等于str_len中保存的值時，即可跳出while循環。也許各位認為這種循環寫法更符合邏輯，但有可能引發無限循環。假設發生異常情況，讀取數據過程中recv_len超過str_len，此時就無法退出循環。而如果while循環寫成下面這種形式，則即使發生異常也不會陷入無限循環。

while(recv_len < str_len)
{...
}

寫循環語句時應盡量降低因異常情況而陷人無限循環的可能。以上示例可以結合第4章的echo_server.c運行。大家已經非常熟悉運行結果。

二、如果問題不在于回聲客戶端：定義應用層協議

回聲客戶端可以提前知道接收的數據長度，但我們應該意識到，更多情況下這不太可能。既然如此，若無法預知接收數據長度時應如何收發數據？此時需要的就是應用層協議的定義。之前的回聲服務器端/客戶端中定義了如下協議。
– “收到Q就立即終止連接。” –
同樣，收發數據過程中也需要定好規則（協議）以表示數據的邊界，或提前告知收發數據的大小。服務器端/客戶端實現過程中逐步定義的這些規則集合就是應用層協議。可以看出，應用層協議并不是高深莫測的存在，只不過是為特定程序的實現而制定的規則。
下面編寫程序以體驗應用層協議的定義過程。該程序中，服務器端從客戶端獲得多個數字和運算符信息。服務器端收到數字后對其進行加減乘運算，然后把結果傳回客戶端。例如，向服務器端傳遞3、5、9的同時請求加法運算，則客戶端收到3+5+9的運算結果；若請求做乘法運算，則客戶端收到3×5×9的運算結果。而如果向服務器端傳遞4、3、2的同時要求做減法，則客戶端將收到4-3-2的運算結果，即第一個參數成為被減數。
大家根據以上要求思考下如何編寫服務器端/客戶端，細節部分可以自定義。我實現的程序運行結果如下。先給出服務器端運行結果。

三、計算器服務器端/客戶端示例

大家嘗試實現了嗎？它在功能上沒有特別之處，但若想在網絡環境下實現這些功能并非易事。特別是不熟悉C語言中的數組及指針應用的人，會在實現程序功能時吃苦頭。因此，我希望通過本示例補充回聲服務器端/客戶端實現中未涉及的部分。如果可能，還是希望大家自已動手實現。若成功實現（而不是看源代碼理解），有助于大家提升自信哦。
我編寫程序前設計了如下應用層協議，但這只是為實現程序而設計的最低協議，實際的應用程序實現中需要的協議更詳細、準確。
■ 客戶端連接到服務器端后以1字節整數形式傳遞待算數字個數。
■ 客戶端向服務器端傳遞的每個整數型數據占用4字節。
■ 傳遞整數型數據后接著傳遞運算符。運算符信息占用1字節。
■ 選擇字符+、一、*之一傳遞。
■ 服務器端以4字節整數型向客戶端傳回運算結果。
■ 客戶端得到運算結果后終止與服務器端的連接。
這種程度的協議相當于實現了一半程序，這也說明應用層協議設計在網絡編程中的重要性。
只要設計好協議，實現就不會成為大問題。另外，之前也講過，調用close函數將向對方傳遞EOF，請大家記住這一點并加以運用。接下來給出我實現的計算器客戶端代碼。實際上，與服務器端相比，客戶端中有更多需要學習的內容。

// op_client.c#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include  <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 1024
#define RLT_SIZE 4 // 10
#define OPSZ 4
void error_handling(char* message);int main(int argc, char *argv[])
{int sock;char opmsg[BUF_SIZE]; // 17int result, opnd_cnt, i;struct sockaddr_in serv_adr;if(argc != 3){printf("Usage : %s <IP> <port>\n", argv[0]);exit(1);}sock = socket(PF_INET, SOCK_STREAM, 0);if(sock == -1)error_handling("socket() error");memset(&serv_adr, 0, sizeof(serv_adr));serv_adr.sin_family = AF_INET;serv_adr.sin_addr.s_addr = inet_addr(argv[1]);serv_adr.sin_port = htons(atoi(argv[2]));if(connect(sock, (struct sockaddr*)&serv_adr, sizeof(serv_adr)) == -1)error_handling("connect() error!");elseputs("Connected......");fputs("Operand count: ", stdout);scanf("%d", &opnd_cnt);// 33opmsg[0]=(char)opnd_cnt;for(i = 0; i < opnd_cnt; ++i) // 36{printf("Operand %d: ", i+1);scanf("%d", (int*)&opmsg[i*OPSZ+1]);} // 40fgetc(stdin);fputs("Operator: ", stdout);scanf("%c", &opmsg[opnd_cnt*OPSZ+1]);write(sock, opmsg, opnd_cnt*OPSZ+2);read(sock, &result, RLT_SIZE);printf("Operation result: %d \n", result);close(sock);return 0;
}void error_handling(char* message)
{fputs(message, stderr);fputc('\n', stderr);exit(1);
}

第10、11行：將待算數字的字節數和運算結果的字節數設為常數。
第17行：為收發數據準備的內存空間，需要數據積累到一定程度后再收發，因此通過數組創建。
第40、41行：從程序用戶的輸入中得到待算數個數后，保存至數組opmsg。強制轉換成char
類型，因為協議規定待算數個數應通過1字節整數型傳遞，因此不能超過1字
節整數型能夠表示的范圍。該示例中用的是有符號整數型，但待算數個數不
能是負數，因此使用無符號整數型更合理。
第43~47行：從程序用戶的輸入中得到待算整數，保存到數組opmsg。4字節int型數據要保存到char數組，因而轉換成int指針類型。若不太理解此部分，應需要單獨復習指針。
第48行：第43行中需輸入字符，在此之前調用fgetc函數刪掉緩沖中的字符n。
第50行：最后輸入運算符信息，保存到opmsg數組。
第51行：調用write函數一次性傳輸opmsg數組中的運算相關信息。可以調用1次write函數進行傳輸，也可以分成多次調用。前面反復強調過，這是因為TCP中不存在數據邊界。
第52行：保存服務器端傳輸的運算結果。待接收的數據長度為4字節，因此調用1次read函數即可接收。

客戶端的實現到此結束，給出客戶端向服務器端傳輸的數據結構示例：

從圖中可以看出，若想在同一數組中保存并傳輸多種數據類型，應把數組聲明為char類型。而且需要額外做一些指針及數組運算。接下來給出服務器端代碼。

// op_server.c#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include  <arpa/inet.h>
#include <sys/socket.h>
#define BUF_SIZE 1024
#define OPSZ 4
void error_handling(char* message);
int calculate(int opnum, int opnds[], char oprator);int main(int argc, char *argv[])
{int serv_sock, clnt_sock;char opinfo[BUF_SIZE];int result, opnd_cnt, i;int recv_cnt, recv_len;struct sockaddr_in serv_adr, clnt_adr;socklen_t clnt_adr_sz;if(argc != 2){printf("Usage : %s <port>\n", argv[0]);exit(1);}serv_sock = socket(PF_INET, SOCK_STREAM, 0);if (serv_sock)error_handling("socket() error");memset(&serv_adr, 0, sizeof(serv_adr));serv_adr.sin_family = AF_INET;serv_adr.sin_addr.s_addr = htonl(INADDR_ANY);serv_adr.sin_port = htons(atoi(argv[1]));if(bind(serv_sock, (struct sockaddr*)&serv_adr, sizeof(serv_adr)) == -1)error_handling("bind() error");if(listen(serv_sock, 5) == -1)error_handling("listen() error");clnt_adr_sz = sizeof(clnt_adr);for (i = 0; i < 5; i++) // 42{opnd_cnt = 0;clnt_sock = accept(serv_sock, (struct sockaddr*)&clnt_adr, &clnt_adr_sz);read(clnt_sock, &opnd_cnt, 1); // 46recv_len = 0;while((opnd_cnt*OPSZ + 1) > recv_len){recv_cnt = read(clnt_sock, &opinfo[recv_len], BUF_SIZE - 1);recv_len += recv_cnt;}result = calculate(opnd_cnt, (int*)opinfo, opinfo[recv_len - 1]); // 54write(clnt_sock, (char*)&result, sizeof(result)); // 55close(clnt_sock);}close(serv_sock);return 0;
}int calculate(int opnum, int opnds[], char op)
{int result = opnds[0], i;switch(op){case '+':for(i = 1; i < opnum; ++i) result += opnds[i];break;case '-':for(i = 1; i < opnum; ++i) result -= opnds[i];break;case '*':for(i = 1; i < opnum; ++i) result *= opnds[i];break; }return result;
}void error_handling(char* message)
{fputs(message, stderr);fputc('\n', stderr);exit(1);
}

■ 第42行：為了接收5個客戶端的連接請求而編寫的for語句。
■ 第46行：首先接收待算數個數。
■ 第42~46行：根據第39行中的待算數個數接收待算數。
■ 第54行：調用calculate函數的同時傳遞待算數和運算符信息參數。
■ 第55行：向客戶端傳輸calculate函數返回的運算結果。
對計算器服務器端/客戶端的講解到此結束，大叫可能略感困難，但思考一下應該就能理解。

三、TCP原理

本想在此結束TCP相關介紹，覺得會稍顯倉促，所以補充講解TCP的理論部分。本章節內容將成為日后理解套接字選項的基礎，希望大家能夠全部掌握。

1.TCP套接字中的I/O緩沖

如前所述，TCP套接字的數據收發無邊界。服務器端即使調用1次write函數傳輸40字節的數據，客戶端也有可能通過4次read函數調用每次讀取10字節。但此處也有一些疑問，服務器端一次性傳輸了40字節，而客戶端居然可以緩慢地分批接收。客戶端接收10字節后，剩下的30字節在何處等候呢？是不是像飛機為等待著陸而在空中盤旋一樣，剩下30字節也在網絡中徘徊并等待接收呢?
實際上，write函數調用后并非立即傳輸數據，read函數調用后也并非馬上接收數據。更準確地說，write函數調用瞬間，數據將移至輸出緩沖；read函數調用瞬間，從輸人緩沖讀取數據。
調用write函數時，數據將移到輸出緩沖，在適當的時候（不管是分別傳送還是一次性傳送)傳向對方的輸人緩沖。這時對方將調用read函數從輸入緩沖讀取數據。這些I/O緩沖特性可整理如下：
■ I/O緩沖在每個TCP套接字中單獨存在。
■ I/O緩沖在創建套接字時自動生成。
■ 即使關閉套接字也會繼續傳遞輸出緩沖中遺留的數據。
■ 關閉套接字將丟失輸人緩沖中的數據。
那么，下面這種情況會引發什么事情？理解了I/O緩沖后，各位應該可以猜出其流程：
– “客戶端輸入緩沖為50字節，而服務器端傳輸了100字節。” –
這的確是個問題。輸人緩沖只有50字節，卻收到了100字節的數據。可以提出如下解決方案：
– “填滿輸入緩沖前迅速調用read函數讀取數據，這樣會騰出一部分空間，問題就解決了。” –
當然，這只是我的一個小玩笑，相信大家不會當真，那么馬上給出結論：
– “不會發生超過輸入緩沖大小的數據傳輸。” –
也就是說，根本不會發生這類問題，因為TCP會控制數據流。TCP中有滑動窗口（Sliding Window)協議，用對話方式呈現如下：
■ 套接字A：“你好，最多可以向我傳遞50字節。”
■ 套接字B：“OK!”
■ 套接字A：“我騰出了20字節的空間，最多可以收70字節。”
■ 套接字B：“OK！”
數據收發也是如此，因此TCP中不會因為緩沖溢出而丟失數據。
（write函數和Windows的send函數并不會在完成向對方主機的數據傳輸時
返回，而是在數據移到輸出緩沖時。但TCP會保證對輸出緩沖數據的傳輸，
所以說write函數在數據傳輸完成時返回。要準確理解這句話。）

2.TCP內部工作原理1：與對方套接字的連接

TCP套接字從創建到消失所經過程分為如下3步。
■ 與對方套接字建立連接。
■ 與對方套接字進行數據交換。
■ 斷開與對方套接字的連接。
首先講解與對方套接字建立連接的過程。連接過程中套接字之間的對話如下。
■ [Shake1]套接字A：“你好，套接字B。我這兒有數據要傳給你，建立連接吧。”
■ [Shake2]套接字B：“好的，我這邊已就緒。”
■ [Shake3]套接字A：“謝謝你受理我的請求。”
TCP在實際通信過程中也會經過3次對話過程，因此，該過程又稱Three-wayhandshaking（三次握手)。接下來給出連接過程中實際交換的信息格式：

套接字是以全雙工（Full-duplex)方式工作的。也就是說，它可以雙向傳遞數據。因此，收發數據前需要做一些準備。首先，請求連接的主機A向主機B傳遞如下信息：
[SYN] SEQ:X, ACK:-
該消息中SEQ為X，ACK為空，而SEQ為X的含義如下：
– “現傳遞的數據包序號為X，如果接收無誤，請通知我向您傳遞X+1號數據包。” –
這是首次請求連接時使用的消息，又稱SYN。SYN是Synchronization的簡寫，表示收發數據前傳輸的同步消息。接下來主機B向A傳遞如下消息：
[SYN+ACK] SEQ:Y, ACK:X+1
此時SEQ為Y，ACK為X+1，而SEQ為Y的含義如下：
“現傳遞的數據包序號為Y，如果接收無誤，請通知我向您傳遞Y+1號數據包。”
而ACKX+1的含義如下：
“剛才傳輸的SEQ為X的數據包接收無誤，現在請傳遞SEQ為X+1的數據包。”
對主機A首次傳輸的數據包的確認消息（ACK X+1）和為主機B傳輸數據做準備的同步消息（SEQ Y）捆綁發送，因此，此種類型的消息又稱SYN+ACK。
收發數據前向數據包分配序號，并向對方通報此序號，這都是為防止數據丟失所做的準備。
通過向數據包分配序號并確認，可以在數據丟失時馬上查看并重傳丟失的數據包。因此，TCP可以保證可靠的數據傳輸。最后觀察主機A向主機B傳輸的消息：
[ACK] SEQ:Z, ACK:Y+1
之前也討論過，TCP連接過程中發送數據包時需分配序號。在之前的序號Y的基礎上加1，也就是分配Y+1。此時該數據包傳遞如下消息：
“已正確收到傳輸的SEQ為Y的數據包，現在可以傳輸SEQ為Y+1的數據包。”
這樣就傳輸了添加ACK Y+1的ACK消息。至此，主機A和主機B確認了彼此均就緒。

3.TCP內部工作原理2：與對方主機的數據交換

通過第一步三次握手過程完成了數據交換準備，下面就正式開始收發數據：

給出了主機A分2次（分2個數據包）向主機B傳遞200字節的過程。首先，主機A通過1個數據包發送100個字節的數據，數據包的SEQ為1200。主機B為了確認這一點，向主機A發送ACK1301消息。
此時的ACK號為1301而非1201，原因在于ACK號的增量為傳輸的數據字節數。假設每次ACK號不加傳輸的字節數，這樣雖然可以確認數據包的傳輸，但無法明確100字節全都正確傳遞還是丟失了一部分，比如只傳遞了80字節。因此按如下公式傳遞ACK消息：
ACK號 → SEQ號 + 傳遞的字節數+1
與三次握手協議相同，最后加1是為了告知對方下次要傳遞的SEQ號。下面分析傳輸過程中數據包消失的情況：

通過SEQ1301數據包向主機B傳遞100字節數據。但中間發生了錯誤，主機B未收到。經過一段時間后，主機A仍未收到對于SEQ1301的ACK確認，因此試著重傳該數據包。為了完成數據包重傳，TCP套接字啟動計時器以等待ACK應答。若相應計時器發生超時（Time-out!）則重傳。

4.TCP的內部工作原理3：斷開與套接字的連接

TCP套接字的結束過程也非常優雅。如果對方還有數據需要傳輸時直接斷掉連接會出問題，所以斷開連接時需要雙方協商。斷開連接時雙方對話如下。
■ 套接字A：“我希望斷開連接。”
■ 套接字B：“哦，是嗎?請稍候。”
■ 套接字B：“我也準備就緒，可以斷開連接。”
■ 套接字A：“好的，謝謝合作。”
先由套接字A向套接字B傳遞斷開連接的消息，套接字B發出確認收到的消息，然后向套接字A傳遞可以斷開連接的消息，套接字A同樣發出確認消息。

數據包內的FIN表示斷開連接。也就是說，雙方各發送1次FIN消息后斷開連接。此過程經歷4個階段，因此又稱四次握手（Four-wayhandshaking)。SEQ和ACK的含義與之前講解的內容一致。向主機A傳遞了兩次ACK5001，也許這會讓各位感到困惑。其實，第二次FIN數據包中的ACK5001只是因為接收ACK消息后未接收數據而重傳的。

總結

講解了TCP協議基本內容TCP流控制（FlowControl)，希望這有助于大家理解TCP數據傳輸特性。