前言

题目来自ConardLi的blog
写的是自己的题解，水平有限，所以仅供参考
代码会整合在github，觉得有帮助就给个star吧~

正文

三、计算机基础

网络协议

1、理解什么是协议，了解TCP/IP网络协议族的构成，每层协议在应用程序中发挥的作用

什么是协议？

• 协议就是双方或者多方达成的共识，是一种行为规范和约定。
• 就像http协议，就是一个用在计算机世界的协议，他用计算机能够理解的语言制定了计算机的交流和规范，以及相关的各种控制和错误处理方式。

TCP/IP 协议常被视为简化的七层OSI模型，总共有四层：

• 链接层
  负责在以太网，WiFi这样的底层网络上发送原始数据包，工作在网卡这一个层次，使用MAC地址来标记网络上的设备，所以有时候也叫MAC层。

• 网际层（网络互连层）
  IP协议就在这一层，IP协议定义了IP地址这一概念，所以就可以在“链路层”的基础上，用IP地址取代MAC地址，把许许多多的局域网，广域网连接成一个巨大的虚拟网络，在这个网络里找设备时只要把 IP 地址再“翻译”成 MAC地址就可以了。

• 传输层
  这个层次的TCP协议的职责是保证数据在IP地址标记的两点之间可靠传输，还有一个协议是UDP。

• 应用层
  Telnet（远程登陆协议）、SSH（安全外壳协议）、FTP（文件传输协议）、SMTP（电子邮件协议） 等等，当然还有我们的 HTTP。

OSI网络分层：

• 物理层
  网络的物理形式，例如电缆、光纤、网卡、集线器等等
• 数据链路层
• 网络层
• 传输层
• 会话层
  维护网络中的连接状态，保持会话和同步
• 表示层
  把数据转换为合适、可理解的语法和语义
• 应用层
  面向具体的应用传输数据

2、三次握手和四次挥手详细原理，为什么要使用这种机制

三次握手：

背景摘要： 小红（客户端）和小蓝（服务端）线下见面

• 小红隔着老远看到了小蓝，但是不确定是不是小蓝，小红先跟小蓝挥手（发送SYN标记包，仅SYN标记为1的TCP包），自己进入 syn_sent 状态
• 小蓝看到小红跟自己挥手，也向小红挥了下手并且还笑了一下（发送仅SYN 和 ACK 标记为1的包，表示对第一个ACK包的确认），进入syn_rcvd状态，跟小红确认，小红看到有人辨认出了自己，自己进入了estalished状态。
• 这个时候小蓝慌了，小红有没有可能不是在跟他打招呼，但是小红马上给了小蓝一个微笑(发送 ACK 标记为1的包)，小蓝确定了小红在和他通信，小蓝进入established状态

syn_sent: syn package has been sent
syn_rcvd: syn package has been received
SYN：同步序列编号（Synchronize Sequence Numbers）
ACK：确认字符 (Acknowledge character)

	方向	seq	ack	SYN	ACK
第一次	A->B	10000	0	1	0
第二次	B->A	20000	10000 + 1 = 10000	1	1
第三次	A->B	10001	20000	0	1

1、A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0。
2、B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001。
3、A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001。

为什么不是两次握手

会导致主机 B 的性能损耗

两次握手就建立连接，假如主机 A 发送的 SYN 因网络问题迟迟没有到达主机 B，这时候会重发另一个 SYN 包给 B，当 A 接受到 B 的 ACK 包时建立连接。这时如果第一个 SYN 到达 B 时，主机 B 会认为主机 A 希望再次建立连接，会返回一个 ACK 包给 A。当 A 收到 ACK 时会抛弃掉这个包，因为 A 并不想建立连接，这时主机 B 认为连接已经建立，会一直等待主机 A 发送数据，这样会导致主机 B 的性能损耗。

四次挥手：

背景摘要：小红（客户端）和小蓝（服务端）要离别

