http/HTTPS相关的一些知识(包含前端的一点知识）

（http是什么，报文格式，http特点以及会话技术，缓存，长短连接，http版本演进，https）

浏览器从输入 URL 开始到页面显示内容，中间发生了什么？
1.进行DNS解析。如果有缓存（浏览器，操作系统，本地DNS服务器）直接找到对应的IP地址，否则，（未开启转发模式下）会分别向根域名服务器，顶级域名服务器…直到找到对应的，然后本地DNS服务器将这个IP送回发送端。其中客户机和本地DNS服务器之间的是递归查询，本地DNS服务器和其他DNS服务器之间的查询是迭代查询。
2、TCP三次握手建立连接；
3.开始发送 HTTP 请求报文。请求行包含请求方法、URL、协议版本；请求头包含请求的附加信息，由关键字/值对组成（Host，表示主机名，虚拟主机；Connection,HTTP/1.1 增加的，使用 keepalive，即持久连接，一个连接可以发多个请求；User-Agent，请求发出者，兼容性以及定制化需求。）请求体，可以承载多个请求参数的数据
4、如果有数据一切正常（状态码200），当浏览器拿到服务器的数据(html)之后，开始渲染页面同时获取HTML页面中图片、音频、视频、CSS、JS，在这期间获取到JS文件之后，会直接执行JS代码，阻塞浏览器渲染，因为渲染引擎和JS引擎互斥，不能同时工作，所以通常把Script标签放在body标签的底部。渲染过程就是先将HTML转换成dom树，再将CSS样式转换成stylesheet，根据dom树和stylesheet创建布局树，对布局树进行分层，为每个图层生成绘制列表，再将图层分成图块，紧接着光栅化将图块转换成位图，最后合成绘制生成页面。
5/当数据传送完毕，需要断开 tcp 连接，此时发起 tcp 四次挥手

DNS是什么：
DNS（Domain Name System，域名系统），因特网上作为域名和IP地址互相映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机对应的IP地址的过程叫做域名解析（或主机名解析）。DNS协议运行在UDP协议之上，使用端口号53。
解析过程已经清楚了，如果有缓存直接返回缓存，没有的话，如果是转发模式，就是访问上一级，没有继续上一级；而不是转发模式就是直接根域名服务器，再找下一层…最终通过本地DNS服务器给用户，并把这个映射缓存起来。
分布式，所以DNS服务器也有主从之分，从DNS可以分担查询的压力和速度，主从之间的备份是基于TCP协议的。
CDN是什么？
CDN主要功能是在不同的地点缓存内容，通过负载均衡技术，将用户的请求定向到最合适的缓存服务器上去获取内容，比如说，是北京的用户，我们让他访问北京的节点，深圳的用户，我们让他访问深圳的节点。通过就近访问，加速用户对网站的访问。解决Internet网络拥堵状况，提高用户访问网络的响应速度。

2、http和https
HTTP超文本传输协议，超文本传输协议，规定了浏览器和服务器之间数据传输的规则，也就是如何将html从服务器传到浏览器。HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80。
http的通信过程：服务器在80端口等待客户的请求；接着浏览器发起到服务器的TCP连接，服务器接受TCP连接，然后浏览器和服务器交换http消息，最后关闭TCP连接。
可以看出，http是基于tcp的。是可靠的，请求相应一一对应。

html是什么？html，css和JavaScript是什么关系
总结：如果把HTML比做身体，那CSS就好比是衣服，而JavaScript则意味着人能做的一些高级动作。
html用各种标签将页面中的元素组织起来，告诉浏览器该如何显示其中的内容,重在内容组织上。
CSS是用来修饰内容样式的（重在内容样式美化展示上）CSS是层叠样式表的简称，它用来表现HTML文件样式的，简单说就是负责HTML页面中元素的展现及排版。
JavaScript是用来做交互的
JavaScript是一种脚本语言，即可以运行在客户端也能运行在服务器端。JavaScript的解释器就是JS引擎，JS引擎是浏览器的一部分。而JavaScript主要是用来扩展文档交互能力的，使静态的HTML具有一定的交互行为（比如表单提交、动画特效、弹窗等）。

http协议的特点：
简单：头部主要规定请求方法和请求路径url；灵活：HТТР允许传输任意类型的数据对象，Content_Type加以标记
无状态HTTP协议是无状态协议：无状态指的是客户端发送HTTP请求给服务端之后，服务端根据请求响应数据，响应完后，不会记录任何信息。这种特性有优点也有缺点，缺点是无法共享数据。无状态的，因此无法做连续多个步骤的操作。例如：加入购物车，结算，支付。每次都需要验证身份信息，但是无状态所以无法连续。解决办法就是利用会话技术(Cookie、Session,token)。优点就是速度快。
http1.1之后支持长连接

** cookie,session,token区别**
http是无连接的，这次请求和上次请求没有关系。但是如果需要数据共享，追踪用户行为（购物车）就需要知道用户信息。
cookie是一种存储在浏览器的字段信息，只有4kb，以键值对形式存在。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态（登录，购物车，个性化设置等）。一般访问流程：用户http请求；服务器在响应头加一个set-cookie选项，里面包含cookie。之后用户再发送http请求时就会把cookie信息加在请求部分里面，服务器就会进行相应的业务响应。
cookies也分为两种，一是会话cookies，浏览器关闭会话结束cookies失效，还有是persistent cookies永不失效或者特定时间失效。
session和cookie看起来很像。但是我们要分清session概念和session实现。session就是一个会话，相当于给服务器和浏览器建立一个连接。那么session的实现就是利用cookie为载体的，服务器会为每个浏览器产生一个独一的session id来标识连接，之后每次请求只要把id放在请求头部就可以知道浏览器是谁了。而一些用户信息上下文信息(比如操作记录)都是存储在服务器中，请求时只需要复制id就可以。而这个id往往就是通过cookie实现的。也就是说cookie是实现session id传递的载体之一。如果浏览器禁用cookie的话，session id也可以通过url重写实现。
所以综合来说，cookie很具体，就是一种服务器生成，存储在浏览器上的小字段，实现鉴权的具体方式。而session是一种宽泛的会话技术，通过session id标识，为服务器浏览器建立连接。
区别总结：
1、cookie存储在浏览器中，所以安全性较差，容易被劫持伪造（httponly是微软对cookie的扩展，不允许客户端的脚本访问，如果不设置的话很有可能cookie中包含的敏感信息被劫持，实现一些跨站脚本攻击XSS）；session只有id在浏览器中，具体信息存储在服务器中，安全性好一点，但是会增加服务器的负担，而且多个服务器的话负载均衡后很有可能找不到了。比如自动保存的密码等。
2、cookie只有4kb大小，只能存ASCII字符，而session存储信息不限，类型也很多。

token:包含（id,时间戳，一段签名防止恶意拼接）原理类似于cookie，也是存储在客户端的，只不过多了一个加密的步骤（JWT json web token），服务器解密，就可以防止信息泄露。
同时，它也解决了session存储在服务器导致服务器压力大，以及负载均衡session失效的问题。应用中，比如高压力的服务器瓶颈可以把鉴权的token放在外部减轻鉴权压力，比如防止redis缓存穿透用布隆过滤器判断元素是否存在，这些都体现了外部减轻主要服务器压力的思想。
另外token还可以抵御CSRF攻击（跨站请求伪造攻击）：这个攻击就是比如你登陆了网站A,获得了cookie，然后再登录网站B，B有一些恶意代码，让你登录A，这样A以为是用户登录，允许登录并执行一些不是用户本身想要做的事。按理说也属于XSS攻击的一种，通过拼接恶意的JS语句执行未授权操作。所以httponly只能让别人不能获取cookie，但是不能防止别人用你的cookie登录网站做一些事。因为post等请求不受同源策略限制，导致不同源的网页可以共享cookie，从而利用js脚本做一些恶意交互。

同源策略和跨域问题
同源策略是浏览器安全功能，阻止一个域的js脚本和另一个域的内容进行交互，用于隔离潜在恶意文件，防止恶意网站窃取用户数据（不同源的网页不能共享cookie,获取dom,ajax请求）
当协议（http，https）域名（cc.com）端口号有一个不同就是跨域；
几乎任何时候安全性和便捷性都是负相关的，所以浏览器做了平衡，比如img,script,style等允许跨域引用，但是引用并不能读取资源的内容。

关于XSS攻击：
16. XSS攻击是什么?如何避免？
XSS攻击全称跨站脚本攻击（前端注入），注入攻击的本质，是把用户输入的数据当做前端代码执行（比如SQL注入）。
。XSS拼接的是网页的HTML代码，一般而言我们是可以拼接出合适的HTML代码去执行恶意的JS语句。在渲染DOM树的时候，执行了不可预期的JS脚本，从而发生了安全问题。（信息泄露、未授权操作、弹窗关不掉等）
常见的 XSS 攻击有三种：反射型XSS攻击、DOM-based 型XXS攻击以及存储型XSS攻击。
反射型 XSS 一般是攻击者通过特定手法（如电子邮件），诱使用户去访问一个包含恶意代码的 URL，当受害者点击这些专门设计的链接的时候，恶意代码会直接在受害者主机上的浏览器执行。反射型XSS通常出现在网站的搜索栏、用户登录口等地方，常用来窃取客户端 Cookies 或进行钓鱼欺骗。
例子：张三做了一个超链接发给阿伟，超链接地址为：http://www.xxx.com?content=。
这样，只要你打开文章，就会丢失cookie信息，危害更大。
基于 DOM 的 XSS 攻击是指通过恶意脚本修改页面的 DOM 结构，是纯粹发生前端的攻击。属于前端 JavaScript 自身的安全漏洞。常见于类似JSON转换、翻译等工具区。
防御：1.对用户向服务器提交的信息（URL、关键字、HTTP头、POST数据等）进行检查，仅接受规定长度、适当格式、预期内容，其余的一律过滤。
2.对输入内容的特定字符进行编码，例如表示 html标记的 < > 等符号。
3. 对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie.
4. 确定接收到的内容被规范化，仅包含最小最安全的tag（不含JavaScript），去掉对任何远程内容的引用（尤其是样式表和JavaScript）

http的请求响应报文结构：

总结：三部分
第一是请求方法（get post put delete trace（回显服务器收到的请求用于测试），option查看服务器性能） 请求URL http版本
第二是一些参数键值对形式（包括长短连接，传输数据长度和类型，缓存策略，host（ip+port）,爬虫用的user-agent，接受的压缩方式，cookie等）
第三就是报文体,post上传资源到服务器
（注意一些格式）

get post put delete等区别
这些都是http定义的与服务器进行交互的不同方法。
从数据库角度来说，get相当于查询，从服务器查询相关数据； post是增加服务器的资源;delete是删除资源；put是修改服务器的资源。
还有其余的，head用来查询头部信息，不返回实体信息；trace用来回环诊断，回显服务器收到的请求，因为请求传递过程中会经过防火墙等，trace查看请求中途是否被更改；options允许客户端查看服务器性能；

由于put是幂等的，也就是如果两次请求相同，那么第二次会覆盖第一次，所以put用来更新资源；而post是非幂等的，不会覆盖，所以用来添加资源。

重点是get和post的区别和联系：
1.一个请求数据，一个上传数据；
2、安全性：get因为参数会放在url中，，get请求会保存在浏览器历史，可保存为书签，所以隐私性，安全性较差，post的数据在body中。
3、数据长度：由于get的请求放在url中，虽然http对url长度没有限制，但是服务器了浏览器有限制，一般在1024字节以内。因为长url解析消耗性能太大，并且容易收到恶意构造长url的攻击。post由于数据放在body中，所以没有限制。示例如下：

GET /updateInfo?name=Javanx&age=25 HTTP/1.1
Host: localhost

POST /updateInfo HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
name=Javanx&age=25

GET 和 POST 只是 HTTP 协议中两种请求方式（异曲同工），而 HTTP 协议是基于 TCP/IP 的应用层协议，无论 GET 还是 POST，用的都是同一个传输层协议，所以在传输上，没有区别。
但如果不按规范来也是可以的，可以在 URL 上写参数，然后方法使用 POST；也可以在 Body 写参数，然后方法使用 GET。当然，这需要服务端支持。
GET 方法参数写法是固定的吗？
在约定中，我们的参数是写在 ? 后面，用 & 分割。
我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。
POST 方法比 GET 方法安全？
有人说POST 比 GET 安全，因为数据在地址栏上不可见。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。

要想安全传输，就只有加密，也就是 HTTPS。
POST 方法会产生两个 TCP 数据包？
有些文章中提到，post 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。
HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试(Chrome)发现，header 和 body 不会分开发送。
所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。

URL,URI区别：
uri是资源标记符，url是资源定位符。uri表示资源的名字，url表示它的路径。相当于绝对路径和相对路径了。

响应头第一行是版本，状态码及其描述。
后面是一些参数，比如服务器名称，时间，缓存策略，数据长度类型等。
响应体就是html代码（包含了CSS,JS）

常见的状态码：
100-199 用于指定客户端应相应的某些动作。
200-299 用于表示请求成功。
300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。永久，暂时，缓存重定向
400-499 用于指出客户端的错误。
500-599 用于支持服务器错误。

如果服务器收到头信息中带有100-continue的请求，这是指客户端询问是否可以在后续的请求中发送附件。(比如post先发送head，回复100再发送请求体。）
200 OK：客户端请求成功。
300表示被请求的文档可以在多个地方找到，并将在返回的文档中列出来。如果服务器有首选设置，首选项将会被列于定位响应头信息中。
301 状态是指所请求的文档在别的地方;文档新的URL会在定位响应头信息中给出。浏览器会自动连接到新的URL。永久重定向。
302：页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持或负载均衡
304 告诉客户端可以使用缓存资源
403 Forbidden：指的是服务器端有能力处理该请求，但是拒绝授权访问。404 Not Found：请求资源不存在，比如资源被删除了，或用户输入了错误的URL。
408 (Request Timeout/请求超时)
500 Internal Server Error：服务器发生不可预期的错误，一般是代码的BUG所导致的。500 (SC_INTERNAL_SERVER_ERROR) 是常用的“服务器错误”状态。该状态经常由CGI程序引起
502 (Bad Gateway/错误的网关)
503 服务器繁忙

HTTP 缓存技术
对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了。HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存
强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。
强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：
Cache-Control， 是一个相对时间；public代表所有内容都缓存，private-"username"只针对单个用户缓存，no-cache:服务器取数据，no-store:不缓存，max-age：失效时间。
Expires，是一个绝对时间；
如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，Cache-Control 的优先级高于 Expires

当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

所以总体流程就是：第一次肯定没有缓存，根据请求头确定是否缓存以及失效时间以及etag,last-modified等。
再次请求时，如果缓存没过期，就执行强制缓存返回200很快。过期了依次判断etag,last-modified,只要有一个可以就304从缓存读取（也可能200,），都不可以就访问服务器200.

** 谈一谈http长连接、短连接、超时**
明确一个概念，http是无状态的应用层协议，没有长短连接一说，请求响应和下一次没有关系的。这里的长连接实际上是指TCP连接。
短连接就是这一次请求响应结束后，下一次请求响应就要重新建立TCP连接。Connection:close就是短连接
长连接就是TCP连接不关闭，下一次请求响应就不用再三次握手四次挥手了，减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等。http1.0默认是短连接，1.1默认是长连接。
一般长连接就是在请求头设置：Connection:keep-alive 和Keep-Alive: timeout=60。有timeout说明60s后连接失效，没有的话说明连接一直有效。
对于点对点的，交互频繁的。比如数据库就是长连接。对于web网页这种，用户很多，一般用短连接。不然的话会有成千上万的连接同时保存在服务器端。
长连接还有一个额外的问题，就是队头阻塞。在请求应答过程中，如果出现任何状况，剩下所有的工作都会被阻塞在那次请求应答之后。
解决办法：现代浏览器会针对单个域名开启6个连接，通过各个连接分别发送请求。它实现了某种程度上的并行，但治标不治本。
HTTP/2是完全多路复用的，而非有序并阻塞的。http2在一个连接上处理多个请求，实现流式传输，将请求分片，每个请求都有自己的id标识，到达服务器后再组装起来。这样就实现多路复用，提高效率。

超时的情况：请求超时，比如现在网络超级不好，当客户端发起一个请求，通信层开始请求与服务器建立连接（包括在重试），如果在5S之内还没有连接到服务器，那么认为超时。
响应超时一个不正确的url，将会响应404。或者服务器响应速度太慢，连接已经关闭。

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。可以理解成HTTPS = HTTP + SSL/TLS。默认端口号是 443。SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。
SSL/TLS的核心要素是非对称加密。非对称加密采用两个密钥——一个公钥，一个私钥。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。
常用的非对称加密算法：RSA。
常见的对称加密算法有：DES、3DES和AES
在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密。

https的主要步骤：1、客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。2、Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端/。3、客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。4、客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。5、Web服务器利用自己的私钥解密出会话密钥。6、Web服务器利用会话密钥加密与客户端之间的通信。
结合了对称加密和非对称加密的方式。
数字签名实现完整性。数字证书CA实现身份认证。加密实现密文传输。

http协议各个版本的演进
http1.0 默认是短连接，效率不高。
http1.1默认是长连接。另外，支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。（缺点:请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大;队头阻塞（因为先发送的要先收到响应，所以如果第一个响应很慢，后面的要等）；请求只能从客户端开始，服务器只能被动响应）
http2的改进：（是基于https的）
头部压缩
HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。
并行发送：针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，服务器也可以同时发送自己已生成的响应数据流。也就是 HTTP/2 可以并行交错地发送请求和响应。
服务器推送：客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。
HTTP/2 的缺点：
但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
TCP 的队头阻塞并没有彻底解决 TCP 为了保证可靠传输，有一个**“超时重传”机制，丢失的包必须等待重传确认**
多路复用导致服务器压力上升，多路复用没有限制同时请求数。请求的平均数量与往常相同，但实际会有许多请求的短暂爆发，导致瞬时 QPS 暴增

HTTP/3 做了哪些优化
所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

无队头阻塞
更快的连接建立
对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。
HTTP/3 在传输数据前虽然需要 QUIC 协议握手，但是这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。
但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商
连接迁移
而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

https的RSA握手解析
包含四次握手和一次客户端验证证书的过程。

所以通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。
因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。（RSA）
第一次：客户端首先会发一个「Client Hello」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

第二次：确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random）。接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。
然后，服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。
服务端发「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了。
客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

接下来客户端会进行验证证书
数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充。说简单些，证书就是用来告诉客户端，该服务端是否是合法的，因为只有证书合法，才代表服务端身份是可信的。服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度。
第三次握手
客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Client Key Exchange」消息传给服务端。服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。
至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。
于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。
生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。然后，客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

第四次握手
服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

RSA 算法的缺陷
使用 RSA 密钥协商算法的最大问题是不支持前向保密。
因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法。

ECDHE 密钥协商算法是 DH 算法演进过来的，所以我们先从 DH 算法说起。
DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是离散对数。
使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间。
具体的就不说了。