在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤?

打开浏览器，输入http://zhihu.com敲回车键。

第一步是浏览器对用户输入的网址做初步的格式化检查，只有通过以上检查才会进入下一步。(如果小明输入的是 “zhi hu.com” 或 “zhi@hu.com1”, 这些网址都是非法无效的，浏览器就要拒绝小明的无理要求，提示小明出错了)

浏览器是用http还是https访问服务器呢？
小明并没有明确告知浏览器是用哪个协议，针对此种情况，浏览器有自己的预案，那就是默认使用http协议，除非小明输入的是“https ://http://zhihu.com”。

所以，小明输入的网址被浏览器补齐为“http://zhihu.com” 。


浏览器请求DNS，查询一下“zhihu.com” 的IP地址是多少？

先查自己内存里的DNS Cache，没有！
再查本地硬盘里的host文件，也没有！

实在没辙只有求人了，于是DNS硬着头皮去联系自己的DNS服务器 8.8.8.8。

DNS将自己的查询打好包，收件人地址为8.8.8.8，寄件人地址为1.1.1.1，DNS联系TCP/IP快递公司。

负责接洽的是UDP，UDP懒洋洋的躺在沙发上，随手在包裹上刷刷写了几笔：

收件人门牌号 53
发件人门牌号 56002

之所以要有门牌号，是因为一个收件人地址可能会有多个门牌号，为了避免混淆。对于整天浸淫在快递行业的UDP，太了解这个行业了。

UDP给货车司机IP打电话：老四啊，有件快递需要你捎带一下。。。

IP司机来了，把包裹扔上车，坐上驾驶座，准备开车。

IP司机查询了导航(IP路由表)，发现要出关(Gateway)，这个关口有点怪癖，需要司机知道其MAC地址，导航信息里竟然没有。

于是IP司机找到了当地向导ARP，老师傅，麻烦您带带路啊！

ARP没有废话，声音洪亮地喊了一嗓子，网关你MAC地址多少啊，告诉老夫一声！

很快传来了网关的回答：我的MAC地址是xx.xx.xx.xx.xx.xx

有了关口的MAC地址，IP司机终于可以开车上路了。

很快就到达了关口，关口放行，IP司机载着快递，上了Internet高速公路，一路狂奔不表。。。

到达目的地8.8.8.8，服务器根据门牌号码53，知道这是DNS Server大叔家的快递。

喊大叔来收快递，大叔打开包裹一看，这个好回答啊，http://zhihu.com对应的IP地址正好在缓存里还热着呢，于是将其回复回去。

这个DNS大叔有一个特点，打破沙锅问到底的学习精神，俗称的一根筋。如果DNS大叔的本地缓存里查询没有，怎么办呢？

DNS大叔会去联系DNS域名系统的根服务器“.”

有读者会问，“.”代表的就是根服务器？

对的，我们经常看到的网址如http://zhihu.com，完整的写法应该是 zhihu.com. 最后的那个“.”相当于树根，天下所有的叶子域名，都是树根的孩子、孩子的孩子....

根域名服务器全球一共多少台？
13台

1台不行吗？
万一根服务器挂了，会影响全球的域名查询系统。使用多台根服务器，可以提供物理冗余，分摊全球的域名查询任务。

DNS大叔知道13台根服务器的IP地址吗？
知道。

DNS大叔就会去联系13台根服务器的一员，查询自己想要的结果。

根服务器一看“zhihu.com.” ，知道是自己的孙子，却不知道其IP地址。但根服务器相信孙子的爸爸“com”会知道，于是告诉DNS大叔，请去联系我孙子的爸爸，他的IP地址是x.x.x.x。

DNS大叔锲而不舍地去联系孙子的爸爸，毫无疑问，爸爸肯定知道儿子的IP地址，儿子的名字都是自己起的，能不知道吗？

将结果告诉了DNS大叔，大叔如获至宝，立马将结果告诉了远在千里之外等待的DNS老实孩子，结果应该是这个样子的：

累死了，鼓捣了半天才算拿到服务器的IP地址，DNS把结果返回给浏览器。

浏览器再次联系TCP/IP快递公司，这次与其接洽的是TCP阿姨，TCP做事非常认真。

知道浏览器想要去拜访“118.89.204.100”，先和对方取得联系，看看对方在不在，这通常由三次握手实现的。

