HTTP&HTTPS过程 包括渲染
用户在浏览器输入URL
- 首先,将有浏览器创建一个新的线程，新的线程解析URL，如果发现协议是http，进入web流程。
- 进行DNS解析域名，获取真实IP。
- 首先，浏览器会向自身缓存查询，
- 若没有，将向操作系统内部查询，系统查询自身缓存与Hosts文件，
- 若没有，将向服务器运营商114.114.114.114（电信）/8.8.8.8(Google)查询。
- 通过IP进行TCP连接。
- 首先，由客户端，向服务器发送SYN，seq=X。
- 服务器收到后，由服务器发送SYN，ACK=X+1，Seq=Y。
- 客户端接收到，由客户端发送，Seq=X+1，ACk=Y+1。
- 发送http报文。
- 浏览器向服务器发送请求行，如：
GET \ HTTP1.1。 - 浏览器向服务器发送请求头，
Connection: keep-alive Cache-Control: max-age=0。 - 浏览器发送空行告知服务器请求头发送完毕，若请求方式不为
POST，将结束此次发送。 - 服务器应答，发送协议版本与状态，
HTTP/1.1 200 OK - 服务器发送应答头。
Content-Type: text/html;charset=utf-8 - 服务器发送空行，告知客户端应答头发送完毕。
- 服务器发送消息体，包含客户端需要的资源。
- 如果
Connection: Keep-Alive，将保存TCP连接，便于下次发送http请求，否则将关闭TCP连接
- 浏览器向服务器发送请求行，如：
- 浏览器接收到服务器发送资源。（渲染HTML）
- 从
<html>标签开始，顺序构建DOM树。 - 碰到
<link>加载的css时，异步加载css文件。 - 浏览器在代码中发现一个
标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码。（图片未设置宽高时，会发生重排，影响性能）
- 浏览器遇到
<script>标签时（非外部引入），将暂停渲染，直到js脚本执行完毕。 - 将异步css文件整上，重新渲染。
- 从
TCP为什么要三次握手与四次挥手
位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)
三次握手原因
TCP连接后，因为是可靠协议，双方必须保证不会丢失任何一个数据包，这样就必须在各自维护一个序列号(Seq),当我接受到对方发送的(假设客户端发送消息，服务端响应)Seq=X+n+1,自身必须做出回应ACK=X+n+1+1,意思为接收到此次请求，客户端接收到ACK=x+n+1+1时，会将自身序列号加一，则，若有下次请求将发送Seq=x+n+1+1
如果改为两次握手，服务器得不到客户端回应，则无法确认自己的信息是否能安全、可靠地被客户端响应。
如果改为四次握手，则造成了资源的浪费。
四次挥手原因
确保数据能够完整传输。
当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。
但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，
再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。
HTTPS请求过程
HTTPS并不是新的协议，而是HTTP+SSL/TLS,(SSL是TLS前身)，想要了解HTTPS在建立连接时发送的数据包会比较复杂，个人推荐Anduin大佬的非对称加密算法与传输安全详解（我真的很推荐），本文只是讲解HTTPS与HTTP的不同，与为什么HTTPS更加安全（非对称加密初探）。
建立连接
和HTTP一样，HTTPS也是通过TCP/IP协议，建立TCP连接，不同的是，我们在浏览器中输入https://domain.com，浏览器解析后发现这是个https请求后，浏览器会使用SSL协议进行秘钥交换。
（以下步骤简化于《图解HTTP》）
- 由客户端发送
Hello报文开始通信； - 服务器可以进行
ssl连接，向客户端发送自己的公钥； - 客户端收到服务器公钥，通过公钥加密一串随机数，得到对称加密密钥，并将此密钥发送至服务器；
- 服务器得到对称加密秘钥，并在之后通信中使用它。
- 之后，我们回归到HTTP通信，当然是收到SSL保护过的。
HTTPS优缺点
优点：现代浏览器中使用HTTPS你真的可以相信它真的安全。
缺点：每一次加密、解密都会消耗一定资源。
参考
如有错误 望请指正 共同学习 不胜感激
