类的加载过程_对象的创建过程_dubbo原理和通信协议_dubbo和spring对比_rpc和http调用的区别_http1.0和http1.1和http2.0_https的tls的四次握手_backlog参数在握手中的作用

 

 对象创建的过程（简单理解）

 

 详细的过程

java创建对象的过程主要分为一下五个步骤：
（1）类加载检查
Java虚拟机（jvm）在读取一条new指令时候，首先检查能否在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否被加载、解析和初始化。如果没有，则会先执行相应的类加载过程。

（2）内存分配
在通过（1）后，则开始为新生的对象分配内存。该对象所需的内存大小在类加载完成后便可确定，因此为每个对象分配的内存大小是确定的。而分配方式主要有两种，分别为：

1.指针碰撞

应用场合：堆内存规整（通俗的说就是用过的内存被整齐充分的利用，用过的内存放在一边，没有用过的放在另外一边，而中间利用一个分界值指针对这两边的内存进行分界，从而掌握内存分配情况）。

即在开辟内存空间时候，将分界值指针往没用过的内存方向移动向应大小位置即可）。

将堆内存这样划分的代表的GC收集器算法有：Serial，ParNew

2.空闲列表

应用场合;堆内存不规整（虚拟机维护一个可以记录内存块是否可以用的列表来了解内存分配情况）

即在开辟内存空间时候，找到一块足够大的内存块分配给该对象即可，同时更新记录列表。

将堆内存这样划分的代表的GC收集器算法有：CMS

（3）初始化默认值
第（2）步完成后，紧接着，虚拟机需要将分配到的内存空间都进行初始化（即给一些默认值），这将做是为了保证对象实例的字段在Java代码中可以在不赋初值的情况下使用。程序可以访问到这些字段对用数据类型的默认值。

（4）设置对象头
初始化（3）完成后，虚拟机对对象进行一些简单设置，如标记该对象是哪个类的实例，这个对象的hash码，该对象所处的年龄段等等（这些可以理解为对象实例的基本信息）。这些信息被写在对象头中。jvm根据当前的运行状态，会给出不同的设置方式。

（5）执行初始化方法
在（4）完成后，最后执行由开发人员编写的对象的初始化方法，把对象按照开发人员的设计进行初始化，一个对象便创建出来了。

dubbo原理

 

 

 主要包括五个节点：Provider、Consumer、Container、Register、Monitor

1. Provider：服务提供者
2. Consumer：服务订阅者
3. Container：服务运行的容器
4. Register：注册中心
5. Monitor：监控中心，统计服务调用次数和调动时间

dubbo工作过程：

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册自己提供的服务。
3. 服务消费者在启动时，向注册中心订阅自己所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

三、dubbo支持哪些的通信协议

http 协议：

• 基于 http 表单的远程调用协议，短连接，json 序列化
• 对传输数据包不限，不支持传文件
• 适用于同时给应用程序和浏览器 JS 使用的服务

dubbo 默认协议：

• 单一 TCP 长连接，Hessian 二进制序列化和 NIO 异步通讯
• 适合于小数据包大并发的服务调用和服务消费者数远大于服务提供者数的情况
• 不适合传送大数据包的服务

rmi 协议：

• 采用 JDK 标准的 java.rmi.* 实现，采用阻塞式短连接和 JDK 标准序列化方式
• 如果服务接口继承了 java.rmi.Remote 接口，可以和原生 RMI 互操作
• 对传输数据包不限，消费者和传输者个数相当

 

 rpc和http调用的区别

 

 

 

 

 

 

 

 

HTTP1.0 和 HTTP1.1 的区别?

• 长连接：HTTP1.0 默认使用短连接，每次请求都需要建立新的 TCP 连接，连接不能复用。HTTP1.1 支持长连接，复用 TCP 连接，允许客户端通过同一连接发送多个请求。不过，这个优化策略也存在问题，当一个队头的请求不能收到响应的资源时，它将会阻塞后面的请求。这就是“队头阻塞”问题。

• 断点续传：HTTP1.0 不支持断点续传。HTTP1.1 新增了 range 字段，用来指定数据字节位置，支持断点续传。

• 错误状态响应码：在 HTTP1.1 中新增了 24 个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突、410（Gone）表示服务器上的某个资源被永久性的地删除。

• Host 头处理：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名。到了 HTTP1.1 时代，虚拟主机技术发展迅速，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址，故 HTTP1.1 增加了 HOST 信息

HTTP1.1 和 HTTP2.0 的区别？

HTTP2.0 相比 HTTP1.1 支持的特性：

