重學網絡-TCP

歡迎關注個人我的博客分享一些前端技術、面試題、面試技巧等

同源策略

瀏覽器有一個很重要的概念————同源策略

同源策略限制了從同一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。

同源是指：域名、協議、端口相同。不一樣源的客戶端腳本(js、ActionScript)在沒明確受權的狀況下，不能讀寫對方的資源。

• http 與 https 下的默認端口可省略

  • http => 80
  • https => 443

域名是倒着解析的

1. .com頂級域名
2. baidu.com (一)二級域名
3. zhidao.baidu.com (二)三級域名
4. www 二級域名前綴，表示萬維網維護的
5. www.baidu.com 屬於特殊的三級域名

zhidao.baidu.com 屬於百度本身維護的網絡地址

• com、org、net 屬於頂級域名，是在全世界範圍內解析的，cn、hk 是在一個地區解析的。
  • cn 中國
  • .com (商業機構)
  • .net (從事互聯網服務的機構)
  • .org (非盈利性組織)
  • .com.cn (國內商業機構)
  • .net.cn (國內互聯網機構)
  • .org.cn (國內非盈利性組織)

若是把 IP 地址比做一間房子，端口就是出入這間房子的門。真正的房子只有幾個門，可是一個 IP 地址的端口能夠有多個。

瀏覽網頁服務默認的端口號都是 80,所以只需輸入網址便可，不用輸入":80"

當你在瀏覽器裏輸入一個 url 發生了什麼

簡單概括

1. 瀏覽器經過 DNS 域名解析到服務 IP(ping www.baidu.com)
2. 客戶端(瀏覽器)經過 TCP 協議創建到服務器的 TCP 鏈接(三次握手)
3. 客戶端(瀏覽器)向 web 服務器端(HTTP 服務器)發送 HTTP 協議包，請求服務器裏的資源文檔
4. 服務器向客戶端發送 HTTP 協議應答包
5. 客戶端和服務器斷開(四次揮手)，客戶端開始解釋處理 HTML 文檔

TCP/UDP(傳輸層協議)

面向鏈接的 TCP

可靠，過程複雜

TCP(Transmission Control Protocol,傳輸控制協議)是基於鏈接的協議，也就是說，在正式收發數據前，必須和對方創建可靠的鏈接。一個 TCP 鏈接必需要通過三次"對話"才能創建起來。

面向非鏈接的 UDP 協議

不可靠，實時(視頻，語音通話)

"面向非鏈接"就是在正式通訊前沒必要與對方先創建鏈接，無論對方狀態就直接發送。與手機短信很是類似:你在發短信時，只須要輸入對方手機號就能夠。 UDP(User Data Protocol,用戶數據報協議)是與 TCP 相對應的協議。它是面向非鏈接的協議,它不與對方創建鏈接，而是直接把數據包發送過去。

什麼是"三次握手,四次揮手"

TCP 是一種面向鏈接的單播協議，在發送數據前，通訊雙方必須在彼此間創建一條"鏈接"。實際上是客戶端和服務器的內存裏保存一份關於對方的信息，如ip地址、端口號等等。

三次握手

簡單描述

1. 先客戶端發送鏈接，請求報文
2. 服務端鏈接後回覆 ACK 報文，併爲此次鏈接分配資源
3. 客戶端接收到 ACK 報文後也向服務端發送 ACK 報文，並分配資源

做用：爲了保證服務端能收接受到客戶端的信息並能作出正確的應答而進行前兩次(第一次和第二次)握手，爲了保證客戶端可以接收到服務端的信息並能作出正確的應答而進行後兩次(第二次和第三次)握手。

詳細描述三次握手

剛開始客戶端處於 closed 的狀態，服務端處於 listen 狀態

第一次握手:客戶端給服務端發一個 SYN 報文，並指明客戶端的初始化序號ISN(c)。此時客戶端處於SYN_Send狀態，等待服務器的確認。

第二次握手:服務器接收到客戶端的 SYN 報文後，會對這個 SYN 報文段進行確認，並將本身的 SYN 報文做爲應答，而且也是指定了本身的初始化序列號 ISN(c),同時會把客戶端的 ISN+1 做爲ACK的值，表示本身已經收到了客戶端的 SYN，此時服務器處於SYN_RCVD狀態。

