计网局部

http和https的区别

超文本传输协定http协定被用于在web浏览器和网站服务器之间传递信息，http协定以明文形式发送内容，不提供任何形式的数据加密，如果攻击者截取了web浏览器和网站服务器之间的传输报文，就能够间接读懂其中的信息，因而，http协定不适宜传输一些敏感信息，比方：银行卡号，明码等领取信息。

为了解决http协定这一缺点，须要应用另一种协定：安全套字超文本传输协定https，为了数据安全https在http的根底上退出了SSL协定，SSL依附证书来验证服务器的身份，并为浏览器和服务器之间的通信加密
基本概念：

  • HTTP：是互联网上利用最为宽泛的一种网络协议，是一个客户端和服务端申请和应答的规范（TCP），用于从www服务器传输超文本到本地浏览器的传输协定，它能够使浏览器更加高效，使网络传输缩小
  • HTTPS：是以平安为指标的HTTP通道，简略讲是HTTP的平安版，即HTTP下退出SSL层，HTTPS的平安根底是SSL，因而加密的具体内容就须要SSL。
  • HTTPS：HTTPS的协定次要作用可分为两种：一种是建设一个信息安全通道，来保障数据传输的平安，另一种就是确认网站的真实性。

HTTP和HTTPS有什么区别：
HTTP协定的数据都是未加密的，也就是明文的，因而应用HTTP协定传输隐衷信息十分不平安，为了保障这些隐衷数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协定用于对HTTP协定传输的数据进行加密，从而就诞生了HTTPS。
简略来说，HTTPS协定是由SSL+HTTP协定构建的可进行加密传输，身份认证的网络协议，要比http协定平安
次要区别如下：

  1. https协定须要到ca申请证书，个别收费证书较少，因此须要肯定费用。
  2. http是超文本传输协定，信息是明文传输，https则是具备安全性的ssl加密传输协定。
  3. http和https应用的是齐全不同的连贯形式，用的端口也不一样，前者是80，后者是433。
  4. http的连贯很简略，是无状态的；https协定是由SSL+HTTP协定构建的可进行加密传输，身份认证的网络协议，比http协定平安。

HTTPS的长处：
只管HTTPS并非相对平安，把握根证书的机构，把握加密算法的组织同样能够进行中间人模式的攻打，但HTTPS仍是现行架构下最平安的解决方案，
次要有以下几个益处：

  1. 应用HTTPS协定可认证用户和服务器，确保数据发送到正确的客户机和服务器；
  2. HTTPS协定是由SSL+HTTP协定构建的可进行加密传输，身份认证的网络协议，要比HTTP协定平安，可避免数据在传输工程中不被窃取，扭转，确保数据的完整性。
  3. HTTPS是现行架构下最平安的解决方案，尽管不是相对平安，但它大幅度减少了中间人攻打的老本
  4. 谷歌曾在14.8月调整搜索引擎算法，并称“比起等同HTTP网站，采纳HTTPS加密的网站在搜寻后果中的排名将会更高”

HTTPS的毛病：

  1. HTTPS协定握手阶段比拟费时，会使页面的加载工夫缩短近50%，减少10%-20%的耗电。
  2. HTTPS连贯缓存不如HTTP高效，会减少数据开销和功耗，甚至已有的安全措施也会因而而受到影响
  3. SSL证书须要钱，性能越弱小的证书费用越高，集体网站，小网站没有必要个别不会用
  4. SSL证书通常须要绑定ip，不能在同一ip上绑定多个域名，ipv4资源不可能撑持这个耗费
  5. HTTPS协定的加密范畴也比拟无限，在黑客攻击，拒绝服务攻打，服务器劫持等方面简直起不到什么作用。最要害的SSL证书的信用链体系并不平安，特地是在某些国家能够管制ca根证书的状况下，中间人攻打一样可行。

HTTPS切换到HTTPS：

  1. 间接在url里改http-->https

  2. 举荐做http和https的兼容

    • 去掉页面链接中的http头部，这样能够主动匹配http头和https头
    • 例如：http://www,baidu.com改为//www.baidu.com
    • 用户从http的入口进入拜访页面时，页面就是http
    • 如果用户是从https的入口进入拜访页面，页面就是https的

HTTP长连贯和短连贯

HTTP协定与TCP/IP协定的关系：

  • HTTP的长连贯和短连贯实质上是TCP长连贯和短连贯。
  • HTTP属于应用层协定，在传输层应用TCP协定，
  • 在网络层应用IP协定，IP协定次要解决网络路由和寻址问题，
  • TCP协定次要解决如何在IP层之上牢靠的传递数据包，使在网络上的另一端受到发端收回的所有包，并且程序与收回程序统一。
  • TCP有牢靠，面向连贯的特点。

如何了解HTTP协定是无状态的：

  • HTTP协定是无状态的的，指的是协定对于事物解决没有记忆能力，服务器不晓得客户端是什么状态
  • 也就是说，关上一个服务器上的网页和你之前关上这个服务器上的网页之间没有任何分割。
  • HTTP是一个无状态的面向连贯的协定，无状态不代表HTTP不能放弃TCP连贯，更不能代表HTTP应用的是UDP协定（无连贯）

什么是长连贯，短连贯？

  • 在HTTP/1.0中，默认应用的是短连贯。也就是说，浏览器和服务器每进行一次HTTP操作，就建设一次连贯，但工作完结就中断连贯，如果客户端浏览器拜访的某个HTML或其余类型的WEB页中蕴含有其余的WEB资源，如JavaScript文件，图像文件，CSS文件等；当浏览器每遇到这样一个WEB资源，就会建设HTTP会话
  • 但从HTTP/1.1起，默认应用长连贯，用以放弃连贯个性，应用长连贯的HTTP协定，会在响应头有退出这行代码： Connection: keep-alive
  • 在应用长连贯的状况下，当一个网页关上实现后，客户端和服务器之间用于传输HTTP数据的TCP连贯不会敞开，如果客户端再次拜访这个服务器上的网页，会持续应用这一条已建设的连贯。keep-alive不会永恒放弃连贯，它有一个放弃工夫，能够在不同的服务器软件（如Apache）中设定这个工夫。实现长连贯要客户端和服务端都反对长连贯。
  • HTTP协定的长连贯和短连贯，本质上是TCP协定的长连贯和短连贯

