长连接

扫码登录操作过程 浏览器输入： https://wx.qq.com/?lang=zh_CN 手机登录微信，利用“扫一扫”功能扫描网页上的二维码 手机扫描成功后，提示“登录网页版微信”；网页上显示“成功扫描 请在手机点击确认以登录” 手机端点击“登录网页版微信”，网页跳转到用户的微信操作界面 整个扫码登录的操作过程还是挺简单的，而且交互地实时性比较好，如果网络不是非常阻塞，整个过程还是非常快的。 扫码登录原理 扫码登录大概的思路是：微信手机客户端从网页二维码里面得到一些信息，然后发送给网页微信的服务器，网页服务器验证信息并响应。下面，我们借助火狐浏览器提供的Firebug工具看看，到底是怎么一回事儿吧！ 1. 每次打开微信网页版的时候，都会生成一个含有唯一 uid 的二维码，而且每次刷新后都会改变。这样可以保证一个 uid 只可以绑定一个账号和密码，确定登录用户的唯一性。可以通过手机上的UC浏览器提供的扫码功能查看二维码里面的信息，但并不会自动打开该地址。我刷新三次，扫描结果如下，其中最后面那串数字就是 uid ： 1） https://login.weixin.qq.com/l/48e24d66bdbc4f 2） https://login.weixin.qq.com/l/0787fb4fa7ad4c 3） https://login.weixin.qq.com/l

一、TCP协议： 位于传输层， 提供可靠的字节流服务。所谓的字节流服务（Byte Stream Service） 是指， 为了方便传输， 将大块数据分割成以报文段（segment） 为单位的数据包进行管理。 而可靠的传输服务是指， 能够把数据准确可靠地传给对方。 即TCP 协议为了更容易传送大数据才把数据分割， 而且 TCP 协议能够确认数据最终是否送达到对方。所以，TCP连接相当于两根管道（一个用于服务器到客户端，一个用于客户端到服务器），管道里面数据传输是通过字节码传输，传输是有序的，每个字节都是一个一个来传输。 (1)、三次握手：握手过程中使用了 TCP 的标志（flag） —— SYN（synchronize） 和ACK（acknowledgement） 。 第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。 第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。 第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，完成三次握手。 若在握手过程中某个阶段莫名中断， TCP 协议会再次以相同的顺序发送相同的数据包。 （2）、四次挥手

一、问题来源分析 出现的错误 ： Cause: java.sql.SQLException: connection holder is null; uncategorized SQLException for SQL []; SQL state [null]; error code [0]; connection holder is null; nested exception is java.sql.SQLException: connection holder is null 1.出现的原因，数据库链接丢失，出现的原因是这样的，我需要执行定时任务去定时更新数据库的数据，每次分页循环跟新，开始数据不多，能成功，后来数据量大了，到了下一次任务开始也不能结束，但是数据库已经报错了，报错理解起来也很简单，数据拦截丢失， 一开始问了度娘，修改了一下的参数 ： <!-- 1800秒，也就是30分钟 修改为了36000，即10小时--> <property name="removeAbandonedTimeout" value="36000" /> 以为问题解决了，到但是过几天还是报错了，仔细想了下，业务代码得改啊，不然的话，连接肯定会超时的，于是修改了业务代码，采用了 多线程 ，每次获取数据库的少于设置的 removeAbandonedTimeout 的时间即可以成功，功能算是可以了； 二

什么是redis？ Redis是一种可基于内存亦可持久化的日志型、Key-Value数据库，支持的存储类型非常丰富，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。（具体介绍请参照百度百科） 为什么快？  纯ANSI C编写。  所有数据均存放在内存中，当然不包括持久化。  不依赖第三方类库，没有像memcached那样使用libevent。  Redis多样的数据结构，每种结构只做自己爱做的事，当然比数据库只有Table，MongogoDB只有JSON一种结构快了。 Redis支持的功能：  所有数据都在内存中。  五种数据结构：String / Hash / List / Set / Ordered Set。  数据过期时间支持。  不完全的事务支持。  服务端脚本：使用Lua Script编写，作用类似存储过程。  PubSub：捞过界的消息一对多发布订阅功能，起码Redis-Sentinel在使用它。  持久化：支持定期导出内存的RDB与 记录写操作日志的Append Only File两种模式。  Replication：Master-Slave模式，Master可连接多个只读Slave。  Fail-Over：Redis

整理和总结了一下大家常遇到的问题： 1. 客户端socket发送消息后，为什么服务端socket没有收到？ 2. 使用while 循环实现连续输入，是不是就是多线程模式？ 3. 对多线程处理机制不是很明白，希望详细讲解？ 4. 希望详细讲解ServerSocketChannel和SocketChannel与ServerSoket和Socket的区别？ 5. 希望有详细的例子，可以直接拷贝下来运行？ 针对童鞋们提出的问题，我会在本文章中详细一一简答，并且给出详细的例子，下面言归正传。 一：socket通信基本原理。 首先socket 通信是基于TCP/IP 网络层上的一种传送方式，我们通常把TCP和UDP称为传输层。 如上图，在七个层级关系中，我们将的socket属于传输层，其中UDP是一种面向无连接的传输层协议。UDP不关心对端是否真正收到了传送过去的数据。如果需要检查对端是否收到分组数据包，或者对端是否连接到网络，则需要在应用程序中实现。UDP常用在分组数据较少或多播、广播通信以及视频通信等多媒体领域。在这里我们不进行详细讨论，这里主要讲解的是基于TCP/IP协议下的socket通信。 socket是基于应用服务与TCP/IP通信之间的一个抽象，他将TCP/IP协议里面复杂的通信逻辑进行分装，对用户来说，只要通过一组简单的API就可以实现网络的连接

