WEB架構發展
1.單機架構，所有應用內程序都在本機運行，所有的數據也都保存在本機上。表示層，應用層喝數據層位於統一主機上
2.工作站/服務器架構（W/S）在服務器上保存數據，在工作站上處理數據。數據層位於服務器端，應用層和表示層位於工作站。
3.客戶端/服務器架構（C/S）客戶機想服務器發出之靈，服務器上存儲喝處理數據，服務器完成數據處理將結果返回客戶機進行二次處理。數據層和應用位於服務器，表示層位於客戶端。
4.瀏覽器/服務器架構（B/S）霧浮起處理數據並生成頁面，客戶級上瀏覽請求頁面和顯示頁面
5.客戶端/應用服務器/數據服務器（C/S/S）在客戶端和和服務器之間加入中間層，即應用服務器。
6.Web瀏覽器/Web服務器/數據庫服務器（B/S/S）由Web瀏覽器、Web服務器、中間件、數據庫服務器組成，各組成部分之間物理上通過intranet或Internet相鏈接，軟件上遵守HTTP協議，瀏覽器通過發送請求和服務器端建立鏈接，從而實現整個Internet為背景的數據存儲和訪問。中間件是一個用API定義的軟件層，是具有清大通信能力和良好可擴展性的分布式軟件管理框架
7.四層體系結構，包括WEB瀏覽器、WEB服務器、應用服務器、數據庫服務器
從單機結構到四層結構或者多層結構，技術方面也從最初的瀏覽器展示，服務端控制，經歷前端組件化、后端為主
MVC時代、Ajax帶來的SPA時代（Single Page Application 單頁免應用）、前后端分離、前端為主的MV*時代。
隨着WEB架構的不斷發展API重要性逐漸提現出來，目前API 接口層已經在軟件開發過程中被獨立出來
OSI七層協議
應用層 文件傳輸，電子郵件，文件服務，虛擬終端 TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
表示層 數據格式化，代碼轉換，數據加密 沒有協議
會話層 解除或建立與別的接點的聯系 沒有協議
傳輸層 提供端對端的接口 TCP，UDP
網絡層 為數據包選擇路由 IP，ICMP，RIP，OSPF，BGP，IGMP
數據鏈路層 傳輸有地址的幀以及錯誤檢測功能 SLIP，CSLIP，PPP，ARP，RARP，MTU
物理層 以二進制數據形式在物理媒體上傳輸數據 ISO2110，IEEE802，IEEE802.2
應用層
傳輸層
網絡層
數據鏈路層
物理層
HTML是一種用來定義網頁的文本，超文本標記語言
HTTP是在網絡上傳輸HTML的協議，用於瀏覽器和服務器的通信
當網絡通信時采用TCP協議時，在真正的讀寫操作之前，客戶端與服務器端之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接時可以釋放這個連接。連接的建立依靠“三次握手”，而釋放則需要“四次握手”，所以每個連接的建立都是需要資源消耗和時間消耗的。
工作流程
1、客戶端與服務器建立連接；
2、建立連接后，客戶端發送一個請求給服務器；
3、服務器接到請求后，給予相應的響應信息；
4、客戶端接收服務器所返回的信息通過瀏覽器顯示，然后斷開連接。
URL：（Uniform Resource Locator）統一資源定位符，對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標准資源的地址。
HTTP使用統一資源標識符（URI）來傳輸數據和建立連接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息。
以下面這個URL為例：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
1.協議部分：代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等。在"HTTP"后面的“//”為分隔符
2.域名部分：“www.aspxfans.com”。一個URL中，也可以使用IP地址作為域名使用
3.端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，將采用默認端口80/tcp
4.虛擬目錄部分：從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
5.文件名部分：從域名后的最后一個“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那么從域名后的最后一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名
6.錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分（可以理解為定位）
7.參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜索部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符。
域名解析
第一步：瀏覽器會檢查緩存中有沒有這個域名對應的解析過的IP地址，如果有，這個解析過程就結束了，直接拿到IP進行訪問。這個瀏覽器緩存域名是有限制的，除了緩存大小有限制，緩存的時間也有限制，通常情況下由TTL屬性來設置。
第二步：如果用戶瀏覽器緩存中沒有，瀏覽器會查找操作系統中是否有這個域名對應的DNS解析結果。windows中c:/windows/system32/drivers/etc/hosts文件設置，linux中/etc/hosts文件中設置。當解析到這個配置文件中的某個域名時，操作系統會在緩存中緩存這個解析結果。（修改文件后不立即生效的原因）
第三步：在網絡配置中都會有“DNS服務器地址”這一項，當前面兩步都不能解析時，操作系統會把這個域名發送給設置的DNS服務器（簡稱LDNS）-local縮寫，一般是本地區的域名服務器也可以是自己設置的域名服務器地址，如果命中，那解析就此結束並返回IP並標記為非權威服務器的應答。如是學校的互聯網，那么你的DNS服務器肯定在你的學校，如果你是一個小區接入互聯網，那這個DNS就是提供給你接入互聯網的應用供應商，即電信或聯通。windows中能用ipconfig查看DNS服務器地址，linux中cat /etc/resolv.conf查看DNS Server。
第四步：如果LDNS沒有命中，LDNS就會向Root Server域名服務器請求解析。LDNS會從配置文件里面讀取13個根域名服務器的地址（這些地址是不變的，直接在BIND的配置文件中），然后像其中一台發起請求。
第五步:根服務器拿到這個請求后，知道他是com.這個頂級域名下的，所以就會返回com.域中的NS記錄，一般來說是13台主機名和IP（主域名服務器地址即gTLD-國際頂級域名服務器地址），返回給本地域名服務器即LDNS，
第六步：LDNS再向上一步返回的其中一台gTLD服務器發送請求。com.域的服務器（gTLD）發現你這請求是baidu.com這個域的，一查發現了這個域的NS（一般就是你注冊的域名服務器），那就返回給你，你再去查。
第七步：LDNS接受gTLD返回的域服務器地址（即域名服務提供商的域服務器）並向其中一台再次發起請求，在baidu.com的域下面查了下有www的這台主機，就把這個IP返回給你了。
第八步：LDNS接受返回的IP和TLL值
第九步：LDNS緩存這個域名和IP的對應關系，緩存時間有TLL控制
第十步：LDNS把解析的結果返回給用戶，用戶根據TLL值緩存在本地系統緩存中，域名解析結束。
返回服務器針對特定資源所支持的HTTP請求方法，也可以利用向web服務器發送‘*’的請求來測試服務器的功能性
2、HEAD
向服務器索與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下，就可以獲取包含在響應小消息頭中的元信息。
3、GET
向特定的資源發出請求。它本質就是發送一個請求來取得服務器上的某一資源。資源通過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。
4、POST
向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函數：web_submit_data,web_submit_form
5、PUT
向指定資源位置上傳其最新內容
6、DELETE
請求服務器刪除Request-URL所標識的資源
7、TRACE
回顯服務器收到的請求，主要用於測試或診斷
8、CONNECT
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
狀態碼
狀態代碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示信息--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：服務器端錯誤--服務器未能實現合法的請求
常見狀態代碼、狀態描述、說明：
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
401 Unauthorized // 請求未經授權， 這個狀態代碼必須和WWW-Authenticate 報頭域一起使用
403 Forbidden //服務器收到請求，但是拒絕提供服務
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable // 服務器當前不能處理客戶端的請求， 一段時間后，可能恢復正常
request
User_agent:發出請求的用戶信息,客戶端操作系統和瀏覽器的名稱和版本
Accept:瀏覽器端可以接收的媒體類型
Accept-Language:瀏覽器申明主機接收的語言
Accept-Encoding:瀏覽器申明接收的編碼方法，通常指定壓縮方法，是否支持壓縮，支持什么壓縮方法
Referer:提供request的上下文信息的服務器，告訴服務器我是從哪個鏈接過來的
Cookie：最重要的header,將cookie值發送給http服務器
Connection:
keep-alive當一個網頁打開完成后，客戶端和服務器之間用於傳輸http數據的tcp鏈接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的鏈接
Close代表一個request完成后，客戶端和服務器之間用於傳輸http數據的tcp鏈接會關閉，當客戶端再次發送request，需要重新建立tcp鏈接
Cache-Control:Public 可以被任何緩存所緩存（）
Cache-Control:Private 內容只緩存到私有緩存中
Cache-Control:no-cache 所有內容都不會被緩存
max-age>0 時 直接從游覽器緩存中 提取 max-age<=0 時 向server 發送http 請求確認 ,該資源是否有修改 ，有的話 返回200 ,無的話 返回304.
X-Forwarded-For:client1, proxy1, proxy2, proxy3
Content-Type:web服務器告訴瀏覽器自己響應的對象的類型和字符集。
Date:生成消息的具體時間和日期。
Server:指明http服務器的軟件信息。
Tracecode:跟蹤代碼
Transfer-encoding:傳輸編碼，chunked便士輸出的內容長度不能確定。
X-powered-by:表示網站用什么技術開發的。
Expires:瀏覽器會在指定過期時間內使用本地緩存
Last-modified:指示資源的最后修改日期和時間
Content-length:實體正文長度
session
session的中文翻譯是“會話”，當用戶打開某個web應用時，便與web服務器產生一次session。服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一台服務器的時候session會丟失。
cookie
cookie是保存在本地終端的數據。cookie由服務器生成，發送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發送給服務器。由於cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據太多磁盤空間，所以每個域的cookie數量是有限的。
cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設置為全局:"\")、失效時間、安全標志(指定后，cookie只有在使用SSL連接時才發送到服務器(https))。下面是一個簡單的js使用cookie的例子:
用戶登錄時產生cookie:
document.cookie = "id="+result.data['id']+"; path=/";
document.cookie = "name="+result.data['name']+"; path=/";
document.cookie = "avatar="+result.data['avatar']+"; path=/";
使用到cookie時做如下解析：
var cookie = document.cookie;var cookieArr = cookie.split(";");var user_info = {};for(var i = 0; i < cookieArr.length; i++) {
user_info[cookieArr[i].split("=")[0]] = cookieArr[i].split("=")[1];
}
$('#user_name').text(user_info[' name']);
$('#user_avatar').attr("src", user_info[' avatar']);
$('#user_id').val(user_info[' id']);
token
token的意思是“令牌”，是用戶身份的驗證方式，最簡單的token組成:uid(用戶唯一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成一定長的十六進制字符串，可以防止惡意第三方拼接token請求服務器)。還可以把不變的參數也放進token，避免多次查庫
cookie 和session的區別
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留，可以放在COOKIE中
token 和session 的區別
session 和 oauth token並不矛盾，作為身份認證 token安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通訊安全了。如上所說，如果你需要實現有狀態的會話，仍然可以增加session來在服務器端保存一些狀態
App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那樣用cookie來保存session,因此用session token來標示自己就夠了，session/state由api server的邏輯處理。 如果你的后端不是stateless的rest api, 那么你可能需要在app里保存session.可以在app里嵌入webkit,用一個隱藏的browser來管理cookie session.
Session 是一種HTTP存儲機制，目的是為無狀態的HTTP提供的持久機制。所謂Session 認證只是簡單的把User 信息存儲到Session 里，因為SID 的不可預測性，暫且認為是安全的。這是一種認證手段。 而Token ，如果指的是OAuth Token 或類似的機制的話，提供的是 認證 和 授權 ，認證是針對用戶，授權是針對App 。其目的是讓 某App有權利訪問 某用戶 的信息。這里的 Token是唯一的。不可以轉移到其它 App上，也不可以轉到其它 用戶 上。 轉過來說Session 。Session只提供一種簡單的認證，即有此 SID，即認為有此 User的全部權利。是需要嚴格保密的，這個數據應該只保存在站方，不應該共享給其它網站或者第三方App。 所以簡單來說，如果你的用戶數據可能需要和第三方共享，或者允許第三方調用 API 接口，用 Token 。如果永遠只是自己的網站，自己的 App，用什么就無所謂了。
token就是令牌，比如你授權（登錄）一個程序時，他就是個依據，判斷你是否已經授權該軟件；cookie就是寫在客戶端的一個txt文件，里面包括你登錄信息之類的，這樣你下次在登錄某個網站，就會自動調用cookie自動登錄用戶名；session和cookie差不多，只是session是寫在服務器端的文件，也需要在客戶端寫入cookie文件，但是文件里是你的瀏覽器編號.Session的狀態是存儲在服務器端，客戶端只有session id；而Token的狀態是存儲在客戶端。
Web緩存一般分為瀏覽器緩存、代理服務器緩存以及網關緩存，本文主要講的是 瀏覽器緩存，其它兩種緩存大家自行去了解下。
Web 緩存游走於服務器和客戶端之間。這個服務器可能是源服務器（資源所駐留的服務器），數量可能是1個或多個；這個客戶端也可能是1個或多個。Web 緩存就在服務器-客戶端之間搞監控，監控請求，並且把請求輸出的內容（例如html頁面、 圖片和文件）（統稱為副本）另存一份；然后，如果下一個請求是相同的 URL，則直接請求保存的副本，而不是再次麻煩源服務器。
使用緩存的2個主要原因：
- 降低延遲：緩存離客戶端更近，因此，從緩存請求內容比從源服務器所用時間更少，呈現速度更快，網站就顯得更靈敏。
- 降低網絡傳輸：副本被重復使用，大大降低了用戶的帶寬使用，其實也是一種變相的省錢（如果流量要付費的話），同時保證了帶寬請求在一個低水平上，更容易維護了。
試想現在的大型網站，隨便一個頁面都是一兩百個請求，每天 pv 都是億級別，如果沒有緩存，用戶體驗會急劇下降（表現在等待請求的時間上）、同時服務器壓力和網絡帶寬都面臨嚴重的考驗。
http下加入ssl層，https的安全基礎是ssl(secure socket layer)