TCP连贯：
当网络通信时采纳TCP协定时，在真正的读写操作之前，server与client之间必须建设一个连贯， 当读写操作实现后，单方不再须要这个连贯时，他们能够开释这个连贯，连贯的建设是须要三次握手的，而开释则须要四次挥手，所以说每个连贯的建设都是须要资源耗费和工夫耗费的。

  • TCP短连贯

    • client向server发动连贯申请，server接到申请，而后单方建设连贯
    • client向server发送音讯，server回应client，而后一次读写就实现了，
    • 这时单方任何一个都能够发动close操作，不过个别都是client先发动close操作
    • 因为个别serve不会回复完client后立刻敞开连贯的，不排除有
    • 短连贯的长处：治理起来比拟不便，存在的连贯都是有用的连贯，不须要额定的管制伎俩

  • TCP长连贯

    • client向server发动连贯申请，server接到申请，而后单方建设连贯
    • client和server实现一次读写之后，他们之间的连贯并不会被动敞开，后续的读写操作会持续应用这个连贯

说一下tcp保活性能。保活性能次要为服务器利用提供，服务器利用心愿晓得客户端主机是否解体，从而能够代表客户应用资源。如果客户曾经隐没，使得服务器上保留一个半凋谢的连贯，而服务器又在期待来自客户端的数据，则服务器将应期待客户端的数据，保活性能就是视图在服务端检测到这种半凋谢的连贯。
如果一个给定的连贯在两个小时内没有任何动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下四个状态之一：

  1. 客户主机仍然失常容许， 并从服务器可达。客户的TCP响应失常，而服务器也晓得对方是失常的，服务器在两个小时候将保活定时器复位
  2. 客户主机曾经解体，并且敞开或正在重新启动。在任何一种状况下，客户的TCP都没有响应，服务端将不能接管到对探测的响应，并在75s后超时。服务器总共发送10个这样的探测，每个距离75s。如果服务器没有收到一个响应，它就认为客户主机曾经敞开并终止连贯。
  3. 客户主机解体并曾经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连贯
  4. 客户主机失常运行，然而服务器不可达，这种状况与2相似，TCP能发现的就是没有收到探查的响应。

HTTP协定和HTTP1.0/1.1/2.0的区别

HTTP协定：

  • HTTP协定，全称超文本传输协定，属于网络结构OSI参考模型的“最上层”应用层，由申请与响应形成，是无状态的协定。
  • HTTP占用默认端口号为80，可承载在TLS和SSL之上，通过加密，认证的形式实现数据传输，即HTTPS协定，默认端口443

HTTP1.0（1996），HTTP1.1（1999）、HTTP2.0（2015）的个性与区别

  • HTTP1.1应用长连贯，无效缩小三次握手的开销
  • HTTP1.1容许只发送header信息不携带body，此时如果服务器认为客户端领有权限，就会向客户端发送状态码100，客户端接管到100后再向服务器发送body信息
  • HTTP1.0没有host域HTTP1.1才开始反对

  • HTTP1.X的致命缺点：

    • 协定规定客户端对同一域的并发连贯只能有一个，而一个页面至多须要加载40个资源
    • 线头阻塞（head of line blocking）同一个连贯中的申请，须要一个一个的手法，效率太低
    • 基于文本协定，申请与响应头信息十分大，无奈进行压缩
    • 只能单向申请，即服务端只能返回客户端的指定申请

  • HTTP2.0的特点

    • 应用了多路复用，HOPACK头压缩，流+二进制帧，流优先级技术
    • HTTP2.0应用了多路复用技术，容许同时通过繁多的HTTP/2连贯发动申请-响应信息，是解决HTTP1.X并发问题和HOLB线头问题的核心技术
  • HTTP2在原有HTTP根底上在应用层（HTTP2)和传输层（TCP/UDP)之间减少了二进制分帧层
  • HTTP2容许客户端发送申请后，服务端将所有相干文件一并返回，并退出浏览器缓存，缩小申请次数

  • HTTP2带来的益处：

    • 更小的传输体积，更小甚至省略的头音讯
    • 冲破原有的TCP连贯并发限度，应用一个TCP可实现多申请并发， 缩小了服务端的压力
    • 解决HOLB线头的问题，慢的申请或者先发送的申请不会阻塞其余申请的返回
    • 联合CDN提供的实时性更高，不会呈现先发送的申请阻塞前面的申请
    • 数据优先级可控
    • 能在不中断TCP连贯的状况下进行数据的发送

从浏览器输出URL到页面展现过程产生了什么

整个过程是由chrome架构中的各个过程之间的配合实现，所以先来认识一下这个架构：
chrome的多过程架构：

  • 浏览器过程：负责用户界面（地址栏，菜单等等）、子过程的治理（过程间通信传递）、存储等等
  • 渲染过程：负责将接管到的HTML文档和Javascript等转化为用户界面
  • 网络过程：负责网络资源的申请，http申请，websocket模块
  • GPU（图形处理器）过程：负责对UI界面的展现
  • 插件过程：负责对插件的治理

过程详解：
产生这个过程的前提，用户在地址栏中输出了URL，而地址栏会依据用户输出，做出判断：

  • 输出的是非URL构造的字符串，咋会用浏览器默认的搜索引擎搜寻该字符串
  • 输出的是 URL构造字符串，则会构建残缺的URL构造，浏览器过程会将残缺的URL通过过程间通信,即IPC，发送给网络过程

申请过程：
在网络过程承受到URL后，并不是马上对指定URL进行申请。首先，咱们须要进行DNS解析域名失去对应的IP，而后通过ARP解析IP失去对应的MAC（Media Access Control Address）地址
域名 是咱们取代记忆简单的IP的一种解决方案，而IP地址才是指标在网络中所被调配的节点。MAC地址是对应指标网卡所在的固定地址

DNS解析：

  • 询问浏览器DNS缓存
  • 询问本地操作系统DNS缓存（即查找本地host文件）
  • 询问ISP（Internet Service Provider）互联网服务提供商（例如挪动，电信）的DNS服务器
  • 询问根服务器，这个过程能够进行递归和迭代两种查找的形式，两者都是先询问顶级域名服务器查找

