一次完整的网络通信

一、在浏览器中输入www.baidu.com

这意味着浏览器要向百度发送一个网页数据包，要发送数据包，须要知道对方的IP地址，这里咱们只知道网址为www.baidu.com,殊不知道IP地址，此时应用层协议DNS协议会帮咱们把网址解析为IP地址，此时会发送一个DNS数据包给DNS服务器，DNS服务器再作出响应来告诉咱们百度的IP地址为220.181.111.147，这样咱们就知道百度（咱们须要通讯的主机）的IP地址。

DNS查找过程以下：（参考来源：DNS域名解析过程）

第1步，浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，若是缓存中有，这个解析过程就将结束。浏览器缓存域名也是有限制的，不只浏览器缓存大小有限制，并且缓存的时间也有限制，一般状况下为几分钟到几小时不等，域名被缓存的时间限制能够经过TTL属性来设置。这个缓存时间太长和过短都很差，若是缓存时间太长，一旦域名被解析到的IP有变化，会致使被客户端缓存的域名没法解析到变化后的IP地址，以至该域名不能正常解析，这段时间内有可能会有一部分用户没法访问网站。若是时间设置过短，会致使用户每次访问网站都要从新解析一次域名。

第2步，若是用户的浏览器缓存中没有，浏览器会查找操做系统缓存中是否有这个域名对应的DNS解析结果。其实操做系统也会有一个域名解析的过程，在Windows中能够经过C:WindowsSystem32driversetchosts文件来设置，你能够将任何域名解析到任何可以访问的IP地址。若是你在这里指定了一个域名对应的IP地址，那么浏览器会首先使用这个IP地址。例如，咱们在测试时能够将一个域名解析到一台测试服务器上，这样不用修改任何代码就能测试到单独服务器上的代码的业务逻辑是否正确。正是由于有这种本地DNS解析的规程，因此黑客就有可能经过修改你的域名解析来把特定的域名解析到它指定的IP地址上，致使这些域名被劫持。Windows 7中将hosts文件设置成了只读的，防止这个文件被轻易修改。

前面这两个步骤都是在本机完成的。到这里尚未涉及真正的域名解析服务器，若是在本机中仍然没法完成域名的解析，就会真正请求域名服务器来解析这个域名了。

第3步，如何、怎么知道域名服务器呢？在咱们的网络配置中都会有"DNS服务器地址"这一项，这个地址就用于解决前面所说的若是两个过程没法解析时要怎么办，操做系统会把这个域名发送给这里设置的LDNS，也就是本地区的域名服务器。这个DNS一般都提供给你本地互联网接入的一个DNS解析服务，例如你是在学校接入互联网，那么你的DNS服务器确定在你的学校，若是你是在一个小区接入互联网的，那这个DNS就是提供给你接入互联网的应用提供商，即电信或者联通，也就是一般所说的SPA，那么这个DNS一般也会在你所在城市的某个角落，一般不会很远。这个专门的域名解析服务器性能都会很好，它们通常都会缓存域名解析结果，固然缓存时间是受域名的失效时间控制的，通常缓存空间不是影响域名失效的主要因素。大约80%的域名解析都到这里就已经完成了，因此LDNS主要承担了域名的解析工做。

第4步，若是LDNS仍然没有命中，就直接到Root Server域名服务器请求解析。

第5步，根域名服务器返回给本地域名服务器一个所查询域的主域名服务器（gTLD Server）地址。gTLD是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右。

第6步，本地域名服务器（Local DNS Server）再向上一步返回的gTLD服务器发送请求。

第7步，接受请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server一般就是你注册的域名服务器，例如你在某个域名服务提供商申请的域名，那么这个域名解析任务就由这个域名提供商的服务器来完成。

第8步，Name Server域名服务器会查询存储的域名和IP的映射关系表，正常状况下都根据域名获得目标IP记录，连同一个TTL值返回给DNS Server域名服务器。

第9步，返回该域名对应的IP和TTL值，Local DNS Server会缓存这个域名和IP的对应关系，缓存的时间由TTL值控制。

第10步，把解析的结果返回给用户，用户根据TTL值缓存在本地系统缓存中，域名解析过程结束。

在实际的DNS解析过程当中，可能还不止这10个步骤，如Name Server也可能有多级，或者有一个GTM来负载均衡控制，这都有可能会影响域名解析的过程。

二、应用层：
浏览网页采用的是HTTP 协议，HTTP数据包会嵌入在TCP数据包中，此时咱们发送的HTTP数据包内容为：

