《计算机网络自顶向下》Wireshark实验 Lab4 TCP

我会带着你远行 2022-09-10 10:08 268阅读 0赞

### 文章目录 ###

*   *  专栏博客链接
     *  前引
     *  Lab4 TCP
     *   *  查阅Wireshark Lab官网 获取Lab文档
         *  Q&A 1 所作工作
         *  Q&A 1

--------------------

## 专栏博客链接 ##

--------------------

**[《计算机网络自顶向下》Wireshark Lab + 套接字编程作业 + 杂项实验室编程作业 全实验博客链接][Wireshark Lab _ _ _ _]**

--------------------

## 前引 ##

--------------------

**各位好 啊 学计算机想要学好真的还是挺难的 说实话 科班学计算机如果想要花大量的时间去学 只能把平时的课程大部分时间不去上 如果班级管理严格或者说 各种因素让你不得不去上**

**哎 真的还是挺苦恼的 想要自己花时间静下心来做很多事情真的还是好不容易 刚刚就出去买了瓶尖叫 就发生了这么多事情 我把UDP 和 TCP争取早点做出来 自己出去散步散散心吧**

**但还好的是 这个星期 待会还有一节课就彻底放了 cqupt三天拿出来新生迎接 当然也不能浪费时间去复习**

**刚刚和老师说了一下 之后又和其他老师沟通了一下 哈哈哈 挺好的 本来烦躁和困顿的心情一下子就破开了 ^^ 把握机会把Lab做完吃饭**

--------------------

## Lab4 TCP ##

--------------------

### 查阅Wireshark Lab官网 获取Lab文档 ###

--------------------

**方便大家还是给一下链接吧 官网链接**  
**[WIRESHARK LABS][]**

**下面是文档的中文截图 就截一部分 继续往下看了**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16]

--------------------

### Q&A 1 所作工作 ###

--------------------

**进入下面链接 下载`alice.txt`文件 直接右键下载即可**  
**[Alice in Wonderland File Download][]**

--------------------

**[Alice in Wonderland File Upload][]**  
**得到`alice.txt`文件后 我们打开浏览器 我们先上传`alice.txt`文件  
此时不要点`upload alice.txt` 我们打开`wireshark` 先开始捕获 我们再点击 看到页面出现`Congratulations!` 即返回`wireshark`停止捕获**

**由于一般浏览器都有自己的访问策略 都是每次建立`TCP`链接 发送两三个一次 所以这里我选择了`firefox`浏览器 刚开始的三次握手更容易看一点**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 1]

--------------------

**得到的`wireshark`截图如下图**

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 2]

--------------------

### Q&A 1 ###

--------------------

**1. 将文件传输到 gaia.cs.umass.edu 的客户计算机（源）使用的 IP 地址和 TCP 端口号码是什么？ 要回答此问题，选择 HTTP 消息并使用"选定数据包头窗口的详细信息"（如果您不确定 Wireshark 窗口不确定，请参阅"从 Wireshark 开始"实验室中的图 2）来浏览用于携带此 HTTP 消息的 TCP 数据包的详细信息可能最简单。**  
**`ip地址 是我校园网ip - - 10.20.72.149 TCP端口号打开即可看到 我这边是6889`**

--------------------

**2. gaia.cs.umass.edu 的 IP 地址是什么？在此连接中，它会发送和接收哪个端口号码的 TCP 段？**  
**`ip地址 128.119.245.12 接收端口号80 首先我们的发送创建请求是发了两条 服务器只回应了其中一个端口 我们发送请求的一个是6889 一个是6890 回应了6889 如下图`**

![在这里插入图片描述][7b7e48bd87d74aa4be83f44159a7b153.png]

--------------------

**3. 客户端计算机（源）用于将文件传输到 gaia.cs.umass.edu 的 IP 地址和 TCP 端口号码是多少？**  
**`这个打开直接看即可`**

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 3]

--------------------

**4. 用于启动客户端计算机和 gaia.cs.umass.edu 之间的 TCP 连接的 TCP SYN 段的序列号是多少？ 将该段标识为 SYN 段的细分市场中有什么？**  
**`这里火狐浏览器 刚开始的SYN序列号为0 标识为SYN段是在标识位置了1`**  
![在这里插入图片描述][0bcd82028c6e473eb4879becaac5016a.png]

--------------------

**5. gaia.cs.umass.edu 发送到客户端计算机以响应 SYN 的 SYNACK 段的序列号是多少？ SYNACK 细分市场中的确认字段的价值是何等？ gaia.cs.umass.edu 如何确定该值？将该细分市场识别为 SYNACK 细分市场的细分市场中有什么？**  
**`响应的序列号为0 ACK为1 ACK为1由于握手的序列号为0 则ACK = 1`**

![在这里插入图片描述][3e685083a497459e85c45555ee3b9c0e.png]

--------------------

**6. 包含 HTTP 邮政命令的 TCP 段的序列号是多少？ 请注意，要找到 POST 命令，您需要深入到 Wireshark 窗口底部的包内容字段，在其数据字段中查找带有"POST"的段。**  
**`含有POST 字段的为最后的一次握手字段 作为客户机最后一次三次握手确认 还包含了要发送的字段 序列号为1 因为是连着上面的序列号0连续发的`**

--------------------

