后端工程師，老師教的七層網路模型你用在了哪里？

計算機網路算是計算機課里公認比較難的課之一，OSI七層網路模型，這個詞估計大部分人都還記得，但還能完全的背出具體都有哪些層嗎？更不用說每層具體的含義，我是有點模糊了，除了具體的開發語言，資料結構和演算法算是平時用到比較多的課程了，

都說學以致用，那么這個網路模型對于我們實際作業中有什么用途呢？比如我寫了個web頁面，或者一個Restful API，這和七層網路模型是怎么對應的呢？

首先從我們熟悉的請求處理程序開始，

1. 簡單的請求處理程序

用一幅圖簡單描述一下用戶發送請求、服務器接收并處理請求直至回傳最終結果的程序，

當客戶端向Web服務器發送一個請求后，服務器收到HTTP請求，如果是靜態網站，則會直接回傳對應的請求檔案，

如果是動態語言的網站，HTTP服務器會將請求經過處理后轉給對應的動態語言程式處理，例如Java、C#、Go、PHP和Python等，這些程式根據用戶發過來的請求，進行處理后回傳結果給HTTP服務器，HTTP服務器再講結果處理并回傳給用戶，

這里用到的就是我們熟悉的HTTP協議，再看下OSI七層模型，

2. 回顧一下OSI七層模型

開放式系統互聯通信參考模型，即Open System Interconnection Reference Model，縮寫為 OSI, 是一種概念模型，由國際標準化組織提出，一個試圖使各種計算機在世界范圍內互連為網路的標準框架，

**注意：**常見的光纖、同軸電纜、雙絞線、Rj45介面等傳輸介質也被稱為傳輸媒體，**但傳輸媒體并不是在物理層，**而是在物理層的下一層，因為物理層是模型的第一層，所以也稱傳輸媒體為第0層，在傳輸媒體中傳輸的是信號，但傳輸媒體并不知道所傳輸的信號代表的是什么意思，物理層則因為規定了電氣特性，因此能夠識別所傳輸的位元流，這是考試經常出現的問題之一，

下圖所示為資料DATA從發送端到達接收端的中間處理程序：

當發送端需要發送資料(DATA)該接收端時，發送端大概流程：

• 用戶操作應用層的應用，產生的發送資料通過應用層的介面進入應用層，
• 從應用層開始，逐級對DATA進行包裝，加上對應層的報頭，例如圖中的AH、PH、SH、TH、NH等，
• 表示層并不“關心”應用層的資料格式，而是把整個應用層遞交的資料報看成是一個整體進行封裝，即加上表示層的報頭(PH)，然后遞交到會話層，
• 資料鏈路層除了要添加報頭DH外，還會添加一個報尾DT還, 最終的一幀資料，

接收端：

• 接收端相當于是對發送程序的逆向，逐級抽絲剝繭，去掉各種報頭報尾，最侄訓到接收端的應用層，
• 應用層對接收到的報文進行處理，

感覺HTTP協議和這個七層模型都是用于網路傳輸，那么二者有什么關系呢？這就必須要說一下TCP/IP協議，

3. TCP/IP協議

TCP/IP協議，英文為Transmission Control Protocol/Internet Protocol，是指能夠在多個不同網路間實作資訊傳輸的協議簇，TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇，當然本文的重點HTTP協議也在其中， 只是因為在TCP/IP協議中TCP協議和IP協議最具代表性，所以被稱為TCP/IP協議，所以HTTP協議是TCP/IP協議簇中的一員，

3.1 五層的體系結構？

四層結構：TCP/IP是一個四層的體系結構，它包含應用層、運輸層、網際層和網路介面層，見下圖中的b，

那么TCP/IP的四層的體系結構和OSI 的七層協議有什么關系呢？

OSI 的體系結構的概念清楚、理論也較完整，但它是一個概念模型，相對既復雜又不實用，所以TCP/IP采用了四層結構，不過從實質上講，TCP/IP只有最上面的三層，因為最下面的網路介面層并沒有什么具體內容，

