Это примерно так:
Когда пользователь посещает вашу веб-страницу, идентификатор сеанса устанавливается в файле cookie в браузере пользователя. Каждый раз, когда браузер отправляет запрос на сервер, он передает серверу файл cookie, содержащий идентификатор сеанса. Это позволяет серверу распознавать пользователя и связывать данные с ним по многостраничным запросам ( вы можете использовать сеансы без файлов cookie, если хотите ).
Сервер по умолчанию будет хранить эти данные в памяти. Однако если приложение работает на нескольких веб-серверах и обслуживает одного и того же пользователя, все они должны знать о данных сеанса пользователя. Таким образом, вы можете настроить свое приложение для хранения данных сеанса с помощью службы Windows «ASP.NET State Server», или вы можете сохранить данные в базе данных SQL (или вы можете написать свой собственный поставщик состояний сеансов и хранить данные где угодно ). Более того, хранение данных сеанса в памяти, очевидно, является плохим выбором, если вы беспокоитесь, что ваша машина может выйти из строя (что, очевидно, должно вас беспокоить).
Что касается «правильного и детального» использования сессий ASP.NET, то сказать сложно - это зависит от того, чего вы пытаетесь достичь.
Если вы можете помочь, вам следует хранить только небольшие объемы данных в сеансах, так как объединенные сеансы всех пользователей, посещающих ваш сайт, могут занимать довольно много места. Более того, если вы используете ASP.NET State Server или состояние сеанса SQL Server хранит данные, которые вы храните, необходимо сериализовать и десериализовать, что займет нетривиальное количество времени для данных нетривиального размера.
Если то, что вы планируете хранить, не является конфиденциальным, альтернативным подходом может быть сохранение данных в файле cookie. Таким образом, ваш сервер не будет беспокоиться о хранении данных вообще. Таким образом, вы торгуете памятью (или дисковым пространством или любым другим механизмом хранения, который вы выбираете) для пропускной способности, поскольку cookie теперь будет частью полезной нагрузки для каждого запроса.