通信过程
首先，建设TCP连贯，即三次握手过程：

  • 客户端发送标有SYN的数据包，示意我将要发送申请
  • 服务端发送标有SYN/ACK的数据包，示意我曾经受到告诉，告知客户端发送申请
  • 客户端发送标有ACK的数据包，示意我要开始发送申请，筹备被承受

在此之后，利用TCP进行数据传输：

  • 服务端接管到数据包，并发送确认数据包已收到的音讯到客户端，一直反复这个过程
  • 客户端在发送一个数据包后，未接管到服务端的确定音讯，则从新发送该数据包，即TCP的重发机制
  • 当承受完所有的数据包后，接收端会依照TCP头中的须要进行排序，造成残缺的数据

最初，断开TCP连贯，即四次挥手过程：

  • 客户端发送申请，申请断开连接，进入期待阶段，此时不会发送数据，然而会持续承受数据
  • 服务端承受申请后，告知客户端已明确，此时服务端进入期待状态，不会再接收数据，然而会持续发送数据
  • 客户端收到后，进入下一阶段期待
  • 服务端发送完残余的数据，通知客户端能够断开连接，此时服务端不会发送和接收数据
  • 客户端收到后，告知服务端我开始断开连接
  • 服务端受到后，开始断开连接

这整个过程的客户端则是网络过程。并且，在数据传输的过程还可能会产生重定向的状况，即当网络过程接管到状态码为3xx的响应报文，则会依据响应报文首部字段中的location字段的值进行从新定向，即会从新发送申请

数据处理：
当网络过程接管到的响应报文状态码，进行相应的操作。例如状态码为200 ok 时，会解析Content-Type首部字段，例如咱们这个过程Content-Type会呈现application/javascript、text/css、text/html、即对应javascript文件、css文件、html文件

创立渲染过程：
以后须要渲染HTML时，则须要创立渲染过程，用于前期渲染HTML。而对于渲染过程，如果是同一站点是能够共享一个渲染过程，例如a.abc.com和c.abc.com能够共享一个渲染过程。否则，须要从新创立渲染过程，须要留神的是，同站指的是 顶级域名 和 二级域名相等

开始渲染：
在创立玩渲染过程后，网络过程会接管到的HTML，javascript等数据传递给渲染过程。而在渲染过程承受完数据后，此时用户界面上会产生这几件事儿

  • 更新地址栏的平安状态
  • 更新地址栏的URL
  • 后退后退此时enablle，显示正在加载状态
  • 更新网页

渲染过程：
渲染过程：是浏览器输出URL到页面渲染过程的最初一步。而页面渲染的过程能够分为9个步骤

  • 解析HTML生成DOM树
  • 解析CSS生成CSSOM
  • 加载或执行JavaScript
  • 生成渲染数（render tree）
  • 布局
  • 分层
  • 生成绘制列表
  • 光栅化
  • 显示

构建DOM树：
因为网络过程传输给渲染过程的是HTML字符串，所以，渲染过程须要将HTML字符串转化成DOM树。
须要留神的是这个DOM树不同于Chrome-devtool中Element选项卡的DOM树，它是存在在内存中的，用于提供JavaScript对DOM的操作

构建CSSOM：
构建CSSOM的过程，即通过解析css文件、style标签，行内style等，生成cssom。而这个过程会做这几件事：

  • 标准css、行将color：blue转化成color：rgb()模式，能够了解成相似ES6转ES5的过程
  • 计算元素款式，例如css款式会继承父级款式，如font-size、color之类的

加载JavaScript：
通常状况下，在构建DOM树或CSSOM的同时，如果也要加载JavaScript，则会造成前者的构建的暂停。当然，咱们能够通过 defer或sync来实现异步加载JavaScript。尽管defer和sync都能够实现异步加载JavaScript，然而前者是在加载后，期待cssom和DOM树构建完后才执行JavaScript，而后者是在异步加载完马上执行，即应用sync的形式依然会造成阻塞。
而JavaScript执行的过程，即编译和运行JavaScript的过程。因为JavaScript是解释性的语言。所以这个过程会使这样的：

  • 针对每句代码进行分行解决，即token化
  • 依据token，生成AST（Abstract Sytanx Tree）形象语法树和创立上下文
  • 解释器解析和执行AST，生成字节码
  • 编译器针对须要重复执行的代码，生成对应的机器码，进步运行效率。

生成渲染树（ Render Tree）：
在有了DOM树和CSSOM之后，须要将两者联合生成渲染树Render Tree，并且这个过程会去除掉那些display：node的节点。此时，渲染树就具备元素和元素的款式信息。

布局：
依据 Render Tree渲染树，对树中每个节点进行计算，确定每个节点在页面中的宽度，高度和地位。
须要留神的是，第一次确定节点的大小和地位的过程称为布局，而第二次才被称为回流

分层：
因为层叠上下文的存在，渲染引擎会为具备层叠上下文的元素创立对应的图层，而诸多图层的叠加就造成了咱们看到的一些页面成果。例如，一些3D的成果、动画就是基于图层而造成的
值得一提的是，对于内容溢出存在滚轮的状况也会进行分层

生成绘制列表：
对于存在图层的页面局部，须要进行有序的绘制，而对于这个过程，渲染引擎会将一个个图层绘制拆分成绘制指令，并依照图层绘制程序造成一个绘制列表。

光栅化：
有了绘制列表后，渲染引擎的合成路线会依据以后视口的大小将图层进行分块解决，而后合成线程会对视口左近的图块生成位图，即光栅化。而渲染过程也保护了一个栅格化的线程池，专门用于将图块转为位图。栅格化的过程通常会应用GPU减速，例如应用wil-change、opacity时

显示：
当所有的图块都通过栅格化处理后，渲染引擎中的合成线程会生成绘制图块的指令、提交给浏览器过程。而后聊了起来过程将页面绘制到内存中。最初将内存绘制结果显示在用户界面上
而这个整个从生成绘制列表，光栅化，显示的过程，就是咱们常说的重绘的过程

