1. 程式人生 > >解釋什麼是報文,http、https、Tcp的三次握手和四次揮手

解釋什麼是報文,http、https、Tcp的三次握手和四次揮手

什麼是報文?

  報文(message)是網路中交換與傳輸的資料單元,即站點一次性要傳送的資料塊。報文包含了將要傳送的完整的資料資訊,其長短很不一致,長度不限且可變。

 有何作用?

    報文多是多個系統之間需要通訊的時候,比如銀行ESB系統到網關係統再到銀聯絡統。在這中間報文就承擔了裝載資料,運輸資料的功能,可能在這三個系統中報文的格式互不相同,但是其承載的資料都是一樣的。

 

什麼是http?

  HTTP是hypertext transfer protocol(超文字傳輸協議)的簡寫,它是TCP/IP協議的一個應用層協議,用於定義WEB瀏覽器與WEB伺服器之間交換資料的過程。客戶端連上web伺服器後,若想獲得web伺服器中的某個web資源,需遵守一定的通訊格式,HTTP協議用於定義客戶端與web伺服器通迅的格式。

在日常的前端開發裡面,我們離不開請求後端的介面獲取資料對頁面進行渲染,那麼可以說前端開發對於http的使用是幾乎無時無刻的在使用。那麼我們常用的Ajax就是基於http協議進行資料傳輸和接受的,所以前端開發工程師必須對http有一定程度的瞭解。

http的特點

  • 簡單快速:客戶向伺服器請求服務時,只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單,使得HTTP伺服器的程式規模小,因而通訊速度很快。
  • 靈活:HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
  • 無連線:無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求,並收到客戶的應答後,即斷開連線。採用這種方式可以節省傳輸時間。
  • 無狀態:HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊,則它必須重傳,這樣可能導致每次連線傳送的資料量增大。另一方面,在伺服器不需要先前資訊時它的應答就較快。
    5、支援B/S及C/S模式。

那麼前端對於這些特點,我們需要關注的點有以下幾點:

  1. 請求方法中,我們一般是使用GET和POST為主,當然如果你想要遵從RESTful API的話就不單單是用GET和POST了,還有PUT、PATCH、DELETE了。
  2. Content-Type是一個修改請求體的資料格式的引數(例如:POST),在前端開發的過程中,我們和不同業務線的後端對接,可能他們接收POST的請求體的接收格式不一樣,經常會遇到我為什麼我之前提交的方式都可以,換成這個專案為什麼後端收不到,那麼第一時間可以檢查一下提交的資料格式是否是後端接收的格式,一般能解決90%這一類問題。具體的Content-Type型別之後再詳細說明。
  3. 無狀態是一個很大的特點,也是一個很大的缺點,因為有這個特性,所以伺服器不需要關注請求這個介面的使用者的狀態,但是往往實現一些像登入這一類的功能的時候,或者商城的列表頁根據使用者不同,可以做一些精準化展示資料的時候就很麻煩了,所以才會出現SESSION和COOKIES這兩個東西。

http的請求方式:

  1. OPTIONS - 返回伺服器針對特定資源所支援的HTTP請求方法,也可以利用向web伺服器傳送‘*’的請求來測試伺服器的功能性
  2. HEAD - 向伺服器索與GET請求相一致的響應,只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下,就可以獲取包含在響應小訊息頭中的元資訊。
  3. GET - 向特定的資源發出請求。它本質就是傳送一個請求來取得伺服器上的某一資源。資源通過一組HTTP頭和呈現資料(如HTML文字,或者圖片或者視訊等)返回給客戶端。GET請求中,永遠不會包含呈現資料。
  4. POST - 向指定資源提交資料進行處理請求(例如提交表單或者上傳檔案)。資料被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函式:web_submit_data,web_submit_form
  5. PUT - 向指定資源位置上傳其最新內容
  6. DELETE - 請求伺服器刪除Request-URL所標識的資源
  7. TRACE - 回顯伺服器收到的請求,主要用於測試或診斷
  8. CONNECT - HTTP/1.1協議中預留給能夠將連線改為管道方式的代理伺服器。

http的基本連結原理

因為http是基於TCP/IP的協議,所以還是要說說這個面試老題,3次握手4次揮手的問題了。

三次握手:

  1. 第一次握手:客戶端傳送了一個帶有SYN(建立連線)的Tcp報文到伺服器,這個三次握手中的開始。表示客戶端想要和服務端建立連線。
  2. 第二次握手:服務端接收到客戶端的請求,返回客戶端報文,這個報文帶有SYN(建立連線)和ACK(確認)標誌,詢問客戶端是否準備好。
  3. 第三次握手:.客戶端再次響應服務端一個ACK(確認),表示我已經準備好。

為什麼要3次握手那麼麻煩?

當然這個其實作為一個前端不需要關注,因為其實基本沒你什麼事情,但是瞭解到這一些基本知識,對於日後排除頁面效能的時候,某些指標就是需要了解整個http連結過程了。言歸正傳,為什麼需要三次握手呢?