• 小红跟小蓝挥手（发送FIN为1，ACK为1的包），准备分离（状态从established变成fin_wait_1）
• 小蓝向小红伤感地笑笑（发送ACK为1的包），但是还没准备好分离（状态从established变成close_wait）
• 小红看到小蓝笑了（小红状态从fin_wait_1变成fin_wait_2）
• 小蓝做好分离的准备（状态从close_wait变为last_ack），向小红挥手（发送FIN为1，ACK为1的包）
• 小红也伤感一笑（发送ACK为1的包，状态从fin_wait_2变成time_wait）
• 小蓝看到小红笑了，转身离去（状态从last_ack变为close）
• 小红也很负责，为了让小蓝和自己不藕断丝连，持续了4分钟的time_wait状态（时间为2MSL，Maximum Segment Lifetime，报文段在网络上能存活的最大时间），确保对方可以收到断开请求，如果对方没有收到的话，就会重传FIN为1，ACK为1的包

上面有一个非常特殊的状态time_wait，它是主动关闭的一方在回复完对方的挥手后进入的一个长期状态，这个状态标准的持续时间是4分钟，4分钟后才会进入到closed状态，释放套接字资源。不过在具体实现上这个时间是可以调整的。

为什么要等待一段时间？

它的作用是重传最后一个ack报文，确保对方可以收到。因为如果对方没有收到ack的话，会重传fin报文，处于time_wait状态的套接字会立即向对方重发ack报文。

四次挥手也并不总是四次挥手，中间的两个动作有时候是可以合并一起进行的，这个时候就成了三次挥手，主动关闭方就会从fin_wait_1状态直接进入到time_wait状态，跳过了fin_wait_2状态。

为什么要使用这种机制：

• 确保数据可靠传输

3、有哪些协议是可靠，怎么有效理解可靠数据传输，TCP有哪些手段保证可靠交付

有哪些协议可靠？

TCP

怎么有效理解可靠数据传输

两方面理解，一是能够保证数据顺利传输，第二是数据传输的完整性和有序、没有丢失或冗余，才能称为可靠数据传输。

TCP有哪些手段保证可靠交付：

1、将数据截断为合理的长度。

• 应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的数据报长度将保持不变。

2、超时重发

• 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

3、对于收到的请求，给出确认响应

• 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒。(之所以推迟，可能是要对包做完整校验)

4、校验出包有错，丢弃报文段，不给出响应，TCP发送数据端，超时的时候会重发数据

• TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。 如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。 （希望发端超时并重发）

5、对失序数据进行重新排序，然后才交给应用层

• 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。 如果必要，TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。

6、对于重复数据，能够丢弃重复数据

• 既然IP数据报会发生重复，TCP的接收端必须丢弃重复的数据。

7、TCP还能提供流量控制。

• TCP连接的每一方都有固定大小的缓冲空间。
• TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。TCP使用的流量控制协议是可变大小的滑动窗口协议。

4、DNS的作用、DNS解析的详细过程，DNS优化原理

DNS的作用：

• DNS 是域名系统 (Domain Name System) 的缩写，它是由解析器和域名服务器组成的
• 顾名思义就是用来进行域名解析，一个或者多个域名对应着一个IP

DNS解析的详细过程：

• 浏览器缓存
  浏览器首先会在自己的缓存中查找有没有对应的域名-IP匹配，如果有的话就可以尝试访问资源了，如果没有就会去系统缓存里找
• 系统缓存
  在操作系统的host文件、DNS缓存里去找
• 路由器缓存
• ISP DNS缓存
  ISP (网络提供商) 的DNS缓存服务器中寻找
• 递归搜索
  根域名 > 顶级dns服务器(如 com) > 二级dns服务器(baidu.com) > 三级dns服务器(www.baidu.com)

DNS优化原理：

• 优雅降级
  在浏览器加载网页时, 对网页中的或者的href属性中的域名进行后台的预解析, 并且将解析结果缓存在浏览器端
• meta
  可以通过用meta信息来告知浏览器, 我这页面要做DNS预取:
• link
  可以使用link标签来强制对DNS做预取

5、CDN的作用和原理

CDN的作用：

• CDN全称是Content Delivery Network（内容分发网络），用了HTTP协议里的缓存和代理技术，代替源站响应客户端的请求。

CDN的原理：

• 给源站域名添加CNMAE,别名为加速节点的域名。当用户向源站发起请求时，dns服务器解析源站域名时会发现有CNMAE记录，这时dns服务器会向CNAME域名发起请求，请求会被调度至加速节点的域名。

6、HTTP请求报文和响应报文的具体组成，能理解常见请求头的含义，有几种请求方式，区别是什么