摘自： https://www.cnblogs.com/mayou18/p/9829876.html 聊聊微服务的服务注册与发现 来源：阿里中间件团队分享 更多文章请关注 MAYOU18 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 引言 聊起微服务的服务注册与发现，很多人立马就会脱口而出 zk、etcd、consul、eureka 这些组件，进而聊到 CAP 如何取舍，性能如何，高可用和容灾是怎么实现的。 在这之前，站在组件使用者的角度，我想先问这么几个问题： 注册的 IP 和端口怎么确定 ？ 实现服务治理还需要注册哪些信息 ？ 如何进行优雅的服务注册与服务下线 ？ 注册服务的健康检查是如何做的 ？ 当服务有节点退出或新的节点加入时，订阅者能不能及时收到通知 ? 我能方便地查看某个应用发布和订阅了哪些服务，以及所订阅的服务有哪些节点吗 ？ 看完这些问题后，您也许会发现，对于服务注册与发现，首先应该关注的是服务注册发现本身的功能，然后才是性能和高可用。 一个好的服务注册发现中间件，应该是能完整地满足服务开发和治理的基础功能，然后才是性能和高可用。如果没有想清楚前面的功能，再高的可用性和性能都是浮云。最后，安全也同样重要。 服务端的性能如何 ？

MIME数据类型 1. text：即文本格式的可读数据，我们最熟悉的应该就是text/html了，表示超文本文档，此外 还有纯文本text/plain、样式表text/css等。 2. image：即图像文件，有image/gif、image/jpeg、image/png等。 3. audio/video：音频和视频数据，例如audio/mpeg、video/mp4等。 4. application：数据格式不固定，可能是文本也可能是二进制，必须由上层应用程序来解释。 常见的有application/json，application/javascript、application/pdf等，另外，如果实在是不 知道数据是什么类型，像刚才说的“黑盒”，就会是application/octet-stream，即不透明的二 进制数据。 编码格式 Encoding type 1. gzip：GNU zip压缩格式，也是互联网上最流行的压缩格式； 2. deflate：zlib（deflate）压缩格式，流行程度仅次于gzip； 3. br：一种专门为HTTP优化的新压缩算法（Brotli）。 表示浏览器最希望使用的是HTML文件，权重是1，其次是XML文件，权重是0.9，最后是任意数据类型，权重是0.8。服务器收到请求头后，就会计算权重，再根据自己的实际情况优先输出HTML或者XML。

一.TCP的通信流程 在TCP双方通信之前，需要通过”三次握手”建立一条连接。连接建立以后双方就可以进行数据交互了，当数据交互完成以后还需要通过”四次挥手”断开连接。这是TCP通信的一般流程 每个连接的建立都是需要资源消耗和时间消耗的，正是考虑到资源消耗和时间问题，才有了TCP短连接和长连接机制。 二.TCP短连接 首先看下TCP短连接的情况: client 向 server 发起连接请求 server 接到请求予以相应和确认，双方建立连接 client 向 server 发送消息 server 回应 client 一次读写完成，此时双方任何一个都可以发起 close 操作，一般都是 client 先发起 close 操作流程： 建立连接 -> 数据传输 -> 关闭连接………………..建立连接 -> 数据传输 -> 关闭连接 应用场景： WEB网站面向客户，通常是成千上万客户端去访问，这时候用短链接会更省资源一些。 三.TCP长连接 下面再看看TCP长连接的操作流程: client 向 server 发起连接 一次读写完成，连接不关闭 后续读写操作… 操作流程： 建立连接 -> 数据传输…（保持连接）…数据传输 -> 关闭连接 应用场景： Mysql数据库客户端的操作就是长链接，链接后可以一直进行操作传输数据。 来源： https://www.cnblogs.com

1 什么是长连接和短连接 三次握手和四次挥手 TCP区别于UDP最重要的特点是TCP必须建立在可靠的连接之上，连接的建立和释放就是握手和挥手的过程。 三次握手为连接的建立过程，握手失败则连接建立失败。 四次挥手为连接的 完整 释放过程，也会发生某个消息丢失或者超时的情况，有一方主动发送 FIN 消息即表示连接即将释放。 注： SYN、ACK、FIN消息具有哪些含义，以及连接的状态，请参考《TCP/IP详解 卷1》第18章。 长连接 长连接，也叫持久连接，在TCP层握手成功后， 不立即 断开连接，并在此连接的基础上进行多次消息（包括心跳）交互，直至连接的任意一方（客户端OR服务端）主动断开连接，此过程称为一次完整的长连接。HTTP 1.1相对于1.0最重要的新特性就是引入了长连接。 短连接 短连接，顾名思义，与长连接的区别就是，客户端收到服务端的响应后， 立刻发送FIN消息 ，主动释放连接。也有服务端主动断连的情况，凡是在一次消息交互（发请求-收响应）之后立刻断开连接的情况都称为短连接。 注：短连接是建立在TCP协议上的，有完整的握手挥手流程，区别于UDP协议。 2 如何快速区分当前连接使用的是长连接还是短连接 1、 凡是在一次完整的消息交互（发请求-收响应）之后，立刻断开连接（有一方 发送FIN消息 ）的情况都称为短连接 ； 2、长连接的一个明显特征是会有心跳消息

dubbo 的工作流程 0. 服务容器负责启动，加载，运行服务提供者。 1. 服务提供者在启动时，向注册中心注册自己提供的服务。 2. 服务消费者在启动时，向注册中心订阅自己所需的服务。 3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 6. 注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外 7. 注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者 8. 注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表 Dubbo ： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 来源： https://www.cnblogs.com/lingboweifu/p/11912977.html