计算机网络实验（Wireshark实验）

最新推荐文章于 2024-10-07 20:00:00 发布

Tgmmmmmmmm

最新推荐文章于 2024-10-07 20:00:00 发布

阅读量1.2w

点赞数 20

文章标签： wireshark 网络协议网络

本文链接：https://blog.csdn.net/tgmmmmmmmm/article/details/122379293

版权

计算机网络实验（Wireshark实验）

文章目录

计算机网络实验（Wireshark实验）

前言

计算机网络是计算机课程中核心的一门，有了他我们的计算机不再只是自己狂欢的平台，让我们可以与世界上其他的计算机进行交流、获取资源。而计算机网络同样作为人造学科，我们首先要学的便是其人造的特点，也就是网络协议的学习。

网络协议是为计算机网络中进行数据交换而建立的规则、标准或者说是约定的集合。因为不同用户的数据终端可能采取的字符集是不同的，两者需要进行通信，必须要在一定的标准上进行。

本次学习的计算机网络实验主要由验证性、Wireshark 和 Cisco Packet Tracer 实验等三个部分组成，可以让我们掌握基础的计算机网络基础，依次基础对网络协议进行抓包分析，最后可以通过模拟实验进行进一步模拟重现。

本篇主要为Wireshark实验，其他见同期文章

Wireshark 实验

Wireshark基本使用

选择那块网卡进行捕捉，可以看到WLAN有网络波动，并且结合本机网络，确实应该选择这个。
开始/停止捕获

选择WLAN，右键，选择Start capture即可开始捕捉，ok其实双击是一样的

开始捕获后自动跳转到捕捉主界面：

可以看到工具栏中，有开始捕获、停止捕获、重新开始当前捕获这些基本功能。

了解Wireshark主要窗口区域

tips:在wireshark的抓包界面，基本分为菜单栏、工具栏、过滤栏、数据列表区、数据详细区、数据字节区和数据统计区等等

开始/停止捕获: 这两个可以通过菜单栏中的捕获一项进行控制，同样也可以通过工具栏中的图标进行控制。
过滤栏则是快速对捕获的包进行过滤
在数据列表区选择某条数据的时候，下方数据详细区则会显示对应包的详细信息，同样数据字节区则会显示该包实际传递到数据字节，数据统计区会对其进行统计分析，在数据列表区右键还可以进行数据流的追踪。

设置数据包的过滤

tips：在过滤栏简单输入需要保留特征，回车即可快速过滤

在其中输入tcp后，协议只保留了所有TCP的协议。

同时我们还可以通过过滤，之查看与某ip相关的包

比如选择我访问qige.io的网络实验教程，查看发现远程地址是ipv6地址

欧克，我们可以看到wireshark他提供了许多过滤方案，我们在过滤器中选择仅ipv6 且输入ip地址为2606:4700:3033::6815:272e

cool，现在我们捕捉到的，就全部是与该ip地址有关的了

跟踪数据流

首先我们去除过滤器，点击过滤栏中右边一个x即可，然后访问我自己部署在ip为139.196.81.224的一个网址，ok其实他是一个swaager-ui，但是没关系，分析以下协议而已。

可以看到根据着色方案来绘制分组的时候，将部分包进行了着色，我们现在希望分析其中一个包，对其进行数据流追踪。

所以我们可以选择一个右键->追踪流->TCP流

同时我们可以看到双方整个对话，或者选择单方，然后可以把展示数据改为原始数据，然后另存到本地，通过二进制的存储，然后利用WinHex等工具对原始资源进行还原。

数据链路层

实作一：Ethernet帧结构

双击任意一个包，即可弹出详细信息界面，在这里选择数据链路层的Ethernet帧，下方即可展开该帧结构，包括目的MAC，源MAC、类型，下方还会高亮对应的数据字节。甚至还会根据MAC地址特点分析出设备厂家等。

问题：校验字段是在物理层进行校验传输是否出错的，wireshark抓的包是校验后的包，所以wireshark展现给我们的帧中没有校验字段。

实作二：子网内/外通信时MAC地址

ping 192.168.1.18 子网内通信