HTTP的请求报文和响应报文的报文结构可以理解成是一个大头儿子，每时每刻网络上都会有数不清的大头儿子在跑来跑去

具体组成：

• 起始行
  描述请求或者响应的基本信息
• 头部字段集合
  使用key value的形式更详细地说明报文
• 消息正文
  实际传输的数据，它不一定是纯文本，也可能是图片视频等二进制数据

总的来说由四部分组成：起始行->头部->空行->消息正文
消息正文可以为空

请求报文：
请求行由三部分组成：

• 请求方法
• 请求目标
• 版本号

响应报文：
状态行由三部分组成：

• 版本号
• 状态码
• 原因

头部字段：
分为请求头和响应头
头部字段是由key:value的形式组成的

常用头字段：

• Host
  HTTP/1.1里必须出现的字段，Host告诉服务器这个请求应该由哪个主机来处理，当一台计算机上托管了多个虚拟主机的时候，服务器就需要用Host字段来选择，也就是说，如果请求头里没有Host，那么就是个错误的报文。
• User-Agent
  User-Agent是请求头里的字段，可以理解成是一个请求的马甲，可信度不高。
• Date
  Date字段是响应头里的字段，他告诉了HTTP报文创建的时间
• Server
  Server字段也是响应头的字段，他告诉客户端当前正在提供服务的软件名和版本号

请求方法和区别：

• GET
  获取资源，可以理解为读取或者下载数据
• HEAD
  获取资源的元信息
• POST
  向资源提交数据，相当于写入或者上传数据
• PUT
  类似于POST
• DELETE
  删除数据
• CONNECT
  建立特殊的连接隧道
• OPTIONS
  列出可对资源实行的办法
• TRACE
  请求追踪-响应的传输路径

7、 HTTP所有状态码的具体含义，看到异常状态码能快速定位问题

HTTP状态码：

• 1XX：
  1XX状态码属于提示信息，是协议处理的中间状态，实际能用到的地方很少。
  101：Switching Protocols，它的意思是客户端使用Upgrade头字段，要求HTTP协议的基础上改用其他的协议进行通信，比如WebSocket。如果服务器也同意变更协议，也会使用101状态码，但这以后数据传输就不会再使用HTTP了

状态码	说明
101	客户端使用Upgrade头字段，要求HTTP协议的基础上改用其他的协议进行通信，比如WebSocket。如果服务器也同意变更协议，也会使用101状态码。

• 2XX
  2XX状态码表示服务器收到了请求并且正确地处理了请求。
  200：成功，如果是非HEAD请求，通常响应头都会有body数据
  204：Not Content，跟200状态码很相似，但是响应头后没有body数据
  206：是HTTP分块下载或者断点重传的基础，在客户端发送了请求范围要求获取服务端的资源时出现，body的资源不是全部，只是一部分。

状态码	说明
200	成功状态码
204	也是成功状态码，但是没有body数据
206	也是成功状态码，但是说明body的资源不是全部，只是一部分

• 3XX
  3XX状态码
  301：Move Permanently，永久重定向，此次请求的资源已经不存在了，需要改用新的URI才能进行访问。
  比如，你的网站升级到了 HTTPS，原来的 HTTP 不打算用了，这就是“永久”的，所以要配置 301 跳转。
  302：Move Temporarily，临时重定向，意思是请求的资源还在，但是需要另一个URI来进行访问。
  比如，今天晚上服务器要维护，就可以将状态码配置成302，把流量切换成一个静态的通知页面，浏览器看到这个302就知道这是暂时的情况。不会做缓存优化，第二天还是会访问原来的地址。
  304：表示资源未修改，用于缓存控制，他不具有跳转的意义，可以理解为重定向到已缓存的文件。

状态码	说明
301	永久重定向
302	临时重定向，意思是请求的资源还在，但是需要另一个URI来进行访问
304	表示资源未修改，用于缓存控制，他不具有跳转的意义，可以理解为重定向到已缓存的文件。

• 4XX
  4XX表示客户端发送的报文有错，服务端无法处理

状态码	说明
400	请求报文有错误
403	服务器禁止访问资源
404	资源在本服务器上未找到
405	不允许某些方法操作资源，例如不允许用POST方法，只能用GET
406	资源无法满足客户端的要求
408	服务器超时
413	body太大
414	请求行的URI过大
429	客户端的请求过多，服务器限连
431	请求头某个字段或总体太大

