前端招聘之路-计网

我整理的前端所需的必会计网知识，有些是leetcode学习里面的内容，需要办会员才能学，我选出一些前端用得上的精华，有些是后来的补充，并且都是在面试几十家公司的过程中总结的

计网

OSI七层协议 TCP/IP五层 TCP/IP四层 HTTP,TCP,UDP,IP在哪层?

OSI七层：物理层，数据链路层，网络层，传输层，会话层，表示层，应用层
TCP/IP五层：物理层，数据链路层，网络层，传输层，应用层
TCP/IP四层：网络接入层，网际互联层，传输层，应用层
HTTP在会话层，TCP,UDP在传输层，IP在网络层

HTTP 1.0 1.1区别

缓存处理：1.0使用if-Modified-Since，Expires作为缓存判断标准
1.1优化缓存管理策略，增加了Entity-tag,if-Unmodified-Since,if-Match,if-None-Match
带宽优化：1.0客户端请求对象部分属性时服务端返回整个对象，不支持断点传输，文件下载中断需要重新下载整个包
1.1引入range头域，允许客户端请求部分资源，返回206
HOST头域：1.0一个主机对应一个IP地址，不需要声明主机名（hostname）由于虚拟主机的出现，一个服务器上可能有多个主机共享一个IP地址
1.1引入了HOST头域，请求和响应都可以携带HOST头域，缺少该字段返回400
状态码：1.1新增了24个状态码，如414URL过长，409请求冲突
长连接：1.0默认使用非持久性连接，TCP连接结束后服务端不会记录和跟踪客户端的状态，旧TCP连接不可复用，需要重新建立连接，启用长连接connection:keep-alive
1.1默认使用持久性连接，但是会造成资源浪费，所以设置timeout，在最后一次请求结束的timeout后关闭连接
请求方法：1.0GET请求数据，POST提交数据并请求，HEAD获取头部
1.1OPTION返回支持方法，TRACE返回接收到的数据，CONNECT服务器代理访问，PUT资源有就替换，没有就增加，PATCH资源局部更新，DELETE删除资源

HTTP 1.x 2.0区别

数据传输：1.0使用文本流(字符串)，2.0使用二进制传输，将数据分解为帧，再由帧组成数据流，每个数据流具有ID和优先级，避免关键请求被阻塞
多路复用：一个HTTP请求可以处理多个HTTP请求的传输，以流ID进行标识
头部压缩：使用gzip和compress进行头部压缩，客户端和服务端共同维护一张头部信息表，只需要传输表中的索引
服务器推送：允许服务器不经过客户端允许推送消息，客户端可以发起复位请求取消

HTTP 3.0

传统TCP连接需要进行三次握手四次挥手，再进行TLS加密需要更多的握手次数，较慢还会造成阻塞
所以HTTP3.0使用谷歌提出的QUIC协议，基于UDP，低延迟，上层仍然使用HTTP/2请求
在建立QUIC连接的时候就完成了TLS1.3的握手，只需要1RTT就可以建立安全连接，会将加密信息保存到本地缓存中，再次建立连接需要0RTT，而传统TCP需要3RTT
2.0使用HPACK压缩头部，要求传输有序，会造成队头堵塞；3.0使用QPACK压缩头部，基于UDP不会出现阻塞问题
不和具体底层连接绑定，为两端分配ID，如网络切换，根据ID继续传输

HTTP	HTTPs	HTTP/2	HTTP/3
HTTP	HTTP	HTTP/2	HTTP/2
–	SSL/TLS	TLS1.2	QUIC
TCP	TCP	TCP	UDP
IP	IP	IP	IP
MAC	MAC	MAC	MAC

dns解析原理及流程

dns域名空间是树形结构：根域名，顶级域名，权威域名
流程：
浏览器拿到url后查询本地缓存和HOST头域，查询IP地址
向本地dns服务器发送请求查询IP地址
本地dns服务器向根域名服务器发送请求，返回根域名IP地址
本地dns服务器向顶级域名服务器发送请求，返回顶级域名IP地址
本地dns服务器向权威域名服务器发送请求，返回域名IP地址
向本地服务器发送请求使用TCP连接，本地dns服务器发送请求使用UDP连接
递归查询：本地dns服务器以客户端身份替主机向域名服务器发送请求
迭代查询：本地dns服务器一层一层向上发送请求的过程

