网络与安全-网络

1: HTTP 2.0 与 HTTP 1.0  和 Http1.1的区别？Http 与 Https 的区别？

---

http1.0: （1）：每次请求都要创建连接（就是一个Request 对应一个Response）

             （2）：客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，

             （3）：使用 if-Modified-Since 和 Expires 作为是否缓存的标示

http1.1: （1）增加了keep-alive参数，告知服务器建立一个长连接（一个TCP连接上可传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟）可以发送多个request

             （ 2）：HTTP1.1支持只发送header信息（不带任何body信息），当服务器认为客户端有权限请求服务器，则会给客户端返回100，客户端收到100状态码后，才把 “请求body”  发送到服务器； 如果返回了401，客户端就不会发送 “请求body” 给服务器了，节省了宽带

              （3）：引入了更多缓存控制策略：Entity tag，If-Unmodified-Since等

http2.0: 

      HTTP2.0 ：采用二进制格式而非文本格式

      HTTP2.0 ：是完全多路复用的，而非有序并阻塞的（在一个连接即可实现并行，使用报头压缩）

          多路复用 (一个TCP连接可以并发处理多个请求：如同时发送js, css 请求) 

          有序阻塞（请求不能立即得到应答，需要等待，那就是阻塞：一个TCP连接，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次发送http请求，周而复始）

      HTTP2.0:  使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。 (http1.1不支持header数据的压缩 )

      HTTP2.0 :降低了开销，让服务器 可以主动 “推送响应”  到客户端缓存中   

http状态码解析：

状态码	类别	描述
1xx	Informational（信息状态码）	接受请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向状态码）	需要附加操作已完成请求
4xx	Client Error（客户端错误状态码）	服务器无法处理请求
5xx	Server Error（服务器错误状态码）	服务器处理请求出错

   Http 与 Https 的区别

	HTTP	HTTPS
URL	以 http:// 开头	以 https:// 开头
安全性	不安全的	安全的
端口	80	443
在 OSI 网络模型中	工作于：应用层	安全传输机制工作在：传输层
加密	无法加密数据	对传输的数据进行加密
证书	不需要	需要 CA 机构 wosign 的颁发的 SSL 证书

   参考资料：https://blog.csdn.net/ailunlee/article/details/97831912  

 2: Http 请求的整个过程

简介版本：

       1: 解析域名 -----》 2: 发起 TCP 3次握手。 -----》 3: 建立 TCP 连接后发送 http 请求

 -----》4: 服务器响应 http 请求，浏览器获取到 html 代码    -----》5: 浏览器解析 html 代码，并请求 html 代码中的资源（js，css，图片等）。 -----》6:浏览器对页面进行渲染呈现给用户

3: Http 缓存配置怎么手动设置 

     前端手动设置 http 缓存

    1:   html 页面缓存方法：静态的html页面想要设置 使用缓存  需要通过HTTP的META 设置 expires 和 cache-control

 max-age=7200： 表示当访问此网页成功后的7200秒内再次访问不会去服务器请求。直接取缓存
（如：刷新， 在地址栏回车， 后退）


 expires 设置缓存失效时间，在设置的时间节点之前缓存有效，之后缓存失效

2:  ajax 请求 设置缓存：（GET 方式请求默认走缓存，POST 方式请求默认不会从缓存中取数据）

$.ajax({
    url: '',
    type: 'GET',
    timeout : 1000, // 超时时间设置，单位毫秒
    dataType: 'json', // 返回格式 （与后台商量）
    //data: JSON.stringify({data:{status: "start"}}),
    data: {name: "xu", foo: 'bar'},
    cache: false, // 是否读取缓存, 默认是true，如果为 false，则每次都会向网站服务器请求
    headers: { 
        "Authorization":"Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJrZW4iLCJpYXQiOjE1Mzc1NTQzMDksImRhdGEiOnsidXNlcm5hbWUiOiJ4dXRvbmdiYW8iLCJpc19zdXBlcnVzZXIiOjEsImlkIjoxNywibG9naW5fdGltZSI6MTUzNzU1NDMwOX0sImV4cCI6MTUzODE1NDMwOX0.32Lys4hjjY2XRpM2r9YSmpYA798u821m_M5Tzb6wxIU",
        // 'Content-Type':"application/json; charset=utf-8" // json格式
        'Content-Type': 'application/x-www-form-urlencoded; charset=utf-8',  // formdata格式
        'Cache-Control': 'no-cache'
    },
    beforeSend:function(){
		请求前的处理
	},               
    success: function(res){
        if (res.code === 200) {}   
    },
	complete:function(){
		请求完成的处理
	},
    error: function(e) {}
});

  cache-control: no-cache ||  no-store || max-age

  no-cache: 

         表面意为“数据内容不被缓存”，而实际 数据是被缓存到本地的，只是每次请求时候直接绕过缓存这一环节直接向服务器请求最新资源，由于浏览器解释不一样。

