OSI參考模型以及TCP/IP模型-有解無憂

OSI(Open System Interconnection)開放式系統互聯，是計算機網路通信的基本框架；它將網路通信的作業分為7層，具體如下圖左邊藍色部分所示；它更像是一個理論上的網路分層劃分，對于我們撰寫代碼來說并沒有太多實際意義；它主要是提供了一系列“協議”，讓網路通信更加標準；通過這些協議可以促進不同設備間的兼容性；促進標準化作業；結構上也更容易分割，這樣做的好處就是利于實作和維護；就像平時我們使用的電源插板一樣，這個行業里有一個標準，只要你的電視機等電器設備在做連接電源的插口時符合這些標準，那么你就不用擔心買回來的電器無法適配家中的插座；

TCP/IP模型則是將OSI參考模型以TCP/IP協議的方式重新劃分，因為目前市場上幾乎所有的網路通信都是基于TCP/IP協議；這個模型是對OSI模型的一個簡化；主要分為5層（網路上也有針對TCP/IP模型分為4層的），其對應的簡化方式如下圖所示；

OSI 7層模型功能描述：
應用層：它是整個層級劃分中最高，也是直接面向用戶的一層，具體的體現比如：瀏覽器，各種客戶端程式等；
表示層：主要負責資料處理，比如壓縮/解壓縮，加密/解密等；
會話層：建立，管理，驗證目標與目標之間的通信會話；
傳輸層：建立目標機器與目標機器之間埠的連接并實作兩個目標之間的資料傳遞方式；
網路層：負責網路中目標機器之間的報文傳輸，這一層傳輸時依靠的是IP地址；比如路由器；解決跨網路的主機通信問題，
資料鏈路層：負責網路之間相鄰節點的可靠傳輸，傳輸依靠的是通過Mac地址；比如交換機；解決相鄰主機通信問題，
物理層：原始信號傳輸，資料傳遞介質，比如網線之類的；物理層的任務就是透明地傳輸位元流，

舉個通俗易懂的“栗子”來說明一下這7層的含義：

我想寫一封情書給一個漂亮姑娘；我最終的目的是想要通過書信里的文字讓她能理解我的心意，但我們距離很遠，又沒有手機，所以我決定以寫信的方式進行；再講例子之前，要先注意一點，不要把應用層，表示層等這些劃分的層級與具體的事物關聯起來去做具體化想象，而應該“協議化”，“標準化”，后面有表述；

1：我現在想寫信，內容就是“我愛你，漂亮的姑娘”，可是這么肉麻的話，我希望就我和她能看到具體的內容；在這里，可以把“我”看成某個應用，我要傳遞資料給另外一臺機器上的某個應用，但是我傳遞給她的資料一定是根據某些“協議”來的（HTTP協議等），比如，她是一個文化程度不高的人，看不懂英文，如果我把信的具體內容寫成英文，她看不懂，那么這封信即使傳遞出去了也沒有價值；所以相當于我們很默契的約定好了，這封信應該用中文寫；“我”這個應用，以及使用了中文寫的文字，就屬于應用層應該遵守的協議以及該干的事情；所以不能簡單的將“我”這個應用來代表會話層，而應該將“我”這個應用，以及約定好的中文形式內容合起來并為會話層；

2：我買了一個信封，將我寫的內容放到信封里封起來；這個程序就是表示層，內容被我套進了信封進行了加密，并且在信封上寫上了姑娘的地址，貼了郵票；而信封也是因為我遵守了寫信這件事的一些俗成約定與協議，所以我不會隨意用一個盒子或者紙盒將信放進去（我遵守的信封“協議”，以及使用信封加密這個程序都應該稱為表示層，而不是單純將信封理解為表示層），接下來就是交給下一層（會話層）處理；

3：會話層，相當于郵局的部分管理系統，郵局拿到我的信之后，需要在郵票上蓋章，只有蓋完章之后才說明了這封信的“合法性”，這封信不管是在郵局的哪個網點，不管這個網點是100平的規模，還是只有一個10平米的小網點，看到這封信上有郵票，并且蓋了章，就知道這封信是“合法”能通行的；所以會話層相當于一個管家，它負責對資料進行相關的驗證管理，如果你貼了郵票，我蓋了章你才能在整個郵局系統通行，不然就無法通行，

4：傳輸層，會話層已經對我的信進行了“合法”校驗等操作，傳輸層拿到這個“合法”資料后，開始進行裝車，但是我不能隨意用摩托車或者其他貨車去裝載這個信；而應該使用郵局內部系統規定的方式；比如，郵局內部的“協議”是，所有的信都必須使用帶有郵政標識的綠色的貨車進行運輸，也只有這種貨車才能不管在郵局的哪個網點都擁有通行的權力，不然其他網點按照規矩辦事可能會拒絕你的信，因為你沒按照我規定的貨車運貨；這里就相當于我已經把要發送的內容按照規定的方式都已經裝載好了，這規定的方式遵守的協議就是TCP或者UDP；這一層說的埠與埠之間的連接;

5：網路層，車已經裝載完畢，郵局開始運送我的信，而郵局送信使用的是貨運車，貨運車根據我信封的地址，送到漂亮姑娘住的小區；而漂亮姑娘住的小區地址就相當于是IP地址；而這一層就是我們平常說的IP協議層；而這個地址按照協議就是必須先寫省份，再寫市之類的格式；

