本文接上篇Fiddler介绍，开始讲fiddler如何使用之前，给大家讲讲http以及web方面的小知识，方便大家后面更好得理解fiddler使用。
目录
一、软件体系结构---B/S与C/S架构
1、B/S架构
2、C/S架构
二、HTTP基础知识
HTTP 基础知识
什么是http请求和响应?
http协议和web之间的本质
http请求和响应的基本原理
http请求报文 (request)基本结构
http响应报文 (Response)基本结构
Fiddler运行原理
一、软件体系结构---B/S与C/S架构
1、B/S架构
在了解Fiddler原理之前，需要先清楚我们web最基本的架构是什么，就是B/S架构, 它也是目前最常用的一种软件架构
B就是浏览器(Browsers)也就是客户端这边S就是服务器端(Server)也就是web服务器这边
我们平常的web服务、web项目、web应用都是运行在服务端的, 那么通过绑定ip地址+端口监听的形式来接收和处理一些前端也就是客户端发起的http请求, 从而客户端通过http协议和请求就可以获取到指定服务器上的页面 文件 资源、等等..
如图
举个例子
当你在浏览器地址栏上输入百度的地址之后，服务器端就会给你返回一个百度的html页面资源
B/S架构就是浏览器/服务器的一种交互模式，是Browser/Server的简称。并且这种架构的软件不需要在用户的电脑上安装任何客户端程序，只需要在用户的电脑上安装浏览器即可。用户仅仅使用浏览器通过web服务器和数据库做交互，交互的结果将会以html网页的形式显示在浏览器上。
2、C/S架构
除了我们现在常见的B/S架构，其实还有一种就是C/S架构，是客户端/服务端的一种交互模式，是Client/Server的简称。它是早期常用的一种软件架构，这种架构的软件需要在用户的电脑上安装客户端程序, 有兴趣的朋友可以自行了解，这里就不过多赘述了!
我们平常在进行软件开发时，通常会根据需求在两种基本架构中进行选择!
二、HTTP基础知识
学习Fiddler的时候,HTTP的知识点也是必不可少的, 所以这里必须要给大家简单的介绍一下HTTP的相关知识!
http中文意思为超文本传输协议 英文全称为Hyper Text Transfer Protocol
它是用于万维网服务器传输超文本到本地浏览器的一种传输协议
目的是保证客户端与服务端之间的通信
什么是http请求和响应?
http的工作方式为一个简单的客户端请求 与 服务端响应的应答过程
它指定了客户端发送给服务器什么样的消息形式以及得到什么样的消息响应
所有的www文件都必须遵循这个标准协议, 目的是提供一种发布和接收html页面的方法
举个例子
比如说 客户端（浏览器）向服务器提交一个http请求, 那么服务器又会向客户端这边返回响应信息。而这些响应信息包含关于客户端请求的状态信息以及客户端所需要的内容信息。
如图
http协议和web之间的本质
其实就是浏览器和服务器打交道的
客户端向服务器端发送Http请求,然后服务器端向客户端返回http响应!
http协议就是浏览器和服务器之间进行沟通的一种规范, 也就是以这个规范来向服务器发起请求, 服务器才会给客户端进行正确的响应, 所以http有的时候也可以理解为是一种 规范、规则、标准
http协议是属于应用层的协议,而且是基于TCP/IP协议的, 也就是说http通信发生在TCP/IP链接之上
通俗一点说http协议就是基于TCP的一种应用层协议 它不会关系数据传输的细节问题,也就是说你不用去关心它下层TCP的运行逻辑, 它的核心只在于用来规定客户端和服务端的数据传输格式
最早http是用来向客户端传输html文件内容,默认的端口80
扩展
有兴趣的朋友可以自行了解一下iso网络七层模型
通俗点说http，就是在请求和响应之后，服务器端立即关闭连接，并释放资源，这样既保证了资源可显示与可用性，也吸取了TCP协议的可靠性优点,但是缺点就无法跟踪用户的操作了,所以我们在后端开发的学习中才会接触一个东西叫session和cookie技术
所以你也可以理解为http是基于请求与响应的模式, 并且是无状态的应用层协议
http请求和响应的基本原理
任何一个http请求都只会分为两个部分: 一个请求报文另外一个是响应报文
请求报文是客户端按照一定的格式生成一段文本,然后发给我们的服务端, 而服务器接收到了这样一个请求报文就会解析里面的内容,然后做出回馈，也就是响应
响应报文也就是服务器端根据请求报文反馈给客户端的文本信息
http请求报文 (request)基本结构
http请求(request)也叫请求报文一个基本的http请求报文结构分为如下几点:
请求行:就是请求方式和协议,也就是说用于描述客户端的请求方式,例如post/get方式, 以及请求的资源名称和HTTP协议的版本号!若干个请求头: 这些也叫消息头告诉服务器发送的是什么数据类型，编码类型、请求的是哪台主机、以及客户端浏览器的一些系统环境等等， 这些消息头中有很多头部字段名和对应的值它的格式为name:value空白行请求正文内容
抓包了解一下
那么我们在学习http知识的时候 就可以先直接使用Fiddler来抓取一个http请求和http响应来先看看到底是什么东西!
这样也有助于一些新手来理解http!
我们可以通过Fiddler抓取网络数据包的手段，就可以看到一个基本的http请求结构都包含哪些信息!
例如一个GET方式的请求(Request)信息 如下:
GET https://www.baidu.com/?name=zhangsan HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9例如一个POST方式的请求(Request)信息 如下:
POST https://api.codelife.cc/stat/userHm HTTP/1.1
Host: api.codelife.cc
Connection: keep-alive
Content-Length: 48
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Google Chrome";v="100"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
sec-ch-ua-platform: "Windows"
version: 1.2.27
Origin: chrome-extension://mhloojimgilafopcmlcikiidgbbnelip
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9{"fp":"4c49c2fd79e1658546e4b8ad","tn":6}
怎么样 是不是看这一大堆脑壳都大了呢 ？ 哈哈哈不要着急，我们慢慢来学!😁😁😁
我们先来看一张请求(Request)图解
如图
然后我们来逐一拆解上图中的各个部分!
1.请求方式 (Request method)
我们常见的一些请求方式也就是POST/GET,当然还有其他的一些请求方式, 如下表:
| 请求方法 | 描述 |
|---|---|
GET | 请求资源 比如常见的就是输入一个URL去请求一个资源下来, 它也可以带上一定的参数一起请求 |
POST | 提交资源 比如说我们想把用户名和密码 提交到服务器去,这个时候用POST比较好 |
HEAD | 获取响应头 |
PUT | 替换资源 |
DELETE | 删除资源 |
OPTIONS | 允许客户端查看服务器的性能 |
TRACE | 显示服务器收到的请求 常见于测试和调试诊断! |
2.URL (Uniform Resource Locator)
URL中文名为统一资源定位符 英文全称Uniform Resource Locator ,
我们网络中的每一信息资源都有统一的且在网上唯一的地址!
URL具体由4部分组成：协议、主机、域名、端口、路径文件、[附加资源]
URL的一般语法格式为：
protocol :// hostname[:port] / path / [?query-parameters]
1.协议 (protocol)
协议有http、ftp、https、等...
2.主机名 (hostname) + 域名
主机名+域名 例如: www.xsphp.com
3.端口 (port)
端口是一个数字, 端口是可选的 省略时使用方案是服务器默认配置的端口
例如 80、8080、..
各种传输协议都有默认的端口号，如http协议的默认端口为80
如果URL地址省略端口，则使用默认端口号
注意：有时候出于安全或其他考虑，可以在服务器配置上对端口进行重新定义，也就是采用非标准端口号，那么此时，URL地址中就不能省略端口号这一项。
4.路径文件 (path)
由零或多个/符号隔开的字符串，一般用来表示主机上的一个目录或文件地址
例如: /tpl/index.php
5.查询参数 附加资源 (query-parameters)
这一项在URL中也是可选的 用于给动态网页如 PHP/JSP/ASP/ASP.NET等后端页面 传递参数的一种方式，并且如果是GET请求方法, 那么可有多个参数, 它们彼此用&符号隔开，每个参数的名和值用=符号隔开
语法格式: ?参数=值&参数2=值 以此类推!
例如: ?id=33&age=25&name=zhangsan
举个例子
一个比较常见的url地址， 如下:
https://www.xxxx.net/xxxx/xxxx/xxxx/100?num=1001.2014.3001.5501
3.请消息求头 (Request Header)
请求消息头也叫消息头告诉服务器发送的是什么数据类型，编码类型、请求的是哪台主机、以及客户端浏览器的一些系统环境 等等前面已经说过了, 并且请求头是可以由开发人员根据需求去进行自定义的
这些消息头中有很多头部字段名 和 对应的值它的格式为 name:value
我们常见的一些请求头如下表:
| 请求头 | 描述 |
|---|---|
Host | 主机IP地址或域名 |
User-Agent | 提交一些客户端相关信息，例如: 操作系统、浏览器等一些版本信息给服务器, 而这些信息可能会让服务器按照一定的规则给客户端返回兼容性比较好的信息! |
Accept | 指定客户端接收的信息类型，例如: image/jpg,text/html,application/json也就是可以让 客户端告诉服务器 之后客户端这一边想接收到什么样的数据格式 |
Accept-Charset | 告诉服务器等一会这边客户端需要接收的字符集编码格式， |
Accept-Encoding | 告诉服务器， 客户端这边可接受的内容压缩编码，例如gzip 可以在一定程度上节省流量! |
Accept-Language | 告诉服务器, 客户端可接受的语言，例如Accept-Language：zh-cn |
Authorization | 客户端提供给服务端进行权限认证的信息, 也就是要告诉服务器端一些认证的信息，服务器才能返回响应的数据! |
Cookie | 携带的COOKIE信息, 普通情况下，当一个用户登录成功，就会在本地保存一份cookie,下次请求就会直接带上这个cookie信息，也就是这个用户的相关信息 |
Referer | 当前文档的URL 也就是纪录下从哪个链接地址提交到服务器的 |
Content-Type | 向服务器提交内容的格式例如： Content-Type：application/x-www-form-urlencoded总而言之,就是告诉 服务器,客户端传递的内容属于什么格式 或 其他编码格式! |
Content-Length | 数据长度, 也就是客户端向服务器端提交内容的数据长度有多少字节! |
Cache-Control | 缓存机制，例如：Cache-Control:no-cache |
pragma | 防止页面被缓存，与Cache-Control:no-cache作用一样 |
我们可以用Fiddler截取一个请求头看看
如图
4.空行
空白行 也就是在消息头结束的下方，会存在一个空白行, 这是必须存在的, 是由HTTP标准规定的!
5.请求体
请求体它的出现是要根据请求的方式不同而不同, 也就是如果是POST那么就会以键与值的形式进行发送, 如果是GET请求那么这里就不会包含请求正文内容
http响应报文 (Response)基本结构
http响应(response)也叫响应报文
其实响应报文比请求报文更加简单, 你只要能够搞懂请求报文 那么响应报文就很容易搞懂!
http响应(response)的一个基本结构分为如下几点:
响应行响应头空白行响应体
我们可以通过Fiddler抓取网络数据包的手段，就可以看到一个基本的http响应结构都包含哪些信息!
举个例子
如果你还看不明白 那么我们先来看一张http响应(response)图解 你就会明白了!
然后我们来逐一拆解上图中的各个部分!
1.响应行
响应行也叫状态行， 上图中响应行内部其实包含了3个重要的信息部分:
HTTP协议的版本、HTTP状态码、HTTP的状态描述
1.HTTP协议的版本现目前都是HTTP/1.1 版本 这个没什么好说的!
2.HTTP状态码 可以用来表示网页服务器端给客户端返回的HTTP响应状态, 通常都是3位数字的代码, 而这些常见的状态码又可以分为几种提示类型: 🙂 如下表
| 类别状态码 | 描述 |
|---|---|
1xx | 这种类别的状态码 为提示消息类型 通常表示请求被服务器端成功接收 |
2xx | 这种类别的状态码 为成功消息类型通常表示请求被服务器端成功处理 |
3xx | 这种类别的状态码 为重定向类型通常表示被服务器端重新定义了请求方向,需要进一步的操作以完成请求 |
4xx | 这种类别的状态码 为客户端错误信息通常表示服务器告诉客户端的一些错误消息 |
5xx | 这种类别的状态码 为服务端错误信息通常表示告诉客户端 服务器这边出现的一些错误信息 |
3.HTTP的状态描述是紧跟在状态码后面的英文单词
每一种具体类别状态码+状态描述可以参考下表:
1xx: 提示消息类型
| 消息: | 状态描述 | 含义 |
|---|---|---|
| 100 | Continue | 服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。 |
| 101 | Switching Protocols | 服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。 |
2xx: 成功消息类型
| 消息: | 状态描述 | 含义 |
|---|---|---|
| 200 | OK | 请求成功（其后是对GET和POST请求的应答文档。） |
| 201 | Created | 请求被创建完成，同时新的资源被创建。 |
| 202 | Accepted | 供处理的请求已被接受，但是处理未完成。 |
| 203 | Non-authoritative Information | 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。 |
| 204 | No Content | 没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。 |
| 205 | Reset Content | 没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。 |
| 206 | Partial Content | 客户发送了一个带有Range头的GET请求，服务器完成了它。 |
3xx: 重定向类型
| 消息: | 状态描述 | 含义 |
|---|---|---|
| 300 | Multiple Choices | 多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。 |
| 301 | Moved Permanently | 所请求的页面已经转移至新的url, 说通俗一点表示请求的资源分配了url，以后就应该使用这个url |
| 302 | Found | 所请求的页面已经临时转移至新的url, 也就是说请求的资源临时分配了url，本次请求暂且使用这个url， 这里302与301的区别是，302表示临时性重定向，重定向的url还有可能还会改变。 |
| 303 | See Other | 表示请求的资源路径发生改变，请使用GET方法请求url。其实与302一样，但是明确指出让我们使用GET方法请求url |
| 304 | Not Modified | 未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。 |
| 305 | Use Proxy | 客户请求的文档应该通过Location头所指明的代理服务器提取。 |
| 306 | Unused | 此代码被用于前一版本。目前已不再使用，但是代码依然被保留。 |
| 307 | Temporary Redirect | 被请求的页面已经临时移至新的url。 |
4xx: 客户端错误信息
| 消息: | 状态描述 | 含义 |
|---|---|---|
| 400 | Bad Request | 服务器未能理解请求，通常为表示请求的报文中存在语法错误 ，比如: 提交json数据的时候，如果json格式有问题，接收端接收json，也会出现400 bad request |
| 401 | Unauthorized | 被请求的页面需要用户名和密码。 |
| 402 | Payment Required | 此代码尚无法使用。 |
| 403 | Forbidden | 对被请求页面的访问被禁止。 |
| 404 | Not Found | 服务器无法找到被请求的页面。 |
| 405 | Method Not Allowed | 请求中指定的方法不被允许, 请求的方式get、post、delete方法与后台规定的方式不符合 例如: 比如： 后台方法规定的请求方式只接受get，如果用post请求，就会出现 405 method not allowed的提示 |
| 406 | Not Acceptable | 服务器生成的响应无法被客户端所接受。 |
| 407 | Proxy Authentication Required | 用户必须首先使用代理服务器进行验证，这样请求才会被处理。 |
| 408 | Request Timeout | 请求超出了服务器的等待时间。 |
| 409 | Conflict | 由于冲突，请求无法被完成。 |
| 410 | Gone | 被请求的页面不可用。 |
| 411 | Length Required | "Content-Length" 未被定义。如果无此内容，服务器不会接受请求。 |
| 412 | Precondition Failed | 请求中的前提条件被服务器评估为失败。 |
| 413 | Request Entity Too Large | 由于所请求的实体的太大，服务器不会接受请求。 |
| 414 | Request-url Too Long | 由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。 |
| 415 | Unsupported Media Type | 由于媒介类型不被支持，服务器不会接受请求, 例如: 后台程序不支持提交的content-type类型，就会返回415 |
| 416 | 服务器不能满足客户在请求中指定的Range头。 | |
| 417 | Expectation Failed |
5xx: 服务器错误信息
| 消息: | 状态描述 | 含义 |
|---|---|---|
| 500 | Internal Server Error | 请求未完成。服务器遇到不可预知的情况。 |
| 501 | Not Implemented | 请求未完成。服务器不支持所请求的功能。 |
| 502 | Bad Gateway | 请求未完成。服务器从上游服务器收到一个无效的响应。 |
| 503 | Service Unavailable | 请求未完成。服务器临时过载或当机。 |
| 504 | Gateway Timeout | 网关超时。 |
| 505 | HTTP Version Not Supported | 服务器不支持请求中指明的HTTP协议版本。 |
2.响应头 (Response Header)
响应头也叫消息报头 也就是服务器端要告诉客户端的一些附加信息, 但是也有可能这些响应头是由后端开发人员进行自定义的!
而且这里的响应头跟请消头 很类似, 格式也基本一样, 它的格式为 name:value
具体我这里也列举了一些常见的响应头 如下表:
| 响应头 | 含义 |
|---|---|
Server | HTTP服务器的软件信息 |
Date | 响应报文的时间, 要注意返回时间的时区 |
Expiros | 服务器指定的一个缓存过期时间 |
Set-Cookie | 设置Cookie, 也就是服务器返回的一段文本给客户端,让客户端保存好,下次请求就把这个cookie文本带上! |
Last-Modified | 资源最后修改时间 ，也就是客户端有缓冲的文档并发出了一个条件性的请求, 服务器告诉客户，原来缓冲的文档还可以继续使用, 也就是说不用在从服务器中进行返回 |
Content-Type | 服务器返回给客户端的响应类型和编码字符集例如： Content-Type:text/html;charset=utf-8 |
Content-Length | 内容长度, 也就是服务器返回给客户端返回的内容是多少字节 |
Connection | 例如Keep-Alive，表示保持tcp链接不会关闭，当然它不会永久保持链接，我们在服务器端中是可以设置的 |
Location | 指明服务器给客户端重定向的位置，也就是新的URL地址 如:304的情况 |
| ...................................... |
还有更多的响应头这里就不一一列举了!
3.空白行
空白行也就是http规范制定的必须存在的一个空行, 空行的目的就是一种格式，也就是要告诉用户接下来的内容就是正文内容了!
4.响应体
响应体也就是实际从服务器返回给客户端的正文内容,也可能是一些字符串， 也可以是任意的格式:
响应体大多数情况下都是html、json、文本、xml 这些格式!
小结
对于http相关的的知识点 就说这么多了,对于学习fiddler足够了
接下来你就可以愉快的学习Fiddler了🤗
Fiddler运行原理
Fiddler的原理简单点说就是通过改写HTTP代理然后让网络数据从Fiddler这边通过 这样子来监控并且截取到网络信息数据。当你打开Fiddler的时候, 就已经设置好了浏览器的代理了。当你关闭的时候，它会自动的帮你把代理还原
之前也说过了 B/S架构就是客户端和服务器之间的 请求和响应, 刚刚我们也知道了Fiddler通过代理的形式来进行监听，它在请求和响应中起到一个什么样的角色呢?
这里还要清楚一点的就是 浏览器默认走的是我们的系统代理
其实这里的代理监听 就是在 请求和响应之间插了一脚, 让fiddler成为系统代理
在你安装好Fiddler之后启动，并可以打开菜单栏中的Tools--->options--->Connections
如下图
看到了吧,这里有一句Act as system proxy on startup意思就是(在启动时充当系统代理),并且默认监听端口设置为了8888
如图
这里以chrome浏览器为例:
只要fiddler一旦启动并开始监听的时候，就会默认成为系统代理, 所以你的网络请求 也就会被fiddler所抓取到!
如图
或者如下图一样Fiddler就是一个中间的proxy(代理服务器)
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ItS8dJ6N-1651910920350)(img/fiddler_3-3.png)]
当关闭fiddler的时候，手动设置代理选项就会被清空
所以我们才会说Fiddler是介于客户端和服务器中间的一个角色, 监控客户端和服务器所有通信的过程!
小结
Fiddler是以代理WEB服务器的形式工作的,浏览器与服务器之间通过建立TCP连接以HTTP协议进行通信，
浏览器默认通过自己发送HTTP请求到服务器，本地使用代理地址:127.0.0.1, 端口:8888.
而当Fiddler开启会自动设置系统代理， 退出的时候它会自动注销代理，这样就不会影响别的程序。
但是如果Fiddler非正常退出，这时可能会因为Fiddler没有自动注销，而会造成网页无法访问。
解决的办法是重新启动下Fiddler就可以了, 这也是有很多新手安装了Fiddler之后导致一些网络无法访问的原因之一!
