臥槽！牛皮了，頭一次見有大佬把TCP/IP三次握手四次揮手解釋的這麼明白

原文：https://blog.csdn.net/ThinkWo...

計算機網絡體系結構

在計算機網絡的基本概念中，分層次的體系結構是最基本的。計算機網絡體系結構的抽象概念較多，在學習時要多思考。這些概念對後面的學習頗有幫助。

網絡協議是什麼？

在計算機網絡要作到有條不紊地交換數據，就必須遵照一些事先約定好的規則，好比交換數據的格式、是否須要發送一個應答信息。這些規則被稱爲網絡協議。

爲何要對網絡協議分層？

• 簡化問題難度和複雜度。因爲各層之間獨立，咱們能夠分割大問題爲小問題。
• 靈活性好。當其中一層的技術變化時，只要層間接口關係保持不變，其餘層不受影響。
• 易於實現和維護。
• 促進標準化工做。分開後，每層功能能夠相對簡單地被描述。

網絡協議分層的缺點： 功能可能出如今多個層裏，產生了額外開銷。

爲了使不一樣體系結構的計算機網絡都能互聯，國際標準化組織 ISO 於1977年提出了一個試圖使各類計算機在世界範圍內互聯成網的標準框架，即著名的開放系統互聯基本參考模型 OSI/RM，簡稱爲OSI。

OSI 的七層協議體系結構的概念清楚，理論也較完整，但它既複雜又不實用，TCP/IP 體系結構則不一樣，但它如今卻獲得了很是普遍的應用。TCP/IP 是一個四層體系結構，它包含應用層，運輸層，網際層和網絡接口層（用網際層這個名字是強調這一層是爲了解決不一樣網絡的互連問題），不過從實質上講，TCP/IP 只有最上面的三層，由於最下面的網絡接口層並無什麼具體內容，所以在學習計算機網絡的原理時每每採用折中的辦法，即綜合 OSI 和 TCP/IP 的優勢，採用一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚，有時爲了方便，也可把最底下兩層稱爲網絡接口層。

四層協議，五層協議和七層協議的關係以下：

• TCP/IP是一個四層的體系結構，主要包括：應用層、運輸層、網際層和網絡接口層。
• 五層協議的體系結構主要包括：應用層、運輸層、網絡層，數據鏈路層和物理層。
• OSI七層協議模型主要包括是：應用層（Application）、表示層（Presentation）、會話層（Session）、運輸層（Transport）、網絡層（Network）、數據鏈路層（Data Link）、物理層（Physical）。

注：五層協議的體系結構只是爲了介紹網絡原理而設計的，實際應用仍是 TCP/IP 四層體系結構。

TCP/IP 協議族

應用層

