一条URL触发的流量

1、一条url触发的流量一条url触发的流量-用科来验证 我们在ie扫瞄器中输入一条url，就能扫瞄到我们需要的网页，可是大家有没有想过，在ie中的一个回车，毕竟产生了哪些流量，这些流量中都有哪些数据包，这些数据包又产生了什么样的效果呢？ 接下来我们通过科来公司的科来网络分析系统对囫囵http的拜访流程举行具体的分析。 本次我们拜访，在扫瞄器中回车之前，我们先要把科来网络分析系统打开，如下图： 650) this.wth=650;" border="0" alt="" src="/uploads/allimg/111111/21594m5

2、20-0.png" /> 用法前界面的设置，不在介绍，csna的结果吧。 数据包视图下： 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594im4-1.png" /> 上图很清楚，第一个包并不是dns哀求的数据包，而是一个arp的哀求数据包。为什么会这样呢，莫非我们之前的分析有问题么？ 其实我们只考虑了ip层面的信息，也就是三层上的，而数据包在传送的时候是要经过二层交换机的，而这种二层设备是无法识别三层的ip

3、信息的，识别的只能是二层的mac。认识osi7层模型的伴侣都会知道，数据在传输的时候是要一层一层的封装的。那这些数据包是如何举行封转的呢，那我们必需先了解几个参数：源ip、目的ip、源mac、目的mac。其中源ip、源mac很清晰就是本机的ip、本机的mac，那目的ip、目的mac又都是什么呢？ 先看这个dns哀求包吧，两个参数：目的ip、目的mac。 首先看一下我们的本地网卡设置： 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594ib6

4、-2.png" /> 目的ip为上图中的设置的dns服务器ip:0,那目的mac是什么呢? 莫非是远端dns服务器的mac么? 答案绝对不是,大家应当注重到了上面有个默认网关,为.这个网关做什么呢,详细用处大家可以百度下,也许就是非本地网段的通信由网关来转发,所以此dns的目的mac为网关的mac. 那网关的mac是如何猎取的呢?这就需要尽人皆知的arp了,通过查询arp来猎取网关的mac.而这个查询也需要两种方式,依次为:本地arp缓存、发送arp哀求。同样我在抓包之前已经在本机举行了 arp d 操作，也就是清除本地arp缓存。

5、猎取arp信息，也就只能通过发送arp哀求来实现了，也就有了囫囵操作的第一个数据包的发出。 那我们就打开第一个数据包，看一下这个数据包的具体解码。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594i015-3.png" /> 中文解码每一个字段，看起来相对还是比较易理解的。在以太网头部中，目的mac为ff：ff：ff：ff：ff：ff，也就是广播；源mac为本机mac， 00:21:70:e9:ab:ac；协议类型为0x0

6、806，代表arp。因为这个arp哀求的目的mac为广播，大家可以思量一下，这样一个数据包发到网络中对交换机,影响。（这个真的可以考虑一下，研究一下） 在arp包头中，协议类型为0x0800也就意味着解析的是ip地址，哀求的详细是哪个ip可以在目标ip地址这个字段看到：，在哀求包中目标物理地址也就是目标mac为00:00:00:00:00:00，也就意味着是空的。而在源ip地址、源物理地址中，则依次填写了本机的ip、mac。大家考虑一下，这样一个数据包发送到网络中对网关以及本网段其他主机的影响。（这个同样必需考虑一下，研究一下） 上面介绍的是arp哀求包，下面我们来介绍

7、一下网关对此arp的应答信息，也就是arp响应。 其次个数据包，arp应答包。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594m5e-4.png" /> 首先对照一下以太网字段中的信息与上一个数据包的区分，之前的源地址成了现在的目标地址，00:21:70:e9:ab:ac；而源地址成了00:17:16:02:ac:2c，也就是网关的mac，协议类型仍然是0x0806. 而在arp包头中，源ip为，

8、源mac为网关mac；目标ip、mac分离为本机的ip、mac。 总结一下，arp哀求是广播发出，应答是单播发出。那本机在收到这样一个数据包后，会如何操作呢，我们可以举行如下操作： 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594kw3-5.png" /> arp缓存中增强了一个条目，也就是有了网关对应的mac地址。在胜利获得arp应答后，本机有了网关的mac。到此为止dns哀求的源目ip、源目mac都已经有了，东风已到，

9、可以发送dns哀求了。大家思量一下，假如此时猎取了一个错误的arp应答，会造成什么样的后果呢？ 第三个包，dns哀求。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594lr8-6.png" /> 果真在这个数据包中， 前两个数据包猎取的信息已经被启用了，目的mac确实为网关的mac。关于ip、udp、dns包头，内容太多，不再具体说明了，感爱好可以看一下tcp/ip详解卷一。ip包头中源ip为本机ip、目的ip为dns服务

