面试题--3.18

1. http与https的区别，以及https的认证过程及加密算法？

区别：

https协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl/tls加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL/TLS+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS 其实是有两部分组成： HTTP + SSL / TLS ，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS 进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的。

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的粘包处理？

协议是一种面向连接，可靠，基于字节流的传输层通信协议； TCP 是全双工模式（同一时刻可以同时发送和接收）

TCP 特点：

1. 可靠性：可靠；

2. 连接性：面向连接

3. 报文：面向字节流

4. 效率：传输效率低

5. 双工性：全双工

6. 流量控制：滑动窗口

7. 拥塞控制：慢开始、拥塞避免、快重传、快恢复

8. 传输速度：慢

9. 应用场景：对效率要求低，对准确性要求高或者要求有连接的场景

以打电话理解 TCP

TCP 的通信的基本过程： TCP 的通信过程与打电话的过程大致相同，一方负责接听特定号码的电话，而另外一方则需要拨通这个电话号码，与对方建立连接。双方都可以通过听筒（socket 输入流）接受对方的信息，通过话筒（ socket输出流）向对方发送信息，并且在整个过程中信息的接收和发送是同时进行的（双工通信）。整个过程使用的是C/S 模型。

TCP 三次握手建立连接：

第一次握手： A给B打电话说，你可以听到我说话吗？
第二次握手： B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？
第三次握手： A收到了B的信息，然后说可以的，我要给你发信息啦！

在三次握手之后， A 和 B 都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。

TCP 的通信过程的三次握手：

三握是发生在连接的建立阶段：

1. 客户端先向服务端发送 SYN 包 (Socket 状态从 closed 变成 SYN-SEND) 。

2. 服务端收到 SYN 包后（ Socket 状态从 LISTEN 变成 SYN-RECV ），向客户端发送针对此 SYN 包的

SYN/ACK 包，以确认收到了这个 SYN 包。

3. 客户端收到此 SYN/ACK 包后（ Socket 状态由 SYN-RECV 变成 Established ），再向服务器发送 SYN/ACK包

4. 服务器收到 ACK 包之后就可以通信了。

粘包的问题的解决思路

粘包问题的最本质原因在与接收对等方无法分辨消息与消息之间的边界在哪。我们通过使用某种方

案给出边界，例如：

发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。
使用更加复杂的应用层协议。

4.time_wait状态是什么，tcp中的close_wait？

说到 CLOSE_WAIT 和 TIME_WAIT 需要看看最原始的四次挥手过程

TCP 的通信过程的四次挥手

（ 1 ）客户端向服务器发送 FIN 数据包，表示要断开连接， Socket 状态从 Established 变成 FIN_WAIT_1 。

（ 2 ） 服务器收到 FIN 数据包后，向客户端发送 ACK 包，表示准备断开，从 Established 变成 closed_wait 。

（ 3 ）客户端收到 ACK 包，从 FIN-wait-1 变成 FIN-WAit_2 ，等待服务器发送确认断开的包。

（ 4 ）服务器发送 FIN 包，确认断开连接，变成 LAST-ACK 。

（ 5 ） 客户端收到 FIN 包后，发送 ACK 包，变成 TIME-Wait ，等待 2 个报文生成时间后（ 2MSL ），变成CLOSED状态。

（ 6 ）服务器收到 ACK 包后，变成 CLOSED 。

TIME_WAIT 表示主动关闭，是主动关闭连接时形成的， CLOSE_WAIT 表示被动关闭，是被动关闭连接时 形成的。表示被动关闭方等待关闭

TIME_WAIT 状态：

TCP协议规定，主动关闭连接的一方要处于TIME_ WAIT状态，等待两个MSL(最大报文生存周期，Linux默认的TIME_WAIT时长一般是60秒 = 2MSL)的时间后才能回到CLOSED状态。
TIME_WAIT持续存在2MSL的话，就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据，但是这种数据很可能是错误的)。
同时也是在理论上保证最后一个报文可靠到达(假设最后⼀个ACK丢失，那么服务器会再重发一个FIN。这时虽然客户端的进程不在了，但是TCP连接还在，仍然可以重发LAST_ACK)。