攒了一个月的Android面试题及详细解答，马上年底准备起来，冲刺大厂单车变摩托！（上篇）

一个月前呢，为了巩固下自己的基础以及为以后的面试做准备，每天去找一些大厂的面试真题，然后解答下，然后自己确实也在这个过程中能复习到不少以前没有重视的问题，今天就总结下之前一个多月总结的面试题，难度不大，大佬可以直接路过，当然发发善心点个赞也是可以的❤️。

进入正题，下面为主要内容，每三个问题为一个小节，也就是一个专题文章，我就不具体区分了，由于字数问题，也只节选了一些问题，大家见谅。另外答的不好的地方大家也可以留言敲敲我，感谢。

网页中输入url，到渲染整个界面的整个过程，以及中间用了什么协议？

1）过程分析：主要分为三步

• DNS解析。用户输入url后，需要通过DNS解析找到域名对应的ip地址，有了ip地址才能找到服务器端。首先会查找浏览器缓存，是否有对应的dns记录。再继续按照操作系统缓存—路由缓存—isp的dns服务器—根服务器的顺序进行DNS解析，直到找到对应的ip地址。
• 客户端（浏览器）和服务器交互。浏览器根据解析到的ip地址和端口号发起HTTP请求，请求到达传输层，这里也就是TCP层，开始三次握手建立连接。服务器收到请求后，发送相应报文给客户端（浏览器），客户端收到相应报文并进行解析，得到html页面数据，包括html，js，css等。
• 客户端（浏览器）解析html数据，构建DOM树，再构造呈现树（render树），最终绘制到浏览器页面上。

2）其中涉及到TCP/IP协议簇，包括DNS，TCP，IP，HTTP协议等等。

具体介绍下TCP/IP

TCP/IP一般指的是TCP/IP协议簇，主要包括了多个不同网络间实现信息传输涉及到的各种协议 主要包括以下几层：

• 应用层：主要提供数据和服务。比如HTTP，FTP，DNS等
• 传输层：负责数据的组装，分块。比如TCP，UDP等
• 网络层：负责告诉通信的目的地，比如IP等
• 数据链路层：负责连接网络的硬件部分，比如以太网，WIFI等

TCP的三次握手和四次挥手，为什么不是两次握手？为什么挥手多一次呢？

客户端简称A，服务器端简称B

1）TCP建立连接需要三次握手

• A向B表示想跟B进行连接（A发送syn包，A进入SYN_SENT状态）
• B收到消息，表示我也准备好和你连接了（B收到syn包，需要确认syn包，并且自己也发送一个syn包，即发送了syn+ack包，B进入SYN_RECV状态）
• A收到消息，并告诉B表示我收到你也准备连接的信号了（A收到syn+ack包，向服务器发送确认包ack，AB进入established状态）开始连接。

2）TCP断开连接需要四次挥手

• A向B表示想跟B断开连接（A发送fin，进入FIN_WAIT_1状态）
• B收到消息，但是B消息没发送完，只能告诉A我收到你的断开连接消息（B收到fin，发送ack，进入CLOSE_WAIT状态）
• 过一会，B数据发送完毕，告诉A，我可以跟你断开了（B发送fin，进入LAST_ACK状态）
• A收到消息，告诉B，可以他断开（A收到fin，发送ack，B进入closed状态）

3）为什么挥手多一次 其实正常的断开和连接都是需要四次：

• A发消息给B
• B反馈给A表示正确收到消息
• B发送消息给A
• A反馈给B表示正确收到消息。

但是连接中，第二步和第三步是可以合并的，因为连接之前A和B是无联系的，所以没有其他情况需要处理。而断开的话，因为之前两端是正常连接状态，所以第二步的时候不能保证B之前的消息已经发送完毕，所以不能马上告诉A要断开的消息。这就是连接为什么可以少一步的原因。

4）为什么连接需要三次，而不是两次。正常来说，我给你发消息，你告诉我能收到，不就代表我们之前通信是正常的吗？

• 简单回答就是，TCP是双向通信协议，如果两次握手，不能保证B发给A的消息正确到达。

TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。

TCP是怎么保证可靠传输的？

• 序列号和确认号。比如连接的一方发送一段80byte数据，会带上一个序列号，比如101。接收方收到数据，回复确认号181（180+1），这样下一次发送消息就会从181开始发送了。

