前端面试之网络

Posted 2021-09-14 seven

1. HTTP2

二进制分帧

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

多路复用

多路复用，代替原来的序列和阻塞机制。所有请求都是通过一个TCP连接并发完成。 HTTP1.x 中，如果想并发多个请求，必须使用多个TCP链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制

这一特性，使性能有了极大提升：

1. 同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
2. 单个连接上可以并行交错的请求和响应，之间互不干扰。
3. 在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。

服务器推送

服务端可以主动推送，客户端也有权利选择是否接收

头部压缩

1. HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
2. 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
3. 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

2. 简述TCP连接的过程

第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；
SYN：同步序列编号(Synchronize Sequence Numbers)

第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.

3. http1.1时如何复用tcp连接

Http/1.0每次请求都需要建立新的TCP连接，连接不能复用。Http/1.1新的请求可以在上次建立的tcp连接之上发送，连接可以复用，即keep-alive。

4. 文件上传如何做断点续传

大文件上传

1. 前端上传大文件时使用 Blob.prototype.slice 将文件切片，并发上传多个切片，最后发送一个合并的请求通知服务端合并切片
2. 服务端接收切片并存储，收到合并请求后使用 fs.appendFileSync 对多个切片进行合并
3. 原生 XMLHttpRequest 的 upload.onprogress 对切片上传进度的监听
4. 根据每个切片的进度算出整个文件的上传进度

断点续传

1. 使用 spark-md5 根据文件内容算出文件 hash
2. 通过 hash 可以判断服务端是否已经上传该文件，从而直接提示用户上传成功（秒传）
3. 通过 XMLHttpRequest 的 abort 方法暂停切片的上传
4. 上传前服务端返回已经上传的切片名，前端跳过这些切片的上传

5. 介绍 HTTPS 握手过程

1. 客户端使用https的url访问web服务器,要求与服务器建立ssl连接
2. web服务器收到客户端请求后, 会将网站的证书(包含公钥)传送一份给客户端
   客户端收到网站证书后会检查证书的颁发机构以及过期时间, 如果没有问题就随机产生一个秘钥
3. 客户端利用公钥将会话秘钥加密, 并传送给服务端, 服务端利用自己的私钥解密出会话秘钥
4. 之后服务器与客户端使用秘钥加密传输

6. HTTPS握手过程中，客户端如何验证证书的合法性

首先什么是 HTTP 协议?

http 协议是超文本传输协议，位于 tcp/ip 四层模型中的应用层；通过请求/响应的方式在客户端和服务器之间进行通信；但是缺少安全性，http 协议信息传输是通过明文的方式传输，不做任何加密，相当于在网络上裸奔；容易被中间人恶意篡改，这种行为叫做中间人攻击；

加密通信：

为了安全性，双方可以使用对称加密的方式 key 进行信息交流，但是这种方式对称加密秘钥也会被拦截，也不够安全，进而还是存在被中间人攻击风险；
于是人们又想出来另外一种方式，使用非对称加密的方式；使用公钥/私钥加解密；通信方 A 发起通信并携带自己的公钥，接收方 B 通过公钥来加密对称秘钥；然后发送给发起方 A；A 通过私钥解密；双发接下来通过对称秘钥来进行加密通信；但是这种方式还是会存在一种安全性；中间人虽然不知道发起方 A 的私钥，但是可以做到偷天换日，将拦截发起方的公钥 key;并将自己生成的一对公/私钥的公钥发送给 B；接收方 B 并不知道公钥已经被偷偷换过；按照之前的流程，B 通过公钥加密自己生成的对称加密秘钥 key2;发送给 A；
这次通信再次被中间人拦截，尽管后面的通信，两者还是用 key2 通信，但是中间人已经掌握了 Key2;可以进行轻松的加解密；还是存在被中间人攻击风险；

解决困境：权威的证书颁发机构 CA 来解决；

1. 制作证书：作为服务端的 A，首先把自己的公钥 key1 发给证书颁发机构，向证书颁发机构进行申请证书；证书颁发机构有一套自己的公私钥，CA 通过自己的私钥来加密 key1,并且通过服务端网址等信息生成一个证书签名，证书签名同样使用机构的私钥进行加密；制作完成后，机构将证书发给 A；
2. 校验证书真伪：当 B 向服务端 A 发起请求通信的时候，A 不再直接返回自己的公钥，而是返回一个证书；
   说明：各大浏览器和操作系统已经维护了所有的权威证书机构的名称和公钥。B 只需要知道是哪个权威机构发的证书，使用对应的机构公钥，就可以解密出证书签名；接下来，B 使用同样的规则，生成自己的证书签名，如果两个签名是一致的，说明证书是有效的；
   签名验证成功后，B 就可以再次利用机构的公钥，解密出 A 的公钥 key1;接下来的操作，就是和之前一样的流程了；
3. 中间人是否会拦截发送假证书到 B 呢？
   因为证书的签名是由服务器端网址等信息生成的，并且通过第三方机构的私钥加密中间人无法篡改； 所以最关键的问题是证书签名的真伪；

https 主要的思想是在 http 基础上增加了 ssl 安全层，即以上认证过程；

项目中如何处理安全问题
介绍SSL和TLS（寺库）
说说网络的五层模型（寺库）
HTTP劫持、DNS劫持与XSS
永久性重定向（301）和临时性重定向（302）对 SEO 有什么影响
介绍下 HTTPS 中间人攻击
请求时浏览器缓存 from memory cache 和 from disk cache 的依据是什么，哪些数据什么时候存放在 Memory Cache 和 Disk Cache中？
说说浏览器缓存机制