当你在浏览器输入网址按下回车时，你的电脑究极发生了什么？(一文详解网络请求)

本文探讨的最复杂的网络情况，所以力争解决你的所有困扰

例如我访问的网址是:niu.bi.com

1.DNS 解析

重要概念：域名查询过程是从右往左的！即查询的是时候是先找.com，再找bi.com，再找niu.bi.com的，但是查询的时候是从低往高查的，即先本地，再顶级，权威，根服务器的(扫盲看这：DNS详解)

好的，经历DNS查询后，现在我们已经知道了niu.bi.com对应的服务器ip地址…………

吗？

CDN加速(内容分发网络（Content Delivery Network）)

当目标网站开启了CDN加速后，你通过DNS解析查询的地址，其实查询到的是CDN的服务器地址！！！

WTF？！为什么要有这东西？

注意看，有个男孩叫小帅，他在中国上海，而niu.bi.com服务器在美国纽约

现在小帅访问niu.bi.com网站时，已知光速每秒传播距离是30万公里，而且这是直线的速度，网络访问是通过线缆光纤传输的，意味着从上海到纽约的网络限速可能远远大于直线距离，以及还有网络拥塞的问题，比如这距离有2万公里，但是线缆的长度一定大于这个数，咱们就算3万公里，好，那么你发过去对方还得给你返回吧？一来一回是不是有6万公里？运气好你在碰上个堵车什么的，你说你等的住不？

所以，这就是CDN的作用，当开启了CDN之后，CDN服务商发现，哟？你还要去美国，我找了下刚好在杭州我有个服务器，那里缓存了你想要的东西，东西给你了，不用去美国啦！从6万公里这下缩减到了来回200公里，你说快不快？！

贵的东西，一定有他贵的道理

所以一般CDN，都是付费的，但是也有免费的

比如Cloudflare(国际)，jsDelivr(国际)，bootcdn(中国大陆)

CDN就像一个中介，如果CDN发现你要的东西他没有，那么他就会向你本来的服务器请求资源，拿到后发给你再自己的服务器上保存一份，下次你再访问的时候，他就会直接给你啦

现在已知CDN的服务器，那么就开始握手了，注意，在这里的握手是指的是你和CDN服务器的握手，接下来就引出了著名的 tcp 三次握手四次挥手

握手和挥手是分开！！！！不是交替运行的！

三次握手，指的是请求建立时期的请求，在这个时期所有的请求都属于握手流程！

四次挥手，指的是断开时期的请求，在这个时期所有的请求都属于挥手流程！

"三次握手"和"四次挥手"是TCP协议中建立连接和断开连接的过程，它们保证了TCP协议的可靠性。

三次握手（TCP连接建立过程）

1. 客户端向服务器发送一个SYN（同步）报文【客户端：你能不能搞？】，其中包含客户端的初始序列号。这是第一次握手。

2. 服务器收到客户端的SYN报文后，会向客户端发送一个SYN-ACK（同步确认）【服务器：能搞能搞！】报文，其中包含服务器的初始序列号和对客户端初始序列号的确认。这是第二次握手。

3. 客户端收到服务器的SYN-ACK报文后，会向服务器发送一个ACK（确认）报文【客户端：开搞开搞！】，确认收到了服务器的初始序列号。这是第三次握手，此时连接建立。

四次挥手（TCP连接断开过程）

1. 当主动关闭连接的一方（可以是客户端，也可以是服务器）决定关闭连接时，会发送一个FIN（结束）报文给对方【不爱了分手吧！】，表示已经没有数据需要发送了。

2. 对方收到FIN报文后，会发送一个ACK（确认）报文，【分就分！】表示已经收到了关闭连接的请求，但可能还有数据需要发送。

3. 当对方发送完所有数据后，也会发送一个FIN报文给主动关闭连接的一方【把你这锅碗瓢盆拿走！】。

4. 主动关闭连接的一方收到FIN报文后，会发送一个ACK报文，然后等待一段时间（这个时间叫做TIME_WAIT），确保对方收到了ACK报文。对方收到ACK报文后，连接断开。【拿走就拿走！】

这就是TCP协议的"三次握手"和"四次挥手"过程。通过这个过程，TCP协议能够确保数据的可靠传输。

三次握手四次挥手只属于tcp的流程，那么如果是http呢？

