Fiddler 不但可以抓包 ， 还可以修改包，也可以像 JMeter 、Postman 和 RestClient 等工具一样直接发送 HTTP 请求。Fiddler 可以使用重放功能或者 FiddlerComposer 来发送 HTTP 请求。
可以用来做性能测试。
15.1 Fiddler Composer 发送 HTTP 请求
Fiddler 有个功能组件叫 Composer ， 可 以用来发送 HTTP 请求。 Fiddler 的作者把 HTTP Request 发送器取名为 Composer。
15.1.1 Composer 发送 Get 请求
启动 Fiddler 找到 Composer 选项卡，手动写一个 HTTP 请求，发送一个 Get 的 HTTP 请求。
1 | GET http://www.cnblogs.com/TankXiao/p/7087990.html HTTP/1.1 |
Composer 发送 HTTP 请求的界面
15.1.2 Composer 的编辑模式
Composer 有两种编辑模式，具体如下。
Parsed 模式。这个模式比较常用，把 HTTP 请求分为 3 个部分：请求起始行、请求 Header 和请求 Body。通过该模式，创建一个 HTTP 请求变得很容易。
Raw 模式。该模式需要一行一行地写一个 HTTP 请求。
15.1.3 Composer 发送 Post 请求
禅道的演示网站是 http://demo.zentao.net，用户名是 demo ，密码是 123456 ，我们来用 Fiddler 发送一个登录的 Post 请求
1 | POST https://demo.zentao.net/user-login.html HTTP/1.1 |
Composer 发送 Post HTTP 请求。
【备注】目前无法使用上述方法进行登陆，猜测是使用了 verifyRand 字段，导致每次登陆只有一次有效性（即该数字不能被重复使用）
15.1.4 Composer 编辑之前捕获的 HTTP 请求
在 Web 会话列表中，可以将捕获到的 HTTP 请求拖曳到 Composer 中，编辑后再发送出去。
15.2 Fiddler 重新发送 HTTP 请求
Fiddler 可以将捕获的 HTTP 请求重新发送出去。Fiddler 工具栏上有一个 Replay 按钮，单击该按钮可以向 Web 服务器重新发送选中的 HTTP 请求 。当选中多个 Session,并且按下 Replay 按钮后，Fiddler 会用多线程同时发送请求。此功能可以用来做并发的性能测试。
15.2.1 Replay 菜单
按下 Shift 键的同时单击该按钮，会弹出提示框，要求指定每个请求被重新发送的次数。
按下 CTRL 键的同时单击该按钮，在 HTTP 请求中不会包含 IF-Modified-Since 和 If-None-Match。
在会话列表中，选中一个或者多个的 Session，右键菜单我们可以看到一个 Replay 菜单。
Replay 菜单的详细说明：
15.2.2 简单的性能测试
在 Web Sessions 列表中，选中 一个或者多个 Session，然后按下 Shhift 键的同时单击“ Replay＂按钮，会弹出提示框，要求指定每个请求被重新发送的次数。Fiddler 会用多线程同时发送该请求，相当于模拟了很多用户同时访问该请求。
15.2.3 先编辑再发送
在 Web Sessions 列表中，选中一个 Session，单击鼠标右键选择 Replay -> Reissue and Edit，快捷键是 E。该功能可以把一个 HTTP 请求重新发送出去，并且拦截住，将其进行编辑，然后再发出去。
15.3 安全测试之重放攻击
Web 安全中，有一种安全测试叫作重放攻击 。重放攻击（ Replay Attacks ）又称重播攻击、回放攻击。软件开发人员和测试人员都需要理解重放攻击的原理，井且防范这种攻击。攻击者发送一个目的主机己接收过的包，特别是在认证的过程中，用于认证用户身份所接收的包，来达到欺骗系统的目的。该包主要用于身份认证过程，破坏认证的安全性。
15.3.1 重放政击是怎么发生的
重放攻击是指黑客通过抓包的方式，得到客户端的请求数据及请求连接，重复地向服务器发送请求的行为。
15.3.2 重放攻击的危害
比如 APP 中有一个“下单”的操作，当你单击购买按钮时，APP 向服务器发送购买的请求。而这时黑客对你的请求进行了抓包，得到了你的传输数据。因为你填写的都是真实有效的数据，是可以购买成功的，因此黑客不用做任何改变，直接把你的数据再往服务器提交一次就行了。这就导致了你可能只想购买一个产品， 结果由于黑客重放攻击，你就购买了多次。如果是用户操作的话，肯定会感到莫名其妙：怎么购买了那么多同样的产品 ，我只买了一个啊？所 以 ，重放攻击的危害还是挺大的，特别是涉及金钱交易时。因此防止重放攻击在电商项目中是必不可少的。
很多网站的投票或者点赞功能也要防止重放。黑客会对投票或者点赞进行抓包，然后重复发送来进行刷票。
15.3.3 重放攻击的解决方案
在 HTTP 请求中添加时间戳（ stamp ）和数字签名（ sign ），可以防止重放攻击。也就是说每次发送请求时需要多传两个参数，分别为 stamp 和 sign。比如：原先的请求为 http://www.669.icu，修改之后的请求为 https://www.tankxiao/apilbuypro?stamp=1403151835&sign=45f36r46b8df298ad65c9f9241eccd。
数字签名是为了确保请求的有效性 。 因为签名是经过加密的，只有客户端和服务器知道加密方式及 Key ，第三方模拟不了。 我们通过对 sign 进行验证来判断请求的有效性，如果 sign 验证失败则判定为无效的请求，反之有效。但是数字签名并不能阻止重放攻击，因为黑客可以抓取你的 stamp 和 sign （不需做任何修改），然后发送请求。这个时候就要对时间戳进行验证 。
时间戳是为了确保请求的时效性。 我们将上一次请求的时间戳进行存储，在下一次请求时，将两次时间戳进行比对 。 如果此次请求的时间戳和上次的相同或小于上一次的时间戳，则判定此请求为过时请求，无效 。 因为正常情况下，第二次请求的时间肯定是比上一次的时间大的，不可能相等或小于 。
有人会问，我直接用时间戳不就行了，为什么还要数字签名？因为黑客可能对请求进行抓包，然后修改时间戳为有效的时间戳值 。 我们的数字签名采用 stamp+key 进行组合加密，即使黑客修改了 stamp ，但是由于黑客不知道 key ，所以 sign 验证这步就成功地阻止了黑客的请求。
15.3.4 APP 验证码重放
很多 APP 都有注册功能，一般用手机号码注册 。 注册时需要给手机号码发送一个验证码，这个获取验证码的操作应该防范重放攻击。
【实例】：
- 在手机上打开一个 APP，打开注册页面，启动 Fiddler，配置好 Fiddler 手机抓包
- 在 App 中输入手机号码，并且单击获取验证码按钮
- 在 Fiddler 中，找到能捕获获取验证码的 HTTP 请求
- 在 Fiddler 中重放这个请求，选中这个 HTTP 请求，利用 Fiddler 的重放功能可以再次发送验证码，甚至可以修改手机号码再发送 。这样做会给 APP 带来很大的损失 。
15.4 查找和登录相关的 Cookie
任何一个网站，都会有一个 Cookie 是用来维护登录的，如果浏览器发送的请求没有这个 Cookie，Web 服务器就会返回 302 状态码，让浏览器跳转到登录页面 。
【演示】如何使用 Fiddler 的重放功能来查找维护登录的 Cookie？
- 打开浏览器，访问百度网页，并且登录账号
- 打开“ http://i.baidu.com”，这个页面只有登录状态下才能打开
- 启动 Fiddler，再一次打开“ http://i.baidu.com ”。我们能用 Fiddler 捕获到浏览器访问“http://i.baidu.com“的包。从 HTTP 请求中，我们可以看到浏览器发送了很多个 Cookie。
- 在 Web 会话列表中，选择“http://i.baidu.com”这个会话，右键单击，选择 Replay -> Reissue and Edit 或者用快捷键 E，这个时候发出去的 HTTP 请求处于可以编辑的状态，删除一个 Cookie，然后单击“ Run to Completion ＂再发出去。
- 删除这个 Cookie 后，检查 HTTP 响应，发现还是处于登录状态，说明删除的那个 Cookie 跟登录没有关系
- 删除一个名为 BDUSS 的 Cookie，然后再发出去。
- 检查 HTTP 响应，可以看到返回的是 302 状态码，说明这个 Cookie 是跟登录相关的
参考
《HTTP 抓包实战》