cdn加速静态资源

加入cdn后，本地dns服务器将解析权交给cname指向的cdn专用dns服务器
将cdn全局负载均衡设备IP返回本地dns，本地dns向全局负载均衡设备发起请求
根据本地dns的IP地址判断位置，找到本地负载均衡系统，返回IP地址
本地dns将本地负载均衡系统IP发给浏览器，浏览器向cdn节点发起请求
cdn节点有资源就返回请求文件，如果不存在向源服务器请求资源

url到页面展示流程

dns解析：将域名发送给dns服务器，转换为IP地址
建立TCP连接：向服务器发送TCP连接，进行三次握手
发送HTTP请求：浏览器向服务器发起HTTP请求，索要网页资源
处理请求并返回：服务器根据请求发送资源文件给浏览器
浏览器渲染：浏览器解析HTML文件，构建DOM树，渲染CSS文件生成样式规则，布局渲染树绘制到屏幕
断开连接：四次挥手终止TCP连接

三次握手四次挥手

三次握手：服务端处于LISTEN状态，客户端发送SYN=1,Seq=x后，进入SYN-SENT状态
服务端发送SYN=1,ACK=1,Seq=y,Ack=x+1后，进入SYN-RECV状态
客户端发送ACK=1,Seq=x+1,Ack=y+1后，进入ESTABLISHED状态
服务器接收到之后进入ESTABLISHED状态
四次挥手：双方处于ESTABLISHED状态，客户端发送FIN=1,Seq=u后，进入FIN-WAIT-1状态
服务端发送ACK=1,Seq=v,Ack=u+1后，进入CLOSE-WAIT状态，客户端进入FIN-WAIT-2状态
服务端发送FIN=1,ACK=1,Seq=w,Ack=u+1后进入LAST-ACK状态
客户端发送ACK=1,Seq=u+1,Ack=w+1后进入TIME-WAIT状态
服务端接收到之后双方进入CLOSE状态
为什么不能两次/四次握手？
两次握手建立连接，客户端知道服务器能够收到数据，而服务器并不知道客户端是否能够收到数据，没收到误以为连接建立浪费资源
因为完全可靠的通信协议是不存在的，只能确认之前的，无法确定之后的情况，握手再多次也不能确定，浪费资源
为什么握手三次，挥手四次？
建立连接时，服务端进入握手阶段并不需要准备，直接返回SYN和ACK报文，建立连接
释放连接时，服务端收到客户端释放连接的请求时并不能立即释放连接，还有必要的数据需要处理，
服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接，才能返回FIN释放连接报文

TCP UDP区别

–	面向连接	可靠性	传输效率	数据传输形式	所需资源	首部长度	应用场景
TCP	面向	可靠	低	字节流	多	20-60字节	发送文件，邮件
UDP	不面向	不可靠	高	数据报文流	少	8字节	即时通讯，域名转换

字节流和数据报文流
TCP将应用程序看成是一连串的无结构的字节流。TCP套接口有一个发送缓冲区，字节流太长，拆分进行发送。字节流太短，TCP会等待缓冲区中的字节流达到一定程度时再构成报文发送出去，
TCP发给对方的数据，对方在收到数据时必须给矛确认，只有在收到对方的确认时，本方TCP才会把TCP发送缓冲区中的数据删除。
客户端连续发送数据，只要服务端的这个函数的缓冲区足够大，会一次性接收过来，即客户端是分好几次发过来，是有边界的，而服务端却一次性接收过来，所以证明是无边界的
UDP传输报文的方式是由应用程序控制的，应用层交给UDP多长的报文，UDP照样发送，既不拆分，也不合并，而是保留这些报文的边界，即一次发送一个报文。
客户端分几次发送过来，服务端就必须按几次接收，是有边界的。

状态码

1xx请求正在处理  
100继续  
2xx成功  
200成功 204成功但无内容返回  206返回部分资源
3xx重定向，需要继续操作  
301永久重定向 302/3/7临时重定向 304自从上次请求后网页if-Modified-Since未修改  
4xx客户端错误  
400语法错误 401需要认证信息 403拒绝访问  404找不到资源 409请求冲突 410资源永久删除 414url过长  
5xx服务器错误  
500服务器错误  502网关或代理服务器接收无效响应  503服务器宕机  504网关或代理服务器超时

