传送门>>>

上一篇： Day4 - 前端高频面试题之浏览器相关

1、请介绍一下`HTTP`和`HTTPS`的区别？

HTTPS是在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密（在传输层）

HTTP + 加密 + 认证 + 完整性保护 = HTTPS

HTTPS协议需要到CA申请证书或自制证书
HTTP的信息是明文传输；

HTTPS则是具有安全性的ssl加密
HTTP是直接与TCP进行数据传输；

而HTTPS运行在SSL/TLS(安全传输层协议)之上，SSL/TLS运行在TCP之上，用的端口也不一样，前者是80（需要国内备案），后者是443
HTTP的连接很简单，是无状态的；

HTTPS协议是由SSL+HTTP协议构建的，可进行加密传输、身份认证的网络协议，比HTTP协议安全

2、`HTTP2`与`HTTP1.x`相比的新特性有哪些？

1、HTTP2使用的是新的二进制格式传送，HTTP1.X是文本（字符串）传送。二进制协议解析起来更高效

2、HTTP2支持多路复用，即连接共享，即每一个request都是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的id将request再归属到各自不同的服务端请求里面。

HTTP2.0多路复用有多好？

HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我「调谐」，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。 HTTP/2通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

3、HTTP2头部压缩，通过gzip和compress压缩头部然后再发送，既避免了重复header的传输，又减小了需要传输的大小。

4、HTTP2支持服务器推送。

3、请介绍一下TCP与UDP的区别，TCP的可靠性如何保证？

UDP是面向无连接的，不可靠的数据报服务；

TCP是面向连接的，可靠的字节流服务。

TCP的可靠性是通过顺序编号和确认（ACK）来实现的。

4、为什么TCP连接需要三次握手？为什么要四次挥手？画出TCP三次握手和四次挥手的全过程（并且标注ack确认号和 seq序列号的值）

三次握手是客户端向服务器发请求，服务器接收请求，服务器接收请求之后发送一个连接标志，客户端接收连接标志之后也向服务器发送一个连接标志，至此连接完成，这是为了保证建立一个可靠的连接；

为什么一定要三次握手呢？考虑一下这种情况：

client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

四次挥手的作用就是断开连接，之所以要断开连接是因为TCP/IP协议是要占用端口的，而计算机的端口是有限的，所以一次传输完成之后是要断开连接的；

为什么四次断开？

因为TCP有个半关闭状态，假设A、B要释放连接，那么A发送一个释放连接报文给B，B收到后发送确认，这个时候A不发数据，但是B如果发数据A还是要接受，这叫半关闭。

然后B还要发给A连接释放报文，然后A发确认，所以是4次。

第一次握手：主机A发往主机B，主机A初始序号是X，设置SYN（同步）位，未设置ACK（确认）位
第二次握手：主机B发往主机A，主机B初始序号是Y，ACK（确认号）是X+1，X+1暗示已经收到主机A发来主机B的同步序号。设置ACK位和SYN位
第三次握手：主机A发往主机B，主机A初始序号是X+1，ACK是Y+1，Y+1暗示已经收到主机A发来主机B的同步序号。设置ACK位，未设置SYN位。

5、HTTP中，POST与GET的区别

1、用途不同：Get是从服务器上获取数据，Post是向服务器传送数据

2、数据传输方式不同：GET请求通过URL传输数据，而POST的数据通过请求体传输

3、传输数据量限制不同：Get传送的数据量小，不能大于2KB (因为浏览器对URL的长度有限制)；POST传送的数据量较大，一般被默认为不受限制

4、GET的数据在URL中，通过历史记录，缓存很容易查到数据信息，相对来说是不安全的；POST的数据在请求主体内，所以有一定的安全性保证

5、GET是安全（这里的安全是指只读特性，就是使用这个方法不会引起服务器状态变化）且幂等（指同一个请求方法执行多次和仅执行一次的效果完全相同），而POST是非安全非幂等

6、HTTP的长连接和短连接分别是什么？你知道keep-alive是干什么的吗？

HTTP的长连接和短连接实际上是TCP的长连接和短连接，HTTP属于应用层协议。

**短连接：**浏览器和服务器每进行一次HTPP操作，就建立一个连接，但任务结束就会中断这个连接

长连接：HTTP1.1规定了默认保持长连接，也称为持久连接。

意思就是，数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据。

长连接好处:

同一个客户端可以使用这个长连接处理其他请求，避免HTTP重新连接和断开所消耗的时间；
服务器可以利用这个连接 主动推送 消息到客户端（重要的）。

