浏览器访问URL的一般过程：
1、格式验证与协议选择（默认为HTTP）
首先我们应该知道，浏览器也是有自己独立的人格的，主人的命令如果是对的，那自然照做。那如果是错误的，那就必然不会听取命令，当然也不能听取命令？
故当我们在浏览器中输入希望查询的URL，如果输入的是非法无效的网址，浏览器就会提示出错了。
所以，第一步是浏览器对用户输入的网址做初步的格式化检查，只有通过以上检查才会进入下一步。
那么浏览器是用http还是https访问服务器呢？
当输入正确的网址之后，比如qq.com，浏览器会默认进行补全，此时除非我们补全输入为https://qq.com，否则浏览器默认选择的协议是http协议！
2、DNS 查询
就好比我们寄快递，需要知道对方的收货地址才能使收件人收到快递，此处浏览器也是如此，只有当浏览器告诉TCP/IP“收件人”的IP地址，才会把消息送到“收件人”地址。所以浏览器联系本地DNS，请求DNS帮忙查询一下“qq.com”的IP地址
然后DNS查自己内存里的DNS Cache、本地硬盘里的host文件。按顺序查找下来之后如果都没有，只能去联系自己的DNS服务器8.8.8.8（不一定是8.8.8.8，可以自己静态配置或着动态获取），DNS将自己的查询消息打好包，收件人地址为8.8.8.8，寄件人地址为1.1.1.1，DNS联系TCP/IP。此时由UDP负责消息的转发，UDP将填写以下信息：“收件人”端口号：53，“发件人”端口号：56002，同时也知道采用的是UDP协议，这就是源地址、目的地址、源端口号、目的端口号、协议五元组！（之所以要有端口号，是因为一个“收件人”地址可能会有多个端口号，为了避免混淆。）
然后TCP/IP中的IP查询路由表，发现要通过网关（Gateway），需要知道MAC地址。一说到MAC地址，此时ARP（地址解析协议）便出现了，声音洪亮地喊了一嗓子，网关你MAC地址多少啊！很快传来了网关的回答：我的MAC地址是xx.xx.xx.xx.xx.xx。
有了网关的MAC地址，IP带着要传递的数据上路了。到达了关口，网关放行，然后IP穿梭在Internet高速公路，一路狂奔。到达目的地8.8.8.8，服务器根据端口号53，知道这是DNS Server的包裹。DNS Server打开包裹一看，“qq.com”对应的IP地址正好在缓存里呢，于是将其回复回去。但是如果此DNS Server本地缓存中没有，那它将去联系DNS域名系统的根服务器“.”。此处顺带提一嘴，根域名服务器全球一共13台，13台之间可以互相提供物理冗余，分摊全球的域名查询任务。
DNS Server就会去联系13台根服务器的一员，查询自己想要的结果（DNS Server知道根服务器）。跟之前使用同样的方式，查询消息到达根服务器，根服务器一看“qq.com.”，知道“com”会知道，于是告诉DNS server，请去联系“com”，他的IP地址是x.x.x.x。于是乎DNS server锲而不舍地去联系“com”，毫无疑问，“com”将结果告诉了DNS server，最后DNS server将服务器IP地址返回给本地DNS，本地DNS把结果返回给浏览器。
3、TCP三次握手
浏览器再次联系TCP/IP，此时TCP出面，众所周知TCP做事非常认真。得知浏览器想要去拜访“x.x.x.x（qq.com对应的IP地址）”，先和对方取得联系，看看对方在不在，这通常由三次握手实现的。三次握手的过程都需要IP来来回回运输三次消息，具体过程和第二步IP运输DNS报文非常类似，就不再赘述。
三次握手完成，TCP与对方建立了一个可靠的虚拟通道，浏览器很快知道了这个消息。然后浏览器将http请求消息，打包好扔给TCP，TCP在包裹上填上关键信息：“收件人”端口号：80，“发件人”端口号：51235。然后仍是通过IP来运输，过程与上文类似。包裹到达了目的地，服务器根据门牌号80，联系到了http server。
http server返回了一个消息：HTTP Redirect 消息，大意是，服务器整体搬迁https://www.qq.com上去了，请重新访问本司的新网址（此时采用的是 https 协议）。浏览器收到这个消息，立马前往https://www.qq.com，整个过程与http:/zhihu.com大体相似，以下主要阐述不一样的地方。
TCP三次握手成功之后，浏览器将自己的打包好的包裹，不是直接扔给TCP，而是委托TLS全权负责。TLS首要的任务是确保包裹在运输过程中的安全，即包裹的内容保密，包裹内容不能被篡改、替换。由于 http 是明文传输的会不安全，而 https 协议是加密的、安全的，需要经过证书验证等步骤。
TLS就相当于一个保镖，在TLS工作时它会先和对方沟通安保措施，沟通的渠道–就是上文三次握手建立的渠道。
TLS先说：你好，我支持TLS版本1.2，以及我的认证算法、加密算法、数据校验算法，此外还有我的随机码，收到请回复。
TLS服务器回复：你好，我也支持1.2版本，那我们就使用xx认证算法、xx加密算法、xx数据校验算法，我的随机码是xx，来实现安保措施，你看好吗？
TLS:没问题啊，能出示一下你的证件(数字证书)吗？
TLS服务器：OK，你瞅瞅，这是我的证件（同时发送证书）。
TLS发现TLS服务器发过来两个证书：
证书1: “*.qq.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个步骤都验证成功，就有了qq.com的公钥。
除此之外，TLS还需检查证书有效期，再检查证书是否被吊销(CRL)，如果一切都没有问题，进入下一个步骤。
TLS大叔用“*.qq.com”公钥加密一段随机的字符串，发送给TLS服务器。
TLS服务器用自己的私钥解密，得到明文字符串。
至此，双方分享了这个神秘的字符串，双方还有早前分享的随机码(nonce)，双方使用同样的算法，可以推导出相同的master key，进而推导出session key、HMAC key。（Session Key用于加密/解密数据， HMAC Key主要用于保护数据的完整性，以防被第三方篡改。）
4、访问新网址
整个TLS沟通过程完成，TLS把浏览器扔给自己的包裹，外面加了一层保险箱，密码锁（session key）只有TLS、TLS服务器知道。然后把“保险箱”再扔给TCP，此时TCP运输一个“保险箱”与一个普通包裹没有任何区别，唯一的区别是收件人的端口号变了：“收件人”端口号：443，然后“保险箱”就被运走了，到达了目的地之后，服务器一看端口号443，知道这是TLS服务器的快递包裹，于是交给TLS服务器。TLS服务器用密码打开了“保险箱”，取出了快递。
在“保险箱”里还有一个小纸条“Application Data =http”, TLS服务器知道这是HTTP Server的包裹。然后把包裹转交给HTTP Server，HTTP Server将www.qq.com 主页返回，并最终到达浏览器。
后续过程中，会断开TCP会话，释放TCP连接，减轻服务器负荷。
到此一次回车键引发的庞大的计算量就结束啦！
注：此过程本人觉得并不是最全面的，以后会进一步进行补充
HTTP部分有问题可以参照HTTP、SSL VPN简单理解中的HTTP部分！
TCP三次握手部分有问题可以参照HTTP、SSL VPN简单理解中TCP部分！
作者：苏小酱