目录
什么是 Socket 编程
TCP Socket 编程
应用消息格式
为什么要定义消息格式
示例1
示例2
支持多个 TCP 客户端
UDP Socket 编程
UDP 协议特点
UDP Socket 编程
现在的软件开发基本都需要 。
不管是传统计算机软件，还是手机软件，还是物联网嵌入系统软件，这些都要和其他网络系统进行通讯。
而当今网络世界 基本上 都是使用TCP/IP协议进行通讯的。任何应用，比如 浏览网页、微信、支付宝、抖音 或者我们开发的 等等都是 通过TCP/IP协议进行通讯的。
TCP/IP 协议 就是一种传输数据的方案。
软件开发上，收发信息的 就像 ；
收发的 就像 快递传输的 ；
具体信息的传输路径（中间经过哪些路由器）和传输的方法（使用什么协议）就像 快递公司的运输流程；
同样的，我们编写发出信息的程序和接收信息的程序，并不需要知道信息传输的所有细节，比如 中间经过哪些路由器，路由器之间又是如何传输的。
我们作为程序员，只要知道，我们的程序如何把 所要发送的信息 交给 ‘收件人’， 如何从 ‘送件人’ 手中获取信息。
那么 和我们的 应用程序 直接打交道的 ‘收件人’ 和 ‘送件人’ 到底是谁？
就是操作系统 提供的
发送信息的应用程序，通过 把信息给操作系统的TCP/IP协议栈通讯模块；
通讯模块一层层传递给 其他通讯模块（网卡驱动等），最后再通过网卡等硬件设备发送到网络上去；
经过网络上路由器的一次次转发，最终到了目的程序 所在的 计算机（或者手机等设备） ， 再通过 其 操作系统的 TCP/IP协议栈通讯模块 一层层上传。
最后接收信息的程序，通过 接收到了传输的信息。
这个过程可以用下图来表示
大家可能使用过 requests库 发送 HTTP请求消息，其实 requests库底层也是使用的socket编程接口发送HTTP请求消息。
HTTP 传输的消息 底层也是通过 TCP/IP 协议传输的， HTTP 加上了一些额外的规定， 比如传输消息的格式。
要进行socket编程，发送网络消息，我们可以使用 Python 内置的 socket 库 。
目前的socket编程，使用的最多的就是通过TCP协议进行网络通讯的。
TCP进行通讯的程序双方，分为服务端和客户端。
TCP 协议进行通讯的双方，是需要先建立一个虚拟连接的。然后双方程序才能发送业务数据信息。
建立TCP虚拟连接是通过著名的 进行的。
具体三次握手的细节大家可以参考这篇文章 深入理解tcp三次握手和四次挥手？ - 知乎
我们现在来看一个 TCP协议进行通讯的 socket 服务端程序和客户端程序。
- 创建套接字──socket()
- 指定本地地址──bind()
- 建立套接字连接──connect()与accept()
- 监听连接──listen()
- 数据传输──send()与recv()
- 输入/输出多路复用──select()
- 关闭套接字──closesocket()
下面是TCP 服务端程序 server.py
下面是TCP 客户端程序 client.py
为什么要定义消息格式
上面的例子中，我们发送的消息就是要传递的内容。 比如字符串。
实际上，我们在企业中开发的程序通讯，消息往往是有 的。 消息的格式定义可以归入 OSI网络模型的 。
比如: 定义的消息包括 消息头 和 消息体。
消息头存放消息的格式数据， 比如 消息的长度、类型、状态等等， 而消息体存放具体的传送数据。
对于使用TCP协议传输信息的程序来说，格式定义一定要明确规定 。
因为 TCP协议传输的是 ， 如果消息中没有指定边界或者长度，接收方就不知道一个完整的消息从字节流的哪里开始，到哪里结束。
指定消息的边界有两种方式：
- 用特殊字节作为消息的结尾符号
可以用消息内容中不可能出现的字节串 （比如 ） 作为消息的结尾字符。
- 在消息开头某个位置，直接指定消息的长度
比如在一个消息的最前面用2个字节表示本消息的长度。
UDP协议通常不需要指定消息边界，因为UDP是数据报协议，应用程序从socket接收到的必定是发送方发送的完整消息。
示例1
我们现在要开发一个实验室的工作站监控系统，包括
-
安装在机房工作站上的 数据采集器 RUS
这个程序作为TCP服务端，获取资源使用数据，简称 RUS （Resource Usage Stat）
-
安装在监控室的管理控制台 AT
这个程序作为TCP客户端，向管理员显示资源使用数据，简称 AT （Admin Terminal）
-
作为这个系统的设计者，你可以自行设计 RUS 和 AT 之间的数据传输规范，包括消息 数据格式规范。
下面是一种参考的规范：
-
AT 和 RUS 之间采用 TCP 长连接方式进行通讯
如果中途出现连接断开，AT 作为 TCP 客户端必须进行重连
-
消息整体
每个消息 都是 UTF8 编码的 字符串
由消息头 和消息体组成。
消息头 和消息体之间 用一个 换行符 （UTF8编码后的字节为 ）隔开。
有如下类型的消息：
-
控制命令
由 AT 发送给 RUS ， 下达管理控制命令。
比如：
- pause 暂停数据采集
- resume 恢复数据采集
RUS接收到 控制命令后，必须完成操作后必须回复响应消息，告诉 AT 命令已经接收已经完成
-
数据上报
由 RUS 发送给 AT，汇报采集的资源数据。 AT接收到数据后，应该回复一个接收汇报的响应消息。
-
-
消息头
消息头只包含一个信息： 消息体的长度
消息头用十进制的字符串 表示一个整数的长度
-
消息体
消息体用json格式的字符串 表示数据信息，如下
- 数据上报 RUS -> AT
- 数据上报响应 AT -> RUS
- 暂停数据上报命令 AT -> RUS
其中 duration 表示暂停上报的时间，以秒为单位
- 恢复数据上报命令 AT -> RUS
- 命令处理响应 RUS -> AT
其中code 是处理结果码，用200表示成功。 info 是处理结果文字描述。
示例2
示例1 中，我们给出的参考接口， 传递的消息都是 放在一个大字符串里面， 然后采用字符串编码为字节串进行传输的。
这种接口设计的好处就是简单，便于发送时的字节编码操作：消息头和消息体分别进行 UTF8编码，然后字节串拼接即可
接收方处理也简单，直接分离出消息头和消息体，分别进行UTF8解码即可。
我们设计普通应用程序之间的通信，这样就很好，简单就是美，容易开发，容易维护。
但是如果消息接口是在 的计算节点之间的通讯， 这样的接口的缺点就暴露了：消息长，而且编解码耗费处理器资源比较大。
典型的例子，就是通讯设备， 比如 4G核心网的业务处理节点。 它们每秒往往要处理数以万计的认证、鉴权、计费 等消息，采用上述方法会给设备带来巨大负担。
首先，数据都用字符表示，其实是比较浪费带宽的做法。
比如返回码 用 200 这样的字符串表示，就会耗费3个字节，24个比特。 如果处理结果 只有成功和不成功，只需要1个bit 即可， 1表示成功，0表示不成功
其次， json这种复杂语法的编解码算法，需要程序代码进行各种复杂处理（参考一下Python json内置库的代码）是比较耗费CPU 资源的。
可以定义更为简单的数据表达方式，比如像这样：
-
消息头 开头2个字节表示消息的长度
-
消息头 第3个字节表示 消息类型 ：
0：暂停命令， 1 ：恢复命令 2：命令响应 3：统计上报 4：统计上报响应
-
消息体 数据定义
可以使用类似 Radius/Diameter Attribute-Value Pairs （AVP） 的定义方法
Attribute： 使用一个字节，表示数据种类。
比如
1： CPU 使用率 2： 内存使用率
Length： 使用一个字节，表示信息长度
Value： 表示具体的数据值
这样，前面的示例信息
其中
, 就像这样用16进制字节表示
, 就像这样用16进制字节表示
合起来就是
对比一下，第一种编码方法
优点：更节省传输带宽，编码解码数据效率更高
缺点：对于人的可读性差，数据表示灵活性较差；
上面的服务端代码 只能和一个客户端进行通信。
如果我们同时运行多个客户端，就会发现 后面的客户端程序不能和服务端连接成功。为什么呢？
因为，服务端程序必须不停的对 监听 socket 对象调用 accept()方法，才能不断的接受 新的客户端连接请求。
而且 还需要运行额外的代码 对 多个客户端连接后，返回的多个数据传输socket对象 进行数据的收发。
显然，我们上面的程序没有这样的处理。
因为缺省情况创建的 socket 是 的，进行 accpet调用时，如果没有客户端连接，程序就阻塞在此处，不再执行后续代码。
同样的，调用recv方法，如果没有数据在本socket的接收缓冲，也会阻塞。
所以，通常一个线程里面，没法不断地 调用 监听socket的 accept方法，同时还能负责多个数据传输socket消息的收发。
那么让一个服务端程序和多个客户端同时连接并通信呢？
一个线程不行，就使用多个线程啊。
修改服务端的代码，如下
多线程方式有个缺点。
如果一个服务端要同时处理大量的客户端连接，比如10000个，需要创建10000个线程。
而操作系统通常不可能为一个进程分配这么多的线程。
实际上，我们的服务端程序，大部分时间都是空闲的，都在等待连接请求，等待接受消息，根本不需要这么多的线程来处理。
这种程序通常被称之为 IO bound 程序，也就是说程序的主要时间都是花费在 IO 上面。
这种程序，其实一个线程就足够了。
关键问题是，需要这一个线程 很好的分配 时间， 在有连接请求到来的时候，执行处理连接请求代码，有消息到达socket缓冲的时候，执行读取处理消息的代码。
这种处理方式称之为异步IO。
Python 3 新增了 asyncio 库， 我们可以使用该库来 实现 同时处理多个客户端数据收发。
示例代码如下：
UDP 协议特点
UDP (User Datagram Protocol) 中文称之为 用户数据报协议， 和TCP一样，也是一种传输层协议。
和TCP较大的不同点在于：
- 它是一种无连接 协议
也就是说：无需事先建立虚拟连接，可以直接给对方地址发送消息。
通信方的地址也是由 IP地址 和 端口号构成。
所以相比 TCP协议，它更加简单快捷。
- 没有消息可靠性保证
UDP传输的消息如果在网络上丢失了，就丢失了。UDP协议本身没有重传机制。
而TCP协议底层有消息验证是否到达，如果丢失，发送方会重传的机制。
所以，如果应用要么不在意丢失一些信息，要么应用层自己实现一套机制保证可靠性。
- 数据消息发送是独立的报文
TCP协议通信双方的信息数据就像流动在管道中，是有明确的先后次序的。
发送方应用 先发送的信息肯定 是 先被接收方应用 先接收的 。
而UDP协议发送的是一个个的独立的报文，接收方应用接收到的次序不一定和发送的次序一致。
对于我们应用开发来说，特别需要注意的一点是：系统设计时要确定应用语义中的 。
这样编码的时候，可以确定一个对应长度的 应用程序接收缓冲，防止出现只接收了一部分的情况。
TCP Socket 是流式（stream）协议，如果应用接收缓冲不够大，只接受了一部分，没有关系，后面继续接收，然后找到消息边界拼接就可以了。
而 UDP式数据报协议， UDP Socket 如果只接受了数据报的一部分，剩余的消息就会被丢弃。下次接收，只能接收到下一个数据报的内容了。
UDP Socket 编程
下面是一个 UDP Socket通信 的示例代码。
实现 客户端 请求服务端返回用户信息 的功能。
客户端请求 消息里面的 action 和 name 参数指定了 和
客户端代码
服务端代码
可以看出 UDP通信服务端 的socket 也需要绑定端口号。
但是和TCP不同， 服务端只需要一个socket进行通信即可，不需要 2个socket分别用来监听和通信。
而 UDP客户端的socket 通常不需要指定绑定的端口号， 操作系统会自动帮其选择一个绑定。
当不需要使用 UDP Socket 时，可以通过 socket 对象的 close 方法 关闭，如下代码所示。
关闭 socket 后，该端口绑定的 端口号 就会被释放，可以再次被本进程或者其它进程的 socket 绑定使用