浏览器的三次握手：
第一次握手：客户端发送网络包，服务端收到了。这时候服务端的都结论：客户端的发送能力、服务端的接受能力正常。
第二次握手：服务端收到网络包会给客户端响应，这时候服务端发送网络包，客户端收到了，此时的服务端得出结论：服务端的发送能力没有问题，因为客户端没有给服务端响应。
第三次握手：客户端收到网络包后，给服务端响应，这时候客户端给服务端发送网络包，服务端收到了，此时服务端得出结论：客户端的发送、接受能力没有问题，自己的发送，接受能力也没有问题。
浏览器的四次挥手：
建立一个连接需要三次握手，而终止一个连接要经过四次挥手，这是由于TCP的半关闭造成的，所谓的半关闭就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
TCP 的连接的拆除需要发送四个包，因此称为四次挥手，客户端或服务端均可主动发起挥手动作。
- 第一次挥手：客户端A发送一个FIN.用来关闭客户A到服务器B的数据传送
- 第二次挥手：服务器B收到这个FIN. 它发回一个ACK，确认序号为收到的序号+1。和SYN一样，一个FIN将占用一个序号
- 第三次挥手：服务器B关闭与客户端A的连接，发送一个FIN给客户端A
- 第四次挥手：客户端A发回ACK报文确认，并将确认序号设置为序号加1
GET 和 POST 请求的区别：
GET 参数通过url传递，POST 放在 body 中。（http 协议规定，url在请求头中，所以大小限制很小）
GET 请求在url中传递的参数是有长度限制的，而 POST 没有。原因见上↑↑↑
GET 在浏览器回退时是无害的，而 POST 会再次提交请求
GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置
GET 比 POST 更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息
对参数的数据类型，GET 只接受 ASCII字符，而 POST 没有限制
GET 请求只能进行url(x-www-form-urlencoded)编码，而 POST 支持多种编码方式
GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。对于 GET 方式的请求，浏览器会把 http 的 header 和 data 一并发送出去，服务器响应200（返回数据）。而对于 POST，浏览器先发送 header，服务器响应100 continue，浏览器再发送 data，服务器响应200 ok（返回数据）
HTTPS 与 HTTP 区别
1.HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
2.HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
3.HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4.HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
HTTPS 介绍：HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。
Web性能优化：
一、尽量减少前端HTTP请求
浏览器并发线程数有限，所以针对资源文件的优化，一般有：
1、 合并脚本文件和CSS文件
2、 CSS Sprites利用CSS background相关元素进行背景图绝对定位,把多个图片合成一个图片。
二、浏览器缓存
在用户浏览网站的不同页面时，很多内容是重复的，比如相同的JS、CSS、图片等。如果我们能够建议甚至强制浏览器在本地缓存这些文件，将大大降低页面产生的流量，从而降低页面载入时间。
1、添加Expires头和Cache-Control
Expires头，浏览器端根据过期时间选择是否加载最新的版本。缺点是：需要服务器和客户端时间的严格同步，
HTTP1.1引入了Cache-Control头来克服Expires头的限制。Cache-Control使用max-age制定组件被缓存多久，使用秒为单位，例如Cache-Control：max-age=3600；表示组件将被缓存60分钟。如果max-age和Expires同时出现，则max-age有更高的优先级，浏览器会根据max-age的时间来确认缓存过期时间。
2、Last-Modified
在上次传输中，服务器给浏览器发送了Last-Modified或Etag数据，再次浏览时浏览器将提交这些数据到服务器，验证本地版本是否最新的，如果为最新的则服务器返回304代码，告诉浏览器直接使用本地版本，否则下载新版本。一般来说，有且只有静态文件，服务器端才会给出这些数据。
三、页面压缩
- 1、GZIP
- IE和Firefox浏览器都支持GZIP解码。后端服务器容器对数据GZIP压缩之后在传输到客户端，浏览器拿到数据后根据 Content-Encoding：gzip 进行解压，这样虽然稍微占用了一些服务器和客户端的CPU，但是换来的是更高的带宽利用率。对于纯文本来讲，压缩率是相当可观的。
- 2，HTML压缩
- 3，JS压缩 混淆
- 4，CSS压缩
- 5，图片压缩，展示尺寸和图片尺寸吻合
四、HTML代码结构优化
1，正确布置行内脚本
- 尽可能使用外部脚本和样式文件
- 脚本尽可能移到底部
- 脚本放在顶部带来的问题，
1） 使用脚本时，对于位于脚本以下的内容，逐步呈现将被阻塞
2） 在下载脚本时会阻塞并行下载
放在底部可能会出现JS错误问题，当脚本没加载进来，用户就触发脚本事件。所以要综合考虑情况。 - Script延迟加载 defer属性(IE & FF3.1+)、setTimeout
- 风险：行内(内联)脚本在样式表后面。
所有主流浏览器都会保持CSS和JavaScript的顺序。在样式表完全下载、解析及应用之后，内联脚本才能执行。同时，必须在内联脚本执行后，剩余资源才能下载。
CSS的下载解析可以和其他资源并发执行。
2，少用iframe
优点：可以和主页面并行加载
缺点： iframe会阻塞onload事件 解决：onload事件后设置iframe的src，或者JS创建iframe节点
和主页面使用同一个连接池
避免src为空—为空默认为主页面地址
3，减少DOM结构的层级
DOM层级越深会增加 CSS rule Tree 和 Dom Tree 匹配构造的性能
4，减少Cookie的大小
5，尽量用div取代table，或者将table打破成嵌套层次深的结构
table会影响页面呈现的速度，只有table里的内容全部加载完才会显示。
五、组件分成多个域
主要的目的是提高页面组件并行下载能力。但不要跨太多域名，建议采用2个子域名。
六、图片懒加载
七、图片，脚本，数据 预加载
八、图片base64
九、根据业务实际情况优化，保证首屏加载时间。
前端优化可以避免我们造成无谓的服务器和带宽资源浪费，但随着网站访问量的增加，仅靠前端优化已经不能解决所有问题了，后端程序处理并发请求的能力、程序运行的效率、硬件性能以及系统的可扩展性，将成为影响网站性能和稳定的关键瓶颈所在。