HTTPS

随着 HTTPS 建站的成本下降，现在大部分的网站都已经开始用上 HTTPS 协议。大家都知道 HTTPS 比 HTTP 安全，也听说过与 HTTPS 协议相关的概念有 SSL 、非对称加密、 CA证书等，但对于以下灵魂三拷问可能就答不上了：

• 为什么用了 HTTPS 就是安全的？

• HTTPS 的底层原理如何实现？

• 用了 HTTPS 就一定安全吗？

HTTPS 的实现原理

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实，HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

1. 证书验证阶段浏览器发起 HTTPS 请求服务端返回 HTTPS 证书客户端验证证书是否合法，如果不合法则提示告警

2. 数据传输阶段当证书验证合法后，在本地生成随机数通过公钥加密随机数，并把加密后的随机数传输到服务端服务端通过私钥对随机数进行解密服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

为什么数据传输是用对称加密？

首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；

另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。

首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。“中间人攻击”的具体过程如下：

过程原理

• 某网站有用于非对称加密的公钥A、私钥A’。
• 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
• 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
• 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。
• 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
• 服务器拿到后用私钥A’解密得到密钥X。
• 这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是明文传输的，难道还得对公钥的传输进行加密？这似乎变成鸡生蛋、蛋生鸡的问题了。解法是什么？

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

浏览器是如何确保 CA 证书的合法性？

证书包含什么信息？

• 颁发机构信息
• 公钥
• 公司信息
• 域名
• 有效期
• 指纹

证书的合法性依据是什么？

首先，权威机构是要有认证的，不是随便一个机构都有资格颁发证书，不然也不叫做权威机构。另外，证书的可信性基于信任制，权威机构需要对其颁发的证书进行信用背书，只要是权威机构生成的证书，我们就认为是合法的。所以权威机构会对申请者的信息进行审核，不同等级的权威机构对审核的要求也不一样，于是证书也分为免费的、便宜的和贵的。

用了 HTTPS 会被抓包吗？

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。

但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。通常 HTTPS 抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？HTTPS 可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

HTTPS 为什么安全？

因为 HTTPS 保证了传输安全，防止传输过程被监听、防止数据被窃取，可以确认网站的真实性。

HTTPS 的传输过程是怎样的？

客户端发起 HTTPS 请求，服务端返回证书，客户端对证书进行验证，验证通过后本地生成用于改造对称加密算法的随机数，通过证书中的公钥对随机数进行加密传输到服务端，服务端接收后通过私钥解密得到随机数，之后的数据交互通过对称加密算法进行加解密。

为什么需要证书？

防止”中间人“攻击，同时可以为网站提供身份证明

使用 HTTPS 会被抓包吗？

会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？

其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但私钥是无法获取的，一份公钥是不可能推算出其对应的私钥，中间人即使拿到证书也无法伪装成合法服务端，因为无法对客户端传入的加密数据进行解密。

那如果我本身就有一个合法的证书的呢，我作为中间人服务器，我拦截目标服务器的证书，把我自己的证书给客户端，客户端肯定能验证通过，然后我自己服务器的证书我当然知道私钥啊，这个怎么解？

他会把你的证书和目标服务器的证书对比，结果证书验证失败，浏览器报警告，如果这时候用户进一步授权，那你的阴谋就得逞了。

浏览器输入地址后到看到页面发生了什么？

1. 对URL进行DNS解析得到对应的IP地址

DNS域名解析采用的是递归查询，顺序为：

先找DNS缓存=>根域名服务器=>继续查找下一级

找到之后给浏览器缓存查找顺序大概是：

浏览器DNS缓存=>系统DNS缓存=>host文件查找=>递归去服务器查找

2.根据IP地址找到对应的服务器并发起TCP三次握手

TCP是一个端到端的可靠的面向链接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题，如会错传重传等问题。 建立一个TCP链接时需要客户端和服务端共发送三个包：

1. 客户端发送一个包到服务器并等待确认
2. 服务器收到客户端的包，并向客户端发送一个确认包
3. 客户端接收到服务端的确认包，三次握手，TCP链接成功

3.建立TCP链接后发送HTTP请求(请求头和请求体)

4.服务器响应HTTP请求，返回响应的数据包

服务器收到处理的请求开始做负载均衡和跨域等

文件处理完毕生成响应数据包(响应头和响应体)并返回

5.经过网络传输文件被下载到本地客户端，浏览器收到HTTP响应，客户端开始加载

6.浏览器得到HTML代码后开始解析，并请求HTML代码中的资源，如CSS、JS和图片

7.浏览器开始对页面进行渲染并呈现给用户