对于HTTP来说，它的连接建立和断开过程与TCP一样，也是通过三次握手和四次挥手来完成的。HTTP协议的请求和响应数据都是在TCP连接建立之后传输的。

那如果是https呢？

在TCP连接建立之后，HTTPS还需要进行SSL/TLS的握手过程，以建立加密的会话。

HTTPS（Hyper Text Transfer Protocol Secure）是HTTP的安全版本，它在HTTP和TCP之间加入了一个SSL/TLS层，用于加密数据和验证服务器的身份。

在HTTPS中，TCP的三次握手和四次挥手仍然存在，因为HTTPS依然使用TCP协议来传输数据。但是，在TCP连接建立之后，HTTPS还需要进行SSL/TLS的握手过程，以建立加密的会话。

SSL/TLS握手过程大致如下：

1. 客户端发送一个"Client Hello"消息给服务器，其中包含了客户端支持的加密算法列表，以及一个客户端生成的随机数。

2. 服务器收到"Client Hello"消息后，会从客户端支持的加密算法列表中选择一个加密算法，然后发送一个"Server Hello"消息给客户端，其中包含了选定的加密算法和一个服务器生成的随机数，以及服务器的证书。

3. 客户端收到"Server Hello"消息后，会验证服务器的证书。如果证书验证通过，客户端会生成一个新的随机数（叫做"premaster secret"），然后使用服务器证书中的公钥加密这个随机数，发送给服务器。

4. 服务器收到加密的随机数后，使用自己的私钥解密，得到"premaster secret"。然后，客户端和服务器都使用这三个随机数，通过一个密钥生成算法，生成同样的会话密钥。

5. 客户端和服务器都发送一个"Finished"消息，其中包含了所有前面消息的一个hash值，用于验证对方是否有篡改消息。

https的公钥是和证书一起发送的吗？还是客户端根据证书自己算的？

在HTTPS的SSL/TLS握手过程中，服务器的公钥是包含在服务器发送给客户端的证书中的。证书是由一个可信的第三方证书颁发机构（CA）签发的，它包含了服务器的公钥和一些服务器的信息，如服务器的域名，组织名称等。

当客户端收到服务器的证书后，它会做两件事情：

1. 验证证书的有效性。客户端会检查证书是否是由一个可信任的CA签发的，是否在有效期内，以及证书中的域名是否和服务器的域名匹配。

2. 从证书中获取服务器的公钥。公钥会用于后续的加密操作，例如，客户端会使用这个公钥来加密"premaster secret"，然后发送给服务器。

所以，服务器的公钥是和证书一起发送给客户端的，客户端不需要自己计算公钥。

客户端是如何检查证书是否是由一个可信任的CA签发的？

客户端检查证书是否由可信任的证书颁发机构（CA）签发，主要依赖于证书链和根证书。

1. 证书链：一个HTTPS证书通常包含一个证书链，也就是一系列的证书，从您的服务器证书开始，通过中间证书，最终到达根证书。每一个证书都是由上一个证书在链中的实体签署的。

2. 根证书：这些是由信任的证书颁发机构（CA）签发的，预先安装在操作系统或浏览器中。它们是信任链的根源。

在SSL/TLS握手过程中，服务器将其证书（包含公钥和服务器信息）和证书链发送给客户端。客户端首先会检查服务器证书的有效性，如过期时间、证书中的域名是否与服务器的域名一致等。然后，客户端会使用证书链，从服务器证书开始，验证每一级证书是否都是由上一级证书签署的，直到验证到根证书。

由于根证书是预先安装在客户端系统或浏览器中的，客户端可以信任它们。如果整个证书链都能正确验证，那么客户端就可以确认服务器证书是由可信任的CA签发的。

此外，客户端还可能会检查证书撤销列表（CRL）或使用在线证书状态协议（OCSP），以确认证书没有被撤销。

那么客户端的私钥是怎么来的？它的作用是什么？

在HTTPS的SSL/TLS握手过程中，客户端并不需要一个固定的私钥。实际上，客户端和服务器会在握手过程中协商出一个叫做"会话密钥"的共享秘密，这个会话密钥会被用于后续的数据加密和解密。

这个过程大致如下：

1. 服务器将其公钥（包含在服务器证书中）发送给客户端。

