书接上文，据说某年某月的某一天，一台机房里普通服务器，开了机，启动了操作系统，随着操作系统的就绪，服务器启动了 http 服务进程，这个 http 服务的守护进程，（daemon），可能是 apache，也可能是 nginx，不管怎么说，这个 http 服务进程开始定位到服务器上的 www 文件夹，一般是位于 /var/www ，然后启动了一些附属的模块，例如 php_mod，或者，使用 fastcgi 方式连接到 php 的 fpm 管理进程，然后，向操作系统申请了一个 tcp 连接，然后绑定在了 80 端口，调用了 accept 函数，开始了默默的监听，监听着可能来自位于地球任何一个地方的请求，随时准备做出响应。
详解一次HTTP请求の客户端
断点1: 客户端域名的解析过程
当用户在浏览器中输入www.baidu.com的时候，域名解析的过程会经过以下过程：（细节详情可参见https://zhidao.baidu.com/question/437513187.html，难得《百度知道》还能有这么正经点的答案，呕吼吼吼~~~）
第1步，浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就将结束。浏览器缓存域名也是有大小和时间（TTL）限制的。
第2步，如果用户的浏览器缓存中没有，浏览器会查找操作系统缓存中是否有这个域名对应的DNS解析结果。比如在Windows中可以通过C:\Windows\System32\drivers\etc\hosts文件，如果在这里指定了一个域名对应的IP地址，那么浏览器会首先使用这个IP地址（不加任何判断），解析过程也就将结束。正是因为有这种本地DNS解析的规程，所以黑客或病毒就有可能通过修改你的域名解析来把特定的域名解析到它指定的IP地址上，导致这些域名被劫持。
前面这两个步骤都是在本机完成的，还没有涉及真正的域名解析服务器（DNS），如果在本机中仍然无法完成域名的解析，浏览器就会向域名服务器发起域名解析请求了。
第3步，如何、怎么知道域名服务器呢？在我们的网络配置中都会有"DNS服务器地址"这一项，据说Windows下，ipconfig即可查看，如下截图(反正我是没看到～～)。操作系统会把这个域名发送给这里设置的LDNS，也就是本地区的域名服务器。这个专门的域名解析服务器会缓存域名解析结果，当然缓存时间是受域名的失效时间控制的，大约80%的域名解析都到这里就已经完成了，所以LDNS主要承担了域名的解析工作。
如果LDNS仍然没有命中，就直接到Root Server域名服务器请求解析。。。。。。。（具体细节过程，改日再叙，这个不是重点。）
总之，dns的域名解析是递归的（dns是迭代的），如果找不到对应域名的ip地址，就向上转发请求，然后把得到的这个域名对应的 nameserver 的地址取得，再向这个 namserver 去请求域名对应的 ip，最后把这个 ip 地址返回给浏览器（坐等收菜即可~~~），浏览器根据TTL值缓存在本地系统中，域名解析过程结束。
<(￣︶￣)↗[GO!]
得到服务器的ip地址后，浏览器开始构造http请求，一个典型的http request header一般需要需要包括请求的方法（共7种），例如 GET 或者 POST 等，不常用的还有 PUT 和 DELETE 方法，更加不常用的还有 HEAD 和 OPTION 以及 TRACE 方法，一般的浏览器只能发起 GET 或者 POST 请求。。。。。。好，暂停存档。
断点2: HTTP的请求格式
虽然计算机网络的基础知识有，但既然是考究过程，那不妨回忆且扫盲下http请求的典型组成结构吧。谁让我们身处网络时代，大神又如此之多呢，详细参解可查看这篇文章，http://blog.csdn.net/u012125579/article/details/47426737，大神写的形式暂可达到扫盲的要求，我也就是看过，并未经己手，终究还是“纸上得来终觉浅”，此事须躬行，举个荔枝～~
客户端通过发送HTTP请求向服务器请求对资源的访问，HTTP请求有三部分组成：请求行、消息头和消息体：
＜request-line＞
＜headers＞
＜blank line＞
[＜request-body＞
请求行（Request Line）
请求行有三个标记组成：请求方法 请求URL 协议／版本，以空格分隔，比如上图中的：GET ／ HTTP／1.1
HTTP1.1支持的请求方法有7种：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。在Internet应用中，最常用的方法是GET和POST，这里稍后简单介绍下：GET、POST和HEAD方法。
URL完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最后，协议版本声明了通信过程中使用HTTP的版本。
1）GET
GET方法用于获取由 Request-URI 所标识的资源的信息，是默认的HTTP请求方法，例如当我们通过在浏览器的地址栏中直接输入网址的方式去访问网页的时候，浏览器采用的就是 GET 方法向服务器获取资源。
GET以URL方式提交数据（比如参数和表单数据），只经过了简单的编码就它将作为URL的一部分向服务器发送请求，例如：http://localhost/login.php?username=aa&password=1234， 因此在安全性和url长度上都会有所限制。
（2）POST
POST方法请求服务器接收在请求中封装的实体，并将其作为由 Request-Line 中的 Request-URI 所标识的资源的一部分，即POST方法将数据封装在消息主体（entity-body），相对于GET方法而言，可接受大批量数据且消息体中的数据并无编码要求。
就解释脚本而言，GET方法的数据会存放在QUERY＿STRING环境变量中，可使用$_GET获取，而POST方法提交的数据则可以从标准输入流中获取，可使用$_POST获取。
（3）HEAD
HEAD 方法与 GET 方法几乎是相同的，它们的区别在于 HEAD 方法请求的话，服务器返回的只是响应标题，而不是完整的内容。对于 HEAD 请求的回应部分来说，它的 HTTP 头部中包含的信息与通过 GET 请求所得到的信息是相同的；通常被用于测试超链接的有效性，是否可以访问，以及最近是否更新。
消息头（Message Headers）
由域名/值对组成，每行一对，域名和值之间用紧跟的英文冒号（“:”），单空格（SP）分开。消息头通知服务器关于客户端的功能和标识，如 Host: www.baidu.com 。在 HTTP/1.1 协议中，Host 消息头是必选的。还可以有其他一些如 Accept-Charset、Accept-Encoding、Authorization 、Set-Cookie等等，详见 RFC1945，RFC2616。
消息体（Entity Body）
HTTP 消息的消息体（如果存在），用于携带与请求相关联的数据，例如可以存一些请求需要的参数等。由消息头中的 Content-Length 或 Transfer-Encoding 来指示，比如 Content-Type 说明了数据的传输类型，Content-Length说明了请求主体的字节数。
一个完整的带消息体的 HTTP 请求示例如下：
POST /news.asp HTTP/1.1
Host: demo.com:80
Content-Length: 15
<空行，通知服务器以下不再有请求头>
[a=1,(b=2,c=3)]
Rollback 断点2
了解了HTTP请求的数据格式后，我们再次书接上文。
应用层的 http 请求准备好后，浏览器在传输层发起一条到达服务器的 tcp 连接，这个时候应该开始三次握手的过程（考究网络传输的报文发送细节，比如三次握手，路由转发，拥塞避免等等），tcp 包被封装到网络层的 ip 包里面，ip 包再被封装到数据链路层的数据帧结构中，再通过物理层的比特流送出去，这些分层的意义在于分工合作，数据链路层通过 CSMA/CD 协议保证了相邻两台主机之间的数据报文传递，而网络层的 ip 数据包通过不同子网之间的路由器的路由算法和路由转发，保证了互联网上两台遥远主机之间的点对点的通讯，不过这种传输是不可靠，于是可靠性就由传输层的 tcp 协议来保证，tcp 通过慢开始，乘法减小等手段来进行流量控制和拥塞避免，同时提供了两台遥远主机上进程到进程的通信，最终保证了 http 的请求头能够被远方的服务器上正在监听的 http 服务器进程收到，终于，数据包在跳与跳之间被拆了又封装，在子网与子网之间被转发了又转发，最后进入了服务器的操作系统的缓冲区，服务器的操作系统由此给正在被阻塞住的 accept 函数一个返回，将他唤醒。。。好，暂停存档。虽然不甚明了，但印象中一个服务器可配置多个站点域名，即一个IP绑定多个域名，比如租用的虚拟主机；而当为了负载均衡，一个域名是可对应到多个IP地址，这种多对多的映射关系是不是有点晕😷，是不是有点好奇服务器怎么调取执行的？既然是考究过程，我们也大致了解一下，不感冒的可自行跳过。
断点3: 服务器域名、IP以及站点间的关系
在IIS中,每个 Web 站点都由IP地址、主机头(HOST)和端口三部分组成且唯一标识（考究NGINX下的多站点配置）。
对于一些小规模的网站，为了减少系统的运行成本和管理难度，经常会与其他网站共享一台物理机器。这种虚拟主机有两种工作方式：1. 基于IP地址的虚拟主机方式：物理机器上同时设置有多个IP地址，不同的主机名host解析到不同的IP地址，进而判定哪个虚拟主机提供服务。这种方式需要在虚拟主机服务器上设立多个IP地址，既浪费IP又限制了一台机器所能容纳的虚拟主机数目。但是，这种方式却是早期使用的HTTP 1.0协议唯一支持的虚拟主机方式； 2. 基于主机名的虚拟主机方式：根据断点2对HTTP请求格式的解析，我们知道HTTP/1.1 协议中，Host 消息头是必选的。服务器http服务进程接收到HTTP请求后，会根据“Host:”语句判定客户程序请求是要由哪个虚拟主机的提供服务，这也是目前很常见的一种形式。
如果服务器端使用的http服务进程是Apache，那么在Apache的配置文件中加入VirtualHost即可新增虚拟主机，如下图示：
大体了解了一个IP绑定多个域名的运行方式后，我们来了解下一个域名对应到多个IP，比较典型的应该是“一个域名对应多个IP地址的负载均衡的实现”，也叫“DNS负载均衡技术”，详情可参见http://www.cnblogs.com/cuihongyu3503319/archive/2012/07/09/2583129.html。
DNS负载均衡技术(dns轮询，或者自己做解析)是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果（随机性），将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。
为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。
由于战线不易拉的过长，关于负载均衡的其他相关方法有时间再赘述吧。
个人思考：其原理倒是浅显易懂，正如上面所说，这种ＤＮＳ负载均衡技术，是在应答DNS查询时将客户端请求引导的不同的机器上（地址要随机分配）以达到负载均衡，那么：1. 根据文章最开始提到的“客户端域名的解析过程”，要想走到DNS查询，浏览器缓存的TTL要够合理吧（这或许是要将DNS刷新时间设置较小的原因？），host要没配置过吧~~~。。。 2. 这种简单的轮询负载算法，不同的服务器的性能差异及当前服务器的运行状态，如何有效的做到随机分配，DNS响应均衡也是个难点吧？
