Python如何做网络编程？Socket通信教程

python网络编程核心是socket模块，通过它可直接操作tcp/udp协议实现服务器与客户端通信。1. tcp服务器端流程：创建socket对象→绑定ip和端口→监听连接→接受客户端连接→接收/发送数据→关闭连接。2. tcp客户端流程：创建socket对象→连接服务器→发送/接收数据→关闭连接。3. 数据传输需注意：sendall()确保完整发送；recv()需处理粘包问题，应用层可通过“长度+数据”协议解决。4. 编码解码需统一使用encode()/decode()。5. 并发处理可通过多线程、多进程或i/o多路复用（如selectors模块）实现。6. 常见问题及解决：地址被占用可设置so_reuseaddr；连接被拒绝需检查服务状态和防火墙；数据接收不完整需设计协议；broken pipe需检测连接状态；阻塞问题可设超时或使用非阻塞+i/o复用。

Python的网络编程，说到底，核心就是

socket

解决方案

要用Python进行网络编程，特别是基于TCP的Socket通信，基本流程其实挺清晰的，虽然初次接触可能会觉得有点绕。简单来说，就是服务器端和客户端各司其职。

TCP服务器端：

立即学习“Python免费学习笔记（深入）”；

1. 创建Socket对象： 就像你要打电话，得先有个电话机。

   socket.socket(socket.AF_INET, socket.SOCK_STREAM)

   ，这里

   AF_INET

   表示使用IPv4地址，

   SOCK_STREAM

   表示使用TCP协议（流式套接字）。
2. 绑定地址和端口： 电话机有了，得插上电话线，并告诉大家你的电话号码。

   s.bind(('127.0.0.1', 8888))

   ，把你的服务绑定到一个IP地址和端口上。

   127.0.0.1

   是本地回环地址，

   8888

   是个常用端口。
3. 开始监听： 电话号码公布了，就等着电话响。

   s.listen(5)

   ，设置最大连接排队数，这里是5个。
4. 接受连接： 电话响了，接起来。

   conn, addr = s.accept()

   ，这会阻塞直到有客户端连接进来。

   conn

   是新的连接套接字，专门用来和这个客户端通信，

   addr

   是客户端的地址。
5. 数据交互： 电话接通了，开始聊天。

   conn.recv(1024)

   接收数据，

   conn.sendall(data)

   发送数据。记住，网络传输的都是字节流，所以发送前要

   encode()

   ，接收后要

   decode()

   。
6. 关闭连接： 聊完了，挂电话。

   conn.close()

   关闭与客户端的连接，

   s.close()

   关闭服务器自身的监听套接字（通常在服务停止时才做）。

TCP客户端：

1. 创建Socket对象： 同样，先有个电话机。

   socket.socket(socket.AF_INET, socket.SOCK_STREAM)

   。
2. 连接服务器： 知道对方号码，拨过去。

   s.connect(('127.0.0.1', 8888))

   ，尝试连接服务器的IP和端口。
3. 数据交互： 连接成功，开始聊天。

   s.sendall(data)

   发送数据，

   s.recv(1024)

   接收数据。
4. 关闭连接： 聊完了，挂电话。

   s.close()

   。

这是一个简单的Echo服务器和客户端的例子，你可以感受一下：

服务器端 (server.py):

import socket

HOST = '127.0.0.1'  # 标准回环接口地址
PORT = 65432        # 非特权端口 > 1023

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.bind((HOST, PORT))
    s.listen()
    print(f"服务器正在监听 {HOST}:{PORT}...")
    conn, addr = s.accept() # 阻塞，直到有客户端连接
    with conn:
        print(f"连接自: {addr}")
        while True:
            data = conn.recv(1024) # 接收数据，缓冲区大小1024字节
            if not data: # 如果没有数据，说明客户端断开连接
                print(f"客户端 {addr} 已断开。")
                break
            print(f"收到来自 {addr} 的消息: {data.decode()}")
            conn.sendall(data) # 把收到的数据原样发回去
            print(f"已回发给 {addr}")

客户端 (client.py):

import socket

HOST = '127.0.0.1'  # 服务器的IP地址
PORT = 65432        # 服务器的端口

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect((HOST, PORT)) # 连接服务器
    message = "Hello, server! This is client."
    s.sendall(message.encode()) # 发送编码后的数据
    print(f"已发送: '{message}'")
    data = s.recv(1024) # 接收服务器回传的数据
    print(f"收到回显: {data.decode()}")

运行的时候，先启动

server.py

client.py

Python Socket通信：客户端与服务器端数据流动的那些事儿

在Socket通信中，数据流动远不止

send

recv

首先，

send()

sendall()

send()

send()

sendall()

sendall()

再来说说接收数据，也就是

recv(bufsize)

bufsize

recv

举个例子，客户端连续发送两条消息“Hello”和“World”，服务器端一次

recv

A1.art

一个创新的AI艺术应用平台，旨在简化和普及艺术创作

下载

数据的编码和解码也是个常被忽略但又很重要的点。Python 3里字符串是Unicode，但网络传输的是字节流。所以，发送前必须调用

.encode('utf-8')

.decode('utf-8')

当一个不够用：Python Socket如何应对海量并发连接的挑战？

上面那个简单的Echo服务器，它一次只能处理一个客户端连接。当一个客户端连接上来后，服务器就会被“卡住”，直到这个客户端断开，才能接受下一个连接。这显然无法满足现代网络应用的需求，想想微信、淘宝，那得同时处理多少用户啊！

