文章来源：川农谭同学

  前言：由于大家的技术掌握情况和技术栈的不同，所以我接下来分享的东西大部分是基础性的内容，现在前后端分离方案，我们更经常与网络打交道，所以接下来重点谈下HTTP小部分基础内容，包括校招需要注意的事项：

  1. Node 服务

  2. 前端基础框架

  3. 前后端协同方案

  4. 构建部署，doker,jenkins

  5. WEB安全

  6. 前端工程化:CommonJS,Webpack

  7. 浏览器：跨域和原理（浏览器解析）

  8. 数据可视化

  9. HTTP

  Post和Get的区别

  在技术上说：

  Get 请求能缓存，Post 不能

  Post 相对 Get 安全一点点，因为Get 请求都包含在 URL 里，且会被浏览器保存历史纪录，Post 不会，但是在非HTTPS协议下抓包的情况下都是一样的。

  Post 可以通过 request body来传输比 Get 更多的数据，Get 没有这个技术

  URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的，不是 RFC 规定的

  Post 支持更多的编码类型且不对数据类型限制

  常见状态码

  2XX 成功

  3XX 重定向

  4XX 客户端错误

  5XX 服务器错误

  浏览器缓存

  浏览器缓存，也就是客户端缓存

  浏览器缓存分为强缓存和协商缓存：

  1）浏览器在加载资源时，先根据这个资源的一些http header判断它是否命中强缓存，强缓存如果命中，浏览器直接从自己的缓存中读取资源，不会发请求到服务器。比如某个css文件，如果浏览器在加载它所在的网页时，这个css文件的缓存配置命中了强缓存，浏览器就直接从缓存中加载这个css，连请求都不会发送到网页所在服务器；

  2）当强缓存没有命中的时候，浏览器一定会发送一个请求到服务器，通过服务器端依据资源的另外一些http header验证这个资源是否命中协商缓存，如果协商缓存命中，服务器会将这个请求返回，但是不会返回这个资源的数据，而是告诉客户端可以直接从缓存中加载这个资源，于是浏览器就又会从自己的缓存中去加载这个资源；

  3）强缓存与协商缓存的共同点是：如果命中，都是从客户端缓存中加载资源，而不是从服务器加载资源数据；区别是：强缓存不发请求到服务器，协商缓存会发请求到服务器。

  4）当协商缓存也没有命中的时候，浏览器直接从服务器加载资源数据。

  注意：第一次请求时没有缓存，所以浏览器缓存主要针对的是第一次之后的请求。

  第一次请求：

      后续请求：

       2.强缓存的原理

  当浏览器对某个资源的请求命中了强缓存时，返回的http状态为200，在chrome的开发者工具的network里面size会显示为from cache，比如京东的首页里就有很多静态资源配置了强缓存，用chrome打开几次，再用f12查看network，可以看到有不少请求就是从缓存中加载的：

 

  强缓存是前端性能优化最有力的工具之一，对于有大量静态资源的网页，一定要利用强缓存，提高响应速度。通常的做法是，为这些静态资源全部配置一个超时时间超长的Expires或Cache-Control，这样用户在访问网页时，只会在第一次加载时从服务器请求静态资源，其它时候只要缓存没有失效并且用户没有强制刷新的条件下都会从自己的缓存中加载，比如前面提到过的京东首页缓存的资源，它的缓存过期时间都设置到了2026年：

  强缓存还有一点需要注意的是，通常都是针对静态资源使用，动态资源需要慎用

  所以有些小伙伴在开发WEB应用时，自己明明修改了代码，却发现没生效，这种情况很可能是因为缓存的原因，此时可以Ctrl+F5强制刷新

  协商缓存的原理

  当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，如果协商缓存命中，请求响应返回的http状态为304并且会显示一个Not Modified的字符串，比如你打开京东的首页，按f12打开开发者工具，再按f5刷新页面，查看network，可以看到有不少请求就是命中了协商缓存的：

  关于缓存的东西还有很多，这里就不一一赘述，跟上面一样，有兴趣自行搜索（强烈建议下来一点要认真理解）

  前端路由：

  后端有后端路由，根据路由返回特定的网页，代表者是传统的mvc模式，模板引擎+node。前端也有前端的路由，我们用三大框架做SSR的时候，总是和路由离不开关系。主要有两种方法：基于哈希路由、基于history

  1.哈希路由

  #后面的内容是网页位置标识符，一般是锚点<a name='xx'>或id属性<div id='xx'>。通过location.hash可以取到该值，常见的返回顶部也可以利用href=‘#’。改变#后面的内容不会引起页面重新刷新，但是会有历史记录，所以可以后退。这对于ajax应用程序特别有用，可以用不同的#值，表示不同的访问状态，然后向用户给出可以访问某个状态的链接。但是IE 6和IE 7不会有历史记录。#后面的内容不会提交到服务器。

  比如http://localhost:2333/#/user/login

  1. history路由：略

  网页生成的过程，大致可以分为五步：

  1. html代码转化为dom

  2. css代码转化为cssom

  3. 结合dom和cssom，生成一颗渲染树

  4. 生成布局layout，即将所有的渲染树的节点进行平面合成

  5. 将布局绘制paint在屏幕上（可以拓展讲一下减少浏览器渲染的重排和重绘）

  前端安全：

  XSS和CSRF

  · XSS：跨站脚本攻击，是一种网站应用程序的安全漏洞攻击，是代码注入的一种。常见方式是将恶意代码注入合法代码里隐藏起来，再诱发恶意代码，从而进行各种各样的非法活动。

  预防：

  使用XSS Filter

  1.输入过滤，对用户提交的数据进行有效性验证，仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。

  2.输出转义，当需要将一个字符串输出到Web网页时，同时又不确定这个字符串中是否包括XSS特殊字符，为了确保输出内容的完整性和正确性，输出HTML属性时可以使用HTML转义编码（HTMLEncode）进行处理，输出到<script>中，可以进行JS编码。

  CSRF：跨站请求伪造，也称 XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。与 XSS 相比，XSS利用的是用户对指定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。

  预防：

  1.用户操作限制——验证码机制

  方法：添加验证码来识别是不是用户主动去发起这个请求，由于一定强度的验证码机器无法识别，因此危险网站不能伪造一个完整的请求。

  优点：简单粗暴，低成本，可靠，能防范99.99%的攻击者。

  缺点：对用户不友好。

  2.请求来源限制——验证 HTTP Referer 字段

  方法：在HTTP请求头中有一个字段叫Referer，它记录了请求的来源地址。 服务器需要做的是验证这个来源地址是否合法，如果是来自一些不受信任的网站，则拒绝响应。

  优点：零成本，简单易实现。

  缺点：由于这个方法严重依赖浏览器自身，因此安全性全看浏览器。

  额外验证机制——token，JWT

  面试相关：

  校招

  一般来说，校招面试流程分为1~3轮技术面和一轮HR面=》发放意向书=》发放Offer

  当然不排除某些大厂有4面，5面甚至6面，这种情况原因有很多：

  比如你自身很优秀，会有额外的面委会加面或者其他部门交叉面来定级，一般来说校招offer分为：

  白菜<SP<SSP

  还有一种情况就是面的人太多，需要额外面试来筛选

  2. 这里建议大家尽可能的优先选择内推，网申比较坑，内推是直接将简历发至HR手里

  3. 书籍推荐（复习和学习用）：

  前端相关：

  《JavaScript高级程序设计》，《JavaScript权威指南》，《JavaScript设计模式与开发实践》,《你所不知道的JavaScript》（上中下三卷）

  CS基础：

  《HTTP权威指南》，《图解HTTP》，《数据结构与算法》，《算法导论》，《编译原理》,《计算机操作系统》

  版权声明：本文来源于知了堂学员分享，转载请注明出处