[plain] view plain copy
GET http://www.baidu.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; Zune 4.7; InfoPath.3; MS-RTC LM 8)
Accept-Encoding: gzip, deflate, peerdist
Proxy-Connection: Keep-Alive
Host: www.baidu.com
Cookie: BDSFRCVID=H1K_JgC2l434o0a3SlYrhIyDwFLxPM7C3J; H_BDCLCKID_SF=tJAt_C8htDv5HTuRj63D5JcH-UnLqMkDWaOZ0h8-aI-5MbAx-jb6hhFXM-r80nblBTbT2C3nthF0HPonHj8Bej5L3J; BAIDUID=C0E879D1A40237E70E9FA559D40EE0AC:FG=1; BDUT=w5n3C0E879D1A40237E70E9FA559D40EE0AC13914a661370; BDUSS=FEQVdNdjllMTYyYlRxY3ZZbW1hM2htemdqZFVJcWRLWmFBaEtqd1FoTDNXeE5SQUFBQUFBJCQAAAAAAAAAAAoqyysAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADEwLjI2LjE5Ny43NwAAAADAxFInAAAAAPcNJlD3DSZQYV; BDRCVFR[eYjbPwSqvSs]=2g3v5sBI-NCpv4EILPoXi4WUvY; Hm_lvt_9f14aaa038bbba8b12ec2a4a3e51d254=1344671219756; Hm_lpvt_9f14aaa038bbba8b12ec2a4a3e51d254=1344671219756
X-P2P-PeerDist: Version=1.0
用来看原始HTTP请求及其响应的工具不少。比较喜欢使用fiddler，固然也有像FireBug这样其余的工具。这些软件在网站优化时会帮上很大忙。

三、传输层：
TCP数据包须要设置端口，接收方（百度）的Http端口默认是80，本机的端口是一个1024-65535之间的随机整数，这里假设为1025，这样TCP数据包由标头（标识着发方和接收方的端口信息）+HTTP数据包，这样TCP数据包再嵌入IP数据包中在网络上传送

四、网络层：
IP数据包须要知道双方的IP地址，本机IP地址假定为192.168.1.5，接受方IP地址为220.181.111.147（百度），这样IP数据包由头部（IP地址信息）+TCP数据包，

五、数据链路层：
IP数据包嵌入到数据帧（以太网数据包）中，以太网数据包须要知道双方的MAC（物理地址），发送方为本机的网卡地址，接受方为网关192.168.1.1的MAC地址（经过ARP地址解析协议获得的）。这样数据帧由头部（MAC地址）+IP数据包组成。

ARP地址解析协议工做过程：
主机A的IP地址为192.168.1.1，MAC地址为0A-11-22-33-44-01；

主机B的IP地址为192.168.1.2，MAC地址为0A-11-22-33-44-02；

当主机A要与主机B通讯时，地址解析协议能够将主机B的IP地址（192.168.1.2）解析成主机B的MAC地址，如下为工做流程：

第1步：根据主机A上的路由表内容，IP肯定用于访问主机B的转发IP地址是192.168.1.2。而后A主机在本身的本地ARP缓存中检查主机B的匹配MAC地址。
第2步：若是主机A在ARP缓存中没有找到映射，它将询问192.168.1.2的硬件地址，从而将ARP请求帧广播到本地网络上的全部主机。源主机A的IP地址和MAC地址都包括在ARP请求中。本地网络上的每台主机都接收到ARP请求而且检查是否与本身的IP地址匹配。若是主机发现请求的IP地址与本身的IP地址不匹配，它将丢弃ARP请求。
第3步：主机B肯定ARP请求中的IP地址与本身的IP地址匹配，则将主机A的IP地址和MAC地址映射添加到本地ARP缓存中。
第4步：主机B将包含其MAC地址的ARP回复消息直接发送回主机A。
第5步：当主机A收到从主机B发来的ARP回复消息时，会用主机B的IP和MAC地址映射更新ARP缓存。本机缓存是有生存期的，生存期结束后，将再次重复上面的过程。主机B的MAC地址一旦肯定，主机A就能向主机B发送IP通讯了。

六、服务器处理请求

通过多个网关的转发到百度服务器220.181.111.147，中间经过各级物理层找到终端服务器IP，并请求对应端口服务，服务接收到发送过来的以太网数包据开始解析请求信息，从以太网数据包中提取IP数据包——>TCP数据包——>HTTP数据包，并组装为有效数据交与对应线程池中分配的线程进行处理，在这个过程当中，生成相应request、response对象。

处理完毕后，将数据经过response对象内部的out给客户输出信息，输出信息也须要拼接HTTP协议头部分，标志out关闭后为断开链接（注意动态内容已经在服务器端被翻译为静态内容，到客户端所有是静态内容，JS动态组装不算），断开后，服务器端自动注销request、response对象，并将释放对应线程的使用标识（通常一个请求单独由一个线程处理，部分特殊状况有一个线程处理多个请求的状况）