要让服务器能同时服务多个客户端，我们通常会考虑几种并发策略。

一种比较直观的方式是多线程（threading）或多进程（multiprocessing）。当服务器接受到一个新的客户端连接时，它可以创建一个新的线程或进程来专门处理这个客户端的通信。这样，主线程（或主进程）就可以继续监听新的连接请求了。

• 多线程模型： 每个客户端连接都分配一个线程去处理。优点是线程创建和切换的开销相对较小，线程间共享内存，数据交换方便。缺点是Python的GIL（全局解释器锁）会限制CPU密集型任务的并行执行，但在I/O密集型任务（网络通信就是典型的I/O密集型）中，GIL的影响没那么大，因为线程在等待I/O时会释放GIL。
• 多进程模型： 每个客户端连接都分配一个进程去处理。优点是进程之间内存独立，互不影响，安全性高，可以充分利用多核CPU。缺点是进程创建和切换的开销较大，进程间数据共享需要特殊的IPC（进程间通信）机制。

这两种方式，代码实现起来都相对直接，你只需要在

s.accept()

conn

addr

# 多线程服务器伪代码
import socket
import threading

def handle_client(conn, addr):
    print(f"新线程处理连接自: {addr}")
    with conn:
        while True:
            data = conn.recv(1024)
            if not data:
                break
            print(f"收到来自 {addr} 的消息: {data.decode()}")
            conn.sendall(data)
    print(f"线程 {addr} 已结束。")

# ... (服务器初始化代码) ...
# s.listen()
while True:
    conn, addr = s.accept()
    client_thread = threading.Thread(target=handle_client, args=(conn, addr))
    client_thread.start()

另一种更高级、更高效的方式是I/O多路复用（I/O Multiplexing）。这不是为每个连接创建一个线程或进程，而是用一个（或少数几个）线程来同时监控多个Socket连接的状态。当某个Socket准备好读写时，操作系统会通知你。Python的

select

selectors

asyncio

I/O多路复用避免了创建大量线程/进程的开销，尤其适用于连接数非常多但每个连接的I/O操作并不频繁的场景（比如聊天服务器）。它让单个线程能够“同时”管理成千上万个连接，效率非常高。理解

select

epoll

踩坑不慌：Python Socket编程中常见的疑难杂症与解法

网络编程这东西，说不准什么时候就给你来个“惊喜”。我自己在写Socket应用的时候，也遇到过不少让人头疼的问题。提前知道这些坑，至少能让你在遇到的时候不那么慌乱。

1. Address already in use

   (地址已被占用)：这是个非常常见的错误，尤其是在你调试服务器端程序时。当你停止一个服务器程序，但它没有完全释放端口，或者上次异常退出导致端口被操作系统暂时占用时，你再次启动服务器就会报这个错。
   • 解法： 等待一段时间让操作系统释放端口（通常几十秒）。更直接的办法是在

     s.bind()

     之前，设置

     s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

     。这告诉操作系统，即使端口还在TIME_WAIT状态，也可以立即重用。这个选项在开发调试时特别有用，在生产环境也经常使用。

2. Connection refused

   (连接被拒绝)：客户端尝试连接服务器时遇到这个错误，通常意味着：
   • 服务器程序没有运行。
   • 客户端连接的IP地址或端口号是错的。
   • 服务器的防火墙阻止了连接。
   • 解法： 检查服务器是否已启动并监听正确地址端口，核对客户端配置，检查服务器和客户端机器的防火墙设置。

3. 数据接收不完整或粘包：前面提过，

   recv()

   不保证一次性收到完整消息。
   • 解法： 应用层协议是唯一的解决方案。最常见的就是“长度+数据”的模式。发送方先发送一个固定长度的头部（比如4个字节），表示后面数据的总长度，然后发送实际数据。接收方先读取4个字节的头部，解析出数据长度，然后循环读取直到收到完整的数据包。

4. Broken pipe

   或

   Connection reset by peer

   ：这通常发生在一方关闭了连接，而另一方还在尝试发送数据时。比如，客户端断开了，服务器还在往这个已关闭的连接上发送数据。
   • 解法： 在发送数据前，最好能检查一下连接是否仍然有效。更重要的是，在你的通信循环中，要正确处理

     recv()

     返回空字节串的情况（表示对方已关闭连接），并及时关闭自己的连接。

5. 阻塞I/O导致程序卡死：默认情况下，

   socket.accept()

   、

   socket.recv()

   等都是阻塞的。这意味着如果长时间没有数据，你的程序就会一直等待。
   • 解法：
     • 多线程/多进程： 将阻塞操作放到单独的线程/进程中。
     • 设置超时：

       s.settimeout(timeout_seconds)

       可以为Socket操作设置一个超时时间，超时后会抛出

       socket.timeout

       异常。
     • 非阻塞模式：

       s.setblocking(False)

       可以将Socket设置为非阻塞模式，此时

       accept()

       或

       recv()

       如果没有数据会立即返回一个

       BlockingIOError

       或

       WouldBlockError

       。这通常需要配合I/O多路复用（如

       select

       或

       selectors

       ）来使用，因为你需要知道哪个Socket在什么时候准备好了。

调试Socket程序时，除了常规的打印日志和断点调试，我发现网络抓包工具（比如Wireshark）简直是神器。它能让你看到网络上实际传输的每一个数据包，包括TCP握手、数据内容、各种标志位，这对于理解网络行为和定位问题非常有帮助。很多时候，代码看起来没问题，但网络层面的一个小细节就可能导致意想不到的行为。