一、实验目的
学会使用抓包软件Wireshark进行抓包，了解其工作原理，进一步理解相关协议。
二、实验内容
任选两个实验完成,要求实验不能是同一章中的内容。
三、具体实验操作
我选择的是HTTP和TCP协议
（一）Ethereal Lab：HTTP
1.基本的 HTTP GET/响应交互
访问网址的网页内容：
Wireshark窗口：
回答以下问题：
(1)您的浏览器运行的是 HTTP 版本 1.0 还是 1.1？服务器运行的是哪个版本的 HTTP？
可知我的浏览器是HTTP1.1版本。
(2)您的浏览器指示服务器可以接受哪些语言（如果有）？
(3)您计算机的 IP 地址是什么？gaia.cs.umass.edu 服务器？
我的IP地址是192.168.126.129
该服务器的IP地址是128.119.245.12
(4)从服务器返回到浏览器的状态代码是什么？
(5)您上次在服务器上修改您正在检索的 HTML 文件是什么时候？
(6)将向浏览器返回多少字节的内容？
126个字节
(7)通过检查数据包内容窗口中的原始数据，您是否看到数据中未显示在数据包列表窗口中的任何标头？如果是这样，请命名一个。
是。如下图未被标红部分就是未显示在数据包列表中的，可能是更低层协议下的一下调试信息。
2.HTTP 条件 GET/响应交互
访问网址的网页内容：
Wireshark窗口：
回答以下问题：
(1)检查从浏览器到服务器的第一个 HTTP GET 请求的内容。您是否在 HTTP GET 中看到“IF-MODIFIED-SINCE”行？
如上图所示，没有看到“IF-MODIFIED-SINCE”行。
(2)检查服务器响应的内容。服务器是否显式返回了文件的内容？你怎么知道呢？
是的，见下图：
(3)现在检查从浏览器到服务器的第二个 HTTP GET 请求的内容。您是否在 HTTP GET 中看到 “IF-MODIFIED-SINCE：” 行？如果是这样，“IF-MODIFIED-SINCE：” 标头后面有什么信息？
看到了，见下图：
包含了时间，这个时间是上一次服务器响应报文中最后一次修改的时间。
(4)服务器为响应第二个 HTTP GET 返回的 HTTP 状态代码和短语是什么？服务器是否显式返回了文件的内容？解释。
返回304 Modified ,并且没有直接返回文件的内容。返回的状态码明显告诉我们没有修改文件，所以直接从本地调用缓存。
3.检索长文档
访问网址的网页内容：
Wireshark窗口：
回答以下问题：
(1)您的浏览器发送了多少条 HTTP GET 请求消息？
只发了一条HTTP GET请求消息。
(2)需要多少个包含数据的 TCP 分段才能承载单个 HTTP 响应？
需要4个，见下图：
(3)与 HTTP GET 请求的响应关联的状态代码和短语是什么？
(4)传输的数据中是否有任何与 TCP 诱导的 “Continuation” 关联的 HTTP 状态行？
答：没有看到。
4.HTML 包含嵌入对象的文档
访问网址的网页内容：
Wireshark窗口：
回答以下问题：
(1)您的浏览器发送了多少条 HTTP GET 请求消息？这些 GET 请求发送到了哪些 Internet 地址？
有三条HTTP GET请求消息，第一条则是正常请求该服务器的请求消息，可以看到上面网址内容有两张图片，所以额外需要向有这两张图片的服务器去请求消息，而第一个gif图片的请求响应为403 Forbidden被停止访问了，所以这张图片无法显示，而第二个GET则响应200，获得了图片。
(2)您能否判断您的浏览器是连续下载了这两个图像，还是同时从两个网站下载了它们？解释。
应该是连续下载了这两个图像。
请求消息是一步一步请求的。
5.HTTP 身份验证
访问网址的网页内容：
（文档给的账号密码有误，正确的账号：wireshark-students 密码：network）
Wireshark窗口：
回答以下问题：
(1)服务器对来自浏览器的初始 HTTP GET 消息的响应（状态代码和短语）是什么？
如果一个HTTP客户端，例如一个web浏览器，请求一个属于受保护领域的页面，服器响应一个401未授权状态码，并在他的响应中包含一个WWW-Authenticate头字段。此报头字段必须包含至少一个适用于所请求页面的身份验证挑战。
(2)当您的浏览器第二次发送 HTTP GET 消息时，HTTP GET 消息中包含哪些新字段？
（左图是访问这个网址时的GET，右图是登陆后的GET）
可以发现第二次发送HTTP GET消息时，HTTP GET多了Authorization和Cache-Control新字段。
（二）Ethereal Lab：TCP
1.捕获从计算机到远程服务器的批量 TCP 传输
执行以下操作：
上传文件后：
Wireshark窗口：
2.初步查看捕获的跟踪
3.TCP 基础知识
对于 TCP 分段，请回答以下问题：
(1)您的客户端计算机（源）用于将文件传输到 gaia.cs.umass.edu 的 IP 地址和 TCP 端口号是什么？gaia.cs.umass.edu 接收文件时使用的 IP 地址和端口号是什么。
源IP：172.16.40.224 源端口号：58692
目的IP：128.119.245.12 目的端口号：80
(2)用于启动客户端计算机和 gaia.cs.umass.edu 之间的 TCP 连接的 TCP SYN 段的序列号是什么？区段中将区段标识为 SYN 区段的是什么？
用于启动客户端计算机和 gaia.cs.umass.edu 之间的 TCP 连接的 TCP SYN 段的序列号是 0。区段中将区段标识为 SYN 区段的是 SYN 标志位被设置1。
在首个建立连接的TCP请求中，SYN标志位为1。
段中的倒数第2bit设置为SYN标识位。
(3)gaia.cs.umass.edu 发送到客户端计算机以响应 SYN 的 SYNACK 段的序列号是什么？SYNACK 区段中 ACKnowledgement 字段的值是多少？gaia.cs.umass.edu 是如何确定该值的？区段中将区段标识为 SYNACK 区段的什么？
响应 SYN 的 SYNACK 段的序列号是0
SYNACK区段中ACKnowledgement字段的值是1。gaia.cs.umass.edu确定该值的方式是将客户端发送的SYN区段的序列号加1。区段中将区段标识为SYNACK区段的是SYN和ACK标志位都被设置为1。
(4)包含 HTTP POST 命令的 TCP 段的序列号是多少？请注意，为了找到 POST 命令，您需要深入研究 Ethereal 窗口底部的数据包内容字段，查找其 DATA 字段中带有 “POST” 的段。
包含POST的字段的TCP序号为151904.
(5)将包含 HTTP POST 的 TCP 段视为 TCP 连接中的第一个段。TCP 连接中的前 6 个分段（包括包含 HTTP POST 的分段）的序列号是什么？每个区段在什么时间发送？何时收到每个区段的 ACK？考虑到每个 TCP 段的发送时间和收到其确认的时间之间的差异，这六个段中每个段的 RTT 值是多少？收到每个 ACK 后的 EstimatedRTT 值（参见正文第 237 页）是多少？假设 EstimatedRTT 的值等于第一个片段的测得 RTT，然后使用第 237 页上的 EstimatedRTT 公式计算所有后续片段。
6个序列号分别是143264.144704，146144，147584，149024，150464.
其中序列号为144704的RTT为9.910285 - 9.656713 = 0.253572
(6)前 6 个 TCP 分段的长度是多少？
我这里的len=1440
(7)对于整个跟踪，在接收时公布的最小可用缓冲区空间量是多少？缺少接收方缓冲区空间是否会限制发送方？
最小窗口应该是1460. 包的实际大小小于缓冲区大小，所以不会限制发送方。
(8)跟踪文件中是否有任何重新传输的段？为了回答这个问题，您检查了什么（在跟踪中）？
没有重传片段。发送端IP为172.16.40.224，查看这个IP发送的所有包序号都没有重复。
(9)接收方通常在 ACK 中确认多少数据？您能否识别出接收方每隔一个接收到的段就对每个 ACK 进行确认的情况（参见正文第 245 页的表 3.2）。
- 接收方通常在ACK中确认的数据量取决于MSS（最大报文段长度），在IPv4网络中，MSS的典型取值为1460字节。这意味着在没有使用SACK（选择性确认）的情况下，接收方通常在ACK中确认1460字节的数据。
- 根据搜索结果中的描述，TCP是累计确认的，一般接收方每隔一个接收到的区段才发送确认。这意味着接收方并不是对每个接收到的段都立即发送ACK，而是可能累积多个段后再发送一个ACK确认。
(10)TCP 连接的吞吐量（每单位时间传输的字节数）是多少？说明您是如何计算此值的。
4.TCP 拥塞控制的实际应用
回答以下问题：
(1)使用 Time-Sequence-Graph（Stevens） 绘图工具查看从客户端发送到 gaia.cs.umass.edu 服务器的 Segment 的序列号与时间图。您能否确定 TCP 的慢启动阶段从何处开始和结束，以及拥塞避免从何处接管？请注意，在这个 “真实世界” 的轨迹中，并不是所有的东西都像图 3.51 中那样整洁干净（还要注意，Time-Sequence-Graph（Stevens） 绘图工具和图 3.51 的 y 轴标签是不同的）。
(2)评论测量数据与我们在本文中研究的 TCP 的理想化行为的不同之处。
- 在理想化的TCP行为中，慢启动阶段拥塞窗口（cwnd）会指数增长，直到达到慢启动门限（ssthresh）。然而，在实际中，由于各种网络条件和操作系统的实现，增长可能不是完全指数的，可能会有更复杂的动态调整。
- 在理想化的TCP行为中，拥塞避免阶段cwnd会线性增长。但在实际中，由于网络条件的复杂性，cwnd的增长可能不是完全线性的，可能会有波动。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