可以看到，此时，无论是发出的目的mac还是返回的源mac都为，对应计算机的mac实际地址。

ping baidu.com 子网外通信

回忆起之前利用arp -a查看到了此时的网关mac为1c-59-9b-4d-cb-98

ping www.cqjtu.edu.cn 同样是子网外通信

呀哈奇了怪了，发现此时抓不到icmp回显的包了，仔细分析结合过滤栏提示

发现访问重庆交通大学时，居然用的是v6地址，好吧，那我就换成icmpv6好了

okk发现同样目的的mac是网关地址。

问题：究其原因，无法是在子网内部，我的arp缓存了192.168.1.18的mac地址，而百度的和重庆交通大学的没有，所以默认转发到网关出去。可以试试先把缓存删掉，再ping。

好吧发现还是一样的结果，最后取消过滤器发现，在找不到的时候，首先使用了arp协议在子网内部广播，然后就找到了192.168.1.18这个ip地址的mac地址，自动存到arp缓存里面去了。

实作三：掌握ARP解析过程

呀哈发现刚刚思考问题的时候顺便把这个也做了，再做一次吧。

当我在ping 192.168.1.18的时候，会发出一个arp广播，

询问谁有192.168.1.18（目的ip），请告诉192.168.1.14（本机ip）

目的mac都是全F，即广播。

而只ping外网时候，回复的就是网关了。

问题：因为本机会自动将子网掩码和目的ip进行与运算，判断该ip是否在本子网内部，如果不再，只是会网关进行回应，如果在内部，则会等待该ip对应的主机回应。那么问题又来了，如果在该子网，但是没开机会怎么样呢，或者说属于该子网，还没分配呢。

测试发现，嗯，他会问很多遍，然后超时了，就让默认网关处理。

网络层

实作一：IP包结构

废物利用一下，icmp包好歹也是ip包

问题：为了在此基础上更加提高效率，有头部长度字段和总长度字段是为了方便上层将 IP 包中的数据提取出来，当数据长度超过1500B时就会被返回链路层进行分段，这样能帮助传输时的识别IP总长度，提高传输效率。

实作二：ip包的分段与重组

tips：利用ping命令的-l指令即可改变要发送的数据长度

问题：IPv6 中，如果路由器遇到了一个大数据包该怎么办？当然是转发到支持该数据传输的路由上或者丢掉咯。

实作三：考察TTL时间

使用tracert www.baidu.com进行追踪，可以看到每次发送的ttl都是逐一增加的，每个都发三次，刚好与其结果对应。

问题：如果你收到一个包，其 TTL 的值为 50，那么可以推断这个包从源点到你之间有多少跳？

这个就不是很好判断了，因为他是一步一步减少的，但是我无法知道他的起始是多少，如果一般的64或者128来说，那就应该是64-50=14或者128-50=78了。

传输层

实作一：熟悉TCP与UPD段结构

熟悉 TCP 段的结构，如：源端口、目的端口、序列号、确认号、各种标志位等字段。

熟悉 UDP 段的结构，如：源端口、目的端口、长度等。

问题：源和目的端口号用来干什么？

端口和目的端口是用来确认某一个应用程序，IP 只能到达子网网关，MAC 地址到达子网下的指定主机，而端口号是达到主机上的某个应用程序。

实作二：分析TCP建立与释放连接

打开浏览器访问 qige.io 网站，用 Wireshark 抓包（可用 tcp 过滤后再使用加上 Follow TCP Stream），不要立即停止 Wireshark 捕获，待页面显示完毕后再多等一段时间使得能够捕获释放连接的包。

第一次握手，SYN为1，ACK为0

第二次握手，SYN为1，ACK为1

第三次握手，SYN为0，ACK为1

SYN 同步序列号，用来发起一个TCP连接

四次挥手释放连接的包

第一次挥手，FIN为1，ACK为1

第二次挥手，ACK为1

第三次握手，FIN为1，ACK为1

第四次握手，ACK

TCP断开连接是通过发送FIN报文，来告诉对方数据已经发送完毕，可以释放连接了。

