http 总结

HTTP协议

超文本传输协议，一种无状态的，以请求/应答方式运行的协议，它使用可扩展的语义和自描述消息格式，与基于网络的超文本信息系统灵活的互动

1、HTTP报文格式

三部分组成：

起始行： GET /index.html HTTP/1.1
头部字段集合：Connetction: keep-alive
消息正文：实际传输的数据，可以是纯文本，图片，视频

请求行报文

请求方法，请求目标，版本号

响应行报文

版本号，状态码，原因

常用头字段

请求字段：Host, Referer(来源)
响应字段: Server
通用字段: Content-type Connection

一个完整的 http 链路

TCP协议 面向连接的，可靠的，基于字节流的传输层通信协议特点：

基于连接的：数据传输之前需要建立连接
全双工的：双向传输
字节流：不限制数据大小，打包成报文段，保证有序接收，重复报文会自动丢弃
流量缓冲：解决双发处理能力的不匹配
可靠的传输服务：保证可达（三次握手），丢包时通过重发机制实现可靠性
拥塞控制：防止网络出现恶性拥塞

HTTPS协议

HTTPS 协议就是在HTTP协议的基础上加了安全层SSL/TSL(加密算法，md5)

对称加密

编，解码使用相同秘钥的算法，

非对称加密算法

它有两个秘钥，一个叫公钥，一个叫私钥，两个秘钥是不同的，公钥可以公开给任何人使用，而私钥必须严格保密在服务器端，在网上任意分发公钥，只有私钥可以解密

http 跟 https https 的加密方式？

1.明文：裸奔

2.对称加密 key 唯一等于是个明文因为所有人的key是一样的

3.非对称加密 s-->c 不安全如果被劫，拿到公钥，依然会破解服务器传输的数据

4。非对称 + 对称：先使用非对称加密生成一个key,利用的是非对称加密能把数据安全的从客户端传输到服务端的特点，然后用双方都有的key进行加密和解密

5中间人劫持：拦截客户端请求的公钥，返回给客户端自己的公钥，然后冒充客户端给服务端请求公钥，然后客户端生成一个对称加密的key给中间人服务器，然后中间人服务器拿到这个key，并用服务器的公钥加密，传给服务器，服务器用私钥解密就拿到了key，这样就形成了代理中间人

6.ca结构签发证书首先服务器去ca机构，机构私用自己的钥加密服务器的公钥，给服务器，服务器给客户端，客户端用自己存的经过认证的ca机构的公钥解密出服务器的公钥然后开始对称加密因为黑客无法伪造ca机构的公钥，所以不能拦截第一个过程，拦截经过服务器公钥加密的key,也没用，因为他没有服务器的私钥；

http http1.1 http2 区别多路复用是怎么实现的？

http1.1 的头信息是文本，所以比较大，所以每次链接需要穿的东西很多；http2的头信息和数据体都是二进制，成为头信息帧和数据帧；只发一个请求，所以突破了一个域名同时只能有六个链接的限制，就很快的传输数据
http2使用了hpack技术压缩请求头，两次请求只会传输不一样的地方
http2 有服务器主动推送的技术，服务器可以主动推送资源给浏览器
http2 缺点，发生丢包的时候会阻塞当前连接的所有请求

TCP UDP 区别

1.`TCP`向上层提供面向连接的可靠服务 ，`UDP`向上层提供无连接不可靠服务。
2.虽然 `UDP` 并没有 `TCP` 传输来的准确，但是也能在很多实时性要求高的地方有所作为
3.对数据准确性要求高，速度可以相对较慢的，可以选用`TCP`
复制代码
复制代码

区别	UDP	TCP
是否连接	无连接	面向连接
是否可靠	不可靠传输，不使用流量控制和拥塞控制	可靠传输，使用流量控制和拥塞控制
连接对象个数	支持一对一，一对多，多对一和多对多交互通信	只能是一对一通信
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅8字节	首部最小20字节，最大60字节
适用场景	适用于实时应用（IP电话、视频会议、直播等）	适用于要求可靠传输的应用，例如文件传输

Http和Https区别（高频）

