本想把题目写成《详解 HTTP 全过程》，能力有限来个《略解 HTTP 全过程》还是更好些。
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

IE 主页设置（ [url]www.51cto.com[/url] ）
Sniffer 设置就绪

 

点 IE ，点 Sniffer!

 

[url]www.51cto.com[/url] 网页完全打开时，我们才停止数据包的捕获（因为我们想得到一个完整的 HTTP 过程，所以先禁用网卡，使保存在计算机缓存中关于 HTTP 的信息自动删除掉！）。

 

经 Sniffer 的工作后，可得到下面的图表（让我们略分析下图表）(图表看起来有点模糊,点击后,可能看到比较清楚的图表喔!)：
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
当我们进行 HTTP 请求时，计算机最先进行的当然是用 ARP 去得到网关的 MAC 喔！（在表中没有显示出来）。

 

 

由于我们使用 [url]www.51cto.com[/url] 访问网页的， DNS 当然就少不的。 [ 序号（ 1 ） ] 行中我们可以看到一个 DNS 数据包被计算机发送了，目标地 IP （ 61.139.2.69 ）当然是 DNS 服务器（这是在本地中有个存 IP 与域名映射的文件中没有相应映射才进行的动作（本地计算机的高速缓存中也没有这个域名与 IP 的映射）），源地址 IP 当然就是我的计算机 IP 地址（ 192.168.0.96 ）。
这样一去一回，计算机这时就知道一个（大型网站，同时有个多域名，有多个 IP 。这样做的好处当然多多喔！）我们想访问网站（ 51CTO 的主页）的 IP 地址喔！

 

 

现在计算机知道了网关的 MAC 也知道我们访问网站的 IP 地址，下面就要进行 TCP 的最最著名的三次握手动作了喔！从 [ 序号（ 3 ） ] 这行中我们知道，这个握手是本地计算机发起的（谁叫是我们向别人要东西喔！当然要主动些啊！）。 [ 序号（ 4 ） ][ 序号（ 5 ） ][ 序号（ 6 ） ] 这三个数据包就是三次握手的“铁证”喔！

鉴于三次握手在 TCP 的地位与声望。在此还是要比较重点的介绍一下，才对得起它。

 

从“摘要”栏中我们可知： [ 序号（ 3 ） ] 这个数据包的目标端口是 80 （这是个 RFC 中定义了的，提供 WEB 服务时使用 TCP 的 80 端口，不过现在有时也不一定喔！有的软件就是不遵从规则，不按规律出牌。像 QQ 不管是 443 、 80 、 8080 一个都不放过。），源端口就是随机的（其实是使用 现在未使用的最小的合法的端口号，是按顺序从低到高取的（这只是在 windows 中是这样的，在其它的 TCP/IP 实现（ linux,mac OS ）中就不知道了）），这次 TCP 连接中计算机选择了 1051 这个端口号 ( 看来计算机先前还是没有建立多少连接 ) 。

 

数据包中的 TCP 段是这个三次握手的主体部分，在 TCP 段中有几个很重要的标志位（虽然只有短短的 6 个比特，但作用是很大，有多大呢？没有它们，三次握手就不能建立，直接的后果这个 TCP 连接就不能建立，间接的后果是我们不能浏览 WEB 等等。）。在三次握手的初始中， SYN 这个标志位就代表发起一个 TCP 连接（请求 51CTO 的 WEB 服务器建立连接）。

 

由于 TCP 连接提供的功能比 UDP 强大。根据功能与复杂度成正比。 TCP 就一定需要用更多的设置来达到某些特定的功能。下面介绍的 SEQ 、 ACK 、 WIN 就是为达到某些功能面产生的“事物”。到底 SEQ 、 ACK 它们存在的价值是什么呢？

SEQ ：     数据包中的实际数据（应用层的数据，不包括 TCP 层、 IP 层、物理层的数据）中最后一个字节（每一个字节占用一个序列号单位）相对初始序列号的序列号（好难说喔！感觉还是没有说清楚喔！）。举例：如果初始序列号（ SEQ ）为 1234567890 ，数据包中的实际数据有 6 个字节，则下个数据包中的 SEQ 为 1234567896 。

 

ACK ：    就是计算机希望得到下一个数据包的这第一个实际数据的序列号。

 

通过 SEQ 、 ACK （还有各种计时器的配合），就可以达到对已发送的数据的确认，如果有未确认的已发的数据，发送方会重新进行传输。