重绘（Repaint）和回流（Reflow）

回流必将引起重绘，重绘不肯定会引起回流。
重绘（Repaint）
当页面中元素款式的扭转并不影响它在文档流中的地位时（例如：color、background-color、visibility 等），浏览器会将新款式赋予给元素并从新绘制它，这个过程称为重绘。
回流（Reflow）
当 Render Tree 中局部或全副元素的尺寸、构造、或某些属性产生扭转时，浏览器从新渲染局部或全副文档的过程称为回流。
会导致回流的操作：

  • 页面首次渲染
  • 浏览器窗口大小产生扭转
  • 元素尺寸或地位产生扭转元素内容变动（文字数量或图片大小等等）
  • 元素字体大小变动
  • 增加或者删除可见的 DOM 元素
  • 激活 CSS 伪类（例如:hover）
  • 查问某些属性或调用某些办法
  • 一些罕用且会导致回流的属性和办法
    clientWidth、clientHeight、clientTop、clientLeftoffsetWidth、offsetHeight、offsetTop、offsetLeftscrollWidth、scrollHeight、scrollTop、scrollLeftscrollIntoView()、scrollIntoViewIfNeeded()、getComputedStyle()、
    getBoundingClientRect()、scrollTo()

性能影响
回流比重绘的代价要更高。
有时即便仅仅回流一个繁多的元素，它的父元素以及任何追随它的元素也会产生回流。古代浏览器会对频繁的回流或重绘操作进行优化：浏览器会保护一个队列，把所有引起回流和重绘的操作放入队列中，如果队列中的工作数量或者工夫距离达到一个阈值的，浏览器就会将队列清空，进行一次批处理，这样能够把屡次回流和重绘变成一次。
当你拜访以下属性或办法时，浏览器会立即清空队列:

clientWidth、clientHeight、clientTop、clientLeftoffsetWidth、offsetHeight、offsetTop、offsetLeftscrollWidth、scrollHeight、scrollTop、scrollLeftwidth、heightgetComputedStyle()getBoundingClientRect()

因为队列中可能会有影响到这些属性或办法返回值的操作，即便你心愿获取的信息与队列中操作引发的扭转无关，浏览器也会强行清空队列，确保你拿到的值是最准确的。

如何防止
CSS

  • 防止应用 table 布局。
  • 尽可能在 DOM 树的最末端扭转 class。
  • 防止设置多层内联款式。
  • 将动画成果利用到 position 属性为 absolute 或 fixed 的元素上。
  • 防止应用 CSS 表达式（例如：calc()）。

Javascript

  • 防止频繁操作款式，最好一次性重写 style 属性，或者将款式列表定义为 class 并一次性更改 class 属性。
  • 防止频繁操作 DOM，创立一个 documentFragment，在它下面利用所有 DOM 操作，最初再把它增加到文档中。
  • 也能够先为元素设置 display: none，操作完结后再把它显示进去。因为在 display 属性为 none 的元素上进行的 DOM 操作不会引发回流和重绘。
  • 防止频繁读取会引发回流/重绘的属性，如果的确须要屡次应用，就用一个变量缓存起来。

  • 对具备简单动画的元素应用相对定位，使它脱离文档流，否则会引起父元素及后续元素频繁回流。

    前端性能优化

    首先讲一下拿到服务端资源后浏览器渲染过程

  • 解析 HTML 文件，构建 DOM 树，同时浏览器主过程负责下载 CSS 文件
  • CSS 文件下载实现，解析 CSS 文件成树形的数据结构，而后联合 DOM 树合并成 RenderObject 树
  • 布局 RenderObject 树 （Layout/reflow），负责 RenderObject 树中的元素的尺寸，地位等计算
  • 绘制 RenderObject 树 （paint），绘制页面的像素信息
  • 浏览器主过程将默认的图层和复合图层交给 GPU 过程，GPU 过程再将各个图层合成（composite），最初显示出页面

CRP（要害渲染门路Critical Rendering Path）优化
要害渲染门路是浏览器将 HTML、CSS、JavaScript 转换为在屏幕上出现的像素内容所经验的一系列步骤。也就是咱们刚刚提到的的的浏览器渲染流程。
为尽快实现首次渲染，咱们须要最大限度减小以下三种可变因素:

  • 要害资源的数量: 可能阻止网页首次渲染的资源。
  • 要害门路长度: 获取所有要害资源所需的往返次数或总工夫。
  • 关键字节: 实现网页首次渲染所需的总字节数，等同于所有要害资源传送文件大小的总和。

优化 DOM

  • 删除不必要的代码和正文包含空格，尽量做到最小化文件。
  • 能够利用 GZIP 压缩文件。
  • 联合 HTTP 缓存文件。

优化 CSSOM
首先，DOM 和 CSSOM 通常是并行构建的，所以 CSS 加载不会阻塞 DOM 的解析。

然而，因为 Render Tree 是依赖于 DOM Tree 和 CSSOM Tree 的，
所以他必须期待到 CSSOM Tree 构建实现，也就是 CSS 资源加载实现(或者 CSS 资源加载失败)后，能力开始渲染。因而，CSS 加载会阻塞 Dom 的渲染。

由此可见，对于 CSSOM 放大、压缩以及缓存同样重要，咱们能够从这方面思考去优化。

  • 缩小要害 CSS 元素数量
  • 当咱们申明样式表时，请亲密关注媒体查问的类型，它们极大地影响了 CRP 的性能 。

优化 JavaScript
当浏览器遇到 script 标记时，会阻止解析器持续操作，直到 CSSOM 构建结束，JavaScript 才会运行并持续实现 DOM 构建过程。

  • async: 当咱们在 script 标记增加 async 属性当前，浏览器遇到这个 script 标记时会持续解析 DOM，同时脚本也不会被 CSSOM 阻止，即不会阻止 CRP。
  • defer: 与 async 的区别在于，脚本须要等到文档解析后（ DOMContentLoaded 事件前）执行，而 async 容许脚本在文档解析时位于后盾运行（两者下载的过程不会阻塞 DOM，但执行会）。
  • 当咱们的脚本不会批改 DOM 或 CSSOM 时，举荐应用 async 。
  • 预加载 —— preload & prefetch 。
  • DNS 预解析 —— dns-prefetch 。