**7. 将包含 HTTP POST 的 TCP 段视为 TCP 连接中的第一段。TCP 连接中前六个段的序列号（包括包含 HTTP POST 的段）是哪些？ 每个段在什么时间发送？ 收到每个段的 ACK 是什么时候？ 鉴于每个 TCP 段的发送时间与收到确认项之间的区别，六个段中每个段的 RTT 值是怎样的？ 收到每个 ACK 后，估计的 TRTT 值（见第 3.5.3 节，文本第 242 页）是什么？ 假设估计 RTT值等于第一段的测量 RTT，然后使用第 242 页中所有后续段的估计 RTT方程进行计算。  
注意 ：Wireshark 具有一个很好的功能，允许您为发送的每个 TCP 段绘制 RTT 图。 在"捕获数据包列表"窗口中选择从客户端发送到 gaia.cs.umass.edu 服务器的 TCP 段。 然后选择： 统计->TCP流图->圆行程时间图。**

**`前面三次为三次握手`**  
**`C->S seq = 0 len = 0 SYN`**  
**`S->C seq = 0 len = 0 ack = 1 SYN ACK`**  
**`C->S seq = 1 len = 1448 ack = 1 ACK 开始发数据了`**  
**下面就是流水线了 但抛开流水线 只看两边的交互的话**  
**`S->C seq = 1 len = 0 ack = 1449 ACK`**  
**`C->S seq = 1449 len = 1448 ack = 1 ACK`**  
**`S->C seq = 1 len = 0 ack = 2897 ACK`**

**从上面的数据可以看出来还是很清晰的**

--------------------

**8. 前六个 TCP 段中每个段的长度是怎么回事?**  
**`刚开始的前两个段没长度正常 因为是正常的握手 到了第三次 也是最后一次建立连接的握手时 客户机已经确定了服务器可以接收数据了 就直接带着ACK和数据一起去了`**

**`之后的回复响应TCP len = 0 因为我们确认是否收到是只看服务器响应的序列号是多少 累计确认之前的那些已经收到了 而我们的len = 1448 是客户机发出去的那么多 也是很正常的`**

--------------------

**9. 在整个跟踪接收时所宣传的可用缓冲空间的最小数量是多少？ 缺少接收器缓冲空间会限制发件人吗？**  
**`由于这边wireshark的window数目是自己计算的 所以我们这边没有办法得到还有多大的数目 详情可看下面链接`**  
**[Wireshark的window size value和calculated window size][Wireshark_window size value_calculated window size]**  
**从`SYN`的握手过程中 还是可以看到服务器那边的`window` 是`28960` 如果缺少缓冲空间 肯定会限制发件人 因为每次发件都会给发件人回一个还有剩余多少`window`的提示 发件方也会根据`window`还有多少来自己决定发送多少**

--------------------

**10. 跟踪文件中是否存在任何重送段？为了回答这个问题，你检查了什么（在跟踪中）？**  
**`没有看见重送段` `检查了挨着送的包的序号 都是只送了一遍 - - 但是服务器方向客户端有的包发了多个确认收到的ACK`**

--------------------

**11. 接收器通常在 ACK 中确认多少数据？ 您能否识别接收方在所有其他接收段中 ACKing 的情况（请参阅文本第 250 页的表 3.2）。**  
**`这个问题没有搞懂 - -咋说什么 由于是累积确认 在发送的序号之前都是确认收到的了`**

--------------------

**12.TCP 连接的吞吐量（每个单位时间传输字节）是什么？ 解释您如何计算此值。**  
**`单位时间内容纳向外能够发出的字节数`**

--------------------

**13. 您能否确定 TCP 的慢启动阶段的开始和结束位置，以及避免拥堵的接管位置？**  
**`结束位置我还是没看出来 但是对于慢启动我看客户端发送还是能够看出来的`**  
**`刚开始的滑动窗口仅仅容纳发送10个满载的TCP段出去 当接受了一次ACK后 很明显的后面直接窗口变大 变到几十个 但是还是有上限的 之后的发送每到一个阶段就会等待服务器的ACK后 再发送数据`**

**刚开始仅仅容纳`10`个**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 4]

--------------------

**到后面一段时间 明显滑动窗口变长 以至于一个屏幕都截不完**  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 5]

[Wireshark Lab _ _ _ _]: https://love6.blog.csdn.net/article/details/120071337
[WIRESHARK LABS]: http://gaia.cs.umass.edu/kurose_ross/wireshark.php
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/039d25f8abf44621a62f6a42f5b4400c.png
[Alice in Wonderland File Download]: http://gaia.cs.umass.edu/wireshark-labs/alice.txt
[Alice in Wonderland File Upload]: http://gaia.cs.umass.edu/wireshark-labs/TCP-wireshark-file1.html
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/7dc49398c83a4491ba9ca33186190a34.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/22d5c7000f9142269e486c0f94113ce9.png
[7b7e48bd87d74aa4be83f44159a7b153.png]: /images/20220829/da2e7c1408164437b139e082880f2387.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220829/e8e77ed7047341408f6d36624e7c2eec.png
[0bcd82028c6e473eb4879becaac5016a.png]: /images/20220829/4d8e62e358164886984d673913802441.png
[3e685083a497459e85c45555ee3b9c0e.png]: /images/20220829/fb47196f73f2422981004959f85f4d6d.png
[Wireshark_window size value_calculated window size]: https://blog.csdn.net/weixin_34051201/article/details/91608467
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220829/390758a17bb34e889cfbca3368281361.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBATG92ZSA2_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220829/37835bff8c7d447ca498c21f8c3708ba.png