1700509032
12.2.5 连接方式
1700509033
1700509034
在数据采集这个环节,还有一个问题需要讨论,那就是使用短连接还是长连接。这两种方式在互联网的应用中都广泛存在。
1700509035
1700509036
1.短连接
1700509037
1700509038
先说短连接(如图12-6所示)。
1700509039
1700509040
1700509041
1700509042
1700509043
图12-6 三次握手与四次挥手
1700509044
1700509045
在TCP协议栈中,连接的建立有标准的步骤,就是TCP协议栈规定的“三次握手”。这里有两个角色:一个是Server,它是被动方,所做的事情就是启动一个TCP端口的监听;另一个是Client,用于主动向服务方Server发起连接请求。
1700509046
1700509047
(1)当Server接收到Client发来的连接请求(SYN包)后,会回发一个SYN包,表示Server方已经准备好建立连接。
1700509048
1700509049
(2)在Client接收到Server发来的SYN包后,回送给Server端一个ACK包。这样,三次握手就建立了一个五元组连接,在Server端和Client端都会看到一个新五元组的建立。这个所谓的五元组是指“本地IP”、“本地Port”、“远端IP”、“远端Port”、协议类型”的组合,用来描述和管理一个独一无二的连接。有些文章中会使用“源地址”、“远端口”、“目的地址”、“目的端口”这样的说法,意思相同。
1700509050
1700509051
(3)当连接建立以后,Client通常会直接把要传递的数据通过这个五元组描述的连接传输给Server,传输完成后关闭连接。
1700509052
1700509053
关闭的过程叫作“四次挥手”,过程如下。
1700509054
1700509055
(1)Client对服务器发送FIN包,表示Client不再有任何数据要传递给Server。
1700509056
1700509057
(2)Server对Client回复ACK包,表示Server已经收到了Client发来的FIN包,但此时Server还可以通过这个连接向Client发送数据。
1700509058
1700509059
(3)Server对Client回复FIN包,表示Server没有数据要传递给Client了。这个时候,作为线上服务器,Server通常可以在没有收到Client最后发来的FIN包的情况下直接关闭连接,回收连接所占用的内存资源。
1700509060
1700509061
(4)Client对Server回答ACK包,表示Client收到了Server最后发来的FIN包,正式关闭连接。
1700509062
1700509063
之所以称为短连接,是因为这样的过程耗时极短。通常在手机、PC终端发起一次HTTP请求,报送数据的量以几百字节(B)到几十千字节(KB)居多,所以,从建立连接,到发送数据,再到连接断开,大概要经历几十毫秒到几秒不等,主要开销是在网络上传输的延迟。这种短连接的报送方式最为普遍,网页上常用的GET方式和POST方式的请求就属于短连接。这种连接适用于高并发的短小访问,例如单条日志的报送。
1700509064
1700509065
2.长连接
1700509066
1700509067
顾名思义,长连接的连接时间较长。它和短连接的区别在于,在三次握手之后,通常要进行不断往复的数据交互,即在连接建立后,Server和Client之间会一直保持着这个连接,并通过这个连接相互发送数据。
1700509068
1700509069
从功能上来说,长连接的好处是连接断开之前Server能在任意时刻向Client发送数据信息,这个功能是短连接不具备的,好处显而易见。而且,再次从Client向Server发送消息也不用进行三次握手。我们平时用的QQ、微信等各种IM工具都要至少拥有一条基于长连接的连接来保持信息往返的畅通。
1700509070
1700509071
当然,长连接也有它的缺点,就是对Server和Client的内存都有一定的占用——因为要维护这条连接是需要内存保存信息的。而对于可以同时容纳数十万长连接的Server来说,内存占用当然就更为明显。从工程经验角度来看,大部分服务器上的轻传输业务的长连接通常只占用1KB到4KB不等的内存,具体占用的大小与内核设置有关,也同时与长连接上传输的内容多寡有关。具体占用的情况可以在实测时用free命令(Linux命令)查阅。
1700509072
1700509074
12.2.6 消息格式
1700509075
1700509076
对于一种已经定制好的日志来说,把日志信息原原本本报送给服务器就可以了,通常不需要进行太多其他处理。但是,如果这种数据收集具有比较大的自主性,甚至在收集数据的生命周期中还需要进行不定时的修改,这个时候就要下点功夫设计整个数据收集的逻辑了。按照我的经验,一般需要注意两点。
1700509077
1700509078
注意点1:报送格式尽量采用Key-VaIue键值对的形式
1700509079
1700509080
这种形式的好处是格式清晰,可扩展性高,Key和Value一一对应,在报送到服务器的时候方便进行切割和对应归档。而且,如果需要进行删减或者增补,只要直接删减或者增加键值对就可以了。
[
上一页 ]
[ :1.700509031e+09 ]
[
下一页 ]