1. 解析HTML文件是自上问下即先是头部后是Body
2. 当解析到头部CSS/JS外部链接时，同步下载
3. 接着解析Body部分，将HTML文件解析成DOM树
4. 同时等待CSS文件下载完成后解析成CSSOM树
5. DOM树和CSSOM树就组成了Render Tree渲染树
6. CSS文件加载不会阻塞HTML的解析，但是会阻塞DOM的渲染及后面JS语句的执行
7. 在下载JS时会阻塞HTML的解析和渲染，有分几种情况\
   1. 没有defer和async标签的script会立即加载并执行
   2. 有async属性会异步下载，完成后立即执行，且不一定按顺序，有可能会阻塞HTML渲染。
   3. 有defer属性会异步下载，完成会等到DOM生成以后再按顺序执行，不会阻塞HTML解析和渲染。
8. 渲染树一旦有了结构模型，就会同步计算渲染树节点的布局位置
9. 计算出渲染坐标后开始同步渲染
10. 进行过程中如遇到图片则跳过去，渲染下面的内容，等图片下载成功后返回来再渲染原来图片的位置
11. 如果渲过程中出现JS代码调整DOM树结构的情况，会再次从修改DOM开始
12. 最终所有节点和资源全都渲染完成，页面渲染结束

8.服务器关闭TCP链接，TCP四次挥手

一个 TCP 链接能发几个 HTTP 请求

HTTP 1.0一般情况下不支持长连接，因此在每次请求发送完毕之后，TCP 连接会立即断开 故此HTTP 1.0 一个 TCP 发送一个 HTTP 请求。

但是通过在请求头带上Connection: Keep-Alive将一条TCP连接保持在活跃状态，并且客户端和服务端都支持的情况下，其实也可以发送多条，不过此方式也有限制。

HTTP 1.1支持了长连接，HTTP 2.0版本协议支持了多用复用。 故此只要不断开TCP的连接，HTTP请求数也是可以没有上限地持续发送。

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

HTTP 与 HTTPS 的区别

HTTP是超文本传输协议，设计目的是为了提供一种发布和接收HTML页面的方法 HTTPS是以数据保密性完整性和身份校验安全性为目标的HTTP安全版

之间区别具有以下几种：

1.传输信息安全不同

HTTP 是超文本传输协议，明文传输

HTTPS 是SSL机密传输协议，密文传输

2.端口不同

HTTP 默认是80，HTTPS 默认是443

3.链接方式不同

HTTP 是无状态链接

HTTPS 是SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，安全性更高

4.证书申请方式不同

HTTP 协议免费，HTTPS 需要CA证书，一般需要付费

与 HTTP 相比 HTTPS 有哪些改进：

1. 双向的身份认证
2. 数据传输的机密性
3. 防止重放攻击

HTTPS 优点：

1. 可认证用户和服务器，确保数据发送到正确的客户机和服务器
2. 是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全
3. 是现行架构下最安全的解决方案(虽然不是绝对安全)

HTTPS 缺点

1. 握手阶段比较费时，使页面加载时间延长
2. HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响
3. SSL 证书需要钱，功能越强大费用越高，且 SSL 证书通常需要绑定 IP，不能在同一 IP上绑定多个域名

HTTPS 工作原理

1. 首先HTTPS请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求域名一直以及证书公钥（RSA加密）等进行校验。

2. 客户端如果校验通过后，就根据证书的公钥有效期生成随机数，随机数使用公钥进行加密（RSA加密）

3. 消息体产生后对它的摘要进行MD5加密/SHA1算法加密，此时就得到了RSA签名

4. 发送服务端，此时只有服务端（RAS私钥）能解密

5. 解密得到的随机数再用AES加密作为秘钥，此时的秘钥只有客户端和服务端知道

http的面试问题

tcp为什么是三次握手

表象： 三次是保证双方互相明确对方能收能发的最低值。

本质: 三次握手才可以阻止重复历史连接的初始化（主要原因）

三次握手才可以同步双方的初始序列号

三次握手才可以避免资源浪费

原因一：避免历史连接

简单来说，三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。

原因二：同步双方初始序列号

TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：

接收方可以去除重复的数据； 接收方可以根据数据包的序列号按序接收； 可以标识发送出去的数据包中， 哪些是已经被对方收到的；

原因三：避免资源浪费

如果三次握手以上，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。

为什么TCP是四次挥手

首先解释为什么需要四次挥手？

