webpack，http整理篇

webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler)。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph)，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

const path = require('path');
module.exports = {
  // 单/多入口 entry: string|Array<string>|{[entryChunkName: string]: string|Array<string>} 
  entry: './src/index.js',   // 或 entry: {main: './src/index.js'}
  // 输出 output 属性告诉 webpack 在哪里输出它所创建的 bundle，以及如何命名这些文件。主要输出文件的默认值是 ./dist/main.js，其他生成文件默认放置在 ./dist 文件夹中
  output: {
      path: path.resolve(__dirname, 'dist'),
      filename: 'my-first-webpack.bundle.js'
  },
  // loader 让 webpack 能够去处理其他类型的文件，并将它们转换为有效 模块，以供应用程序使用，以及被添加到依赖图中
  module: {
    rules: [
      { test: /\.txt$/, use: 'raw-loader' },
      {
        test: /\.css$/i,
        use: ['style-loader', 'css-loader'],
      }
    ]
  },
  // 插件可用于打包优化，资源管理，注入环境变量等
  plugins: [
    new HtmlWebpackPlugin({template: './src/index.html'})
  ],
  // 模式，4.0版本新增， development|production|none
  mode: 'production',  //默认
  // 开发服务器配置
  devServer: {
    index: 'index.html',
    lazy: true,  // 懒惰模式，不监视任何文件修改
    contentBase: path.join(__dirname, 'dist'),
    compress: true,
    port: 9000,
    host: '0.0.0.0',
    hot: true
  }
};

grunt，gulp，webpack

前端工程化的早期，主要是解决重复任务的问题。Grunt、Gulp就是其中代表。比如: 压缩、编译less、sass、地址添加hash、替换等，而如今的Webpack更像一套前端工程化解决方案。利用强大插件机制，解决前端静态资源依赖管理的问题。

 Grunt和Gulp属于任务流工具Tast Runner，Gulp吸取了Grunt的优点，拥有更简便的写法，通过流（Stream）的概念来简化多任务之间的配置和输出，让任务更加简洁和容易上手；webpack属于模块打包工具 Bundler

Webpack作者Tobias回复与 Grunt Gulp NPM脚本的比较

Tobias： NPM脚本对我而言足矣。实际上，说webpack是Grunt/Gulp的替代器并不完全准确。Grunt和Gulp以及NPM脚本都是任务执行程序。
Webpack是模块打包程序。这两类程序的目标不一样。但webpack简化了必须“过度使用”Grunt和Gulp和NPM脚本才能实现的Web开发任务也是事实。NPM脚本才是Grunt和Gulp的替代品。
不过，除了纯粹的构建之外，任务运行程序也有存在的理由，比如部署、代码检查、版本管理，等等。

Grunt与Gulp性能比较

Grunt: 每个任务处理完成后存放在本地磁盘.tmp目录中，有本地磁盘的I/O操作，会导致打包速度比较慢。

// Gruntfile.js
module.exports = function(grunt) {
  grunt.initConfig({
    // js格式检查任务
    jshint: {
      src: 'src/test.js'
    }
    //  代码压缩打包任务
    uglify: {}
  });
  // 导入任务插件
  grunt.loadnpmTasks('grunt-contrib-uglify');
  // 注册自定义任务, 如果有多个任务可以添加到数组中
  grunt.regusterTask('default', ['jshint'])
}

// gulpfile.js
var gulp = require('gulp');
var jshint = require('gulp-jshint');
var uglify = require('gulp-uglify');

// 代码检查任务 gulp 采取了pipe 方法，用流的方法直接往下传递
gulp.task('lint', function() {
  return gulp.src('src/test.js')
    .pipe(jshint())
    .pipe(jshint.reporter('default'));
});

// 压缩代码任务
gulp.task('compress'， function() {
  return gulp.src('src/test.js')
    .pipe(uglify())
    .pipe(gulp.dest('build'));
});

// 将代码检查和压缩组合，新建一个任务
gulp.task('default', ['lint', 'compress']);

运行机制

grunt gulp 思路
【遍历源文件】->【匹配规则】->【打包】
做不到按需加载，对打包的资源，是否用到，打包过程不关心。
webpack
【入口】->【模块依赖加载】->【依赖分析】->【打包】
在加载、分析、打包的过程中，可以针对性的做一些解决方案。比如：code split(拆分公共代码)

Gulp vs Grunt

