A．   request Dispatcher.forward() 是容器中控制权的转向 ，在客户端浏览器地址栏中不会显示出转向后的地址；

B．   response.sendRedirect() 则是完全的跳转 ，浏览器将会得到跳转的地址，并重新发送请求链接。这样，从浏览器的地址栏中可以看到跳转后的链接地址。
前者更加高效；

C．   在前者可以满足需要时，尽量使用RequestDispatcher.forward()方法 . 在有些情况下，比如，需要跳转到一个其它服务器上的资源，则必须使用HttpServletResponse.sendRequest()方法。


由于response是jsp页面中的隐含对象，故在jsp页面中可以用response.sendRedirect()直接实现重定位。
　　注意：
　　 (1).使用response.sendRedirect时，前面不能有HTML输出。
这并不是绝对的，不能有HTML输出其实是指不能有HTML被送到了浏览器。事实上现在的server都有cache机制，一般在8K（我是说JSP　SERVER），这就意味着，除非你关闭了cache，或者你使用了out.flush()强制刷新，那么在使用sendRedirect之前，有少量的HTML输出也是允许的。
　　 (2).response.sendRedirect之后，应该紧跟一句return;
　　我们已经知道response.sendRedirect是通过浏览器来做转向的，所以只有在页面处理完成后，才会有实际的动作。既然你已经要做转向了，那么后的输出还有什么意义呢？而且有可能会因为后面的输出导致转向失败。
　　补充
　　 1.RequestDispatcher.forward()
　　是在服务器端起作用,当使用forward()时,Servlet engine传递HTTP请求从当前的Servlet or JSP到另外一个Servlet,JSP 或普通HTML文件,也即你的form提交至a.jsp,在a.jsp用到了forward()重定向至b.jsp,此时form提交的所有信息在b.jsp都可以获得,参数自动传递.
　　但forward()无法重定向至有frame的jsp文件,可以重定向至有frame的html文件,同时forward()无法在后面带参数传递,比如servlet?name=frank,这样不行,可以程序内通过response.setAttribute("name",name)来传至下一个页面.
　　重定向后浏览器地址栏URL不变.
　　例:在servlet中进行重定向
public void doPost(HttpServletRequest request,HttpServletResponse response)
throws ServletException,IOException
{
　 response.setContentType("text/html; charset=gb2312");
　 ServletContext sc = getServletContext();
　 RequestDispatcher rd = null;
　 rd = sc.getRequestDispatcher("/index.jsp"); //定向的页面
　 rd.forward(request, response);
}
　　通常在servlet中使用，不在jsp中使用。
　　 2.response.sendRedirect()
　　是在用户的浏览器端工作,sendRedirect()可以带参数传递,比如servlet?name=frank传至下个页面,同时它可以重定向至不同的主机上,sendRedirect()可以重定向有frame.的jsp文件.
　　重定向后在浏览器地址栏上会出现重定向页面的URL

使用Response Buffering

　　通过打开“response buffering”可以缓冲一个值得输出的整个页面内容，这将最小化输出到浏览器的数据量，从而提高了整体性能。每一次输出都耗费许多，所以写得越少，效果越好。TCP/IP在发送少量大的数据包时，要比发送大量小的数据包工作效率高，因为它是慢速启动并不断发送的。

　　有2种方法打开Response Buffering。首先，可以使用Internet Services Manager为整个应用程序打开response buffering，这是推荐的方式，而且在IIS4.0和IIS5.0中，默认状态下，response buffering是打开的。其次，在每一页面上，可以在头部放置如下代码开打开response buffering：

< % Response.Buffer = True % >

　　这段代码必须在任何数据输出到浏览器前被执行（就是说，在任何html内容显示前和在任何cookie被设置前）。通常情况下，为整个应用程序打开response buffering是很好的方案，这么做后就不用在每个页面头部设置如上的代码。

　　关于打开response buffering的一个通用问题是：用户必须要等待整个页面全部产生后，才能看到内容。对于一个长时间运行的页面来说，可以设置Response.Buffer=False关闭缓冲。然后，好的策略是利用Response.Flush方法，它将输出所有已被ASP描述的HTML内容到浏览器。比如，在描述了一个1，000行表格的100行后，ASP就可以使用Response.Flush来强迫输出这100行的内容到浏览器，这时用户就可以看到前100行数据，同时其余的行数据正在准备生成。

　　注意，关于上面的1，000行表格输出的例子，对于一些浏览器器来说，除非遇到< /table >标记，它们不会输出表格的任何内容。如果这样，可以将表格分割成许多含有少量行的多个表格，然后在每一个表格产生后，调用Response.Flush输出。新版的Internet Explorer在整个表格下载后才显示内容，并且，如果定义了表格的列宽度，生成表格的速度将特别快。

关于打开response buffering的另外一个问题是：当生成非常大的页面时，将消耗非常大的服务器内存


如果总结得不够全面，请各位发表自己的意见或经验。