第三次握手:客戶端收到 SYN 報文以後，回發送一個 ACK 報文，也是同樣把服務器的 ISN+1 做爲 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處於ESTABLISHED狀態。

服務器收到 ACK 報文後，也處於ESTABLISHED狀態，此時，雙方創建起了連接，完成 TCP 三次握手。

三次握手的目的

• 爲了防止已失效的鏈接請求報文忽然又傳送到服務端，於是產生錯誤
• 爲了解決"網絡中存在延遲的重複分組"問題
• 指定本身的初始化序列號，爲後面的可靠傳送作準備
• 若是是 https 協議的話，三次握手這個過程，還會進行數字證書的驗證以及加密密鑰的生成
• 防止了服務器端的一直等待而浪費資源。

四次揮手

簡單描述

1. 客戶端發送中斷鏈接請求，也就是發送 FIN 報文。
2. 服務端發送 ACK
   1. wait:這個時候客戶端進入 FIN_WAIT 狀態，繼續等待服務端的 FIN 報文
3. 當服務端肯定數據已發送完成，則向客戶端發送 FIN 報文
4. 客戶端收到 FIN 報文後，發送 ACK 後進入 TIME_WAIT 狀態，若是服務端沒有收到 ACK 則能夠重傳，服務端收到 ACK 後，就知道能夠斷開鏈接了。客戶端等待了 2MSL 後依然沒有收到回覆，則證實服務端已正常關閉，客戶端也關閉鏈接

詳細描述四次揮手

剛開始雙方都處於 ESTABLISHED 狀態,能夠是客戶端，也能夠是服務器端先發起關閉請求。

第一次揮手:客戶端設置發送 FIN 報文，報文中會指定一個序列號。此時客戶端進入FIN_WAIT_1狀態，這表示客戶端沒有數據要發送給客戶端了。

第二次揮手:服務端收到了客戶端發送的 FIN 報文段，向客戶端返回一個 ACK 報文段，代表本身接受到了客戶端關閉鏈接的請求，且把客戶端的序列號值+1 做爲 ACK 報文的序列號值，發送完畢後服務器端進入CLOSE_WAIT狀態， 客戶端進入FIN_WAIT_2狀態，等待服務器端關閉鏈接。

第三次揮手:若是服務端準備好了也想斷開鏈接，和客戶端的第一次揮手同樣，發送 FIN 報文，，且指定一個序列號。發送完畢後，服務端進去LAST_ACK狀態，等待來自客戶端的最後一個 ACK

第四次揮手:客戶端收到 FIN 以後，同樣發送一個 ACK 報文做爲應答，且把服務端的序列號值 + 1 做爲本身的 ACK 報文的序列號值，此時客戶端處於TIME_WAIT狀態，等待可能出現的要求重傳的 ACK 包；服務端接收到這個確認包後，關閉鏈接，進入 CLOSED 狀態。客戶端等待一段時間(兩個最大生命週期，2MSL，2 Maximum Segment Lifetime)以後，沒有收到服務端的 ACK，認爲服務端已經正常關閉鏈接，因而本身也關閉鏈接，進入 CLOSED 狀態。TCP 的四次揮手就完成了。

爲何客戶端發送 ACK 以後不直接關閉

要確保服務器是否已經收到了咱們的 ACK 報文，若是沒有收到的話，服務器會從新發 FIN 報文給客戶端，客戶端再次收到 FIN 報文以後，就知道以前的 ACK 報文丟失，而後再次發送 ACK 報文。

---

但願對讀完本文的你有幫助、有啓發，若是有不足之處，歡迎批評指正交流！

歡迎關注個人我的博客分享一些前端技術、面試題、面試技巧等

辛苦整理良久，還望手動點贊鼓勵~

---

'摘抄'不是單純的「粘貼->複製」，而是眼到，手到，心到的一字一句敲打下來。

博客聲明:全部轉載的文章、圖片僅用於做者本人收藏學習目的，被要求或認爲適當時，將標註署名與來源。若不肯某一做品被轉用，請及時通知本站，本站將予以及時刪除。