• 5XX
  是服务端的错误码

状态码	说明
500	服务器出错
501	某些功能暂时还不支持
502	网关代理出错
503	服务器正在忙

8、HTTP1.1、HTTP2带来的改变

HTTP简单，灵活可扩展，纵横江湖几十年而不倒，但是HTTP安全不足而且性能不高

HTTP2

• 头部压缩
  HTTP/1可以对body进行压缩，具体做法是在头部指定Content-Encoding指定body的编码方式，比如用gzip压缩来节约宽带。
  HTTP2把头部压缩作为性能改进的一个点，HTTP2开发了专门的“HPACK”算法，在客户端和服务端建立字典，用索引号来表示重复的字符，还采用哈夫曼编码来压缩整数和字符串，可以达到50%-90%的高压缩率。

• 二进制格式
  HTTP2全面采用二进制格式，方便了计算机的解析，以二进制为基础，HTTP2对数据进行了分帧。
  它把 TCP 协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。
  HTTP2数据分帧之后，Header+Body的结构就完全消失了，我们就只能看到的是一个个小小的碎片。

• 虚拟的流
  消息的“碎片”到达目的地后应该怎么组装起来呢？
  同一个消息往返的帧会分配同样的ID，这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文。
  在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发的“帧”。多个请求 / 响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。
  HTTP/2 还在一定程度上改变了传统的“请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为“服务器推送”

• 强化安全
  但由于 HTTPS 已经是大势所趋，而且主流的浏览器 Chrome、Firefox 等都公开宣布只支持加密的 HTTP/2，所以“事实上”的 HTTP/2 是加密的。也就是说，互联网上通常所能见到的 HTTP/2 都是使用“https”协议名，跑在 TLS 上面。
  为了区分“加密”和“明文”这两个不同的版本，HTTP/2 协议定义了两个字符串标识符：“h2”表示加密的 HTTP/2，"h2c"表示明文的HTTP/2，c的意思是clear text
  底层用的是TLS1.25以上

9、HTTPS的加密原理，如何开启HTTPS，如何劫持HTTPS请求

HTTPS

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。

HTTP 与 HTTPS 的区别

• HTTP 是明文传输，HTTPS 通过 SSL\TLS 进行了加密
• HTTP 的端口号是 80，HTTPS 是 443
• HTTPS 需要到 CA 申请证书，一般免费证书很少，需要交费
• HTTPS 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

SSL/TLS

简介：

• SSL即安全套接层，处于OSI七层模型里的第五层（会话层）

• SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。

• 目前应用最广泛的协议是TLS1.2

• TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。

• HTTPS = HTTP +TLS/SSL

• HTTPS 的语法、语义仍然是 HTTP，但把下层的协议由 TCP/IP 换成了 SSL/TLS

对称加密和非对称加密（机密性实现）

对称加密？非对称加密？

对称加密

指加密和解密用的密钥是同一个，两边都用同一个密钥，这就叫对称

对称加密算法：
目前常用的只有 AES 和 ChaCha20

AES 的意思是“高级加密标准”（Advanced Encryption Standard），密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法。

ChaCha20 是 Google 设计的另一种加密算法，密钥长度固定为 256 位，纯软件运行性能要超过 AES，曾经在移动客户端上比较流行，但 ARMv8 之后也加入了 AES 硬件优化，所以现在不再具有明显的优势，但仍然算得上是一个不错算法。

加密分组模式：
对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文）。

比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分组模式是 Poly1305。

说了半天，对称加密似乎非常完美，但是有一个问题，我要怎么把密钥传输给对方呢？总不能再对密钥加密，再把密钥的密钥加密，再加密密钥的密钥的密钥吧。

非对称加密：

这个时候，非对称加密就跳了出来。

它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。

非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密。而黑客因为没有私钥，所以就无法破解密文。

非对称加密算法：

RSA：
RSA 可能是其中最著名的一个，几乎可以说是非对称加密的代名词，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

10 年前 RSA 密钥的推荐长度是 1024，但随着计算机运算能力的提高，现在 1024 已经不安全，普遍认为至少要 2048 位。

ECC：
ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。

比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了，对于现在的移动互联网非常有吸引力。

非对称加密这么厉害，我们是不是能抛弃对称加密了呢

混合加密