问题：不跟踪一个 TCP 流，你可能会看到访问 qige.io 时我们建立的连接有多个。请思考为什么会有多个连接？作用是什么？

因为这个连接属于短连接，这为了实现多个用户进行访问，对业务频率不高的场合，不让其长期占用通道。

问题：释放连接需要四次挥手，有时你可能会抓到只有三次挥手。原因是什么？

服务器向客户端发送断开连接和回复同意断开连接合成一次挥手。

应用层

实作一：DNS解析

先使用 ipconfig /flushdns 命令清除缓存，再使用 nslookup qige.io 命令进行解析，同时用 Wireshark 任意抓包（可用 dns 过滤）。

当前计算机使用 UDP，向默认的 DNS 服务器的 53 号端口发出了查询请求，

DNS 服务器的 53 号端口返回了结果。

QR：查询/应答标志。0表示这是一个查询报文，1表示这是一个应答报文
opcode，定义查询和应答的类型。0表示标准查询，1表示反向查询（由IP地址获得主机域名），2表示请求服务器状态
AA，授权应答标志，仅由应答报文使用。1表示域名服务器是授权服务器
TC，截断标志，仅当DNS报文使用UDP服务时使用。因为UDP数据报有长度限制，所以过长的DNS报文将被截断。1表示DNS报文超过512字节，并被截断
RD，递归查询标志。1表示执行递归查询，即如果目标DNS服务器无法解析某个主机名，则它将向其他DNS服务器继续查询，如此递归，直到获得结果并把该结果返回给客户端。0表示执行迭代查询，即如果目标DNS服务器无法解析某个主机名，则它将自己知道的其他DNS服务器的IP地址返回给客户端，以供客户端参考
RA，允许递归标志。仅由应答报文使用，1表示DNS服务器支持递归查询
zero，这3位未用，必须设置为0
rcode，4位返回码，表示应答的状态。常用值有0（无错误）和3（域名不存在）

问题：你可能会发现对同一个站点，我们发出的 DNS 解析请求不止一个，思考一下是什么原因？

DNS不止一个的原因可能是DNS解析过程是先从浏览器的DNS缓存中检查是否有这个网址的映射关系，如果有，就返回IP，完成域名解析；如果没有，操作系统会先检查自己本地的hosts文件是否有这个网址的映射关系，如果有，就返回IP，完成域名解析；如果还没有，电脑就要向本地DNS服务器发起请求查询域名；本地DNS服务器拿到请求后，先检查一下自己的缓存中有没有这个地址，有的话直接返回；没有的话本地DNS服务器会从配置文件中读取根DNS服务器的地址，然后向其中一台发起请求；直到获得对应的IP为止。

实作二：HTTP请求和应答

打开浏览器访问 qige.io 网站，用 Wireshark 抓包（可用http 过滤再加上 Follow TCP Stream），不要立即停止 Wireshark 捕获，待页面显示完毕后再多等一段时间以将释放连接的包捕获。

选择qige.io使用的是https，使用http过滤已经无法抓取信息，换了个url进行抓取。

其中获取资源，大部分用的get

HTTP 请求包，查看请求使用的什么命令，如：GET, POST。并仔细了解请求的头部有哪些字段及其意义。

3.请在你捕获的包中找到 HTTP 应答包，查看应答的代码是什么，如：200, 304, 404 等。并仔细了解应答的头部有哪些字段及其意义。

其中还有更多的应答代码：

 1开头 基本是消息响应
 2开头 基本是成功响应，200——OK
 3开头 基本是重定向，即文件换位置了，比如304——Not Modified没有修改，在缓存中有
 4开头 基本就是客户端错误了，比如404——Not Found，403——Forbidden
 5开头 基本是服务段错误了，比如502——Bad Gateway

