1. TCP/IP協議分層結構
應用層（含括了OSI七層中的上三層，分別為應用層，表示層， 會話層）：DNS, URI, HTML, HTTP, TLS/SSL, SMTP, POP, IMAP, MIME, TELNET, SSH, FTP, SNMP, MIB, SIP, RTP, LDAP；
傳輸層: TCP , UDP, UDP_LITE, SCTP, DCCP;
網絡層： ARP, IP, ICMP;
物理層（包含OSI七層模型的下兩層，數據鏈路層及物理層）： PPP（點到點）等
1. http請求到響應過程
A. 瀏覽器生成HTTP請求信息（第五層）：
第一步：當用戶輸入網址並回車
第二步：瀏覽器分解URL（例如 http://www.test.com/p1.html http為請求協議， www.test.com為請求的域名即web服務器地址， p1.html為資源，當然在這里資源分為靜態資源及動態請求）
第三步：生成http請求消息
消息的格式為: <請求行 METHOD+path+協議及版本> + <請求頭 User-Agent、Content-type等等> <請求體 post數據放在此>
第四步：DNS解析（解析域名，得到WEB服務器IP地址） （DNS優化: 1.DNS緩存， 2.DNS負載均衡）
1）首先會搜索瀏覽器自身的DNS緩存，否則執行2）；
2）則搜索操作系統的DNS緩存，否則執行3）；
3）搜索hosts文件里面去找，否則執行4）；
4）遞歸查找DNS服務器；（dns為樹狀結構，直到查找至最頂層）
B. TCP連接（三次握手）：
第一步：建立socket
操作系統在接到請求后，首先會申請一塊用於存放一個套接字所需的內存空間，套接字是存放了一些通信相關的控制信息的集合。然后向這個內存空間寫入一些初始狀態，並把該套接字的唯一標識告訴應用程序，即瀏覽器。
第二步：建立TCP連接：
這里參照這篇博文
第四步：發送HTTP請求:
操作系統收到數據后會將數據存放在的發送數據緩存區中，並等待接收后續數據，只有當接收的數據達到一個網絡包的大小的時候，或者達到最大等待時間之后，才會委托ip模塊發送出去。瀏覽器數據量小、對性能要求高，一般會設置為直接發送。一般的http請求數據用一個網絡包就夠了，但有時提交的表單數據較大時，會拆分成多個網絡包發送
C. 網絡層處理：
當上層（傳輸層）HTTP請求數據到達之后，該層做進一步的數據包封裝， 主要包括源地址及目的地址，當然這里的地址包括IP及MAC地址， 其中目的IP地址就是應用層中DNS解析的IP地址， 而MAC地址則需要通過ARP協議進行廣播查詢
D. 物理層將數據包以數字信號進行發送，在此之前還需要添加一些CRC校驗字段等等來確保數據未發生丟失
E. 服務器響應HTTP請求， 瀏覽器得到資源文件
HTTP響應同樣由響應行、響應頭、響應體組成
常見的響應狀態碼類別有：
F. 瀏覽器解析HTML代碼， 同時請求相關靜態資源
瀏覽器（應用層）在得到HTML文件之后， 會按照<!DOCTYPE XXXX>規定的格式進行解析， 如果碰到鏈接的靜態文件資源時， 瀏覽器便會另開多個線程去請求下載， 這是便會使用到HTTP協議的keep-alive特性了， 建立了一次HTTP連接，但是能夠請求多個靜態資源。
G. 生成DOM並渲染， 邊解析邊渲染
瀏覽器是一個邊解析邊渲染的過程。首先瀏覽器解析HTML文件構建DOM樹，然后解析CSS文件構建渲染樹，等到渲染樹構建完成后，瀏覽器開始布局渲染樹並將其繪制到屏幕上。這個過程比較復雜，涉及到兩個概念: reflow(回流)和repain(重繪)。DOM節點中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顏色,字體,等確定下來之后，瀏覽器便開始繪制內容，這個過程稱為repain。頁面在首次加載時必然會經歷reflow和repain。reflow和repain過程是非常消耗性能的，尤其是在移動設備上，它會破壞用戶體驗，有時會造成頁面卡頓。所以我們應該盡可能少的減少reflow和repain。
JS的解析是由瀏覽器中的JS解析引擎完成的。JS是單線程運行，JS有可能修改DOM結構，意味着JS執行完成前，后續所有資源的下載是沒有必要的，所以JS是單線程，會阻塞后續資源下載
自此便完成了一次HTTP請求及響應