應用層( application-layer ）的任務是經過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通訊和交互的規則。

對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少，如域名系統 DNS，支持萬維網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等。

運輸層

運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。

運輸層主要使用一下兩種協議

1. 傳輸控制協議-TCP：提供面向鏈接的，可靠的數據傳輸服務。
2. 用戶數據協議-UDP：提供無鏈接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

每個應用層（TCP/IP參考模型的最高層）協議通常都會使用到兩個傳輸層協議之一：

運行在TCP協議上的協議：

• HTTP（Hypertext Transfer Protocol，超文本傳輸協議），主要用於普通瀏覽。
• HTTPS（HTTP over SSL，安全超文本傳輸協議）,HTTP協議的安全版本。
• FTP（File Transfer Protocol，文件傳輸協議），用於文件傳輸。
• POP3（Post Office Protocol, version 3，郵局協議），收郵件用。
• SMTP（Simple Mail Transfer Protocol，簡單郵件傳輸協議），用來發送電子郵件。
• TELNET（Teletype over the Network，網絡電傳），經過一個終端（terminal）登錄到網絡。
• SSH（Secure Shell，用於替代安全性差的TELNET），用於加密安全登錄用。

運行在UDP協議上的協議：

• BOOTP（Boot Protocol，啓動協議），應用於無盤設備。
• NTP（Network Time Protocol，網絡時間協議），用於網絡同步。
• DHCP（Dynamic Host Configuration Protocol，動態主機配置協議），動態配置IP地址。

運行在TCP和UDP協議上：

• DNS（Domain Name Service，域名服務），用於完成地址查找，郵件轉發等工做。

網絡層

網絡層的任務就是選擇合適的網間路由和交換結點，確保計算機通訊的數據及時傳送。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP/IP 體系結構中，因爲網絡層使用 IP 協議，所以分組也叫 IP 數據報 ，簡稱數據報。

互聯網是由大量的異構（heterogeneous）網絡經過路由器（router）相互鏈接起來的。互聯網使用的網絡層協議是無鏈接的網際協議（Intert Prococol）和許多路由選擇協議，所以互聯網的網絡層也叫作網際層或 IP 層。

數據鏈路層

數據鏈路層(data link layer)一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。

在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。

在接收數據時，控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。

通常的web應用的通訊傳輸流是這樣的：

發送端在層與層之間傳輸數據時，每通過一層時會被打上一個該層所屬的首部信息。反之，接收端在層與層之間傳輸數據時，每通過一層時會把對應的首部信息去除。

物理層

在物理層上所傳送的數據單位是比特。 物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來講，這個電路好像是看不見的。

TCP/IP 協議族

在互聯網使用的各類協議中最重要和最著名的就是 TCP/IP 兩個協議。如今人們常常提到的 TCP/IP 並不必定是單指 TCP 和 IP 這兩個具體的協議，而每每是表示互聯網所使用的整個 TCP/IP 協議族。

互聯網協議套件（英語：Internet Protocol Suite，縮寫IPS）是一個網絡通信模型，以及一整個網絡傳輸協議家族，爲網際網絡的基礎通信架構。它常被通稱爲TCP/IP協議族（英語：TCP/IP Protocol Suite，或TCP/IP Protocols），簡稱TCP/IP。由於該協定家族的兩個核心協定：TCP（傳輸控制協議）和IP（網際協議），爲該家族中最先經過的標準。

劃重點：

TCP（傳輸控制協議）和IP（網際協議） 是最早定義的兩個核心協議，因此才統稱爲TCP/IP協議族

TCP的三次握手四次揮手

TCP是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，在發送數據前，通訊雙方必須在彼此間創建一條鏈接。所謂的「鏈接」，實際上是客戶端和服務端保存的一份關於對方的信息，如ip地址、端口號等。

TCP能夠當作是一種字節流，它會處理IP層或如下的層的丟包、重複以及錯誤問題。在鏈接的創建過程當中，雙方須要交換一些鏈接的參數。這些參數能夠放在TCP頭部。

一個TCP鏈接由一個4元組構成，分別是兩個IP地址和兩個端口號。一個TCP鏈接一般分爲三個階段：鏈接、數據傳輸、退出（關閉）。經過三次握手創建一個連接，經過四次揮手來關閉一個鏈接。

當一個鏈接被創建或被終止時，交換的報文段只包含TCP頭部，而沒有數據。

TCP報文的頭部結構

在瞭解TCP鏈接以前先來了解一下TCP報文的頭部結構。

上圖中有幾個字段須要重點介紹下：

（1）序號：seq序號，佔32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。

（2）確認序號：ack序號，佔32位，只有ACK標誌位爲1時，確認序號字段纔有效，ack=seq+1。

（3）標誌位：共6個，即URG、ACK、PSH、RST、SYN、FIN等，具體含義以下：

• ACK：確認序號有效。
• FIN：釋放一個鏈接。
• PSH：接收方應該儘快將這個報文交給應用層。
• RST：重置鏈接。
• SYN：發起一個新鏈接。
• URG：緊急指針（urgent pointer）有效。

須要注意的是：

• 不要將確認序號ack與標誌位中的ACK搞混了。
• 確認方ack=發起方seq+1，兩端配對。

三次握手

三次握手的本質是確認通訊雙方收發數據的能力

首先，我讓信使運輸一份信件給對方，對方收到了，那麼他就知道了個人發件能力和他的收件能力是能夠的。

因而他給我回信，我若收到了，我便知個人發件能力和他的收件能力是能夠的，而且他的發件能力和個人收件能力是能夠。

然而此時他還不知道他的發件能力和個人收件能力到底可不能夠，因而我最後回饋一次，他若收到了，他便清楚了他的發件能力和個人收件能力是能夠的。

這，就是三次握手，這樣說，你理解了嗎？

• 第一次握手：客戶端要向服務端發起鏈接請求，首先客戶端隨機生成一個起始序列號ISN(好比是100)，那客戶端向服務端發送的報文段包含SYN標誌位(也就是SYN=1)，序列號seq=100。
• 第二次握手：服務端收到客戶端發過來的報文後，發現SYN=1，知道這是一個鏈接請求，因而將客戶端的起始序列號100存起來，而且隨機生成一個服務端的起始序列號(好比是300)。而後給客戶端回覆一段報文，回覆報文包含SYN和ACK標誌(也就是SYN=1,ACK=1)、序列號seq=300、確認號ack=101(客戶端發過來的序列號+1)。
• 第三次握手：客戶端收到服務端的回覆後發現ACK=1而且ack=101,因而知道服務端已經收到了序列號爲100的那段報文；同時發現SYN=1，知道了服務端贊成了此次鏈接，因而就將服務端的序列號300給存下來。而後客戶端再回復一段報文給服務端，報文包含ACK標誌位(ACK=1)、ack=301(服務端序列號+1)、seq=101(第一次握手時發送報文是佔據一個序列號的，因此此次seq就從101開始，須要注意的是不攜帶數據的ACK報文是不佔據序列號的，因此後面第一次正式發送數據時seq仍是101)。當服務端收到報文後發現ACK=1而且ack=301，就知道客戶端收到序列號爲300的報文了，就這樣客戶端和服務端經過TCP創建了鏈接。

四次揮手

四次揮手的目的是關閉一個鏈接

好比客戶端初始化的序列號ISA=100，服務端初始化的序列號ISA=300。TCP鏈接成功後客戶端總共發送了1000個字節的數據，服務端在客戶端發FIN報文前總共回覆了2000個字節的數據。

• 第一次揮手：當客戶端的數據都傳輸完成後，客戶端向服務端發出鏈接釋放報文(固然數據沒發完時也能夠發送鏈接釋放報文並中止發送數據)，釋放鏈接報文包含FIN標誌位(FIN=1)、序列號seq=1101(100+1+1000，其中的1是創建鏈接時佔的一個序列號)。須要注意的是客戶端發出FIN報文段後只是不能發數據了，可是還能夠正常收數據；另外FIN報文段即便不攜帶數據也要佔據一個序列號。
• 第二次揮手：服務端收到客戶端發的FIN報文後給客戶端回覆確認報文，確認報文包含ACK標誌位(ACK=1)、確認號ack=1102(客戶端FIN報文序列號1101+1)、序列號seq=2300(300+2000)。此時服務端處於關閉等待狀態，而不是立馬給客戶端發FIN報文，這個狀態還要持續一段時間，由於服務端可能還有數據沒發完。
• 第三次揮手：服務端將最後數據(好比50個字節)發送完畢後就向客戶端發出鏈接釋放報文，報文包含FIN和ACK標誌位(FIN=1,ACK=1)、確認號和第二次揮手同樣ack=110二、序列號seq=2350(2300+50)。
• 第四次揮手：客戶端收到服務端發的FIN報文後，向服務端發出確認報文，確認報文包含ACK標誌位(ACK=1)、確認號ack=235一、序列號seq=1102。注意客戶端發出確認報文後不是立馬釋放TCP鏈接，而是要通過2MSL(最長報文段壽命的2倍時長)後才釋放TCP鏈接。而服務端一旦收到客戶端發出的確認報文就會立馬釋放TCP鏈接，因此服務端結束TCP鏈接的時間要比客戶端早一些。

常見面試題

爲何TCP鏈接的時候是3次？2次不能夠嗎？

由於須要考慮鏈接時丟包的問題，若是隻握手2次，第二次握手時若是服務端發給客戶端的確認報文段丟失，此時服務端已經準備好了收發數(能夠理解服務端已經鏈接成功)據，而客戶端一直沒收到服務端的確認報文，因此客戶端就不知道服務端是否已經準備好了(能夠理解爲客戶端未鏈接成功)，這種狀況下客戶端不會給服務端發數據，也會忽略服務端發過來的數據。

若是是三次握手，即使發生丟包也不會有問題，好比若是第三次握手客戶端發的確認ack報文丟失，服務端在一段時間內沒有收到確認ack報文的話就會從新進行第二次握手，也就是服務端會重發SYN報文段，客戶端收到重發的報文段後會再次給服務端發送確認ack報文。

爲何TCP鏈接的時候是3次，關閉的時候倒是4次？

由於只有在客戶端和服務端都沒有數據要發送的時候才能斷開TCP。而客戶端發出FIN報文時只能保證客戶端沒有數據發了，服務端還有沒有數據發客戶端是不知道的。而服務端收到客戶端的FIN報文後只能先回復客戶端一個確認報文來告訴客戶端我服務端已經收到你的FIN報文了，但我服務端還有一些數據沒發完，等這些數據發完了服務端才能給客戶端發FIN報文(因此不能一次性將確認報文和FIN報文發給客戶端，就是這裏多出來了一次)。

爲何客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP鏈接？

這裏一樣是要考慮丟包的問題，若是第四次揮手的報文丟失，服務端沒收到確認ack報文就會重發第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，因此須要等這麼長時間來確認服務端確實已經收到了。

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP設有一個保活計時器，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75秒鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。

什麼是HTTP，HTTP 與 HTTPS 的區別

HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範

經常使用HTTP狀態碼

HTTP狀態碼錶示客戶端HTTP請求的返回結果、標識服務器處理是否正常、代表請求出現的錯誤等。

狀態碼的類別：

GET和POST區別

說道GET和POST，就不得不提HTTP協議，由於瀏覽器和服務器的交互是經過HTTP協議執行的，而GET和POST也是HTTP協議中的兩種方法。

HTTP全稱爲Hyper Text Transfer Protocol，中文翻譯爲超文本傳輸協議，目的是保證瀏覽器與服務器之間的通訊。HTTP的工做方式是客戶端與服務器之間的請求-應答協議。

HTTP協議中定義了瀏覽器和服務器進行交互的不一樣方法，基本方法有4種，分別是GET，POST，PUT，DELETE。這四種方法能夠理解爲，對服務器資源的查，改，增，刪。

• GET：從服務器上獲取數據，也就是所謂的查，僅僅是獲取服務器資源，不進行修改。
• POST：向服務器提交數據，這就涉及到了數據的更新，也就是更改服務器的數據。
• PUT：英文含義是放置，也就是向服務器新添加數據，就是所謂的增。
• DELETE：從字面意思也能看出，這種方式就是刪除服務器數據的過程。

GET和POST區別

1. Get是不安全的，由於在傳輸過程，數據被放在請求的URL中；Post的全部操做對用戶來講都是不可見的。 可是這種作法也不時絕對的，大部分人的作法也是按照上面的說法來的，可是也能夠在get請求加上 request body，給 post請求帶上 URL 參數。
2. Get請求提交的url中的數據最多隻能是2048字節，這個限制是瀏覽器或者服務器給添加的，http協議並無對url長度進行限制，目的是爲了保證服務器和瀏覽器可以正常運行，防止有人惡意發送請求。Post請求則沒有大小限制。
3. Get限制Form表單的數據集的值必須爲ASCII字符；而Post支持整個ISO10646字符集。
4. Get執行效率卻比Post方法好。Get是form提交的默認方法。
5. GET產生一個TCP數據包；POST產生兩個TCP數據包。

對於GET方式的請求，瀏覽器會把http header和data一併發送出去，服務器響應200（返回數據）；
而對於POST，瀏覽器先發送header，服務器響應100 continue，瀏覽器再發送data，服務器響應200 ok（返回數據）。

什麼是對稱加密與非對稱加密

對稱密鑰加密是指加密和解密使用同一個密鑰的方式，這種方式存在的最大問題就是密鑰發送問題，即如何安全地將密鑰發給對方；

而非對稱加密是指使用一對非對稱密鑰，即公鑰和私鑰，公鑰能夠隨意發佈，但私鑰只有本身知道。發送密文的一方使用對方的公鑰進行加密處理，對方接收到加密信息後，使用本身的私鑰進行解密。
因爲非對稱加密的方式不須要發送用來解密的私鑰，因此能夠保證安全性；可是和對稱加密比起來，很是的慢

什麼是HTTP2

HTTP2 能夠提升了網頁的性能。

在 HTTP1 中瀏覽器限制了同一個域名下的請求數量（Chrome 下通常是六個），當在請求不少資源的時候，因爲隊頭阻塞當瀏覽器達到最大請求數量時，剩餘的資源需等待當前的六個請求完成後才能發起請求。

HTTP2 中引入了多路複用的技術，這個技術能夠只經過一個 TCP 鏈接就能夠傳輸全部的請求數據。多路複用能夠繞過瀏覽器限制同一個域名下的請求數量的問題，進而提升了網頁的性能。

Session、Cookie和Token的主要區別
HTTP協議自己是無狀態的。什麼是無狀態呢，即服務器沒法判斷用戶身份。

什麼是cookie

cookie是由Web服務器保存在用戶瀏覽器上的小文件（key-value格式），包含用戶相關的信息。客戶端向服務器發起請求，若是服務器須要記錄該用戶狀態，就使用response向客戶端瀏覽器頒發一個Cookie。客戶端瀏覽器會把Cookie保存起來。當瀏覽器再請求該網站時，瀏覽器把請求的網址連同該Cookie一同提交給服務器。服務器檢查該Cookie，以此來辨認用戶身份。

什麼是session

session是依賴Cookie實現的。session是服務器端對象

session 是瀏覽器和服務器會話過程當中，服務器分配的一塊儲存空間。服務器默認爲瀏覽器在cookie中設置 sessionid，瀏覽器在向服務器請求過程當中傳輸 cookie 包含 sessionid ，服務器根據 sessionid 獲取出會話中存儲的信息，而後肯定會話的身份信息。

cookie與session區別

• 存儲位置與安全性：cookie數據存放在客戶端上，安全性較差，session數據放在服務器上，安全性相對更高；
• 存儲空間：單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie，session無此限制
• 佔用服務器資源：session必定時間內保存在服務器上，當訪問增多，佔用服務器性能，考慮到服務器性能方面，應當使用cookie。

什麼是Token

Token的引入：Token是在客戶端頻繁向服務端請求數據，服務端頻繁的去數據庫查詢用戶名和密碼並進行對比，判斷用戶名和密碼正確與否，並做出相應提示，在這樣的背景下，Token便應運而生。

Token的定義：Token是服務端生成的一串字符串，以做客戶端進行請求的一個令牌，當第一次登陸後，服務器生成一個Token便將此Token返回給客戶端，之後客戶端只需帶上這個Token前來請求數據便可，無需再次帶上用戶名和密碼。

使用Token的目的：Token的目的是爲了減輕服務器的壓力，減小頻繁的查詢數據庫，使服務器更加健壯。

Token 是在服務端產生的。若是前端使用用戶名/密碼向服務端請求認證，服務端認證成功，那麼在服務端會返回 Token 給前端。前端能夠在每次請求的時候帶上 Token 證實本身的合法地位

session與token區別

• session機制存在服務器壓力增大，CSRF跨站僞造請求攻擊，擴展性不強等問題；
• session存儲在服務器端，token存儲在客戶端
• token提供認證和受權功能，做爲身份認證，token安全性比session好；
• session這種會話存儲方式方式只適用於客戶端代碼和服務端代碼運行在同一臺服務器上，token適用於項目級的先後端分離（先後端代碼運行在不一樣的服務器下）

Servlet是線程安全的嗎

Servlet不是線程安全的，多線程併發的讀寫會致使數據不一樣步的問題。

解決的辦法是儘可能不要定義name屬性，而是要把name變量分別定義在doGet()和doPost()方法內。雖然使用synchronized(name){}語句塊能夠解決問題，可是會形成線程的等待，不是很科學的辦法。

注意：多線程的併發的讀寫Servlet類屬性會致使數據不一樣步。可是若是隻是併發地讀取屬性而不寫入，則不存在數據不一樣步的問題。所以Servlet裏的只讀屬性最好定義爲final類型的。

Servlet接口中有哪些方法及Servlet生命週期探祕

在Java Web程序中，Servlet主要負責接收用戶請求HttpServletRequest，在doGet()，doPost()中作相應的處理，並將迴應HttpServletResponse反饋給用戶。Servlet能夠設置初始化參數，供Servlet內部使用。

Servlet接口定義了5個方法，其中前三個方法與Servlet生命週期相關：

• void init(ServletConfig config) throws ServletException
• void service(ServletRequest req, ServletResponse resp) throws ServletException, java.io.IOException
• void destory()
• java.lang.String getServletInfo()
• ServletConfig getServletConfig()

生命週期：

Web容器加載Servlet並將其實例化後，Servlet生命週期開始，容器運行其init()方法進行Servlet的初始化；

請求到達時調用Servlet的service()方法，service()方法會根據須要調用與請求對應的doGet或doPost等方法；

當服務器關閉或項目被卸載時服務器會將Servlet實例銷燬，此時會調用Servlet的destroy()方法。

init方法和destory方法只會執行一次，service方法客戶端每次請求Servlet都會執行。Servlet中有時會用到一些須要初始化與銷燬的資源，所以能夠把初始化資源的代碼放入init方法中，銷燬資源的代碼放入destroy方法中，這樣就不須要每次處理客戶端的請求都要初始化與銷燬資源。

若是客戶端禁止 cookie 能實現 session 還能用嗎？

Cookie 與 Session，通常認爲是兩個獨立的東西，Session採用的是在服務器端保持狀態的方案，而Cookie採用的是在客戶端保持狀態的方案。

但爲何禁用Cookie就不能獲得Session呢？由於Session是用Session ID來肯定當前對話所對應的服務器Session，而Session ID是經過Cookie來傳遞的，禁用Cookie至關於失去了Session ID，也就得不到Session了。

假定用戶關閉Cookie的狀況下使用Session，其實現途徑有如下幾種：

1. 手動經過URL傳值、隱藏表單傳遞Session ID。
2. 用文件、數據庫等形式保存Session ID，在跨頁過程當中手動調用。

若有錯誤或其它問題，歡迎小夥伴留言評論、指正。若有幫助，歡迎點贊+轉發分享。

歡迎你們關注民工哥的公衆號：民工哥技術之路