状态码原因短语代表含义 HTTP 版本
100 Continue (继续) 客户端应当继续发送请求.这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝.客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应.服务器必须在请求完成后向客户端发送一个最终响应. HTTP/1.1 可用
101 Switching Protocol (切换协议) 服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。 HTTP/1.1 可用
200 OK (成功) 请求成功.成功的意义根据请求所使用的方法不同而不同.GET: 资源已被提取,并作为响应体传回客户端.HEAD: 实体头已作为响应头传回客户端POST: 经过服务器处理客户端传来的数据,适合的资源作为响应体传回客户端.TRACE: 服务器收到请求消息作为响应体传回客户端.PUT, DELETE, 和 OPTIONS 方法永远不会返回 200 状态码. HTTP/0.9 可用
201 Created (已创建) 请求成功，而且有一个新的资源已经依据请求的需要而建立，通常这是 PUT 方法得到的响应码. HTTP/0.9 可用
202 Accepted (已创建) 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。:返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。 HTTP/0.9 可用
203 Non-Authoritative Information (未授权信息) 服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝,如果不是上述情况,使用200状态码才是最合适的. HTTP/0.9 and 1.1
204 No Content (无内容) 该响应没有响应内容,只有响应头,响应头也可能是有用的.用户代理可以根据新的响应头来更新对应资源的缓存信息. HTTP/0.9 可用
205 Reset Content (重置内容) 告诉用户代理去重置发送该请求的窗口的文档视图. HTTP/1.1 可用
206 Partial Content (部分内容) 当客户端通过使用range头字段进行文件分段下载时使用该状态码 HTTP/1.1 可用
300 Multiple Choice (多种选择) 该请求有多种可能的响应,用户代理或者用户必须选择它们其中的一个.服务器没有任何标准可以遵循去代替用户来进行选择. HTTP/1.0 and later
301 Moved Permanently (永久移动) 该状态码表示所请求的URI资源路径已经改变,新的URL会在响应的Location:头字段里找到. HTTP/0.9 可用
302 Found (临时移动) 该状态码表示所请求的URI资源路径临时改变,并且还可能继续改变.因此客户端在以后访问时还得继续使用该URI.新的URL会在响应的Location:头字段里找到. HTTP/0.9 可用
303 See Other (查看其他位置) 服务器发送该响应用来引导客户端使用GET方法访问另外一个URI. HTTP/0.9 and 1.1
304 Not Modified (未修改) 告诉客户端,所请求的内容距离上次访问并没有变化. 客户端可以直接从浏览器缓存里获取该资源. HTTP/0.9 可用
305 Use Proxy (使用代理) 所请求的资源必须统过代理才能访问到.由于安全原因,该状态码并未受到广泛支持. HTTP/1.1 可用
306 unused (未使用) 这个状态码已经不再被使用,当初它被用在HTTP 1.1规范的旧版本中. HTTP/1.1 可用
307 Temporary Redirect (临时重定向) 服务器发送该响应用来引导客户端使用相同的方法访问另外一个URI来获取想要获取的资源.新的URL会在响应的Location:头字段里找到.与302状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST). HTTP/1.1 可用
308 Permanent Redirect (永久重定向) 所请求的资源将永久的位于另外一个URI上.新的URL会在响应的Location:头字段里找到.与301状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST). HTTPbis (试验草案)
400 Bad Request (错误请求) 因发送的请求语法错误,服务器无法正常读取. HTTP/0.9 可用
401 Unauthorized (未授权) 需要身份验证后才能获取所请求的内容,类似于403错误.不同点是.401错误后,只要正确输入帐号密码,验证即可通过. HTTP/0.9 可用
402 Payment Required (需要付款) 该状态码被保留以供将来使用.创建此代码最初的目的是为数字支付系统而用,然而,到现在也没投入使用. HTTP/0.9 and 1.1
403 Forbidden (禁止访问) 客户端没有权利访问所请求内容,服务器拒绝本次请求. HTTP/0.9 可用
404 Not Found (未找到) 服务器找不到所请求的资源.由于经常发生此种情况,所以该状态码在上网时是非常常见的. HTTP/0.9 可用
405 Method Not Allowed (不允许使用该方法) 该请求使用的方法被服务器端禁止使用,RFC2616中规定, GET 和 HEAD 方法不能被禁止. HTTP/1.1 可用
406 Not Acceptable (无法接受) 在进行服务器驱动内容协商后,没有发现合适的内容传回给客户端. HTTP/1.1 可用
407 Proxy Authentication Required (要求代理身份验证) 类似于状态码 401,不过需要通过代理才能进行验证. HTTP/1.1 可用
408 Request Timeout (请求超时) 客户端没有在服务器预备等待的时间内完成一个请求的发送.这意味着服务器将会切断和客户端的连接. 在其他浏览器中,这种响应更常见一些, 例如Chrome 和 IE9, 目的是为了使用HTTP 预连机制加快浏览速度. 同时注意,一些服务器不发送此种响应就直接切断连接. HTTP/1.1 可用
409 Conflict (冲突) 该请求与服务器的当前状态所冲突. HTTP/1.1 可用
410 Gone (已失效) 所请求的资源已经被删除. HTTP/1.1 可用
411 Length Required (需要内容长度头) 因服务器在本次请求中需要 Content-Length 头字段,而客户端没有发送.所以,服务器拒绝了该请求. HTTP/1.1 可用
412 Precondition Failed (预处理失败) 服务器没能满足客户端在获取资源时在请求头字段中设置的先决条件. HTTP/1.1 可用
413 Request Entity Too Large (请求实体过长) 请求实体大小超过服务器的设置的最大限制,服务器可能会关闭HTTP链接并返回Retry-After 头字段. HTTP/1.1 可用
414 Request-URI Too Long (请求网址过长) 客户端请求所包含的URI地址太长,以至于服务器无法处理. HTTP/1.1 可用
415 Unsupported Media Type (媒体类型不支持) 服务器不支持客户端所请求的媒体类型,因此拒绝该请求. HTTP/1.1 可用
416 Requested Range Not Satisfiable (请求范围不合要求) 请求中包含的Range头字段无法被满足,通常是因为Range中的数字范围超出所请求资源的大小. HTTP/1.1 可用
417 Expectation Failed (预期结果失败) 在请求头Expect 中指定的预期内容无法被服务器满足. HTTP/1.1 可用
500 Internal Server Error (内部服务器错误) 服务器遇到未知的无法解决的问题. HTTP/0.9 可用
501 Implemented (未实现) 服务器不支持该请求中使用的方法,比如POST 和 PUT.只有``GET 和 HEAD 是RFC2616规范中规定服务器必须实现的方法. HTTP/0.9 可用
502 Bad Gateway (网关错误) 服务器作为网关且从上游服务器获取到了一个无效的HTTP响应. HTTP/0.9 可用
503 Service Unavailable (服务不可用) 由于临时的服务器维护或者过载,服务器当前无法处理请求.这个状况是临时的,并且将在一段时间以后恢复.如果能够预计延迟时间,那么响应中可以包含一个Retry-After:头用以标明这个延迟时间.如果没有给出这个Retry-After:信息，那么客户端应当以处理500响应的方式处理它.同时,这种情况下,一个友好的用于解释服务器出现问题的页面应当被返回,并且,缓存相关的HTTP头信息也应该包含,因为通常这种错误提示网页不应当被客户端缓存. HTTP/0.9 可用
504 Gateway Timeout (网关超时) 服务器作为网关且不能从上游服务器及时的得到响应返回给客户端. HTTP/1.1 可用
505 HTTP Version Not Supported (HTTP版本不受支持) 服务器不支持客户端发送的HTTP请求中所使用的HTTP协议版本. HTTP/1.1 可用