TCP是基于全双工通信的，所以双方都可以主动释放连接。 四次挥手的意义就在于，当 A 发送完最后一条数据之后，但可能B还有未发送给A 的数据。 所以A在发送完收据后可以请求释放连接，此时B给与A响应，告诉A我知道你想断开连接，此时A还可以继续接收B发送的信息。 在B处理完工作后，也请求释放连接。A同意后，就断开连接。 这样可以保证数据正常可靠的交互。

摘要算法

数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。

数字签名

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

数字签名的过程如下：

明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名

数字签名有两种功效：

一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。

二、数字签名能确定消息的完整性。

注意：

数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围

发送方将电子文档Hash运算，得到摘要，然后将摘要用私钥加密，就得到数字签名； 数字签名与电子文档一起发送给接收方，接收方收到后，将电子文档同样进行Hash运算得到摘要，然后将数字签名用公钥解密，并与摘要比较，相等即校验通过。

为什么要有数字证书？

对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。

数字证书的颁发过程

用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。

证书包含哪些内容

证书颁发机构的名称

证书本身的数字签名

证书持有者公钥

证书签名用到的Hash算法

验证证书的有效性

浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥

证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书

证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了，认为是危险证书。

对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A，然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的。

证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。

1、2点是对伪造证书进行的，3是对于篡改后的证书验证，4是对于过期失效的验证。

SSL (Secure Socket Layer，安全套接字层)

SSL 的工作主要可以分为三个阶段：握手、密钥导出、数据传输。

握手阶段

在握手阶段需要完成的三个任务分别是：建立一条 TCP 连接、验证服务端身份、分发通信主密钥。大致过程描述如下：

客户端首先发起一条到服务端的 TCP 连接，随后的数据传输都是在这条 TCP 连接之上的，在 TCP 链接建立之后，客户端会向服务端发送 HELLO 报文，这个报文中包含了客户端所支持的密码算法列表，服务端在接收后会选用一种对称算法，一种非对称算法和一种 MAC 算法，连同其 证书 回应给客户端（这个证书就是经过权威机构认证的一个实体与其公钥的绑定）。

因为在各种的加密过程中，只要是涉及到使用公开密钥的，一般都会有公钥被入侵者盗用和伪造的风险，这时就需要权威机构颁发的数字证书来证明一个公要与实体的绑定。

客户端在收到服务端发来的证书之后，就可以明确的知道当前正在跟自己通信的服务端就是目标服务器，客户端随后会从证书中提取服务端发来的公钥，并在客户端生成一个随机的主密钥 MS，然后用服务端的公钥对其进行加密后发送给服务端，服务端会用自己的私钥解密得到主密钥 MS，这样就完成了主密钥的分发。

客户端和服务器都掌握了主密钥，有了这个其他人都不知道的主密钥，随后的数据加密和验证过程就好办了。

密钥导出

密钥导出阶段，就是通信双方会以相同的方法，用主密钥生成四个密钥，这四个密钥的分别作用如下：

EB：用于从服务端到客户端发送数据的会话加密密钥 MB：用于从服务端到客户端发送数据的会话 MAC 密钥 EA：用于从客户端到服务端发送数据的会话加密密钥 MA：用于从客户端到服务端发送数据的会话 MAC 密钥 会话加密密钥就是实际用来加密传输数据的对称密钥，MAC 密钥在是标志传输数据完整性的密钥。

MAC：报文鉴别码，是一种用来监测报文完整性的技术。它的过程并不复杂，发送方将明文与一个鉴别密钥进行级联，这个鉴别密钥是通信双方所共有的，随后会计算这个级联后的数据散列值，这个散列值就叫做原始数据的报文鉴别码 MAC，将报文的鉴别码附加在原始明文后面，一同发送给接收方。接收方用收到的明文，级联相同的鉴别密钥，再以相同的方法计算散列值，与收到的散列值 MAC 进行对比，若两者相同，则说明数据未被篡改，上述的 MA 和 MB 就是 MAC 里的鉴别密钥。

数据传输

SSL 将数据流分割成记录，对每个记录 EA 加密，并附加一个 MAC（用于完整性鉴别），然后对该记录与 MAC 进行加密，然后将这个被加密的包发送服务器，服务端收到这个数据包后，用相应的 EB 对称密钥进行解密，再用 MB 进行数据完整性检验。

TLS (Transport Layer Security，传输层安全协议)

用于两个应用程序之间提供保密性和数据完整性。

TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。

SSL/TLS协议作用：

认证用户和服务器，确保数据发送到正确的客户机和服务器；

加密数据以防止数据中途被窃取；

维护数据的完整性，确保数据在传输过程中不被改变。

TLS比SSL的优势

对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。

增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。

改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。

一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。

特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