乍一看，Grunt和Gulp的基本功能似乎并没有太大区别。两种自动化工具都可以在MIT许可下使用，因此源代码是开放的并且免费提供。这两个应用程序都可以从命令行进行控制，并具有自己的界面。任务运行者还使用相同的包管理器npm。由于它们的插件目录很大，Grunt和Gulp都可以轻松地自动化大量任务。如果没有所需过程的扩展，则可以使用两种工具对其进行编程，尽管由于结构复杂，两个任务运行者都需要JavaScript和node.js的知识。
但是，虽然Gulp主要基于node.js模块流，但Grunt主要使用fs（文件系统）模块，这突出了这两个工具之间最重要的区别之一：Grunt严格面向文件并创建临时本地文件在执行任务期间。另一方面，Gulp 通过内存处理这些进程，并将它们立即写入目标文件中，从而使程序具有速度优势。
第二个区别特征是两种解决方案的各自概念。Grunt的编程和结构为用户提供了一些指导。已经定义了位于此处的已完成任务，然后必须对其进行简单配置。相比之下，Gulp通过仅提供单个模块为独立编程提供了更多的空间。一方面，这使得更容易理解背景和上下文，同时也要求用户更多。一个项目越大，Gulp的优势就越发挥作用，这就是为什么新的任务执行者现在成为许多人的首选的原因。但是由于较低的要求，Grunt仍然是较小的，可管理的项目。

http

概念：超文本传输协议（HTTP）是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待它收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。该协议虽然通常基于 TCP/IP 层，但可以在任何可靠的传输层上使用；也就是说，不像 UDP，它是一个不会静默丢失消息的协议。RUDP——作为 UDP 的可靠化升级版本——是一种合适的替代选择

http特性：

1.HTTP 是无连接无状态的

2.HTTP 一般构建于 TCP/IP 协议之上，默认端口号是 80

3.HTTP 可以分为两个部分，即请求和响应。

http请求：

HTTP 定义了在与服务器交互的不同方式，最常用的方法有 4 种
分别是 GET，POST，PUT， DELETE。URL 全称为资源描述符，可以这么认为：一个 URL 地址
对应着一个网络上的资源，而 HTTP 中的 GET，POST，PUT，DELETE
就对应着对这个资源的查询，修改，增添，删除4个操作。
HTTP 请求由 3 个部分构成，分别是：状态行，请求头(Request Header)，请求正文。
HTTP 响应由 3 个部分构成，分别是：状态行，响应头(Response Header)，响应正文。
HTTP 响应中包含一个状态码，用来表示服务器对客户端响应的结果。
状态码一般由3位构成：

1xx : 表示请求已经接受了，继续处理。 2xx : 表示请求已经处理掉了。 3xx : 重定向。 4xx : 一般表示客户端有错误，请求无法实现。 5xx : 一般为服务器端的错误。

常见的状态码：

200 OK 客户端请求成功。
301 Moved Permanently 请求永久重定向。
302 Moved Temporarily 请求临时重定向。
304 Not Modified 文件未修改，可以直接使用缓存的文件。
400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
401 Unauthorized 请求未经授权，无法访问。
403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因。
404 Not Found 请求的资源不存在，比如输入了错误的URL。
500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
502 Bad Gateway 是一种HTTP协议的服务器端错误状态代码，它表示作为网关或代理角色的服务器，从上游服务器（如tomcat、php-fpm）中接收到的响应是无效的
503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。

在浏览器地址栏输入URL之后回车的过程

URL解析，抽出域名字段
DNS解析，域名解析成IP
- 浏览器缓存->操作系统缓存->路由器缓存->ISP缓存->根域名服务器->主域名服务器
TCP/IP连接，三次握手（Three-way Handshake，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包）
- 客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号(Sequence Number)字段里
- 服务器发回确认包(ACK)应答
- 客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1
发送HTTP请求
服务器处理请求并返回 HTTP 报文
浏览器解析渲染页面
断开连接：TCP 四次挥手
- 假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据
- 服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接
- 服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK
- 客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT状态，等待可能出现的要求重传的 ACK 包。服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态

http与https的区别

https协议需要到ca申请证书，一般免费证书较少，需要付费
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议
http默认80端口，https默认443端口
http是无状态连接；https协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，安全性更高

缓存 SessionStorage，localStorage，Cookie

存储方式

cookie会数据始终在同源http请求中携带，在浏览器和服务器之间来回传递
sessionStroage和localStroage仅保存在本地

存储大小

单个cookie不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie
sessionStroage和localStroage可以达到5M

过期时间

只在设置的cookie过期时间之前有效，即使窗口关闭或浏览器关闭
sessionStorage,仅在当前浏览器窗口关闭之前有效
localStorage：始终有效，窗口或浏览器关闭也一直保存，本地存储，因此用作持久数据

作用域

cookie和localStorage: 在所有同源窗口中都是共享的.只要浏览器不关闭，数据仍然存在
sessionStorage：打开多个相同的URL的Tabs页面，会创建各自的sessionStorage；关闭对应浏览器tab，会清除对应的sessionStorage