长连接方案及相关概念、技术

1. 概念

在探索长连接方案过程中，肯定会遇到很多的技术名词，下面就是一些，需要了解它是什么、什么时候可以用到、怎么使用等等。

1.1. socket

先来个总结：一切进程间通信都是socket通信。socket作为门面，包装了TCP/IP的复杂性。让我们仅仅需要指定服务端的ip、端口、协议要素，就可以实现服务端和client端的通信。
下面的内容，主要摘抄自：https://blog.csdn.net/pashanhu6402/article/details/96428887
socket的java demo代码在8-代码\8.5springboot-socket

说起socket，应该要从TCP/IP协议族开始说起。
TCP/IP（Transmission Control Protocol/Internet Protocol）即传输控制协议/网间协议，是一个工业标准的协议集，它是为广域网（WANs）设计的。
UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是属于TCP/IP协议族中的一种。
这里有一张图，表明了这些协议的关系。

TCP/IP协议族包括运输层、网络层、链路层。现在你知道TCP/IP与UDP的关系了吧。
Socket在哪里呢？
在图1中，我们没有看到Socket的影子，那么它到底在哪里呢？还是用图来说话，一目了然。

Socket是什么呢？
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。在设计模式中，Socket其实就是一个门面模式，它把复杂的TCP/IP协议族隐藏在Socket接口后面，对用户来说，一组简单的接口就是全部，让Socket去组织数据，以符合指定的协议。

就目前而言，几乎所有的应用程序都是采用socket，而现在又是网络时代，网络中进程通信是无处不在，这就是我为什么说“一切皆socket”。

socket中TCP的三次握手建立连接详解

• 客户端向服务器发送一个SYN J
• 服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1
• 客户端再向服务器发一个确认ACK K+1
  

1.2. websocket

• 定义：WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就可以建立持久性的连接，并进行双向数据传输。
• 注意：WebSocket是H5新推出的协议，一般用于前端，但是在实际项目中可能需要用java代码来获取一些设备的实时运行数据，在后台处理后推送的前台界面，为了保证实时性，我们需要用到WebSocket协议，而刚好有一个叫java-websocket的开源项目，我们可以利用它来实现java版的websocket client。案例代码可以参考：https://www.cnblogs.com/hhhshct/p/9507446.html

学习了解websocket的一些博客

• WebSocket其实没那么难：https://zhuanlan.zhihu.com/p/74326818
• WebSocket 是什么原理？为什么可以实现持久连接？https://www.zhihu.com/question/20215561

---

OK，定义、概念over，开始搞事情~
首先，你需要问一下你自己：

• 你需要的是web和server和长连接？
• 还是java client和server的长连接？
• 你的架构方案里，server是集群吗？
• 要不要搞个springboot websocket来快速爽一把交差？
• 移动端app h5、小程序、公众号是否支持websocket协议？
• …

上菜~

• SpringBoot整合WebSocket实现前后端互推消息 https://www.cnblogs.com/JohanChan/p/12522001.html
  然后，如果你想用在公司项目里，想想，集群下，websocket如何保证多实例websocket session共享？↓

1.2.1. websocket 集群方案

不同于httpsession，websocket session无法序列化到redis。目前没有比较好的集群方案，所以考虑引入mq，使每一个实例都可以收到待发送的消息，再通过springboot websocket，发送给浏览器。https://blog.csdn.net/xiaoxian8023/article/details/48729479

1.3. webservice

1.3.1. 概念

• WebService是一种跨编程语言和跨操作系统平台的远程调用技术。（Asp.net开发的WebService用java代码调用完全没问题，和操作系统也没有关系。）
• WebService服务的请求和响应各自表现为一组数据，数据具有某种表示形式（XML）和类型标准（XSD），数据通过某传输协议（HTTP）通过网络进行传输。
• WSDL(Web Services Description Language)是一个基于XML的语言，用于描述Web Service及其函数、参数和返回值。它是WebService客户端和服务器端都能理解的标准格式。为用户提供详细的接口说明书。

在找资料的过程中，感觉，webservice相关的，都比较老一些，包括示例代码，很多是eclipse…

1.3.2. 首先，还是看各种文档资料，熟悉一下什么是webservice、为什么、怎么做

• 我的第一次WebService接口开发 https://blog.csdn.net/qq_38584967/article/details/90040429

1.3.3. 然后就是动手搞事(代)情(码)~

• 看这一篇就够了，有说明有代码，够入门 https://blog.csdn.net/hgx_suiyuesusu/article/details/88918192

• webservice请求过程中，xml格式的数据可以认为是payload，而soap可以认为是一个信封，把xml数据封装起来，webservice服务端打开信封，取出信件（数据），执行对应的方法，并将结果再放回信封（soap）返回给客户端。
• 看看概念、做做demo，整体感觉下来，有现成的工具可以生成client代码，调用起来类似RPC，也还不错。就是那个wsdl值得吐槽，虽说是xml格式可以给人看，那是人看的东西？！
• 有一说一，如果是跨公司系统间服务调用，还是比较OK的。如果是公司内部，springcloud的feign，做的也很不错，虽不是rpc，但实现的效果大体相同~

1.4. RESTful

REST – REpresentational State Transfer URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。
直面灵魂的提问：你真的懂restful吗？是代码？是接口？是规范？用在哪儿？为什么要用？

