|
|
刚写了篇基础文档，给大家共享一下，同时感谢本论坛中by笨笨 同学对本文提出的宝贵意见。
我们在IE浏览器中输入一条URL，就能浏览到我们需要的网页，可是大家有没有想过，在IE中的一个回车，究竟产生了哪些流量，这些流量中都有哪些数据包，这些数据包又产生了什么样的效果呢？接下来我们通过科来公司的科来网络分析系统对整个http的访问流程进行详细的分析。
本次我们访问www.sohu.com
，在浏览器中回车之前，我们先要把科来网络分析系统打开，如下图：
使用前界面的设置，不在介绍，CSNA论坛上有大量的使用介绍。
我们先想一下, www.sohu.com
这是一个域名,而数据在互联网上传输的时候是以IP进行传输的,而通过域名是无法访问到最终的服务器的.
所以在输入url后,系统的第一个操作会是DNS的解析,也就是通过域名来翻译出目的IP.
而这个翻译过程,大致分为三种途径，依次为 NS缓存、host文件、DNS请求。
在进行这个测试之前，本机已经做了C:\Users\chen>ipconfig /flushdns 操作，所以DNS缓冲是不存在的。而host文件是默认的，里面肯定是没有关于sina.com相关的条目的。综上分析，域名向IP的解析，则只能通过DNS请求来获取的，也就是获取sina服务器的IP。
所以发出的第一个数据包应该是DNS请求包。那事实是这样么？那我们还是看一下科来网络分析系统抓包的结果吧。
数据包视图下：
上图很清晰，第一个包并不是DNS请求的数据包，而是一个ARP的请求数据包。为什么会这样呢，难道我们之前的分析有问题么？
其实我们只考虑了IP层面的信息，也就是三层上的，而数据包在传送的时候是要经过二层交换机的，而这种二层设备是无法识别三层的IP信息的，识别的只能是二层的MAC。熟悉OSI7层模型的朋友都会知道，数据在传输的时候是要一层一层的封装的。那这些数据包是如何进行封转的呢，那我们必须先了解几个参数：源IP、目的IP、源MAC、目的MAC。其中源IP、源MAC很清楚就是本机的IP、本机的MAC，那目的IP、目的MAC又都是什么呢？
先看这个DNS请求包吧，两个参数：目的IP、目的MAC。
首先看一下我们的本地网卡设置：
目的IP为上图中的设置的DNS服务器IP:202.106.0.20,那目的MAC是什么呢? 难道是远端DNS服务器的MAC么?
答案肯定不是,大家应该注意到了上面有个默认网关,为192.168.10.1.这个网关做什么呢,具体用处大家可以百度下,大概就是非本地网段的通信由网关来转发,所以此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地址这个字段看到：192.168.10.1，在请求包中目标物理地址也就是目标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为192.168.10.1，源MAC为网关MAC；目标IP、MAC分别为本机的IP、MAC。
总结一下，ARP请求是广播发出，应答是单播发出。那本机在收到这样一个数据包后，会如何操作呢，我们可以进行如下操作：
Arp缓存中增加了一个条目，也就是有了网关对应的MAC地址。在成功获得ARP应答后，本机有了网关的MAC。到此为止DNS请求的源目IP、源目MAC都已经有了，东风已到，可以发送DNS请求了。大家思考一下，如果此时获取了一个错误的ARP应答，会造成什么样的后果呢？
第三个包，DNS请求。
果然在这个数据包中， 前两个数据包获取的信息已经被启用了，目的MAC的确为网关的MAC。关于IP、UDP、DNS包头，内容太多，不再详细解释了，感兴趣可以看一下TCP/IP详解卷一。IP包头中源IP为本机IP、目的IP为DNS服务器IP；DNS包头中查询问题中域名字段为：www.sohu.com
，这也就是咱们要访问的域名。
第四个数据包，DNS应答。
这个数据包我们看一下DNS头部中的答案即可，解析的IP地址为61.135.181.169。当然这个答案为多个，用于访问sohu的备份IP。如果在这个过程中出现问题的后果，大家可以回想一下2010年无法访问百度那件事故就明白了。
其实像这种ARP、DNS请求应答信息，没必要去看详细的数据包解码，只要在数据包视图下，查看概要即可，如下图：
在上图中概要一栏，以及很清晰的看到相关信息了。
要访问域名的IP以及有了，就可以进行http的应用请求了，而http是跑在TCP层之上的。众所周知TCP是面向连接的传输协议，也就意味着要进行三次握手，进行TCP建立连接。操作系统对http进行解析，了解到http使用了TCP的80端口，所以在发起TCP连接的时候，目标端口为80.
第五个包，TCP三次握手第一个包，SYN发送。
TCP头部比IP、UDP头部更复杂，只选择几个重点的说一下吧。源端口为本地随机的端口，目标端口为80，用于http。初始序列号8389539为随机的，确认号为0，标志为000010即同步位置1。TCP选项中的最大段长为1460，这个跟MTU有关，需要在TCP握手期间进行协商。
第六个包，TCP三次握手第二个包，SYN ack。
源端口为80，目标端口为61706；序列号为2272548105，确认号为8389540，注意这个确认号与上一个包的序列号之间的关系，考虑一下。
标志位010010，SYN、ACK都置1，是对SYN包的确认包。TCP选项中最大段长为1452，而在上一个数据包中为1460，这样会话两端则会协商到一个结果，最大段长为1452，取最小值。以后发送TCP数据时，TCP承载的数据大小则不会超过1452.
第七个包，TCP三次握手第三个包，ACK包。
可以看到这个数据包已经没有TCP选项字段，在接下来的数据包中也不会存在TCP选项字段了。这个数据包仍为本地主机发出，源IP为192.168.10.107。TCP源端口为61706，与TCP第一个包的源端口是一样的，目标仍为80.所以说，在一个TCP会话中源目端口是不会变化的。序列号为8389540，与第一次发出TCP SYN包增加了1；确认号为由之前的0变为2272548106，关于这个2272548106与服务器端发出的SYN
ACK中序列号（2272548105）的关系，思考一下。标志位为010000，只要ACK位置1.
至此为止TCP的三次握手已经完成，接下来可以进行http的请求了。
同样TCP握手这三个数据包，我们也没必要去看详细的解码信息。可以在TCP会话视图中，查看如下图：
在这个时序图中，我们可以清晰的看到这个TCP会话的源目IP、源目TCP端口，序列号的变化，标志位的置位情况。
其实在TCP会话分析中一个最重要的参数我们没有提到，那就是时间。这次我们是介绍网络操作的变化，不涉及太多时间，但我们仍然要说一下。
在TCP会话视图中，双击第一个TCP会话，则打开TCP流分析界面。如下图：
在上图的左下角部分，是一个TCP的时序图，包括了相对时间和时间差，通过这个时间差我们可以计算网络的RTT值（往返时间），进而来评估网络层面的延时情况。在本次会话中，网络层面的延时为0.022741s，此延时基本可以容忍。
继续介绍本机在完成三次握手之后，接下来的操作。
第八个数据包，http的get请求。
如上图，http的数据是在TCP包头的里面，也就是HTTP是由TCP来承载的，看一下http字段。请求为GET，host主机部分为www.sohu.com
也就是咱们要访问的界面。
第九个数据包，http get的ACK。
这个数据包内容很简单，只是一个ack置1的包。用于对http get在TCP层面的确认，也就是每个TCP数据发出后，对端需要进行确认，体现了TCP传输的可靠性。同样注意一下这个包的确认号与第7个数据包中的确认号的差额。
第十个包，http 的响应包。
这个数据包是服务器对http get在应用层的响应，可以看一下字段中有一个200 0k字样，这个代表服务器对客户端发出的请求能进行正常服务。
接下来，就是服务器对客户端请求的页面进行回馈了，可以看到后面的数据主要为服务器端发送数据，客户端对数据进行确认，即简单的ACK。
如上图，同样上面介绍的http信息也没必要去看详细的解码，只要看概要中的GET及服务器回应的200 OK即可。
在这个过程中也涉及了一个时间的概念，这个时间主要是服务器对http get的响应时间，是应用层面的响应时间。我们同样在TCP流分析中看到：
在上图中的时间差中，第4与第5个包之间的时间差，为2.966484，可以认为是服务器的响应时间，3s个人感觉还可以忍受。
Ok，所有数据都传完，我们也就可以看到sohu的主页了。
总结一下，以上涉及了IP地址设置、ARP解析、DNS解析、TCP建立、http请求等。其中的任何一个环节出现了问题，都会导致网页打不开的。
当我们再遇到网页打不开的时候，我们就不要再无奈的抱怨了。只需要打开科来网络分析系统，查看具体在哪个环节出现问题，解决相应的问题即可。
原文见附件 |
评分
-
2
查看全部评分
-
|
发表于 2011-9-19 17:50:05
发表于 2011-9-19 17:58:30
发表于 2011-9-19 21:24:06