HTTPS连接过程

1. 客户端发送一个https的请求到服务端

2. 服务端申请配置好数字证书，包含公钥和私钥

3. 服务端将证书传送给客户端，证书中包含了很多信息，比如证书的颁发机构，过期时间，网址，公钥等

4. 客户端解析证书，由客户端的TLS完成，首先会验证公钥是否有效，比如颁发机构，过期时间等。如果有异常，就会弹出警告信息，并结束通信。如果正常，则生成一个随机值（用于对称加密），然后用服务端的公钥对随机值进行非对称加密

5. 客户端将加密后的随机值传送到服务端

6. 服务端使用证书的私钥非对称解密得到客户端的随机值，用获取的随机值将传输的明文内容进行对称加密

7. 服务端把对称加密后的数据传输到客户端

8. 客户端通过随机值对称解密获取明文内容

HTTP Get 和 Post 区别

get 请求的 URL 有长度限制，而 post 请求会把参数和值放在消息体中，对数据长度没有要求。

get 请求会被浏览器主动 cache，而 post 不会，除非手动设置。

get 请求在浏览器反复的 回退/前进 操作是无害的，而 post 操作会再次提交表单请求。

get 请求在发送过程中会产生一个 TCP 数据包；post 在发送过程中会产生两个 TCP 数据包。对于 get 方式的请求，浏览器会把 http header 和 data 一并发送出去，服务器响应 200（返回数据）；而对于 post，浏览器先发送 header，服务器响应 100 continue，浏览器再发送 data，服务器响应 200 ok（返回数据）。

UDP 是什么

UDP 的全称是 User Datagram Protocol，用户数据报协议。它不需要所谓的握手操作，从而加快了通信速度，允许网络上的其他主机在接收方同意通信之前进行数据传输。

数据报是与分组交换网络关联的传输单元。

UDP 的特点主要有

UDP 能够支持容忍数据包丢失的带宽密集型应用程序

UDP 具有低延迟的特点

UDP 能够发送大量的数据包

UDP 能够允许 DNS 查找，DNS 是建立在 UDP 之上的应用层协议。

TCP 是什么

CP 的全称是Transmission Control Protocol ，传输控制协议。它能够帮助你确定计算机连接到 Internet 以及它们之间的数据传输。通过三次握手来建立 TCP 连接，三次握手就是用来启动和确认 TCP 连接的过程。一旦连接建立后，就可以发送数据了，当数据传输完成后，会通过关闭虚拟电路来断开连接。

TCP 的主要特点有：

TCP 能够确保连接的建立和数据包的发送

TCP 支持错误重传机制

TCP 支持拥塞控制，能够在网络拥堵的情况下延迟发送

TCP 能够提供错误校验和，甄别有害的数据包

TCP 和 UDP的区别

TCP 是面向连接的协议 。 UDP 是无连接的协议

TCP 在发送数据前先需要建立连接，然后再发送数据 。 UDP 无需建立连接就可以直接发送大量数据

TCP 会按照特定顺序重新排列数据包 。 UDP 数据包没有固定顺序，所有数据包都相互独立

TCP 传输的速度比较慢 。 UDP 的传输会更快

TCP 的头部字节有 20 字节 。 UDP 的头部字节只需要 8 个字节

TCP 是重量级的，在发送任何用户数据之前，TCP需要三次握手建立连接。 UDP 是轻量级的。没有跟踪连接，消息排序等。

TCP 会进行错误校验，并能够进行错误恢复 。 UDP 也会错误检查，但会丢弃错误的数据包。

TCP 有发送确认。 UDP 没有发送确认

TCP 会使用握手协议，例如 SYN，SYN-ACK，ACK。 UDP无握手协议

TCP 是可靠的，因为它可以确保将数据传送到路由器。 UDP 中不能保证将数据传送到目标。

CA 证书生成的流程

在自己的服务器上生成一对公钥和私钥。然后将域名、申请者、公钥(注意不是私钥，私钥是无论如何也不能泄露的)等其他信息整合在一起，生成.csr 文件。 将这个 .csr 文件发给 CA 机构，CA 机构收到申请后，会通过各种手段验证申请者的组织信息和个人信息，如无异常(组织存在，企业合法，确实是域名的拥有者)，CA 就会使用散列算法对.csr里的明文信息先做一个HASH，得到一个信息摘要，再用 CA 自己的私钥对这个信息摘要进行加密，生成一串密文，密文即是所说的 签名。签名 + .csr 明文信息，即是 证书。CA 把这个证书返回给申请人。

ping命令用的是什么协议

ping命令主要用的是ICMP协议