6：資料鏈路層，當信被送到小區門口后，發現進不去，因為門衛（交換機）說，本小區的信都放在我這里，我再幫你送上去；資料鏈路層就是將位元流組合成位元組，再將位元組組合成幀，通過mac地址（姑娘的門牌號）進行差錯檢測；

7：這封信在整個的傳輸程序中，走的是高速，還有其他道路，這些路和運送信的車都屬于物理層，它們就是真正保證我的信能夠安全快速送達的最底層保證；信號的最終傳輸都是通過物理層實作的；常用的一些設備比如網線；

以上兩張圖片摘自網路

從上面兩張圖我們也能看出，各層與各層之間都有一定“具體的物體”，這些物體在運行時又分別遵守了在該層應該遵守的協議；但這些模型終究是要對兩個目標機器之間的資料傳輸；再來一張終極解釋的圖片，看看兩個機器之間如何進行通信；

Socket（套接字）底層通信原理

Socket通信一直給人一種非常神秘的感覺，如果要了解Socket就必須先從“宏觀”的角度來理清楚它的原理；

首先，Socket最開始是在Unix/Linux上使用的，之后由于其方便，高效，目前絕大部分市場上的應用都采用的是Socket；如果不熟悉Unix/Linux也沒關系，但需要知道的是，在Unix/Linux中，可以認為“一切皆檔案”，這里的檔案的怎么解釋？一個檔案如果要進行修改必須先open操作，然后read/write操作，之后再close，那也就意味著Socket本質的通信方式也是打開某個“檔案”，然后讀取，然后關閉；

另外，再說一下行程間通信，系統的每個行程都是在自己的“范圍”內運行，如果兩個行程要進行通信就必須通過“系統”提供的其他方式；比如Android中的行程間通信就是靠binder機制；而網路機器之間的應用資料傳遞也是“行程間通信”，只是之前不夸機器，這次夸了機器而已；如果對binder機制不是特別熟悉，那么我們可以先把整個Binder機制的底層操作邏輯看成一個檔案，（在windows電腦上，我們可以通過局域網看到其他電腦分享的檔案，同時也具備對該檔案一定的操作權限）

如上圖所示，某“檔案”就代表了整個Binder機制的底層邏輯；A機器的A應用通過Binder機制，將自己的資料寫入到A機器系統提供的“某檔案”，然后A機器的“某檔案”通過Socket的方式與B機器的“某檔案”進行資料的傳輸，當B應用需要獲取從A應用來的資料時，只需要實時監聽B系統提供的“某檔案”是否發生了改變，改變了什么即可；

但這種“檔案操作”對于上層應用來說是非常不友好的，所以系統使用了Scoket（套接字）的方式來幫助我們建立起他們之間的鏈接，開發者只需要關注Socket的API即可；

上圖來源于網路，Socket就是封裝了TCP/IP那一層；

再來看一下Scoket的通信原理；

此圖來源于網路：（原文鏈接：https://www.cnblogs.com/JavaHxm/p/10968210.html）

再根據之前我們說到的“宏觀”方式來理解這幅圖，TCP服務器有一個“檔案”需要共享出去，并且時刻知道它發生了哪些改變，當發生了某些改變時，服務器對這個檔案做相應的業務修改；為了能夠實作共享，于是使用了Socket，Socket通過呼叫socket(),bind()，listen()，accept()方法來創建了一個“檔案”，并且時刻監聽著；TCP客戶端則按照服務器的方式創建Socket并通過connect()方法去連接服務器的“檔案”，不停的往“檔案”中寫入資料，服務器則根據“檔案”里資料的變化來實行自己的業務邏輯；直到滿足兩者的交流后再通過close()方法進行關閉；想更加自信的了解不同的方法具體做了什么事情，可以訪問上圖底部提供的參考連接；

TCP的3次握手和四次揮手

3次握手解讀

第一次：客戶端發送請求給服務器，請求包括syn=1，以及隨機產生的seq數值；

第二次：服務器收到客戶端發來的資訊后，先確認請求，然后向客戶端發送ack number（ack等于seq+1），syn=1，ack=1；

第三次：客戶端檢查ack是否正確，即第一次發過去的seq是不是已經加1了，以及ack是否為1，如果正確；客戶端會再發送ack number（seq+1），ack=1，服務器確認seq值以及ack=1后則連接成功；

4次揮手解讀

第一次：客戶端發起中斷連接請求，發送FIN報文；

第二次：服務器接收到客戶端的FIN后，回饋一個ACK給客戶端，告訴客戶端，你的請求我已經收到，但請等待一下，我可能還有資料要發給你；客戶端進入FIN_WAIT狀態（此時還沒有關閉，只是客戶端想斷開連接）；

第三次：服務器發送FIN給客戶端，告訴客戶端我已經發送完資料了，現在你可以關閉連接；

第四次：客戶端接收到服務器的FIN，再發送ACK給服務器，服務器收到ACK后，則斷開連接；

為什么三次握手，確有4次揮手？

因為服務器接到客戶端發送的請求后，只需要校驗請求是否合法，如果ok則可以直接連接；但揮手時有一個特殊情況需要處理，當客戶端需要斷開連接時，服務器還有可能有一些資料是沒有發送給客戶端的，當服務器接到客戶端發送的斷開請求時，必須要先確認自己的資料都已經發送完畢了，所以接收到客戶端的請求時，服務器端回應兩次；