[前端]前端面试题第二波~[http/tcp/网络篇]

 目录:

1. Cookie 是否会被覆盖，localStorage是否会被覆盖?

2. 如何保持登录状态?

3. Ajax原生

4. Jsonp的原理。怎么去读取一个script里面的数据。

5. 若是页面初始载入的时候把ajax请求返回的数据存在localStorage里面，而后每次调用的时候去localStorage里面取数，是否可行。

6. 304是什么意思？

7. 强缓存和协商缓存的命中和管理

8. http请求和响应的消息结构

9. http请求头有哪些字段

10. http响应常见状态码

11. 简述http 1.1 与 http 1.0的区别

12. 请列举三种禁止浏览器缓存的头字段, 并写出相应的设置值

13. 和客户端浏览器缓存相关的http头

14. Cookie跨域请求能不能带上

15. js异步的方法（promise，generator，async）

16. Get和post的区别

17. Post一个file的时候file放在哪的？

18. 三次握手

19. tcp/ip／http对应哪一层 七层模型

20. 浏览器中输入网址后到页面展示的过程

21. 浏览器是如何进行加载, 解析, 渲染的呢? 重点说一下浏览器渲染页面的过程?

22. cookie和session的区别

23. 同步和异步的区别

24. 浏览器发送cookie时会发送哪几个部分?

25. cookie由哪几部分组成?

26. 请描述一下 cookies，sessionStorage 和 localStorage 的区别？

27. 浏览器本地存储与服务器端存储之间的区别

28. sessionStorage和页面js数据对象的区别

29. js实现跨域

 

http和ajax等:

1. Cookie 是否会被覆盖，localStorage是否会被覆盖?

答: Cookie是能够覆盖的，若是重复写入同名的Cookie，那么将会覆盖以前的Cookie

若是要删除某个Cookie，只须要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。负数表明其余的意义。

localStorage存储在一个对象中. 有键值对

 

2. 如何保持登录状态?

答: 把登陆信息如帐号、密码等保存在Cookie中，并控制Cookie的有效期，下次访问时再验证Cookie中的登陆信息便可。

保存登陆信息有多种方案。最直接的是把用户名与密码都保持到Cookie中，下次访问时检查Cookie中的用户名与密码，与数据库比较。这是一种比较危险的选择，通常不把密码等重要信息保存到Cookie中。

还有一种方案是把密码加密后保存到Cookie中，下次访问时解密并与数据库比较。这种方案略微安全一些。若是不但愿保存密码，还能够把登陆的时间戳保存到Cookie与数据库中，到时只验证用户名与登陆时间戳就能够了。

这几种方案验证帐号时都要查询数据库。

参考: Cookie/Session机制详解 

 

3. Ajax原生