状态码	原因短语	代表含义	HTTP 版本
100	Continue (继续)	客户端应当继续发送请求.这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝.客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应.服务器必须在请求完成后向客户端发送一个最终响应.	HTTP/1.1 可用
101	Switching Protocol (切换协议)	服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。	HTTP/1.1 可用
200	OK (成功)	请求成功.成功的意义根据请求所使用的方法不同而不同.GET: 资源已被提取,并作为响应体传回客户端.HEAD: 实体头已作为响应头传回客户端POST: 经过服务器处理客户端传来的数据,适合的资源作为响应体传回客户端.TRACE: 服务器收到请求消息作为响应体传回客户端.PUT, DELETE, 和 OPTIONS 方法永远不会返回 200 状态码.	HTTP/0.9 可用
201	Created (已创建)	请求成功，而且有一个新的资源已经依据请求的需要而建立，通常这是 PUT 方法得到的响应码.	HTTP/0.9 可用
202	Accepted (已创建)	服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。:返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。	HTTP/0.9 可用
203	Non-Authoritative Information (未授权信息)	服务器已成功处理了请求,但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝,如果不是上述情况,使用200状态码才是最合适的.	HTTP/0.9 and 1.1
204	No Content (无内容)	该响应没有响应内容,只有响应头,响应头也可能是有用的.用户代理可以根据新的响应头来更新对应资源的缓存信息.	HTTP/0.9 可用
205	Reset Content (重置内容)	告诉用户代理去重置发送该请求的窗口的文档视图.	HTTP/1.1 可用
206	Partial Content (部分内容)	当客户端通过使用range头字段进行文件分段下载时使用该状态码	HTTP/1.1 可用
300	Multiple Choice (多种选择)	该请求有多种可能的响应,用户代理或者用户必须选择它们其中的一个.服务器没有任何标准可以遵循去代替用户来进行选择.	HTTP/1.0 and later
301	Moved Permanently (永久移动)	该状态码表示所请求的URI资源路径已经改变,新的URL会在响应的`Location`:头字段里找到.	HTTP/0.9 可用
302	Found (临时移动)	该状态码表示所请求的URI资源路径临时改变,并且还可能继续改变.因此客户端在以后访问时还得继续使用该URI.新的URL会在响应的`Location:`头字段里找到.	HTTP/0.9 可用
303	See Other (查看其他位置)	服务器发送该响应用来引导客户端使用GET方法访问另外一个URI.	HTTP/0.9 and 1.1
304	Not Modified (未修改)	告诉客户端,所请求的内容距离上次访问并没有变化. 客户端可以直接从浏览器缓存里获取该资源.	HTTP/0.9 可用
305	Use Proxy (使用代理)	所请求的资源必须统过代理才能访问到.由于安全原因,该状态码并未受到广泛支持.	HTTP/1.1 可用
306	unused (未使用)	这个状态码已经不再被使用,当初它被用在HTTP 1.1规范的旧版本中.	HTTP/1.1 可用
307	Temporary Redirect (临时重定向)	服务器发送该响应用来引导客户端使用相同的方法访问另外一个URI来获取想要获取的资源.新的URL会在响应的`Location:`头字段里找到.与302状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST).	HTTP/1.1 可用
308	Permanent Redirect (永久重定向)	所请求的资源将永久的位于另外一个URI上.新的URL会在响应的`Location:`头字段里找到.与301状态码有相同的语义,且前后两次访问必须使用相同的方法(GET POST).	HTTPbis (试验草案)
400	Bad Request (错误请求)	因发送的请求语法错误,服务器无法正常读取.	HTTP/0.9 可用
401	Unauthorized (未授权)	需要身份验证后才能获取所请求的内容,类似于403错误.不同点是.401错误后,只要正确输入帐号密码,验证即可通过.	HTTP/0.9 可用
402	Payment Required (需要付款)	该状态码被保留以供将来使用.创建此代码最初的目的是为数字支付系统而用,然而,到现在也没投入使用.	HTTP/0.9 and 1.1
403	Forbidden (禁止访问)	客户端没有权利访问所请求内容,服务器拒绝本次请求.	HTTP/0.9 可用
404	Not Found (未找到)	服务器找不到所请求的资源.由于经常发生此种情况,所以该状态码在上网时是非常常见的.	HTTP/0.9 可用
405	Method Not Allowed (不允许使用该方法)	该请求使用的方法被服务器端禁止使用,RFC2616中规定, `GET` 和 `HEAD` 方法不能被禁止.	HTTP/1.1 可用
406	Not Acceptable (无法接受)	在进行服务器驱动内容协商后,没有发现合适的内容传回给客户端.	HTTP/1.1 可用
407	Proxy Authentication Required (要求代理身份验证)	类似于状态码 401,不过需要通过代理才能进行验证.	HTTP/1.1 可用
408	Request Timeout (请求超时)	客户端没有在服务器预备等待的时间内完成一个请求的发送.这意味着服务器将会切断和客户端的连接. 在其他浏览器中,这种响应更常见一些, 例如Chrome 和 IE9, 目的是为了使用HTTP 预连机制加快浏览速度. 同时注意,一些服务器不发送此种响应就直接切断连接.	HTTP/1.1 可用
409	Conflict (冲突)	该请求与服务器的当前状态所冲突.	HTTP/1.1 可用
410	Gone (已失效)	所请求的资源已经被删除.	HTTP/1.1 可用
411	Length Required (需要内容长度头)	因服务器在本次请求中需要 `Content-Length` 头字段,而客户端没有发送.所以,服务器拒绝了该请求.	HTTP/1.1 可用
412	Precondition Failed (预处理失败)	服务器没能满足客户端在获取资源时在请求头字段中设置的先决条件.	HTTP/1.1 可用
413	Request Entity Too Large (请求实体过长)	请求实体大小超过服务器的设置的最大限制,服务器可能会关闭HTTP链接并返回`Retry-After` 头字段.	HTTP/1.1 可用
414	Request-URI Too Long (请求网址过长)	客户端请求所包含的URI地址太长,以至于服务器无法处理.	HTTP/1.1 可用
415	Unsupported Media Type (媒体类型不支持)	服务器不支持客户端所请求的媒体类型,因此拒绝该请求.	HTTP/1.1 可用
416	Requested Range Not Satisfiable (请求范围不合要求)	请求中包含的`Range`头字段无法被满足,通常是因为`Range`中的数字范围超出所请求资源的大小.	HTTP/1.1 可用
417	Expectation Failed (预期结果失败)	在请求头`Expect` 中指定的预期内容无法被服务器满足.	HTTP/1.1 可用
500	Internal Server Error (内部服务器错误)	服务器遇到未知的无法解决的问题.	HTTP/0.9 可用
501	Implemented (未实现)	服务器不支持该请求中使用的方法,比如`POST` 和 PUT.只有``GET 和 `HEAD` 是RFC2616规范中规定服务器必须实现的方法.	HTTP/0.9 可用
502	Bad Gateway (网关错误)	服务器作为网关且从上游服务器获取到了一个无效的HTTP响应.	HTTP/0.9 可用
503	Service Unavailable (服务不可用)	由于临时的服务器维护或者过载,服务器当前无法处理请求.这个状况是临时的,并且将在一段时间以后恢复.如果能够预计延迟时间,那么响应中可以包含一个`Retry-After:`头用以标明这个延迟时间.如果没有给出这个`Retry-After:`信息，那么客户端应当以处理500响应的方式处理它.同时,这种情况下,一个友好的用于解释服务器出现问题的页面应当被返回,并且,缓存相关的HTTP头信息也应该包含,因为通常这种错误提示网页不应当被客户端缓存.	HTTP/0.9 可用
504	Gateway Timeout (网关超时)	服务器作为网关且不能从上游服务器及时的得到响应返回给客户端.	HTTP/1.1 可用
505	HTTP Version Not Supported (HTTP版本不受支持)	服务器不支持客户端发送的HTTP请求中所使用的HTTP协议版本.	HTTP/1.1 可用

问题：刷新一次 qige.io 网站的页面同时进行抓包，你会发现不少的 304 代码的应答，这是所请求的对象没有更改的意思，让浏览器使用本地缓存的内容即可。那么服务器为什么会回答 304 应答而不是常见的 200 应答？

因为这样服务器不会返回源文件，也就是说你可以直接使用本地的缓存，会快速很多。

小结

使用wireshark抓包并分析，可以快速提升自身网络知识，在其中对问题的探寻可以逐步引人进入更深层次研究，但是这始终是认为规定的知识，所以我们的ip地址从ipv4会逐渐走向ipv6，但不论是什么，我们只要知道其核心理念，就一定能够理解他的构成，各网络分层的设计初衷。总体来说，wireshark是一个好用的工具，可以帮助我们对于协议的理解更进一步。