TCP/IP网络编程系列之四-基于TCP的服务端/客户端
理解TCP和UDP
根据数据传输方式的不同，基于网络协议的套接字一般分为TCP和UDP套接字。因为TCP套接字是面向连接的，因此又称为基于流的套接字。在了解TCP之前，先了解一下TCP所属的TCP/IP协议栈。
如图所示，TCP/IP协议栈共分为4层，可以理解成数据收发分成了4个层次化过程。
链路层
它是物理链接领域标准化结果，也是最基本的领域，专门定义LAN、WAN、MAN等网络标准。若两台计算机通过网络进行数据交换，链路层就负责整个物理连接。
IP层
准备好物理连接后就要传输数据，首先要考录路径的选择问题，向目标主机传输数据选择哪条路径，就是由IP层负责处理的。IP本身是面向消息的、不可靠的协议。每次传输数据时会帮我们选择路径，但是并不一致，传输过程中出现路径错误，则选择其他路径。但是如果发生数据丢失或错误则无法解决，IP协议无法应对数据错误。
TCP/UDP层
IP层负责传输路径的选择，只需按照路径传输即可。TCP/UDP层以IP层提供的路径信息为基础完成实际的数据传输，故该层又称为传输层。UDP比TCP简单，先说一下TCP。TCP可以保证传输数据的可靠性。IP层只关注一个数据包的传输过程。因此，即使传输多个数据包，每个数据包也是由IP层实际传输的。也就是说，传输的顺序及传输本身不可靠的。若只利用IP层传输数据，则有可能导致后传输的数据包B比先传输的数据包A先到达目的地。也有可能在传输的过程中丢失A,反之如果添加TCP协议的话就不会出现这种情况。数据交换过程中可以确认对方已收到数据，并重传丢失的数据，那么IP层不保证数据传输，这类通信也是可靠的。
总之，TCP和UDP存在于IP层之上，决定主机之间的数据传输方式，TCP确认之后向不可靠的IP协议赋予可靠性。
应用层
套接字通信过程是自动处理的。选择数据传输路径、数据确认过程都被隐藏到套接字内部。总之，向各位提供的工具就是套接字，大家只需利用套接字编写程序即可。编写软件的过程中，需要根据程序特点决定服务端和客户端之间的数据传输规则，这便是应用层的协议。
实现基于TCP的服务端/客户端
TCP函数的调用顺序为下面所示：
socket()->bind()->listen()->accept()->read()/write()->close() 《=》 创建套接字->分配套接字地址->等待连接请求->允许连接->数据交换->断开连接
进入等待连接请求状态
我们调用的bind函数分配了地址，下面就要调用listen函数进入等待连接请求状态。只有调用了listen函数，客户端才能进入可发出连接请求的状态。这时的客户端才可以调用connect函数。（提前调用失败）.
#inlcude <sys/socket.h> int listen(int sock,int backlog) 成功时返回0，失败时返回-1 sock：希望进入等待连接请求的套接字文件描述符，传递的描述符套接字参数成为服务端套接字（监听套接字） backlog：连接请求等待队列的长度，若为5，则队列长度为5，表示最多可以连接5个客户端连接。
"服务端等待连接请求状态"是指客户端请求连接时，受理连接前一直使请求状态处于等待状态。listen函数的第一个参数的用途，客户端连接请求本身也是从网络中接收到的一种数据，而想要接受就需要套接字。此任务就有服务端套接字完成。
受理客户端的连接请求
调用listen函数之后，若有新的连接请求，则应按顺序受理。受理请求意味着进入可接受数据的状态。
#include <sys/socket.h> int accept(int sock,struct sockaddr *addr,socklen_t *addrlen) 成功时返回创建的套接字文件描述符，失败时返回-1 sock：服务端套接字描述符 addr：保存发起连接请求的客户端地址信息的变量地址值，调用函数后想传递来的地址变量参数填充客户端地址信息。 addrlen:第二个参数addr参数长度，但是存有长度的变量地址。函数调用完成后，该变量即被填入客户端地址长度。
accept函数受理连接请求等待队列中待处理的客户端连接请求。函数调用成功时，accept函数内部将产生用于数据I/O的套接字，并返回文件描述符。需要强调的是，套接字是自动创建的，并自动与发起连接请求的客户端建立连接。
TCP客户端的默认函数调用顺序
socket()->connect()->read()/write()->close() ============== 创建套接字->请求连接->交换数据->断开连接
服务端调用listen函数后创建连接请求等待队列，之后客户端即可请求连接。那么如何发起连接请求的呢？就是通过connect函数完成的。
#include <sys/socket.h> int connect(int sock,struct sockaddr *servaddr,socklen_t addrlen) sock:客户端套接字文件描述符 servaddr：保存服务端地址信息的变量地址 addelen：以字节为单位已传递给第二个结构体参数servaddr的地址变量长度。
客户端调用connect函数后，“服务端接收连接请求”或”发生断网等异常情况而中断请求“函数才会返回，完成函数调用。需要注意的是，所谓的"接收连接"并不意味着服务端调用accept函数，其实是服务端把连接请求记录到等待队列。因此accept函数返回后并不立即进行交换数据。
客户端实现过程中并未出现套接字地址分配，而是创建完套接字之后立即调用connect函数，客户端套接字是何时、何地如何分配的呢？何时？调用connect函数时候；何地？操作系统，更准确的说是在内核中；如何？IP用计算机的IP，端口随机分配的。
总结：
服务端创建套接字后连续调用bind、listen函数进入等待状态，客户端通过函数connect请求连接。需要注意的是，客户端只能等到服务器端调用listen函数后才能调用connect函数。同时清楚，客户端调用connect函数之前，服务端有可能率先调用accept函数。当然，此时的服务器端在调用accept函数时进入阻塞状态，直到客户端调用connect函数为止。
实现迭代服务器端/客户端
回声客户端存在问题，每次调用read、write函数都会以字符串为单位执行实际的I/O操作。当然，每次调用write函数都会传递一个字符串，因此还算合理。但是客户端是基于TCP的，因此多次调用write函数传递的字符串有可能一次传递到服务端。此时客户端有可能从服务器端收到多个字符串，这不是我们希望看到的结果。还需要考虑服务端的情况，就是字符串太长，需要分两个数据包发送。服务器端希望通过调用1次write函数传输数据，但如果数据太大，操作系统就有可能把数据分成多个数据包发送到客户端。另外，在此过程中，客户端有可能尚未收到全部数据包时就调用了read函数。
服务端代码：
#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 argc,char *argv[]) { int serverSocket; int clientSocket; struct sockaddr_in serverAddr; struct sockaddr_in clientAddr; socklen_t clientSocketAddrSize; char message []="Hello!"; if(argc != 2) { printf("Usage:%s <port> ",argv[0]); exit(1); } serverSocket = socket(PF_INET,SOCK_STREAM,0); if(serverSocket == -1) { Error_Handling("socket() error"); } memset(&serverAddr,0,sizeof(serverAddr)); serverAddr.sin_family=AF_INET; serverAddr.sin_addr.s_addr=htonl(INADDR_ANY); serverAddr.sin_port=htons(atoi(argv[1])); if(bind(serverSocket,(struct sockaddr*) &serverAddr,sizeof(serverAddr))==-1) { Error_Handling("bind() error"); } if(listen(serverSocket,5)==-1) { Error_Handling("listen() error"); } clientSocketAddrSize = sizeof(clientAddr); clientSocket = accept(serverSocket,(struct sockaddr*)&clientAddr,&clientSocketAddrSize); if(clientSocket == -1) { Error_Handling("accept() error"); } write(clientSocket,message,sizeof(message)); close(clientSocket); close(serverSocket); return 0; } void Error_Handling(char *message) { fputs(message,stderr); fputc(' ',stderr); exit(1); }
客户端代码：
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <arpa/inet.h> #include <sys/socket.h> #define MAXSIZE 30 void Error_Handling(char* message); int main(int argc,char* argv[]) { int sock; struct sockaddr_in serverAddr; char message[MAXSIZE]; int str_len; if(argc != 3) { printf("Usage : %s <IP> <Port> ",argv[0]); exit(1); } sock = socket(PF_INET,SOCK_STREAM,0); if(sock == -1) { Error_Handling("sock() error"); } memset(&serverAddr,0,sizeof(serverAddr)); serverAddr.sin_family=AF_INET; serverAddr.sin_addr.s_addr=inet_addr(argv[1]); serverAddr.sin_port=htons(atoi(argv[2])); if(connect(sock,(struct sockaddr*)&serverAddr,sizeof(serverAddr))==-1) { Error_Handling("connect() error"); } str_len = read(sock,message,sizeof(message)-1); if(str_len == -1) { Error_Handling("read error"); } printf("Message from server : %s ",message); close(sock); return 0; } void Error_Handling(char *message) { fputs(message,stderr); fputc(' ',stderr); exit(1); }
但是上述代码是可以运行，只不过你的数据小不会出现这种情况，单数数据量很大话就会有错误。
回声客户端的解决办法
问题不在服务端而在客户端，但是只看代码也许不太好理解，因为I/O使用了相同的函数。两者都是在循环调用read和write函数。实际上之前的回声客户端将100%接收自己传输的数据，只不过接收数据的单位有问题。回声客户端传输的是字符串，而且通过调用write函数一次性发送的。之后还调用一次read函数，期待中接收自己传输的字符串。这就是问题所在，既然回声客户端会接收到所有字符串数据，是否只需等待一会，那等待多长时间？这个不合理。我们可以提前确定接收数据的大小。若之前传输了20字节长的字符串，则在接收时循环调用read函数读取20个字节即可。回声客户端可以提前知道接收的数据长度，但是我们应该意识到大多数情况下这不太可能，既然如此，若无法预知接收数据长度时应如何收发数据？那就需要应用层协议的定义，收发数据过程中定义好规则以表示数据的边界，或提前告知收发数据的大小。服务端/客户端实现过程中逐步定义这些规则的集合就是应用层协议。
TCP 原理
TCP套接字中的I/O缓冲
TCP套接字的数据收发无边界。服务端调用一次write函数传输40个字节的数据，客户端也有可能通过4次read函数调用每次读取10字节。那么有个问题，客户端可以缓慢的分批读取数据，那么剩余的数据都存放在哪？实际上，write函数调用后并非立即传输数据，read函数调用后也并非马上接收数据。write函数调用瞬间，数据将移至输出缓冲；read函数调用瞬间，从输入缓冲读取数据。调用writ函数时，数据将移到输出缓冲，在适当的时候传向对方的输入缓冲。这是对方将调用read函数冲输入缓冲读取数据。
I/O缓冲的特点：
1.I/O缓冲在每个TCP套接字中单独存在
2.I/O缓冲在创建套接字过程中自动生成
3.即使关闭套接字也会继续传输输出缓冲中的遗留数据
4.关闭套接字将丢失输入缓冲中的数据。
那么如果客户端的输入缓冲为30个字节，但是服务端传输了100个字节，那怎么办？这根本不会发生的。因为TCP会控制数据流，TCP中有滑动窗口协议（Sliding Window）。
与对方套接字的连接
TCP通信过程中会经过3次对话过程，因此该过程又称三次握手。套接字是以全双工方式工作的。也就是说，它可以双向传递数据。因此，收发数据前做些准备，首先，请求连接的主机A向主机B传递如下信息：
[SYN] SEQ: 1000,ACK:-
该消息中，SEQ为1000，ACK为空。现在传递的数据包序号为1000，如果接收无误，请通知我向你传递1001号数据包。这是首次请求连接时使用的信息，又称SYN。SYN是Synchronization的简写，表示收发数据前传输的同步信息。接下来主机B向A传递如下信息：
[SYN+ACK] SEQ:2000,ACK:1001
此时SEQ为2000，ACK为1001。代表现在传递数据包的序号为2000，如果接收无误，请通知我向你传递2001号数据包。而ACK1001的含义：刚才传输的SEQ为1000的数据包接收无误，现在请传递2001号数据包。对主机A首次传输的数据包的确认信息（ACK:1001）和为主机B传输数据做准备的同步消息（SEQ 2000）捆绑发送，因此，这种类型的消息又称SYN+ACK.
收发数据前向数据包分配序号，并向对方通报次序号，这都是为防止数据丢失所做的准备。通过向数据包分配序号并确认，可以在数据丢失时马上查看并重传丢失的数据包。因此，TCP可以保证可靠的数据传输。最后观察主机A向主机B传输的消息：
[ACK] SEQ:1001,ACK:2001
已正确收到传输的SEQ为2000的数据包，现在可以传输SEQ为2001的数据包。这样就传输了添加ACK 2001的ACK信息。至此，主机A和主机B确认了彼此均就绪。
与对方主机的数据交换
通过第一步的三次握手过程完成了数据交换的准备，下面是正式开始收发数据，比如主机A分两次（2个数据包）向主机B传递200字节的过程。首先，主机A通过1个数据包发送100个字节的数据，数据包的SEQ为1200.主机B为了确认这一点，向主机A发送ACK1301消息。此时的ACK号为1301，原因在于ACK号的增量为传输的数据字节数。ACK消息：
ACK号-》SEQ号+传递的字节数+1，与三次握手协议相同，最后加1是为了告知对方下次要传递的SEQ号。如果在传输的过程中出现错误，则重传数据,tcp套接字启动计时器以等待ACK应答。若相应计时器超时，则重传。
断开与套接字的连接
先由套接字A向套接字B传递断开连接的消息，套接字B发出确认收到的消息，然后向套接字A传递可以断开连接的消息，套接字A同样发出确认消息。数据包内的FIN表示断开连接，也就是说，双发各发送1次FIN消息后断开连接。此过程经历四个阶段，因此又称四次握手。