假设1枚炮弹击中目标的伤害为10，而4枚炮弹同时击中目标的伤害为200。现在我方只有一门火炮，4枚炮弹。此火炮每次只能发射一枚炮弹。问如何操作可以使其伤害达到200？
答案是”让子弹多飞一会儿”，不过这个回答不是来自姜文的电影，而是源于美军在二战中提出的 MRSI (Multiple Rounds Simultaneous Impact)技术，粗糙的翻译一下就是“发射多次却同时命中”。
我们知道炮弹飞行的时间取决于开炮时的发射仰角，比如仰角大于45度时，炮弹的飞行的长度和时间比仰角小于45度要长。那么我们就可以采用MRSI 技术，以从大到小的发射仰角，连续发射4次。这样第一次发射的炮弹飞行时间最长，最后一次发射的飞行时间最短。只要我们精确的计算好角度和发射的时间间隔，就有可能让4枚炮弹同时击中目标，从而造成200的伤害。
简而言之，就是利用炮弹的飞行时间差来弥补发射的间隔时间。
Ryan Rasti在Temporal Lensing and its Application in Pulsing Denial-of-Service Attacks一文中提出了一种利用网络延迟来增强DDoS攻击效果的方法。以DNS放大攻击为例。假设攻击者选择了两个DNS 服务器（A和B）来攻击目标， 已知A到目标的网络延迟为110毫秒，B到目标的网络延迟为40毫秒。而攻击者到A和B的延迟忽略不计。那么攻击者可以先给A发一个假冒的DNS请求，让A反射目标。略等70毫秒以后（110-40=70毫秒），攻击者再发给B请求，让B反射目标。这样，虽然攻击者的两个DNS请求不是同时发出的，但是反射出来的攻击消息却可以同时击中目标。如下图所示
这么做的好处是什么呢？当然是提高了DDoS的效率，攻击者的发报率是1包/70毫秒，而在某个时间点却有2个反射包击中目标。这相当于巧妙的利用了网络延迟而把所有的攻击包汇聚在某一个特定的时间点上。例子中只用到了2个DNS服务器，但是在实际攻击中，可以扩展到n个。攻击方式也不仅限于DNS放大攻击，用http 代理的CC攻击也可以。
优化过的DDoS步骤是
1.假设有n条线路（取决于具体的攻击方法，可能有n个DNS服务器，n个http代理等等），攻击者先测量出每条攻击路线的延迟， 对应记为 (L1,L2,…,Ln)。
2.从(L1,L2,…,Ln)中找出最大延迟，记为Lmax
3. 对于路线i（1≤ i ≤n），攻击者在发送前须等待 Lmax-Li
普通的DDoS是拼命打，有多少打多少。这样的结果是数据包击中最终目标的时间是平均分布的，如下图所示
而优化过的DDoS应该是这样的
然而为了成功的优化DDoS，我们还必须得解决一个首要问题，如何测量网络延迟。 对于HTTP CC类攻击来说比较简单，攻击者配制好代理，对攻击目标发一个http请求，接收http响应，就可以得到请求往返时间，然后用这个请求往返时间来估算网络延迟。当然，在实际情况中，网络延迟取决于很多因素，还需要用不同的方法降低噪音带来的影响，比如多次测量取平均值等等。
对于DNS放大攻击，一般用King测量法。比如攻击者(A)打算用DNS服务器D来攻击目标T。然而，直接测量 A经过D到T的网络延迟 （LADT）是很难的。但是，我们可以利用DNS递归查询的特性，测量出 A经过D到T的DNS服务器 的网络延迟（LADT(DNS)）。方法是让A对D发一个关于T域的DNS查询，在这种情况下D会向T的DNS服务器递归查询。从而该攻击者可以用此DNS请求往返时间来估算LAT(DNS)。一般来说, DNS服务器都在离其他服务器很近的地方，延迟差别可以忽略不计，因此LAT ≈ LAT(DNS) 。
比如攻击者打算利用google DNS （8.8.8.8）来攻击test.com的web 服务器。为了优化，攻击者需要先知道他到8.8.8.8再到test.com web服务器的延迟。怎么计算延迟呢？ 攻击者可以给8.8.8.8发送一个DNS查询：[随机子域].test.com 。由于8.8.8.8 并不负责test.com子域名，它只能递归询问test.com的DNS服务器。test.com的DNS服务器收到该询问以后，会进行本地记录查询。因为该子域是随机产生的，所以肯定会返回找不到啦，8.8.8.8收到回答以后，会再把这一回答继续转发给攻击者。这样攻击者就可以计算出他到8.8.8.8再到test.com DNS服务器的延迟。由于一般DNS服务器都在离WEB服务器很近的地方，因此可以推算出到8.8.8.8再到test.com web服务器的延迟。
为什么查询的时候要使用随机子域呢？是为了防止查询结果被cache缓存。如果查询结果被缓存了，那么DNS服务器就不递归查询了，从而导致测量结果不准确。
![教你如何突破IE安全限制获取iframe子框架内的本地cookie（图）]("/Article/UploadFiles/200809/20080902083122466.jpg)