//**********第一步, 得到一个xhr对象*************

       var xmlHttpReq = null;   //声明一个空对象用来装入XMLHttpRequest

       if (window.ActiveXObject){//IE5 IE6是以ActiveXObject的方式引入XMLHttpRequest的

              xmlHttpReq = new ActiveXObject("Microsoft.XMLHTTP");

       }

       else if (window.XMLHttpRequest){//除IE5 IE6 之外的浏览器XMLHttpRequest是window的子对象

              xmlHttpReq = new XMLHttpRequest();//实例化一个XMLHttpRequest

       }

       if(xhr != null){  //若是对象实例化成功
              //设置回调函数
              xhr.onreadystatechange = function(){

                  if(xhr.readyState == 4){  //肯定响应已经成功返回
                       //200可做为成功标志, 304表示请求资源没有修改, 可直接使用浏览器缓存
                       if ((xhr.status>=200 && xhr.status < 300 ) || xhr.status == 304){
                             alert(xhr.responseText);
                        } else {
                             alert( " Request was unsuccessful: " + xhr.status);
                        }
                    }
              }

//************第二步: 启动请求.******************
              //open方法接收三个参数: 要发送的请求类型(get,post等), 请求的url和是否异步发送请求的布尔值
              xhr.open("get","test.php",true);     //调用open()方法并采用异步方式. 若是第三个参数是false, 同步执行, 则js代码会等到服务器响应以后再继续执行

//*************第三步: 发送数据*******************
              //send方法接收一个参数,即要做为请求主体发送的数据. 若是不须要经过请求主体发送数据, 则必须传入null. 由于这个参数对有些浏览器是必须的
              xhr.send(null);  //由于使用get方式提交，因此能够使用null参调用

// 若是要设置请求头部信息,必须在调用open()方法以后且调用send()方法以前调用setRequestHeader()
                                                                

• readyStatus的五个阶段
• 0：未初始化。还没有调用open()方法
• 1：启动。已经调用open()方法，还没有调用send()方法
• 2：发送。已经调用send()方法，还没有接收到响应
• 3：接收。已经接收部分响应数据。
• 4：完成。已经接收到所有响应数据，并且已经能够在客户端使用了。【通常只需检查这个阶段】
• 得到的数据在responseText或responseXML属性中, 后者须要XML解析

参考:《JavaScript》高级程序设计第21章：Ajax和Comet，jsonp

　　

4. Jsonp的原理。怎么去读取一个script里面的数据。

答: 动态添加一个<script>标签，而script标签的src属性是没有跨域的限制的。

首先在客户端注册一个callback, 而后把callback的名字传递给服务器. 服务端获得请求的数据后, 要用callback把要输出返回的内容包起来, 这样, 服务器生成的json数据就能被客户端正确接收了.

而后以js语法的方式,生成一个function, function的名字就是传递上来的参数callback方法的名字

最后将json数据直接以入参的方式, 放置到function中, 这样就生成了一段js语法的文档, 返回给客户端.

客户端浏览器, 解析script标签,. 并执行返回的js文档, 此时js文档数据做为参数, 传递到了客户端预先定义好的callback函数里.

参考: JSONP跨域的原理解析

举个栗子:

    <script type="text/javascript">
        function jsonpCallback(result) {
            alert(result.msg);
        }
    </script>
    <script type="text/javascript" src="http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback"></script>

其中jsonCallback是客户端注册的，获取跨域服务器上的JSON数据后，回调的函数。http://crossdomain.com/jsonServerResponse?jsonp=jsonpCallback 这个url是跨域服务器取JSON数据的接口，参数为回调函数的名字，返回的格式为： jsonpCallback({msg:'this is json data'}) 。如此就生成了一段js语法的文档, 传回客户端就能够调用jsonpCallBack函数了. 

因此这里也能够看到, 回调函数应当是定义在全局的?

 

5. 若是页面初始载入的时候把ajax请求返回的数据存在localStorage里面，而后每次调用的时候去localStorage里面取数，是否可行。

（直接说了不能保证数据的实时性，请求和实时性必然会有一方有所牺牲）

 

6. 304是什么意思？

答: 304表示请求资源没有修改, 能够直接使用浏览器缓存.

 

7. 强缓存和协商缓存的命中和管理

答: 

• 1）浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存若是命中，浏览器直接从本身的缓存中读取资源，不会发请求到服务器。好比某个css文件，若是浏览器在加载它所在的网页时，这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css，连请求都不会发送到网页所在服务器；
• 2）当强缓存没有命中的时候，浏览器必定会发送一个请求到服务器，经过服务器端依据资源的另一些http header验证这个资源是否命中协商缓存，若是协商缓存命中，服务器会将这个请求返回，可是不会返回这个资源的数据，而是告诉客户端能够直接从缓存中加载这个资源，因而浏览器就又会从本身的缓存中去加载这个资源；
• 3）强缓存与协商缓存的共同点是：若是命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；区别是：强缓存不发请求到服务器，协商缓存会发请求到服务器。
• 4）当协商缓存也没有命中的时候，浏览器直接从服务器加载资源数据。

 

1. 关于强缓存:

   1. 当浏览器对某个资源的请求命中了强缓存时，返回的http状态为200，在chrome的开发者工具的network里面size会显示为from cache
   2. 强缓存是利用Expires或者Cache-Control这两个http response header实现的，它们都用来表示资源在客户端缓存的有效期。
   3. Expires: 是http1.0提出的一个表示资源过时时间的header，它描述的是一个绝对时间，由服务器返回，用GMT格式的字符串表示，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，它的缓存原理是：
      1. 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Expires的header
      2. 浏览器在接收到这个资源后，会把这个资源连同全部response header一块儿缓存下来（因此缓存命中的请求返回的header并非来自服务器，而是来自以前缓存的header）；
      3. 浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，拿出它的Expires跟当前的请求时间比较，若是请求时间在Expires指定的时间以前，就能命中缓存，不然就不行。
      4. 若是缓存没有命中，浏览器直接从服务器加载资源时，Expires Header在从新加载的时候会被更新。
   4. Cache-Control:  Expires是较老的强缓存管理header，因为它是服务器返回的一个绝对时间，在服务器时间与客户端时间相差较大时，缓存管理容易出现问题，好比随意修改下客户端时间，就能影响缓存命中的结果。因此在http1.1的时候，提出了一个新的header，就是Cache-Control，这是一个相对时间，在配置缓存的时候，以秒为单位，用数值表示，如：Cache-Control:max-age=315360000，它的缓存原理是：
      1. 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Cache-Control的header
      2. 浏览器在接收到这个资源后，会把这个资源连同全部response header一块儿缓存下来；
      3. 浏览器再请求这个资源时，先从缓存中寻找，找到这个资源后，根据它第一次的请求时间和Cache-Control设定的有效期，计算出一个资源过时时间，再拿这个过时时间跟当前的请求时间比较，若是请求时间在过时时间以前，就能命中缓存，不然就不行。
      4. 若是缓存没有命中，浏览器直接从服务器加载资源时，Cache-Control Header在从新加载的时候会被更新。
   5. Cache-Control描述的是一个相对时间，在进行缓存命中的时候，都是利用客户端时间进行判断，因此相比较Expires，Cache-Control的缓存管理更有效，安全一些。
   6. 这两个header能够只启用一个，也能够同时启用，当response header中，Expires和Cache-Control同时存在时，Cache-Control优先级高于Expires

2. 关于协商缓存

   1. 当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，若是协商缓存命中，请求响应返回的http状态为304而且会显示一个Not Modified的字符串
   2. 协商缓存是利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对Header来管理的。

   3. 【Last-Modified，If-Modified-Since】的控制缓存的原理是：

      1. 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上Last-Modified的header，这个header表示这个资源在服务器上的最后修改时间

      2. 浏览器再次跟服务器请求这个资源时，在request的header上加上If-Modified-Since的header，这个header的值就是上一次请求时返回的Last-Modified的值：

      3. 服务器再次收到资源请求时，根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化，若是没有变化则返回304 Not Modified，可是不会返回资源内容；若是有变化，就正常返回资源内容。当服务器返回304 Not Modified的响应时，response header中不会再添加Last-Modified的header，由于既然资源没有变化，那么Last-Modified也就不会改变，这是服务器返回304时的response header：

      4. 浏览器收到304的响应后，就会从缓存中加载资源。

      5. 若是协商缓存没有命中，浏览器直接从服务器加载资源时，Last-Modified Header在从新加载的时候会被更新，下次请求时，If-Modified-Since会启用上次返回的Last-Modified值。

   4. 【ETag、If-None-Match】: 【Last-Modified，If-Modified-Since】都是根据服务器时间返回的header，通常来讲，在没有调整服务器时间和篡改客户端缓存的状况下，这两个header配合起来管理协商缓存是很是可靠的，可是有时候也会服务器上资源其实有变化，可是最后修改时间却没有变化的状况，而这种问题又很不容易被定位出来，而当这种状况出现的时候，就会影响协商缓存的可靠性。因此就有了另一对header来管理协商缓存，这对header就是【ETag、If-None-Match】。它们的缓存管理的方式是：

      1. 浏览器第一次跟服务器请求一个资源，服务器在返回这个资源的同时，在respone的header加上ETag的header，这个header是服务器根据当前请求的资源生成的一个惟一标识，这个惟一标识是一个字符串，只要资源有变化这个串就不一样，跟最后修改时间没有关系，因此能很好的补充Last-Modified的问题：

      2. 浏览器再次跟服务器请求这个资源时，在request的header上加上If-None-Match的header，这个header的值就是上一次请求时返回的ETag的值：

      3. 服务器再次收到资源请求时，根据浏览器传过来If-None-Match和而后再根据资源生成一个新的ETag，若是这两个值相同就说明资源没有变化，不然就是有变化；若是没有变化则返回304 Not Modified，可是不会返回资源内容；若是有变化，就正常返回资源内容。与Last-Modified不同的是，当服务器返回304 Not Modified的响应时，因为ETag从新生成过，response header中还会把这个ETag返回，即便这个ETag跟以前的没有变化

      4. 浏览器收到304的响应后，就会从缓存中加载资源。

3. 浏览器行为对缓存的影响

   1. 若是资源已经被浏览器缓存下来，在缓存失效以前，再次请求时，默认会先检查是否命中强缓存，若是强缓存命中则直接读取缓存，若是强缓存没有命中则发请求到服务器检查是否命中协商缓存，若是协商缓存命中，则告诉浏览器仍是能够从缓存读取，不然才从服务器返回最新的资源。这是默认的处理方式

   2. 如下行为可能改变缓存的默认处理方式

      1. 当ctrl+f5强制刷新网页时，直接从服务器加载，跳过强缓存和协商缓存；

      2. 当f5刷新网页时，跳过强缓存，可是会检查协商缓存；

参考:  浏览器缓存知识小结及应用by 流云诸葛

 

8. http请求和响应的消息结构:

答:

• 请求消息结构
  • 一个请求行, 若干消息头, 以及实体内容.
  • 当中的一些消息头和实体内容都是可选的, 消息头和实体内容之间要用空行隔开.
• 响应消息结构　
  • 一个状态行, 若干消息头, 以及实体内容
  • 当中的一些消息头和实体内容都是可选的, 消息头和实体内容之间要用空行隔开.
• 二者区别: 请求消息有请求行, 响应消息有状态行

实例见下一题.

 url在请求行, cookie在请求头

 

参考: HTTP请求报文解剖

 

9. http请求头有哪些字段

答:

http请求和http响应都使用头发送有关http消息的信息. 头由一系列行组成, 每行都包含名称, 而后依次是冒号, 空格, 值. 字段可按任何顺序排列. 某些头字段既能够用于请求头也能够用于响应头, 而另外一些字段只能使用其中之一.

许多请求字段都容许客户端在值部分指定多个可接收的选项, 有时甚至能够对这些选项的首选项进行排名. 多个项以逗号分隔. 例如, 客户端能够发送包含"Content-Encoding: gzip, compress"的请求头, 表示能够接受各类压缩类型. 若是服务器的响应正文使用gzip编码,其响应头中将包含"Content-Encoding: gzip".

有些字段能够在单个头中出现屡次, 例如, 头能够有多个"Warning"字段.

下表列出了http1.1头字段. 注意, 有些头字段是mime字段. mime字段在ietf文档rfc2045中进行了定义, 但也可用于http1.1协议.

通常头字段: 通常头字段可用于请求消息和响应消息

通常头字段: 可用于请求信息和响应信息

Cache-Control	指定请求和响应遵循的缓存机制. 请求消息或响应消息中设置Cache-Control并不会修改另外一个消息处理过程只能怪的缓存处理过程	"max-age=10" or "no-cache" or "no-store"
Connection	处理完此次请求后是否断开链接仍是继续保持链接	"close"  or  "Keep-Alive"
Date	表示消息发送的时间. 时间的描述格式由rfc822定义	"Tue, 11 Jul 2000 18:23:51 GMT"
Pragma	用来包含实现特殊的指令 知道"no-cache"值表示服务器必须返回一个刷新后的文档, 即便它是代理服务器并且已经有了页面的本地拷贝	"no-cache"(与设置Cache-Control: no-cache相同)
Trailer		"Date"
Transfer-Encoding		"chuncked"
Upgrade	向服务器指定某种传输协议以便服务器进行转换(若是支持)	"SHTTP/1.3"
Via	通知中间网关或代理服务器地址, 通讯协议	"HTTP/1.1 Proxy1, HTTP/1.1 Proxy2"
Warning	关于实体消息的警告细心	"112 Disconnected Operation"

请求字段头:

请求消息的第一行格式为:

Method SP Request-URI SP HTTP-Version CRLF

• Method表示对Request-URI完成的方法, 这个字段是大小写敏感的, 包括 OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE
  • GET方法取回Request-URI标识的信息,
  • HEAD方法也是取回由Request-URI标识的信息, 只是能够在响应时不返回消息体,
  • POST方法能够请求服务器接收包含在请求中的实体消息, 能够用于提交表单, 向新闻组, BBS, 邮件群组和数据库发送消息.
• SP表示空格
• Request-URI遵循URI格式,在此字段为*时, 说明请求并不用于某个特定的资源地址, 而是用于服务器自己.
• HTTP-Version表示支持的http版本, 例如HTTP/1.1
• CRLF表示换行符

请求头域: 容许客户端向服务器传递关于请求或者关于客户机的附加信息.

请求字段头: 请求字段仅用于请求消息

Accept	浏览器可以处理的内容类型.	"text/html, iamge/*"
Accept-Charset	告诉服务器, 客户端采用的编码格式/字符集	"iso8859-5"
Accept-Encoding	告诉服务器, 客户机支持的数据压缩格式	"gzip, compress"
Accept-Language	客户机的语言环境	"en, fr"
Authorization	受权信息., 一般出如今对服务器发送的WWW-Authenticate头的应答中	[credentials]
Content-Encoding		"gzip"
Expect		"100-continue"
From	请求发送者的email地址, 由一些特殊的web客户程序使用, 浏览器不会用到	"user@microsoft.com"
Host	客户机想访问的主机名. 即指定资源的internet主机和端口号. 必须表示请求url的原始服务器或网关的位置, http/1.1 请求必须包含主机头域, 不然系统会以400状态码返回	"www.microsoft.com"
If-Match		"entity_tag001"
If-Modified-Since	资源的缓存时间. 只有当所请求的内容在指定的日期以后又通过修改才返回它, 不然返回304 "Not Modified" 应答	"Tue, 11 Jul 2000 18:12:12 GMT"
If-None=Match		"entity_tag001"
If-Range		"entity_tag001" or "Tue, 11 Jul 2000 18:12:12 GMT"
If-Unmodified-Since		"Tue, 11 Jul 2000 18:12:12 GMT"
Max-Forwards		"3"
Proxy-Authorization		[credentials]
Range	请求实体的一个或者多个子范围. 如示例即表示请求100-599个字节. 可是服务器能够忽略此请求头, 若是无条件get包含range请求头, 响应会以状态码206返回而不是200	"bytes=100-599"
Referer	告诉服务器, 客户端是从哪一个资源来访问服务器的(防盗链)	"http://www.microsoft.com/resources.asp"
TE	客户端愿意接受的传输编码, 并通知服务器接受接受尾加头信息	"trailers"
User-Agent	客户机的软件环境, 浏览器类型	"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)"

 

响应头字段:

响应消息的第一行为下面的格式

HTTP-Version SP Status-Code SP Reason-Phrase CRLF

　　

响应头字段: 响应头字段用于响应信息

Accecpt-Ranges	表面服务器是否支持指定范围请求及哪一种类型的分段请求	"none"
Age	从原始服务器到代理缓存造成的估算时间(以秒记, 非负)	"2147483645(2^31)"
ETag	缓存相关的头	"b38b9-17dd-367c5dcd"
Last-Modified	请求资源的最后修改时间	"Tue, 11 Jul 2000 18:23:51 GMT"
Location	配合302状态码使用, 用于告诉客户找谁	"http://localhost/redirecttarget.asp"
Proxy-Authenticate	指出认证方案和可应用到代理的该url上的参数	[challenge] Proxy-Authenticate: Basic
Retry-After		"Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server	服务器经过这个告诉浏览器数据的服务器的类型	"Microsoft-IIS/5.0"
Vary		"Date"
WWW-Authenticate		[challenge]

实体头字段

请求消息和响应消息均可以包含实体信息. 实体信息通常是由实体头域和实体组成. 实体头域包含关于实体的原信息.实体能够是一个通过编码的字节流. 其编码方式由Content-Encoding和content-Type定义. 长度由Content-Length或Content-Range定义.

实体头字段:实体头字段能够用于请求消息或响应消息. 实体头字段中包含消息实体正文的有关信息, 如使用的编码格式

Allow		"GET, HEAD"
Content-Encoding	数据的压缩格式	"gzip"
Content-Language		"en"
Content-Length	请求消息正文的长度	"8445"
Content-Location		"http://localhost/page.asp"
Content-MD5		[md5-digest]
Content-Range	用于指定整个实体中的一部分的插入位置, 也指示了整个实体的长度. 在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度	"bytes 2543-4532/7898"
Content-Type	数据的类型. 指定head方法送到接收方的实体介质类型, 或get方法发送的请求介质类型Content-Range实体头	"text/html"
Expires	告诉浏览器把回送的资源缓存多长时间 -1或0则是不缓存.  即应该在何时认为文档已通过期, 从而再也不缓存它	"Tue, 11 Jul 2000 18:12:12 GMT"
Last-Modified	当前资源的最后缓存时间. 即服务器上保存内容的最后修订时间. 客户能够经过If-Modified-Since请求头提供一个日期, 该请求将被视为一个条件get, 只有改动时间迟于指定时间的文档才会返回, 不然返回一个304(Not Modified)状态	"Tue, 11 Jul 2000 18:12:12 GMT"

实体内容:

表明服务器向客户端回送的数据

请求头实例:

GET /articles/news/today.asp HTTP/1.1
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer: http://localhost/links.asp
User-Agent: Mozilla/4.0 (compatible; MSIE 3.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate

 

该请求具备请求行, 其中包括方法(GET), 资源路径(/articles/news/today.asp)和http版本(http/1.1). 因为该请求没有正文, 故全部请求行后面的内容都是头的一部分. 紧接着头以后是一个空行, 表示头已结束.

响应头实例

Web服务器能够经过多种方式响应前一个请求, 假设文件是能够访问的, 而且用户具备查看该文件的权限, 则响应相似于:

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 13 Jul 2000 05:34:32 GMT
Content-Length: 2291
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQGGGNCG=LKLDFFKCINFLDMFHCBCBMFLJ; path=/
Cache-control: private

<HTML>
<BODY>
...

 

响应的第一行称为状态行. 它包含响应所用的http版本, 状态编码(200)和缘由短语. 示例中包含一个头, 其中具备五个字段, 接着是一个空行(回车和换行符), 而后是响应正文的头两行.

参考: HTTP头参考  HTTP协议---HTTP请求中的经常使用请求字段和HTTP的响应状态码及响应头  HTTP头字段  

HTTP响应头和请求头信息对照表

请求头与请求体

 

10. http响应常见状态码

• 100-199 : 表示成功接收请求, 要求客户端继续提交下一次请求才能完成整个处理过程
• 200-299: 表示成果接收请求并已完成整个处理过程. 经常使用200
• 300-399: 为完成请求, 客户需进一步细化需求: 例如: 请求的资源已经移动一个新地址, 经常使用302(重定向), 307和304(拿缓存)
• 400-499: 客户端的请求有错误, 包含语法错误或者不能正确执行. 经常使用404(请求的资源在web服务器中没有) 403(服务器拒绝访问, 权限不够)
• 500-599: 服务器端出现错误

 

经常使用:

• 200 　　 正常　　 表示一切正常, 返回的是正常请求结果
• 302/307　　临时重定向　　指出请求的文档已被临时移动到别处, 此文档的新的url在location响应头中给出
• 304　　未修改　　表示客户机缓存的版本是最新的, 客户机应该继续使用它
• 403　　禁止　　服务器理解客户端请求, 但拒绝处理它, 一般用于服务器上文件或目录的权限设置所致
• 404　　找不到　　服务器上不存在客户机所请求的资源
• 500　　服务器内部错误　　服务器端的cgi, asp, jsp等程序发生错误

 

11. 简述http 1.1 与 http 1.0的区别

答:

• http 1.0 对于每一个链接都得创建一次链接, 一次只能传送一个请求和响应, 请求就会关闭, http1.0没有Host字段
• 而http1.1 在同一个链接中能够传送多个请求和响应, 多个请求能够重叠和同时进行, http1.1必须有host字段
• http1.1中引入了ETag头, 它的值entity tag能够用来惟一的描述一个资源. 请求消息中能够使用If-None-Match头域来匹配资源的entitytag是否有变化 
• http1.1 新增了Cache-Control头域(消息请求和响应请求均可以使用), 它支持一个可扩展的指令子集
• http1.0中只定义了16个状态响应码, 对错误或警告的提示不够具体. http1.1引入了一个Warning头域, 增长对错误或警告信息的描述. 且新增了24个状态响应码

参考: HTTP/1.1 与 HTTP/1.0的区别

　　

12. 请列举三种禁止浏览器缓存的头字段, 并写出相应的设置值

答:

1. Expires: 告诉浏览器把回送的资源缓存多长时间  -1或0则是不缓存
2. Cache-Control: no-cache
3. Pragma: no-cache

 

13.  和客户端浏览器缓存相关的http头

• Expires: +过时时间

  • 表示在指定时间后浏览器缓存失效
  • 这里的过时时间必须是http格式的日期时间, 其余都会被解析成当前时间"以前", 缓存会立刻过时. http的日期时间必须是格林威治时间(GMT), 而不是本地时间
  • e.g.  Fri, 30 Oct 2009 13:13:13
  • 使用Expires过时必需要求服务器的时间是正确的,不然发送的http头就会出问题, 在windows服务下能够设置时间服务器来同步时间

• Cache-control: 缓存控制

  • 控制缓存
  • 值分为:　　
    • max-age=[秒]: 执行缓存被认为是最新的最长时间. 相似于过时时间, 这个参数是基于请求时间的相对时间间隔, 而不是绝对过时时间, [秒]是一个数组, 单位是秒: 从请求时间到过时时间之间的秒数
    • s-maxage=[秒]: 相似于max-age属性, 除了他应用于共享(如: 代理服务器)换粗
    • public: 仅体如今响应头. 通知浏览器能够无条件地缓存该响应.  标记认证内容也能够被缓存. 通常来讲, 通过http认证才能访问的内容, 输出是自动不能够缓存的
    • private: 仅体如今响应头, 通知浏览器只针对单个用户缓存响应, 且能够具体指定某个字段, 如private-"username"
    • no-cache: 强制每次请求之间发送给源服务器, 而不通过本地缓存版本的校验. 这对于须要确认认证应用颇有用(能够和public结合使用), 或者严格要求使用最新数据的应用(不惜牺牲使用缓存的全部好处)
      • 请求头中: 告诉浏览器回去服务器取数据, 并验证你的缓存(若是有的话)
      • 响应头中: 告诉浏览器, 必定要回服务器校验, 无论有没有缓存数据. 若是肯定没有修改, 能够使用缓存中的数据
    • no-store: 告诉浏览器任何状况下都不要被缓存
    • must-revalidate: 告诉浏览器必须遵循全部你给予副本的新鲜度的, http容许缓存在某些特定状况下返回过时数据, 指定了这个属性, 你告诉缓存, 你但愿严格的遵循你的规则
    • proxy-revalidate: 和must0revalidate相似, 除了他只对缓存代理服务器起做用
  • e.g.  Cache-Control: max-age=3600, must-revalidate

• Last-Modifield / If-Modified-Since(/If-Unmodified-Since)

  • 一对
    • Last-Modified表示某个地址的最近更新时间, 是服务器端响应给客户端的
    • If-(Un)Modified-Since是客户端浏览器发送给服务器的, 告诉web服务器客户端有一个最后更改时间为何时间的缓存, 服务器接收到If-Modified-Since头后则判断客户端缓存的这份url地址的缓存是不是最新的, 若是是最新的则服务器直接给客户端返回HttpStatus 304, 若是服务器发现url的最后更新时间比If-Modified-Since的值要新, 则会输出新的内容

• ETag/If-None-Match

  • ETag和Last-Modified相似, 不过他发送的是一个字符串来标识url的版本, 若是url变了则此标识也跟着变化, 在浏览器发送If\-Modified-Match时告诉浏览器内容已经变了, 或者没变能够使用缓存
  • list会自动给静态文件加上Etag, 在文件发生改变时从新生成一个ETag, 这样对于一个网站中的n多个静态文件, 如样式表, 小图片等, 客户端只须要下载一次就够了, 能够减轻负载

• Pragma: no-cache　

  • 是http1.0中的常规头, 做用同http1.1的Cache-Control: no-cache

关于以上缓存机制的优先级:

Cache-Control > Expires : 前者设置更详细

Cache-Control/Expires > Last-Modified/ETag : 本地副本根据Cache-Control/Expires还在有效期内, 则不会在此发送请求去服务器询问修改时间或实体标识了 

即最前面的最重要, 前面的生效后, 后面的基本就失效了

ETag默认是须要要源网站确认的, 由于要确认是否匹配. 而Last-Modified默认是不向源服务器确认的

在大型多web集群时, 使用ETag有问题. 由于多服务器时INode不同, 因此不一样的服务器生成的ETag不同, 因此用户有可能重复下载(这时ETag就会不许).

若是服务器端同时设置了ETag和Expires时, ETag原理一样, 即与Last-Modified/ETag对应的HttpRequest Header: If-Modified-Since和If-None-Match. 则在彻底匹配If-Modified-Since和If-None-Match即检查完修改时间和ETag后, 服务器才能返回304;

若是服务器又设置了Cache-Control:max-age和Expires时, 也是同时使用.(究竟是同时使用仍是如上所述前者大于后者?)

通常状况下, 使用Cache-Control/ Expires 会配合Last-Modified/ETag一块儿使用, 由于即便在服务器设置缓存时间, 当用户点击"刷新"按钮时, 浏览器会忽略缓存继续向服务器发送请求, 这是后者就能够很好利用304, 从而减小响应开销

ETag是服务器自动生成或者或者由开发者生成的对应资源在服务器端的惟一标识符, 可以更加准确的控制缓存. Last-Modified和ETag是能够一块儿使用的, 服务器会优先验证ETag, 一致的状况下, 才会继续比对Last-Modified, 最后才决定返回304.

用户操做和缓存的关系

用户操做	Cache-Control/Expires	Last-Modified/ETag
地址栏回车	有效	有效
页面连接调整	有效	有效
新开窗口	有效	有效
前进后退	有效	有效
F5刷新	无效	有效
Ctrl+F5	无效	无效

 

参考: 有关客户端浏览器缓存的Http头介绍   HTTP缓存相关的概念 http请求头信息 http响应头信息   expires与etag控制页面缓存的优先级

 

14. Cookie跨域请求能不能带上

 

15. js异步的方法（promise，generator，async）

答:

js语言的执行环境是单线程, 一次只能完成一个任务, 若是有多个任务则须要排队. 因而, js将任务的执行模式分为两种: 同步(Sychronous)和异步(Asynchronous).同步就是后一段等前一个任务执行结束再执行, 异步模式则是: 每个任务有一个回调函数, 前一个任务结束后, 不是执行后一个任务,而是执行回调函数, 后一个任务则是不等前一个任务执行完毕就执行, 因此程序的执行顺序与任务的排序顺序是不一致的, 异步的.

异步的方法:

1. 回调函数
2. 事件监听: 采用事件驱动模式, 任务的执行不取决于代码的顺序, 而取决于某个事件是否发生. 
3. 观察者模式
4. promise对象: 每个异步任务返回一个promise对象, 该对象有一个then方法, 容许指定回调函数, 

 

16. Get和post的区别

答:

• get请求通常用于向服务器查询某些信息, post请求一般用于向服务器发送应该被保存的数据. 即: get是从服务器上获取数据，post是向服务器传送数据
• get请求能够将查询字符串参数追加到url的末尾; post请求应该把数据做为请求的主体提交. 其请求主体能够包含很是多的数据, 并且格式不限
• 由于get请求提交的数据直接加载url末尾,因此其大小有限制; 理论来说, post是没有大小限制的. 
• post安全性比get要高
• 对于get方式, 服务器端用Request.QueryString获取变量的值, 对于post方式, 服务器端用Request.Form获取提交的数据

　　

• get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中能够看到。post是经过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一块儿传送到ACTION属性所指的URL地址。用户看不到这个过程
• get形式的url对搜索引擎更加友好，能够提升搜索引擎排名。Post使用的url有时候会阻止爬虫和搜索引擎的访问。其余网站和用户能够连接到get形式的url，不管用户的访问，仍是搜索引擎的收录而相应提升了页面排名，可以直接或间接提升网站浏览。同时，get形式的url这种表示法是能够缓存的，显著提高了客户端和服务端的性能。
• 而不安全操做，如肯定订购、下订单、达成协议和删除页面等，应该经过post执行，避免没有显式用户请求和同一的状况下发生意外的操做。例如搜索引擎删除整个页面，只由于抓取了一个连接。不少不但愿用户浏览器遵循页面连接的各类完整，这些状况下，应该要求用户登陆而且足够的权限才能执行某些危险操做。

　　

• 若符合下列任一状况，则用POST方法：
  • * 请求的结果有持续性的反作用，例如，数据库内添加新的数据行。
  • * 若使用GET方法，则表单上收集的数据可能让URL过长。
  • * 要传送的数据不是采用7位的ASCII编码。
• 若符合下列任一状况，则用GET方法：
  • * 请求是为了查找资源，HTML表单数据仅用来帮助搜索。
  • * 请求结果无持续性的反作用。
  • * 收集的数据及HTML表单内的输入字段名称的总长不超过1024个字符。

 

17. Post一个file的时候file放在哪的？

答: 应该是请求实体吧

 

18. 三次握手

答: 创建TCP链接须要三次握手, 而断开链接须要执行四次挥手.

• 三次握手: 首先Client端发送链接请求报文，Server段接受链接后回复ACK报文，并为此次链接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文，并分配资源，这样TCP链接就创建了。
  • 第一步: 客户机的TCP先向服务器的TCP发送一个链接请求报文. 这个特殊的报文中不含应用层数据, 其首部中的SYN标志位被置1. 另外, 客户机会随机选择一个起始序号seq=x(链接请求报文不携带数据,但要消耗掉一个序号)
  • 第二步: 服务器端的TCP收到链接请求报文后, 若赞成创建链接, 就向客户机发送请求, 并为该TCP链接分配TCP缓存和变量. 在确认报文中,SYN和ACK位都被置为1, 确认号字段的值为x+1, 而且服务器随机产生起始序号seq=y(确认报文不携带数据, 但也要消耗掉一个序号). 确认报文一样不包含应用层数据.
  • 第三步: 当客户机收到确认报文后, 还要向服务器给出确认, 而且也要给该链接分配缓存和变量. 这个报文的ACK标志位被置为1, 序号字段为x+1, 确认号字段为y+1
• 四次挥手
  • 第一步: 客户机打算关闭链接,就向其TCP发送一个链接释放报文,并中止再发送数据,主动关闭TCP链接, 该报文的FIN标志位被置1, seq=u, 它等于前面已经传送过的数据的最后一个字节的序号加1(FIN报文即便不携带数据,也要消耗掉一个序号)
  • 第二步: 服务器接收链接释放报文后即发出确认, 确认号是ack=u+1, 这个报文本身的序号是v, 等于它前面已传送过的数据的最后一个本身的序号加1. 此时, 从客户机到服务器这个方向的链接就释放了, TCP链接处于半关闭状态. 但服务器若发送数据, 客户机仍要接收, 即从服务器到客户机的链接仍未关闭.
  • 第三步: 若服务器已经没有了要向客户机发送的数据, 就通知TCP释放链接, 此时其发出FIN=1的链接释放报文
  • 第四步: 客户机收到链接释放报文后, 必须发出确认. 在确认报文中, ACK字段被置为1, 确认号ack=w+1, 序号seq=u+1. 此时, TCP链接尚未释放掉, 必须通过等待计时器设置的时间2MSL后, A才进入到链接关闭状态.

 

19. tcp/ip／http对应哪一层 七层模型

• TCP/IP 四层协议: 应用层、传输层、网络互连层和主机到网络层. http对应应用层
• ISO 七层模型: 物理层, 数据链路层, 网络层, 传输层, 会话层, 表示层, 应用层.  http对应应用层

 

20. 浏览器中输入网址后到页面展示的过程

　　1）用户输入网址

　　2）浏览器经过DNS获取网站的IP地址。客户端先检查本地是否有对应的IP地址，若找到则返回响应的IP地址。若没找到则请求上级DNS服务器，直至找到或到根节点。

　　　　DNS查找IP地址的顺序: 浏览器缓存、系统缓存、互联网服务提供商（ISP）的DNS缓存、递归搜索（从浏览器缓存开始，若是没找到就继续往下一个找。）找到后，浏览器会得到一个IP地址。

　　3）浏览器客户端发送http请求

　　　　HTTP请求包括请求报头和请求主体两个部分，其中请求报头包含了相当重要的信息，包括请求的方法（GET / POST）、目标url、遵循的协议（http / https / ftp…），返回的信息是否须要缓存，以及客户端是否发送cookie等。

　　4）传输层TCP传输报文。TCP协议经过“三次握手”等方法保证传输的安全可靠。

　　5）网络层IP协议查询MAC地址

　　　　IP协议的做用是把TCP分割好的各类数据包传送给接收方。而要保证确实能传到接收方还须要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一对应的关系，一个网络设备的IP地址能够更换，可是MAC地址通常是固定不变的。ARP协议能够将IP地址解析成对应的MAC地址。当通讯的双方不在同一个局域网时，须要屡次中转才能到达最终的目标，在中转的过程当中须要经过下一个中转站的MAC地址来搜索下一个中转目标。

　　7）数据到达数据链路层

　　　　在找到对方的MAC地址后，就将数据发送到数据链路层传输。这时，客户端发送请求的阶段结束

　　8）服务器接收数据

　　　　 接收端的服务器在链路层接收到数据包，再层层向上直到应用层。这过程当中包括在运输层经过TCP协议将分段的数据包从新组成原来的HTTP请求报文。

　　9）服务器响应请求

　　　　服务接收到客户端发送的HTTP请求后，查找客户端请求的资源，并返回响应报文，响应报文中包括一个重要的信息——状态码。状态码由三位数字组成，其中比较常见的是200 OK表示请求成功。301表示永久重定向，即请求的资源已经永久转移到新的位置。在返回301状态码的同时，响应报文也会附带重定向的url，客户端接收到后将http请求的url作相应的改变再从新发送。404 not found 表示客户端请求的资源找不到。

　　10）服务器返回响应文件

　　　　请求成功后，服务器会返回相应的HTML文件。接下来就到了页面的渲染阶段了。

　　11） 页面渲染： 解析HTML以构建DOM树 –> 构建渲染树 –> 布局渲染树 –> 绘制渲染树。

　　　　关于页面渲染过程：

　　　　1）解析HTML代码，生成一棵DOM树

　　　　2）解析CSS文件

　　　　3）生成渲染树（受样式影响，包含不可见元素）

　　　　4）渲染树中的节点

　

　　　　DOM树是由HTML文件中的标签排列组成，渲染树是在DOM树中加入CSS或HTML中的style样式而造成。渲染树只包含须要显示在页面中的DOM元素，像<head>元素或display属性值为none的元素都不在渲染树中。

   　　　在浏览器还没接收到完整的HTML文件时，它就开始渲染页面了，在遇到外部链入的脚本标签或样式标签或图片时，会再次发送HTTP请求重复上述的步骤。在收到CSS文件后会对已经渲染的页面从新渲染，加入它们应有的样式，图片文件加载完马上显示在相应位置。在这一过程当中可能会触发页面的重绘或重排。

　　参考： 从输入URL到浏览器显示页面发生了什么

　　其余： 浏览器中输入网址后到页面展示的过程

 

21. 浏览器是如何进行加载, 解析, 渲染的呢? 重点说一下浏览器渲染页面的过程?

答:

1. 用户访问网页, DNS服务器(域名解析系统)会根据用户提供的域名查找对应的IP地址, 找到后, 系统会向对应IP地址的网络服务器发送一个http请求
2. 网络服务器解析请求, 并发送数据给数据库服务器
3. 数据库服务器将请求的资源返回给网络服务器, 网络服务器解析数据, 并生成html文件, 放入http response中, 返回给服务器.
4. 浏览器解析http response
5. 浏览器解析http response后, 须要下载html文件, 以及html文件内包含的外部引用文件, 及文件内涉及的图片或者多媒体文件

关于加载顺序:

• 当浏览器得到一个html文件, 会"自上而下"加载, 并在加载过程当中进行解析渲染. 下载和渲染是同时进行的
• 在渲染到页面的某一部分时, 其上面到全部部分都已经下载完成(并非说全部关联元素都已经下载完)
• 若是加载过程当中遇到外部css文件, 浏览器会发出一个请求, 来获取css文件. 
• 样式表在下载完成后, 将和之前下载的全部样式表一块儿进行解析, 解析完成后, 将对此前全部元素(含之前已经渲染的)从新进行渲染
• 遇到图片资源, 浏览器会发出请求获取图片资源. 这是异步请求, 并不会影响html文档进行加载,
• 当文档加载过程当中遇到js文件, html文档会挂起渲染(加载解析渲染同步)的线程, 不只要等待文档中js文件加载完毕, 还要等待解析执行完毕, 才能够恢复html文档的渲染线程. 即js的加载不能并行下载和解析
  • 缘由: js有可能会修改DOM, 好比document.write. 这意味着, 在js执行完成前, 后续全部资源的下载多是没有必要的, 这是js阻塞后续资源下载的根本缘由.
  • 因此通常将外部引用的js文件放在</body>前
• 虽然css文件的加载不影响js文件的加载,可是却影响js文件的执行, 即便js文件内只有一行代码, 也会形成阻塞　
  • 缘由: 可能会有: var width = $('#id').width(). 这意味着, 在js代码执行前, 浏览器必须保证css文件已下载和解析完成。这也是css阻塞后续js的根本缘由。
  • 办法：当js文件不须要依赖css文件时，能够将js文件放在头部css的前面。　
  • 固然除了，<link href="" />这种形式，内部<style></style>这种样式定义，在考虑阻塞时也要考虑
• js,css中若是有重定义, 后定义函数将覆盖前定义函数

　　　　　　　　

主要解析过程: 

1. 浏览器解析html源码, 建立一棵DOM树
2. 浏览器解析CSS代码, 计算出最终的样式数据
3. js解析由于文件在加载的同时也进行解析
4. 构建DOM树, 而且计算出样式数据后, 下一步就是构建一棵渲染树(rendering tree)
   1. 渲染树和DOM树有区别, DOM树彻底与html标签一一对应, 可是渲染树会忽略掉不须要渲染的元素, 好比head, display: none的元素等
   2. 一大段文本中的每一行在渲染树中都是一个独立的节点
   3. 渲染树的每个节点都存储有对应的css属性
5. 渲染树建立好, 浏览器就能够根据渲染树直接把页面绘制到屏幕上 

　　

• 1.用户输入网址（假设是个html页面，而且是第一次访问），浏览器向服务器发出请求，服务器返回html文件； 
• 2.浏览器开始载入html代码，发现＜head＞标签内有一个＜link＞标签引用外部CSS文件； 
• 3.浏览器又发出CSS文件的请求，服务器返回这个CSS文件； 
• 4.浏览器继续载入html中＜body＞部分的代码，而且CSS文件已经拿到手了，能够开始渲染页面了； 
• 5.浏览器在代码中发现一个＜img＞标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码； 
• 6.服务器返回图片文件，因为图片占用了必定面积，影响了后面段落的排布，所以浏览器须要回过头来从新渲染这部分代码； 
• 7.浏览器发现了一个包含一行Javascript代码的＜script＞标签，赶快运行它； 
• 8.Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个＜div＞ （style.display=”none”）。杯具啊，忽然就少了这么一个元素，浏览器不得不从新渲染这部分代码； 
• 9.终于等到了＜/html＞的到来，浏览器泪流满面…… 
• 10.等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下＜link＞标签的CSS路径； 
• 11.浏览器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞们，“大伙儿收拾收拾行李，咱得从新来过……”，浏览器向服务器请求了新的CSS文件，从新渲染页面。

 

　　参考: 浏览器~加载, 解析, 渲染 浏览器加载和渲染html的顺序

 

22. cookie和session的区别:

• cookie数据存放在客户的浏览器上，session数据放在服务器上。

• cookie不是很安全，别人能够分析存放在本地的COOKIE并进行COOKIE欺骗

     考虑到安全应当使用session。

• session会在必定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能

     考虑到减轻服务器性能方面，应当使用COOKIE。

• 单个cookie保存的数据不能超过4K，不少浏览器都限制一个站点最多保存20个cookie。

• 因此建议是：

     将登录信息等重要信息存放为SESSION
     其余信息若是须要保留，能够放在COOKIE中

 

23. 同步和异步的区别?

　　同步：脚本会停留并等待服务器发送回复而后再继续。提交请求->等待服务器处理->处理完毕返回，这个期间客户端浏览器不能干任何事。

　　异步：脚本容许页面继续其进程并处理可能的回复。请求经过事件触发->服务器处理（这是浏览器仍然能够做其余事情）->处理完毕

　　若要在使用ajax请求后处理发送请求返回的结果，最好使用同步请求。

 

24. 浏览器发送cookie时会发送哪几个部分?

1 2 3

HTTP/1.1 200 OK Content-type: text/html Set-Cookie: name=value; expires=失效时间; domain=域名

 

25. cookie由哪几部分组成?

　　Cookie由变量名和值组成, 其属性中既有标准的Cookie变量, 也有用户本身建立的变量,属性中变量是用"变量=值"形式来保存

　　Cookie格式以下:

　　　　Set－Cookie: NAME=VALUE；Expires=DATE；Path=PATH；Domain=DOMAIN_NAME；SECURE

　　Set－Cookie: NAME=VALUE；

　　Expires=DATE[有效终止日期]；

　　Path=PATH[Path属性定义了Web服务器上哪些路径下的页面可获取服务器设置的Cookie]；

　　Domain=DOMAIN_NAME；

　　SECURE[在Cookie中标记该变量，代表只有当浏览器和Web Server之间的通讯协议为加密认证协议时，浏览器才向服务器提交相应的Cookie。当前这种协议只有一种，即为HTTPS]

　　参考: Cookie的组成

 

26. 请描述一下 cookies，sessionStorage 和 localStorage 的区别？

答:

• cookie:
  • cookie是网站为了标示用户身份而储存在用户本地终端（Client Side）上的数据（一般通过加密）。
  • cookie数据始终在同源的http请求中携带（即便不须要），记会在浏览器和服务器间来回传递。
• sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存。
• 存储大小：
  • cookie数据大小不能超过4k。
  • sessionStorage和localStorage 虽然也有存储大小的限制，但比cookie大得多，能够达到5M或更大。
• 有期时间：
  • localStorage    存储持久数据，浏览器关闭后数据不丢失除非主动删除数据；
  • sessionStorage  数据在当前浏览器窗口关闭后自动删除。
  • cookie          设置的cookie过时时间以前一直有效，即便窗口或浏览器关闭
• 做用域不一样:
  • sessionStorage不在不一样的浏览器窗口中共享，即便是同一个页面；
  • localStorage 在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的。
• Web Storage 支持事件通知机制，能够将数据更新的通知发送给监听者。
• Web Storage 的 api 接口使用更方便。

sessionStorage 和 localStorage 是HTML5 Web Storage API 提供的，这两种方式都容许开发者使用js设置的键值对进行操做，在在从新加载不一样的页面的时候读出它们。这一点与cookie相似。能够方便的在web请求之间保存数据。有了本地数据，就能够避免数据在浏览器和服务器间没必要要地来回传递。

sessionStorage、localStorage、cookie都是在浏览器端存储的数据， 其中sessionStorage的概念很特别，引入了一个“浏览器窗口”的概念。

sessionStorage是在同源的同学口（或tab）中，始终存在的数据。也就是说只要这个浏览器窗口没有关闭，即便刷新页面或进入同源另外一页面，数据仍然存在。关闭窗口后，sessionStorage即被销毁。同时“独立”打开的不一样窗口，即便是同一页面，sessionStorage对象也是不一样的。

Web Storage 数据彻底存储在客户端, 不须要经过浏览器的请求将数据传给服务器, 所以比cookies可以存储更多的数据,大概5M左右

Web Storage带来的好处：

　　使用 local storage和session storage主要经过在js中操做这两个对象来实现，分别为window.localStorage和window.sessionStorage. 这两个对象均是Storage类的两个实例，天然也具备Storage类的属性和方法。

　　减小网络流量：一旦数据保存在本地后，就能够避免再向服务器请求数据，所以减小没必要要的数据请求，减小数据在浏览器和服务器间没必要要地来回传递。

　　快速显示数据：性能好，从本地读数据比经过网络从服务器得到数据快得多，本地数据能够即时得到。再加上网页自己也能够有缓存，所以整个页面和数据都在本地的话，能够当即显示。

　　临时存储：不少时候数据只须要在用户浏览一组页面期间使用，关闭窗口后数据就能够丢弃了，这种状况使用sessionStorage很是方便。

 

27. 浏览器本地存储与服务器端存储之间的区别

• 其实数据既能够在浏览器本地存储，也能够在服务器端存储。

• 浏览器端能够保存一些数据，须要的时候直接从本地获取，sessionStorage、localStorage和cookie都由浏览器存储在本地的数据。

• 服务器端也能够保存全部用户的全部数据，但须要的时候浏览器要向服务器请求数据。
  • 1.服务器端能够保存用户的持久数据，如数据库和云存储将用户的大量数据保存在服务器端。
  • 2.服务器端也能够保存用户的临时会话数据。服务器端的session机制，如jsp的 session 对象，数据保存在服务器上。实现上，服务器和浏览器之间仅需传递session id便可，服务器根据session id找到对应用户的session对象。会话数据仅在一段时间内有效，这个时间就是server端设置的session有效期。

• 服务器端保存全部的用户的数据，因此服务器端的开销较大，而浏览器端保存则把不一样用户须要的数据分布保存在用户各自的浏览器中。
• 浏览器端通常只用来存储小数据，而服务器能够存储大数据或小数据。
• 服务器存储数据安全一些，浏览器只适合存储通常数据。

　　

28. sessionStorage和页面js数据对象的区别

答:

• 页面中通常的 js 对象或数据的生存期是仅在当前页面有效，所以刷新页面或转到另外一页面这样的从新加载页面的状况，数据就不存在了。
• 而sessionStorage 只要同源的同学口（或tab）中，刷新页面或进入同源的不一样页面，数据始终存在。也就是说只要这个浏览器窗口没有关闭，加载新页面或从新加载，数据仍然存在。

 

29. js实现跨域

js跨域是由于同源策略致使的。解决方法有：

• 图像Ping：使用<img>标签，由于网页能够从任何网页中加载图片，而不用担忧跨域。请求数据经过字符串形式发送，而响应能够是任何内容。这种方法，1）只能发送get请求。2）浏览器没法获取响应数据。3）只适用于浏览器与服务器之间的单向通讯
• JSONP：经过动态<script>元素使用，使用时为src指定一个跨域url。有两部分：1）回调函数：响应到来时在页面中使用；2）数据：传入回调函数中的JSON数据
• 后台代理方法：将后台做为代理，每次对其它域的请求转交给本域的后台，本域的后台经过模拟http请求去访问其它域，再将返回的结果返回给前台
• 设置document.domain：只适用于主域相同子域不一样
• 使用window.name：+iframe。应用页面建立iframe，src指向数据页面；数据页面把数据附加到window.name上；应用界面监听iframe的onload事件，在此事件中设置这个iframe的src指向本地域的代理文件；获取数据后销毁iframe
• 使用html5新方法：window.postMessage(message, targetOrigin)

 

---

 

js:

1. 原生js添加class怎么添加，若是自己已经有class了，会不会覆盖，怎么保留？

参考:  

原生JS实现addClass,removeClass,toggleClass

2. 事件代理js实现　　
3. requireJS的原理是什么
4. 数组去除一个函数。用arr.splice。又问splice返回了什么？应该返回的是去除的元素。

5. commonJS和AMD。

6. 对象中key-value的value怎么再放一个对象。（直接放也能够，转成json字符串存数，读取再解析）

 

 

css控制UL LI 的样式详解(推荐)

CSS

1. CSS实现动画效果 

2. Animation还有哪些其余属性?

3. CSS实现三列布局

4. CSS实现保持长宽比1:1

参考: 

纯 CSS 实现高度与宽度成比例的效果

使用css保持必定宽高比例

5. CSS实现两个自适应等宽元素中间空10个像素

6. 浮动的原理以及如何清除浮动

7. 

=============================================================

1.css 盒模型
2.css 布局，左边定宽右边自适应。两种方法，NEC上的用负边距消除宽度，用弹性布局。而后问我有没有第三种。。。
3.冒泡和捕获，事件流哪三个阶段？除了冒泡和捕获，还有目标阶段。他们的前后顺序，先捕获，到了目标，再冒泡。（不要只记概念，要了解是干么用的）
4.实现事件代理。用jquery写了。要求写原生。子元素传递上来的应该是event.target或者e.srcElement。这个强调下IE和W3C的区别，建议写一个封装。
5.原型链。继承的两种方法。原型链继承和类继承。而后类继承只继承了实例属性，没有原型属性。原型链继承能够继承全部。而后用apply和call怎么继承原型链上的共享属性？经过空函数传值。新建一个空函数C。C实例化后C的实例属性就是空，而后用B的apply/call去继承C，至关于继承了C的实例属性。

7，闭包。简单说一个闭包的应用。而后闭包的主要做用是什么：封装！


二面：

1.css:两个块状元素上下的margin-top和margin-bottom会重叠。啥缘由？怎么解决？（应该给父类元素添加BFC）
2.js：写一个递归。就是每隔5秒调用一个自身，一共100次。

=============================================================
挖财 面 9.10（2轮技术面，1个多小时，没有HR面，没有offer。）
一面：
你对组件的理解
组件的html怎么进行管理
less和sass用过么
nodejs用过么
js的异步加载，promise的三种状态，ES7中的async用过么
js原型链的继承
静态属性怎么继承
jquery和zepto有什么区别
angular的双向绑定原理
angular和react的认识（挖财用这个两个框架，后来问了）
MVVM是什么

二面：
适配有去考虑么，retina屏幕啊？
rem是什么？em是什么？若是上一层就是根root了，em和rem等价么？


二面面试官给个人感受不好，那我面的也很消极，而后跪了瓜熟蒂落。


1.怎么获得一个页面的a标签（就说了getElementByTagName和选择器）
2.怎么在页面里放置一个很简单的图标，不能用img和background-img
（说了canvas，或者一些库有icon库，data-icon).
3.正则表达式判断url（只写了判断是不是http或者https开头）
4.怎么去除字符串先后的空格（正则匹配^\s和\s$而且替代，Jquery的$.trim，string.trim()）
5.实现页面的局部刷新

 

二、手写链表倒数第K个查找

 

四、垂直居中，多行文本垂直居中

五、原型链的解释

六、对闭包的理解，实现一个暴露内部变量，并且外部能够访问修改的函数（get和set，闭包实现）

七、{}=={}?   []==[]? null==undefined?

八、基本的数据类型

九、基本的两列自适应布局

十、unix中经常使用的命令行

 

十二、网站性能优化

1三、解释平衡二叉树，以及在数据结构中的应用（红黑树）

1四、快排的时间复杂度和空间复杂度。

一面问的基础知识不少，可是基本都答出来了，面完后有些蒙逼。

二面是一位女面试官，给的压力很大，人比较严肃，不苟言笑，后来据说二面是压力面，二面问了50分钟。

一、手写一个jQuery插件

二、在jquery方法和原型上面添加方法的区别和实现（$.extend,$.fn.extend），以及jquery对象的实现（return new jQuery.fn.init）

三、手写一个递归函数（考察arguments.callee，以及arguments的解释）

四、对前端路由的理解？先后端路由的区别？

五、介绍一下webpack和gulp，以及项目中具体的使用

六、你对es6的了解

七、解释一下vue和react，以及异同点

八、关于平衡二叉树

九、先后端分离的意义以及对前端工程化的理解

十、使用css实现一个三角形（盒模型border和css旋转，主要考察css3旋转）

十一、用promise手写ajax

十二、手写一个继承，并解释一下

1三、解释一下call函数和apply函数的做用，以及用法

二面面完后我很虚，感受本身答的不是很好，有可能挂了，可是没想到当天下午就收到了三面的通知。

三面也是一位哥哥，过程还算轻松，也面了50多分钟，不知道结果如何

一、介绍一下本身

二、你说本身抗压能力强，具体表如今哪里？

三、对前端前景的展望，之后前端会怎么发展

四、手写第一次面试没有写出来的链表问题，要求用es6写

五、平时是怎么学技术的？

六、平时大学里面时间是怎么规划的？

七、接下来有什么计划？这个学期和下个学期的计划是？

八、项目中遇到的难点，或者你学习路上的难点

九、你是经过什么方法和途径来学习前端的

十、手写一个简单遍历算法

十一、解释一下react和vue，以及区别

 

1三、对java的理解

1四、介绍node.js，而且介绍你用它作的项目

 

一、介绍本身

二、手写一个js的深克隆

三、for函数里面setTimeout异步问题

四、手写归并排序

五、介绍本身的项目

面试我一开始我就想离开了，由于面试官态度太差了，我当时就想说怪不得连百度都要把外卖卖给美团，这面试官的素质。

原本以为本身挂了，可是过两天收到了二面的通知。

 

二面是一位人很好的哥哥，问的也挺难的，也让我对外卖改观了。

 

一、实现两个数组的排序合并，我一开始先合并再排序，他不乐意，而后我用了相似插入排序的方法。

 

三、手写一个promise版的ajax

四、手写实现一个promise（不会）

五、手写实现requireJS模块实现（想了半天才想到createElement("script"），配合异步来加载，闭包导出）

六、手写实现jquery里面的insertAfter（结合nextSibling和insertBefore来实现）

七、react和vue的介绍以及异同

八、AMD和CMD，commonJS的区别

 

 

题目参考: 

互联网前端面试面经（网易/腾讯等）by 丢三落四的松鼠   

百度前端三面面经+百度外卖一二面面经（武汉）by 验证码有误