10、器ip；dns包头中查咨询题中域名字段为：，这也就是咱们要拜访的域名。 第四个数据包，dns应答。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594i633-7.png" /> 这个数据包我们看一下dns头部中的答案即可，解析的ip地址为69。固然这个答案为多个，用于拜访sohu的备份ip。假如在这个过程中浮现问题的后果，大家可以回想一下2010年无法拜访百度那件事故就明了了。 其实像这种arp、d

11、ns哀求应答信息，没须要去看具体的数据包解码，只要在数据包视图下，查看概要即可，如下图： 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594j241-8.png" /> 在上图中概要一栏，以及很清楚的看到相关信息了。 要拜访域名的ip以及有了，就可以举行http的应用哀求了，而http是跑在tcp层之上的。尽人皆知tcp是面对衔接的传输协议，也就意味着要举行三次握手，举行tcp建立衔接。操作系统对http举行解析，了解到ht

12、tp用法了tcp的80端口，所以在发起tcp衔接的时候，目标端口为80. 第五个包，tcp三次握手第一个包，syn发送。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594io8-9.png" /> tcp头部比ip、udp头部更复杂，只挑选几个重点的说一下吧。源端口为本地随机的端口，目标端口为80，用于http。初始序列号8389539为随机的，确认号为0，标记为000010即同步位置1。tcp选项中的最大段长为1460，

13、这个跟mtu有关，需要在tcp握手期间举行商议。 第六个包，tcp三次握手其次个包，syn ack。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594ht3-10.png" /> 源端口为80，目标端口为61706；序列号为2272548105，确认号为8389540，注重这个确认号与上一个包的序列号之间的关系，考虑一下。 标记位010010，syn、ack都置1，是对syn包确实认包。tcp选项中最大段长为1452，而在

14、上一个数据包中为1460，这样会话两端则会商议到一个结果，最大段长为1452，取最小值。以后发送tcp数据时，tcp承载的数据大小则不会超过1452. 第七个包，tcp三次握手第三个包，ack包。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594jj7-11.png" /> 可以看到这个数据包已经没有tcp选项字段，在接下来的数据包中也不会存在tcp选项字段了。这个数据包仍为本地主机发出，源ip为0

15、7。tcp源端口为61706，与tcp第一个包的源端口是一样的，目标仍为80.所以说，在一个tcp会话中源目端口是不会变幻的。序列号为8389540，与第一次发出tcp syn包增强了1；确认号为由之前的0变为2272548106，关于这个2272548106与服务器端发出的syn ack中序列号（2272548105）的关系，思量一下。标记位为010000，只要ack位置1. 至此为止tcp的三次握手已经完成，接下来可以举行http的哀求了。 同样tcp握手这三个数据包，我们也没须要去看具体的解码信息。可以在tcp会话视图中，查看如下图： 650) this.width=650;"

16、 border="0" alt="" src="/uploads/allimg/111111/21594gl3-12.png" /> 在这个时序图中，我们可以清楚的看到这个tcp会话的源目ip、源目tcp端口，序列号的变幻，标记位的置位状况。 其实在tcp会话分析中一个最重要的参数我们没有提到，那就是时光。这次我们是介绍网络操作的变幻，不涉及太多时光，但我们仍然要说一下。 在tcp会话视图中，双击第一个tcp会话，则打开tcp流分析界面。如下图： 650) this.width=650;" border="0

17、" alt="" src="/uploads/allimg/111111/21594kj2-13.png" /> 在上图的左下角部分，是一个tcp的时序图，包括了相对时光和时光差，通过这个时光差我们可以计算网络的rtt值（来回时光），进而来评估网络层面的延时状况。在本次会话中，网络层面的延时为0.022741s，此延时基本可以容忍。 继续介绍本机在完成三次握手之后，接下来的操作。 第八个数据包，http的get哀求。 650) this.width=650;" border="0" alt="&qu

18、ot; src="/uploads/allimg/111111/21594gx1-14.png" /> 如上图，http的数据是在tcp包头的里面，也就是http是由tcp来承载的，看一下http字段。哀求为get，host主机部分为 也就是咱们要拜访的界面。 第九个数据包，http get的ack。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594h035-15.png" /> 这个数据包内容很

19、容易，只是一个ack置1的包。用于对http get在tcp层面确实认，也就是每个tcp数据发出后，对端需要举行确认，体现了tcp传输的牢靠性。同样注重一下这个包确实认号与第7个数据包中确实认号的差额。 第十个包，http 的响应包。 650) this.width=650;" border="0" alt="" src="/uploads/allimg/111111/21594m093-16.png" /> 这个数据包是服务器对http get在应用层的响应，可以看一下字段中有一个200 0k字样，这个代表服务器对客户端发出的哀求能举行正常服务。 接下来，就是服务器对客户端哀求的页面举行回馈了，可以看到后面的数据主要为服务器端发送