17370845950

Python网络超时由操作系统在系统调用未完成时返回错误触发，非解释器主动中断；连接超时发生于TCP三次握手阶段，读取超时发生于已连接后等待数据时，DNS解析不属其范畴，且实际耗时可能略超设定值。

Python 网络超时由底层 socket 层触发，不是 Python 解释器主动“计时中断”，而是当系统调用（如 connect()、recv()）在指定时间内未完成时，操作系统返回错误，Python 将其封装为 socket.timeout 或更通用的 TimeoutError 异常。

连接超时（connect timeout）

发生在 TCP 三次握手阶段。调用 socket.connect() 时，若在设定时间内未收到 SYN-ACK 响应，内核返回 ETIMEDOUT（Linux）或 WSAETIMEDOUT（Windows），Python 抛出 socket.timeout。

• 使用 socket.settimeout(n) 设置

  

  后，所有阻塞 I/O 操作都受控，包括 connect()
• 也可用 socket.setsockopt(socket.SOL_SOCKET, socket.SO_RCVTIMEO, ...) 单独设接收超时，但不推荐——跨平台行为不一致
• requests 库中的 timeout=(3, 7) 第一个数字即连接超时，本质是调用底层 socket 的 connect 超时

读取超时（read timeout）

发生在已建立连接后等待数据到达时。例如调用 recv() 或 readline()，若对端迟迟不发数据，且 socket 已设超时，内核在超时后返回 EAGAIN/EWOULDBLOCK，Python 转为 socket.timeout。

• HTTP 长连接中，服务端可能保持连接但延迟发送响应体，此时读取超时会中断等待
• requests 中 timeout=(3, 7) 的第二个数字即读取超时，覆盖整个响应体接收过程
• 注意：超时从调用 recv() 开始计，不是从请求发出开始

DNS 解析是否算在网络超时里？

不算。DNS 查询由操作系统或 libc 的 getaddrinfo() 完成，不走 socket 超时机制。它有自己的超时逻辑（如 /etc/resolv.conf 中的 timeout: 和 attempts:），Python 默认不干预。

• requests、urllib 等库发起请求前先做 DNS 解析，若解析卡住，会表现为“连接前就卡住”，但异常类型通常是 gaierror 或 ConnectionError，而非 TimeoutError
• 可手动用 socket.getaddrinfo(host, port, timeout=5)（Python 3.12+）控制 DNS 超时，旧版本需配合线程/asyncio 实现

超时不是“精确倒计时”

实际耗时可能略超设定值。原因包括：

• Python 在系统调用返回后才抛异常，而内核定时器精度有限（通常 10–15ms）
• 线程调度延迟：CPython GIL 切换、系统负载高时，异常抛出可能延后几毫秒到几十毫秒
• 某些场景（如 HTTPS 握手）涉及多次系统调用，超时是各阶段叠加，非单一计时器