- 討論今天這個問題之前，我們先來看下瀏覽器公布的資源並發數限制個數，如下圖
不難看出，目前主流瀏覽器支持都是最多6個並發
需要注意的是，瀏覽器的並發請求數目限制是針對同一域名的
意即，同一時間針對同一域名下的請求有一定數量限制。超過限制數目的請求會被阻塞，這就是很多網站專門解決這個問題的原因。
有的請求會持續很長時間，如果把 img, css, js… 都放到http://一個域名下面，其他請求就遲遲無法完成，瀏覽者看來就是『卡住了』。而把圖片放到另一個域名之后，css和圖片就可以並發請求了。
瀏覽器並發請求就簡單說到這里，原文地址：https://www.zhihu.com/question/20474326
- 下面步入正題，在開發中我遇到一個和奇怪的問題，就是我們接入SSO之后,發現並發請求反而更慢，如圖
前面是接入sso之后，后面是沒接入sso的情況
后來，找sso那邊的同事查問題，他給我發了一個地址 https://blog.csdn.net/littlewrong/article/details/48134535
以下為問題的原因
問：為了可以順序訪問Session的狀態值，Session是否提供了鎖定機制？
答：Session實現了Reader/Writer的鎖機制：
當頁面對Session具有可寫功能（即頁面有<%@Page EnableSessionState="True" %>標記），此時直到請求完成該頁面的Session持有一個寫鎖定。
當頁面對Session具有只讀功能（即頁面有<%@Page EnableSessionState="ReadOnly" %>標記），此時知道請求完成該頁面的Session持有一個讀鎖定。
讀鎖定將阻塞一個寫鎖定；讀鎖定不會阻塞讀鎖定；寫鎖定將阻塞所有的讀寫鎖定。這就是為什么兩個框架中的同一個頁面都去寫同一個Session時，其中一個要等待另一個（稍快的那個）完成后，才開始寫。
“寫鎖定將阻塞所有的讀寫鎖定”，也就是說頁面在EnableSessionState="True"的情況下沒返回輸出時，一直持着Session寫操作，其他頁面對Session的讀操作必須等待，而asp.net的aspx頁面默認是EnableSessionState="True"，每個頁面從請求開始至返回一直持着Session寫操作，需驗證頁面必須讀取Session值判斷，這就是為什么需驗證的頁面請求被阻塞的原因。只要耗時頁面（A頁面）沒有Session的寫操作，也就不會阻塞其他頁面的請求，於是修改A頁面的EnableSessionState="ReadOnly"，例如：<%@ Page Language="C#" AutoEventWireup="true"CodeFile="TBS_Monitor_List.aspx.cs"EnableSessionState="ReadOnly" Inherits="TBS_Monitor_List" %> ，問題解決。
也就是說，在無需對session進行寫操作的頁面，加上EnableSessionState="ReadOnly"屬性，就不會造成Request阻塞的情況了。
這個是asp.net的解決方式，后來我又查了下MVC的解決方案，這里是隨意找的一篇：https://blog.csdn.net/paolei/article/details/38052129
具體解決方案就是在 controller上打個[SessionState(SessionStateBehavior.ReadOnly)] 的標簽，由於我的項目中沒有對session進行寫操作的地方，所有我在BaseController上打了標簽，最終的結果就是問題解決了，親測有效