1.`HTTP` 的URL 以http:// 开头，而HTTPS 的URL 以https:// 开头
2.`HTTP` 是不安全的，而 HTTPS 是安全的
3.`HTTP` 标准端口是80 ，而 HTTPS 的标准端口是443
4.`在OSI` 网络模型中，HTTP工作于应用层，而HTTPS 的安全传输机制工作在传输层
5.`HTTP` 无法加密，而HTTPS 对传输的数据进行加密
6.`HTTP`无需证书，而HTTPS 需要CA机构wosign的颁发的SSL证书
复制代码
复制代码

GET和POST区别（高频）

1.GET在浏览器回退不会再次请求，POST会再次提交请求
2.GET请求会被浏览器主动缓存，POST不会，要手动设置
3.GET请求参数会被完整保留在浏览器历史记录里，POST中的参数不会
4.GET请求在URL中传送的参数是有长度限制的，而POST没有限制
5.GET参数通过URL传递，POST放在Request body中
6.GET参数暴露在地址栏不安全，POST放在报文内部更安全
7.GET一般用于查询信息，POST一般用于提交某种信息进行某些修改操作
8.GET产生一个TCP数据包；POST产生两个TCP数据包
复制代码
复制代码

理解xss，csrf，ddos攻击原理以及避免方式

XSS(Cross-Site Scripting，跨站脚本攻击)是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

XSS避免方式：

url参数使用encodeURIComponent方法转义
尽量不是有InnerHtml插入HTML内容
使用特殊符号、标签转义符。

CSRF避免方式：

添加验证码
使用token
- 服务端给用户生成一个token，加密后传递给用户
- 用户在提交请求时，需要携带这个token
- 服务端验证token是否正确

DDoS又叫分布式拒绝服务，全称 Distributed Denial of Service，其原理就是利用大量的请求造成资源过载，导致服务不可用。

DDos避免方式：

限制单IP请求频率。
防火墙等防护设置禁止ICMP包等
检查特权端口的开放

http特性以及状态码

比如：
    200响应成功
    301永久重定向
    302临时重定向
    304资源缓存
    403服务器禁止访问
    404服务器资源未找到
    500 502服务器内部错误
    504 服务器繁忙
    1xx	Informational（信息状态码）	  接受请求正在处理
    2xx	Success（成功状态码）            请求正常处理完毕
    3xx	Redirection（重定向状态码）		 需要附加操作已完成请求
    4xx	Client Error（客户端错误状态码）	服务器无法处理请求
    5xx	Server Error（服务器错误状态码）	服务器处理请求出错
复制代码
复制代码

http三次握手

目的：同步通信双方初始序列号，协商TCP通信参数（MSS 窗口信息，指定校验和算法）

第一步：客户端发送SYN报文到服务端发起握手，发送完之后客户端处于SYN_Send状态
第二步：服务端收到SYN报文之后回复SYN和ACK报文给客户端
第三步：客户端收到SYN和ACK，向服务端发送一个ACK报文,客户端转为established状态，此时服务端收到ACK报文后也处于established状态，此时双方已建立了连接

http四次挥手

客户端和服务器都可发送关闭请求

A: 发送FIN数据包，代表A不在发送数据

B: 收到请求，开始应答，避免A重新发送FIN重试（应答机制）

B: 处理完数据之后关闭连接，及发送FIN请求

A: 收到请求后发送ACK应答，B服务可以释放连接

等待2MSL后释放连接

1、防止报文丢失，导致B重复发送FIN

2、防止滞留在网络中的报文，对新建立的连接造成数据扰乱

详细过程

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。
第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态
服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

http1.0、http1.1、http2.0的区别

1和1.0相比，1.1可以一次传输多个文件
http1.x解析基于文本，http2.0采用二进制格式，新增特性多路复用、header压缩、服务端推送(静态html资源)

http如何实现缓存

