1. http与https的区别，以及https的认证过程及加密算法 ？
区别：
- https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
- http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
1.客户端发起HTTPS请求
用户在浏览器里输入一个https网址，然后连接到server的443端口。
2.服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3.传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4.客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5.传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6.服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7.传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原
8.客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
HTTPS加密算法：
一、加密SSL
HTTP 协议本身没有加密机制，但是可以使用 SSL（Secure Socket Layer）/TLS（Transport Layer Security）协议解决 HTTP 的安全性问题。SSL 不仅提供加密处理，还提供了一种证书机制，用于确定客户端或服务器。证书由值得信任的第三方机构颁发，用来证明客户端和服务端是真实存在的。
二、加密方式
1）共享（对称）密钥加密
所谓共享密钥加密（Common key crypto system）就是加密和解密都使用相同的密钥，因此也被称为对
称密钥加密。
使用共享密钥加密时必须将密钥也发送给对方 ，这样就存在一个问题，发送的密钥可能会被攻击者窃听，如果不发送，对方又不能解密。
2）公开（非对称）秘钥加密
公开秘钥加密使用一对非对称的秘钥，一把叫做私有密钥（private-key），另一把叫做公开密（Public key）。公开密钥任何人都可以获得，但是私有密钥是私有的。通过这种方式，可以很好的解决共享密钥加密的安全性问题。
使用公开密钥加密时，发送密文的一方使用公钥加密，对方收到加密的信息后，再使用自己的私钥进行解密。这样不需要发送用来解密的私钥，就不存在密钥被窃取的风险了。
三、HTTPS 加密方式 HTTPS
采用共享密钥加密和公开密钥加密两者并用的混合加密机制。 使用公开密钥加密方式安全地交换
在稍后使用的共享密钥中的密钥；确保密钥是安全的前提下，使用共享密钥加密方式进行通信。
如何保证公开密钥加密方式交换的密钥是安全的呢？ 将公钥放在数字证书中 ，数字证书由双方都可依赖的第三方机构颁发，因此只要证书是可信的，公钥就是可信的。
2.linux系统；什么是孤儿进程、什么是僵尸进程有什么区别和联系，以及如何100%创建孤儿进程 ？
僵尸进程
子进程退出，父进程要调用wait或waitpid函数等待回收子进程的资源，否则子进程就一直以“僵尸”
状态存在。这种子进程就是僵尸进程。
如果其父进程还存在，而一直不调用wait，则该僵尸进程将无法回收，等到其父进程退出后该进程
将被init回收。
孤儿进程
一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被
init进程（进程号为1）所收养，并由init进程对他们完成状态收集工作。
区别：
- 僵尸进程对系统的影响：如果进程不调用wait()或waitpid()的话，那么保留的信息就不会释放，其进程号就会一直被占用，但是系统所能使用的进程号是有限的，如果大量的产生僵死进程，将因为没有可用的进程号而导致系统不能产生新的进程. 此即为僵尸进程的危害，应当避免。
- 孤儿进程并不会有什么危害，init进程会接管并处理掉它
3.tcp的特点，tcp的通信过程以及tcp的粘包处理 ？
- 第一次握手： A给B打电话说，你可以听到我说话吗？
- 第二次握手： B收到了A的信息，然后对A说： 我可以听得到你说话啊，你能听得到我说话吗？
- 第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！
- 发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
- 包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
- 包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。
- 使用更加复杂的应用层协议。
4.time_wait状态是什么，tcp中的close_wait？
- TCP协议规定，主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL(最大报文生存周期，Linux默认的TIME_WAIT时长一般是60秒 = 2MSL)的时间后才能回到CLOSED状态。
- TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的)。
- 同时也是在理论上保证最后一个报文可靠到达(假设最后⼀个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK)。
- CLOSE_WAIT是TCP关闭连接过程中的一个正常状态。
- CLOSE_WAIT只会发生在被动关闭链接的那一端。
如果服务端一直没有向客户端发送 FIN 包 ( 调用 close() API) ，那么这个 CLOSE_WAIT 会一直存在下去
5.http和rpc有什么区别 ？
1.传输协议
- RPC，可以基于TCP协议，也可以基于HTTP协议
- HTTP，基于HTTP协议
2.传输效率
- RPC，使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减少报文的体积，提高传输效率
- HTTP，如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为一个RPC来使用的，这时标准RPC框架更多的是服务治理
- RPC，可以基于thrift实现高效的二进制传输
- HTTP，大部分是通过json来实现的，字节大小和序列化耗时都比thrift要更消耗性能
4.负载均衡
- RPC，基本都自带了负载均衡策略
- HTTP，需要配置Nginx，HAProxy来实现
- RPC，能做到自动通知，不影响上游
- HTTP，需要事先通知，修改Nginx/HAProxy配置
6.rpc 的通信原理？
- 解决分布式系统中，服务之间的调用问题。
- 远程调用时，要能够像本地调用一样方便，让调用者感知不到远程调用的逻辑。
- RPC Server：暴露服务的服务提供者。
- RPC Client：调用远程服务的服务消费者。
- Registry： 服务注册与发现的注册中心。