还有一些

  • webpack模块打包和JavaScript 压缩（如gzip压缩）
  • 利用CDN
  • 按需加载资源
  • 在应用 DOM 操作库时用上 array-ids
  • 缓存优化
  • 防止重定向
  • 启用 HTTP/2
  • 利用性能剖析
  • 应用负载平衡计划
  • 为了更快的启动工夫考虑一下同构
  • 应用索引减速数据库查问
  • 应用更快的转译计划
  • 防止或最小化 JavaScript 和 CSS 的应用而阻塞渲染
  • 用于将来的一个倡议：应用 service workers + 流
  • 图片编码优化，尽量应用svg和字体图标

TCP和UDP各自的特点和区别

TCP（传输控制协议）：提供的是面向连贯，牢靠的字节流服务。即客户和服务器替换数据前，必须在单方之间建设一个TCP连贯，之后能力传输数据。而且提供超时重发，抛弃反复数据，测验数据，流量管制等性能，保证数据能从一端传到另一端。
UDP（用户数据报协定）：是一个简略的面向数据报的运输层协定。它不提供可靠性，只是报应用程序传给IP层的数据报发送进来，然而不能保障它们能达到目的地。因为UDP在传输数据前不必再客户和服务器之间建设一个连贯，且没有超时重发等机制，所以传输很快
区别：

  1. TCP是面向连贯的，UDP是无连贯的即发送数据前不须要先建设链接
  2. TCP提供牢靠的服务。也就是说，通过TCP连贯传送的数据，无差错，不失落，不反复，且按序达到；UDP尽最大致力交付，即不保障牢靠交付。并且因为TCP牢靠，面向连贯，不会失落数据因而适宜大数据量的替换。
  3. TCP是面向字节流，UDP面向报文，并且网络呈现拥塞不会使得发送速率升高（因而会呈现丢包，对实时的利用比方IP电话和视频会议等）
  4. TCP只能是1对1的，UDP反对1对1，1对多
  5. TCP的首部较大为20字节，而UDP只有8字节
  6. TCP是面向连贯的可靠性传输，而UDP是不牢靠的

前端平安XSS、CSRF进攻

XSS攻打原理：
XSS又称CSS，全称CrossSiteScript,跨站脚本攻打，是web程序中常见的破绽，XSS属于被动式且用于客户端的攻击方式，所以容易被疏忽其危害性
其攻打原理是攻击者向有XSS破绽的网站中输出歹意的HTML代码，当其余用户浏览该网站时，这段HTML代码会主动执行，从而达到攻打的目标。如，盗取用户Cookie,毁坏页面的失常构造，插入广告等歹意内容，重定向到其余网站，D-doss攻打等。XSS攻打相似于SQL注入攻打，攻打之前，咱们先找到一个存在XSS破绽的网站。实践上，所有可输出的中央没有对输出数据进行解决的话，都会存在XSS破绽，破绽的危害取决于攻打代码的威力。
XSS的攻击方式：

  • 反射型

    • 发送申请时，XSS代码呈现在url中，作为输出提交到服务器端，服务器端解析后相应，XSS代码随响应内容一起传回给浏览器，最初浏览器解析执行XSS代码。这个过程像一次反射， 所以叫反射型XSS

  • 存储型

    • 存储型XSS和反射型XSS的差异在于，提交的代码会存储在服务器端（数据库、内存、文件系统等）下次申请时指标页面时不必再提交XSS代码

XSS的防范措施（encode+过滤）：
XSS的防范措施次要有三个

  • 编码：对用户输出的数据进行HTML Entity编码。Encode的作用是将等一些字符进行转化，使得浏览器在最终输入后果上是一样的。
  • 过滤：移除用户输出的和事件相干的属性。如onerror能够主动触发攻打，还有onclick等。移除用户输出的Style节点、Script节点、Iframe节点（尤其是script节点，可反对跨域，肯定要移除）
  • 校对：防止间接对HTML Entity进行编码。应用DOM Parse转换，校对不配对的DOM标签

XSS的影响：

  • 利用虚伪输出表单骗取用户个人信息
  • 利用脚本窃取用户的Cookie值，被害者在不之情的状况下，帮忙攻击者发送歹意申请
  • 显示伪造的文章和图片

CSFR攻打原理：
CSRF（Cross-Site Request Forgery，跨站点伪造申请）：是一种网络攻击形式，该攻打能够在受害者毫不知情的状况下以受害者名义伪造申请发送给受攻打站点，从而在未受权的状况下执行在权限爱护之下的操作，具备很大的危害性。具体来讲，能够这样了解CSRF攻打：攻击者盗用了你的身份，以你的名义发送歹意申请，对服务器来说这个申请是齐全非法的，然而却实现了攻击者所冀望的一个操作，比方以你的名义发送邮件，发消息，盗取你的账号，增加系统管理员，甚至于购买商品，虚构货币转账等。
攻打原理：

  1. 用户C关上浏览器，拜访受信赖网站A，输出用户名和明码申请登录网站A
  2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A胜利，能够失常发送申请到网站A
  3. 用户未退出网站A之前，在同一浏览器，关上一个TAB页拜访网站B
  4. 网站B接管到用户申请后，返回一些攻击性代码，并收回一个申请要拜访第三方站点A;
  5. 浏览器在接管到这些攻击性代码后，依据网站B的申请，在用户不知情的状况下携带Cookie信息，向网站A发送申请。网站A并不知道该申请其实由B发动的，所以会依据用户C的Cookie信息的权限解决该申请，导致来自网站B的恶意代码被执行

用户是网站A的注册用户，且登录进去，于是网站A就给用户下发cookie
要实现顺次CSRF攻打，受害者必须满足两个必要条件：

  • 登录受信赖网站A，并在本地生成Cookie（如果用户没有登录网站A，那么网站B在诱导的时候，申请网站A的api接口时，会提醒你登录）

  • 在不登出A的状况下，拜访危险网站B（其实利用了网站A的破绽）

    • cookie保障了用户能够处于登录状态，但网站B其实拿不到cookie

