https的TLS的四次握手流程_CA机构在其中的作用_backlog参数在握手中的作用
https的TLS的四次握手流程
四次握手是三次握手之后进行对http加入安全性引入的，在应用层和tcp层加入tls/ssl协议保证传输的安全性，这就需要四次握手。对称加密不安全，容易被窃取，tls采用非对称加密算法，服务端向ca机构申请证书，ca机构提供公钥和私钥，通过证书把公钥传给浏览器，浏览器使用公钥加密最终生成密钥给服务端，之后使用密钥进行通信，保证安全性，ca机构生成数字签名的算法可以保证原文内容被窃取更改可以被发现。
tls是对称加密和非对称加密一起使用，先非对称后对称，因为ca提供的私钥一直在服务端所以其他人无法解析公钥加密后的数据，保证密钥的安全性。
首先第一次握手客户端会向服务端发送client hello信息，告诉服务端需要的tls版本信息，支持的加密算法有哪些，这些算法组成加密套件，然后是一个随机数。
然后第二次握手服务端向客户端发送一个Server hello，然后告诉客户端服务端支持的确认支持的tls版本以及选择的加密套件，也会生成一个随机数告诉客户端，然后服务器出示一个证书，这样浏览器可以根据自己信任的证书列表来确认这个证书服务器是否可信，
然后把公钥给客户端，再发后一个结束信号，Server Hello Done
第三次握手会使用公钥加密生成预主密钥给服务端，服务端使用私钥解密，接下来使用预祝密钥和前两个随机数组成最终的密钥进行密钥通信，
第四次握手服务端发送一个信号对客户端进行确认，加密通信开始。
CA机构在其中的作用
ca机构是第三方机构用来保证数据的可靠性，ca机构给服务端提供公钥和私钥，然后把公钥安全的传输给客户端，方便后面的对称加密，那么如何保证公钥安全的给客户端呢，因为可以保证不能被篡改和更换
如何证明浏览器收到的公钥一定是该网站的公钥？
其实所有证明的源头都是一条或多条不证自明的“公理”（可以回想一下数学上公理），由它推导出一切。比如现实生活中，若想证明某身份证号一定是小明的，可以看他身份证，而身份证是由政府作证的，这里的“公理”就是“政府机构可信”，这也是社会正常运作的前提。
那能不能类似地有个机构充当互联网世界的“公理”呢？让它作为一切证明的源头，给网站颁发一个“身份证”？
它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。
数字证书
网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！
如何放防止数字证书被篡改？
我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名：
数字签名
这部分内容建议看下图并结合后面的文字理解，图中左侧是数字签名的制作过程，右侧是验证过程：
数字签名的生成与验证（https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/）
数字签名的制作过程：
- CA机构拥有非对称加密的私钥和公钥。
- CA机构对证书明文数据T进行hash。
- 对hash后的值用私钥加密，得到数字签名S。
明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）
浏览器验证过程：
- 拿到证书，得到明文T，签名S。
- 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
- 用证书里指明的hash算法对明文T进行hash得到T’。
- 显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。
为何么这样可以保证证书可信呢？我们来仔细想一下。
中间人有可能篡改该证书吗？
假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
既然不可能篡改，那整个证书被掉包呢？
中间人有可能把证书掉包吗？
假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文“中间人攻击”那里提到的漏洞？
其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。
backlog参数在握手中的作用
三次握手
TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。
为什么非要三次握手呢？谢希仁的《计算机网络》中这样说：为了防止已失效的连接请求报文段突然又传送到了服务端因而产生错误。
已失效的连接请求报文段的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段，但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样server的很多资源就白白浪费掉了。采用三次握手的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。这就有效的防止了服务器端的一直等待而浪费资源。
2 backlog
backlog这个参数值和三次握手的概念有着密切关联。backlog队列大小 = 未完成三次握手队列 + 已经完成三次握手队列。
未完成三次握手队列：服务器处于listen状态时，收到客户端syn报文（connect）时放入未完成队列中。
已完成三次握手队列：三次握手的第二个状态即服务器syn+ack响应client后，此时第三个状态ack报文到达前（客户端对服务器syn的ack）一直保留在未完成连接队列中。若三次握手完成，该条目将从未完成连接队列搬到已完成连接队列尾部。当server调用accept时，从已完成三次握手队列中的头部取出一个socket连接给进程
backlog参数设置既可在linux内核参数设置(修改文件/etc/sysctl相关参数)，也可在socket系统调用listen函数时设置(第二个参数)。这二者区别是前者为全局性的，影响所有socket，后者为局部性的，影响当前socket。
若backlog设置过小可能会出现以下情况：server的accpet速度跟不上，导致A、B队列满了，导致新的客户端无法连接。
HTTPS和HTTP的区别主要如下：
https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
