Socket 网络编程实践经验
2017-11-04 13:27 云物互联 阅读(448) 评论(0) 编辑 收藏 举报目录
相关文章
NOTE:本文假设你已经对 Socket 的使用有一定的了解。
Socket 与 HTTP 的区别
首先通过对比法来了解两者不同的特性:
HTTP:超文本传输协议,首先它是一个协议,并且是基于 TCP/IP 协议(传输层)之上的应用层协议,要想通过 HTTP 来进行通信,首先需要双方建立起 TCP/IP 连接,因为TCP/IP 主要解决的问题是数据如何在网络中传输,而 HTTP 协议主要解决的问题是如何包装需要传输的数据。所以 HTTP 协议能够支持使用 Header 信息来详细规定浏览器与服务器之间的通信规则。HTTP 连接是基于 Request-Response 的非持久(短)连接,其连接的生命周期通过 Request 界定,一个 Request 一个 Response,此次 HTTP 连接的生命周期结束。对于这点在 HTTP 1.1 中进行了改进,支持 Keep-alive,允许在一个 HTTP 连接的生命周期中,可以发送多个 Request,接收多个 Response,但由 Request 来界定生命周期的本质没有改变。
Socket:首先需要注意的是 Socket 不是一种协议,而是一种调用接口(API)或称之为 TCP/IP 的基本操作单元。Socket 实际上是对 TCP/IP 协议的封装,通过 Socket,就能够应用 TCP/IP 协议来建立连接并传输数据。Socket 连接是持久化(长)连接,这种连接的生命周期能够自主控制,也就是说客户端和服务器端一旦建立连接后,理想状态下连接会持久存在,直到一方自动发出断开指令。
生产实践考虑
下面列出在生产项目中应用 Socket 所需要注意的几点:
- 网络断开重连问题
- 连接会话和身份认证问题
- 同步和异步问题
- 数据缓存问题
- 完全断开连接问题
网络断开重连问题
的确,Socket 连接在理想的网络环境下是持久的长连接,但实际网络环境是复杂的,网络抖动、路由宕机等各种网络问题都会导致 Socket 连接被动断开。而且 Socket 没有提供「自动重连」的机制,所以解决网络断开重连问题,是 Socket 程序稳定性的重要保证。
思路:在 发送 和 接收 前检查 Socket 连接是否依然生效,若不生效,则重新建立 Socket 连接。
那么首先需要解决的是:如何判断 Socket 连接状态是否 ACTIVE?
NOTE:一般的来说,「判断 Socket 连接状态是否 ACTIVE」都是服务端的功能需求,因为服务端需要以此来作为是否回收连接资源的依据。而客户端则无需特别在意,因为即便断开了连接也只需捕获异常、重新连接、重新发送即可。
Heartbeat 心跳机制
别名定义:
- 客户端 Socket == cli-socket
- 服务端 Socket == ser-socket
一般的 Socket 应用程序逻辑中,ser-socket 应该能够感知到 cli-socket 的断开,并且执行相应的断开逻辑处理,释放相应的 Socket 连接资源。但实际是,ser-socket 无法有效的区分 cli-socket 是处于长时间空闲还是处于 offline 的状态,所以也无法确定 cli-socket 的连接是否已经断开。为解决这个问题,程序员所提出的思路就是,屏蔽「长时间空闲」的场景,让 cli-socket 看起来始终是忙碌的(不断发送「无用包」),直到其静默即表示连接断开。
这就是较为通用的用于保证连接质量的心跳机制,而 cli-socket 发送的无用包也称之为心跳包。所谓心跳包就是 cli-socket 定时发送简单的协议信息给 ser-socket,以此让 ser-socket 知道 cli-socket 依旧 online。相对的, ser-socket 就会认为 cli-socket 已经断开。注意,发包方可以是 cli-socket 也可以是 ser-socket,但出于效率的考虑(减轻服务器压力),一般由 cli-socket 承担。如果是流式 Socket(for TCP),则使用 send 发出;如果是数据报式 Socket(for UDP),则使用 sendto 发出。还有一点需要说明,心跳包实际是一个自定义协议包,由开发者制定,并在 cli-socket 和 ser-socket 中遵守。
NOTE:如果仅为了确定 ser-socket 是否 online,可以用 TCP 协议自带的心跳包,应用 socket.socket.setsockopt 的 SO_KEEPALIVE 属性,来设置发包时间间隔。SO_KEEPALIVE 是操作系统的底层机制,用于维护每一个 TCP 连接。但SO_KEEPALIVE 并不能用于替代心跳机制,因为其仅能确保 ser-socket 一方的连接状态。
使用非阻塞模式下的 select 函数进行 Socket 连接检查
以异步(非阻塞)模式建立连接 s.setblocking(0),如果 select 函数返回的值为 1 (表示 Socket 可读),但使用 recv 函数读取到的数据长度为 0,并且 errno != EINTR and errno != EAGAIN,则说明该 Socket 已经断开
NOTE:需要注意的是,在非阻塞模式下,即便 recv 函数的返回值小于等于 0,依旧不足以证明问题。此时还需要继续判断 errno ?= EINTR,如果 Yes,则说明此次 recv 是由于程序接收到 EINTR 中断信号后返回的,Socket 连接仍然正常。除此之外,如果 write 写的太快,很有可能会把 Buffer 写满,这时的 errno == EAGAIN。根据实际需要,如果 errno == EAGAIN 的话,建议重试几次。当然,Read 也有类似的情况。
会话过期问题
如果服务端程序应用了 Session 机制,那么在实现客户端程序时除了需要考虑 Socket 连接的问题之外,还需要考虑 Session 是否过期的问题。
在 发送 和 接收 前首先检查连接是否有效,然后检查会话是否过期:
- 连接失效:则重新建立连接,并且重新创建 session
- 连接有效,但会话过期:则重新创建 session
- 连接有效,会话有效:PASS
同步还是异步问题
选择同步还是异步模式是非常重要的,使用了错误的连接模式将无法达到预期效果。例如高并发需求没能达到,例如程序的稳定性没能提高等等,如何进行选择需要结合实际的应用场景:
- 在高并发且不关注执行结果的场景中使用异步模式。
- 在对程序执行的稳定性,对执行结果响应的准确性都有很高要求的场景下使用同步模式,并且需要保证一次 send 和 recv 的原子性。
NOTE:对于后者,应该尽可以能仅保证 send 和 recv 原子操作是同步的,以此来优化效率。
数据缓存问题
Socket 的 recv 具有缓存功能,如果其中一方发送的数据量超过了另一方 recv 所允许一次接受的最大数据量,数据会被截短,并将剩余的数据缓冲在接收端。再次调用 recv 时,剩余的数据会从缓冲区取出并删除。这一特性与 HTTP 连接方式有很大区别,表示 Socket 连接无法像 HTTP 连接那般,一次 Request 对应的一次 Response 就能完成一次操作单元,而是很可能需要任意次的 send 以及任意次的 recv 才能完成。换句话说就是,需要开发者来保证 send 和 recv 的完整性,你需要手动的整理、组合出完整的发送和响应结果数据。经常的,为了得到一个完整的响应结果可能需要进行多次 recv。
完全断开连接问题
调用 Socket 的 close 函数并不会马上断开 Socket 连接,一般的我们会在 close 之前调用 shutdown 函数来确保连接会被正常关闭。而且 shutdown 提供了多种不同的关闭方式:
- SHUT_RD:关闭读,不能使用 read/recv
- SHUT_WR:关闭写,不能使用 send/write
- SHUT_RDWR:关闭读写,不能使用 send/write/recv/read
NOTE:在客户端程序中,一般我们会选择使用 SHUT_WR 方式,立即停止写操作,但可以继续将响应数据读完。而在服务端程序中一般会选择 SHUT_RD 模式,立即停止对客户端请求的读取,但会继续完成响应。当然了,在某些对精度要求不要的场景中,SHUT_RDWR 是不错的选择。