CSRF的影响：

  • 利用已通过认证的用户权限更新设定信息等
  • 利用已通过认证到的用户权限购买商品
  • 利用已通过认证的用户权限在留言板上发表舆论

CSRF如何进攻：
办法一：Token验证：（用的最多）

  1. 服务器发送给客户端一个token
  2. 客户端提交的表单中带着这个token
  3. 如果这个token不非法，那么服务器回绝这个申请

办法二：暗藏令牌
把token暗藏在http的head头中
办法二和办法一有点像，实质上没有太大区别，只是应用形式上有区别
办法三：Referer验证
Referer指的是页面申请起源。意思是，只承受本站的申请，服务器才做响应，如果不是就拦挡

CSRF和XSS的区别

  • 区别一

    • CSRF：须要用户先登录网站，获取cookie
    • XSS：不须要登录

  • 区别二（原理的区别）

    • CSRF：是利用网站自身的破绽，去申请网站的api
    • XSS：是向网站注入JS代码，而后执行JS里的代码，篡改网站的内容

get 和 post区别

  1. get和post是http申请的两种根本办法，

    • GET把参数蕴含在URL中，POST通过request body传递参数
    • GET在浏览器退回时是有害的，而POST会再次提交申请
    • GET产生的URL地址能够被Bookmark，而POST不能够
    • GET申请会被浏览器被动cache，而POST不会，除非手动设置
    • GET申请之恶能进行url编码，而POST反对多种编码方式
    • GET申请参数会被残缺保留在浏览器历史记录里，而POST中的参数不会被保留
    • GET申请在URL中传送的参数是有长度限度的，而POST没有
    • 对参数的数据类型，GET只承受ASCII字符，而POST没有限度
    • GET比POST更不平安，因为参数间接裸露在URL上，所以不能用来传递敏感信息。

  2. GET和POST是HTTP协定中两种发送申请的帮扶

    • HTTP是基于TCP/IP的对于数据如何在万维网中如何通信的协定
    • HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说GET/POSTD都是TCP链接。GET和POST能做的事件是一样一样的。
    • 你要给GET加上request body ，给POST带上url参数，技术上是齐全行的通的

实质没有区别

  • 在我大万维网世界中，TCP就像汽车，咱们用TCP来运输数据，它很牢靠，从来不会产生丢件少件的景象。
  • 然而如果路上跑的全是看起来截然不同的汽车，那这个世界看起来是一团凌乱，送急件的汽车可能被后面满载货物的汽车拦堵在路上，整个交通系统肯定会瘫痪。
  • 为了防止这种状况产生，交通规则HTTP诞生了。

  • HTTP给汽车运输设定了好几个服务类型，有GET,POST,PUT,DELETE期待，

    • HTTP规定，当执行GET申请的时候，要给汽车贴上GET的标签（设置method为GET),而且要求把传送的数据放在车顶上（url中）以不便记录
    • 如果是POST申请，就要在车上贴上POST的标签，并把货物放在车厢里，
  • 当然，你也能够在GET的时候往车厢里偷偷藏点或物，然而这是很不荣耀
  • 也能够在POST的时候在车顶也放一些数据，让人感觉傻乎乎
  • HTTP只是个行为准则，而TCP才是GET和POST怎么实现的根本

大小限度的阐明

  • 在我大万维网世界中，还有另一个重要的角色：运输公司。
  • 不同的浏览器（发动http申请）和服务器（接管http申请）就是不同的运输公司
  • 尽管实践上，你能够在车顶上有限的堆货物（url中有限加参数）。
  • 然而运输公司可不傻，装货和卸货也是有很大老本的，他们会限度单次运输量来管制危险，数据量他打对浏览器和服务器都是很大累赘
  • 业界不成文的规定是：大多数浏览器通常会限度url长度在2k个字节，而大多数服务器最多解决64k大小的url
  • 超过的局部，恕不解决，
  • 如果你用GET服务，在request body 偷偷藏了数据，不同服务器的解决形式也是不同的，有的服务器会帮你卸货，读出数据，有些服务器间接疏忽，
  • 所以，尽管GET能够带request body ，也不能保障肯定被接管到
  • GET和POST实质上就是TCP链接，并无差别，然而因为HTTP的规定和浏览器/服务器的限度，导致他们在利用过程中体现出一些不同

重大区别

  • 简略来说：

    • GET产生一个TCP数据包
    • POST产生两个TCP数据包

  • 长的说：

    • 对于GET形式的申请，浏览器会把http header 和 data 一并发送进来，服务器响应200（返回数据）
    • 而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送 data，服务器响应200 ok（返回数据）

  • 也就是说

    • GET只须要汽车跑一趟就把货送到了，

    • 而POST得跑两趟

      • 第一躺，先去和服务器打个招呼“嗨，我等下要送来一批货，你们打开门迎接我”
      • 第二趟，送货

    • 因为POST须要两步，工夫耗费的要多一点，看起来GET比POST更无效，因而Yahoo团队有举荐用GET替换POST来优化网站性能，然而这是一个坑，因为

      • GET与POST都有本人的语义，不能轻易混用
      • 据钻研，在网络环境好的状况下，发一次包的工夫和发两次包的工夫差异根本能够忽视
      • 而在网络环境差的环境下，两次包的TCP在验证数据包完整性上，有十分大的长处
    • 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次

过程与线程的区别

  • 基本区别：过程是操作系统资源分配的根本单位，而线程是任务调度和执行的根本单位
  • 在开销方面：每个过程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程能够看作轻量级的过程，同一类线程共享代码和数据空间，每个线程都有本人独立的运行栈和程序计数器（PC)，线程之间切换的开销小
  • 所处环境：在操作系统中能同时运行多个过程（程序）；而在同一个过程（程序）中有多个线程同时执行（通过CPU调度，在每个工夫片中只有一个线程执行）
  • 内存调配方面：零碎在运行的时候会为每个过程调配不同的内存空间，而对线程而言，除了CPU外，零碎不会为线程分配内存（线程所用的资源来自其所属过程的资源），线程组之间只能共享资源
  • 蕴含关系：没有线程到的过程能够看做是单线程的，如果一个过程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的，线程是过程的一部分，所以线程也被称作清权过程或轻量级过程

