阿里盒马前端五面问题总结
1.提交表单,常用的方法有哪些?应用层,通信层发生了哪些过程?
- 在form表单提交时我们最常用的方式时get和post,form表单提交时最要注意的就是enctype,enctype属性默认是application/x-www-form-urlencoded.
- 在get方式时,浏览器会以当前的enctype编码方式将form数据转化成一个字符串,并将改字符串append到url上,以?分割。加载该新的url
- 在post方式中:
- 如果form中没有type为file的控件时,form也会以默认enctype进行编码。
- 如果是具有type为file的控件时,enctype得设置成multipart/form-data,这样浏览器会将表单以控件为单位分割,并为每个部分加上Content-Disposition(form-data或者时file)、content-type(默认值为text/plain)、name等信息,并加上分割符(boundary)
浏览器请求后发生的完整过程
- 浏览器发送请求后,DNS(Domain Name System)解析域名得到相应的IP地址。
- 通过域名访问网页
- 将域名发送到解析域名的服务器上,有很多专门解析.org、.cn、.com等,最主要有一台根域名服务器
- 找到对应的IP地址
- 应用层http协议(HyperText Transfer Protocol,超文本传输协议)
- 发送请求的我们称之为客户端(client)、而做出相应的服务器叫做源服务器(origin server)。在客户端和服务端之间可能存在很多中间层,比如代理,网关,隧道等。
- http协议中的请求报文和响应报文(具体格式大家可以百度了解下)
- 通信层(TCP/IP):
- 生成http报文及请求
- TCP协议将http请求报文进行分割(为了方便传输),并在每个报文上标记序号和端口号发给网络层(IP协议)
- 网络层增加作为通信目的的MAC地址后转发给链路层(建立电路连接,整个网络的物理基础,典型协议为以太网和ADSL等)
- 链路层处理后生成的数据包通过物理层传输到接收端
- 接收到数据的服务端后按序网上传,
- TCP连接的三次握手四次挥手
- IP协议实现数据传递到对方计算机
- 解析请求报文并生成响应报文
参考资料:https://blog.csdn.net/weixin_42621338/article/details/87354737
2.post和get的区别,列举一下
区别
1.get在浏览器后退时无害,不发送请求。post在浏览器后退时会再次发送请求。
2.get参数通常放在url后面传递,post则通常放在Request body中传递。但实际上,get也可以用body少量传值,post也可以在url中少量传值,这在技术上是完全行的通的,只是不符合http的规定
3.get比post更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
4.get在url中传输参数有长度限制,post没有限制。get之所以会限制请求长度,是因为url请求数据量太大对浏览器和服务器都是很大的负担,处理起来有成本,所以浏览器和服务器对单次访问都做了限制。(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。超过的部分,恕不处理。虽然GET可以带request body,也不能保证一定能被接收到。所以此处的不同,是因为HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。所以如果请求参数可能很长很多的话,直接用post即可(如果用get,超过限制,参数传不过去,会报null)!
5.GET产生一个TCP数据包;POST产生两个TCP数据包(重点区别!)**。对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。也就是post请求,第一次将header发送过去,确认服务器和网络没问题可以服务,才会将真正的data数据提交。 因为POST需要两步,时间上消耗的要多一点,看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑!跳入需谨慎。为什么?
5.1. GET与POST都有自己的语义,不能随便混用。get从指定的资源获取数据,post是向指定的资源提交数据(使用场景!)
5.2.在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。也就是网络好的话get和post请求效率基本一样,网络不好的时候post对验证请求数据完整性更有优势。
5.3.并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次
联系
1.get和post只是http请求的两种方式,底层都是TCP/IP协议进行通信的。大致过程:用户发出http请求(此时用户的电脑也是一个端,有自己的ip,通过socket使用tcp协议传送数据),请求数据包会通过tcp协议通过网络传给解析的ip,ip收到数据之后(可能还会使用tcp协议与其他ip进行数据交互),处理完成之后,再通过tcp协议将结果返回给用户。所以get和post本质并无区别,只是被http规定了不同的行为和方式。
2.之所以有get和post区分,是因为他们底层数据的传输都是基于tcp协议,如果不做区分,网络中都是某一种服务类别,难免会混乱。为了避免这种情况发生,http协议诞生了。HTTP给网络运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,HTTP规定,当执行GET请求的时候,要给请求包贴上GET的标签(设置method为GET),而且要求把传送的数据放在url中以方便记录。如果是POST请求,在请求数据包贴上POST的标签。
用法
1.get:如果主要是为了获取数据,比如一些获取数据的get请求,且加上请求参数的url不会特别大(小于1k还是2k),且最好没有需要保密的字段,则用get请求;
2.post:如果主要是为了提交一些数据,比如提交一些数据给后台保存,删除等(通常是一些写方法),无论是否有一定数据量均可使用post;
3.以上没有严格划分,即使使用post提交请求来get一些数据也是可以的
HTTP常见状态码
1××:消息响应
2××:成功响应
3××:重定响应
4××:客户端错误
5××:服务器端错误
500 内部服务器错误
404 错误请求,
因发送的请求语法错误,服务器无法正常读取。
403 禁止访问
客户端没有权利访问所请求内容,服务器拒绝本次请求。
(状态码403通常代表客户端错误,是指的服务器端有能力处理该请求,但是拒绝授权访问。这个状态码类似于401,但是进入该状态后不能再继续进行验证,该访问是长期禁止的,并且与应用逻辑密切相关,比如密码不正确等。)
400 错误请求
因发送的请求语法错误,服务器无法正常读取。
(一般会因为前端提交数据的字段名称,或者是字段类型和后台的实体类不一致,导致无法封装。)
401 Unauthorized 未经授权
需要身份验证后才能获取所请求的内容,类似于403错误.不同点是.401错误后,只要正确输入帐号密码,验证即可通过。
200 请求成功
PUT
和 DELETE
的请求成功通常并不是响应200OK
的状态码而是 204No Content
表示无内容(或者 201Created
表示一个资源首次被创建成功)。
206 部分内容
Partial Content 206 部分内容,当客户端通过使用range头字段进行文件分段下载时使用该状态码。
状态码206表示服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
301 永久重定向
Moved Permanently 301 永久移动,该状态码表示所请求的URI资源路径已经改变,新的URL会在响应的Location:头字段里找到。
尽管标准要求浏览器在收到该响应并进行重定向时不应该修改http method和body,但是有一些浏览器可能会有问题。所以最好是在应对GET
或 HEAD
方法时使用301,其他情况使用308
来替代301。
302 临时重定向
Found 302临时移动,该状态码表示所请求的URI资源路径临时改变,并且还可能继续改变.因此客户端在以后访问时还得继续使用该URI.新的URL会在响应的Location:头字段里找到。
即使规范要求浏览器在重定向时保证请求方法和请求主体不变,但并不是所有的用户代理都会遵循这一点,你依然可以看到有缺陷的软件的存在。所以推荐仅在响应 GET 或 HEAD 方法时采用 302 状态码,而在其他时候使用 307 Temporary Redirect 来替代,因为在这些场景下方法变换是明确禁止的。
502 无效网关
Bad Gateway 502 网关错误,服务器作为网关且从上游服务器获取到了一个无效的HTTP响应。
bad gateway502代表您所访问的网站出了问题,因为502 Bad Gateway 服务器作为网关或者代理时,是为了完成访问下一个服务器,但该服务器返回了非法的应答。也许是暂时的,也许是的。建议大家稍等一下再从新访问试试。
前端鉴权
- HTTP Basic Authentication
- session-cookie机制
- Token验证
- OAuth开放授权
1、HTTP Basic Authentication(基本不用)
在HTTP中,基本认证是允许http用户代理(浏览器)在请求时,提供用户名和密码的一种方式。是一种十分简单的技术,使用的是HTTP头部字段强制用户访问网络资源,而不是通过cookie、sessionId、登陆页面等非获取访问控制的手段。
很多网页浏览器都支持这个,但是很少可以在公网上使用,因为他并没有为传送凭证提供数据保护,使用简单的base64编码后直接发送,编码可逆且安全性低。还有一个缺点就是用户在打开浏览器的情况下用户无法登出,也就是无法注销你已登录。解决方法一般是服务器准备一个注销的账号,当服务器接收到的账号密码是注销账号时就会注销。
如果用户在没有验证的情况下会返回401状态码提示用户进行授权,基本上就是一种密码机制,中间可能会被截取和修改字段,所以是很不安全的机制。
2、session-cookie机制(用的少)
利用服务端的session和浏览器的cookie来实现前后端鉴权,我们知道http是一种无状态的请求,用户请求完成就会关闭。如果要维持状态就需要浏览器第一次请求的时候在服务端创建一个session,session有一个唯一的标识就是sessionId。一般生产sessionId之后经过加密(可不用加密)返回给客户端,以cookie的形式保存在浏览器中。
当下一次请求时就会在请求头中加入cookie信息,服务器取出sessionId与之前生成的sessionId比对是否一致,来判断请求是否合法。
这种方法一般用在老版本的web系统,因为信息也是存储在cookie当中,也有不安全的成分在里面,一般现在的系统也不会采用这种形式的鉴权。
3.token
我们输入用户名和密码点击登陆的时候,加入网站是以Token进行鉴权的话,会有以下的步骤产生:
- 用户名和密码请求登陆
- 服务端验证是否为数据库用户
- 成功,下发令牌Token给客户端
- 客户端以后每次请求都会带上令牌
- 服务端每次都会验证令牌
其实看起来和上一个的验证方法差不多呀,到底有哪些区别呢?
session和cookie机制是在客户端与服务端之间保持一个状态,服务端创建session对象也是需要开辟一定的内存空间来保存登陆状态的,但是利用Token的话就不会保持状态,只需比对令牌是否有效即可。
也就是说Token是不存储在服务器的,这个Token本身就保存着登陆状态,服务器根据事先定义好的规则进行解密就可以知道该Token是否合理。初次之外,我们知道不只是浏览器是代理客户端,手机APP也是,在手机上面cookie是不起作用的,那么久限制了客户端类型,Token验证就不会有这个问题。
4、OAuth开放授权
这种方法用的是最多的,我们常见的一些网站比如CSDN、掘金等都可以利用微信和QQ进行登陆的,无须使用其他的用户名和密码。这种方式就可以省略了很多步骤,使得用户体验良好。
那么它是怎么操作的呢?
- 向用户请求授权
- 用户授权,返回凭证code给第三方(CSDN/掘金)
- 利用code向授权服务器请求Access Token
- 返回Access Token
- 利用Access Token向资源服务器请求用户资源
- 获取用户资源,登陆成功
5.说说https的内在原理,ssl握手过程
先验知识
1、对称加密
有流式、分组两种,加密和解密都是使用的同一个密钥。
例如:DES、AES-GCM、ChaCha20-Poly1305等
2、非对称加密
加密使用的密钥和解密使用的密钥是不相同的,分别称为:公钥、私钥,公钥和算法都是公开的,私钥是保密的。非对称加密算法性能较低,但是安全性超强,由于其加密特性,非对称加密算法能加密的数据长度也是有限的。
例如:RSA、DSA、ECDSA、 DH、ECDHE
3、哈希算法
将任意长度的信息转换为较短的固定长度的值,通常其长度要比信息小得多,且算法不可逆。
例如:MD5、SHA-1、SHA-2、SHA-256 等
4、数字签名
签名就是在信息的后面再加上一段内容(信息经过hash后的值),可以证明信息没有被修改过。hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。
具体过程
1、获取公钥
(1)提供一个下载公钥的地址,回话前让客户端去下载。(缺点:下载地址有可能是假的;客户端每次在回话前都先去下载公钥也很麻烦)
(2)回话开始时,服务器把公钥发给客户端(缺点:黑客冒充服务器,发送给客户端假的公钥)
2、那有木有一种方式既可以安全的获取公钥,又能防止黑客冒充呢? 那就需要用到终极武器了:SSL 证书(申购)
如上图所示,在第 ② 步时服务器发送了一个SSL证书给客户端,SSL 证书中包含的具体内容有:
(1)证书的发布机构CA
(2)证书的有效期
(3)公钥
(4)证书所有者
(5)签名
………
3、客户端在接受到服务端发来的SSL证书时,会对证书的真伪进行校验,以浏览器为例说明如下:
(1)首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验
(2)浏览器开始查找操作系统中已内置的受信任的证书发布机构CA,与服务器发来的证书中的颁发者CA比对,用于校验证书是否为合法机构颁发
(3)如果找不到,浏览器就会报错,说明服务器发来的证书是不可信任的。
(4)如果找到,那么浏览器就会从操作系统中取出 颁发者CA 的公钥,然后对服务器发来的证书里面的签名进行解密
(5)浏览器使用相同的hash算法计算出服务器发来的证书的hash值,将这个计算的hash值与证书中签名做对比
(6)对比结果一致,则证明服务器发来的证书合法,没有被冒充
(7)此时浏览器就可以读取证书中的公钥,用于后续加密了
4、所以通过发送SSL证书的形式,既解决了公钥获取问题,又解决了黑客冒充问题,一箭双雕,HTTPS加密过程也就此形成
所以相比HTTP,HTTPS 传输更加安全
(1) 所有信息都是加密传播,黑客无法窃听。
(2) 具有校验机制,一旦被篡改,通信双方会立刻发现。
(3) 配备身份证书,防止身份被冒充。
6.为什么要用非对称密钥,pms呢?公钥怎么了?
1)对称加密:两边需要使用相同的密钥,需要使用一种安全的方式交换密钥,单纯使用对称加密,无法实现密钥交换。
2)非对称加密:只使用非对称加密是可以满足安全性要求的,但是由于非对称加密的计算耗时高于对称加密的2-3个数量级(相同安全加密级别),所以才先使用非对称交换密钥,之后再使用对称加密通信。
先补充说明一下SSL握手过程(算法列表,完整性鉴别,不重数…等细节略):
客户端获取证书取得服务器公钥仅仅只是一个开始,之后客户端利用这个公钥发送给服务器一个PMS(Pre-Master Secret 前主密钥),双方共享了这个PMS之后利用特定的算法导出这次会话所要使用的对称密钥,然后这次对话的数据全都用这个对称密钥加密(非对称加密的计算开销太大,不能大量使用)
是否每次HTTPS请求都要进行SSL握手?
并不是。SSL是逻辑上独立于运输层的,并且是面向连接的,所以不管进行几次https请求,也不管tcp连接有没有更新,只要客户和服务器的SSL连接没有终止并且双方没有丢失这段SSL连接的识别号,客户和服务器之间就可以一直使用握手阶段生成的对称密钥进行应用层通信。只有重新进行SSL连接时才会再握手。
7.响应式布局
响应式布局:容器大小随窗口大小而变化,一套界面代码对应多种屏幕。
自适应布局:容器大小不随窗口大小而变化,边距随窗口大小而变化。
优点:
智能响应式设计为客户提供了更高的浏览体验。
响应式网站建设比传统网站更适合SEO排名。
可以通过一个网站访问多个终端,从而降低了开发成本。
响应式网页原理解析
@media 媒体查询就是根据不同设备给予不同的样式,我们用这个css3中的语句就可以设计我们网站的样式了
这里我们还需要了解下“em”这样一个值,我们平时设计网页大小的时候都是使用的px(这样一个相对于屏幕大小的长度单位),而“em” 这个单位是相对于我们浏览器大小的尺寸单位,因为任意未调整浏览器默认字体高度都是16px,所以我们可以认为1em=16px.
响应式网站=媒体查询+弹性图片
@media 媒体查询就是根据不同设备给予不同的样式,我们用这个css3中的语句就可以设计我们网站的样式了
这里我们还需要了解下“em”这样一个值,我们平时设计网页大小的时候都是使用的px(这样一个相对于屏幕大小的长度单位),而“em” 这个单位是相对于我们浏览器大小的尺寸单位,因为任意未调整浏览器默认字体高度都是16px,所以我们可以认为1em=16px.
那么我们知道em这个单位到底有什么用处呢?
先不要着急我们再来了解下rem这个单位,em是根据浏览器来进行大小评定的单位,而在支持rem的浏览器中,rem是根据HTML标签来进行定位的,他的参考是HTML的根元素。
1、IE9/IE10在用于伪元素时或者使用字体简写声明时不支持rem;
2、IOS Safari5.0-5.1虽然支持rem,但是在使用媒体查询时不支持rem。
如果你的网站面向是IE用户那么还是少量考虑rem了吧。
知道了em和rem那么我是不是就可以通过监控这两个单位表示的数给予不同设备,不同的样式了能?那么我简单写了下面一些内容
1 | @media only screen and (max-width: 50em) { |
通过上面一段简单的代码我们就可以对我们不同分辨率下网站的显示出来效果做不同的调整,更好的突出我们想展现的页面元素,尤其在移动设备上突出一些我们更想让用户看到的元素,减少我们一些表示意义并不大的元素。
接下来解决一个我们想让在不同设备上都显示出来我们的高清图片这样一个问题,我们把它叫做弹性图片,这就要牵扯到h5的一个新的标签SOURCE,它里面有一个媒体资源类型属性media,可以设置浏览器在什么样的状态下选择什么样的图片就可以做到弹性图片了,下面是一些简单参考代码
1 | <dev class="ad"> |
8.dom树和cssom树原理
1 根据HTML构建HTML树(DOM)
2 根据CSS构建CSS树(CSSOM)
3 将两棵树合并成一颗渲染树(render tree)
4 Layout布局(文档流,盒模型,计算大小和位置)
5 Paint绘制 (把边框颜色,文字颜色,阴影等画出来)
6 Compose 合成 (根据层叠关系展示画面)
如果DOM或CSSOM被修改,您只能在执行一遍以上的步骤,以确定哪些像素需要在屏幕上进行重新渲染。
优化关键渲染路径就是指最大限度缩短执行上述第一步至第五步耗费的总时间。这样一来,就能尽快将内弄渲染到屏幕上,此外还能缩短首次渲染后屏幕刷新的时间,即为交互式内容实现更高的刷新率。
9.为什么link要在前,script标签要在后面呢?
CSS
不会阻塞 DOM
的解析,但会阻塞 DOM
渲染。
JS
阻塞 DOM
解析,但浏览器会”偷看”DOM
,预先下载相关资源。
浏览器遇到 <script>
且没有defer
或async
属性的 标签时,会触发页面渲染,因而如果前面CSS
资源尚未加载完毕时,浏览器会等待它加载完毕在执行脚本。
所以,<script>
最好放底部,<link>
最好放头部,如果头部同时有<script>
与<link>
的情况下,最好将<script>
放在<link>
10.XSS攻击
1,escapeHTML将< > & “ ‘转成字符实体
使用场景:
(1)用户在页面中录入(比如输入框)<script>alert(2);</script>
, js将该内容提交给后端保存
(2)显示时,后端将字符串返回前端;js接收到之后:
a, 使用escapeHTML,将字符串转为 <script>alert(2);</script>此时,浏览器将能正确解析,因为浏览器接收到实体字符后,转成对应的尖括号等。
b, 不使用escapeHTML,浏览器一看到<,便认为是html标签的开始,直接把刚才的字符串当脚本执行了,这就是xss漏洞。
2,unescapeHTML将字符实体转成< > & “ ‘
使用场景:
后端将已经转义后的内容显示到页面;比如<script>alert(2);</script>
js收到后:
a,前端进行unescapeHTML,则可以直接dom操作,将标签显示到页面。
b,前端没有unescapeHTML,则原样输出<script>alert(2);</script>
,但此时并没有执行。
转义字符:
提示:使用实体名而不是数字的好处是,名称易于记忆。不过坏处是,浏览器也许并不支持所有实体名称(对实体数字的支持却很好)。
除此之外,还可以限制上传文件的文件类型。
- 本文作者: Raphael_Li
- 本文链接: https://lifei-2019.github.io/interview3/
- 版权声明: 本博客所有文章除特别声明外,均采用 Apache License 2.0 许可协议。转载请注明出处!