2. 客户端生成一个随机的"premaster secret"，然后使用服务器的公钥对它进行加密，然后将加密后的"premaster secret"发送给服务器。

3. 服务器使用自己的私钥对收到的加密的"premaster secret"进行解密，得到原始的"premaster secret"。

4. 现在，客户端和服务器都有了同样的"premaster secret"，然后他们会使用这个"premaster secret"和一些其他的公开信息（例如随机数）来生成同样的会话密钥。

这个会话密钥就是接下来用来加密和解密HTTP数据的密钥。这个过程保证了即使有人能够监听到客户端和服务器之间的通信，他们也无法得到会话密钥，因此无法解密数据。

所以，客户端并不需要一个私钥。客户端和服务器的秘密信息（例如会话密钥）是在SSL/TLS握手过程中动态生成的。

那么其实私钥和公钥都是服务器的？客户端只是拿到公钥加密了数据？只不过这个私钥是可以用来逆向解密公钥的数据的吗？

是的，在HTTPS的SSL/TLS握手过程中，私钥和公钥都是服务器的。公钥是包含在服务器发送给客户端的证书中的，而私钥则始终存储在服务器上，不会发送给任何人。这是非对称加密的特性，即使用公钥加密的信息只能用相应的私钥解密，反之亦然。

在握手过程中，客户端会生成一个随机的"premaster secret"，然后使用服务器的公钥对它进行加密，然后将加密后的"premaster secret"发送给服务器。服务器接收到加密的"premaster secret"后，使用自己的私钥解密，得到原始的"premaster secret"。

然后，客户端和服务器都会使用这个"premaster secret"和其他一些公开的信息（例如随机数）来生成同样的会话密钥。这个会话密钥将用于后续的数据加密和解密。

这个过程保证了即使有人能够监听到客户端和服务器之间的通信，他们也无法得到会话密钥，因此无法解密数据。这就是所谓的"前向保密"。

那么ssh中使用的密钥对免密登录的时候，需要把.ssh文件夹的rsa文件下载到客户端，那么这个rsa是私钥还是公钥？

在SSH免密登录中，使用的是公钥加密技术。用户在本地生成一对密钥，包括私钥和公钥。私钥保存在本地，公钥可以放在任何需要登录的服务器上。当你尝试通过SSH连接到服务器时，服务器会发送一个随机数给你的客户端，客户端使用私钥对这个随机数进行加密，然后将加密后的信息发送回服务器。服务器使用已经存储的公钥对这个信息进行解密，如果解密成功，那么就证明了你是拥有相应私钥的合法用户，于是允许你登录。