常见状态码status

201-206示意服务器解决胜利了申请的状态代码，阐明网页能够失常拜访

  • 200（胜利）：服务器胜利解决了申请。通常，这示意服务器胜利了提供了申请的网页
  • 201（已创立）：示意申请胜利且服务器曾经创立了新的资源
  • 202（已接管）：示意服务器曾经接管了申请，但尚未对其进行解决
  • 203（非受权信息）：示意服务器曾经胜利解决了申请，但返回了可能来自另一源的信息
  • 204（无内容）：服务器胜利解决了申请，然而未返回任何内容
  • 205（重置内容）：服务器胜利解决了申请，然而未返回任何内容，与204不同，此响应要求请求者重置文档视图（例如革除表单内容输出新的内容）
  • 206（局部内容）：服务器胜利解决了局部GET申请

300-307示意要实现申请，你须要进一步的操作，通常这些状态码都是领有重定向的

  • 300（多种抉择）：服务器依据申请可执行多种操作，服务器可依据请求者来抉择一项操作，或提供操作列表供其选怎
  • 301（永恒挪动）：申请的网页已被永恒的挪动到的新的地位，服务器返回此时响应时，会主动将请求者转移到新的地位，你应应用此代码通知搜索引擎网页或网站曾经被永恒挪动到新的地位
  • 302（长期挪动）：服务器目前正从不同的地位的网页响应申请，但申请应持续应用原有的地位进行当前的申请。会主动将请求者转到不同的地位，但因为搜索引擎会持续抓取原有地位并将其编入索引，因而你不该应用此代码通知搜索引擎网站或者网页曾经被挪动
  • 303（查看其它地位）：当请求者应答不同的地位进行单的get申请以检索响应时，服务器会返回此代码。对于除head申请之外的所有申请，服务器会主动跳转到其余地位
  • 304（未修改）：自从上次申请后，申请的网页没有被批改过，服务器返回此响应时，不会返回网页内容，如果网页自请求者上次申请之后再也没有更改过，你该当将服务器配置为返回此项因。因为服务器能够通知搜索引擎自从上次抓取之后网页没有更改过，应用本地缓存，因而能够节约宽带和开销
  • 305（应用代理）：请求者只能应用代理拜访申请的网页。如果服务器返回此响应，那么服务器还会指明请求者该当应用的代理
  • 307（长期重定向）：服务器目前正从不同地位的网页响应申请，但请求者应持续应用原有地位来持续当前的申请。会主动将请求者转到不同的地位，但因为搜索引擎会持续抓取原有地位并将其编入索引，因而你不该应用此代码来通知搜索引擎某个网页或者网站已被挪动

400-417示意申请可能出错，会障碍服务器的解决

  • 400（谬误申请）：服务器不了解申请的语法
  • 401（身份验证谬误）：此页面要求受权
  • 403（禁止）：服务器拒绝请求
  • 404（未找到）：服务器找不到申请的网页，谬误页面
  • 405（办法禁止）：禁用申请中指定的办法
  • 406（不承受）：无奈应用申请的内容个性响应申请的网页
  • 407（须要代理受权）：指定请求者必须受权应用代理，如果服务器返回此响应，还示意该当应用代理
  • 408（申请超时）：服务器等待申请时产生超时
  • 409（发生冲突）：服务器在实现申请时发生冲突，服务器必须在响应中蕴含无关抵触的信息
  • 410（已删除）：申请的资源永恒删除
  • 411（须要无效长度）：服务器不承受不含无效内容长度标头字段的解决
  • 412（未满足前提条件）：服务器未满足请求者在申请中设置的其中一个前提条件
  • 413（申请实体过大）：服务器无奈解决申请，因为申请实体过大，超出服务器的申请范畴
  • 414（申请的url过长）：申请的url过长，服务器无奈解决
  • 415（不反对的媒体类型）：申请的格局不受申请页面的反对
  • 416（申请范畴不符合要求）：如果页面无奈提供申请的范畴，则服务器还会返回此状态码
  • 417（未满足期望值）：服务器未满足冀望申请的标头字段的要求

500-505示意的意思时服务器在尝试解决申请时产生外部谬误。这些谬误可能时服务器自身的谬误，而不是申请出错

  • 500（服务器外部谬误）：服务器遇到谬误，无奈实现申请
  • 501（尚未施行）：服务器不具备实现申请的性能
  • 502（谬误网关）：服务器作为网关或者代理，从上游服务器收到了有效的响应
  • 503（服务不可用）：目前无奈应用服务器
  • 504（网关超时）：服务器作为网关或者代理。未及时从上游服务器接管申请
  • 505（http版本不受反对）：服务器不反对申请中应用的http协定版本

token sessin cookie

  • token
    令牌，是用户身份的验证形式。Token是服务端生成的一串字符串，以作客户端进行申请的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，当前客户端只需带上这个Token前来申请数据即可，无需再次带上用户名和明码。

最简略的token组成:uid(用户惟一的身份标识)、time（以后工夫的工夫戳）、sign（签名）。

对Token认证的五点意识

  • 一个Token就是一些信息的汇合；
  • 在Token中蕴含足够多的信息，以便在后续申请中缩小查询数据库的几率；
  • 服务端须要对cookie和HTTP Authrorization Header进行Token信息的查看；
  • 基于上一点，你能够用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；
  • 因为token是被签名的，所以咱们能够认为一个能够解码认证通过的token是由咱们零碎发放的，其中带的信息是非法无效的；

  • token身份验证

    • 应用基于 Token 的身份验证办法，在服务端不须要存储用户的登录记录。流程是这样的：
    • 客户端应用用户名跟明码申请登录
    • 服务端收到申请，去验证用户名与明码
    • 验证胜利后，服务端会签发一个 Token，再把这个 Token 发送给客户端
    • 客户端收到 Token 当前能够把它存储起来，比方放在 Cookie 里或者 Local Storage 里
    • 客户端每次向服务端申请资源的时候须要带着服务端签发的 Token
    • 服务端收到申请，而后去验证客户端申请外面带着的 Token，如果验证胜利，就向客户端返回申请的数据
    • APP登录的时候发送加密的用户名和明码到服务器，服务器验证用户名和明码，如果胜利，以某种形式比方随机生成32位的字符串作为token，存储到服务器中，并返回token到APP，当前APP申请时，
    • 但凡须要验证的中央都要带上该token，而后服务器端验证token，胜利返回所须要的后果，失败返回错误信息，让他从新登录。其中服务器上token设置一个有效期，每次APP申请的时候都验证token和有效期。
  • session

  • 会话，代表服务器与浏览器的一次会话过程，这个过程是间断的，也能够连续不断。

    • cookie中寄存着一个sessionID，申请时会发送这个ID；
    • session因为申请（request对象）而产生；
    • session是一个容器，能够寄存会话过程中的任何对象；
    • session的创立与应用总是在服务端，浏览器素来都没有失去过session对象；
    • session是一种http存储机制，目标是为武装的http提供长久机制。
  • cookie

