一、TCP
要說http就繞不開tcp，TCP協議對應於傳輸層，而HTTP協議對應於應用層，從本質上來說，二者沒有可比性。但是，http是基於tcp協議的。
TCP/IP 協議分層模型
-
物理層：將二進制的0和1和電壓高低，光的閃滅和電波的強弱信號進行轉換
-
鏈路層：代表驅動
-
網絡層
-
使用 IP 協議，IP 協議基於 IP 轉發分包數據
-
IP 協議是個不可靠協議，不會重發
-
IP 協議發送失敗會使用ICMP 協議通知失敗
-
ARP 解析 IP 中的 MAC 地址，MAC 地址由網卡出廠提供
-
IP 還隱含鏈路層的功能，不管雙方底層的鏈路層是啥，都能通信
-
-
傳輸層
-
TCP 協議面向有連接，能正確處理丟包，傳輸順序錯亂的問題，但是爲了建立與斷開連接，需要至少7次的發包收包，資源浪費
-
UDP 面向無連接，不管對方有沒有收到，如果要得到通知，需要通過應用層
-
通用的 TCP 和 UDP 協議
-
-
會話層以上分層
-
TCP/IP 分層中，會話層，表示層，應用層集中在一起
-
網絡管理通過 SNMP 協議
-
二、TCP三次握手和四次揮手
劃重點了啊（面試最常問的啊），被問爛了的問題了。
三次握手：
-
客戶端–發送帶有SYN標誌的數據包–一次握手–服務端
-
服務端–發送帶有SYN/ACK標誌的數據包–二次握手–客戶端
-
客戶端–發送帶有帶有ACK標誌的數據包–三次握手–服務端
四次揮手：
-
客戶端-發送一個FIN，用來關閉客戶端到服務器的數據傳送
-
服務器-收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1 。和SYN一樣，一個FIN將佔用一個序號
-
服務器-關閉與客戶端的連接，發送一個FIN給客戶端
-
客戶端-發回ACK報文確認，並將確認序號設置爲收到序號加1
三、TCP和UDP的區別
仔細閱讀上面傳輸層裏寫的內容，懂了嗎？（不懂？不懂背下來啊！）舉一個我們微信聊天時候經常會有這種情況：
是不是感同身受，這種情況就是對方用了TCP協議來聊天，要經過--在嗎？--在--巴拉巴拉，才能成功的傳遞信息。而如果對方使用UDP，則會有事直接說，不管我收沒收到。（以後找我請用UDP協議，着急直接打電話！）
四、HTTP簡介
Http協議是建立在TCP協議基礎之上的，當瀏覽器需要從服務器獲取網頁數據的時候，會發出一次Http請求。Http會通過TCP建立起一個到服務器的連接通道，當本次請求需要的數據完畢後，Http會立即將TCP連接斷開，這個過程是很短的。所以Http連接是一種短連接，是一種無狀態的連接。
所謂的無狀態，是指瀏覽器每次向服務器發起請求的時候，不是通過一個連接，而是每次都建立一個新的連接。如果是一個連接的話，服務器進程中就能保持住這個連接並且在內存中記住一些信息狀態。而每次請求結束後，連接就關閉，相關的內容就釋放了，所以記不住任何狀態，成爲無狀態連接。
1、http傳輸流
發送端在層與層間傳輸數據時，沒經過一層都會被加上首部信息，接收端每經過一層都會刪除一條首部
2、HTTP的英文全稱
又來劃重點了啊！開玩笑的，這個顯然不是重點，但是不排除有人會去問，還是要知道的：超文本傳輸協議（HyperText Transfer Protocol）
五、狀態碼
狀態碼就那些，常用的記住就行了：
2XX 成功
-
200 OK，表示從客戶端發來的請求在服務器端被正確處理
-
204 No content，表示請求成功，但響應報文不含實體的主體部分
-
206 Partial Content，進行範圍請求
3XX 重定向
-
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
-
302 found，臨時性重定向，表示資源臨時被分配了新的 URL
-
303 see other，表示資源存在着另一個 URL，應使用 GET 方法定向獲取資源
-
304 not modified，表示服務器允許訪問資源，但因發生請求未滿足條件的情況
-
307 temporary redirect，臨時重定向，和302含義相同
4XX 客戶端錯誤
-
400 bad request，請求報文存在語法錯誤
-
401 unauthorized，表示發送的請求需要有通過 HTTP 認證的認證信息
-
403 forbidden，表示對請求資源的訪問被服務器拒絕
-
404 not found，表示在服務器上沒有找到請求的資源
5XX 服務器錯誤
-
500 internal sever error，表示服務器端在執行請求時發生了錯誤
-
503 service unavailable，表明服務器暫時處於超負載或正在停機維護，無法處理請求
六、HTTP協議格式
HTTP的請求和響應的消息協議是一樣的，分爲三個部分，起始行、消息頭和消息體。這三個部分以CRLF作爲分隔符。最後一個消息頭有兩個CRLF，用來表示消息頭部的結束。
HTTP請求的起始行稱爲請求行，形如GET /index.html HTTP/1.1
HTTP響應的起始行稱爲狀態行，形如200 ok
消息頭部有很多鍵值對組成，多個鍵值對之間使用CRLF作爲分隔符，也可以完全沒有鍵值對。形如Content-Encoding: gzip 消息體是一個字符串，字符串的長度是由消息頭部的Content-Length鍵指定的。如果沒有Content-Length字段說明沒有消息體，譬如GET請求就是沒有消息體的，POST請求的消息體一般用來放置表單數據。GET請求的響應返回的頁面內容也是放在消息體裏面的。我們平時調用API返回的JSON內容都是放在消息體裏面的。
七、HTTP的無狀態性
所謂HTTP協議的無狀態性是指服務器的協議層無需爲不同的請求之間建立任何相關關係，它特指的是協議層的無狀態性。但是這並不代表建立在HTTP協議之上的應用程序就無法維持狀態。
應用層可以通過會話Session來跟蹤用戶請求之間的相關性，服務器會爲每個會話對象綁定一個唯一的會話ID，瀏覽器可以將會話ID記錄在本地緩存LocalStorage或者Cookie，在後續的請求都帶上這個會話ID，服務器就可以爲每個請求找到相應的會話狀態。
八、輸入url到頁面加載都發生了什麼事情？（最最常問的來了）
-
輸入地址
-
瀏覽器查找域名的 IP 地址 這一步包括 DNS 具體的查找過程，包括：瀏覽器緩存->系統緩存->路由器緩存...
-
瀏覽器向 web 服務器發送一個 HTTP 請求
-
服務器的永久重定向響應（從 http://example.com 到 http://www.example.com）
-
瀏覽器跟蹤重定向地址
-
服務器處理請求
-
服務器返回一個 HTTP 響應
-
瀏覽器顯示 HTML
-
瀏覽器發送請求獲取嵌入在 HTML 中的資源（如圖片、音頻、視頻、CSS、JS等等）
-
瀏覽器發送異步請求
參考原文：juejin.im/post/5ad4094e6fb9a028d7011069
