InProc模式
优点：获取session状态的速度快，session状态直接存储在iis的进程中。
缺点：易丢失，经常需要重新登录
StateServer模式
优点：session状态单独存储在一个进程中，不会因为iis或者应用的重启而丢失状态
缺点：获取session状态的速度比InProc慢一些，毕竟是两个不同的进程。
MSDN解释：
StateServer 模式，此模式将会话状态存储在一个名为 ASP.NET 状态服务的单独进程中。这确保了在重新启动
Web 应用程序时会保留会话状态，并让会话状态可用于网络场中的多个 Web 服务器 .
根据这个解释，即表示stateserver是支持远程存储的，那我们继续看msdn的案例：
StateServer 模式的一种配置设置，其中会话状态存储在一个名为 SampleStateServer 的远程计算机上：
这个案例本身是没有问题的，但是我们在是实际的项目中往往会出现一些错误，其中一个很重要的原因在于，webconfig这样配置后，要是这段配置生效，那么我们还要确认两台电脑的AllowRemoteConnection是开启的。
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=SampleStateServer:42424"
cookieless="false"
timeout="20"/>
</system.web>
</configuration>
在开发的时候，对应用有一点修改，就会导致应用的重启，这时候如果使用InProc模式
，那么每次都需要重新登录,比较浪费时间.建议使用StateServer模式。并在iis里面设置超时时间长一些。
注:使用StateServer模式的时候
1、要开启“ASP.NET State Service”服务（设为“自动”）
2、如果stateConnectionString的值不是127.0.0.1或者localhost等代表本地地址的值，需要修改注册表：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\aspnet_state \Parameters 节点 → 将 AllowRemoteConnection 的键值设置成“1”（1 为允许远程电脑的连接，0 代表禁止）→ 设置 Port (端口号)
3、session中存储非序列化的对象，如果违反会抛出 无法序列化会话状态。在“StateServer”或“SQLServer”模式下，ASP.NET 将序列化会话状态对象，因此不允许使用无法序列化的对象或 MarshalByRef 对象。如果自定义会话状态存储在“Custom”模式下执行了类似的序列化，则适用同样的限制。这样的异常。如果向session存储自定义的对象，那么该对象的类上一定要加上[Serializable]注释。
来源
https://blog.csdn.net/qq_41261286/article/details/84844792?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522164991906016782092928537%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=164991906016782092928537&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~baidu_landing_v2~default-1-84844792.142^v8^pc_search_result_control_group,157^v4^new_style&utm_term=StateServer&spm=1018.2226.3001.4187