一文搞懂TCP/IP和HTTP、HTTPS

TCP/IP概念

TCP/IP(Transmission Control Protocol/Internet Protocol,傳輸控制協議/網際協議)是指能夠在多個不同網絡間實現信息傳輸的協議簇。TCP/IP協議不僅僅指的是TCP 和IP兩個協議,而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇,同時是Internet最基本的協議、Internet國際互聯網絡的基礎,由網絡層的IP協議和傳輸層的TCP協議組成。 TCP/IP 定義了電子設備如何連入因特網,以及數據如何在它們之間傳輸的標準。

我的理解: 互聯網中的設備要相互通信,必須基於相同的方式,比如由哪一方發起通訊,使用什麼語言進行通訊,怎麼結束通訊這些都要事先確定,不同設備之間的通訊都需要一種規則,我們將這種規則成爲協議。

TCP/IP 的分層管理圖


TCP/IP協議中最重要的特點就是分層。由上往下分別爲 應用層,傳輸層,網絡層,數據鏈路層,物理層。當然也有按不同的模型分爲4層或者7層的。

爲什麼要分層呢?在設計的角度來講變得靈活了,當某一層需要修改時,只需要拿掉對相應的層,實現可拔插,無需變動所有層。對於使用者來講,屏蔽了底層複雜的傳輸過程。

應用層

TCP/IP模型將OSI參考模型中的會話層和表示層的功能合併到應用層實現。這一層主要的代表有DNS域名解析/http協議

傳輸層

在TCP/IP模型中,傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。即:傳輸控制協議TCP和用戶數據報協議UDP.

網絡層

網絡互連層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時,爲了儘快地發送分組,可能需要沿不同的路徑同時進行分組傳遞。因此,分組到達的順序和發送的順序可能不同,這就需要上層必須對分組進行排序。網絡互連層定義了分組格式和協議,即IP協議(Internet Protocol )。

物理層

該層負責 比特流在節點之間的傳輸,即負責物理傳輸,這一層的協議既與鏈路有關,也與傳輸的介質有關。通俗來說就是把計算機連接起來的物理手段。

數據鏈路層

控制網絡層與物理層之間的通信,主要功能是保證物理線路上進行可靠的數據傳遞。爲了保證傳輸,從網絡層接收到的數據被分割成特定的可被物理層傳輸的幀。幀是用來移動數據結構的結構包,他不僅包含原始數據,還包含發送方和接收方的物理地址以及糾錯和控制信息。其中的地址確定了幀將發送到何處,而糾錯和控制信息則確保幀無差錯到達。如果在傳達數據時,接收點檢測到所傳數據中有差錯,就要通知發送方重發這一幀。

UDP 和 TCP 的特點:
  • 用戶數據報協議 UDP(User Datagram Protocol):無連接;盡最大努力的交付;面向報文;無擁塞控制;支持一對一、一對多、多對一、多對多的交互通信;首部開銷小(只有四個字段:源端口、目的端口、長度、檢驗和)。UDP是面向報文的傳輸方式是應用層交給UDP多長的報文,UDP發送多長的報文,即一次發送一個報文。因此,應用程序必須選擇合適大小的報文。
  • 傳輸控制協議 TCP(Transmission Control Protocol):面向連接;每一個TCP連接只能是點對點的(一對一);提供可靠交付服務;提供全雙工通信;面向字節流。應用程序和TCP的交互是一次一個數據塊(大小不等),但TCP把應用程序看成是一連串的無結構的字節流。TCP有一個緩衝,當應該程序傳送的數據塊太長,TCP就可以把它劃分短一些再傳送。

UDP的首部格式:
圖片來源於網絡
用戶數據報有兩個字段:數據字段和首部字段,數據字段很簡單,只有8個字節,由四個字段組成,每個字段的長度都是兩個字節。各字段意義如下:

  1. 源端口: 源端口號,在需要給對方回信時使用。不需要是可全用0.
  2. 目的端口號: 這在終點交付報文時必須使用。
  3. 長度: 用戶數據報UDP的長度,最小爲8(僅首部)。
  4. 校驗和: 用於校驗用戶數據報在傳輸過程是否出錯,出錯則丟棄該報文。
TCP報文首部格式:

圖片來源於網絡
源端口和目的端口: 各佔兩個字節,分別寫入源端口號和目的端口號。
序號 : 佔4個字節;用於對字節流進行編號,例如序號爲 301,表示第一個字節的編號爲 301,如果攜帶的數據長度爲 100 字節,那麼下一個報文段的序號應爲 401。
確認號 : 佔4個字節;期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段,序號爲 501,攜帶的數據長度爲 200 字節,因此 B 期望下一個報文段的序號爲 701,B 發送給 A 的確認報文段中確認號就爲 701。
數據偏移 : 佔4位;指的是數據部分距離報文段起始處的偏移量,實際上指的是首部的長度。
確認 ACK : 當 ACK=1 時確認號字段有效,否則無效。TCP 規定,在連接建立後所有傳送的報文段都必須把 ACK 置 1。
同步 SYN :在連接建立時用來同步序號。當 SYN=1,ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接,則響應報文中 SYN=1,ACK=1。
終止 FIN : 用來釋放一個連接,當 FIN=1 時,表示此報文段的發送方的數據已發送完畢,並要求釋放連接。
窗口 : 佔2字節;窗口值作爲接收方讓發送方設置其發送窗口的依據。之所以要有這個限制,是因爲接收方的數據緩存空間是有限的。
檢驗和: 佔2個字節;檢驗和字段檢驗的範圍包括首部和數據這兩個部分。在計算檢驗和時,在TCP報文段的前面加上12字節的僞首部。
套接字: TCP連接的端點叫做套接字或插口。端口號拼接到IP地址即構成了套接字。