老阿姨：在家吗？想去拜访您。
对方：在的，欢迎啊。
老阿姨：马上到。

这一来二回的三次消息，也都需要IP司机来来回回运输三次，具体过程和上文IP司机运输DNS报文非常类似，就不再重复。

三次握手完成，TCP阿姨与对方建立了一个可靠的虚拟通道，浏览器很快知道了这个消息。

浏览器将http请求消息，打包好扔给TCP阿姨，阿姨在包裹上填上关键信息：

收件人门牌号 80
发件人门牌号 51235

然后也是联系IP司机来运输，过程不表。

包裹到达了目的地，服务器根据门牌号80，联系到了http server小姐姐。

小姐姐返回了一个消息：HTTP Redirect 消息，大意是，本公司服务器整体搬迁到https://www.zhihu.com上去了，请重新访问本司的新网址。


浏览器收到这个消息，立马前往https://www.zhihu.com，整个过程与http:/http://zhihu.com大体相似，接下来主要阐述不一样的地方。

TCP三次握手成功之后，浏览器将自己的打包好的包裹，不是直接给TCP阿姨，而是委托TLS安保大叔全权负责。

TLS安保大叔，首要的任务是确保包裹在运输过程中的安全，即包裹的内容保密，包裹内容不能被篡改、替换。

TLS大叔需要先和对方沟通安保措施，沟通的渠道，就是上文三次握手建立的渠道。

TLS大叔先发言：你好，我支持TLS版本1.2，以及我的认证算法、加密算法、数据校验算法，此外还有我的随机码，收到请回复。

TLS服务器回复：你好，我也支持1.2版本，那我们就使用xx认证算法、xx加密算法、xx数据校验算法，我的随机码是xx，来实现安保措施，你看好吗？

TLS大叔:没问题啊，能出示一下你的证件(数字证书)吗？
TLS服务器：okay，这是我的证件，请过目。


TLS大叔发现对方发过来两个证书：
证书1: “*.zhihu.com”，由GeoTrust RSA CA 2018签名并颁发
证书2: “GeoTrust RSA CA 2018”，由DigiCert Global Root CA签名并颁发


验证过程如下：

1.用DigiCert Global Root CA的公钥解密证书2的签名


DigiCert Global Root CA作为一个权威CA，已经被浏览器预先安装在可信任根证书列表，那么我们信任该CA的一切，当然包括其公钥，在该证书里包含了明文的公钥，如下图所示：

解开了，证明是该CA私钥加密的，由于CA私钥只有CA知道，证书有效，并信任GeoTrust RSA CA 2018公钥。

解不开，证明不是CA私钥加密，无效证书。



2. 用GeoTrust RSA CA 2018的公钥解密证书1的签名

过程和步骤1同样的原理，如果2个步骤都验证成功，就有了http://zhihu.com的公钥。

TLS大叔还需要检查的证书有效期，再检查证书是否被吊销(CRL)，如果一切都没有问题，进入下一个步骤。

TLS大叔用“*.zhihu.com”公钥加密一段随机的字符串，发送给TLS服务器。
TLS服务器用自己的私钥解密，得到明文字符串。

至此，双方分享了这个神秘的字符串，双方还有早前分享的随机码(nonce)，双方使用同样的算法，可以推导出相同的master key，进而推导出session key、HMAC key。

Session Key用于加密/解密数据， HMAC Key主要用于保护数据的完整性，以防被第三方篡改。

整个TLS沟通过程就算完成了，TLS大叔把浏览器扔给自己的包裹，外面加了一层保险箱，密码锁（session key）只有TLS大叔、TLS服务器知道。

然后把保险箱再扔给TCP阿姨，TCP阿姨一点也不在乎，运输一个保险箱与一个普通包裹没有任何区别，唯一的区别是收件人的门牌号变了：

收件人门牌号 443

然后保险箱就被运走了，很快就到达了目的地，服务器老大爷一看门牌号443，知道这是TLS服务器的快递包裹。

TLS服务器用密码打开了保险箱，取出了快递。

在保险箱里还有一个小纸条写着“Application Data =http”, TLS服务器知道这是HTTP Server高富帅的包裹。

然后把包裹转交给高富帅，高富帅将http://www.zhihu.com 主页返回，并最终到达浏览器。

小明很快就搜索到本文开始的那个回答，小明做梦都没有想到，自己的一次回车键，引发如此庞大的计算量。。。