前端工程師系列，TCP複習及濃縮總結（全乾貨，支持面試）

最近公司項目很少，閒着也來寫寫文章，複習一下基礎知識。 以前也寫了好幾片文章，苦於本身不太會玩標題黨，結構內容也不生動，沒什麼點擊量，但願慢慢總結的寫，提升水平，給你們帶來好的內容，廢話很少說。下面進入正題。

說道TCP/IP、HTTP兩個詞，我估計各位應該沒有人不知道，多多少少聽到一些，若是您是網絡專業的專家或熟知這些內容，就請您輕拍、路過。

TCP/IP 名詞解釋

• IP（Internet Protocol）協議的英文名直譯就是：因特網協議，它能夠根據網絡狀況，將要傳輸的數據，分爲不一樣大小的包、固定的格式，在源地址和目的地址之間傳送。就比如現實生活中，咱們有一批貨物要從北京發送到廣州，運輸時咱們把貨物包裝成一個個的包裝箱後，而後進行運輸，在這裏IP協議就比如規定了包裝箱的尺寸和包裝方法。

• IP的頭部只有16位首部校驗和，只能對ip頭信息進行數據校驗，但對數據自己是沒有校驗的。

• TCP （Transmission Control Protocol）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。IP協議也有一些缺陷（傳輸不可靠也就是不提供點到點的傳輸確認、對數據沒有完整性校驗、不能重發和流量控制）。繼續用傳輸貨物的比喻，IP協議就比如貨是打包發走了，但廣州方面收沒收到貨物無論，貨物是否無缺無損無論。TCP協議在IP協議的基礎上提供了可靠地面向對象的數據流傳輸服務的規則和約定。簡單說，就是發送一個數據包，我就要確認對方有效，完整的收到。

• TCP的頭部16位校驗和是對數據的完整性校驗。

TCP首部長度，有哪些字段，總長度多少?

• 固定長度總共有20個字節長度，分爲5行，每行4個字節、32位。
• 選項算入報頭首部，但不在固定20個字節內。

TCP首部中有6個標誌比特位

能夠設成1 or 0，用來應答，它們分別表示的含義以下：

• URG： 緊急指針
• ACK： 確認序號有效
• PSH： 儘量快地將數據送往接收進程
• RST： 重建鏈接
• SYN： 同步序號用來發起一個鏈接
• FIN： 發端完成發送任務

TCP/IP四層模型與OSI七層模型的對應關係

• TCP/IP與OSI最大的不一樣在於OSI是一個理論上的網絡通訊模型，而TCP/IP則是實際運行的網絡協議。
• IP協議在網絡層。TCP和UDP協議在傳輸入層。
• TCP： FTP、HTTP、Telnet、SMTP、POP三、HTTPS
• UDP：DNS、SNMP、NFS

TCP和UDP的區別

• TCP是有鏈接的，兩臺主機在進行數據交互以前必須先經過三次握手創建鏈接；而UDP是無鏈接的，沒有創建鏈接這個過程。
• TCP是可靠的傳輸，TCP協議經過確認和重傳機制來保證數據傳輸的可靠性；而UDP是不可靠的傳輸。
• TCP還提供了擁塞控制、滑動窗口等機制來保證傳輸的質量，而UDP都沒有。
• TCP是基於字節流的，將數據看作無結構的字節流進行傳輸，當應用程序交給TCP的數據長度太長，超過MSS時，TCP就會對數據進行分段，所以TCP的數據是無邊界的；而UDP是面向報文的，不管應用程序交給UDP層多長的報文，UDP都不會對數據報進行任何拆分等處理，所以UDP保留了應用層數據的邊界。

TCP 三次握手四次揮手

三次握手