GET和POST区别

GET参数在URL中，安全性低，适用于请求资源，只支持URL编码和ASCII编码，发送Head+data返回200，生成一个TCP数据包，参数通过Request.QueryString获取
POST参数在请求主体中，安全性高，支持多种编码，发送Head返回100，再发送data返回200，生成两个TCP数据包（Firefox一个），参数通过Request.Form获取

HTTP和HTTPs区别 HTTPs加密过程

HTTPs=HTTP+SSL

–	数据格式	安全性	默认端口	响应速度	–
HTTP	明文	未加密	80	快	–
HTTPs	加密	安全性好	443	慢(多SSL)	需要申请CA证书，有费用

HTTPs加密过程 在建立TCP三次握手之后
客户端发起HTTPs请求到443端口，提供支持算法和密钥长度
服务端对比算法列表选择一种算法，与其他密钥组件发送给客户
服务端发送带有公钥的CA数字证书给客户
服务端通知客户端，SSL第一阶段协商结束
客户端使用证书中的公钥生成随机密码串发送给服务端
客户端发送给服务端加密串加密的报文，再发送finish
如果服务端可以解密，服务端也同样报文给客户端，发送finish
非对称加密：验证CA数字证书阶段
对称加密：利用密钥加密解密阶段

websocket理解

建立与TCP之上，只需要一次握手可以建立持久性连接，允许服务端向客户端推送消息  
客户端发起http请求，经过3次握手后，建立起TCP连接  
发送GET请求，带有WebSocket支持的版本号，Upgrade:websocket，Connection:Upgrade  
服务器收到客户端的握手请求后，返回一个Switching Protocol  
客户端收到连接成功的消息后，开始借助于TCP传输信道进行全双工通信  

Session和Cookie区别

Session：发起请求时，在服务端创建Seesion对象，以键值对形式存储，分配sessionid给客户端，
保存至Cookie中（Cookie被禁用，重写URL的token中携带）
优点：安全性高，保存在服务端
缺点：如果是分布式系统，负载均衡，多个请求到不同的服务器，不能保持数据一致性
方案：使用中间件，如Redis，将Session存储在中间件中
Cookie:服务端在响应头设置SetCookie字段存储客户端状态,创建Cookie，浏览器每次访问请求Cookie
(设置secure=true和头部加httpOnly禁止js获取cookie(tomcat7默认加httpOnly))
优点：减轻服务器负担
缺点：不安全，请求头长占用带宽

cookie加密：用户名，MD5加密的密码，有效时间，自定义字符串webkey使用":"间隔，
拼接成一个字符串，再用MD5加密，进行base64编码，设置为coookieName写入客户端

cookie属性：expires，domains(服务器域名)，path(域名下哪些路径可接收cookie)，
secure(只有https可以设置，传输过程加密本地cookie不加密)，httponly(只能服务端设置)
samesite属性：防止CSRF攻击，用来限制第三方cookie
strict完全禁止获取cookie，不会发送cookie，登录cookie不发送体验不好
lax大多数情况禁止cookie，基本杜绝CSRF，除了预加载GET请求
none没有限制，必须同时设置secure属性

localstorage和sessionstorage区别

都以键值对形式保存在客户端
localStorage存储持久型数据，浏览器关闭后数据不丢失，除非主动删除，用于存储浏览器访问次数
sessionStorage基于当前会话，数据在当前浏览器窗口关闭后删除，用于页面传值

JWT登录鉴权-JSON Web Token

分为header，payload，signature
流程：
用户输入账号密码登录，服务器返回token和refresh-token，客户端保存到本地
带token请求资源
如果token过期，客户端带refresh-token请求资源，服务端返回新的token和refresh-token，客户端保存到本地
如果token和refresh-token都过期，需重新登录
signature加密：使用服务端私有密钥secret，将header和payload转成base64，与secret用"."拼接,再用header指定的签名算法加密

多地登录问题

登陆后，后端清除该账户所有token，并新建一个token返回给客户端，客户端存到localStorage
别处登录的客户端由于对应的token被系统清除，所以是未登录状态，如果本地有token，则证明异地登录，如果没有token，证明没有登陆过