七、服务器发回一个HTML响应

服务器生成并返回的响应：

[plain] view plain copy
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
整个响应大小为35kB，其中大部分在整理后以blob类型传输。
内容编码头告诉浏览器整个响应体用gzip算法进行压缩。解压blob块后，你能够看到以下指望的HTML：

[plain] view plain copy
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
关于压缩，头信息说明了是否缓存这个页面，若是缓存的话如何去作，有什么cookies要去设置（前面这个响应里没有这点）和隐私信息等等。
请注意报头中把Content-type设置为“text/html”。报头让浏览器将该响应内容以HTML形式呈现，而不是以文件形式下载它。浏览器会根据报头信息决定如何解释该响应，不过同时也会考虑像URL扩展内容等其余因素。

八、浏览器开始显示HTML

客户端接收到返回数据，去掉对应头信息，造成也能够被浏览器认识的页面HTML字符串信息，交与浏览器翻译为对应页面规则信息展现为界面内容。浏览器一样的过程读取到HTTP响应的内容（HTTP响应数据包），而后浏览器对接受到的HTML页面进行解析，把网页显示出来呈现给用户。

九、浏览器发送获取嵌入在HTML中的对象

在浏览器显示HTML时，它会注意到须要获取其余地址内容的标签。这时，浏览器会发送一个获取请求来从新得到这些文件。
下面是几个咱们访问facebook.com时须要重获取的几个URL：

图片
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
CSS 式样表
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
JavaScript 文件
http://static.ak.fbcdn.net/rs...
http://static.ak.fbcdn.net/rs...
…
这些地址都要经历一个和HTML读取相似的过程。因此浏览器会在DNS中查找这些域名，发送请求，重定向等等...
但不像动态页面那样，静态文件会容许浏览器对其进行缓存。有的文件可能会不须要与服务器通信，而从缓存中直接读取。服务器的响应中包含了静态文件保存的期限 信息，因此浏览器知道要把它们缓存多长时间。还有，每一个响应均可能包含像版本号同样工做的ETag头（被请求变量的实体值），若是浏览器观察到文件的版本 ETag信息已经存在，就立刻中止这个文件的传输。
试着猜猜看“fbcdn.net”在地址中表明什么？聪明的答案是"Facebook内容分发网络"。Facebook利用内容分发网络（CDN）分发像图片，CSS表和JavaScript文件这些静态文件。因此，这些文件会在全球不少CDN的数据中心中留下备份。
静态内容每每表明站点的带宽大小，也能经过CDN轻松的复制。一般网站会使用第三方的CDN。例如，Facebook的静态文件由最大的CDN提供商Akamai来托管。
举例来说，当你试着ping static.ak.fbcdn.net的时候，可能会从某个akamai.net服务器上得到响应。有意思的是，当你一样再ping一次的时候，响应的服务器可能就不同，这说明幕后的负载平衡开始起做用了。

1. 浏览器发送异步（AJAX）请求

在Web 2.0伟大精神的指引下，页面显示完成后客户端仍与服务器端保持着联系。
以 Facebook聊天功能为例，它会持续与服务器保持联系来及时更新你那些亮亮灰灰的好友状态。为了更新这些头像亮着的好友状态，在浏览器中执行的 JavaScript代码会给服务器发送异步请求。这个异步请求发送给特定的地址，它是一个按照程式构造的获取或发送请求。仍是在Facebook这个例 子中，客户端发送给http://www.facebook.com/ajax/... 在线的状态信息。

提起这个模式，就必需要讲讲"AJAX"-- “异步JavaScript 和 XML”，虽然服务器为何用XML格式来进行响应也没有个一清二白的缘由。再举个例子吧，对于异步请求，Facebook会返回一些JavaScript的代码片断。除了其余，fiddler这个工具可以让你看到浏览器发送的异步请求。事实上，你不只能够被动的作为这些请求的看客，还能主动出击修改和从新发送它们。AJAX请求这么容易被蒙，可着实让那些计分的在线游戏开发者们郁闷的了。（固然，可别那样骗人家~）Facebook聊天功能提供了关于AJAX一个有意思的问题案例：把数据从服务器端推送到客户端。由于HTTP是一个请求-响应协议，因此聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看本身有没有新消息。这些状况发生时长轮询是个减轻服务器负载挺有趣的技术。若是当被轮询时服务器没有新消息，它就不理这个客户端。而当还没有超时的状况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息作为响应返回给客户端。