例如：

   ie 中我们设置了 no-cache 之后，请求虽然不会直接使用缓存，但是还会用缓存数据与服务器数据进行一致性检测(也就是说还是有几率会用到缓存的),

  firefox 中则完全无视 no-cache 存在，详细解释见 no-store;

  no-store 

       指示缓存不存储此次请求的响应部分, 这个设置更加粗暴直接 禁用缓存。与 no-cache 比较来说，一个是不用缓存，一个是不存储缓存。

但是具体实现起来 浏览器之间差异却特别大，一般不会直接用该字段进行设置，不过 no-store 是为了防止恶意修改  缓存存储路径 导致信息被泄露 而设置的。

例如：毕竟有它的用处，

在 firefox 中实现缓存是：通过 缓存副本(将文件另存为) 保存到本地，直接利用 no-cache 对其是无效的，如果加上 no-store 设置的话 则可以起到与 no-cache 一样的效果;

即：cache-control: no-cache,no-store;可以确保在支持 http1.1 版本中各大浏览器回车后退刷新无缓存；

再加上 Pragma: no-cache 设置兼容版本 1.0 即可(不过为了防止 " 一致性检测" 时候的万一, 我们还是最好加上"一致性检测的内容" ，如下所示几种方式)；

 max-age

     例如 Cache-control: max-age=3；表示此次请求成功后 3 秒之内发送同样请求不会去服务器重新请求，而是使用本地缓存；

     同样我们如果设置 max-age=0 表示立即 抛弃缓存 直接发送请求到服务器 

 HTML：http-equiv 属性  和  meta 标签

 实例 每隔 30 秒刷新一次文档：

扩展知识：header

     与缓存有关的 header 我们来看看每个 header 的具体含义。

 1: Request

• Cache-Control: max-age=0 （以秒为单位）
• if-Modified-Since: Mon, 19 Nov 2012 08:38:01 GMT（ 缓存文件的最后修改时间）
• If-None-Match: "0693f67a67cc1:0" （缓存文件的 Etag 值 ）
• Cache-Control: no-cache （不使用缓存 ）
• Pragma: no-cache （不使用缓存）

2:  Response

  

• Cache-Control: public （响应被缓存公有缓存，并且在多用户间共享）
• Cache-Control: private （响应只能作为私有缓存，不能在用户之间共享）
• Cache-Control:no-cache （提醒浏览器要从服务器提取文档进行验证）
• Cache-Control: no-store （绝对禁止缓存（用于机密，敏感文件））
• Cache-Control: max-age=60 （60 秒之后缓存过期（相对时间））
• Date: Mon, 19 Nov 2012 08:39:00 GMT （当前 response 发送的时间）
• Expires: Mon, 19 Nov 2012 08:40:01 GMT （缓存过期的时间（绝对时间）
• Last-Modified: Mon, 19 Nov 2012 08:38:01 GMT （服务器端文件的最后修改时间）
• ETag: "20b1add7ec1cd1:0" （服务器端文件的 Etag 值）
• Referer：表示一个来源（从哪里跳转到当前页面的）

reponse 里 header 中 Referer参数作用：

  1: 用于统计该网站流量来源 ；

   2: 可以利用这个来防止盗链了（比如： 我只允许我自己的网站访问我自己的图片服务器）

      那我的域名是www.google.com，那么图片服务器每次取到Referer来判断一下是不是我自己的域名www.google.com，如果是就继续访问，不是就拦截。

  js中通过document.referrer来获取

---

4:  如何在 HTML 中开启和关闭 DNS 预读取? 

    DNS 预读取：

           概念；浏览器主动去执行 域名解析 功能。

                     当浏览网页时，浏览器对网页中的 域名解析并缓存，这样当点击 “当前页面中的连接时”  就 无需进行DNS解析，减少用户等时间，提高用户体验。

           范围： 图片， JS ，CSS  或 HTML 上的link 等 URL

    前端优化：1: 减少 DNS 请求次数；   2: 进行 DNS 预获取； 

5:  域名收敛 和 域名发散 是什么？

域名收敛：就是将静态资源放在一个域名下。减少DNS解析的开销。
域名发散：是将静态资源放在多个子域名下，就可以多线程下载，提高并行度，使客户端加载静态资源更加迅速。

域名发散：是pc端为了利用浏览器的多线程并行下载能力
域名收敛：多用于移动端，提高性能，因为dns解析是是从后向前迭代解析，
        如果域名过多，性能会下降，增加DNS的解析开销。

---

6: 什么是 Http 协议无状态协议?怎么解决 Http 协议无状态协议?

       无状态协议：对于事务处理没有记忆能力。

       缺少状态意味着：如果后续处理需要前面的信息也就是说，当客户端第一次 HTTP 请求完成以后，客户端再发送一次 HTTP 请求，HTTP 并不知道当前客户端是一个”老用户

   解决方法：可以使用 cookie 来解决 无状态的问题，Cookie 就相当于一个通行证，第一次访问的时候给客户端发送一个 Cookie，当客户端再次来的时候，拿着 Cookie(通行证)，那么服务器就知道这个是”老用户“。

7:  常见的浏览器端的存储技术有哪些 ，它们的优缺点和使用场景？