五層結構：五層結構又是什么呢？因此在學習計算機網路的原理時往往采取對上面兩個協議的折中的辦法，即綜合OSI和TCP/IP的優點，采用一種只有五層協議的體系結構(下圖中的c)，這樣既簡潔又能將概念闡述清楚，有時為了方便，也可把最底下兩層稱為網路介面層，

下圖說明了這幾種結構的關系：

3.2 HTTP協議與TCP/IP協議的關系

常見的HTTP服務有Apache、 Nginx 、IIS等，比較通用的機制就是創建一個行程監聽80（443）介面，及時發現客戶端發來的連接請求，當監聽到連接請求并成功建立TCP連接之后，客戶端就向服務器發送HTTP請求，服務器決議該請求并回傳對應的結果，最后,釋放TCP連接，

從三次握手的角度說一下HTTP協議與TCP/IP協議的關系：

用戶在發出一個請求后，HTTP協議首先要和Web服務器建立 TCP連接，這需要使用三次握手，當握手兩次之后（即過了一個RTT時間后)，客戶端就把HTTP請求報文，作為建立TCP連接的第三次握手的資料，發送給HTTP服務器，服務器收到HTTP請求報文后，就把所請求的檔案作為回應報文回傳給客戶端，

大概的機制如下圖：

從圖中可以看出，向服務器請求一個檔案所需的總時間等于該檔案的傳輸時間（與檔案大小成正比）加上兩倍的RTT 時間(一個RTT用于連接TCP連接，另一個RTT用于請求和接收檔案，)，

這也體現了HTTP/1.0的主要缺點，就是每個請求都要有兩倍的RTT 的開銷，若一個主頁上有很多鏈接的物件（如圖片等）需要依次進行鏈接，那么每一次鏈接下載都導致2倍RTT的開銷，另一種開銷就是客戶端和服務器每一次建立新的TCP連接都要分配快取和變數，特別是HTTP服務器往往要同時服務于大量客戶的請求，所以這種非持續連接會使HTTP服務器的負擔很重，好在瀏覽器都能夠打開5~10個并行的TCP連接，而每一個TCP連接處理客戶的一個請求，因此，使用并行TCP連接可以縮短回應時間，

從這個痛點出發，HTTP/1.1協議較好地解決了這個問題，它使用了持續連接(persistent connection)，所謂持續連接就是HTTP服務器在發送回應后仍然在一段時間內保持這條連接，使同一個客戶（瀏覽器）和該服務器可以繼續在這條連接上傳送后續的HTTP請求報文和回應報文，這并不局限于傳送同一個頁面上鏈接的檔案，而是只要這些檔案都在同一個服務器上就行，

3.3 HTTP報文樣式

一個http請求可以分為請求地址和請求方法，請求頭和請求體，如下圖所示

這是已POST請求的例子，請求體中的⑤請求內容是一段JSON，目的是新建一個用戶，

請求頭是由一些key-value組成的集合，常見的元素有請求的長度、③請求內容格式和④期望的回傳結果格式等，

③請求內容格式注明了當前請求體中的內容的格式，本例是JSON，

④期望的回傳結果格式，告訴服務器，自己期望回傳JSON格式的內容，服務器端如果支持多種格式的回傳，例如支持JSON、XML等，這里可以根據客戶端的期望回傳對應的格式，所以這里只是期望，服務器如果不支持，還是有可能回傳其他格式的回應資料，

回應結果也分為頭和體兩部分，大概結構如下圖：

回應頭部主要包括HTTP協議的版本、狀態碼、回應內容的格式等，回應體一般為回應的具體內容，

所以，后端服務器就是實作了接收HTTP請求并進行處理，然后回傳相應結果的功能，而后端服務一般由HTTP服務器（IIS、Apache、Tomcat等，Tomcat比較特殊，既實作了HTTP服務器的功能，又實作了servlet容器的功能，）+處理程式組成，

3.4 HTTPS

HTTPS不是一種新協議，而是 HTTP 通信介面部分用 SSL和 TLS協議代替而已，

在上文中，HTTP 直接和 TCP 通信，當使用HTTPS時，中間加了一層SSL，需要先和 SSL通信，再由 SSL和 TCP 通信了，

大概的區別如下圖：

具體HTTPS相關的知識比較多，就不在此贅述了，

4.參考資料：

《計算機網路》《圖解HTTP》