• REST（英文：Representational State Transfer，简称REST）。在目前主流的三种Web服务交互方案中，REST相比于SOAP（Simple Object Access protocol，简单对象访问协议）以及XML-RPC更加简单明了，无论是对URL的处理还是对Payload的编码，REST都倾向于用更加简单轻量的方法设计和实现。值得注意的是REST并没有一个明确的标准，而更像是一种设计的风格。
• REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
• REST本身并没有创造新的技术、组件或服务，而隐藏在RESTful背后的理念就是使用Web的现有特征和能力， 更好地使用现有Web标准中的一些准则和约束。虽然REST本身受Web技术的影响很深， 但是理论上REST架构风格并不是绑定在HTTP上，只不过目前HTTP是唯一与REST相关的实例。 所以我们这里描述的REST也是通过HTTP实现的REST。

1.4.1. 翻翻博客，看看大神们怎么解释

• 理解RESTful架构 http://www.ruanyifeng.com/blog/2011/09/restful.html
• RESTful API 设计指南 http://www.ruanyifeng.com/blog/2014/05/restful_api.html
• 菜鸟教程 - RESTful 架构详解 https://www.runoob.com/w3cnote/restful-architecture.html
• 知乎：怎样用通俗的语言解释REST，以及RESTful？ https://www.zhihu.com/question/28557115
  一定要看哈，不然后面可能会晕车~

1.4.2. RESTful特点包括：

1、每一个URI代表1种资源；
2、客户端使用GET、POST、PUT、DELETE4个表示操作方式的动词对服务端资源进行操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源；
3、通过操作资源的表现形式来操作资源；
4、资源的表现形式是XML或者HTML；
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。

1.4.3. 再延伸看看RPC概念

使用 RPC 样式架构构建的基于 SOAP 的 Web 服务成为实现 SOA 最常用的方法。RPC 样式的 Web 服务客户端将一个装满数据的信封（包括方法和参数信息）通过 HTTP 发送到服务器。服务器打开信封并使用传入参数执行指定的方法。方法的结果打包到一个信封并作为响应发回客户端。客户端收到响应并打开信封。每个对象都有自己独特的方法以及仅公开一个 URI 的 RPC 样式 Web 服务，URI 表示单个端点。它忽略 HTTP 的大部分特性且仅支持 POST 方法。
在 RPC 样式的架构中，关注点在于方法，而在 REST 样式的架构中，关注点在于资源 —— 将使用标准方法检索并操作信息片段（使用表示的形式）。资源表示形式在表示形式中使用超链接互联。

---

通过上面的一些概念表达，可能还只是一个模糊的概念，能区分RPC和REST：RPC侧重方法，REST侧重资源，通过GET\POST\DELETE\PUT来操作资源。那么，既然RESTful是一种架构约束条件和原则，那有什么比较好的现成方案可供借鉴呢？

• Springboot官网教程：Building a RESTful Web Service https://spring.io/guides/gs/rest-service/
  这个貌似有点不对题，并不是标准的RESTful接口-_-||
• （拆台）博客：SpringBoot RESTful API 架构风格实践 https://www.cnblogs.com/fishpro/p/spring-boot-study-restful.html

1.4.4. 拆台RESTful

为什么不推荐使用 RESTful API：
RESTful API 固然很好但大多数互联网公司都没有按照其规则来设计。因为 REST 本来就是一种风格，并没有什么固定的规则来约束，基于过于理想的 RESTful API 只会付出更多的人力成本和时间成本。

• 操作方式繁琐，没有效率，且意义不大
  使用 HTTP 的 GET\POST\PUT\DELETE 来区分操作资源，HTTP Method 本身就对外部不友好，是隐藏的方法，把动词加入到 url 中，反而清晰可见，简单易懂，为什么一定要用 url 来表示资源而不能加动词呢。
  GET\POST\PUT\DELETE 的兼容性有待认证，首先是兼容老的系统，大部分 HTTP 应用是基于 GET/POST 来实现的。
• 过分强调单一资源
  这可能是人的理解问题，就看我们对资源的定义，太多的场景，如果使用 Restful API 规则行事，势必要把一个 API 拆分多个 API，框架多个 API 之间的状态又成了问题。ps：抄来的，写作的人真的很不用心，完全不通顺。我理解，是一个资源就1个uri，具体的动作需要依靠GET\POST\DELETE等动作来判断，API不够友好。
• 返回值问题
  使用 HTTP Status 状态码是没有问题的，但使用不常见的状态码表示操作层面的含义，对开发不是很友好。
  对返回集中定义 status、message 例如下面的 json 返回是很常见的返回，简单易懂。并没有什么不妥，但在 RESTful Api 拥护者眼里就是错误的格式，错误的返回。

{
    "status":1,
    "message":"",
    "data":[]
}

• 更高的成本
  统一为 RESTful API 风格，强化要求做的完美，比如带来更多的时间成本、人力成本。沟通成本。

怪不得，平时工作中，遇到RESTful的接口很少，真的不好用，研发人员会比较累，遵守规范也不会有什么明显的好处~话说两面，如果遵循了RESTful风格，接口看起来会比较的规范，易于理解（即使在不同的公司，用这种规范来书写代码，可以达到接口自解释）

1.5. mina 长连接

长连接概念不用再多说，全双工通信，server和client可以互发消息。mina可以说更适用于java-java而非web-java的场景，如果是web-java，可以考虑websocket。

• mina相关的demo，可以参考：https://blog.csdn.net/walle167/article/details/79014387?utm_source=blogxgwz7

1.6. netty

netty入门有些吃力，多了比较多的概念，所以，先从一些博客入手，对其有个大概的认知。
一些比较重要的观点：

• netty系列博客：https://blog.csdn.net/qq_18603599/category_7748400.html

netty，还是先啃一遍书再说吧，没有底~准备下一篇netty相关文章