Android面试官:想进大厂先把基础打牢了再说,腾讯T3手把手教你
作者:互联网
3.常用的状态码
-
1XX
- 临时消息。服务器收到请求,需要请求者继续操作。 -
2XX
- 请求成功。请求成功收到,理解并处理。 -
3XX
- 重定向。需要进一步的操作以完成请求。 -
4XX
- 客户端错误。请求包含语法错误或无法完成请求。 -
5XX
- 服务器错误。服务器在处理请求的过程中发生了错误。
常见状态码:
200 OK
- 客户端请求成功301
- 资源(网页等)被永久转移到其它URL302
- 临时跳转400 Bad Request
- 客户端请求有语法错误,不能被服务器所理解404 - 请求资源不存在
,错误的URL。500
- 服务器内部发生了不可预期的错误。503 Server Unavailable
- 服务器当前不能处理客户端的请求,一段时间后可能恢复正常。
4.讲一下TCP协议和UDP协议的区别和场景
我先说两个场景,大家可能就比较能理解了。
1) 第一个场景,浏览网页
。(TCP场景)
-
我们访问网页,网页肯定要把所有数据都正确的显示出来吧,如果这个过程中丢包了,那么肯定也会重新传包,不可能只显示一部分网页(保证数据正确性)
-
同样,网页中的内容肯定也需要是
顺序
的。比如我一个抽奖,不可能还没抽就把奖给你了。(保证数据的顺序) -
再来,在这个对数据要求严格的过程中,我们肯定需要两方建立起一个
可靠
的连接,也就是我们上述说到的要经过三次握手才开始传输数据,并且每次发数据包都需要回执(面向连接的) -
而这种连接中传输数据就是用的
字节流
,也就是有根管道,你想怎么传数据都行,想怎么接受数据也都可以,只要在这一根管道里面。
所以这种需要数据准确、顺序不能错、要求稳定可靠
的场景就需要用到TCP。
2)第二个场景,打游戏。(UDP场景)
打游戏最最重要的就是即时,不然我这个技能发出去了你那边还没被打中,这就玩不了了。
-
所以
UDP
是需要保证数据的即时性
,而不保证每个数据包都正确接收到,即使丢包了,也不会去找丢的那个是什么包,因为要显示当前时间的当前数据包。(不保证数据正确性和数据顺序,可能会丢包) -
同样,为了数据的即时性,
UDP
也就不会去建立连接了,不需要什么三次握手,每次你还要确认收没收到。管你收没收到,我只要快速把每个数据包丢给你就行了。(面向无连接的) -
因为是
无连接
的,所以就不需要用到字节流,直接每次丢一个数据报
给你,接收方也只能接受一个数据报(不能和其他发送方的数据报混淆)。(基于数据报的)
如果你还是有点晕,可以看看这篇文章(亚当和夏娃),很形象的比喻:https://www.zhihu.com/question/51388497?sort=created
5.socket和WebSocket
虽然这两个货名字类似,但其实不是一个层级的概念。
-
socket
,套接字。上文说过了,在TCP建立连接的过程中,是调用了Socket的相关API,建立了这个连接通道。所以它只是一个接口,一个类。 -
WebSocket
,是和HTTP同等级,属于应用层协议。它是为了解决长时间通信的问题,由HTML5规范引出,是一种建立在TCP协议基础上的全双工通信的协议,同样下层也需要TCP建立连接,所以也需要socket。
科普:WebSocket在TCP连接建立后,还要通过Http进行一次握手,也就是通过Http发送一条GET请求消息给服务器,告诉服务器我要建立WebSocket连接了,你准备好哦,具体做法就是在头部信息中添加相关参数。然后服务器响应我知道了,并且将连接协议改成WebSocket,开始建立长连接。
如果硬要说这两者有关系,那就是WebSocket
协议也用到了TCP连接
,而TCP连接用到了Socket
的API。
6.Https的连接建立过程
说完了HTTP和TCP/IP,再说说HTTPS
。
其中主要就是用到了数字证书
。
现在完整看看Https连接建立(也叫TLS握手流程)
:
- 1、客户端发送 Client Hello 数据包消息。
这个消息内容包括一个随机数(randomC)
,加密族
(密钥交换算法也就是非对称加密算法、对称加密算法、哈希算法),Session ID
(用作恢复回话)。
客户端要建立通信,在TCP握手之后,会发送第一个消息,也叫Client Hello
消息。这个消息主要发了以上的一些内容,其中密文族就是把客户端这边支持的一些算法发给服务器,然后服务器拿来和服务器支持的算法一比较,就能得出双方都支持的最优算法了。
- 2、服务器回复三个数据包消息:Server Hello,Certificate,Server Hello Done。
Server Hello
消息内容包括一个随机数(randomS),比较后得出的加密族,Session ID(用作恢复回话)。
到现在,双方已经有两个随机数了,待会再看看这两个随机数是干嘛的。然后加密算法刚才说过了,服务器协商出了三种算法并发回给客户端。
Certificate
消息就是发送数字证书了。这里就不细说了。
Server Hello Done
消息就是个结束标志,表示已经把该发的消息都发给你了。
- 3、对称密钥生成过程
1)首先,客户端会对发来的证书进行验证
,比如数字签名、证书链、证书有效期、证书状态。2)证书校验完毕后,然后客户端会用证书里的服务器公钥加密发送一个随机数 pre—master secret
,服务器收到之后用自己的私钥解密。3)到此,客户端和服务器就都有三个随机数了:randomC、randomS、pre—master secret。
4)然后客户端和服务器端分别按照固定的算法,用三个随机数生成对称密钥
。
- 4、生成Session ID
这一步和开始两个hello消息中的Session ID
对应起来了。
会生成会话的id,如果后续会话断开了,那么通过这个Session ID
就可以恢复对话,不需要重新进行发送证书、生成密钥过程了。
- 5、用对称密钥传输数据
拿到对称密钥后,双方就可以使用对称密钥加密解密数据,进行正常通信了。
扩展
:为什么要使用非对称加密算法协商出对称加密这种方法?
首先,网络传输数据对传输的速度要求比较高,在保证安全的前提下,所以采用了对称加密的方法,而不用耗时较多的非对称加密算法。其次,在确定对称加密传输数据的前提下,如果传输对称加密的密钥是个涉及到安全的问题,所以就采用了安全性更高的非对称加密算法,加上证书链机制,保证了传输对称密钥相关数据
的安全性。
7.请给我讲解一下数字签名,为什么真实可靠
数字签名
,也就是上文中说的电子签名,再简单回顾下:
数字签名,其实也是一种非对称加密
的用法。
它的使用方法是:
A使用私钥对数据的哈希值
进行加密,这个加密后的密文就叫做签名
,然后将这个密文和数据本身传输给B。
B拿到后,签名用公钥
解密出来,然后和传过来数据的哈希值做比较,如果一样,就说明这个签名确实是A签的,而且只有A才可以签,因为只有A有私钥
。
反应实际情况就是:
服务器端将数据,也就是我们要传的数据(公钥),用另外的私钥签名
数据的哈希值,然后和数据(公钥)
一起传过去。然后客户端用另外的公钥对签名解密,如果解密数据和数据(公钥)的哈希值一致,就能证明来源正确
,不是被伪造的。
-
来源可靠
。数字签名只能拥有私钥的一方才能签名,所以它的存在就保证了这个数据的来源是正确的 -
数据可靠
。hash值是固定的,如果签名解密的数据和本身的数据哈希值一致,说明数据是未被修改的。
8.证书链安全机制
证书颁发机构(CA, Certificate Authority)即颁发数字证书的机构。是负责发放和管理数字证书的权威机构,并作为电子商务交易中受信任的第三方,承担公钥体系中公钥的合法性检验的责任。
实际情况中,服务器会拿自己的公钥以及服务器的一些信息传给CA
,然后CA
会返回给服务器一个数字证书
,这个证书里面包括:
-
服务器的公钥
-
签名算法
-
服务器的信息,包括主机名等。
-
CA自己的私钥对这个证书的签名
然后服务器将这个证书在连接阶段传给客户端
,客户端怎么验证呢?
细心的小伙伴肯定知道,每个客户端,不管是电脑、手机都有自带的系统根证书
,其中就会包括服务器数字证书的签发机构
。所以系统的根证书会用他们的公钥
帮我们对数字证书的签名进行解密,然后和证书里面的数据哈希值进行对比,如果一样,则代表来源
是正确的,数据
是没有被修改的。
当然中间人也是可以通过CA申请证书的,但是证书中会有服务器的主机名,这个主机名(域名、IP)
就可以验证你的来源是来源自哪个主机。
扩展一下:
其实在服务器证书和根证书中间还有一层结构:叫中级证书
,我们可以任意点开一个网页,点击左上角的
标签:面试官,证书,T3,传输,打牢,服务器,数据,连接,客户端 来源: https://blog.csdn.net/m0_61408726/article/details/120119255