对线面试官:HTTP协议

面试官今天要不来聊聊HTTP吧?

候选者:嗯,HTTP「协议」是客户端和服务器「交互」的一种通迅的格式

候选者:所谓的「协议」实际上就是双方约定好的「格式」,让双方都能看得懂的东西而已

候选者:所谓的交互实际上就是「请求」和「响应」

图片

面试官那你知道HTTP各个版本之间的区别吗?

候选者:HTTP1.0默认是短连接,每次与服务器交互,都需要新开一个连接

候选者:HTTP1.1版本最主要的是「默认持久连接」。只要客户端服务端没有断开TCP连接,就一直保持连接,可以发送多次HTTP请求。

候选者:其次就是「断点续传」(Chunked transfer-coding)。利用HTTP消息头使用分块传输编码,将实体主体分块进行传输

候选者:HTTP/2不再以文本的方式传输,采用「二进制分帧层」,对头部进行了「压缩」,支持「流控」,最主要就是HTTP/2是支持「多路复用」的(通过单一的TCP连接「并行」发起多个的请求和响应消息)

面试官:嗯,稍微打断下。我知道HTTP1.1版本有个管线化(pipelining)理论,但默认是关闭的。管线化这个跟HTTP/2的「多路复用」是很类似的,它们有什么区别呀?

候选者:HTTP1.1提出的「管线化」只能「串行」(一个响应必须完全返回后,下一个请求才会开始传输)

候选者:HTTP/2多路复用则是利用「分帧」数据流,把HTTP协议分解为「互不依赖」的帧(为每个帧「标序」发送,接收回来的时候按序重组),进而可以「乱序」发送避免「一定程度上」的队首阻塞问题

图片

候选者:但是,无论是HTTP1.1还是HTTP/2,response响应的「处理顺序」总是需要跟request请求顺序保持一致的。假如某个请求的response响应慢了,还是同样会有阻塞的问题。

候选者:这受限于HTTP底层的传输协议是TCP,没办法完全解决「线头阻塞」的问题

面试官:哦,好的。

候选者:HTTP/3 跟前面版本最大的区别就是:HTTP1.x和HTTP/2底层都是TCP,而HTTP/3底层是UDP。使用HTTP/3能够减少RTT「往返时延」(TCP三次握手,TLS握手)

图片

面试官你了解HTTPS的过程吗?

候选者:嗯啊,HTTPS在我的理解下,就是「安全」的HTTP协议(客户端与服务端的传输链路中进行加密)

图片

图片

候选者:HTTPS首先要解决的是:认证的问题

候选者:客户端是需要确切地知道服务端是不是「真实」,所以在HTTPS中会有一个角色:CA(公信机构)

候选者:服务端在使用HTTPS前,需要去认证的CA机构申请一份「数字证书」。数字证书里包含有证书持有者、证书有效期、「服务器公钥」等信息

候选者:CA机构也有自己的一份公私钥,在发布数字证书之前,会用自己的「私钥」对这份数字证书进行加密

候选**者**:等到客户端请求服务器的时候,服务端返回证书给客户端。客户端用CA的公钥对证书解密(因为CA是公信机构,会内置到浏览器或操作系统中,所以客户端会有公钥)。这个时候,客户端会判断这个「证书是否可信/有无被篡改」

候选者:私钥加密,公钥解密我们叫做「数字签名」(这种方式可以查看有无被篡改)

候选者:到这里,就解决了「认证」的问题,至少客户端能保证是在跟「真实的服务器」进行通信。

图片

候选者:解决了「认证」的问题之后,就要解决「保密」问题,客户端与服务器的通讯内容在传输中不会泄露给第三方

候选者:客户端从CA拿到数字证书后,就能拿到服务端的公钥

候选者:客户端生成一个Key作为「对称加密」的秘钥,用服务端的「公钥加密」传给服务端

候选者:服务端用自己的「私钥解密」客户端的数据,得到对称加密的秘钥

候选者:之后客户端与服务端就可以使用「对称加密的秘钥」愉快地发送和接收消息

图片

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!