http协议
(tcp协议和ip协议是众多协议中最重要的，所以用这两者命名)
tcp/ip协议包含了互联网基础的网络协议，特点是分层管理：
应用层：http协议（超文本传输）、ftp协议（文件传输）、dns协议（域名系统）；
传输层：tcp协议（建立连接、超时重传、发送和接收方确认）、udp协议（没有确认机制）
网络层：处理发送和返回的数据包（包括ip协议）；
链路层：硬件部分。
二、http协议的特点：
1、快速简单，明文传输
2、灵活（根据头部分的数据类型，就可以完成对不同数据类型的传输）
3、无连接（连接一次就会断开）
4、无状态（不会记住上次连接者的身份）
三、http和https的区别
1、端口号不一样，前者80，后者443；
2、http不需要证书，https需要CA申请证书，需要一定的费用；
3、http信息明文传输，https经过加密传输、身份认证，比较安全；
四、http的方法
get：获取
post：发送 与put区别（后一个不会把前一个覆盖，用post来新增资源）
put：与post区别（两个相同的请求，后一个会把前一个覆盖掉，用put来改资源）
head：只获取头部，可查看资源是否存在
delete：删除某个资源；
options：查看当前uri所支持的方法
五、http状态码
1**：请求已接收，继续处理；
2**：请求已被成功接收；
3**：重定向；
4**：客户端错误；
5**：服务端错误；
200：成功；
206：已完成一部分的请求（断点续传时，客户端发送一个带有range头的get请求，服务器已完成）
301：已永久重定向；
302：临时重定向；
304：缓存还可用；
401：客户端的请求不被服务器所理解
403：被禁止，客户没有权限；
404：请求资源不存在；
503：服务器过载崩溃，过段时间可恢复。
502：网关错误
504：超时
附：断点续传
从文件已经下载的地方开始继续下载
请求头加上开始下载的节点：Range：bytes=2000-
六、post和get区别
安全性上：
1、首先get的参数会被拼接在url上，而post则是放在请求体中；
2、其次，get请求会被浏览器的历史记录缓存，而post不会；
3、攻击者更容易利用get去伪造一个请求，所以在安全性上，post优于get；
请求数据上：
通常浏览器和服务器会限制url的长度，所以get请求数据大小也有一定的限制；浏览器2k，服务器64k；
效率上：
get请求是header跟data一并发送的，只产生一个数据包，而post是先发送header，再发送data，会产生两个数据包，所以get效率要优于post。
（在验证数据完整性上，post更优）
七、http1.1版本特性
1、默认持久连接，Connection:keep-alive模式避免重新建立连接。
2、管线化，建立一个tcp连接可发送多个http请求（可并发请求），而不用等待一个一个响应。
八、http的优化方案
1、持久连接，避免重新建立连接，造成性能和带宽的浪费。
2、http复用（管线化），多个http请求通过一个tcp连接进行处理。
3、内容缓存。将常用的内容进行缓存，客户端直接在内存读取数据。
4、压缩，减少带宽。
5、加密，使用ssl/tls协议对http协议进行加密（https：数据加密，身份认证），
6、tcp缓冲，提高服务器的响应时间和处理效率。
九、DNS解析过程
即把域名转换为ip的过程：
本地DNS服务器=>根域名服务器=>com顶级域名服务器=>google.com域名服务器
十、https的连接方式
https：在http协议的基础上，使用tls对数据进行加密传输。
1、客户使用https的url访问web服务器，要求建立ssl连接；
2、服务器收到请求，将网站的证书信息（包含公钥）发送一份给客户端；
3、客户端验证证书的合法性，建立会话秘钥，并用公钥加密，传送给服务器
4、服务器用自己的私钥解密会话秘钥，并用会话秘钥加密数据。
（会话秘钥：采用非对称加密；数据：采用对称加密）
十一、同源策略
1、定义：
同源策略即协议、域名、端口都要相同。不同源的客户端脚本在没有授权的情况下，不能读取对方的资源。
2、目的：
保证用户信息安全，防止恶意网站窃取数据。
3、哪些行为受同源限制：
cookie、webStorage、indexDB
DOM、iframe对象无法读取
ajax不能发送请求 （报错：。。。No 'Access-Control-Allow-Origin'...)
4、哪些行为不受同源限制：
script标签、img标签、link标签
页面中的链接、重定向、表单提交
十二、跨域
受同源策略的限制，当我们去访问一个不同源下的资源的时候就会产生跨域。
解决跨域的方法：
客户端与服务器端之间：
1、（后端）服务器配置cors，跨域资源共享；使用自定义的http头部，让浏览器与服务器进行沟通。
res.header("Access-Control-Allow-Origin", "*"); //设置请求来源不受限制
res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS"); //设置请求方式
2、（后端）nginx反向代理（服务器之间没有同源策略的限制）
3、jsonp，利用script标签可以跨域的特性，只能使用get方法，不安全。
4、如果使用webpack的话，修改webpack选项devServer的代理功能proxy：
（webpack-dev-server是一个小型的Node.js Express服务器，用它做反向代理）
proxy:{ '/api':{ target:'', //请求的实际地址 changeOrgin:true, //是否跨域 /''/ pathRewrite: { //将/api 替换为空 '^/api':'' } } }
客户端之间（页面与页面之间）：
具有相同的上级域名：
1、html5 postMessage()，客户端之间传递数据
window.onload = function() { var ifr = document.getElementById('ifr'); var targetOrigin = "http://www.google.com"; ifr.contentWindow.postMessage('hello world!', targetOrigin); };
2、document.domain（document.domian='baidu.com')，这时浏览器会认为他们都处于同一个域下。问题：当其中一个站点被攻击后，另一个站点也会有安全漏洞。
3、设置window.name
六、从输入url到渲染完成经历了什么？
1、根据地址栏中的域名进行DNS解析，返回对应的ip。（查询浏览器DNS缓存=>系统DNS缓存=>hosts文件的缓存=>都没有，则DNS服务器端将对应的IP地址返回； 2、浏览器根据返回的ip，找到对应的服务器，并与服务器建立TCP连接； 3、向服务器发送http请求； 4、服务器响应请求，并返回数据； 5、浏览器下载返回的数据； 6、解析html，生成DOM树，解析css和js，渲染页面。
tcp连接三次握手和四次挥手：
1、防止服务器端开启一些无用的连接，增加服务器开销；
2、防止已失效的连接请求报文段又传到服务端，产生错误。
七、网站攻击的方式有哪几种
1、xss（跨站脚本攻击）：富文本、评论
在页面中输入并执行js脚本，获取客户敏感信息（发布评论、恶意连接、插入广告，获取cookie等）
方法一：cookie添加httpOnly属性，这是使用js是不能读取和操作cookie的。
方法二：在cookie中添加校验信息。
方法三：对用户输入进行编码（encode）、过滤（移除style、script、iframe相关节点）、校正（）
js编码解码：
1、使用参数时，使用encodeURIComponent
2、进行url跳转时，使用encodeURI
3、js使用数据时，使用escape
2、csrf（跨站请求伪造）：支付扣款
伪造用户的请求，冒充用户在站内进行操作。
方法一：使用referer来判定来源页面
方法二：关键操作只接受post请求，因为get请求的参数携带在url中，很容易模拟。
方法三：在http请求中加上token，并在服务器端验证这个token。
方法四：登录、支付的页面加上一些用户互动，比如验证码，确保当前请求是用户发起的。
两者的区别：
1、xss不需要登录；csrf需要用户先登录获取到cookie；
2、xss是在网站A注入js代码，然后执行js代码，达到篡改网站A的内容；
csrf利用网站A的漏洞，去请求网站A的api。
Cookie和Token都存需要放在Header里面，为什么只劫持前者？
1、http是无状态的，为了使域名下的所有网页能共享某些数据，因此出现了session、cookie以及token。
2、cookie是用于记录用户状态的一种方式，装有sessionId，由服务端设置，存储在客户端在每个请求中会自动携带。
3、token是无状态的，用户信息都被加密到token中，服务器收到token后解密就可以知道是哪个用户，token不会在请求中自动携带，而需要手动添加。
cookie：用户点击了链接，cookie未失效情况下，后端以为是用户的正常操作，于是进行扣款等操作。
token：用户点击链接，由于浏览器不会自动带上token，即使发了请求，但是后端token验证不通过。
//封装cookie
function setCookie(name,value,days,domain){ let oDate=new Date(); oDate.setDate(odate.getDate()+days); if(domain){ document.cookie=`name=${value};expires=${oDate};domain=${domain};path=/` }else{ document.cookie=`name=${value};expires=${oDate};path=/; } }; function getCookie(key){ let arr=document.cookie.split(';'); for(var i=0;i<arr.length;i++){ let arr2=arr[i].split('='); if(arr2[0]==key){ return arr2[1] } } return null; }; function delCookie(name,value,-1){ setCookie(name) };
收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？
如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。
如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。
轮询和长轮询
轮询：说白了就是客户端定时去请求服务端， 是客户端主动请求来促使数据更新；
长轮询：说白了也是客户端请求服务端，但是服务端并不是即时返回，而是当有内容更新的时候才返回内容给客户端，从流程上讲，可以理解为服务器向客户端推送内容；
从中可以看出区别：
轮询：
1：大量耗费服务器内存和宽带资源，因为不停的请求服务器，很多时候 并没有新的数据更新，因此绝大部分请求都是无效请求
2：数据不一定是实时更新，要看设定的请求间隔，基本会有延迟。
长轮询：
1：解决了轮询的两个大问题，数据实时更新；
2：唯一的缺点是服务器在挂起的时候比较耗内存；