贮存在用户本地终端上的数据，服务器生成，发送给浏览器，下次申请对立网站给服务器。
Cookie实际上是一小段的文本信息（key-value格局）。客户端向服务器发动申请，如果服务器须要记录该用户状态，就应用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再申请该网站时，浏览器把申请的网址连同该Cookie一起提交给服务器。服务器查看该Cookie，以此来识别用户状态。

  • cookie属性项

    • NAME=VALUE：键值对，能够设置要保留的 Key/Value，留神这里的 NAME 不能和其余属性项的名字一样
    • Expires：过期工夫，在设置的某个工夫点后该 Cookie 就会生效
    • Domain：生成该 Cookie 的域名，如 domain="www.baidu.com"
    • Path：该 Cookie 是在以后的哪个门路下生成的，如 path=/wp-admin/
    • Secure：如果设置了这个属性，那么只会在 SSH 连贯时才会回传该 Cookie
  • Expires

该属性用来设置Cookie的有效期。Cookie中的maxAge用来示意该属性，单位为秒。Cookie中通过getMaxAge()和setMaxAge(int maxAge)来读写该属性。maxAge有3种值，别离为负数，正数和0。

如果maxAge属性为负数，则示意该Cookie会在maxAge秒之后主动生效。浏览器会将maxAge为负数的Cookie长久化，即写到对应的Cookie文件中（每个浏览器存储的地位不统一）。无论客户敞开了浏览器还是电脑，只有还在maxAge秒之前，登录网站时该Cookie依然无效。上面代码中的Cookie信息将永远无效。
当maxAge属性为正数，则示意该Cookie只是一个长期Cookie，不会被长久化，仅在本浏览器窗口或者本窗口关上的子窗口中无效，敞开浏览器后该Cookie立刻生效。
能够看到，当MaxAge为-1时，工夫曾经过期。maxAge设置为正数，能看到Expires属性扭转了，但Cookie依然会存在一段时间直到敞开浏览器或者从新关上浏览器。
当maxAge为0时，示意立刻删除Cookie。maxAge设置为0示意立刻删除该Cookie，如果在debug的模式下，执行上述办法，能够看见cookie立刻被删除了。

  • 批改或删除cookie

HttpServletResponse提供的Cookie操作只有一个addCookie(Cookie cookie)，所以想要批改Cookie只能应用一个同名的Cookie来笼罩原先的Cookie。如果要删除某个Cookie，则只须要新建一个同名的Cookie，并将maxAge设置为0，并笼罩原来的Cookie即可。

新建的Cookie，除了value、maxAge之外的属性，比方name、path、domain都必须与原来的统一能力达到批改或者删除的成果。否则，浏览器将视为两个不同的Cookie不予笼罩。

值得注意的是，从客户端读取Cookie时，包含maxAge在内的其余属性都是不可读的，也不会被提交。浏览器提交Cookie时只会提交name和value属性，maxAge属性只被浏览器用来判断Cookie是否过期，而不能用服务端来判断。
咱们无奈在服务端通过cookie.getMaxAge()来判断该cookie是否过期，maxAge只是一个只读属性，值永远为-1。当cookie过期时，浏览器在与后盾交互时会主动筛选过期cookie，过期了的cookie就不会被携带了。

  • cookie与session区别

    • cookie数据寄存在客户端上，session数据放在服务器上；
    • cookie不是很平安，且保留数据无限；
    • session肯定工夫内保留在服务器上,当拜访增多，占用服务器性能。

  • session与token

    • 作为身份认证，token平安行比session好；
    • Session 认证只是简略的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是平安的。这是一种认证伎俩。 而Token ，如果指的是OAuth Token 或相似的机制的话，提供的是 认证 和 受权 ，认证是针对用户，受权是针对App 。其目标是让 某App有权力拜访 某用户 的信息。

  • token与cookie

    • Cookie是不容许垮域拜访的，然而token是反对的， 前提是传输的用户认证信息通过HTTP头传输；
  • token就是令牌，比方你受权（登录）一个程序时，他就是个根据，判断你是否曾经受权该软件；cookie就是写在客户端的一个txt文件，外面包含你登录信息之类的，这样你下次在登录某个网站，就会主动调用cookie主动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也须要在客户端写入cookie文件，然而文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

localStorage和sessionStorage之间的区别比照

  1. localStorage和sessionStorage一样都是用来存储客户端长期信息的对象。
  2. 他们均只能存储字符串类型的对象（尽管标准中能够存储其余原生类型的对象，然而目前为止没有浏览器对其进行实现）。
  3. localStorage生命周期是永恒，这意味着除非用户显示在浏览器提供的UI上革除localStorage信息，否则这些信息将永远存在。
  4. sessionStorage生命周期为以后窗口或标签页，一旦窗口或标签页被永恒敞开了，那么所有通过sessionStorage存储的数据也就被清空了。
  5. 不同浏览器无奈共享localStorage或sessionStorage中的信息。雷同浏览器的不同页面间能够共享雷同的 localStorage（页面属于雷同域名和端口），然而不同页面或标签页间无奈共享sessionStorage的信息。这里须要留神的是，页面及标 签页仅指顶级窗口，如果一个标签页蕴含多个iframe标签且他们属于同源页面，那么他们之间是能够共享sessionStorage的。