標籤：ssltls tcpip 網路通訊協定 電腦網路 osi
話說上回說到我和其他朋友們討論來討論去總算是大致解決了任意兩台電腦之間的通訊問題，不過又有新問題了：
“（我）諸位，我發現上次咱們是依據OSI模型討論問題的，但這個模型其實並不是那麼合適，有一些冗餘之處。大家想一想，會話層和展示層實際上都是與應用程式配合工作的，而物理層那些純硬體層面的問題其實並不是我們的領域，我們最多隻要處理到與硬體的介面這一層次上就足夠了。”“的確啊。”“（我）工作室需要合并一下：物理層與資料連結層合并為網路介面層，只負責硬體介面相關任務，硬體問題就不要去管它了；網路層改名為網路互連層，更為清晰；傳輸層不變；會話層，展示層和應用程式層合并為一層，統稱應用程式層。”
現在實際使用的就是TCP/IP模型，也稱作TCP/IP協議棧，由以下4層組成（這些層都不是真實存在的，只是一種抽象概念而已）：
1，網路介面層
一般認為對應OSI模型中的物理層和資料連結層，但實際上TCP/IP標準並不定義與OSI資料連結層和物理層相對應的功能。相反，它定義像位址解析通訊協定(Address Resolution Protocol,ARP)這樣的協議，提供TCP/IP協議的資料結構和實際物理硬體之間的介面，例如PC的網路卡驅動程式。
2，網路互連層
一般認為對應OSI模型中的網路層，包含IP協議、RIP協議(Routing Information Protocol，路由資訊協議)，負責資料的封裝、定址和路由。同時還包含網間控制報文協議(Internet Control Message Protocol,ICMP)用來提供網路診斷資訊。注意，ICMP其實位於IP層之上，但它卻是IP的附屬協議，在OSI模型和TCP/IP協議棧中都沒法放在一個合適的位置上。沒辦法，沒有哪個模型是完美的。
3，傳輸層
一般認為對應OSI模型中的傳輸層，能夠解決諸如端到端可靠性（“資料是否已經到達目的地？”）和保證資料按照正確的順序到達這樣的問題，也包括所給資料應該送給哪個應用程式。
4，應用程式層
一般認為對應OSI模型的會話層，展示層和應用程式層，該層包括所有和應用程式協同工作，利用基礎網路交換應用程式專用的資料的協議。應用程式層的協議是要依賴傳輸層的協議工作的，應用程式層協議運行在傳輸層的TCP或UDP協議之上（這句話的意思是應用程式層協議負責打包封裝資料提供給用戶端或伺服器端有用資訊，再由傳輸層協議接過封包進行處理和傳輸）。
“（我）諸位，任務來了：A地的PC使用者想要瀏覽網頁，對應的網站伺服器在半個地球之外的B地呢。開始吧！”"我先處理使用者的請求！（HTTP和其他幾位（其中有原來的展示層工作室成員））"“我們一起建立可靠串連！（TCP和IP異口同聲。PS：TCP和IP總是配合工作，TCP的查錯機制中就有一步是對整個TCP段和偽段頭（IP頭的一部分）檢查和，有些使用者參數TCP直接傳遞給IP層處理），應用程式層的諸位，資料封裝好之後就交給我們來處理傳輸！”“YES！（應用程式層）”“然後我們就可以把這些邏輯資訊最終轉化為物理資訊送出去了！（網路介面層的諸位）”“（我）似乎還漏了負責路由器的幾位......算了，他們太低調了，有空再介紹吧。”
“咳咳，這樣傳輸的可是明文啊，你們不在乎資料被竊聽複製篡改或者落到中間人的手裡？”
“（我和其他人）SSL？什麼中間人？”
“叫我TLS！算了，這不重要，你們想象一下這樣的情境：一個不懷好意的第三方想要竊取使用者資料，那麼他會在路上偽裝成目標網站伺服器接收資料......”
“（我）第三方無法滿足使用者請求的，而且有獨一無二的網域名稱做保證......”
“笨蛋！網域名稱系統是很不可靠的，網域名稱欺騙網域名稱劫持網域名稱汙染這些都是常有的事！[3]還有，第三方完全可以先截取使用者資料，再自己當用戶端與目標網站建立串連，從目標網站抓取資料之後再轉交給使用者，這樣使用者就根本無法察覺自己被中間人攻擊了！”
"（我）那你說該怎麼辦？（生氣中）"
“首先，使用者資料當然要被從頭到尾都被加密了，而且要是強加密，否則分分鐘被暴力破解；然後，需要有一個可靠的身分識別驗證機制，保證使用者和伺服器之間沒有第三方；還有，必須要保證一個資料包都不掉隊，要知道為了建立加密串連我可是要幫用戶端和目標伺服器握手呢，這期間要是有資料包丟了而我卻不知道，那就搞笑了！所以我要在TCP的協助下工作（TCP：OK，建立可靠串連，我最擅長了！）最後就是，用戶端和目標伺服器各自持有不能被第三方截取到的密鑰，要不然加密就失去意義了。”
“（我）那麼，雙方事先準備一對密鑰？”
“不現實。鬼才知道使用者想要和哪些網站建立HTTPS串連，怎麼個事先準備法？又該用什麼途徑把密鑰送到使用者手裡？網站伺服器要是一直都用一個密鑰，那麼在不知情的情況下被第三方偷走了怎麼辦？那樣後果會相當嚴重的！必須做到每個串連兩個獨一無二的密鑰！”
“（我）等一下，兩個？兩個不同的密鑰？”
“沒錯。如果是相同的密鑰（採用對稱式加密，例如你用7zip加密了壓縮包，密碼設定為123456，那下次開啟壓縮包解密時也是輸入123456，加密金鑰和解密密鑰是同一個），那麼怎麼秘密傳遞密鑰就又是一個無解的問題了。你總不能線下交給使用者吧（笑），如果加密傳遞，那麼就變成一個先有雞還是先有蛋的問題了：加密傳遞時的解密密鑰又該如何安全傳送？那麼只能採用非對稱式加密了，加密金鑰（公開金鑰）是明文傳遞的，解密密鑰（私密金鑰）是秘密的，這樣第三方只能幹瞪眼。不過如果第三方偽裝成目標伺服器，那麼他還是有辦法對付非對稱式加密的，所以還需要可靠的身分識別驗證機制。”
“（我）那麼你的想法具體是怎樣的呢？”
“說來話長，我的想法並不是那麼容易理解的，下次再具體說明吧。”
“（我）好吧，TLS，下次就是你的專場了（笑）。對了，你有一個缺點，介意我提出來嗎？”
“說吧，幽靈。”
“（我）拜託你能不能改掉這個不打招呼就冷不丁插話的壞毛病！（咆哮）”
SSL/TLS的原理以及互連網究竟是如何工作的（2）—“更合適的架構，大家一起努力！”
