我已经对这个主题进行了搜索，并且一遍又一遍地找到相同的数据——回顾了三种不同类型的会话。（InProc，Sql，StateServer）但是，我的问题具有不同的性质。
具体来说，首先使用内置 .NET 会话的优点/缺点是什么？
这就是我要问的原因：一位 .NET 开发人员告诉我永远不要使用内置的 Microsoft Session。一点也不。甚至没有创建自定义会话状态提供程序。他对此的推理如下——如果您在 IIS 中打开了 Session，它会使您的所有请求同步发生。他说启用会话会降低 Web 服务器的性能。
他对此的解决方案是自己创建一个会话——一个存储您需要的所有值并在数据库内外序列化的类。他建议您存储唯一 ID 以在 cookie 或查询字符串变量中引用它。在我们的环境中，需要使用数据库来存储会话，因为我们制作的所有页面都在网络农场上，并且我们使用 Oracle——所以我同意这部分。
使用内置 Session 是否会比自制 Session 降低性能？这有什么安全问题吗？
所以总结一下，有什么优点/缺点？
感谢所有回答的人！
我的经验是，当您适当地使用会话时，会话是管理状态的好方法。然而，它经常被滥用，导致许多开发人员共享“从不使用会话”的情绪。
当我们错误地使用会话从数据库中存储大量数据以“节省行程”时，我和许多其他开发人员都遇到了重大的性能问题。这是不好的。当超过几个用户使用该应用程序时，每个会话存储 2000 条用户记录将使 Web 服务器瘫痪。会话不应用作数据库缓存。
但是，每个会话存储一个整数是完全可以接受的。表示当前用户如何使用您的应用程序（想想购物车）的少量数据是会话状态的一个很好的用途。
对我来说，这真的是关于管理状态。如果做得正确，那么会话可以成为管理状态的许多好方法之一。不过，应该在一开始就决定如何管理状态。大多数时候，当有人决定“在会话中扔东西”时，我们会遇到麻烦。
我发现这篇文章在使用进程外模式时非常有用，并且它包含一些我自己从未想过的技巧。例如，与其将类标记为可序列化，不如将其原始数据类型成员存储在单独的会话变量中，然后重新创建对象可以提高性能。
首先，您的同事正在实现他自己的数据库支持的会话管理系统，我看不出这比使用存储在数据库上的内置会话状态有什么优势（MS SQL 是默认设置，没有理由不使用 Oracle）。
他的解决方案是否比内置解决方案更好？不太可能。一开始对你来说工作量更大。这是一个简单的说明。假设您使用 cookie 来存储您的 ID，您如何应对关闭 cookie 的用户？如果您使用的是 ASP.Net 的会话状态，则没有问题，因为它将回退到使用查询字符串。有了你同事的想法，你必须自己动手。
关于您是否拥有会话状态，这是一个非常有效的问题。如果您可以将应用程序设计为根本不需要任何会话状态，那么您将更容易进行时间扩展和测试。显然，您可能具有无论如何都需要在会话之外存在的应用程序状态（简单的情况是用户名和密码），但是无论您是否具有会话状态，您都必须存储这些数据。
会话状态的 MS 实现本身并不邪恶……这就是一些开发人员使用它的方式。如上所述，使用内置会话状态提供程序意味着您不必重新发明安全性、老化和并发问题。只是不要开始在会话中塞入大量垃圾，因为您懒得想出更好的方法来管理状态和页面转换。会话不能很好地扩展......如果您网站上的每个用户都在会话中填充一堆对象，并且这些对象占用了您应用程序可用的有限内存的一小部分，那么您将很快遇到问题稍后随着您的应用程序越来越受欢迎。以设计的方式使用会话：表示用户仍在“使用”您的站点的标记。当你开始冒险超越它时，
您应该谨慎使用 Session，因为对同一 Session 对象的多个请求通常会排队：请参阅“并发请求和会话状态”http://msdn.microsoft.com/en-us/library/ms178581.aspx。
请注意，您可以设置EnableSessionState为ReadOnly允许对会话状态进行并发读取访问。
这种排队是一件好事，因为这意味着开发人员可以使用 Session 而不必担心同步。
我不同意你同事关于“从不”使用 Session 的建议，我当然不会考虑自己动手。
首先，浏览器在给定时间只会向给定主机名发出两个请求。在大多数情况下，这些请求是针对静态内容（JS 文件、CSS 等）的。因此，对动态内容的请求序列化几乎不是人们可能想到的问题。另外，我认为这可能与 Classic ASP 混淆，其中使用 Session 的页面肯定是序列化的，我不相信 ASP.Net 就是这种情况。
使用 ASP.Net 会话状态（SQL 模式、状态服务器或自定义），您拥有一个标准的实现，并且在整个应用程序中都是一致的。如果您不需要共享会话信息，这是您最好的选择。如果您需要与其他应用程序环境（php、swing/java、经典 asp 等）共享信息，则可能值得考虑。
另一个优点/缺点是，有很多开发人员专注于会话的内置方法，以提高性能，以及设计而不是滚动自己的方法，即使使用不同的提供者也是如此。
这有什么安全问题吗？
如果你自己动手，你将不得不处理 Session Fixation 和 Hijacking 攻击，而使用内置的 Session 我认为它们是为你处理的（但我可能是错的）。
正如您所描述的，自制会话没有做任何不同的.Net会话的“SQL”状态，根据我的经验，我认为会话无论如何都不会降低您的性能。构建您自己的会话管理器将需要同时执行其他几个管道任务 - 安全性、将其清除等。
内置会话的优点是它易于使用，所有这些管道都已经处理好了。使用“SQL”模式，您可以将会话数据保存在数据库中，从而允许您在网络农场上运行您的应用程序而不会出现任何问题。
我们为财富 57 强公司设计了一个 b2b 电子商务应用程序，该应用程序每天处理超过 10 万笔交易，并且非常广泛地使用会话 [SQL 模式]，完全没有任何问题。
如果我错了，请纠正我：
将会话状态存储在数据库（例如 SQL Server）中的主要优点是您不会消耗内存资源，而是将其存储到数据库中的磁盘中。
缺点是您每次需要时都会进行 IO 命中以从数据库中检索此信息（或者 SQL Sever 甚至可能根据最近执行的查询为您做一些神奇的数据缓存？）
无论如何，对于遇到大量流量的站点来说，每次访问 Web 服务器从数据库中检索会话信息的 IO 价格似乎是一种更安全的策略。