面試靈魂拷問

TCP的三次握手與四次揮手
  1. 第一次握手:Client將標誌位SYN置爲1,隨機產生一個值seq=J,並將該數據包發送給Server,Client進入SYN_SENT狀態,等待Server確認。
  2. 第二次握手:Server收到數據包後由標誌位SYN=1知道Client請求建立連接,Server將標誌位SYN和ACK都置爲1,ack=J+1,隨機產生一個值seq=K,並將該數據包發送給Client以確認連接請求,Server進入SYN_RCVD狀態。
  3. 第三次握手:Client收到確認後,檢查ack是否爲J+1,ACK是否爲1,如果正確則將標誌位ACK置爲1,ack=K+1,並將該數據包發送給Server,Server檢查ack是否爲K+1,ACK是否爲1,如果正確則連接建立成功,Client和Server進入ESTABLISHED狀態,完成三次握手,隨後Client與Server之間可以開始傳輸數據了。

爲什麼要進行三次握手呢?
第三次握手是爲了防止失效的連接請求到達服器,讓服務器錯誤打開連接。客戶端發送的連接請求如果在網絡中滯留,那麼就會隔很長一段時間才能收到服務器端發回的連接確認。客戶端等待一個超時重傳時間之後,就會重新請求連接。但是這個滯留的連接請求最後還是會到達服務器,如果不進行三次握手,那麼服務器就會打開兩個連接。如果有第三次握手,客戶端會忽略服務器之後發送的對滯留連接請求的連接確認,不進行第三次握手,因此就不會再次打開連接。

如果此時變成兩次揮手行不行?
舉個打電話的例子,比如:
第一次握手: A給B打電話說,你可以聽到我說話嗎?
第二次握手: B收到了A的信息,然後對A說: 我可以聽得到你說話啊,你能聽得到我說話嗎?
第三次握手: A收到了B的信息,然後說可以的,我要給你發信息啦!
結論:
在三次握手之後,A和B都能確定這麼一件事:我能聽到你,你也能聽到我。這樣,就可以開始正常通信了。如果是兩次,那將無法確定。

當數據傳送完畢,斷開連接就需要進行TCP的四次揮手:

  1. 第一次揮手,客戶端設置seq和 ACK ,向服務器發送一個 FIN(終結)報文段。此時,客戶端進入 FIN_WAIT_1
    狀態,表示客戶端沒有數據要發送給服務端了。
  2. 第二次揮手,服務端收到了客戶端發送的 FIN 報文段,向客戶端回了一個 ACK 報文段。
  3. 第三次揮手,服務端向客戶端發送FIN 報文段,請求關閉連接,同時服務端進入 LAST_ACK 狀態。
  4. 第四次揮手,客戶端收到服務端發送的 FIN 報文段後,向服務端發送 ACK 報文段,然後客戶端進入 TIME_WAIT狀態。服務端收到客戶端的 ACK 報文段以後,就關閉連接。此時,客戶端等待2MSL(指一個片段在網絡中最大的存活時間)後依然沒有收到回覆,則說明服務端已經正常關閉,這樣客戶端就可以關閉連接了。
    四次揮手
    最後完整的過程

爲什麼要四次揮手?
客戶端發送了 FIN 連接釋放報文之後,服務器收到了這個報文,就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據,傳送完畢之後,服務器會發送 FIN 連接釋放報文。

HTTP持久連接

如果有大量的連接,每次在連接,關閉都要經歷三次握手,四次揮手,這顯然會造成性能低下。因此。Http 有一種叫做 長連接(keepalive connections) 的機制。它可以在傳輸數據後仍保持連接,當客戶端需要再次獲取數據時,直接使用剛剛空閒下來的連接而無需再次握手。

HTTP和HTTPS

什麼是HTTP?

超文本傳輸協議,是一個基於請求與響應,無狀態的,應用層的協議,常基於TCP/IP協議傳輸數據,互聯網上應用最爲廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是爲了提供一種發佈和接收HTML頁面的方法。

HTTP特點:

  1. 無狀態:協議對客戶端沒有狀態存儲,對事物處理沒有“記憶”能力,比如訪問一個網站需要反覆進行登錄操作。
  2. 無連接:HTTP/1.1之前,由於無狀態特點,每次請求需要通過TCP三次握手四次揮手,和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源,服務器並不能區別是否已經響應過用戶的請求,所以每次需要重新響應請求,需要耗費不必要的時間和流量。
  3. 基於請求和響應:基本的特性,由客戶端發起請求,服務端響應。
  4. 簡單快速、靈活。
  5. 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性。

