目錄
五層協議的體系結構
- Q：五層協議的體系結構分別是什麼？每一層都有哪些協議？
MAC地址&IP地址
MAC地址
IP地址
- Q：爲何有MAC地址還要IP地址？
- Q：既然 IP 地址不能去掉，那麼能不能去掉 MAC 地址呢？
TCP&UDP
TCP
- Q：建立&斷開TCP連接?（三次握手&四次揮手）
- Q：TCP 爲什麼是三次握手，而不是兩次或四次？
- Q：TCP 爲什麼是四次揮手？
- Q：爲什麼第四次揮手後，客戶端要等待TIME-WAIT時間2MSL，而不是直接進入CLOSED狀態？
- Q：TCP如何保證可靠傳輸？
UDP
TCP&UDP的對比與應用
- Q：TCP和UDP的區別？
- Q：播放視頻使用TCP還是UDP？
HTTP(S)
版本
長連接&短連接
- Q：響應狀態碼有哪些？
- Q：http請求有哪些？
- Q：get和post的區別？
- Q：http和https的區別？
- Q：http和tcp的區別？
- Q：http和Socket的區別？
- Q：在地址欄輸入URL進行訪問，會發生什麼？
五層協議的體系結構
Q：五層協議的體系結構分別是什麼？每一層都有哪些協議？
第一層：物理層(physical layer)
- 中繼器、集線器等，以二進制數據形式在物理媒體上傳輸數據。
- 任務：透明地傳送比特流。
第二層：數據鏈路層(data link layer)
- 以太網交換機、網卡等，接收來自物理層的位流形式的數據，並封裝成幀，傳送到上一層；同樣也將來自上層的數據幀，拆裝爲位流形式的數據轉發到物理層。
- 協議：邏輯鏈路控制LLC、媒體接入控制MAC。
第三層：網絡層(network layer)
- 負責爲分組交換網上的不同主機提供通信服務。
- 協議：IP協議、地址解析協議ARP、逆地址解析協議RARP、因特網控制報文協議ICMP。
第四層：運輸層(transport layer)
- 負責向兩個主機中進程之間的通信提供服務。
- 協議：傳輸控制協議TCP、用戶數據包協議UDP.。
第五層：應用層(application layer)
- 體系結構中的最高，直接爲用戶的應用進程提供網絡通信服務。
- 協議：文件傳輸協議FTP、遠程登錄協議TELNET、超文本傳輸協議HTTP、域名系統DNS、簡單郵件協議SMTP、簡單網絡管理協議SNMP。
數據在各層之間的傳遞過程
MAC地址&IP地址
MAC地址
**MAC地址（Media Access Control Address）**是在媒體接入層上使用的地址，也叫物理地址、硬件地址或鏈路地址，由網絡設備製造商生產時寫在硬件內部。
唯一性：每臺設備具有唯一的MAC地址。MAC地址與網絡無關，也即無論將帶有這個地址的硬件（如網卡、集線器、路由器等）接入到網絡的何處，都有相同的MAC地址，它由廠商寫在網卡的BIOS裏。
- 拓展內容：怎樣確保MAC地址唯一
MAC地址的長度爲48位（6個字節），通常表示爲12個16進制數，如：08:00:20:0A:8C:6D。其中前6位16進制數08:00:20代表網絡硬件製造商的編號，它由IEEE（Istitute of Electrical and Electronics Engineers，電氣與電子工程師協會）分配，而後6位16進制數0A:8C:6D代表該製造商所製造的某個網絡產品（如網卡）的系列號。每個網絡製造商必須確保它所製造的每個以太網設備都具有相同的前三字節以及不同的後三個字節。這樣就可保證世界上每個以太網設備都具有唯一的MAC地址。
IP地址
**IP地址(Internet Protocol Address)**即網際協議地址，是IP協議提供的一種統一的地址格式，它爲互聯網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異。
IP地址表示方式
- IP地址由32位二進制位表示，提供2^32 ≈ 42億個地址。
- 點分十進制表示：32位分成了4個8位組，相鄰8位組之間用’.'分割，每個8位組轉換成十進制數，從0到255。
一些特殊的IP地址
- 0.0.0.0：保留的IP地址，表示這個主機，這個網絡，Cisco路由器指定的默認路由。
- 255.255.255.255：泛洪廣播地址，指代互聯網上所有的主機。
- 127.x.x.x：環回地址，特殊地址，用於迴路測試。
- 127.0.0.1：表示localhost，本機IP地址。
- 169.254.x.x：如果你的主機使用了DHCP功能自動獲得一個IP地址，那麼當你的DHCP服務器發生故障，或響應時間太長而超出了一個系統規定的時間，Wingdows系統會爲你分配這樣一個地址。
- 10.x.x.x、172.16.x.x～172.31.x.x、192.168.x.x：私有地址，這些地址被大量用於企業內部網絡中。一些寬帶路由器，也往往使用192.168.1.1作爲缺省地址。
Q：爲何有MAC地址還要IP地址？
IP地址根據網絡的拓樸結構分配，保證路由選擇方案建立在網絡所處的拓撲位置基礎而不是設備製造商的基礎上。
**使用IP地址更方便數據傳輸。**數據包在這些節點之間的移動都是由ARP協議負責將IP地址映射到MAC地址上來完成的。原因
如果只用 MAC 地址，我們會發現路由器需要記住每個 MAC 地址所在的子網是哪一個（不然每一次收到數據包的時候路由器都要重新滿世界地去找這個 MAC 地址的位置）。而世界上有2^48個 MAC 地址，這就意味着即使我們給每個 MAC 地址只留 1 字節的儲存空間，每個路由器也需要 256 TB 的內存。這顯然是不可能實現的。
這就是我們需要 IP 地址的原因了。和 MAC 不同的是，IP 地址是和地域相關的。對於位於同一個子網上的設備，我們給他們分配的 IP 地址前綴都是一樣的。這個前綴就像郵政編碼一樣。這樣，路由器過 IP 地址的前綴就能知道這個設備在哪個子網上了。現在，路由器只需要記住每個子網的位置即可，大大減少了路由器所需要的內存。
Q：既然 IP 地址不能去掉，那麼能不能去掉 MAC 地址呢？
- 不能。因爲 IP 地址是要設備上線以後，才能根據他進入了哪個子網來分配的，不能。因爲 IP 地址是要設備上線以後，才能根據他進入了哪個子網來分配的。
TCP&UDP
TCP
傳輸控制協議TCP(Transmission Control Protocol)：面向連接的，數據傳輸的單位是報文段，能夠提供可靠的交付。
Q：建立&斷開TCP連接?（三次握手&四次揮手）
- 建立TCP連接：TCP的三次握手
TCP是全雙工的，即客戶端在給服務器端發送信息的同時，服務器端也可以給客戶端發送信息。
第二次握手：服務器收到SYN包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態，完成三次握手。
- 斷開TCP連接：TCP的四次揮手
由於TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。
第一次揮手：客戶端在數據發送完畢後，發送一個結束數據段FIN，用來關閉客戶到服務器的數據傳送。
第二次揮手：服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。
CLOSE-WAIT時間：服務器考慮是否還有數據需要發送給客戶端，繼續發送完畢後進入第三次揮手。
第三次揮手：服務器關閉客戶端的連接，發送一個FIN給客戶端。
第四次揮手：客戶端發回ACK報文確認，將確認序號設置爲收到序號加1。
Q：TCP 爲什麼是三次握手，而不是兩次或四次？
來自知乎的回答：https://www.zhihu.com/question/24853633
三次握手：“喂，你聽得到嗎？”
“我聽得到呀，你聽得到我嗎？”
“我能聽到你，今天balabala……”兩次握手：“喂，你聽得到嗎？”
“我聽得到呀”
“喂喂，你聽得到嗎？”
“草，我聽得到呀！！！！”
“你TM能不能聽到我講話啊！！喂！”
“……”四次握手：“喂，你聽得到嗎？”
“我聽得到呀，你聽得到我嗎？”
“我能聽到你，你能聽到我嗎？”
“……不想跟傻逼說話”
Q：TCP 爲什麼是四次揮手？
由於TCP連接是全雙工的，因此每個方向都必須單獨關閉，一共需要四個階段：服務器讀通道關閉->客戶機寫通道關閉->客戶機讀通道關閉->服務器寫通道關閉。
例如客戶端A與服務器B需要斷開TCP連接
A：“喂，我不說了 (FIN)。”
A->FIN_WAIT1
B：“我知道了(ACK)。等下，上一句還沒說完。Balabala……（傳輸數據）”
B->CLOSE_WAIT | A->FIN_WAIT2
B：“好了，說完了，我也不說了（FIN）。”
B->LAST_ACK
A：“我知道了（ACK）。”
A->TIME_WAIT | B->CLOSED
A等待2MSL，保證B收到了消息，否則重說一次“我知道了”，A->CLOSED
Q：爲什麼第四次揮手後，客戶端要等待TIME-WAIT時間2MSL（Maximum Segment Lifetime 最長報文壽命），而不是直接進入CLOSED狀態？
等待2倍最長報文壽命，能夠保證對方收到ACK後可靠關閉連接，保證本次連接的所有數據都從網絡中消失。
保證TCP協議的全雙工連接能夠可靠關閉
- 如果Client直接CLOSED了，那麼由於IP協議的不可靠性或者是其它網絡原因導致Server沒有收到Client最後回覆的ACK，那麼Server就會在超時之後繼續發送FIN，而此時Client已經CLOSED了，就找不到與重發的FIN對應的連接，最後Server就會收到RST而不是ACK，Server就會以爲是連接錯誤把問題報告給高層。
保證本次連接的重複數據段從網絡中消失
- 如果Client直接CLOSED，然後又再向Server發起一個新連接，我們不能保證這個新連接與剛關閉的連接的端口號是不同的。加入出現這樣的特殊情況：新連接和已經關閉的老連接端口號是一樣的，前一次連接的某些數據仍然滯留在網絡中，這些延遲數據在建立新連接之後纔到達Server，TCP協議就認爲那個延遲的數據是屬於新連接的，這樣就和真正的新連接的數據包發生混淆了。
Q：TCP如何保證可靠傳輸？
- 校驗和：TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到端的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。
- 確認應答：TCP傳輸的過程中，每次接收方收到數據後，都會對傳輸方進行確認應答。也就是發送ACK報文。這個ACK報文當中帶有對應的確認序列號，告訴發送方，接收到了哪些數據，下一次的數據從哪裏發。
- 序列號：TCP給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
- 超時重傳：當TCP發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。
- 連接管理：三次握手&四次揮手。
- 流量控制：TCP連接的每一方都有固定大小的緩衝空間，TCP的接收端只允許發送端發送接收端緩衝區能接納的我數據。當接收方來不及處理髮送方的數據，能提示發送方降低發送的速率，防止包丟失。
- 擁塞控制：對網絡中的路由和鏈路傳輸進行速度限制，避免網絡過載；包含四個過程：慢啓動、擁塞避免、快重傳和快恢復。
UDP
用戶數據報協議UDP(User Datagram Protocol)：無連接的，數據傳輸的單位是用戶數據報，不保證提供可靠的交付，只能提供“盡最大努力交付”。
- 特點：UDP不屬於連接型協議，因而具有資源消耗小，處理速度快的優點，所以通常音頻、視頻和普通數據在傳送時使用UDP較多，因爲它們即使偶爾丟失一兩個數據包，也不會對接收結果產生太大影響。
TCP&UDP的對比與應用
Q：TCP和UDP的區別？
TCP傳輸控制協議 UDP用戶數據報協議 面向連接 無連接 使用全雙工的可靠信道 使用不可靠信道 提供可靠的服務，即無差錯、不丟失、不重複，保證順序 盡最大努力交付，即不保證可靠交付，可能丟包，不保證順序 擁塞控制、流量控制、超時重發、丟棄重複數據等等可靠性檢測手段 無擁塞控制等 流模式，面向字節流 數據報模式，面向報文 每條TCP連接只能是點到點的 支持一對一、一對多、多對一和多對多的交互通信 用於傳輸可靠性要求高的數據 用於傳輸可靠性要求不高的數據 對系統資源的要求較多 對系統資源的要求較少 速度慢 速度快
Q：播放視頻使用TCP還是UDP？
播放視頻使用UDP。UDP適用於對網絡通訊質量要求不高、要求網絡通訊速度能儘量快的實時性應用；且視頻區分關鍵幀和普通幀，如果UDP只是丟普通幀損失並不大，取而代之的是高速率和實時性，降低資源要求。
- 拓展內容：兩者的應用場景？
TCP：通信數據完整性 > 通信實時性，如：文件傳輸、重要狀態的更新等。
UDP：通信實時性 > 通信數據完整性，如：視頻傳輸、實時通信、遊戲等。
HTTP(S)
版本
- HTTP/0.9：只接受GET一種請求方法，沒有在通信中指定版本號，且不支持請求頭。由於該版本不支持POST方法，因此客戶端無法向服務器傳遞太多信息。
- HTTP/1.0：第一個在通信中指定的版本號，至今被廣泛採用，特別是在代理服務器中。
- HTTP/1.1：當前版本，持久連接被默認採用，並能很好地配合代理服務器工作。還支持以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。
- HTTP/2：採用了新的方法來編碼、傳輸客戶端——服務器間的數據。使用多路複用技術(Multiplexing)，多路複用允許同時通過單一的 HTTP/2 連接發起多重的請求-響應消息。
長連接&短連接
- 在HTTP/1.0中，默認使用的是短連接。瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
- 從 HTTP/1.1起，默認使用長連接，用以保持連接特性。
Q：響應狀態碼有哪些？
HTTP狀態碼（HTTP Status Code）是用以表示網頁服務器超文本傳輸協議響應狀態的3位數字代碼，其中第一位數字表示響應的類型，常用的狀態碼有五大類：
- **1xx：消息。**服務器已接受請求，需要繼續處理。
- **2xx：成功。**服務器已成功接收到請求並進行處理。
- 200 OK：請求成功（其後是對GET和POST請求的應答文檔）
- 201 Created：請求被創建完成，同時新的資源被創建。
- 202 Accepted：服務器已接受請求，但尚未處理。
- **3xx：重定向。**需要客戶端採取進一步的操作才能完成請求。
- **4xx：請求錯誤。**客戶端請求錯誤，妨礙了服務器的處理。
- 400 Bad Request：服務器未能理解請求。（語義有誤、請求參數有誤）
- 401 Unauthorized：當前請求需要用戶驗證。請求需包含一個恰當的 Authorization 頭信息。
- 402 Payment Required：此代碼尚無法使用。
- 403 Forbidden：對被請求頁面的訪問被禁止。
- 404 Not Found：服務器無法找到被請求的頁面。
- **5xx：服務器錯誤。**服務器在處理請求的過程中有錯誤或者異常狀態發生。
- 500 Internal Server Error：請求未完成。服務器遇到不可預知的情況。
- 501 Not Implemented：服務器不支持所請求的功能。
- 502 Bad Gateway：服務器從上游服務器收到一個無效的響應。
- 503 Service Unavailable：臨時的服務器維護或者過載，服務器當前無法處理請求。
- 504 Gateway Timeout：網關或者代理工作的服務器嘗試執行請求超時。
Q：http請求有哪些？
- GET：請求指定的頁面信息，並返回實體主體。
- HEAD：只請求頁面的首部。
- POST：請求服務器接受所指定的文檔作爲對所標識的URI的新的從屬實體。
- PUT：從客戶端向服務器傳送的數據取代指定的文檔的內容。
- DELETE：請求服務器刪除指定的頁面。
- OPTIONS：允許客戶端查看服務器的性能。
- TRACE：請求服務器在響應中的實體主體部分返回所得到的內容。
- PATCH：實體中包含一個表，表中說明與該URI所表示的原內容的區別。
- MOVE：請求服務器將指定的頁面移至另一個網絡地址。
- COPY：請求服務器將指定的頁面拷貝至另一個網絡地址。
- LINK：請求服務器建立鏈接關係。
- UNLINK：斷開鏈接關係。
- WRAPPED：允許客戶端發送經過封裝的請求。
Q：get和post的區別？
GET：
- 當客戶端要從服務器中讀取某個資源時使用GET；
- 一般用於獲取/查詢資源信息；
- GET參數通過url傳遞，以?分割url和傳輸數據，參數之間以&相連；
- 傳遞的參數是有長度限制（因爲瀏覽器對url有長度限制），不能用來傳遞敏感信息;
- 只要在地址欄中輸入一個網址回車訪問，那麼就是GET。
POST：
- 當客戶端給服務器提供信息較多時可以使用POST；
- POST會附帶用戶數據，一般用於更新資源信息；
- POST將請求參數封裝在HTTP 請求報文體中，url看不到；
- 可以傳輸大量數據，傳參方式比GET更安全。
Q：http和https的區別？
https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，後者是443。
http的連接很簡單，是無狀態的；https協議是由SSL+http協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
Q：http和tcp的區別？
- tcp是傳輸層協議，定義數據傳輸和連接方式的規範。
- Q：http是建立在tcp協議之上的一種應用，是應用層協議，定義的是傳輸數據的內容的規範。
Q：http和Socket的區別？
- http是應用層協議，基於TCP協議，是短連接；使用“請求—響應”方式建立連接；不僅在請求時建立連接，而且客戶端向服務器端請求後，服務器才返回數據。
- Socket是對TCP/IP協議的封裝，是接口而不是協議；Socket是長連接，通常情況下Socket連接就是 TCP 連接；Socket連接一旦建立，通訊雙方開始互發數據內容，直到雙方斷開連接。
Q：在地址欄輸入URL進行訪問，會發生什麼？
- 瀏覽器向DNS服務器請求解析URL中的域名所對應的IP地址；
- 解析出IP地址後，根據該IP地址和默認端口80，和服務器建立TCP連接；
- 瀏覽器向服務器發送讀取文件的HTTP請求（該請求報文作爲TCP三次握手的第三個報文的數據發送給服務器）；
- 服務器對瀏覽器請求作出響應，並把對應的html文本發送給瀏覽器；
- 釋放TCP連接，若connection模式爲close，則服務器主動關閉TCP連接，客戶端被動關閉連接；若connection模式爲keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求；
- 瀏覽器解析接收到的html文本並顯示。
（後續補充中…）
希望這篇文章對你有幫助~