强缓存==>Expires(过期时间)/Cache-Control(no-cache)(优先级高) 协商缓存 ==>Last-Modified/Etag(优先级高)Etag适用于经常改变的小文件 Last-Modefied适用于不怎么经常改变的大文件
强缓存策略和协商缓存策略在缓存命中时都会直接使用本地的缓存副本，区别只在于协商缓存会向服务器发送一次请求。它们缓存不命中时，都会向服务器发送请求来获取资源。在实际的缓存机制中，强缓存策略和协商缓存策略是一起合作使用的。浏览器首先会根据请求的信息判断，强缓存是否命中，如果命中则直接使用资源。如果不命中则根据头信息向服务器发起请求，使用协商缓存，如果协商缓存命中的话，则服务器不返回资源，浏览器直接使用本地资源的副本，如果协商缓存不命中，则浏览器返回最新的资源给浏览器。

什么是同源策略

一个域下的js脚本未经允许的情况下，不能访问另一个域下的内容。通常判断跨域的依据是协议、域名、端口号是否相同，不同则跨域。同源策略是对js脚本的一种限制，并不是对浏览器的限制，像img,script脚本请求不会有跨域限制。

跨域通信的几种方式

解决方案：

jsonp(利用script标签没有跨域限制的漏洞实现。缺点：只支持GET请求)
CORS(设置Access-Control-Allow-Origin：指定可访问资源的域名)
postMessage(message, targetOrigin, [transfer])(HTML5新增API 用于多窗口消息、页面内嵌iframe消息传递),通过onmessage监听传递过来的数据
Websocket是HTML5的一个持久化的协议，它实现了浏览器与服务器的全双工通信，同时也是跨域的一种解决方案。
Node中间件代理
Nginx反向代理
各种嵌套iframe的方式，不常用。
日常工作中用的最对的跨域方案是CORS和Nginx反向代理

能不能说一说浏览器的本地存储？各自优劣如何？

浏览器的本地存储主要分为Cookie、WebStorage和IndexDB, 其中WebStorage又可以分为localStorage和sessionStorage。

共同点: 都是保存在浏览器端、且同源的

不同点：

cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递。cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下sessionStorage和localStorage不会自动把数据发送给服务器，仅在本地保存。
存储大小限制也不同，

cookie数据不能超过4K，sessionStorage和localStorage可以达到5M
sessionStorage：仅在当前浏览器窗口关闭之前有效；
localStorage：始终有效，窗口或浏览器关闭也一直保存，本地存储，因此用作持久数据；
cookie：只在设置的cookie过期时间之前有效，即使窗口关闭或浏览器关闭

作用域不同

sessionStorage：不在不同的浏览器窗口中共享，即使是同一个页面；
localstorage：在所有同源窗口中都是共享的；也就是说只要浏览器不关闭，数据仍然存在
cookie: 也是在所有同源窗口中都是共享的.也就是说只要浏览器不关闭，数据仍然存在

api 请求时 content-type 有几种值，分别是什么意思

application/x-www-form-urlencoded 浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 会进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。例如 PHP 中，$_POST[‘XXX’] 可以获取到相应的值。
我们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」。如果你用js写ajax要用这种方式，一定要注意加上setRequestHeader(“Content-type”,“application/x-www-form-urlencoded”)；否则无法正常解析

multipart/form-data 我们使用表单上传文件时，就要让 form 的 enctype 等于这个值。直接来看一个请求示例

首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 mutipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。

application/json application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。

text/xml 相比于JSON，XML不能更好的适用于数据交换，它包含了太多的包装, 而且它跟大多数编程语言的数据模型不匹配，让大多数程序员感到诧异，XML是面向数据的，JSON是面向对象和结构的，后者会给程序员一种更加亲切的感觉。
我们现在一般这样来使用：
1、XML 存储数据，存储配置文件等需要结构化存储的地方使用；
2、数据传输、数据交互使用JSON；
下面就是ajax Content-Type为text/xml的请求：

其他

你未来一到三年的一个职业规划是什么？
你都是怎么去学习和关注新技术的？
你近几年工作中有哪些心得或总结？
你觉得你在工作中的优缺点是什么？
你过来我们公司，你的优势是什么？
有些过开源项目吗？
写过 npm 包吗，写过 webpack 插件吗？
看过哪些框架或者类库的源码，有什么收获？