HTTP報文組成:

  1. 請求行:包括請求方法、URL、協議/版本
  2. 請求頭(Request Header)
  3. 請求正文
  4. 狀態行
  5. 響應頭
  6. 響應正文

在這裏插入圖片描述
HTTP的缺點

  1. 通信使用明文(不加密),內容可能會被竊聽。
  2. 不驗證通信方的身份,因此有可能遭遇僞裝。
  3. 無法證明報文的完整性,所以有可能已遭篡改。
什麼是HTTPS?

HTTPS:是以安全爲目標的HTTP通道,簡單講是HTTP的安全版,即HTTP下加入SSL層,HTTPS的安全基礎是SSL,因此加密的詳細內容就需要SSL。
HTTPS協議的主要作用可以分爲兩種:一種是建立一個信息安全通道,來保證數據傳輸的安全;另一種就是確認網站的真實性。


HTTPS 並非是應用層的一種新協議。只是 HTTP 通信接口部分用SSL(Secure Socket Layer)和 TLS(Transport Layer Security)協議代替而已。通常,HTTP 直接和 TCP 通信。當使用 SSL時,則演變成先和 SSL通信,再由 SSL和 TCP 通信了。簡言之,所謂 HTTPS,其實就是身披SSL協議這層外殼的 HTTP。

HTTPS通訊方式:

  1. 客戶使用https的URL訪問Web服務器,要求與Web服務器建立SSL連接。
  2. Web服務器收到客戶端請求後,會將網站的證書信息(證書中包含公鑰)傳送一份給客戶端。
  3. 客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級,也就是信息加密的等級。
  4. 客戶端的瀏覽器根據雙方同意的安全等級,建立會話密鑰,然後利用網站的公鑰將會話密鑰加密,並傳送給網站。
  5. Web服務器利用自己的私鑰解密出會話密鑰。
  6. Web服務器利用會話密鑰加密與客戶端之間的通信。

爲什麼HTTPS安全

  1. SSL不僅提供加密處理,加密方式爲混合加密。
  2. SSL而且還使用了一種被稱爲證書的手段,可用於確定方。證書由值得信任的第三方機構頒發,用以證明服務器和客戶端是實際存在的。另外,僞造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方(服務器或客戶端)持有的證書。


加密方法

對稱加密:
加密和解密同用一個密鑰的方式稱爲共享密鑰加密(Common keycrypto system),也被叫做對稱密鑰加密.

對成加密的方式效率比較低,加密速度慢。另外對稱加密存在安全隱患的問題,堆成加密的密鑰必須要傳到對方對方纔能解密,要是對方在密鑰傳輸的過程獲取到密鑰,那不是密鑰失去了加密的意義,所以完全使用對稱加密也是不安全的。

非對稱加密:
公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰(private key),另一把叫做公開密鑰(public key)。顧名思義,私有密鑰不能讓其他任何人知道,而公開密鑰則可以隨意發佈,任何人都可以獲得。公鑰加密,私鑰解密
使用公開密鑰加密方式,發送密文的一方使用對方的公開密鑰進行加密處理,對方收到被加密的信息後,再使用自己的私有密鑰進行解密。

那麼非對稱個加密就一定安全嗎?非對稱加密也不安全,爲什麼呢?因爲存在中間僞造公鑰和私鑰,假如在公鑰傳給對方的時候,有人獲取到公鑰,雖然她不能用你的公鑰做什麼,但是它截獲公鑰後,把自己僞造的公鑰發送給對方,這樣對方獲取的就不是真正的公鑰,當對方用公鑰進行加密文件,再將文件發送給對方,這樣即使截獲人沒有獲取到真正的私鑰,但是加密時的公鑰是截獲人的,他獲取到加密文件,只需要用自己的私鑰進行解密就成功獲取到文件了。

混合加密機制(對稱加密與非對稱加密結合的方式)
顧名思義也就是對稱加密和非對稱加密的方式相結合。


如何證明公開沒要本身的真實性。因爲在公開祕鑰傳輸的過程中,可能真正的公開祕鑰已經被攻擊者替換掉了。

爲了解決上述問題,於是除了CA認證證書。服務器將CA證書發送給客戶端,以進行公開密鑰加密方式通信。接到證書的客戶端可使用數字證書認證機構的公開密鑰,對那張證書上的數字簽名進行驗證,一旦驗證通過,客戶端便可明確兩件事:
一,認證服務器的公開密鑰的是真實有效的數字證書認證機構。
二,服務器的公開密鑰是值得信賴的。

那麼公開密鑰如何交接給客戶端是一件非常重要的事,因此多數瀏覽器開發商發佈版本時,會事先在內部植入常用認證機關的公開密鑰,這樣就確保公鑰是使用認證機構的公鑰避免了公鑰僞造的過程,進而確保了安全。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章