Wireshark抓包分析机制
--------------------------------
如上图所示，TCP保活报文总是成对出现，包括TCP保活探测报文和TCP保活探测确认报文。
TCP保活探测报文是将之前TCP报文的确认序列号减1，并设置1个字节，内容为“00”的应用层数据，如下图所示：
TCP保活探测报文
TCP保活探测确认报文就是对保活探测报文的确认，其报文格式如下：
因为Websocket通过Tcp Socket方式工作，现在考虑一个问题，在一次长连接中，服务器怎么知道消息的顺序呢？这就涉及到tcp的序列号（Sequence Number）和确认号（Acknowledgment Number）。我的理解是序列号是发送的数据长度；确认号是接收的数据长度。这样讲比较抽象，我们从TCP三次握手开始（结合下图）详细分析一下。
包1：
TCP会话的每一端的序列号都从0开始，同样的，确认号也从0开始，因为此时通话还未开始，没有通话的另一端需要确认
包2：
服务端响应客户端的请求，响应中附带序列号0（由于这是服务端在该次TCP会话中发送的第一个包，所以序列号为0）和相对确认号1（表明服务端收到了客户端发送的包1中的SYN）。需要注意的是，尽管客户端没有发送任何有效数据，确认号还是被加1，这是因为接收的包中包含SYN或FIN标志位。
包3：
和包2中一样，客户端使用确认号1响应服务端的序列号0，同时响应中也包含了客户端自己的序列号（由于服务端发送的包中确认收到了客户端发送的SYN，故客户端的序列号由0变为1）此时，通信的两端的序列号都为1。
包4：客户端——>服务器
这是流中第一个携带有效数据的包（确切的说，是客户端发送的HTTP请求），序列号依然为1，因为到上个包为止，还没有发送任何数据，确认号也保持1不变，因为客户端没有从服务端接收到任何数据。需要注意的是，包中有效数据的长度为505字节
包5：客户端<-----服务器
当上层处理HTTP请求时，服务端发送该包来确认客户端在包4中发来的数据，需要注意的是，确认号的值增加了505（505是包4中有效数据长度），变为506，简单来说，服务端以此来告知客户端端，目前为止，我总共收到了506字节的数据，服务端的序列号保持为1不变。
包6：客户端<-----服务器
这个包标志着服务端返回HTTP响应的开始，序列号依然为1，因为服务端在该包之前返回的包中都不带有有效数据，该包带有129字节的有效数据。
包7：
由于上个数据包的发送，TCP客户端的确认序列号增长至130，从服务端接收了129字节的数据，客户端的确认号由1增长至130
理解了序列号和确认序列号是怎么工作的之后，我们也就知道“TCP保活探测报文是将之前TCP报文的确认序列号减1，并设置1个字节数据”为什么要这么搞了。
序列号减一再加一：是为了保证一次连接中keep alive不影响序列号和确认序列号。Keep alive 中的1byte 00的数据并不是真正要传递的数据，而是tcp keep alive约定俗称的规则。
总结：
WebSocket 是一个独立的基于 TCP 的协议，它与 HTTP 之间的唯一关系就是它的握手请求可以作为一个升级请求（Upgrade request）经由 HTTP 服务器解释。再严谨一点:WebSocket是一个网络通讯协议, 只要理解上面的数据帧格式和握手流程, 都可以完成基于websokect的即时通讯。
-----------------------------------
特别鸣谢：
原文出处：https://blog.csdn.net/u014252478/article/details/84380643
原文：https://www.cnblogs.com/zhangmingda/p/12680454.html