ＨＴＴＰ相關的一些東西

這幾天一直在看關於HTTP和前端性能優化相關的內容，今天先寫一篇關於HTTP的文章，若是時間容許的話再接着把前端性能優化的寫完。畢竟還要留着時間去看小片嘛😌

接下來就是正文啦！

瀏覽器輸入URL後HTTP請求返回的完整過程

就是下圖這個啦(這個但是我從某課網偷來的)

從輸入地址到頁面渲染

在HTTP的五層分層中：

• 應用層爲應用軟件提供了不少服務，構建於TCP協議之上，屏蔽網絡傳輸相關細節
• 傳輸層向用戶提供可靠的端到端（End-to-End）服務，向高層屏蔽了下層數據通訊的細節
• 網絡層爲數據在結點之間傳輸建立邏輯鏈路
• 數據鏈路層在通訊的實體間創建數據鏈路
• 物理層主要做用是定義物理設備如何傳輸數據

#### 統一資源標識符URI

URI用字符串標識某一互聯網資源，包括URL和URN。

URL爲統一資源定位符，表示資源的地點(互聯網上所處的位置)；

URN爲永久統一資源定位符：資源在移動以後還能被找到，目前尚未很是成功的使用方案。

#### TCP鏈接中的三次握手與四次揮手

這部份內容是面試中的重點，尤爲是SYN、ACK啥的，好亂😵

先放圖😏

其中：起初兩端的TCP進程都是CLOSED狀態。主動打開鏈接的是客戶端，被動打開鏈接的是服務器

1. 第一次握手：客戶端向服務器發出鏈接請求保溫，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號seq=x，此時，TCP客戶端進程進入了SYN-SENT（同步已發送狀態）。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但須要消耗掉一個序號。
2. 第二次握手：服務器收到請求報文後，若是贊成鏈接就發出確認報文。確認報文中ack=1,SYN=1，確認號爲ACK=x+1，同時也要爲本身初始化一個序號seq=y，此時服務器進入了SYN-RCVD（同步收到）狀態。這個報文不能攜帶數據，可是一樣要消耗一個序號。
3. 第三次握手：客戶端收到確認後，還要向服務器給出確認。確認報文的ack=1，ACK=y+1，本身的序列號seq=x+1，此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。TCP規定，ACK報文段能夠攜帶數據，可是若是不攜帶數據則不消耗序號。

當服務端收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始連通了。

四次揮手：

• 第一次揮手：客戶端向服務器發送一個FIN報文段，將設置seq=x+2和ACK=y+1，;此時，客戶端進入 FIN_WAIT_1狀態,這表示客戶端沒有數據要發送服務器了，請求關閉鏈接;
• 第二次揮手：服務器收到了客戶端發送的FIN報文段，向客戶端回一個ACK報文段，ACK=x+3;服務器進入了CLOSE_WAIT狀態，客戶端收到服務器返回的ACK報文後，進入FIN_WAIT_2狀態;
• 第三次揮手：服務器會觀察本身是否還有數據沒有發送給客戶端，若是有，先把數據發送給客戶端，再發送FIN報文；若是沒有，那麼服務器直接發送FIN報文給客戶端。請求關閉鏈接，同時服務器進入LAST_ACK狀態;
• 第四次揮手：客戶端收到服務器發送的FIN報文段，向服務器發送ACK報文段，而後客戶端進入TIME_WAIT狀態;服務器收到客戶端的ACK報文段之後，就關閉鏈接;此時，客戶端等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，客戶端也能夠關閉鏈接了。

好啦，忽然看了看，剩下總結的均可以歸爲緩存了，那就在下一篇裏面再寫吧，拜拜了您吶😁