【转载】在浏览器地址栏输入一个URL回车后，究竟会发生什么？
小明打开浏览器，输入idleleo.com敲回车键。
在小明眼里，浏览器是自己的小奴才，让你干啥就干啥。
浏览器才不这么看，鄙人也是有自己独立的人格的，老板的命令如果是对的，那自然照做。那如果是错误的，那就不能听命不是？
如果小明输入的是 “idle leo.com” 或 “idle@leo.com1”, 这些网址都是非法无效的，浏览器就要拒绝小明的无理要求，提示小明出错了。
所以，第一步是浏览器对用户输入的网址做初步的格式化检查，只有通过以上检查才会进入下一步。
浏览器是用http还是https访问服务器呢？
小明并没有明确告知浏览器是用哪个协议，针对此种情况，浏览器有自己的预案，那就是默认使用http协议，除非小明输入的是“https://idleleo.com”。
所以，小明输入的网址被浏览器补齐为“http://idleleo.com” 。
浏览器知道，TCP/IP快递公司那帮王八蛋，只有告诉它们收件人的IP地址，才会把快递送到收件人地址。告诉他们 “idleleo.com”如同对牛弹琴，它们不懂啊！
浏览器于是联系“黄页公司” DNS，请帮我查询一下“idleleo.com” 的IP地址是多少？
DNS是个老实孩子，自己能查询到的，绝不麻烦别人。
先查自己内存里的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大叔家的快递。
喊大叔来收快递，大叔打开包裹一看，这个好回答啊，idleleo.com对应的IP地址正好在缓存里还热着呢，于是将其回复回去。
这个DNS大叔有一个特点，打破沙锅问到底的学习精神，俗称的一根筋。如果DNS大叔的本地缓存里查询没有，怎么办呢？
DNS大叔会去联系DNS域名系统的根服务器“.”
有读者会问，“.”代表的就是根服务器？
对的，我们经常看到的网址如idleleo.com，完整的写法应该是 idleleo.com. 最后的那个“.”相当于树根，天下所有的叶子域名，都是树根的孩子、孩子的孩子....
根域名服务器全球一共多少台？
13台
1台不行吗？
万一根服务器挂了，会影响全球的域名查询系统。使用多台根服务器，可以提供物理冗余，分摊全球的域名查询任务。
DNS大叔知道13台根服务器的IP地址吗？
知道。
DNS大叔就会去联系13台根服务器的一员，查询自己想要的结果。
根服务器一看“idleleo.com.” ，知道是自己的孙子，却不知道其IP地址。但根服务器相信孙子的爸爸“com”会知道，于是告诉DNS大叔，请去联系我孙子的爸爸，他的IP地址是x.x.x.x。
DNS大叔锲而不舍地去联系孙子的爸爸，毫无疑问，爸爸肯定知道儿子的IP地址，儿子的名字都是自己起的，能不知道吗？
将结果告诉了DNS大叔，大叔如获至宝，立马将结果告诉了远在千里之外等待的DNS老实孩子，结果应该是这个样子的：
累死了，鼓捣了半天才算拿到服务器的IP地址，DNS把结果返回给浏览器。
浏览器再次联系TCP/IP快递公司，这次与其接洽的是TCP阿姨，TCP做事非常认真。
知道浏览器想要去拜访“47.96.6.248”，先和对方取得联系，看看对方在不在，这通常由三次握手实现的。
老阿姨：在家吗？想去拜访您。
对方：在的，欢迎啊。
老阿姨：马上到。
这一来二回的三次消息，也都需要IP司机来来回回运输三次，具体过程和上文IP司机运输DNS报文非常类似，就不再重复。
三次握手完成，TCP阿姨与对方建立了一个可靠的虚拟通道，浏览器很快知道了这个消息。
浏览器将http请求消息，打包好扔给TCP阿姨，阿姨在包裹上填上关键信息：
收件人门牌号 80
发件人门牌号 51235
然后也是联系IP司机来运输，过程不表。
包裹到达了目的地，服务器根据门牌号80，联系到了http server小姐姐。
小姐姐返回了一个消息：HTTP Redirect 消息，大意是，本公司服务器整体搬迁到https://www.idleleo.com上去了，请重新访问本司的新网址。
浏览器收到这个消息，立马前往https://www.idleleo.com，整个过程与http:/idleleo.com大体相似，接下来主要阐述不一样的地方。
TCP三次握手成功之后，浏览器将自己的打包好的包裹，不是直接给TCP阿姨，而是委托TLS安保大叔全权负责。
TLS安保大叔，首要的任务是确保包裹在运输过程中的安全，即包裹的内容保密，包裹内容不能被篡改、替换。
TLS大叔需要先和对方沟通安保措施，沟通的渠道，就是上文三次握手建立的渠道。
TLS大叔先发言：你好，我支持TLS版本1.2，以及我的认证算法、加密算法、数据校验算法，此外还有我的随机码，收到请回复。
TLS服务器回复：你好，我也支持1.2版本，那我们就使用xx认证算法、xx加密算法、xx数据校验算法，我的随机码是xx，来实现安保措施，你看好吗？
TLS大叔:没问题啊，能出示一下你的证件(数字证书)吗？
TLS服务器：okay，这是我的证件，请过目。
TLS大叔发现对方发过来两个证书：
证书1: “*.idleleo.com”，由Let's Encrypt Authority X3签名并颁发
证书2: “Let's Encrypt Authority X3”，由DST Root CA X3签名并颁发
验证过程如下：
1.用Let's Encrypt Authority X3的公钥解密证书2的签名
Let's Encrypt Authority X3作为一个权威CA，已经被浏览器预先安装在可信任根证书列表，那么我们信任该CA的一切，当然包括其公钥，在该证书里包含了明文的公钥，如下图所示：
解开了，证明是该CA私钥加密的，由于CA私钥只有CA知道，证书有效，并信任
Let's Encrypt Authority X3 公钥。
解不开，证明不是CA私钥加密，无效证书。
2. 用Let's Encrypt Authority X3的公钥解密证书1的签名
过程和步骤1同样的原理，如果2个步骤都验证成功，就有了idleleo.com的公钥。
TLS大叔还需要检查的证书有效期，再检查证书是否被吊销(CRL)，如果一切都没有问题，进入下一个步骤。
TLS大叔用“*.idleleo.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高富帅的包裹。
然后把包裹转交给高富帅，高富帅将www.idleleo.com 主页返回，并最终到达浏览器。