• 第一次握手（綠區箭頭1）：客戶端想與服務器創建鏈接傳送數據，客戶端調用向服務器發送TCP報文請求，SYN = 1, Sequence Number = x; 而後，客戶端進入SYN_SEND狀態，等待服務器的確認。
• 第二次握手（綠區箭頭2）：正在處於LISTEN狀態的服務器端接受到客戶端發來的SYN報文後，表示我收到了你的請求，我能夠與你創建鏈接收發數據，服務器會發送返回確認信息，這個信息是Acknowledgment Number = x + 1(Sequence Number + 1)；同時包含服務器端的SYN請求信息：SYN = 1, Sequence Number = y; 一併發送給客戶端，此時服務器進入SYN_RECV狀態。
• 第三次據手（綠區箭頭3）：處於SYN_SEND狀態的客戶端，接收到服務器發來的SYN+ACK標識位的報文後，將Acknowledgment Number = y + 1，的確認報文回發給服務器，表示我知道服務器端你已經收到我發送的第一次握手請求。而後進入ESTABLISHED狀態。
• 服務器端收到第三次握手後，進入ESTABLISHED狀態。到此完成TCP三次握手，能夠接下來收發數據。

四次揮手

• 第一次揮手（橙區箭頭一）：客戶說數據傳完啦，我想和你斷開鏈接，而後發送TCP報文，內容爲：FIN = 1, Sequence Number = x + 2, ACK = Y + 1; 而後客戶端進入FIN_WAIT_1狀態；
• 第二次揮手（橙區箭頭二）：服務器收到第一次揮手的請求後，說我收到了，回覆：ACK = x +3; 而後服務器進入CLOSE_WAIT狀態;
• 客戶端收到之後狀態改成FIN_WAIT_2。
• 第三次揮手（橙區箭頭三）：服務器向客戶端發送：FIN = 1, Sequence Number = y + 1; 而後服務器進入LAST_ACK狀態;
• 第四次揮手（橙區箭頭四）：客戶端收到服務器發送的FIN報文，而後向服務器發送：ACK = Y + 2; 而後而後客戶端就進入TIME_WATI狀態，服務器收到之後就關閉鏈接，此時，客戶端還會等待2MSL後，依然沒有收到服務器端任何回覆，就表示服務器端正常關閉，那客戶端也就關閉了。

爲何須要三次握手，四次握手呢？

• 由於每一個方向都須要一個FIN和ACK，當一端發送了FIN包以後，處於半關閉狀態，此時仍然能夠接收數據包。
• 在創建鏈接時，服務器能夠把SYN和ACK放在一個包中發送。
• 可是在斷開鏈接時，若是一端收到FIN包，但此時仍有數據未發送完，此時就須要先向對端回覆FIN包的ACK。等到將剩下的數據都發送完以後，再向對端發送FIN，斷開這個方向的鏈接。
• 所以不少時候FIN和ACK須要在兩個數據包中發送，所以須要四次握手   

客戶端最後TIME_WAIT狀態持續時間及緣由

• 持續時間未2MSL，一個數據包在網絡中的最長生存時間爲MSL。
• 假設最後客戶端回覆的ACK（第四次揮手）丟失，服務器端會在超時時間到來時，重傳最後一個FIN包（從新發送第三次揮手請求）。
• ACK和FIN在網絡中的最長生存時間就爲2MSL，這樣就能夠可靠的斷開TCP的雙向鏈接。

三次握手過程當中有哪些不安全性呢？

• 假裝的IP向服務器發送一個SYN請求創建鏈接，而後服務器向該IP回覆SYN和ACK，可是找不到該IP對應的主機，當超時時服務器收不到ACK會重複發送。當大量的攻擊者請求創建鏈接時，服務器就會存在大量未完成三次握手的鏈接，服務器主機backlog被耗盡而不能響應其它鏈接。即SYN泛洪攻擊。
• 防範措施：
  1. 下降SYN timeout時間，使得主機儘快釋放半鏈接的佔用。
  2. 採用SYN cookie設置，若是短期內連續收到某個IP的重複SYN請求，則認爲受到了該IP的攻擊，丟棄來自該IP的後續請求報文。
  3. 在網關處設置過濾，拒絕將一個源IP地址不屬於其來源子網的包進行更遠的路由。
  4. 當一個主機向服務器發送SYN請求鏈接，服務器回覆ACK和SYN後，攻擊者截獲ACK和SYN。而後假裝成原始主機繼續與服務器進行通訊。   

下一篇計劃《HTTP協議幹活面試》。