基于TCP的服务端/客户端(1)
理解TCP和UDP
根据数据传输方式的不同，基于网络协议的套接字一般分为TCP套接字和UDP套接字。
因为TCP套接字是面向连接的，因此又称基于流(stream)的套接字。
TCP是Transmission Control Protocol(传输控制协议)的简写意为“对数据传输过程的控制因此，学习控制方法及范围有助于正确理解TCP套接字。
TCP/IP协议栈
讲解TCP前先介绍TCP所属的TCP/IP协议栈(Stack，层)
- 链路层
- IP层
- 传输层：TCP/UDP
- 应用层
TCP/IP协议栈共分4层，可以理解为数据收发分成了4个层次化过程。也就是说，面对“基于互联网的有效数据传输”的命题，并非通过1个庞大协议解决问题，而是化整为零，通过层次化方案-TCP/IP协议栈解决。通过TCP/UDP套接字收发数据时需要借助这4层
TCP与UDP只在传输层不同。
这里分为4层，其实与OSI7层模型有很多共通的地方
TCP/IP协议的诞生背景
“通过因特网完成有效数据传输”这个课题让许多专家聚集到了一起，这些人是硬件、系统路由算法等各领域的顶级专家。为何需要这么多领域的专家呢?
我们之前只关注套接字创建及应用，却忽略了计算机网络问题并非仅凭软件就能解决。编写软件前需要构建硬件系统，在此基础上需要通过软件实现各种算法。所以才需要众多领域的专家进行讨论，以形成各种规定。因此，把这个大问题划分成若干小问题再逐个攻破，将大幅提高效率。
把“通过因特网完成有效数据传输”问题按照不同领域划分成小问题后，出现多种协议，它们通过层级结构建立了紧密联系。
链路层
接下来逐层了解TCP/IP协议栈，先讲解链路层。链路层是物理链接领域标准化的结果，也是最基本的领域，专门定义LAN、WAN、MAN等网络标准。若两台主机通过网络进行数据交换则需要物理连接，链路层就负责这些标准。
IP层
准备好物理连接后就要传输数据。为了在复杂的网络中传输数据,首先需要考虑路径的选择。
向目标传输数据需要经过哪条路径?解决此问题就是IP层，该层使用的协议就是IP。
IP本身是面向消息的、不可靠的协议。每次传输数据时会帮我们选择路径，但并不一致。如果传输中发生路径错误，则选择其他路径;但如果发生数据丢失或错误，则无法解决。换言之，IP协议无法应对数据错误。
传输层，TCP/UDP层
IP层解决数据传输中的路径选择问题，只需照此路径传输数据即可。TCP和UDP层以IP层提供的路径信息为基础完成实际的数据传输，故该层又称传输层(Transport)。UDP比TCP简单，我们将在后续章节展开讨论，现只解释TCP。TCP可以保证可靠的数据传输，但它发送数据时以IP层为基础(这也是协议栈结构层次化的原因)。那该如何理解二者关系呢?
IP层只关注1个数据包(数据传输的基本单位)的传输过程。因此，即使传输多个数据包每个数据包也是由IP层实际传输的，也就是说传输顺序及传输本身是不可靠的。若只利用IP层传输数据，则有可能导致后传输的数据包B比先传输的数据包A提早到达。另外，传输的数据包A.B、C中有可能只收到A和C，甚至收到的C可能已损毁。反之，若添加TCP协议则按照如下对话方式进行数据交换。
主机A:“正确收到第二个数据包!
主机B:“恩，知道了。”
主机A:“正确收到第三个数据包!”
主机B:“可我已发送第四个数据包了啊!哦，您没收到第四个数据包吧?我给您重传!”
这就是TCP的作用。如果数据交换过程中可以确认对方已收到数据，并重传丢失的数据，那么即便IP层不保证数据传输，这类通信也是可靠的
总之，TCP和UDP存在于IP层之上，决定主机之间的数据传输方式，TCP协议确认后向不可靠的IP协议赋予可靠性。
应用层
上述内容是套接字通信过程中自动处理的。选择数据传输路径、数据确认过程都被隐藏到套接字内部。而与其说是“隐藏”，倒不如“使程序员从这些细节中解放出来”的表达更为准确。程序员编程时无需考虑这些过程，但这并不意味着不用掌握这些知识。只有掌握了这些理论，才能编写出符合需求的网络程序。
总之，向各位提供的工具就是套接字，大家只需利用套接字编出程序即可。编写软件的过程中，需要根据程序特点决定服务器端和客户端之间的数据传输规则(规定)，这便是应用层协议网络编程的大部分内容就是设计并实现应用层协议。
实现基于TCP的服务器端/客户端
本节实现完整的TCP服务器端，在此过程中各位将理解套接字使用方法及数据传输方法。
TCP服务器端的默认函数调用顺序
socket()创建套接字bind()分配套接字地址listen()进入监听状态accept()接收请求read()/write()数据交换close()断开连接
调用socket函数创建套接字，声明并初始化地址信息结构体变量，调用bind函数向套接字分配地址。这2个阶段之前都已讨论过，下面讲解之后的几个过程。
进入等待连接请求状态
我们已调用bind函数给套接字分配了地址，接下来就要通过调用listen函数进入等待连接请求状态。只有调用了listen函数，客户端才能进入可发出连接请求的状态。换言之，这时客户端才能调用connect函数(若提前调用将发生错误)。
#include<sys/socket.h>
int listen(int sock, int backlog);
// 成功时返回0，失败时返回-1。
// sock 希望进入等待连接请求状态的套接字文件描述符，传递的描述符套接字参数成为服务器端套接字(监听套接字)。
// backlog 连接请求等待队列(Queue)的长度，若为5，则队列长度为5，表示最多使5个连接请求进入队列。
先解释一下等待连接请求状态的含义和连接请求等待队列。“服务器端处于等待连接请求状是指，客户端请求连接时，受理连接前一直使请求处于等待状态。
作为listen函数的第一个参数传递的文件描述符套接字的用途。客户端连接请求本身也是从网络中接收到的一种数据，而要想接收就需要套接字。此任务就由服务器端套接字完成。服务器端套接字是接收连接请求的一名门卫或一扇门。
客户端如果向服务器端询问:“请问我是否可以发起连接?”服务器端套接字就会亲切应答:“您好!当然可以，但系统正忙，请到等候室排号等待，准备好后会立即受理您的连接。”同时将连接请求请到等候室。调用listen函数即可生成这种门卫(服务器端套接字)listen函数的第二个参数决定了等候室的大小。等候室称为连接请求等待队列，准备好服务器端套接字和连接请求等待队列后，这种可接收连接请求的状态称为等待连接请求状态
listen函数的第二个参数值与服务器端的特性有关,像频繁接收请求的Web服务器端至少应为15。另外，连接请求队列的大小始终根据实验结果而定。
受理客户端连接请求
调用listen函数后，若有新的连接请求，则应按序受理。受理请求意味着进入可接受数据的状态。也许各位已经猜到进入这种状态所需部件一-当然是套接字!大家可能认为可以使用服务器端套接字，但服务器端套接字是做门卫的。如果在与客户端的数据交换中使用门卫，那谁来守门呢?因此需要另外一个套接字，但没必要亲自创建。下面这个函数将自动创建套接字，并连接到发起请求的客户端。
#include <sys/socket.h>
int accept(int sock, struct sockaddr * addr, socklent * addrlen);
// 成功时返回创建的套接字文件描述符，失败时返回-1。
// sock 服务器套接字的文件描述符
// addr 保存发起连接请求的客户端地址信息的变量地址值，调用函数后向传递来的地址变量参数填充客户端地址信息。
// addrlen 第二个参数addr结构体的长度，但是存有长度的变量地址。函数调用完成后，该变量即被填入客户端地址长度。
accept函数受理连接请求等待队列中待处理的客户端连接请求。函数调用成功时，accept函数内部将产生用于数据I/O的套接字，并返回其文件描述符。需要强调的是，套接字是自动创建的并自动与发起连接请求的客户端建立连接。
TCP客户端的默认函数调用顺序
接下来讲解客户端的实现顺序。如前所述，这要比服务器端简单许多。因为创建套接字和请求连接就是客户端的全部内容
socket()创建套接字connect()请求连接read()/write()交换数据close()断开连接
与服务器端相比，区别就在于“请求连接”，它是创建客户端套接字后向服务器端发起的连接请求。服务器端调用listen函数后创建连接请求等待队列，之后客户端即可请求连接。那如何发起连接请求呢?通过调用如下函数完成。
#include <sys/socket.h>
int connect(int sock, struct sockaddr * servaddr, socklen_t addrlen);
// 成功时返回0失败时返回-1。
// sock 客户端套接字文件描述符。
// servaddr 保存目标服务器端地址信息的变量地址值。
// addrlen 以字节为单位传递已传递给第二个结构体参数servaddr的地址变量长度。
客户端调用connect函数后，发生以下情况之一才会返回(完成函数调用)。
- 服务器端接收连接请求
- 发生断网等异常情况而中断连接请求
需要注意，所谓的“接收连接”并不意味着服务器端调用accept函数，其实是服务器端把连接请求信息记录到等待队列。因此connect函数返回后并不立即进行数据交换。
客户端套接字地址信息在哪?
实现服务器端必经过程之一就是给套接字分配IP和端口号。但客户端实现过程中并未出现套接字地址分配，而是创建套接字后立即调用connect函数。难道客户端套接字无需分配IP和端口?当然不是!网络数据交换必须分配IP和端口。既然如此，那客户端套接字何时、何地、如何分配地址呢?
- 何时?调用connect函数时。
- 何地?操作系统，更准确地说是在内核中
- 如何?IP用计算机(主机)的IP，端口随机。
客户端的IP地址和端口在调用connect函数时自动分配，无需调用标记的bind函数进行分配。
实现选代服务器端/客户端
本节编写回声(echo)服务器端/客户端。顾名思义，服务器端将客户端传输的字符串数据原封不动地传回客户端，就像回声一样。在此之前，需要先解释一下迭代服务器端。
实现迭代服务器端
之前讨论的Hello world服务器端处理完1个客户端连接请求即退出，连接请求等待队列实际没有太大意义。但这并非我们想象的服务器端。设置好等待队列的大小后，应向所有客户端提供服务。如果想继续受理后续的客户端连接请求，应怎样扩展代码?最简单的办法就是插人循环语句反复调用accept函数
调用accept函数后，紧接着调用IO相关的read、write函数，然后调用close函数。这并非针对服务器端套接字，而是针对accept函数调用时创建的套接字。
调用close函数就意味着结束了针对某一客户端的服务。此时如果还想服务于其他客户端，就要重新调用accept函数。
“这算什么呀?又不是银行窗口，好歹也是个服务器端，难道同一时刻只能服务于-个客户端吗?
是的!同一时刻确实只能服务于一个客户端。将来学完进程和线程后，就可以编写同时服务多个客户端的服务器端了。目前只能做到这一步，虽然很遗憾，但请各位不要心急。
迭代回声服务器端/客户端
前面讲的就是迭代服务器端。即使服务器端以迭代方式运转，客户端代码亦无太大区别。接下来创建迭代回声服务器端及与其配套的回声客户端。首先整理一下程序的基本运行方式。
- 服务器端在同一时刻只与一个客户端相连，并提供回声服务
- 服务器端依次向5个客户端提供服务并退出
- 客户端接收用户输人的字符串并发送到服务器端
- 服务器端将接收的字符串数据传回客户端，即“回声”
- 服务器端与客户端之间的字符串回声一直执行到客户端输入0为止。
首先介绍满足以上要求的回声服务器端代码。希望各位注意观察accept函数的循环调用过程。
#include <arpa/inet.h>
#include <cstring>
#include <iostream>
#include <string>
#include <sys/socket.h>
#include <unistd.h>
constexpr size_t BUF_SIZE = 1024;
int main(int argc, char* argv[])
{
if (argc != 2) {
std::cout << "Usage: " << argv[0] << " port" << std::endl;
return 0;
}
// 创建套接字
int servSock = socket(PF_INET, SOCK_STREAM, 0);
if (servSock == -1) {
std::cout << "socket 错误！" << std::endl;
return 0;
}
// 初始化地址信息
sockaddr_in servAdr;
std::memset(&servAdr, 0, sizeof(servAdr));
servAdr.sin_family = AF_INET;
servAdr.sin_addr.s_addr = htonl(INADDR_ANY);
servAdr.sin_port = htons(std::atoi(argv[1]));
// 绑定套接字地址信息
int stu = bind(servSock, (sockaddr*)&servAdr, sizeof(servAdr));
if (stu == -1) {
close(servSock);
std::cout << "bind 错误！" << std::endl;
return 0;
}
// 进入监听状态
stu = listen(servSock, 5);
if (stu == -1) {
close(servSock);
std::cout << "listen 错误！" << std::endl;
return 0;
}
char buf[BUF_SIZE] = { 0 };
// 循环接收请求，只接收5次
for (int i = 0; i < 5; ++i) {
sockaddr_in clntAdr;
socklen_t szClntAdr = sizeof(clntAdr);
int clntSock = accept(servSock, (sockaddr*)&clntAdr, &szClntAdr);
if (stu == -1) {
std::cout << "第" << i << "个客户端"
<< "accept 错误！" << std::endl;
continue;
} else {
std::string adrStr = inet_ntoa(clntAdr.sin_addr);
std::cout << "接收第" << i << "个客户端"
<< ":" << adrStr << std::endl;
}
int strLen = 0;
do {
strLen = read(clntSock, buf, BUF_SIZE);
if (strLen == -1) {
std::cout << "第" << i << "个客户端 read 错误" << std::endl;
break;
}
write(clntSock, buf, strLen);
} while (strLen != 0);
close(clntSock);
std::cout << "第" << i << "个客户端通信完毕" << std::endl;
}
close(servSock);
return 0;
}
在运行过程中，同时只能处理一个客户端，直到客户端断开连接，read才会返回0，进而退出读取逻辑，关闭客户端套接字。
然后进入下一个循环，接收新的请求。
回声客户端代码：
#include <arpa/inet.h>
#include <cstring>
#include <iostream>
#include <string>
#include <sys/socket.h>
#include <unistd.h>
constexpr size_t BUF_SIZE = 1024;
int main(int argc, char* argv[])
{
if (argc != 3) {
std::cout << "Usage: " << argv[0] << " IP port" << std::endl;
return 0;
}
// 创建套接字
int clntSock = socket(PF_INET, SOCK_STREAM, 0);
if (clntSock == -1) {
std::cout << "socket 错误" << std::endl;
return 0;
}
// 初始化服务器地址信息
sockaddr_in servAdr;
servAdr.sin_family = AF_INET;
servAdr.sin_addr.s_addr = inet_addr(argv[1]);
servAdr.sin_port = htons(std::atoi(argv[2]));
// 连接到服务器
int stu = connect(clntSock, (sockaddr*)&servAdr, sizeof(servAdr));
if (stu == -1) {
close(clntSock);
std::cout << "connect 错误" << std::endl;
return 0;
}
char buf[BUF_SIZE] = { 0 };
while (true) {
std::cout << "输入消息：";
std::string msg;
std::cin >> msg;
if (msg == "Q" || msg == "q") {
break;
}
write(clntSock, msg.c_str(), msg.size());
int strLen = read(clntSock, buf, BUF_SIZE - 1);
buf[strLen] = 0;
std::cout << "服务端消息：" << buf << std::endl;
}
close(clntSock);
return 0;
}
我们编写的回声服务器端（客户端以字符串为单位传递数据。理解这一点后再观察echo_client.c 第45行和第46行。各位若已完全掌握了之前讲过的TCP，就会意识到这2行代码不太适合做字符串单位的回声。
回声客户端存在的问题
代码有个错误假设：
“每次调用read、write函数时都会以字符串为单位执行实际的I/O操作。”
当然，每次调用write函数都会传递1个字符串，因此这种假设在某种程度上也算合理。但大家还记得第2章中"TCP不存在数据边界"的内容吗？上述客户端是基于TCP的，因此，多次调用write函数传递的字符串有可能一次性传递到服务器端。此时客户端有可能从服务器端收到多个字符串，这不是我们希望看到的结果。还需考虑服务器端的如下情况：
“字符串太长，需要分2个数据包发送！”
那样客户端就无法读完数据
服务器端希望通过调用1次write函数传输数据，但如果数据太大，操作系统就有可能把数据分成多个数据包发送到客户端。另外，在此过程中，客户端有可能在尚未收到全部数据包时就调用read函数。
所有这些问题都源自TCP的数据传输特性。那该如何解决呢？答案请见第5章。
“但上述示例不是正常运转了吗？”
当然，我们的回声服务器端/客户端给出的结果是正确的。但这只是运气好罢了！只是因为收发的数据小，而且运行环境为同一台计算机或相邻的两台计算机，所以没发生错误，可实际上仍存在发生错误的可能。
基于Windows的实现
随着本书学习的深入，Windows和Linux的平台差异将愈加明显。但至少现在还不大，所以很容易将Linux示例移植到Windows平台。
基于 Windows 的回声服务器端
为了将Linux平台下的示例转化成Windows平台示例，需要记住以下4点。
- 通过WSAStartup、WSACleanup函数初始化并清除套接字相关库。
- 把数据类型和变量名切换为Windows风格。
- 数据传输中用recv、send函数而非read、write函数。
- 关闭套接字时用closesocket函数而非close函数。
接下来给出基于Windows的回声服务器端。只需更改如上4点，故省略。
934
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
