案例-一条URL触发的流量.docxVIP

一条URL触发的流量我们在IE浏览器中输入一条URL，就能浏览到我们需要的网页，可是大家有没有想过，在IE中的一个回车，究竟产生了哪些流量，这些流量中都有哪些数据包，这些数据包又产生了什么样的效果呢？接下来我们通过科来公司的科来网络分析系统对整个http的访问流程进行详细的分析。 本次我们访问，在浏览器中回车之前，我们先要把科来网络分析系统打开，如下图：使用前界面的设置，不在介绍，CSNA论坛上有大量的使用介绍。我们先想一下, 这是一个域名,而数据在互联网上传输的时候是以IP进行传输的,而通过域名是无法访问到最终的服务器的.所以在输入url后,系统的第一个操作会是DNS的解析,也就是通过域名来翻译出目的IP.而这个翻译过程,大致分为三种途径，依次为:DNS缓存、host文件、DNS请求。在进行这个测试之前，本机已经做了C:\Users\chenipconfig /flushdns 操作，所以DNS缓冲是不存在的。而host文件是默认的，里面肯定是没有关于相关的条目的。综上分析，域名向IP的解析，则只能通过DNS请求来获取的，也就是获取sohu服务器的IP。所以发出的第一个数据包应该是DNS请求包。那事实是这样么？那我们还是看一下科来网络分析系统抓包的结果吧。数据包视图下：上图很清晰，第一个包并不是DNS请求的数据包，而是一个ARP的请求数据包。为什么会这样呢，难道我们之前的分析有问题么？其实我们只考虑了IP层面的信息，也就是三层上的，而数据包在传送的时候是要经过二层交换机的，而这种二层设备是无法识别三层的IP信息的，识别的只能是二层的MAC。熟悉OSI7层模型的朋友都会知道，数据在传输的时候是要一层一层的封装的。那这些数据包是如何进行封转的呢，那我们必须先了解几个参数：源IP、目的IP、源MAC、目的MAC。其中源IP、源MAC很清楚就是本机的IP、本机的MAC，那目的IP、目的MAC又都是什么呢？先看这个DNS请求包吧，两个参数：目的IP、目的MAC。首先看一下我们的本地网卡设置：目的IP为上图中的设置的DNS服务器IP:0,那目的MAC是什么呢? 难道是远端DNS服务器的MAC么?答案肯定不是,大家应该注意到了上面有个默认网关,为.这个网关做什么呢,具体用处大家可以百度下,大概就是非本地网段的通信由网关来转发,所以此DNS的目的MAC为网关的MAC.那网关的MAC是如何获取的呢?这就需要众所周知的ARP了,通过查询ARP来获取网关的MAC.而这个查询也需要两种方式,依次为:本地ARP缓存、发送ARP请求。同样我在抓包之前已经在本机进行了 arp –d 操作，也就是清除本地ARP缓存。获取ARP信息，也就只能通过发送ARP请求来实现了，也就有了整个操作的第一个数据包的发出。那我们就打开第一个数据包，看一下这个数据包的详细解码。中文解码每一个字段，看起来相对还是比较易理解的。在以太网头部中，目的MAC为FF：FF：FF：FF：FF：FF，也就是广播；源MAC为本机MAC， 00:21:70:E9:AB:AC；协议类型为0x0806，代表ARP。由于这个ARP请求的目的MAC为广播，大家可以思考一下，这样一个数据包发到网络中对交换机,影响。（这个真的可以考虑一下，讨论一下）在ARP包头中，协议类型为0x0800也就意味着解析的是IP地址，请求的具体是哪个IP可以在目标IP地址这个字段看到：，在请求包中目标物理地址也就是目标MAC为00:00:00:00:00:00，也就意味着是空的。而在源IP地址、源物理地址中，则依次填写了本机的IP、MAC。大家考虑一下，这样一个数据包发送到网络中对网关以及本网段其他主机的影响。（这个同样必须考虑一下，讨论一下）上面介绍的是ARP请求包，下面我们来介绍一下网关对此ARP的应答信息，也就是ARP响应。第二个数据包，ARP应答包。首先对比一下以太网字段中的信息与上一个数据包的区别，之前的源地址成了现在的目标地址，00:21:70:E9:AB:AC；而源地址成了00:17:16:02:AC:2C，也就是网关的MAC，协议类型仍然是0x0806.而在ARP包头中，源IP为，源MAC为网关MAC；目标IP、MAC分别为本机的IP、MAC。总结一下，ARP请求是广播发出，应答是单播发出。那本机在收到这样一个数据包后，会如何操作呢，我们可以进行如下操作：Arp缓存中增加了一个条目，也就是有了网关对应的MAC地址。在成功获得ARP应答后，本机有了网关的MAC。到此为止DNS请求的源目IP、源目MAC都已经有了，东风已到，可以发送DNS请求了。大家思考一下，如果此时获取了一个错误的ARP应答，会造成什么样的后果呢？第三个包，DNS请求。果然在这个数据包中， 前两个数据包获取的信息已经被启用了，目的MAC的确为