cookie

     h5 之前存储主要用 cookies，缺点是在请求头上带着数据，导致流量增加。大小限制 4k

操作方式：
document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 GMT;
path=/" // 设置 cookie 
document.cookie = "username=; expires=Thu, 01 Jan 1970
00:00:00 GMT" // 删除 cookie

 设置 cookie 的方法比较简单，其中有几个参数可以添加

  expires:  过期时间，当过了到期日期时，浏览器会自动删除该 cookie，

                  如果想删除一个 cookie只需要把它过期时间设置成过去的时间即可,

                  比如希望设置过期时间一年：new Date().getTime() + 365 _ 24 _ 60 _ 60 _ 1000

  path：可以限制 cookie 只属于某个路径下

              路径值可以是一个目录，或者是一个路径。如果 cc.com/test/index.html 建立了一个     cookie，那么在  cc.com/test/ 目录里的所有页面，以及该目录下面 任何子目录 里的页面都可以访问这个 cookie。因此在 cc.com/test/test2/test3 里的任何页面都可以访问 cc.com/test/index.html 建立的 cookie。

            若 cc.com/test/  想访问 cc.com/test/index.html 设置的 cookes，需要把 cookies 的 path 属性设置成  “/”。 在指定路径的时候，凡是来自同一服务器，URL 里有相同路径 的所有 WEB 页面都可以共享 cookies

 domain : 主机名，控制 cookie 在不同主机中访问，设置同一个域下的不同主机，

              例如：www.baidu.com 和 map.baidu.com 就是两个不同的主机名。

              默认情况下，一个主机中创建的 cookie 在另一个主机下是不能被访问的，但可以通过 domain 参数来实现对其的控制：document.cookie = "name=value;domain=.baidu.com" 这样，所有 *.baidu.com 的主机都可以访问该 cookie。

localStorage 

        以键值对(Key-Value)的方式存储，永久存储，永不失效，除非手动删除。IE8+支持，每个域名限制 5M

操作方式：
window.localStorage.username = 'hehe' // 设置 
window.localStorage.setItem('username', 'hehe') // 设置 
window.localStorage.getItem('username') // 读取 
window.localStorage.removeItem('username') // 删除 
window.localStorage.key(1) // 读取索引为 1 的值 
window.localStorage.clear() // 清除所有 可以存储数组、数字、对象等可以被序列化为字符串的内容

sessionStorage 

       区别在于 sessionStorage 在关闭页面后即被清空，而 localStorage 则会一直保存,

       刷新页面 sessionStorage 不会清除，但是打开同域新页面访问不到

3 者区别： 

1: cookie 数据始终在同源的 http 请求中携带（即使不需要），即 cookie 在浏览器和服务器间来回传递。 而 sessionStorage 和 localStorage 不会自动把数据发给服务器，仅在本地保存

2: cookie 数据还有路径（path）的概念，可以限制 cookie 只属于某个路径下。 存储大小限制不同，

•   数据不能超过 4k，同时因为每次 http 请求都会携带 cookie，所以 cookie 只适合保存很小的数据，如会话标识 ，
•   sessionStorage 和 localStorage 虽然也有存储大小的限制，但比 cookie 大得多，可以达到 5M 或更大

3:  数据有效期不同，

•     sessionStorage：仅在当前浏览器窗口关闭前有效；
•     localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；
•     cookie 只在设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭   

4: 作用域不同

•   sessionStorage 不在不同的浏览器页面中共享（即使是同一个页面）；
•   localStorage 在所有同源（域名、协议、端口相同）窗口中都是共享的；
•   cookie 也是在所有同源窗口中都是共享的。

cookie，localStorage，sessionStorage，indexDB

特性	cookie	localStorage	sessionStorage	indexDB
数据生命周期	一般由服务器生成，可以设置过期时间	除非被清理，否则一直存在	页面关闭就清理	除非被清理，否则一直存在
数据存储大小	4K	5M	5M	无限
过期时间	expires属性设置过期时间
设置作用域	domain设置域名限制作用域  path设置文件路径作用域
与服务端通信	每次都会携带在 header 中，对于请求性能影响	不参与	不参与	不参与

从上表可以看到，cookie已经不建议用于存储。如果没有大量数据存储需求的话，可以使用localStorage和sessionStorage。对于不怎么改变的数据尽量使用localStorage存储，否则可以用sessionStorage存储。

注意：安全性

      不是什么数据都适合放在 Cookie、localStorage 和 sessionStorage 中的，因为它们保存在本地容易被篡改，使用它们的时候，需要时刻注意是否有代码存在 XSS 注入的风险。所以千万不要用它们存储你系统中的敏感数据。

对于cookie，我们还需要注意安全性。

属性	作用
value	如果用于保存用户登录态，应该将该值加密，不能使用明文的用户标识
http-only	不能通过 JS 访问 Cookie，减少 XSS 攻击
secure	只能在协议为 HTTPS 的请求中携带
same-site	规定浏览器不能在跨域请求中携带 Cookie，减少 CSRF 攻击