TCP/IP和Socket开发经验分享 _TCP

当前与网络相关的业务主要是基于tcp/ip或http，熟悉j2ee的同学一定会对http场景下的开发比较了解。但是，精通tcp/ip以及如何构建一个直接基于tcp/ip层通讯的知识却不太多见。恰巧，最近一年来我参与了一些基于tcp/ip应用的开发工作。总算有所收获，今天在博客中做些分享，希望对有兴趣的同学有所帮助。
比较常见的4层网络模型（图）如下：

文章插图

基于应用层的开发难度是相对比较低的，因为绝大部分与连接和数据传输、校验相关的事情已经交给（系统）来完成，使得开发人员只需要专注于业务即可。这种分层的技术结构是非常高级和有效的。基于应用层的开发虽然方便，但是当我们需要在功能上实现某些特殊需求的时候，就难免有些掣肘。例如，我们需要从一些传感器上采集数据或希望他们能够主动将数据上送，并在经过了中心系统处理后推送到其它响应装置。这样的需求使用http来开发，反而增大了难度。
操作系统实际已经为我们提供了一种基于传输层的通讯方式：套接字（socket）。使用套接字可以让我们自由定义通讯协议并选择合适的连接方式。
【TCP/IP和Socket开发经验分享】利用socket实现网络通信分为服务端和客户端，服务端绑定端口并主动监听连接，客户端需要向服务端发起连接。建立一次tcp连接需要进过“三次”握手：

文章插图

第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
三次握手被抽象成socket连接，这个过程服务端和客户端会分别生成一个socket并通过在这个套接字上的连接收发数据。那么问题产生了，假如我们知道服务端对8081端口进行监听，客户端会随机打开一个高位端口进行连接。连接建立后，服务端是在哪个端口上监听数据的呢？答案是8081端口，服务端会根据端口上数据的源地址和端口判断从而将数据分发到正确的应用上去。
理解这一点其实很重要，如果此时通信的双方没有任何数据交换，socket也无法判断连接是否被断开。任意一方必须首先通知socket断开连接，整个通信过程才算结束。如果中间网络中断，连接会一直处于等待状态。
利用socket编程的另一个难点是，由于通信的双方完全对等任何一方都可以主动发送数据，如何实现在http应用中常见的请求/应答会比较麻烦。为此我专门查阅了http1.0和http1.1的相关资料，基本的解决方案总结如下：

客户端等待：客户端发送请求后，都需要进行堵塞并直到接收到应答或超时为止。这个是http1.0的协议规范，整个数据的交互方式是串行的。
服务端等待：串行的运行方式实际上浪费了大量的系统运算时间，使得网络通讯很容易成为整个系统的瓶颈。于是http1.1协议做了更改，客户端只要准备好请求就可以直接发送，服务端可能会一次性接收到多条请求，但是只能按照请求的顺序依次应答。

服务器的运算能力通常都比客户端强，第二种解决方案能更加有效的利用网络。但是，如果有一条请求需要请求占用服务端大量的运算时间，后续应答都会被堵塞，因此在某些情况下也会引发比较严重的问题。
为了解决这个问题，我借鉴了spring kafka在实现消息交互的时候提供的一种解决思路：为每一条请求指定一个ID，经过服务端处理后的应答都需要带上这个ID 。这样在回复给客户端的时候，客户端就可以根据这条ID值来调用不同的回调处理业务。