-
http请求方法
a. http 1.0: get, post, head(只返回响应头内容)
b. http 1.1: 新增了5中请求方法:option, put, patch, delete(删除指定页面), trace, connect -
http状态码有什么
100继续,200成功,301(资源永久移除到其它url)307(临时重定向)400(客户端错误,请求包含语法错误或请求无法完成)500(服务端错误)
-
跨域底层原理:
Webpack Proxy工作原理(本地跨域)
首先强调的是webpack proxy只能用作于开发阶段,临时解决本地请求服务器(通常是测试服)产生的跨域问题,并不适用线上环境。配置在webpack的 devServer 属性中。
webpack中的proxy只是一层代理,用于把指定的path,代理去后端提供的地址,背后使用node来做server。可能有人疑惑,为什么只适用本地开发?因为该技术只是在webpack打包阶段在本地临时生成了node server,来实现类似nginx 的proxy_pass的反向代理效果
proxy工作原理实质上是利用http-proxy-middleware 这个http代理中间件,实现请求转发给其他服务器。例如:本地主机A为http://localhost:3000,该主机浏览器发送一个请求,接口为/api,这个请求的数据(响应)在另外一台服务器Bhttp://10.231.133.22:80上,这时,就可以通过A主机设置webpack proxy,直接将请求发送给B主机。
参考博客:
Webpack Proxy工作原理(本地跨域)
-
前端写代码防止什么攻击xss?xss的原理
(1)xss攻击指的是通过网页开发时留下的漏洞,通过巧妙地方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序,这些恶意网页程序通常是javascript、java等。攻击者可以得到私密网页内容,会话,cookie等。Xss产生的原因是因为用户输入的数据变成了代码。
(2)解决方案:
a. 对重要的cookie设置httponly,防止客户端通过document.cokie读取cookie
b. 编码。对用户输入的内容进行字符实体编码;原样显示的内容必须解码,不然显示不到内容
c. 将不合法的东西都过滤掉,比如移除用户上传的DOM属性
d. 存在一个parse函数,对输入的数据进行处理,返回处理之后的数据
e. 尽量避免eval语句。 -
get和post的差别
(1)get在浏览器回退是无害的,而post会再次提交请求
(2)get产生的url地址可以被bookmark,post不可以
(3)get请求会被浏览器主动cache, post不会
(4)get请求只能进行url编码,而post支持多种编码方式
(5)get请求参数会完整保留在浏览器历史记录里,而post参数不会被保留
(6)get请求在url中传送的参数有长度限制,post没有
(7)对于参数的数据类型,get请求只接受ASCII字符,post没有限制
(8)get通过url传参,post放在request body中
(9)最后一个重大区别就是get产生一个tcp数据包,而post会产生2个,对于get,浏览区会把http header一起发出去,服务器响应200返回数据;对于post,浏览器先发送header,服务器响应100浏览器再发送data,服务器返回数据。所以在网络环境差的时候,get会有优势 -
有没有封装过请求方法:
Ajax的封装;
小程序请求的封装 -
Http与Https的区别
- HTTP 的 URL 以 http:// 开头,而 HTTPS 的 URL 以 https:// 开头
- HTTP 是不安全的,而 HTTPS 是安全的
- HTTP 标准端口是80 ,而 HTTPS 的标准端口是443
- HTTP 无法加密,而 HTTPS 对传输的数据进行加密
- HTTP 无需证书,而 HTTPS 需要 CA 机构的颁发的 SSL 证书、
-
什么是Http协议无状态协议?怎么解决Http协议无状态协议?
无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,也就是说,当客户端一次HTTP请求完成以后,客户端再发送一次HTTP请求,HTTP并不知道当前客户端是一个“老用户”
可以使用Cookie来解决无状态的问题,Cookie就相当于一个通行证,第一次访问的时候给客户端发送一个Cookie,当客户端再次来的时候,拿着Cookie(通行证),那么服务器就知道这个是“老用户”
9.一次完整的HTTP请求所经历的7个步骤
建立TCP连接->发送请求行->发送请求头->(到达服务器)发送状态行->发送响应头->发送响应数据->断TCP连接
- 三次握手四次挥手
三次握手:
第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
四次挥手:
1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
2)服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
- 为什么连接的时候是三次握手,关闭的时候却是四次握手?
因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
- 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
- 为什么不能用两次握手进行连接?
3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
- 如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
-
说一下Http协议中302,304, 307状态
- 302:http协议中,返回状态码302表示重定向。 这种情况下,服务器返回的头部信息中会包含一个 Location 字段,内容是重定向到的url
- 304:304状态码或许不应该认为是一种错误,而是对客户端有缓存情况下服务端的一种响应。客户端在请求一个文件的时候,发现自己缓存的文件有 Last Modified ,那么在请求中会包含 If Modified Since ,这个时间就是缓存文件的 Last Modified 。因此,如果请求中包含 If Modified Since,就说明已经有缓存在客户端。服务端只要判断这个时间和当前请求的文件的修改时间就可以确定是返回 304 还是 200 。
对于静态文件,例如:CSS、图片,服务器会自动完成 Last Modified 和 If Modified Since 的比较,完成缓存或者更新。但是对于动态页面,就是动态产生的页面,往往没有包含 Last Modified 信息,这样浏览器、网关等都不会做缓存,也就是在每次请求的时候都完成一个 200 的请求。
因此,对于动态页面做缓存加速,首先要在 Response 的 HTTP Header 中增加 Last Modified 定义,其次根据 Request 中的 If Modified Since 和被请求内容的更新时间来返回 200 或者 304 。虽然在返回 304 的时候已经做了一次数据库查询,但是可以避免接下来更多的数据库查询,并且没有返回页面内容而只是一个 HTTP Header,从而大大的降低带宽的消耗,对于用户的感觉也是提高。当这些缓存有效的时候,通过 Fiddler 或HttpWatch 查看一个请求会得到这样的结果:第一次访问 200,按F5刷新(第二次访问) 304,按Ctrl+F5强制刷新 200 - 307: 307 Temporary Redirect(临时重定向)是表示重定向的响应状态码,说明请求的资源暂时地被移动到 Location 首部所指向的 URL 上。状态码 307 与 302 之间的唯一区别在于,当发送重定向请求的时候,307 状态码可以确保请求方法和消息主体不会发生变化。当响应状态码为 302 的时候,一些旧有的用户代理会错误地将请求方法转换为 GET:使用非 GET 请求方法而返回 302 状态码,Web 应用的运行状况是不可预测的;而返回 307 状态码时则是可预测的。对于 GET 请求来说,两种情况没有区别。
-
Http协议由什么组成?
1. 请求报文包括三部分:(1).请求行:包含请求方法,URI,HTTP版本协议(2).请求首部字段(3).请求内容实体 2. 响应报文包含三部分:(1).状态行:包含HTTP版本,状态码,状态码原因短语(2).响应首部字段(3).响应内容实体
-
Http协议实现的原理机制
(1).整个流程步骤:
(2)域名解析过程:
18. 浏览器的主要组成部分是什么?
1. 用户界面 - 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外,其他显示的各个部分都属于用户界面。
2. 浏览器引擎 - 在用户界面和呈现引擎之间传送指令。
3. 呈现引擎 - 负责显示请求的内容。如果请求的内容是 HTML,它就负责解析 HTML 和 CSS 内容,并将解析后的内容显示在屏幕上。
4. 网络 - 用于网络调用,比如 HTTP 请求。其接口与平台无关,并为所有平台提供底层实现。
5. 用户界面后端 - 用于绘制基本的窗口小部件,比如组合框和窗口。其公开了与平台无关的通用接口,而在底层使用操作系统的用户界面方法。
6. JavaScript 解释器。用于解析和执行 JavaScript 代码。
7. 数据存储。这是持久层。浏览器需要在硬盘上保存各种数据,例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”,这是一个完整(但是轻便)的浏览器内数据库。
-
浏览器是如何渲染UI的?
- 浏览器获取HTML文件,然后对文件进行解析,形成DOM Tree
- 与此同时,进行CSS解析,生成Style Rules
- 接着将DOM Tree与Style Rules合成为 Render Tree
- 接着进入布局(Layout)阶段,也就是为每个节点分配一个应出现在屏幕上的确切坐标
- 随后调用GPU进行绘制(Paint),遍历Render Tree的节点,并将元素呈现出来
-
什么是浏览器同源策略?
同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。
同源是指"协议+域名+端口"三者相同,即便两个不同的域名指向同一个ip地址,也非同源。
-
如何实现跨域?
- vue中用proxy
- cors
- Nginx
参考博客: