-
1.必备基础TCP，UDP
TCP协议指的是传输控制协议，是一个面向连接的传输协议，他是一个能提供高可靠性的通信协议，所谓高可靠性指的是数据无丢失、数据无误、数据无失序、数据无重到达。就像图上所示，TCP能把“孩子”安全地送到接收者手上。
TCP类似于打电话这一行为，而UDP类似于写信或者qq离线发送这个行为。
TCP面向连接，通过三次握手建立连接，四次挥手接除连接。因此TCP的工作可靠性高。
UDP是无连接的，发送数据之前不需要建立连接，这种方式为UDP带来了高效的传输效率，但也导致无法确保数据的发送成功。
tcp的三次握手四次挥手解释（A与B约定出去散步）
第一次握手： A给B发短信说：“B，你现在准备好了吗？”
第二次握手： B收到了A的信息，然后对A说： “ 我好了，已经出发了，你出发了吗？ ”
第三次握手： A收到了B的确认信息，然后说：“我也好了，我出发了。
第一次挥手： A给B发短信说：“B，你到了吗，我有事去不了了”
第二次挥手： B此时收到了A的信息，然后先对A说:“没有到”
第三次挥手： B对A说到:“那我就回家了”然后回家了，
第四次挥手： A此时收到了B的确认信息，然后给B发消息说：“好的，我知道了”这时A也回家
-
2.什么是http？
HTTP协议全称Hyper Text Transfer Protocol，
翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。
-
3.HTTP各个版本之间的区别？
- 4.HTTPS的原理
HTTPS首先要解决的是：认证的问题。
客户端是需要确切地知道服务端是不是「真实」，所以在HTTPS中会有一个角色：CA（公信机构）。
服务端在使用HTTPS前，需要去认证的CA机构申请一份「数字证书」。数字证书里包含有证书持有者、证书有效期、「服务器公钥」等信息。
机构也有自己的一份公私钥，在发布数字证书之前，会用自己的「私钥」对这份数字证书进行加密 。
等到客户端请求服务器的时候，服务端返回证书给客户端。客户端用CA的公钥对证书解密（因为CA是公信机构，会内置到浏览器或操作系统中，所以客户端会有公钥）。这个时候，客户端会判断这个「证书是否可信/有无被篡改」。
私钥加密，公钥解密我们叫做「数字签名」（这种方式可以查看有无被篡改）。
到这里，就解决了「认证」的问题，至少客户端能保证是在跟「真实的服务器」进行通信。
解决了「认证」的问题之后，就要解决「保密」问题，客户端与服务器的通讯内容在传输中不会泄露给第三方。
客户端从CA拿到数字证书后，就能拿到服务端的公钥。
客户端生成一个Key作为「对称加密」的秘钥，用服务端的「公钥加密」传给服务端。
服务端用自己的「私钥解密」客户端的数据，得到对称加密的秘钥。
之后客户端与服务端就可以使用「对称加密的秘钥」愉快地发送和接收消息。
HTTP 属于应用层协议，HTTPS 并不是一个新的协议，它只是比 HTTP 协议多了一层（TSL/SSL）来保证数据传输安全。TSL/SSL也属于协议，它的主要作用是保证数据传输安全。大多数使用的是 OpenSSL 来实现，
比如 Node 中的 TSL 就是基于 OpenSSL 实现的。
- 5.生动有趣的解说Https
五个角色:我 妈妈 黑客 技术大牛 CA证书颁发机构
我：妈妈，生日快乐！
妈妈：卡号拿来，给你打点钱。
我：卡号xxx。
黑客:监听，改了卡号yyy。
结果：黑客拿到钱后就逃之夭夭。
这就是http协议的弊端。
技术大牛来剖析一下我和妈妈被骗的场景，提出方案。
方案1:对称加密AES
既然我和她妈妈的聊天内容是明文传输的，
那直接把内容加密不就完事了吗。我和她妈妈就约定了一个密码，所有的内容都通过这个密码进行加密和解密。
结果：不行，这个密码一旦泄露，还会出现同样问题。
方案2:非对称加密
使用两个密钥，公钥加密私钥解密。
结果：不行，一旦公钥泄露，还会出现同样问题
这似乎是永远解不了的问题，毕竟公钥始终是要经过传输的。这似乎是一个鸡生蛋蛋生鸡的问题。后来我想了想他平时网上购物的时候，以前总是担心怕付款了，商家跑路不给发货，自从有了淘宝这个第三方机构，毕竟阿里家大业大。
方案3：CA证书颁发机构
第一步是人员认证 ，第二步是通讯保密。
流程：妈妈先去CA申请一份证书，我和妈妈沟通的时候,妈妈将证书发给我，我进行校验，
校验成功后我用对称加密算法生成一个密钥，使用非对称算法的公钥对我的密钥进行加密，然后把我生成的密钥传输给妈妈。我和妈妈后面的通信都是基于对称加密算法的密钥进行解密。
结果：可行！
