输入URL到页面加载——从服务器接收到请求到对应后台接收到请求
负载均衡
对于大型的项目，由于并发访问量非常大，所以往往一台服务器是吃不消的，一般会有若干台服务器组成一个集群，然后通过配合反向代理实现负载均衡。
这里实现负载均衡的方式有很多种，我们以比较熟悉的方向代理负载均衡为例，先来看看它的调度算法：
1.weight(轮询)
接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台服务器宕机，nginx会自动将这台服务器剔除队列，请求受理的情况不会受到任何影响。在这种方式下，可以给不同的后端服务器设置一个权重值，用于调整不同的服务器上请求的分配率，权重数据越大，被分配到的几率越大，该权重值主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
2.ip_hash
每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法保证了下一个固定ip地址的客户端总是会访问到上一次访问的服务器，这也在一定程度上解决了集群服务器环境下session共享问题。
3.fair
动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少。默认nginx不支持此算法，需要安装upstream_fair模块。
4.url_hash
按照访问的url的hash结果分配请求，每个请求的url会指向后端的固定服务器，可以在nginx作为静态服务器的情况下提高缓存效率，同样nginx也不支持此算法，需要安装hash包。
HTTP1.0、HTTP1.1、HTTP2.0和HTTPS
HTTP1.0
http/1.0最大的问题是连接无法复用，比如浏览器页面中包含很多同一服务器下的图片，那么使用http/1.0协议的话会导致连接无法复用，每次连接都会造成资源的浪费。尤其在高延迟的3次握手阶段以及大文件的慢启动阶段导致用户的体验遭到影响。
HTTP1.1
为了客户http/1.0的缺陷，http/1.1使用长连接的访问机制，即在在过期时间内一个TCP连接中可以传送多个http请求，以此来减少建立和关闭连接的消耗和延迟。
HTTP2.0
相对于http/1.1来说浏览器再同一时间对同一域名的请求是有最大限制的。http/2.0通过多路复用技术，同一个tcp请求可以请求多个资源。
以下是http/2.0的新特性：
1.多路复用
2.首部压缩
3.二进制分帧
4.服务器端推送
5.请求优先级设置
HTTPS
https就是安全版本的http，譬如一些支付操作就需要用到https协议。
下面简述SSL/TLS协议的握手流程：
1.浏览器请求建立SSL连接，并向服务端发送一个随机数（Client-Random）和客户端所支持的算法。
2.服务端选出一组算法，并回复一个随机数（Server-Random）,并将安全证书（公钥包含其中）发送给浏览器。
3.浏览器收到服务器的证书后，首先会生成第三个随机数（Premaster-secret），并且会验证证书是否合法有效。并通过约定好算法与服务器发送的公钥进行加密这个随机数。
4.服务器使用自己的私钥获取这个随机数的“真面目”。
5.服务器使用约定的算法，以及之前的三个随机数，生成对话密钥（session key）,用来加密之后的过程。
GET和POST区别
上文中，我们提到应用层HTTP协议规定的数据的规范，实际用于传输的协议是TCP/IP协议。并且针对不同浏览器上GET和POST的实践也有些不同，所以这里我们不讨论传输层或不同浏览器中GET和POST的区别，我们只讨论在语义上两者所带来的区别。
GET表达的是一种幂等的，只读的操作。讲通俗一些，就是他只查数据，而不会对数据做任何操作，因此对于大部分GET请求都可以被缓存下来，这能大大减少服务器的压力。
POST相对于GET表达的是非幂等的，并且对数据有影响的操作，这些必须通过服务器进行处理。
若把GET请求全被换成POST请求，首先所有的CDN全部废掉了，服务器的压力将变得巨大。
GZIP压缩
开启GZIP压缩的好处显而易见，一般文本可以将其压缩至原大小的60%，从而提升请求的效率。如果想要开启GZIP传输的话，需要后端容器进行配置，开启压缩功能。
浏览器发送请求给Web服务器，request中有Accept-Encoding：gzip，deflate。这里表示浏览器支持GZIP压缩，请服务器帮忙压缩后再进行相应。
服务器通过LZ77算法和哈夫曼编码对其response进行压缩后发送给浏览器。浏览器再对其进行解码，再将其展示在页面上。
需要注意的是，GZIP对于压缩图片这部分会大大增加服务器的CPU压力，并且压缩效果也不好，所以不太推荐针对图片进行压缩。
长连接与短连接
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就会建立一次连接，任务结束就中断连接。
而从HTTP/1.1开始，默认使用长连接，用以保持连接活性。使用长连接，会在响应头加入这行代码。
Connection: keep-alive
在使用长连接的的情况下，当一个网页打开完成后，客户端与服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个过期时间，可以在不同的服务器软件中设定这个时间。
实现长连接需要客户端和服务端都支持长连接，HTTP长连接和短连接实际上是TCP协议的长连接和短连接。
缓存问题
缓存可以简单的分为两种类型：
强缓存（200 from cache）,浏览器判断本地缓存未过期的话，就直接使用，不会发起http请求。
协商缓存（304），浏览器会向服务器发送请求，然后服务端告诉浏览器文件未改变，让浏览器使用缓存。
并且针对于http/1.0缓存中的不足，http/1.1提出了一些新的内容：
| 协议名称 | http/1.0 | http/1.1 |
|---|---|---|
| 控制头部 | Pragma，可以通过设置no-cache让缓存失效 | Cache-Control，有no-cache，max-age等多种取值 |
| 过期时间 | Expires，服务端配置，一般为服务端时间 | Max-Age，服务端配置，一般为浏览器时间 |
| 协商内容 | If-Modified-Since/Last-Modified，表名服务端文件最后何时改变，并通过两者进行对比验证，只能精确到1秒 | If-None-Match/E-tag，类似于md5，只要文件变了E-tag就变了,没有时间限制 |
浏览器本地存储方案
Cookie
1.大小受限制，cookie大小被限制在4KB。
2.cookie的实现是通过扩展HTTP协议实现，cookie存储的内容将保留在请求头中。并且对于同源的请求中，每次cookie都在浏览器和服务器中传输，这样会造成不必要的资源浪费。一般优化的方案是通过拆分服务器域名，将静态资源，请求多的服务器和使用cookie的服务器进行分离.
3.对于服务器来说处理cookie非常方便，但是通过js处理cookie虽然有很多很棒的库帮忙，但是本质上还是通过正则表达式来进行分割处理。
SessionStorage
1.大小为5M，可以存储较多的数据。
2.sessionStorage与服务器的session类似，它是会话级别的缓存，关闭浏览器后将被清除。
3.不同窗口不可以共享sessionStorage。
4.他非常方便的API。
LocalStorage
1.大小为5M，同sessionStorage。
2.他是一种持久化方案，如果说不手动清除得话，数据是不会过期的。
3.不同窗口，非跨域情况可以共享。
总结
上文说到，服务器已经接受到了通过tcp/ip协议发送过来的数据了，此时这台服务器如果是反向代理服务器的话，还会根据负载均衡将请求派发到具体的容器中。对应容器又会将请求转交到后台接口中，此时如果涉及到权限验证，跨域验证等没有通过的话，将直接根据对应的http协议返回响应结果，拒绝请求。只有通过了验证才能进行访问数据库等操作，等程序执行完毕后，将返回一个http响应包，重复上文的过程，完成交互。