TCP/IP网络编程（4）——基于 TCP 的服务端/客户端（1）

第 4 章 基于 TCP 的服务端/客户端1

4.1 理解 TCP 和 UDP

根据数据传输方式的不同基于网络协议的套接字一般分为 TCP 套接字和 UDP 套接字。因为 TCP 套接字是面向连接的因此又被称为基于流stream的套接字。

TCP 是 Transmission Control Protocol 传输控制协议的简写意为对数据传输过程的控制

4.1.1 TCP/IP 协议栈

TCP/IP 协议栈共分为 4 层可以理解为数据收发分成了 4 个层次化过程通过层次化的方式来解决问题

4.1.2 链路层

链路层专门定义 LAN、WAN、MAN 等网络标准。若两台主机通过网络进行数据交换则需要物理连接链路层就负责这些标准。

4.1.3 IP 层

准备好物理连接后就要传输数据。为了在复杂网络中传输数据首先要考虑路径的选择。向目标传输数据需要经过哪条路径 解决此问题的就是IP层该层使用的协议就是IP。

IP 是面向消息的、不可靠的协议。每次传输数据时会帮我们选择路径但并不一致。如果传输过程中发生错误则选择其他路径但是如果发生数据丢失或错误则无法解决。换言之IP协议无法应对数据错误。

4.1.4 TCP/UDP 层

IP 层解决数据传输中的路径选择问题只需照此路径传输数据即可。TCP 和 UDP 层以 IP 层提供的路径信息为基础完成实际的数据传输故该层又称为传输层。UDP 比 TCP 简单现在我们只解释 TCP 。 TCP 可以保证数据的可靠传输但是它发送数据时以 IP 层为基础这也是协议栈层次化的原因。

IP 层只关注一个数据包数据传输基本单位的传输过程。因此即使传输多个数据包每个数据包也是由 IP 层实际传输的也就是说传输顺序及传输本身是不可靠的。若只利用IP层传输数据则可能导致后传输的数据包B比先传输的数据包A提早到达。另外传输的数据包A、B、C中可能只收到A和C甚至收到的C可能已经损毁 。反之若添加 TCP 协议则按照如下对话方式进行数据交换。

这就是 TCP 的作用。如果交换数据的过程中可以确认对方已经收到数据并重传丢失的数据那么即便IP层不保证数据传输这类通信也是可靠的。

4.1.5 应用层

上述内容是套接字通信过程中自动处理的。选择数据传输路径、数据确认过程都被隐藏到套接字内部。向程序员提供的工具就是套接字只需要利用套接字编出程序即可。编写软件的过程中需要根据程序的特点来决定服务器和客户端之间的数据传输规则这便是应用层协议。

4.1.6 生活小例子

假设你在网上买了个增肌粉店家送你一个杯子一个小盒子和一罐营养片三个赠品你在福州下单之后店家就在武汉发货了。链路层就像是福州和武汉之间无数条公路这是必须的基础设施IP层就像快递员他可以选择某一条很近的道路送过来但是他无法保证先送过来的是增肌粉于是他先把赠品送了过来实际上我们是要求有序先增肌粉再赠品于是你去了快递站发现只有一个赠品是无法从快递站拿出来的淘宝的聊天系统就像 TCP 协议你告诉店家只有一个赠品时店家会说“抱歉忘记发增肌粉了”然后重发或者他会崔快递员赶紧把增肌粉发到福州那么我就能先拿到增肌粉再拿到赠品了。如果这时候发现赠品少了个杯子或者杯子损坏了我就可以通过聊天系统和店家反应这时店家就会给我重新发一个一模一样的赠品。

4.2 实现基于 TCP 的服务器/客户端

4.2.1 TCP 服务端的默认函数的调用程序

这在第一章就已经讲到过了

4.2.2 进入等待连接请求状态

调用 bind 函数给套接字分配地址接下来就是要通过调用 listen 函数进入等待链接请求状态。只有调用了 listen 函数客户端才能进入可发出连接请求的状态。客户端可以调用 connect 函数向服务端请求连接对于客户端发来的请求先进入连接请求等待队列等待服务端受理请求。

#include <sys/socket.h>
int listen(int sock, int backlog);
//成功时返回0失败时返回-1
//sock: 希望进入等待连接请求状态的套接字文件描述符传递的描述符套接字参数称为服务端套接字
//backlog: 连接请求等待队列的长度若为5则队列长度为5表示最多使5个连接请求进入队列            

4.2.3 受理客户端连接请求

调用 listen 函数后套接字应该按序受理客户端发起的连接请求。受理请求就是服务端处理一个连接请求进入可接受客户端数据的状态。进入这种状态所需的部件是套接字但是此时使用的不是服务端套接字此时需要另一个套接字但是没必要亲自创建下面的函数将自动创建套接字。
因此服务端和客户端之间是有三个套接字的