因為第一次握手的時候,客戶端傳送了一個請求,之後因為網路原因或者任何原因,客戶端斷網了或者沒有收到伺服器回傳的ACK確認碼,在這種情況下,如果伺服器不去接收客戶端回傳ACK碼確認,就開啟連結,在這個時候就浪費了伺服器的資源了,所以第三次握手就為這樣的一種情況設計的,伺服器必須確認客戶端接收到了ACK碼才開啟連線。

 

四次揮手:

  1. 第一次握手:客戶端傳送一個FIN(結束),用來關閉客戶到服務端的連線。
  2. 第二次握手:服務端收到這個FIN,他發回一個ACK(確認),確認收到序號為收到序號+1,和SYN一樣,一個FIN將佔用一個序號。
  3. 第三次握手:服務端傳送一個FIN(結束)到客戶端,服務端關閉客戶端的連線。
  4. 第四次握手:客戶端傳送ACK(確認)報文確認,並將確認的序號+1,這樣關閉完成。

那麼為什麼關閉一個http請求需要走4次握手呢?

因為伺服器收到了客戶端的FIN報文請求關閉連線的時候,伺服器端很可能並不會立即關閉連線,而是需要等待所有資料都傳輸完畢後才進行關閉,所以會先回復一個ACK報文告訴客戶端收到了FIN報文,當資料都傳輸完畢了,才使用FIN報文告訴客戶端現在可以進行關閉了,客戶端回覆ACK報文進行確認,彼此才真正關閉連線。因此需要4次握手。

什麼是https?

    HTTPS(Secure Hypertext Transfer Protocol)安全超文字傳輸協議 它是一個安全通訊通道,它基於HTTP開發,用於在客戶計算機和伺服器之間交換資訊。它使用安全套接字層(SSL)進行資訊交換,簡單來說它是HTTP的安全版。 它是由Netscape開發並內置於其瀏覽器中,用於對資料進行壓縮和解壓操作,並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安 全全套接字層(SSL)作為HTTP應用層的子層。(HTTPS使用埠443,而不是象HTTP那樣使用埠80來和TCP/IP進行通訊。)SSL使 用40 位關鍵字作為RC4流加密演算法,這對於商業資訊的加密是合適的。HTTPS和SSL支援使用X.509數字認證,如果需要的話使用者可以確認傳送者是誰。 

HTTPS和HTTP的區別:

  https協議需要到ca申請證書,一般免費證書很少,需要交費。 http是超文字傳輸協議,資訊是明文傳輸,https 則是具有安全性的ssl加密傳輸協議 http和https使用的是完全不同的連線方式用的埠也不一樣,前者是80,後者是443。
http的連線很簡單,是無狀態的 HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議 要比http協議安全 HTTPS解決的問題:
1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證明伺服器用途型別的證書. 改證書只有用於對應的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,採用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的資料的洩密和被竄改
一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.
b) 服務端和客戶端之間的所有通訊,都是加密的. i. 具體講,是客戶端產生一個對稱的金鑰,通過server 的證書來交換金鑰. 一般意義上的握手過程. ii. 加下來所有的資訊往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有金鑰. 當然竄改也就沒有什麼意義了.
少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這裡客戶端證書,其實就類似表示個人資訊的時候,除了使用者名稱/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.
b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.像我用的交通銀行的網上銀行就是採取的這種方式。 HTTPS 一定是繁瑣的. a) 本來簡單的http協議,一個get一個response. 由於https 要還金鑰和確認加密演算法的需要.單握手就需要6/7 個往返. i. 任何應用中,過多的round trip 肯定影響效能. b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密. i. 儘管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 晶片. 如果CPU 信能比較低的話,肯定會降低效能,從而不能serve 更多的請求.

符:SSL的簡介:
SSL是Netscape公司所提出的安全保密協議,在瀏覽器(如Internet Explorer、Netscape Navigator)和Web伺服器(如Netscape的Netscape Enterprise Server、ColdFusion Server等等)之間構造安全通道來進行資料傳輸,SSL執行在TCP/IP層之上、應用層之下,為應用程式提供加密資料通道,它採用了RC4、MD5 以及RSA等加密演算法,使用40 位的金鑰,適用於商業資訊的加密。同時,Netscape公司相應開發了HTTPS協議並內置於其瀏覽器中,HTTPS實際上就是SSL over HTTP,它使用預設埠443,而不是像HTTP那樣使用埠80來和TCP/IP進行通訊。HTTPS協議使用SSL在傳送方把原始資料進行加密,然 後在接受方進行解密,加密和解密需要傳送方和接受方通過交換共知的金鑰來實現,因此,所傳送的資料不容易被網路黑客截獲和解密。 然而,加密和解密過程需要耗費系統大量的開銷,嚴重降低機器的效能,相關測試資料表明使用HTTPS協議傳輸資料的工作效率只有使用HTTP協議傳輸的十 分之一。假如為了安全保密,將一個網站所有的Web應用都啟用SSL技術來加密,並使用HTTPS協議進行傳輸,那麼該網站的效能和效率將會大大降低,而 且沒有這個必要,因為一般來說並不是所有資料都要求那麼高的安全保密級別,所以,我們只需對那些涉及機密資料的互動處理使用HTTPS協議,這樣就做到魚與熊掌兼得。總之不需要用https 的地方,就儘量不要用。