问题：﻿在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？ 一个老问题了，希望在知乎上有更加详细深入的回答，谢谢
话题：﻿互联网、程序员、科技、计算机网络、计算机科学
回答：﻿为了让更多读者理解这个问题，接下来派出男主角小明出场，采用拟人的手法来阐述整个过程。小明听说最近两天知乎有一个帖子挺火，问题的提出者是腾讯的总裁PonyMa，有一个回答是这样的：于是小明想去看看精彩评论，于是开始了网上冲浪之旅。。。小明打开浏览器，输入http://zhihu.com敲回车键。在小明眼里，浏览器是自己的小奴才，让你干啥就干啥。浏览器才不这么看，鄙人也是有自己独立的人格的。老板的命令是对的，那自然照做。如果是错误的，就当老板放P！如果小明输入的是“zhihu.com”或“zhi@hu.com1”,这些网址都是非法无效的，浏览器就要拒绝小明的无理要求，提示小明出错了。所以，第一步是浏览器对用户输入的网址做初步的格式化检查，只有通过以上检查才会进入下一步。浏览器是用http还是https访问服务器呢？小明并没有明确告知浏览器是用哪个协议，针对此种情况，浏览器有自己的预案，那就是默认使用http协议，除非小明输入的是“https://http://zhihu.com”。所以，小明输入的网址被浏览器补齐为“http://zhihu.com”。浏览器知道，TCP/IP快递公司那帮王八蛋，只有告诉它们收件人的IP地址，才会把快递送到收件人地址。告诉他们“zhihu.com”如同对牛弹琴，它们不懂啊！浏览器于是联系“黄页公司”DNS，请帮我查询一下“zhihu.com”的IP地址是多少？DNS是个老实孩子，自己能查询到的，绝不麻烦别人。先查自己内存里的DNSCache，没有！再查本地硬盘里的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，知道这是DNSServer大叔家的快递。喊大叔来收快递，大叔打开包裹一看，这个好回答啊，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，联系到了httpserver小姐姐。小姐姐返回了一个消息：HTTPRedirect消息，大意是，本公司服务器整体搬迁到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”，由GeoTrustRSACA2018签名并颁发证书2:“GeoTrustRSACA2018”，由DigiCertGlobalRootCA签名并颁发验证过程如下：1.用DigiCertGlobalRootCA的公钥解密证书2的签名DigiCertGlobalRootCA作为一个权威CA，已经被浏览器预先安装在可信任根证书列表，那么我们信任该CA的一切，当然包括其公钥，在该证书里包含了明文的公钥，如下图所示：解开了，证明是该CA私钥加密的，由于CA私钥只有CA知道，证书有效，并信任GeoTrustRSACA2018公钥。解不开，证明不是CA私钥加密，无效证书。2.用GeoTrustRSACA2018的公钥解密证书1的签名过程和步骤1同样的原理，如果2个步骤都验证成功，就有了http://zhihu.com的公钥。TLS大叔还需要检查的证书有效期，再检查证书是否被吊销(CRL)，如果一切都没有问题，进入下一个步骤。TLS大叔用“*.zhihu.com”公钥加密一段随机的字符串，发送给TLS服务器。TLS服务器用自己的私钥解密，得到明文字符串。至此，双方分享了这个神秘的字符串，双方还有早前分享的随机码(nonce)，双方使用同样的算法，可以推导出相同的masterkey，进而推导出sessionkey、HMACkey。SessionKey用于加密/解密数据，HMACKey主要用于保护数据的完整性，以防被第三方篡改。整个TLS沟通过程就算完成了，TLS大叔把浏览器扔给自己的包裹，外面加了一层保险箱，密码锁（sessionkey）只有TLS大叔、TLS服务器知道。然后把保险箱再扔给TCP阿姨，TCP阿姨一点也不在乎，运输一个保险箱与一个普通包裹没有任何区别，唯一的区别是收件人的门牌号变了：收件人门牌号443然后保险箱就被运走了，很快就到达了目的地，服务器老大爷一看门牌号443，知道这是TLS服务器的快递包裹。TLS服务器用密码打开了保险箱，取出了快递。在保险箱里还有一个小纸条写着“ApplicationData=http”,TLS服务器知道这是HTTPServer高富帅的包裹。然后把包裹转交给高富帅，高富帅将http://www.zhihu.com主页返回，并最终到达浏览器。小明很快就搜索到本文开始的那个回答，小明做梦都没有想到，自己的一次回车键，引发如此庞大的计算量。。。更多文章，请阅读：在浏览器地址栏输入一个URL后回车，背后会进行哪些技术步骤？​mp.weixin.qq.com