2021应届秋招前端面经（一）计网部分

计网部分

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协议安全
主要区别如下：

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是433。
http的连接很简单，是无状态的；https协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议，比http协议安全。

HTTPS的优点：
尽管HTTPS并非绝对安全，掌握根证书的机构，掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，
主要有以下几个好处：

使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议，要比HTTP协议安全，可防止数据在传输工程中不被窃取，改变，确保数据的完整性。
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅度增加了中间人攻击的成本
谷歌曾在14.8月调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”

HTTPS的缺点：

HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%-20%的耗电。
HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响
SSL证书需要钱，功能越强大的证书费用越高，个人网站，小网站没有必要一般不会用
SSL证书通常需要绑定ip，不能在同一ip上绑定多个域名，ipv4资源不可能支撑这个消耗
HTTPS协议的加密范围也比较有限，在黑客攻击，拒绝服务攻击，服务器劫持等方面几乎起不到什么作用。最关键的SSL证书的信用链体系并不安全，特别是在某些国家可以控制ca根证书的情况下，中间人攻击一样可行。

HTTPS切换到HTTPS：

直接在url里改http-->https
推荐做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保活功能。保活功能主要为服务器应用提供，服务器应用希望知道客户端主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应等待客户端的数据，保活功能就是视图在服务端检测到这种半开放的连接。
如果一个给定的连接在两个小时内没有任何动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下四个状态之一：

客户主机依然正常允许，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两个小时候将保活定时器复位
客户主机已经崩溃，并且关闭或正在重新启动。在任何一种情况下，客户的TCP都没有响应，服务端将不能接收到对探测的响应，并在75s后超时。服务器总共发送10个这样的探测，每个间隔75s。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。
客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接
客户主机正常运行，但是服务器不可达，这种情况与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、clientLeft
offsetWidth、offsetHeight、offsetTop、offsetLeft
scrollWidth、scrollHeight、scrollTop、scrollLeft
width、height
getComputedStyle()
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在传输数据前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输很快
区别：

TCP是面向连接的，UDP是无连接的即发送数据前不需要先建立链接
TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。并且因为TCP可靠，面向连接，不会丢失数据因此适合大数据量的交换。
TCP是面向字节流，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）
TCP只能是1对1的，UDP支持1对1，1对多
TCP的首部较大为20字节，而UDP只有8字节
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攻击：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件，发消息，盗取你的账号，添加系统管理员，甚至于购买商品，虚拟货币转账等。
攻击原理：

用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A
在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A
用户未退出网站A之前，在同一浏览器，打开一个TAB页访问网站B
网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要访问第三方站点A;
浏览器在接收到这些攻击性代码后，根据网站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验证：（用的最多）

服务器发送给客户端一个token
客户端提交的表单中带着这个token
如果这个token不合法，那么服务器拒绝这个请求

方法二：隐藏令牌
把token隐藏在http的head头中
方法二和方法一有点像，本质上没有太大区别，只是使用方式上有区别
方法三：Referer验证
Referer指的是页面请求来源。意思是，只接受本站的请求，服务器才做响应，如果不是就拦截

CSRF和XSS的区别

区别一
- CSRF：需要用户先登录网站，获取cookie
- XSS：不需要登录
区别二（原理的区别）
- CSRF：是利用网站本身的漏洞，去请求网站的api
- XSS：是向网站注入JS代码，然后执行JS里的代码，篡改网站的内容

get 和 post区别

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上，所以不能用来传递敏感信息。
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之间的区别对比

localStorage和sessionStorage一样都是用来存储客户端临时信息的对象。
他们均只能存储字符串类型的对象（虽然规范中可以存储其他原生类型的对象，但是目前为止没有浏览器对其进行实现）。
localStorage生命周期是永久，这意味着除非用户显示在浏览器提供的UI上清除localStorage信息，否则这些信息将永远存在。
sessionStorage生命周期为当前窗口或标签页，一旦窗口或标签页被永久关闭了，那么所有通过sessionStorage存储的数据也就被清空了。
不同浏览器无法共享localStorage或sessionStorage中的信息。相同浏览器的不同页面间可以共享相同的 localStorage（页面属于相同域名和端口），但是不同页面或标签页间无法共享sessionStorage的信息。这里需要注意的是，页面及标签页仅指顶级窗口，如果一个标签页包含多个iframe标签且他们属于同源页面，那么他们之间是可以共享sessionStorage的。