所以握手过程中，比如A发送syn信号给B，初始序列号为120，那么B收到消息，回复ack消息，序列号为120+1。同时B发送syn信号给A，初始序列号为256，如果收不到A的回复消息，就会重发，否则丢失这个序列号，就无法正常完成后面的通信了。

这就是三次握手的原因。

TCP和UDP的区别？

TCP提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接（三次握手），之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

UDP 是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

所以总结下来就是：

• TCP 是面向连接的，UDP 是面向无连接的
• TCP数据报头包括序列号，确认号，等等。相比之下UDP程序结构较简单。
• TCP 是面向字节流的，UDP 是基于数据报的
• TCP 保证数据正确性，UDP 可能丢包
• TCP 保证数据顺序，UDP 不保证

可以看到TCP适用于稳定的应用场景，他会保证数据的正确性和顺序，所以一般的浏览网页，接口访问都使用的是TCP传输，所以才会有三次握手保证连接的稳定性。而UDP是一种结构简单的协议，不会考虑丢包啊，建立连接等。优点在于数据传输很快，所以适用于直播，游戏等场景。

HTTP的几种请求方法具体介绍

常见的有四种：

• GET 获取资源，没有body，幂等性
• POST 增加或者修改资源，有body
• PUT 修改资源，有body，幂等性
• DELETE 删除资源，幂等性

HTTP请求和响应报文的格式，以及常用状态码。

1）请求报文：

//请求行（包括method、path、HTTP版本）
   GET /s HTTP/1.1
   //Headers
   Host: www.baidu.com
   Content-Type: text/plain
   //Body
   搜索****

2）响应报文

 //状态行 （包括HTTP版本、状态码，状态信息）
   HTTP/1.1 200 OK
   //Headers
   Content-Type: application/json; charset=utf-8
   //Body
   [{"info":"xixi"}]

3）常用状态码

主要分为五种类型：

• 1开头， 代表临时性消息，比如100（继续发送）
• 2开头， 代表请求成功，比如200（OK）
• 3开头， 代表重定向，比如304（内容无改变）
• 4开头， 代表客户端的一些错误，比如403（禁止访问）
• 5开头， 代表服务器的一些错误，比如500

介绍对称加密和非对称加密

1）对称加密，即加密和解密算法不同，但是密钥相同。比如DES，AES算法。

数据A --> 算法D（密钥S）--> 加密数据B
加密数据B --> 算法E（密钥S）--> 数据A

优点：缺点：密钥有可能被破解，容易被伪造。传输过程中一旦密钥被其他人获知则可以进行数据解密。

2）非对称加密，即加密和解密算法相同，但是密钥不同。私钥自己保存，公钥提供给对方。比如RSA，DSA算法。

数据A --> 算法D（公钥）--> 加密数据B
加密数据B --> 算法D（私钥）--> 数据A

优点：安全，公钥即使被其他人获知，也无法解密数据。缺点：需要通信双方都有一套公钥和私钥

数字签名的原理

1）首先，为什么需要数字签名？防止被攻击，被伪造。由于公钥是公开的，别人截获到公钥就能伪造数据进行传输，所以我们需要验证数据的来源。

2）怎么签名？由于公钥能解密 私钥加密的数据，所以私钥也能解密 公钥加密的数据。（上图非对称加密A和B代号互换即可） 所以我们用公钥进行加密后，再用私钥进行一次加密，那么私钥的这次加密就叫签名，也就是只有我自己可以进行加密的操作。所以传输数据流程就变成了加密数据和签名数据，如果解出来都是同样的数据，那么则数据安全可靠。

数据A --> 算法D（公钥）--> 加密数据B
数据A --> 算法D（私钥）--> 签名数据C

加密数据B --> 算法D（私钥）--> 数据A
签名数据C --> 算法D（公钥）--> 数据A

Base64算法是什么，是加密算法吗？

• Base64是一种将二进制数据转换成64种字符组成的字符串的编码算法，主要用于非文本数据的传输，比如图片。可以将图片这种二进制数据转换成具体的字符串，进行保存和传输。

• 严格来说，不算。虽然它确实把一段二进制数据转换成另外一段数据，但是他的加密和解密是公开的，也就无秘密可言了。所以我更倾向于认为它是一种编码，每个人都可以用base64对二进制数据进行编码和解码。

• 面试加分项：为了减少混淆，方便复制，减少数据长度，就