前端技术日新月异，唯独基础不变，HTML/CSS/Javascript三座大山是前端技术的核心，随着端的演变，对前端工程师提出更高的要求，不仅仅是前端技术本身Webpack/Vue/React等框架使用，还要求掌握如Java、Python等，和APP原生的交互处理。如此，就前端本身而言，对自己的技术掌握有一个清晰的认识就显得尤为重要，技术更新让我们应接不暇，但万变不离其宗，回归基础，夯实基础，加深理解，是成为高级前端工程师的必经之路。
- 在开发项目中，往往难道我们的不是新的框架本身，而是最基础的技术使用，比如数组的方法，循环处理等等。
下面就从一个问题入手，分析盘点前端基础技术：
从输入URL到页面加载，中间都经历了什么？
这个问题在互联网技术行业统统适用，网络工程师、安全工程师、前端工程师、后端工程师等针对这个问题都会回答出侧重点不同的答案，下面重点从前端开发入手探讨这个过程：
- 输入URL
从浏览器接受url到开启网络请求线程：
-
浏览器进程/线程模型
浏览器是多进程的，有一个主控进程，以及每一个tab页面都会新开一个进程，进程可能包括主控进程，插件进程，GPU，tab页等。
browser_inner_thread.png
可以看到，里面的JS引擎是内核进程中的一个线程，这也是为什么常说JS引擎是单线程的。
- 解析URL
输入url，浏览器会进行解析：
URL一般包括几大部分：
1） protocol 协议头，如http,ftp等
2） host 主机域名或IP地址
3） port 端口号
4） path 目录路径
5） query 查询参数
6） fragment 即#后的hash值，一般用来定位到某个位置
- 浏览器查找域名的IP地址
- DNS查询得到IP
如果输入的是域名，需要进行dns解析成IP，大致流程：
1） 如果浏览器有缓存，直接使用浏览器缓存，否则使用本机缓存，在没有话使用host;
2）如果本地没有，就像dns域名服务器查询，查询到对应的IP.
注意：域名查询时有可能是经过CDN调度器的（如果cdn有存储功能的话）
而且需要知道dns解析是很耗时的，因此如果解析域名过多，会让首屏加载变得过慢，可以考虑dns-prefetch优化。 - TCP/IP 请求
http的本质是tcp/ip请求，需要了解3次握手规则建立连接以及断开连接时的四次挥手。
TCP/IP的并发限制
浏览器对同一域名下并发的TCP连接是有限制的（2-10个不等）
而且在http1.0中往往一个资源下载就需要对应一个TCP/IP请求
所以针对这个瓶颈，有出现了很多资源优化方案，如http2
Get和Post的区别
get和post虽然本质都是tcp/ip，但两者除了在http层面外，在tcp/ip层面也有区别。
get会产生一个tcp数据包，post两个，具体就是：
1） get请求时，浏览器会把headers和data一起发送出去，服务器响应200（返回数据）；
2） post请求时，浏览器现发送headers，服务器响应100 continue，浏览器再发送data，服务器响应200（返回数据）。
- 浏览器向web服务器发送一个HTTP请求
- 五层因特网协议栈
从客户端发出http请求到服务器接收，中间会经历一系列的流程。
简括就是：
从应用层的发送http请求，到传输层通过三次握手建立tcp/ip连接，再到网络层的ip寻址，再到数据链路层的封装成帧，最后到物理层的利用物理介质传输。
当然，服务器端的接收就是反过来的步骤。
五层因特网协议栈其实就是：
1） 应用层（dns,http）DNS解析成IP并发送http请求
2） 传输层（tcp,udp） 建立TCP连接（三次握手）
3） 网络层（IP, ARP） IP寻址
4） 数据链路层（PPP）封装成帧
5） 物理层 利用物理介质传输比特流
OSI七层框架：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层；
- 服务器处理请求
- 从服务器接收到请求到对应后台接收到请求
服务端在接收请求时，内部会进行很多的处理：
负载均衡
对于大型的项目，由于并发访问量很大，所以往往一台服务器是吃不消的，所以一般会有若干台服务器组成一个集群，然后配合反向代理实现负载均衡。简单的说：
用户发起的请求都指向调度服务器（反向代理服务器，譬如安装了nginx控制负载均衡），然后调度服务器根据实际的调度算法，分配不同的请求给对应集群中的服务器执行，然后调度器等待实际服务器的HTTP响应，并将它反馈给用户
后台处理
一般后台都是部署到容器中，所以一般为：
1）先是容器接受到请求（如tomcat容器）；
2）然后对应容器中的后台程序接收到请求（如java程序）；
3）然后就是后台会有自己的统一处理，处理完后响应响应结果。
概括下：
1）一般有的后端是有统一验证的，如安全拦截，跨域验证
2）如果这一步不符合，就直接返回相应的http报文（如拒绝请求）
3）然后当验证通过后，才会进入实际的后台代码，此时是程序接收到请求，然后执行（如查询数据库，大量计算等等）
4） 等程序执行完毕后，就会返回一个http响应报
5）然后就将这个包从后端发送到前端，完成交互。
- 服务器返回一个HTTP响应
- 后台和前台的htpp交互
前后端交互时，http报文作为信息的载体
http报文结构
报文一般包括了：通用头部，请求/响应头部，请求/响应体
1）通用头部
这也是开发人员见过的最多的信息，包括如下：
Request Url: 请求的web服务器地址
Request Method: 请求方式
（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）
Status Code: 请求的返回状态码，如200代表成功
Remote Address: 请求的远程服务器地址（会转为IP）
譬如，在跨域拒绝时，可能是method为options，状态码为404/405等
其中，Mthod的话一般分为两批次：
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
以及几种Additional Request Methods：PUT、DELETE、LINK、UNLINK
HTTP1.1定义了八种请求方法：GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
这里面最常用到的就是状态码，很多时候都是通过状态码来判断，如（列举几个最常见的）：
200——表明该请求被成功地完成，所请求的资源发送回客户端
304——自从上次请求后，请求的网页未修改过，请客户端使用本地缓存
400——客户端请求有错（譬如可以是安全模块拦截）
401——请求未经授权
403——禁止访问（譬如可以是未登录时禁止）
404——资源未找到
500——服务器内部错误
503——服务不可用
再列举下大致不同范围状态的意义
1xx——指示信息，表示请求已接收，继续处理
2xx——成功，表示请求已被成功接收、理解、接受
3xx——重定向，要完成请求必须进行更进一步的操作
4xx——客户端错误，请求有语法错误或请求无法实现
5xx——服务器端错误，服务器未能实现合法的请求
总之，当请求出错时，状态码能帮助快速定位问题
2）请求/响应头部
请求和响应头部也是分析时常用到的，常用的请求头部（部分）：
Accept: 接收类型，表示浏览器支持的MIME类型
（对标服务端返回的Content-Type）
Accept-Encoding：浏览器支持的压缩类型,如gzip等,超出类型不能接收
Content-Type：客户端发送出去实体内容的类型
Cache-Control: 指定请求和响应遵循的缓存机制，如no-cache
If-Modified-Since：对应服务端的Last-Modified，用来匹配看文件是否变动，只能精确到1s之内，http1.0中
Expires：缓存控制，在这个时间内不会请求，直接使用缓存，http1.0，而且是服务端时间
Max-age：代表资源在本地缓存多少秒，有效时间内不会请求，而是使用缓存，http1.1中
If-None-Match：对应服务端的ETag，用来匹配文件内容是否改变（非常精确），http1.1中
Cookie: 有cookie并且同域访问时会自动带上
Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如keep-alive
Host：请求的服务器URL
Origin：最初的请求是从哪里发起的（只会精确到端口）,Origin比Referer更尊重隐私
Referer：该页面的来源URL(适用于所有类型的请求，会精确到详细页面地址，csrf拦截常用到这个字段)
User-Agent：用户客户端的一些必要信息，如UA头部等
常用的响应头部（部分）：
Access-Control-Allow-Headers: 服务器端允许的请求Headers
Access-Control-Allow-Methods: 服务器端允许的请求方法
Access-Control-Allow-Origin: 服务器端允许的请求Origin头部（譬如为*）
Content-Type：服务端返回的实体内容的类型
Date：数据从服务器发送的时间
Cache-Control：告诉浏览器或其他客户，什么环境可以安全的缓存文档
Last-Modified：请求资源的最后修改时间
Expires：应该在什么时候认为文档已经过期,从而不再缓存它
Max-age：客户端的本地资源应该缓存多少秒，开启了Cache-Control后有效
ETag：请求变量的实体标签的当前值
Set-Cookie：设置和页面关联的cookie，服务器通过这个头部把cookie传给客户端
Keep-Alive：如果客户端有keep-alive，服务端也会有响应（如timeout=38）
Server：服务器的一些相关信息
一般来说，请求头部和响应头部是匹配分析的。
譬如，请求头部的Accept要和响应头部的Content-Type匹配，否则会报错
譬如，跨域请求时，请求头部的Origin要匹配响应头部的Access-Control-Allow-Origin，否则会报跨域错误
譬如，在使用缓存时，请求头部的If-Modified-Since、If-None-Match分别和响应头部的Last-Modified、ETag对应
3）请求/响应实体
http请求时，除了头部，还有消息实体，一般来说
请求实体中会将一些需要的参数都放入进入（用于post请求）。
譬如实体中可以放参数的序列化形式（a=1&b=2这种），或者直接放表单对象（Form Data对象，上传时可以夹杂参数以及文件），等等
而一般响应实体中，就是放服务端需要传给客户端的内容
一般现在的接口请求时，实体中就是对于的信息的json格式，而像页面请求这种，里面就是直接放了一个html字符串，然后浏览器自己解析并渲染。
CRLF
CRLF（Carriage-Return Line-Feed），意思是回车换行，一般作为分隔符存在
请求头和实体消息之间有一个CRLF分隔，响应头部和响应实体之间用一个CRLF分隔
一般来说（分隔符类别）：
CRLF->Windows-style
LF->Unix Style
CR->Mac Style
浏览器开始渲染页面HTML
浏览器发送请求获取嵌入在HTML中的资源
浏览器发送异步请求
