在我们点击一个网址，到它能够呈现在浏览器中，展示在我们面前，这个过程中，电脑里，网络上，究竟发生了什么事情。

  服务器启动监听模式

  那我们就开始了，故事其实并不是从在浏览器的地址栏输入一个网址，或者我们抓着鼠标点击一个链接开始，事情的开端要追溯到服务器启动监听服务的时候，在某个未知的时刻，一台机房里普普通通的刀片服务器，加上电，启动了操作系统，随着操作系统的就绪，服务器启动了 http 服务进程，这个 http 服务的守护进程，（daemon），可能是 apache，也可能是 nginx，不管怎么说js网页计数器，这个 http 服务进程开始定位到服务器上的 www 文件夹，一般是位于 /var/www ，然后启动了一些附属的模块，例如 php，或者，使用 fastcgi 方式连接到 php 的 fpm 管理进程，然后，向操作系统申请了一个 tcp 连接，然后绑定在了 80 端口，调用了 accept 函数，开始了默默的监听，监听着可能来自位于地球任何一个地方的请求，随时准备做出响应。

  这个时候，典型的情况下，机房里面应该还有一个数据库服务器，或许，还有一台缓存服务器，如果对于流量巨大的网站，那么动态脚本的解释器可能还有单独的物理机器来跑，如果是中小的站点，那么，上述的各色服务，甚至都可能在一台物理机上，这些服务监听之间的关系。不管怎么说，他们做好了准备，静候差遣。

  客户端浏览器发送请求1. 解析URL2. 输入的是 URL 还是搜索的关键字？

  当协议或主机名不合法时，浏览器会将地址栏中输入的文字传给默认的搜索引擎。大部分情况下，在把文字传递给搜索引擎的时候，URL会带有特定的一串字符，用来告诉搜索引擎这次搜索来自这个特定浏览器。

  3. 转换非 ASCII 的 Unicode 字符5. dns查询6. ARP 过程

  要想发送 ARP（地址解析协议）广播，我们需要有一个目标 IP 地址，同时还需要知道用于发送 ARP 广播的接口的 MAC 地址。

  我们发送一个二层（ OSI 模型 中的数据链路层）ARP 请求：

  ARP Request:

  1

  2

  3

  4

  Sender MAC: interface:mac:address:here

  Sender IP: interface.ip.goes.here

  Target MAC: FF:FF:FF:FF:FF:FF (Broadcast)

  Target IP: target.ip.goes.here

  根据连接主机和路由器的硬件类型不同，可以分为以下几种情况：

  直连：

  集线器：

  ARP Reply:

  1

  2

  3

  4

  Sender MAC: target:mac:address:here

  Sender IP: target.ip.goes.here

  Target MAC: interface:mac:address:here

  Target IP: interface.ip.goes.here

  现在我们有了 DNS 服务器或者默认网关的 IP 地址，我们可以继续 DNS 请求了：

  当浏览器得到了目标服务器的 IP 地址，以及 URL 中给出来端口号（http 协议默认端口号是 80，https 默认端口号是 443）js网页计数器，它会调用系统库函数 socket ，请求一个 TCP流套接字，对应的参数是 AF_INET/AF_INET6 和 SOCK_STREAM 。

  到了现在，TCP 封包已经准备好了，可以进行tcp三次握手（在地址解析完毕后首先进行的是三次握手，就是客户端和服务器端只发送SYN包，建立三次连接后，在对HTTP的引用进行响应）

  最终封包会到达管理本地子网的路由器。在那里出发，它会继续经过自治区域(autonomous system, 缩写 AS)的边界路由器，其他自治区域，最终到达目标服务器。一路上经过的这些路由器会从IP数据报头部里提取出目标地址，并将封包正确地路由到下一个目的地。IP数据报头部 time to live (TTL) 域的值每经过一个路由器就减1，如果封包的TTL变为0，或者路由器由于网络拥堵等原因封包队列满了，那么这个包会被路由器丢弃。

  8. TLS 握手9. HTTP 服务器请求处理

  HTTPD(HTTP Daemon)在服务器端处理请求/响应。最常见的 HTTPD 有 Linux 上常用的 Apache 和 nginx，以及 Windows 上的 IIS。

  服务器验证其上已经配置了 google.com 的虚拟主机

  服务器验证 google.com 接受 GET 方法

  服务器验证该用户可以使用 GET 方法(根据 IP 地址，身份信息等)

  如果服务器安装了 URL 重写模块（例如 Apache 的 mod_rewrite 和 IIS 的 URL Rewrite），服务器会尝试匹配重写规则，如果匹配上的话，服务器会按照规则重写这个请求

  服务器根据请求信息获取相应的响应内容，这种情况下由于访问路径是 “/“ ,会访问首页文件（你可以重写这个规则，但是这个是最常用的）。

  服务器会使用指定的处理程序分析处理这个文件，假如 Google 使用 PHP，服务器会使用 PHP 解析 index 文件，并捕获输出，把 PHP 的输出结果返回给请求者

  请求进入处理函数之后，如果客户端所请求需要浏览的内容是一个动态的内容，那么处理函数会相应的从数据源里面取出数据，这个地方一般会有一个缓存，例如 memcached 来减小 db 的压力，如果引入了 orm 框架的话，那么处理函数直接向 orm 框架索要数据就可以了，由 orm 框架来决定是使用内存里面的缓存还是从 db 去取数据，一般缓存都会有一个过期的时间，而 orm 框架也会在取到数据回来之后，把数据存一份在内存缓存中的。

  orm 框架负责把面向对象的请求翻译成标准的 sql 语句，然后送到后端的 db 去执行，db 这里以 mysql 为例的话，那么一条 sql 进来之后，db 本身也是有缓存的，不过 db 的缓存一般是用 sql 语言 hash 来存取的，也就是说，想要缓存能够命中，除了查询的字段和方法要一样以外，查询的参数也要完全一模一样才能够使用 db 本身的查询缓存，sql 经过查询缓存器，然后就会到达查询分析器，在这里，db 会根据被搜索的数据表的索引建立情况，和 sql 语言本身的特点，来决定使用哪一个字段的索引，值得一提的是，即使一个数据表同时在多个字段建立了索引，但是对于一条 sql 语句来说，还是只能使用一个索引，所以这里就需要分析使用哪个索引效率最高了，一般来说，sql 优化在这个点上也是很重要的一个方面。

  sql 由 db 返回结果集后，再由 orm 框架把结果转换成模型对象，然后由 orm 框架进行一些逻辑处理，把准备好的数据，送到视图层的渲染引擎去渲染，渲染引擎负责模板的管理，字段的友好显示，也包括负责一些多国语言之类的任务。对于一条请求在 mvc 中的生命周期，在视图层把页面准备好后，再从动态脚本解释器送回到 http 服务器，由 http 服务器把这些正文加上一个响应头，封装成一个标准的 http 响应包，再通过 tcp ip 协议，送回到客户机浏览器。

  10. 客户端渲染