HTTP头部有了Connection: Keep-Alive这个值，代表客户端期望这次请求是长连接的。但是并不代表一定会使用长连接，服务器端都可以无视这个值，也就是不按标准来。实现长连接要客户端和服务端都支持长连接。

keep-alive的优点：

较少的CPU和内存的使用（由于同时打开的连接的减少了）
允许请求和应答的HTTP管线化
降低拥塞控制（TCP连接减少了）
减少了后续请求的延迟（无需再进行握手）
报告错误无需关闭TCP连接

7、HTTP Request Header和Response Header里面分别都有哪些比较重要的字段？

**通用首部字段：**请求报文和响应报文两方都会使用的首部

Cache-Control 告诉所有的缓存机制是否可以缓存及哪种类型
Connection 表明是否需要持久连接
Transfer-Encoding 文件传输编码

Request Header：

Accept 指定客户端能够接收的内容类型，内容类型中的先后次序表示客户端接收的先后次序
Range 实体的字节范围请求
Authorization web的认证信息
Host 请求资源所在服务器
User-Agent 客户端程序信息

Response Header：

Location 令客户端重定向的URI
ETag 能够表示资源唯一资源的字符串
Server 服务器的信息

实体首部字段：（Entity头域）

Last-Modified 请求资源的最后修改时间
Expires 响应过期的日期和时间
Allow 资源可支持http请求的方法，不允许则返回405
Content-Type 返回内容的媒体类型 Content-Type: text/html; charset=utf-8

// 典型的请求消息： 

GET http://download.google.com/somedata.exe 
Host: download.google.com
Accept:*/* 
Pragma: no-cache 
Cache-Control: no-cache 
Referer: http://download.google.com/ 
User-Agent:Mozilla/4.04[en](Win95;I;Nav) 
Range:bytes=554554-

// 典型的响应消息： 

HTTP/1.0200OK 
Date:Mon,31Dec200104:25:57GMT 
Server:Apache/1.3.14(Unix) 
Content-type:text/html 
Last-modified:Tue,17Apr200106:46:28GMT 
Etag:"a030f020ac7c01:1e9f" 
Content-length:39725426

8、说说你所知道的web安全及防护措施？

对Web应用的攻击模式有以下两种：主动攻击和被动攻击

XSS（Cross-Site Scripting, 跨站脚本攻击）（被动攻击）
- 是最常见和基本的攻击 WEB 网站方法，攻击者通过注入非法的 html 标签或者 javascript 代码，从而当用户浏览该网页时，控制用户浏览器。
- 影响：利用虚假输入表单骗取用户个人信息；利用脚本窃取用户的Cookie值
- 防御：
  1. httpOnly: 在 cookie 中设置 HttpOnly 属性，使js脚本无法读取到 cookie 信息
  2. 前端负责输入检查，后端也要做相同的过滤检查
  3. 某些情况下，不能对用户数据进行严格过滤时，需要对标签进行转换
CSRF (Cross-Site Request Forgeries, 跨站请求伪造)（被动攻击）
- 冒充用户发起请求（在用户不知情的情况下），完成一些违背用户意愿的事情
- 本质：重要操作的所有参数都是可以被攻击者猜测到的。攻击者预测出URL的所有参数与参数值，就能成功地构造一个伪造的请求
- 影响：利用已通过认证的用户权限更新设定信息、购买商品、在留言板上发表言论等
- 防御：
  1. 验证码；强制用户必须与应用进行交互，才能完成最终请求
  2. 尽量使用 post ，限制 get 使用；get 太容易被拿来做 csrf 攻击
  3. 请求来源限制，此种方法成本最低，但是并不能保证 100% 有效，因为服务器并不是什么时候都能取到 Referer，而且低版本的浏览器存在伪造 Referer 的风险
  4. token 验证 CSRF 防御机制是公认最合适的方案
- 使用token的原理：
  1. 第一步：后端随机产生一个 token，把这个token 保存到 session 状态中；同时后端把这个token 交给前端页面；
  2. 第二步：前端页面提交请求时，把 token 加入到请求数据或者头信息中，一起传给后端；
  3. 后端验证前端传来的 token 与 session 是否一致，一致则合法，否则是非法请求。
SQL注入攻击（主动攻击）
- 会执行非法SQL的SQL注入攻击
HTTP首部注入攻击（被动攻击）
- 指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。
- 影响：设置任何Cookie信息；重定向至任意URL