答案是不行的，虽然非对称加密没有“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢，即使是 ECC 也要比 AES 差上好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信速度有如乌龟、蜗牛，实用性就变成了零。

那么，是不是能够把对称加密和非对称加密结合起来呢，两者互相取长补短，即能高效地加密解密，又能安全地密钥交换。

这就是现在 TLS 里使用的混合加密方式：

• 在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。
• 然后用随机数产生对称算法使用的“会话密钥”（session key），再用公钥加密。
• 因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。
• 对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

这样混合加密就解决了对称加密算法的密钥交换问题，而且安全和性能兼顾，完美地实现了机密性。

题外话：
比特币，以太坊等区块链技术也用到了ECC加密技术，它们选择的曲线是secp256k1。

摘要算法（完整性）

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。

你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。

摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”（collision，也叫碰撞）的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”，让这种可能性尽量地小。

你一定在日常工作中听过、或者用过 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在 TLS 里已经被禁止使用了。

目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。

摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。

比如，你发了条消息：“转账 1000 元”，然后再加上一个 SHA-2 的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致，就说明消息是完整可信的，没有被修改。

如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被窜改，是不可信的。

所以，真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了。

数字签名（身份认证和不可否认性）：

加密算法结合摘要算法，我们的通信过程可以说是比较安全了。但这里还有漏洞，就是通信的两个端点（endpoint）。

就像一开始所说的，黑客可以伪装成网站来窃取信息。而反过来，他也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么被偷走了。

现实生活中，解决身份认证的手段是签名和印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。

数字签名的原理很简单，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”，把公钥私钥的用法反过来，之前是公钥加密、私钥解密，现在是私钥加密、公钥解密。

比如，你用自己的私钥签名一个消息“我是小明”。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息“我是某宝”。你收到后再用它的公钥验一下，也没问题，这样你和网站就都知道对方不是假冒的，后面就可以用混合加密进行安全通信了。

但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。

数字证书与CA（公钥的信任问题）：

综上所述，我们已经实现了安全的四个特性，机密性，完整性，身份认证和不可否认性，是不是已经完美实现了安全传输呢？答案是NO，我们还有一个问题没有解决，那就是公钥的可信度。

因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者某宝的公钥呢？

这个时候我们就要找一个公认的可信的第三方，这个“第三方”就是我们常说的CA（Certificate Authority，证书认证机构）。它就像网络世界里的公安局、教育部、公证中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。

CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。

内容太多暂时待更新

10.理解WebSocket协议的底层原理、与HTTP的区别

“WebSocket”是一种基于 TCP 的轻量级网络通信协议，在地位上是与 HTTP“平级”的。
WebSocket 是一个真正“全双工”的通信协议。

11、TCP和UDP的区别？各自的应用场景

区别：

TCP	UDP
可靠	不可靠
TCP面向连接	UDP无连接
TCP面向字节流	UDP面向报文
TCP效率低	UDP效率高
TCP有滑动窗口	UDP没有
TCP速度慢	UDP速度快
TCP慢开始，拥塞避免，快重传，快恢复	UDP无
TCP全双工	UDP一对一，一对多，多对一，多对多

应用场景：

TCP	UDP
SMTP 电子邮件	DNS 域名转换
FTP 文件传输	TFTP 文件传输
TELNET 远程终端接入	SNMP 网络管理
HTTP万维网	NFS 远程文件服务器

12、 Access-Control-Allow-Origin与Cookie的关系

前端发出的请求如果是附带身份验证（withCredentials：true）
而后端的Access-Control-Allow-Origin如果设置的是*
那么这个请求会失败，在Options预请求时会被拦截下来。

13、ARP协议

目标IP与自己在同一网段

• arp高速缓存有目标IP的MAC地址：直接发送到该物理地址
• arp高速缓存没有目标IP的MAC地址：发送ARP广播请求目标IP的MAC地址，缓存该MAC地址，然后发数据报到该MAC地址。

目标IP与自己不在同一个网段

• 这种情况需要将包发给默认网关，所以主要获取网关的MAC地址

• arp高速缓存有默认网关的MAC地址：直接发送IP数据报道默认网关，再由网关转发到外网。

• arp高速缓存没有默认网关的MAC地址 ：还是发送ARP广播请求默认网关的MAC地址，缓存该地址，并且发送数据报到网关。