在标准的spring mvc项目中，当对象数据已经产生时，不管是输出json，还是view,最终均是将相应的数据直接写入response的outputStream中。这里的输出是同步式调用的，即意味着只有当整个数据完整地写到输出流中时，整个业务线程才会被认为执行结束。
这就意味着在传统的基于请求的慢速攻击之外，还有一种基于响应的慢速攻击，其思路即是客户端强制让整个接收变慢，而服务端因为缓存区不足以存储完整的响应数据，而被动地阻塞调用端，进而阻塞业务线程。
在Servlet 3.0版本中，提出了业务中的异步处理，即 通过 HttpServletRequest#startAsync 来开启异步处理。等业务处理完成之后，才通过 AsyncContext#complete 来结束处理。在中间，可以仍然通过 HttpServletResponse#getOutputStream 来输出数据. 这里的异步处理仅仅是将容器的处理线程解放出来，即当业务处理需要长时间或者需要故意挂起请求(如LongPull)时，才有相应的意义。在最终输出数据时，这里仍然是阻塞的，只不过是阻塞业务线程(而非容器线程).造成的后果即是缓慢地IO操作造成线程阻塞。
随着 NIO 的出现，所有Web容器均使用了Nio来处理请求，即当整个请求已经完整读取完毕之后，才转交由具体的业务线程来处理，即在这里的io读取均为非阻塞读取，由很少数的线程就可以处理上百(千)个请求的网络请求. 在 Servlet 3.1 版本中， 规范中给出了 异步响应的概念，即可以通过响应式来达到异步非阻塞输出数据的效果. 从调用端来看，调用write之后即刻返回，并不会阻塞业务线程。后续未刷新到缓冲区的数据将在后续通过标准Nio流程由web容器的IO线程负责处理.
一个参考使用例子如下所示(参考于 https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/HTML5andServlet31/HTML5andServlet%203.1.html):
//开启异步
val context = request.startAsync();
val response = context.getResponse();
val servletOut = response.getOutputStream();
//定义响应监听器，以可写时输出相应的数据
val writeListener = new WriteListenerImpl(context, servletOut, actionQueue);
servletOut.setWriteListener(writeListener);
//一个参考的监听器实现
public class WriteListenerImpl implements WriteListener {
private ServletOutputStream output = null;
private Queue queue = null;
private AsyncContext context = null;
private boolean flag = false;
@Override
public void onWritePossible() throws IOException {
if (flag) {
return;
}
//这里仅当output.isReady() 时才会调用write方法，否则会报 IllegalStateException
while (queue.peek() != null && output.isReady()) {
val action = queue.poll();
doWrite(action);
}
}
private void doWrite(Action action) throws IOException {
//已完成标记位
if (action == Action.COMPLETE) {
flag = true;
}
action.run(context, servletOut);
}
}
继续阅读“使用 Servlet3.1 WriteListener进行异步响应输出以及踩过的坑” 