2021年06月10日阅读 108

Android面试指南（四）————网络篇

HTTP和HTTPS

简述一次完整的Http请求过程

通过域名请求后————>DNS域名解析为ip地址————>中间路由跳转————>直接访问ip地址进行三次握手————>tcp三次握手成功后进行通信响应———>tcp四次挥手结束通信

客户端：

在浏览器输入网址。
浏览器解析网址，并生成http请求消息。
浏览器调用系统解析器，发送消息到DNS服务器查询域名对应的ip。
拿到ip后，和请求消息一起交给操作系统协议栈的TCP模块。
将数据分成一个个数据包，并加上TCP报头形成TCP数据包。
TCP报头包括发送方端口号、接收方端口号、数据包的序号、ACK号。
然后将TCP消息交给IP模块。
IP模块会添加IP头部和MAC头部。
IP头部包括IP地址，为IP模块使用，MAC头部包括MAC地址，为数据链路层使用。
IP模块会把整个消息包交给网络硬件，也就是数据链路层，比如以太网，WIFI等。
然后网卡会将这些包转换成电信号或者在光信号，通过网线或者光纤发送出去，再由路由器等转发设备送达接收方。

服务器端：

数据包到达服务器的数据链路层，比如以太网，然后会将其转换为数据包（数字信号）交给IP模块。
IP模块会将MAC头部和IP头部后面的内容，也就是TCP数据包发送给TCP模块。
TCP模块会解析TCP头信息，然后和客户端沟通表示收到这个数据包了。
TCP模块在收到消息的所有数据包之后，就会封装好消息，生成相应报文发给应用层，也就是HTTP层。
HTTP层收到消息，比如是HTML数据，就会解析这个HTML数据，最终绘制到浏览器页面上。

简述三次握手和四次挥手

三次握手：
客户端发送一个随机seq=100
服务端返回一个随机seq=200，ack=100+1
客户端返回一个ack=200+1

四次挥手：
客户端发送一个FIN=1，seq=100
服务端发送一个ack=100+1 服务端发送一个FIN=1，seq=200 客户端发送一个ack=200+1

服务端发送两次的原因是需要等待服务器处理当前任务完毕。

为什么需要三次握手而不是2次或者4次？

防止已失效的连接请求又传送到服务器端，因而产生错误

两次的话，服务端是不知道自己的请求是否成功发送到客户端的。但是服务端又会认为连接建立成功了。假设第二次丢失了，客户端认为服务端没有响应，就会重发一次，这样已经失效的连接请求就会传送到服务端。

tcp是可靠的双方通信协议，所以双方都会生成一个初始的序列号供双方确认，如果改成两次，只会确定客户端对于服务端具有可靠性，而服务端对客户端没有可靠性

四次的话，太过繁琐

为什么握手需要三次？挥手却需要四次？

因为挥手的时候需要等待服务器将本次连接中的所有保文都处理完，在发送关闭状态，说白了，服务器需要等待自身进入可关闭状态

握手可以携带数据信息吗？

第三次请求可以携带数据信息，客户端认为连接已经建立的，就可以携带参数，但是前两次不能，容易造成对服务器的攻击

为什么TIME_WAIT状态需要等待2MSL才能转换到CLOSE状态？

保证最后一次能成功到达服务器。最后一次客户端发送给服务端的确认信息可能丢失，如果丢失，服务端会有重试机制，等待一来一回的时间，也就是2MSL的时间，如果没有接收到服务端的重试请求，就认为服务端接收了，等到了就刷新2MSL时间
等待2MSL的时间也是为了防止失效连接的请求报文会出现在新连接中，防止第三次重试请求能被客户端接受，不会干扰其他请求

SSL层在传输层还是应用层？

SSL层在传输层和应用层之间，是一个SSL层

TCP和UDP的区别？

1、基于连接与无连接；

2、对系统资源的要求（TCP较多，UDP少）；

3、UDP程序结构较简单；

4、流模式与数据报模式；

5、TCP保证数据正确性，UDP可能丢包；

6、TCP保证数据顺序，UDP不保证。

常见状态码

1XX - 临时消息。服务器收到请求，需要请求者继续操作。
2XX - 请求成功。请求成功收到，理解并处理。
3XX - 重定向。需要进一步的操作以完成请求。
4XX - 客户端错误。请求包含语法错误或无法完成请求。
5XX - 服务器错误。服务器在处理请求的过程中发生了错误。

200：客户端请求成功
301：资源（网页等）被永久转移到其他URL
302：重定向，临时跳转
400：客户端请求存在语法错误，不能给被服务器理解（Bad Request）
404：请求资源不存在，错误的URL
500：服务器内部发生了不可预料的错误
502：网关错误（Bad Getway）
503：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。（Server Unavailable）

简述TCP和UDP的区别

TCP：需要数据准确、顺序不能错、要求稳定可靠的场景就需要用到TCP。
UDP：数据即时性

socket

tcp内部是由socket协议填充的

简述https的加密过程

RSA是非对称加密，AES是对称加密

加密过程

客户端请求服务端进行访问
服务端创建RSA，获得私钥和公钥
服务端发送公钥给客户端
客户端经过复杂的证书验证
客户端生成AES密钥
将AES密钥经过RSA公钥加密后发送给服务端
服务端通过RSA私钥解密获取AES密钥
客户端和服务端后续通过AES密钥进行通信

为什么要使用RSA加密形式交换AES密钥，不直接使用RSA加密？

因为RSA加密有性能上的损耗，加解密过程会比较耗时，不适用于频繁通信过程，而AES加密比较快捷

简述中间人攻击，如何解决？（dns劫持）

客户端访问域名A，向服务端进行请求
中间人劫持dns，使之指向私人ip B。即客户端同B建立https连接
B在和A建立https连接
服务端创建RSA，获得公钥（S）和私钥（S）
服务端发送公钥（S）给客户端
中间人拦截信息，获得公钥（S）
生成RSA公钥（中）和私钥（中），并将公钥（中）发送给客户端
客户端生成AES密钥
使用公钥（中）加密AES密钥，并发送给服务端
中间人拦截信息，获得加密信息，使用私钥（中）进行解密，获得AES密钥
中间人使用公钥（S）加密AES密钥，并发送给服务端
服务端通过私钥（S）进行解密，获得AES密钥。

到此为止，中间人持有客户端和服务端交换的AES密钥，可以进行消息拦截，并解密信息

解决方案：将RSA公钥交给CA机构，CA机构添加上域名，有效期等将其制作成证书，在用CA机构的私钥进行加密后放置在服务器上，当客户端请求时，返回加密后信息，客户端从CA机构获取公钥（一般情况下内置在机器中）进行解密，成功解密后，获取的信息，域名等可以匹配上，则CA验证通过，获得服务器公钥，走下面流程。