今天在做一个Web项目的最后部署工作的时候产生了一个问题，经过多次的试验，得出问题的关键就是出现在重定向方法的使用上，从而对这个问题进行了一下深入的研究。得出的结论应该已经有人说明过，我只是从应用的角度再来说明一下问题。呵呵，有点献丑的感觉。

问题的产生：
在这个Web项目的部署时，做了一个Frame,顶端是top,下边左边是menu,右边是main,工作区。此时，这个包含frame的页面是部署在A服务器上。
因为实际情况决定，通过menu的一个节点，在工作区请求了部署在B服务器上的一个页面(暂时叫做B1页面），这个B1页面是部署在B服务器上的一个查询系统的初始页面。在程序设计时，通过B1页面的一些选择，得到了一些条件，赋值给Session，然后重定向到结果页面B2，使用的方法是：Response.Redirect。在B2页面中，获得此Session，然后进行条件组合，得到结果列表。
问题就产生在由B1页面重定向到B2时，在B2页面中启动了报错机制，得出的结果是B2页面的Session为null值，所以报错。
此时的问题是：B服务器上的B1页面由A服务器上的menu页面请求获得，并仍然显示在A服务器Frame的工作区内，但B服务器上的B2页面无法获得B1页面形成的Session。

但是，当在A服务器上的menu页面上，新开一个窗口请求B1页面，然后形成Session，再重定向至B2页面，就没有此问题，B2页面能获得Session并列出结果。而且，在回到A服务器的Frame中请求B1页面，显示在A服务器Frame的工作区内B1到B2页面也是一切正常。

分析的结果就是，但在A服务器的Frame内请求时，B1页面形成的Session是存在于A服务器上，所以B2页面无法在B服务器上获得Session。而新开一个窗口请求B1页面，相当于在B服务器上来一个新的请求，所以B1页面形成的Session就存在于B服务器上，可以正常使用，而此时再返回在A服务器的Frame内请求时，因为B服务器上已经存在Session，所以此时在A服务器的Frame内，B1和B2页面又可以正常工作了。

到现在，问题原因已经分析出来了，但是没有解决问题，因为我要的是直接在A服务器的Frame内请求时就可以得到正确的结果。

因为分析是因为形成Session的位置不对，所以经过和同事的讨论，决定修改重定向方法，不用Response.Redirect，而使用Server.Transfer，结果一下就成功了，即使直接在A服务器的Frame内请求B1页面，也可以正确的在B2页面中得出结果了。此时，就得出了一个问题：Response.Redirect和Server.Transfer在服务器端的数据传输上有什么区别。

和同事讨论，都没有得出个所以然，然后在网上查找。得出的结果是：“雖然Server.Transfer和Response.Redirect都會轉向，但兩者之間仍有些不同：Response.Redirect是先由伺服器端將資料送到用戶端，用戶端再依照Redirect內容，向伺服器端要求轉向到另一個網頁，如此會增加一次用戶端與伺服器端來回通訊時間，而Server.Transfer則是在伺服器端直接轉向到另一個網頁。並且由於Server.Transfer轉向前後的網頁，仍屬同一應用程式，因此會將Session和Application的變數值帶到轉向後的URL位置，而Response.Redirect不會。”具体页面请看这里(微软的解释）。

看完后，我的理解是这样的：使用Response.Redirect方法时重定向操作发生在客户端，总共涉及到两次与服务器的通信，第一次是对原始页面的请求，第二次是声明的新页面，并重定向至新页面；而Server.Transfer方法在同一执行流中，从当前的ASPX文件直接转到同一服务器上的另一个ASPX页面，当前的ASPX页面终止执行，并转入新的ASPX页面，但新的ASPX页面仍使用前一ASPX页面创建的请求。

最后得出的结果就是：在同一个窗口中，请求的是同一台服务器上的页面时，Response.Redirect和Server.Transfer是没有太多的区别的；而在同一个窗口中，请求的是不同服务器上的页面时，为了保证页面的正常执行，推荐使用Server.Transfer这种重定向方法。当然要视具体的应用而定。