B/S架構兩方面好處：客戶端使用統一的瀏覽器Browser；服務端基於統一的HTTP協議。
HTTP協議採用無狀態的短連接的通信方式，通常情況下一次請求就完成了一次數據交互，通常也對應一個業務邏輯，然後這次通信連接就斷開了。
如何發起一個請求
當一個用戶在瀏覽器裏輸入www.pingan.com這個URL時：
1.請求DNS把這個域名解析成對應的IP地址。
2.根據IP地址在互聯網上找到對應的服務器，向這個服務器發起一個get請求。
3.由這個服務器決定返回默認的數據資源給訪問的用戶。
在服務器端實際上還有很複雜的業務邏輯：
服務器可能有很多臺，到底指定哪臺服務器來處理請求，需要一個負載均衡設備來平均分配所有用戶的請求。
請求的數據是存儲在分佈式緩存中還是一個靜態文件中，或是在數據庫裏。
當數據返回瀏覽器時，瀏覽器解析數據發現還有一些靜態資源（如CSS、JS或者圖片）時又會發起另外的HTTP請求，而這些請求很可能會在CDN上，那麼CDN服務器上又會處理這個用戶的請求。
不管網絡架構如何變化，始終有一些固定不變的原則：
互聯網上所有資源都要用一個URL來表示。
必須基於HTTP協議與服務端交互。
數據展示必須在瀏覽器中進行。
如何發起一個HTTP請求和如何建立一個Socket連接區別不大，只不過outputStream.write寫的二進制字節數據格式要符合HTTP協議。
瀏覽器在建立Socket連接之前，必須根據地址欄裏輸入的URL的域名DNS解析出IP地址，再根據這個IP地址和默認80端口與遠程服務器建立socket連接，然後瀏覽器根據這個URL組裝成一個get類型的HTTP請求頭，通過outputStream.write發送到目標服務器，服務器等待inputStream.read返回數據，最後斷開這個連接。
不同瀏覽器在如何使用這個已經建立好的連接，以及根據什麼規則來管理連接，有各種不同的實現方法。
一句話：發起一個HTTP請求的過程就是建立一個socket通信的過程。
HTTP協議解析
要理解HTTP協議，最重要的就是要熟悉HTTP協議中的HTTP Header， HTTP Header控制着互聯網上成千上萬的用戶的數據的傳輸。
最關鍵的是，它控制着用戶瀏覽器的渲染行爲和服務器的執行邏輯。
常見的HTTP請求頭：
Accept-Charset: 用於指定客戶端接受的字符集
Accept-Encoding 指定可接受的內容編碼，如Accept-Encoding:gzip.defate
Accept-Language 指定一種自然語言，如Accept-Language;zh-cn
Host 用於指定被請求資源的Internet主機和端口號，如Host:www.pingan.com
User-Agent 客戶端將它的操作系統、瀏覽器和其他屬性告訴服務器
Connection 當前連接是否保持，如Connection:Keep-Alive
常見的HTTP響應頭：
Server 使用的服務器名稱，如Server.Apache/1.3.6(UNIX)
Content-Type 用來指明發送給接收者的實體正文的媒體類型，如Content-Type:text/html;charset=GBK
Content-Encoding 與請求報頭Accept-Encoding對應，告訴瀏覽器服務端採用的是什麼壓縮編碼
Content-Language 描述了資源所用的自然語言，與Accept-Language對應
Content-Length 指明實體正文的長度，用以字節方式存儲的十進制數字來表示
Keep-Alive 保持連接的時間，如Keep-Alive:timeout
常見的HTTP狀態碼
200 客戶端請求成功
302 臨時跳轉，跳轉的地址通過Location指定
400 客戶端請求有語法錯誤，不能被服務器識別
403 服務器收到請求，但是拒絕提供服務
404 請求的資源不在
500 服務器發生不可預期的錯誤
瀏覽器緩存機制
在我們瀏覽一個頁面時發現有異常的情況下，通常考慮是不是瀏覽器做了緩存，一般的做法是按Ctrl+F5重新請求一次，重新請求的頁面肯定是最新的頁面。
原因： 在瀏覽器端，如果是按Ctrl+F5組合鍵刷新頁面，瀏覽器會直接向目標URL發送請求，而不是使用瀏覽器緩存的數據。
其次，即使請求發送到服務端，也有可能訪問到的是緩存的數據，比如，在我們的應用服務器的前端部署一個緩存服務器，如Varnish代理，那麼Varnish也可能直接使用緩存數據。
所以爲了保證用戶能夠看到最新的數據，必須通過HTTP協議來控制。
當我們在使用CTRL + F5組合鍵刷新一個頁面時，在HTTP的請求頭中會增加一些請求頭，告訴服務器我們要獲取最新的數據而不是緩存。Cache-Control,Pragma,Expires,Last-Modified,Etag
DNS域名解析
當用戶在瀏覽器中輸入域名並按下回車鍵後：
1.瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，如果緩存中有，這個解析過程就將結束。瀏覽器緩存是受這個域名的失效時間和緩存的空間大小控制的。
2.如果用戶的瀏覽器緩存中沒有，瀏覽器會查找操作系統緩存中的是否有這個域名對應的DNS解析結果。
操作系統會有一個域名解析的過程，在WINDOWS中可以通過C:\Windows\System32\drivers\etc\hosts文件來設置。可以將任何域名解析到任何可以訪問的IP地址。如果在這個文件中指定了一個域名對應的IP地址，那麼瀏覽器會首先使用這個IP地址。在linux中這個配置文件是/etc/hosts，修改這個文件可以達到同樣的目的。
3.在我們的網絡配置中都會有“DNS服務器地址”，這個地址就用於解決前面所說的如果兩個過程無法解析時要怎麼辦，操作系統會把這個域名發送給這裏設置的LDNS，也就是本地區的域名服務器。這個DNS通常都提供給你本地互聯網接入的一個DNS解析服務。這個專門的域名解析服務器性能都會很好，它們一般都會緩存域名解析結果，當然緩存時間是受域名的失效時間控制的，一般緩存空間不是影響域名失效的主要因素。大約80%的域名解析都到這裏就已經完成了，所以LDNS主要承擔了域名的解析工作。
4.如果LDNS仍然沒有命中，就直接到Root Server域名服務器請求解析
5.根域名服務器返回給本地域名服務器一個所查詢的域的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com，.cn、.org等。全球只有13臺左右。
6.本地域名服務器（Local DNS Server）再向上一步返回的gTLD服務器發送請求。
7.接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server通常就是你註冊的域名服務器，例如你在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成
8.Name Server域名服務器會查詢存儲的域名和IP的映射關係表，正常情況下都根據域名得到目標IP記錄，連同一個TTL值返回給DNS Server域名服務器。
9.返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間由TTL值控制。
10.把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束。
在實際的DNS解析過程中，可能還不止這10個步驟，如Name Server也可能有多級，或者有一個GTM來負載均衡控制，這都有可能會影響域名解析的過程。
DNS域名解析後會緩存解析結果，其中主要在兩個地方緩存結果，一個是Local DNS Server，另外一個是用戶的本地機器。這兩個緩存都是TTL值和本機緩存大小控制的，但是最大緩存時間是TTL值，基本上Local DNS Server 的緩存時間就是TTL控制的，很難人工介入，但是我們的本機緩存可以通過如下方式清除：
Windows在命令行模式下執行ipconfig/flushdns命令來刷新緩存
Linux下可以通過/etc/init.d/nscd restart來清除緩存。
重啓依然是解決很多問題的第一選擇。
在java應用中JVM也會緩存DNS的解析結果，這個緩存是在InetAddress類中完成的，有兩種緩存策略：一種是正確解析結果緩存，另一種是失敗的解析結果緩存。這兩個緩存時間由兩個配置項控制，配置項是在%JAVA_HOME%\lib\security\java.security文件中配置的。兩個配置項分別是networkaddress.cache.ttl和networkaddress.cache.negative.ttl，他們的默認值分別是-1（永不失效）和10（緩存10秒）。修改這兩個值的幾種方式：直接修改java.security文件中的默認值、在java的啓動參數中增加-Dsun.net.inetaddr.ttl=xxx來修改默認值、通過InetAddress類動態修改。
如果我們需要用InetAddress類解析域名時，一定要是單例模式，不然會有嚴重的性能問題，如果每次都創建InetAddress實例，每次都要進行一次完整的域名解析，非常耗時。
幾種域名解析方式：
域名解析記錄主要分爲：
A記錄，A代表的是Address，用來指定域名對應的IP地址，如將item.pingan.com指定到115.238.23.241，將switch.pingan.com指定到121.14.24.241。A記錄可以將多個域名解析到一個IP地址，但是不能將一個域名解析到多個IP地址。
MX記錄，表示的是Mail Exchange，就是可以將某個域名下的郵件服務器指向自己的Mail Server，如pingan.com域名的A記錄IP地址是115.238.25.245，如果MX記錄設置爲115.238.25.246所在的服務器，而正常通過Web請求的話仍然解析到A記錄的IP地址。
CNAME記錄，全稱是Canonical Name(別名解析)。所謂的別名解析就是可以爲一個域名設置一個或者多個別名。如將pingan.com解析到sunk.net，，將srcfan.com也解析到到sunk.net。其中sunk.net分別是pingan.com和srcfan.com的別名。
NS記錄，爲某個域名指定DNS解析服務器，也就是這個域名有指定 的IP地址去解析。
TXT記錄，爲某個主機名或域名設置說明。
CDN工作機制
CDN即內容分佈網絡（Content Delivery Network）,它是構築在現有Internet上的一種先進的流量分配網絡。其目的是通過現有的Internet中增加一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡“邊緣”，使用戶可以就近取得所需的內容，提高用戶訪問網站的響應速度。有別於鏡像，它比鏡像更智能，可以這樣做一個比喻：CDN=鏡像（Mirror） + 緩存（cache） + 整體負載均衡（GSLB），因而，CDN可以明顯提高Internet中信息流動的效率。
目前CDN都以緩存網站中的靜態數據爲主，如CSS、JS、圖片和靜態網頁等數據。用戶在從主站服務器請求到動態內容後再從CDN上下載這些靜態數據，從而加速網頁數據內容的下載速度，如淘寶有90%以上的數據都是由CDN來提供的。
通常來說CDN要達到以下幾個目標：
可擴展(Scalability)。性能可擴展性：應對新增的大量數據、用戶和事務的擴展能力；成本可擴展性：用低廉的運營成本提供動態的服務能力和高質量的內容分發。
安全性(Security)。強調提供物理設備、網絡、軟件、數據和服務過程的安全性，（趨勢）減少因爲DDoS攻擊或者其他惡意行爲造成商業網站的業務終端。
可靠性、響應性和執行（Reliability、Responsiveness和Performance）。服務可用性，能夠處理可能的故障和用戶體驗的下降，通過負載均衡及時提供網絡的容錯機制。
CDN架構
一個用戶訪問某個靜態文件（如CSS），這個靜態文件的域名假如是cdn.pingan.com，那麼首先要向Local DNS服務器發起請求，一般經過迭代解析後回到這個域名的註冊服務器去解析，一般每個公司都會有一個DNS解析服務器。這時這個DNS解析服務器通常會把它重新CNAME解析到另外一個域名，而這個域名最終會被指向CDN全局中的DNS負載均衡服務器，再由這個GTM來最終分配是哪個地方的訪問用戶，返回給離這個訪問用戶最近的CDN節點。
拿到DNS解析結果，用戶就直接去這個CDN節點訪問這個靜態文件了，如果這個節點中請求的文件不存在，就會再回到源站去獲取這個文件，然後再返回給用戶。
負載均衡（Load Balance）
負載均衡就是對工作任務進行平衡、分攤到多個操作單元上執行，如圖片服務器、應用服務器等，共同完成工作任務。它可以提高服務器響應速度及利用效率，避免軟件
或者硬件模塊出現單點失效，解決網絡擁塞問題，實現地理位置無關性，爲用戶提供較一致的訪問質量。
三種負載均衡架構：
鏈路負載均衡
鏈路負載均衡也就是前面提到的通過DNS解析成不同的IP，然後用戶根據這個IP來訪問不同的目標服務器
負載均衡是由DNS的解析來完成的，用戶最終訪問哪個Web Server是由DNS Server來控制的，在這裏就是由Global DNS Server來動態解析域名服務。這種DNS解析的優點是用戶會直接訪問目標服務器，而不需要經過其他的代理服務器，通常訪問速度會更快。但是也有缺點，由於DNS在用戶本地和Local DNS Server都有緩存，一旦某臺Web Server掛掉，那麼很難及時更新用戶的域名解析結構。如果用戶的域名沒有及時更新，那麼用戶將無法訪問這個域名，帶來的後果非常嚴重。
集羣負載均衡
硬件負載均衡：
硬件負載均衡的關鍵就是這是價格非常昂貴的設備，如F5,通常爲了安全需要一主一備。它的優點很顯然就是性能非常好，缺點就是非常貴，一般公司用不起的，還有就是當訪問量陡然增大超出服務極限時，不能進行動態擴容。
軟件負載均衡：
軟件負載均衡是使用最普遍的一種負載方式，它的特點是使用成本非常低，直接使用廉價的PC就可以搭建。缺點是一般一次訪問請求要經過多次代理服務器，會增加網絡延時。
操作系統負載均衡
就是利用操作系統級別的軟中斷或者硬件中斷來達到負載均衡，如可以設置多隊列網卡等來實現