#include <sys/socket.h>
int accept(int sock, struct sockaddr *addr, socklen_t *addrlen);
/*
成功时返回文件描述符失败时返回-1
sock: 服务端套接字的文件描述符
addr: 受理的请求中客户端地址信息会保存到该指针指向的地址
addrlen: 该指针指向的地址中保存第二个参数的结构体长度
*/

accept 函数受理连接请求队列中待处理的客户端连接请求。函数调用成功后accept 内部将产生用于数据 I/O 的套接字并返回其文件描述符。需要强调的是套接字是自动创建的并自动与发起连接请求的客户端建立连接。

注意accept 函数返回的套接字不等于服务端套接字也需要通过 close 函数关闭。

4.2.4 回顾 Hello World 服务端

代码程序下载

重新整理一下代码的思路

1. 服务端实现过程中首先要创建套接字此时的套接字并非是真正的服务端套接字
2. 为了完成套接字地址的分配初始化结构体变量并调用 bind 函数。
3. 调用 listen 函数进入等待连接请求状态。连接请求状态队列的长度设置为5。
4. 调用 accept 函数从队头取 1 个连接请求与客户端建立连接并返回创建的套接字文件描述符。另外调用 accept 函数时若等待队列为空则 accept 函数不会返回直到队列中出现新的客户端连接。此时的套接字才是服务端套接字
5. 调用 write 函数向客户端传送数据调用 close 关闭连接

4.2.5 TCP 客户端的默认函数调用顺序

与服务端相比区别就在于「请求连接」它是创建客户端套接字后向服务端发起的连接请求。服务端调用 listen 函数后创建连接请求等待队列之后客户端即可请求连接。

#include <sys/socket.h>
int connect(int sock, struct sockaddr *servaddr, socklen_t addrlen);
/*
成功时返回0失败返回-1
sock:客户端套接字文件描述符
servaddr: 保存目标服务器端地址信息的变量地址值
addrlen: 第二个结构体参数 servaddr 变量的字节长度
*/

客户端调用 connect 函数后发生以下情况之一才会返回完成函数调用:

• 服务端接受连接请求
• 发生断网等异常状况而中断连接请求

注意接受连接不代表服务端调用 accept 函数其实只是服务器端把连接请求信息记录到等待队列。因此 connect 函数返回后并不应该立即进行数据交换。

客户端在调用connect函数时自动分配主机的IP随机分配端口。无需调用标记的bind函数进行分配。

4.2.6 回顾 Hello World 客户端

重新理解这个程序

1. 创建准备连接服务器的套接字此时创建的是 TCP 套接字
2. 结构体变量 serv_addr 中初始化IP和端口信息。初始化值为目标服务器端套接字的IP和端口信息。
3. 调用 connect 函数向服务端发起连接请求
4. 完成连接后接收服务端传输的数据
5. 接收数据后调用 close 函数关闭套接字结束与服务器端的连接。(对套接字调用close函数对应于向建立连接的对应套接字发送EOF。即如果客户端的套接字调用了close函数服务端read时候会返回0。)

4.2.7 基于 TCP 的服务端/客户端函数调用关系

关系图如下所示

• 客户端只能等到服务端调用 listen 函数后才才能调用 connect 函数
• 服务器端可能会在客户端调用 connect 之前调用 accept 函数这时服务器端进入阻塞blocking状态直到客户端调用 connect 函数后接收到连接请求。

4.2.8 服务端/客户端函数调用思维导图

简单整理了一下服务端和客户端的思维导图方便大家记忆
服务端

客户端

4.3 实现迭代服务端/客户端

4.3.1 实现迭代服务器端

在 Hello World 的例子中等待队列的作用没有太大意义。如果想继续处理好后面的客户端请求应该怎样扩展代码最简单的方式就是插入循环反复调用 accept 函数如图:

可以看出调用 accept 函数后紧接着调用 I/O 相关的 read write 函数然后调用 close 函数。这并非针对服务器套接字而是针对 accept 函数调用时创建的套接字。

服务端程序基本运行方式

1. 服务器端在同一时刻只与一个客户端相连(将来学完进程和线程后就可以编写同时服务多个客户端的服务器端了,目前只能做到这一步)并提供回声服务。
2. 服务器端依次向5个客户端提供服务并退出。
3. 客户端接收用户输人的字符串并发送到服务器端
4. 服务器端将接收的字符串数据传回客户端即“回声”
5. 服务器端与客户端之间的字符串回声一直执行到客户端输入Q为止。

程序代码如下

服务端和客户端的程序思维导图

运行结果

但是「第二章」中说过「TCP 不存在数据边界」上述客户端是基于 TCP 的因此多次调用 write 函数传递的字符串有可能一次性传递到服务端。此时客户端有可能从服务端收到多个字符串这不是我们想要的结果。还需要考虑服务器的如下情况

「字符串太长需要分 2 个包发送」

服务端希望通过调用 1 次 write 函数传输数据但是如果数据太大操作系统就有可能把数据分成多个数据包发送到客户端。另外在此过程中客户端可能在尚未收到全部数据包时就调用 read 函数。