• 新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0 采用二进制格式传输数据，解析更高效。

• 多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行地传输而不被阻塞，避免 HTTP1.1 出现的“队头堵塞”问题。

• 头部压缩，HTTP1.1 的 header 带有大量信息，而且每次都要重复发送；HTTP2.0 把 header 从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且 HTTP2.0 在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求 a 发送了所有的头信息字段，请求 b 则只需要发送差异数据，这样可以减少冗余数据，降低开销。

• 服务端推送：HTTP2.0 允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

https的四次握手

四次握手是三次握手之后进行对http加入安全性引入的，在应用层和tcp层加入tls/ssl协议保证传输的安全性，这就需要四次握手。对称加密不安全，容易被窃取，tls采用非对称加密算法，服务端向ca机构申请证书，ca机构提供公钥和私钥，通过证书把公钥传给浏览器，浏览器使用公钥加密最终生成密钥给服务端，之后使用密钥进行通信，保证安全性，ca机构生成数字签名的算法可以保证原文内容被窃取更改可以被发现。

tls是对称加密和非对称加密一起使用，先非对称后对称，因为ca提供的私钥一直在服务端所以其他人无法解析公钥加密后的数据，保证密钥的安全性。

 

 

首先第一次握手客户端会向服务端发送client hello信息，告诉服务端需要的tls版本信息，支持的加密算法有哪些，这些算法组成加密套件，然后是一个随机数。

然后第二次握手服务端向客户端发送一个Server hello，然后告诉客户端服务端支持的确认支持的tls版本以及选择的加密套件，也会生成一个随机数告诉客户端，然后服务器出示一个证书，这样浏览器可以根据自己信任的证书列表来确认这个证书服务器是否可信，

然后把公钥给客户端，再发后一个结束信号，Server Hello Done

第三次握手会使用公钥加密生成预主密钥给服务端，服务端使用私钥解密，接下来使用预祝密钥和前两个随机数组成最终的密钥进行密钥通信，

第四次握手服务端发送一个信号对客户端进行确认，加密通信开始。

CA机构在其中的作用

ca机构是第三方机构用来保证数据的可靠性，ca机构给服务端提供公钥和私钥，然后把公钥安全的传输给客户端，方便后面的对称加密，那么如何保证公钥安全的给客户端呢，因为可以保证不能被篡改和更换

如何证明浏览器收到的公钥一定是该网站的公钥？

其实所有证明的源头都是一条或多条不证自明的“公理”（可以回想一下数学上公理），由它推导出一切。比如现实生活中，若想证明某身份证号一定是小明的，可以看他身份证，而身份证是由政府作证的，这里的“公理”就是“政府机构可信”，这也是社会正常运作的前提。

那能不能类似地有个机构充当互联网世界的“公理”呢？让它作为一切证明的源头，给网站颁发一个“身份证”？

它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

数字证书

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！

如何放防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名：

数字签名

这部分内容建议看下图并结合后面的文字理解，图中左侧是数字签名的制作过程，右侧是验证过程：

数字签名的生成与验证（https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/）

数字签名的制作过程：

1. CA机构拥有非对称加密的私钥和公钥。
2. CA机构对证书明文数据T进行hash。
3. 对hash后的值用私钥加密，得到数字签名S。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

1. 拿到证书，得到明文T，签名S。
2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
3. 用证书里指明的hash算法对明文T进行hash得到T’。
4. 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

为何么这样可以保证证书可信呢？我们来仔细想一下。

中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

既然不可能篡改，那整个证书被掉包呢？

中间人有可能把证书掉包吗？

假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？

其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

backlog

backlog这个参数值和三次握手的概念有着密切关联。backlog队列大小 = 未完成三次握手队列 +  已经完成三次握手队列。

未完成三次握手队列：服务器处于listen状态时，收到客户端syn报文（connect）时放入未完成队列中。

已完成三次握手队列：三次握手的第二个状态即服务器syn+ack响应client后，此时第三个状态ack报文到达前（客户端对服务器syn的ack）一直保留在未完成连接队列中。若三次握手完成，该条目将从未完成连接队列搬到已完成连接队列尾部。当server调用accept时，从已完成三次握手队列中的头部取出一个socket连接给进程

backlog参数设置既可在linux内核参数设置(修改文件/etc/sysctl相关参数)，也可在socket系统调用listen函数时设置(第二个参数)。这二者区别是前者为全局性的，影响所有socket，后者为局部性的，影响当前socket。

若backlog设置过小可能会出现以下情况：server的accpet速度跟不上，导致A、B队列满了，导致新的客户端无法连接。