解釋什麼是報文，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協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。
  五、支持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層之上、應用層之下，爲應用程序提供加密數據通道，它採用了RC四、MD5 以及RSA等加密算法，使用40 位的密鑰，適用於商業信息的加密。同時，Netscape公司相應開發了HTTPS協議並內置於其瀏覽器中，HTTPS實際上就是SSL over HTTP，它使用默認端口443，而不是像HTTP那樣使用端口80來和TCP/IP進行通訊。HTTPS協議使用SSL在發送方把原始數據進行加密，然 後在接受方進行解密，加密和解密須要發送方和接受方經過交換共知的密鑰來實現，所以，所傳送的數據不容易被網絡黑客截獲和解密。 然而，加密和解密過程須要耗費系統大量的開銷，嚴重下降機器的性能，相關測試數據代表使用HTTPS協議傳輸數據的工做效率只有使用HTTP協議傳輸的十 分之一。假如爲了安全保密，將一個網站全部的Web應用都啓用SSL技術來加密，並使用HTTPS協議進行傳輸，那麼該網站的性能和效率將會大大下降，而 且沒有這個必要，由於通常來講並非全部數據都要求那麼高的安全保密級別，因此，咱們只需對那些涉及機密數據的交互處理使用HTTPS協議，這樣就作到魚與熊掌兼得。總之不須要用https 的地方,就儘可能不要用。