所以，在SSH免密登录中，你需要在本地保存私钥（通常是一个名为id_rsa的文件），并将公钥（通常是一个名为id_[rsa.pub](http://rsa.pub)的文件）放在服务器上（通常放在.ssh/authorized_keys文件中）。因此，.ssh文件夹中的rsa文件通常是私钥。

这个私钥文件是要在服务器生成还是客户端生成？

您可以在服务器上生成密钥对，但是在SSH免密登录中，通常的做法是在本地（即客户端）生成密钥对，然后将公钥复制到服务器。

如果您在服务器上生成了密钥对，那么您需要将生成的私钥文件安全地复制到客户端，然后删除服务器上的私钥。这是因为私钥必须保密，只能存储在您信任的地方，一般来说，就是您的本地机器。公钥则可以放在任何地方，包括服务器。

所以，尽管在服务器上生成密钥对是可能的，但通常的做法是在本地生成，这样可以避免私钥在网络中传输，降低了私钥被窃取的风险。

那么wss是如何加密的？

WebSocket Secure（WSS）协议是WebSocket协议的安全版本，它实现了数据的加密传输。WSS协议的加密过程与HTTPS协议非常相似，都是基于TLS（Transport Layer Security）协议进行加密的。

以下是WSS的基本工作流程：

1. 客户端和服务器发起一个握手请求，这个握手请求是通过HTTPS进行的，因此会包含TLS握手过程。

2. 在TLS握手过程中，客户端和服务器会协商加密的详细参数，并交换公钥。

3. 客户端会验证服务器的证书，如果证书有效，客户端会生成一个随机的密钥（也叫做premaster secret），然后用服务器的公钥加密这个密钥，然后发送给服务器。

4. 服务器使用自己的私钥解密得到这个premaster secret，然后双方使用这个密钥生成会话密钥。

5. 之后的所有通信都会使用这个会话密钥进行加密，确保数据的安全性。

所以，WSS的加密过程是基于公钥加密和对称加密的组合，这样既能保证安全性，又能保证效率。

他和https都是一样的吗？

WebSocket Secure (WSS) 和 HTTPS 在安全性方面有很多相似之处，因为它们都使用了TLS（传输层安全）协议来保证数据的安全传输。然而，尽管它们的安全机制相似，但它们在应用层面上有一些重要的不同。

HTTPS 是 HTTP 协议的安全版本，它是一种请求-响应协议，用于在客户端和服务器之间传输网页。每一个HTTPS请求都会打开一个新的连接，请求完成后这个连接就会关闭。虽然现代的浏览器和服务器会尽量复用已经打开的连接，但本质上HTTPS还是一种无状态的协议。

而 WSS 则是 WebSocket 协议的安全版本，它是一种全双工的通信协议，可以在客户端和服务器之间建立持久的连接，双方都可以随时向对方发送数据。这使得 WSS 非常适合实时通信的场景，例如聊天应用、多人在线游戏等。

所以，尽管 WSS 和 HTTPS 在安全性方面有很多相似之处，但它们在应用层面上有一些重要的不同。

那么TLS是什么？

TLS，全称为Transport Layer Security，即传输层安全协议，是一种为网络通信提供安全和数据完整性的协议。TLS协议的前身是SSL（Secure Sockets Layer，安全套接字层协议），由网景公司（Netscape）开发。现在，TLS已经成为网页、电子邮件、即时通讯和VoIP等各种网络通信中保障安全的重要工具。

TLS工作在传输层（例如TCP）之上，应用层（例如HTTP）之下。当应用层协议需要安全通信时，例如HTTPS，就会使用TLS协议。

TLS协议主要有两个部分：握手协议和记录协议。

1. 握手协议：在通信开始前，客户端和服务器会通过握手协议建立一个安全的连接，协商加密算法和密钥等参数。这个过程中，服务器会向客户端发送证书，证书中包含了服务器的公钥和一些其他信息。客户端会验证这个证书的有效性，然后生成一个随机的密钥（premaster secret），使用服务器的公钥加密，然后发送给服务器。服务器使用自己的私钥解密得到这个密钥，然后双方使用这个密钥生成会话密钥。这个过程中，会话密钥在网络中从未直接传输，确保了安全性。

2. 记录协议：握手协议完成后，客户端和服务器就可以开始安全的通信了。他们会使用会话密钥来加密和解密数据，使用消息认证码来保证数据的完整性。

所以，简单来说，TLS就是一种保证网络通信安全的协议，它通过握手协议来协商加密参数，并通过记录协议来保证数据的安全传输。

TLS和SSL的区别是什么？

SSL（Secure Sockets Layer）和TLS（Transport Layer Security）都是为网络通信提供安全和数据完整性的协议。实际上，TLS是SSL的后续版本，但是由于历史原因，很多人还是习惯性地称呼这类协议为SSL。

SSL是在1990年代由网景公司（Netscape）开发的，目的是为了解决网络通信的安全问题。SSL经过了几个版本的迭代，最后一个版本是SSL 3.0。

然而，在SSL 3.0发布后不久，人们就发现了其中一些严重的安全问题。为了解决这些问题，以及为了提供更好的安全性和可扩展性，IETF（Internet Engineering Task Force）开发了一个新的协议，并将其命名为TLS 1.0。TLS 1.0在很大程度上基于SSL 3.0，但是做了一些重要的改进。

从那时起，TLS就取代了SSL，成为了主流的安全协议。到目前为止，TLS已经发展到了1.3版本，每个新版本都在安全性和效率上做了改进。

所以，从技术角度来看，TLS和SSL的主要区别在于它们的版本和安全性。TLS是SSL的后续版本，提供了更好的安全性和更高的效率。然而，在日常对话中，人们往往仍然使用“SSL”这个词来泛指这类协议，尽管实际使用的协议可能是TLS。

---

以上就是关于网络篇所有的问题了，相信如果你认真看到这里，萦绕在你脑海的大部分问题都已经烟消云散了，如果还有不甚了解的地方，欢迎留言，将一定为您解答！