一、TCP/IP協(xié)議

作為一個小萌新，當然我無法將tcp/ip協(xié)議的大部分江山和盤托出，但是其中很多面試可能問到的知識，我覺得有必要總結一下！
首先，在學習tcp/ip協(xié)議之前，我們必須搞明白什么是tcp/ip協(xié)議。

1、什么是tcp/ip協(xié)議

書本上的定義：網(wǎng)絡協(xié)議是為計算機網(wǎng)絡中進行數(shù)據(jù)交換而建立的規(guī)則、標準或約定的集合。

比如：中國人之間交流使用漢語，要遵循漢語的語法結構和發(fā)音；那如果我們跟英國人交流的話，就要使用英語的語法結構和發(fā)音；人與人之間交流所用的語言就是一種協(xié)議。對于計算機來說，兩臺機器之間的通信就要制定各種各樣的協(xié)議，例如：文件傳輸使用TCP協(xié)議，域名系統(tǒng)使用DNS協(xié)議。數(shù)據(jù)根據(jù)協(xié)議規(guī)定的內容進行傳輸，這樣就實現(xiàn)了兩臺機器之間的通信。

總的來說：網(wǎng)絡協(xié)議就是人為規(guī)定的一套通信規(guī)范，只要雙方都遵循這個規(guī)范，就能實現(xiàn)交流。
TCP/IP具體含義：從字面意義上講，可能會認為 TCP/IP 是指 TCP 和 IP 兩種協(xié)議。然而多數(shù)情況下，它只是利用ip進行通信時所必須用到的協(xié)議群的統(tǒng)稱。具體來說，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都屬于 TCP/IP 協(xié)議。他們與 TCP 或 IP 的關系緊密，是互聯(lián)網(wǎng)必不可少的組成部分。TCP/IP 一詞泛指這些協(xié)議，因此，有時也稱 TCP/IP 為網(wǎng)際協(xié)議群。

2、tcp/ip協(xié)議的分層

TCP/IP協(xié)議族中有一個重要的概念是分層，提到協(xié)議分層，通常會聯(lián)想到OSI的七層協(xié)議經(jīng)典架構，但是TCP/IP協(xié)議族的結構則稍有不同，但是二者之間有一定聯(lián)系，如圖所示：

tcp/ip協(xié)議分為“應用層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層”。

2.1、應用層

顧名思義，應用層就是我們應用和接觸最多的層，我們最常寫的Java程序，甚至QQ微信都是應用層的產物。
應用層決定這次通信的應用類型，比如說FTP、DNS、SMTP等等，同時HTTP協(xié)議也屬于應用層的范圍。通俗來講，應用層決定這一次通信要干嘛。

2.2、傳輸層

應用層把數(shù)據(jù)丟給傳輸層后，傳輸層把數(shù)據(jù)進行一下包裝，包裝紙上面寫著“源端口、目的端口、序號、確認序號、檢驗和等TCP自身的數(shù)據(jù)，
傳輸層提供兩臺計算機之間的數(shù)據(jù)傳輸，傳輸層中包含著兩個很吊的協(xié)議，分別是TCP和UDP協(xié)議，而且沒有第三種協(xié)議可走。
TCP和UDP協(xié)議的區(qū)別

1、基于連接（TCP）與無連接(UDP)。

2、TCP要求系統(tǒng)資源較多，UDP較少。

3、UDP程序結構較簡單。
4、流模式（TCP）與數(shù)據(jù)報模式(UDP)。

5、TCP保證數(shù)據(jù)正確性，UDP可能丟包。

6、TCP保證數(shù)據(jù)順序，UDP不保證。
7、TCP面向連接（如打電話要先撥號建立連接）;UDP是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
8、TCP提供可靠的服務。也就是說，通過TCP連接傳送的數(shù)據(jù)，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付。
9、TCP面向字節(jié)流，實際上是TCP把數(shù)據(jù)看成一連串無結構的字節(jié)流;UDP是面向報文的，沒有擁塞控制，因此網(wǎng)絡出現(xiàn)擁塞不會使源主機的發(fā)送速率降低（對實時應用很有用，如IP電話，實時視頻會議等）。
10、每一條TCP連接只能是點到點的;UDP支持一對一，一對多，多對一和多對多的交互通信。
11、TCP首部開銷20字節(jié);UDP的首部開銷小，只有8個字節(jié)。

12、TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道。

此外，面試中經(jīng)常提及的三次握手，四次揮手就是TCP協(xié)議的部分內容 。

三次握手，四次揮手
TCP有6種標志符

	1、SYN(synchronous),建立聯(lián)機
	2、ACK(acknowledgement),確認
	3、PSH(push),傳輸
	4、FIN(finish),結束
	5、RST(reset),重置
	6、URG(urgent),緊急

1、三次握手：

概念：指在發(fā)送數(shù)據(jù)的準備階段，服務器和客戶端之間需要三次交互

第一次握手：建立連接時，客戶端向服務器發(fā)送一個SYN包，并進入SYN_SENT狀態(tài)，等待服務器確認

第二次握手：當服務器收到客戶端的請求后，此時要給客戶端給一個確認信息ACK,同時發(fā)送SYN包，此時服務器進入 SYN_RECV狀態(tài)

第三次握手：客戶端收到服務器發(fā)的ACK+SYN包后，向服務器發(fā)送ACK,發(fā)送完畢之后，客戶端和服務器進入
ESTABLISHED(TCP連接成功)狀態(tài)，完成三次握手

2、四次揮手
概念：所謂四次揮手就是說關閉TCP連接的過程，當斷開一個TCP連接時，需要客戶端和服務器共發(fā)送四個包確認

第一次揮手：客戶端發(fā)送一個FIN,用來關閉客戶端到服務器的數(shù)據(jù)傳輸，客戶端進入FIN_WAIT_1狀態(tài)

第二次揮手：服務器收到FIN后，發(fā)送一個ACK給客戶端，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號），服務器進入CLOSE_WAIT狀態(tài)

第三次揮手：服務器發(fā)送一個FIN,用來關閉服務器到客戶端的數(shù)據(jù)傳輸，服務器進入LAST_ACK狀態(tài)

第四次揮手：客戶端收到FIN后，客戶端進入TIME_WAIT狀態(tài)，接著發(fā)送一個AKC給服務器，確認序號為收到序號+1，服務器進入CLOSED狀態(tài)，完成四次揮手

TCP四次揮手過程中通信雙方狀態(tài)解析：

FIN_WAIT_1:?其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：

1. FIN_WAIT_1狀態(tài)：實際上是當SOCKET在ESTABLISHED狀態(tài)時，它想主動關閉連接，向對方發(fā)送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)。而當對方回應ACK報文后，則進入到FIN_WAIT_2狀態(tài)，當然在實際的正常情況下，無論對方何種情況下，都應該馬上回應ACK報文，所以FIN_WAIT_1狀態(tài)一般是比較難見到的，而FIN_WAIT_2狀態(tài)還有時常?？梢杂胣etstat看到。（主動方）
2. FIN_WAIT_2：實際上FIN_WAIT_2狀態(tài)下的SOCKET，表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還有點數(shù)據(jù)需要傳送給你(ACK信息)，稍后再關閉連接。（主動方）

CLOSE_WAIT:表示在等待關閉。當對方close一個SOCKET后發(fā)送FIN報文給自己，你系統(tǒng)毫無疑問地會回應一個ACK報文給對方，此時則進入到CLOSE_WAIT狀態(tài)。接下來呢，實際上你真正需要考慮的事情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以 close這個SOCKET，發(fā)送FIN報文給對方，也即關閉連接。所以你在CLOSE_WAIT狀態(tài)下，需要完成的事情是等待你去關閉連接。（被動方）

LAST_ACK:?被動關閉一方在發(fā)送FIN報文后，最后等待對方的ACK報文。當收到ACK報文后，也即可以進入到CLOSED可用狀態(tài)了。（被動方）

TIME_WAIT:?表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后即可回到CLOSED可用狀態(tài)了。如果FIN WAIT1狀態(tài)下，收到了對方同時帶FIN標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過FIN_WAIT_2狀態(tài)。（主動方）

CLOSED:?表示連接中斷。

為什么要有TIME_WAIT這個狀態(tài)？

假設最終的ACK丟失，主機2將重發(fā)FIN，主機1必須維護TCP狀態(tài)信息以便可以重發(fā)最終的ACK，否則會發(fā)送RST，結果主機2認為發(fā)生錯誤。TCP實現(xiàn)必須可靠地終止連接的兩個方向(全雙工關閉)，主機1必須進入 TIME_WAIT 狀態(tài)，因為主機1可能面 臨重發(fā)最終ACK的情形。

出現(xiàn)太多TIME_WAIT可能導致的后果：

在高并發(fā)短連接的TCP服務器上，當服務器處理完請求后立刻按照主動正常關閉連接。這個場景下，會出現(xiàn)大量socket處于TIMEWAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時部分客戶端就會顯示連接不上。 我來解釋下這個場景。主動正常關閉TCP連接，都會出現(xiàn)TIMEWAIT。為什么我們要關注這個高并發(fā)短連接呢？有兩個方面需要注意：

① 高并發(fā)可以讓服務器在短時間范圍內同時占用大量端口，而端口有個0~65535的范圍，并不是很多，刨除系統(tǒng)和其他服務要用的，剩下的就更少了。

②在這個場景中，短連接表示“業(yè)務處理+傳輸數(shù)據(jù)的時間 遠遠小于 TIMEWAIT超時的時間”的連接。這里有個相對長短的概念，比如，取一個web頁面，1秒鐘的http短連接處理完業(yè)務，在關閉連接之后，這個業(yè)務用過的端口會停留在TIMEWAIT狀態(tài)幾分鐘，而這幾分鐘，其他HTTP請求來臨的時候是無法占用此端口的。單用這個業(yè)務計算服務器的利用率會發(fā)現(xiàn)，服務器干正經(jīng)事的時間和端口（資源）被掛著無法被使用的時間的比例是 1：幾百，服務器資源嚴重浪費。

說個題外話，從這個意義出發(fā)來考慮服務器性能調優(yōu)的話，長連接業(yè)務的服務就不需要考慮TIMEWAIT狀態(tài)。同時，假如你對服務器業(yè)務場景非常熟悉，你會發(fā)現(xiàn)，在實際業(yè)務場景中，一般長連接對應的業(yè)務的并發(fā)量并不會很高

綜合這兩個方面，持續(xù)的到達一定量的高并發(fā)短連接，會使服務器因端口資源不足而拒絕為一部分客戶服務。

time_wait狀態(tài)如何避免

首先服務器可以設置SO_REUSEADDR套接字選項來通知內核，如果端口忙，但TCP連接位于TIME_WAIT狀態(tài)時可以重用端口。在一個非常有用的場景就是，如果你的服務器程序停止后想立即重啟，而新的套接字依舊希望使用同一端口，此時SO_REUSEADDR選項就可以避免TIME_WAIT狀態(tài)。

2.3、網(wǎng)絡層

應用層將數(shù)據(jù)丟給傳輸層進行包裝，網(wǎng)絡層則是用來處理這些流動的數(shù)據(jù)包，也就是如果把相應的數(shù)據(jù)包路由到指定的地點，為通信時的網(wǎng)絡傳輸選擇傳輸路線。
就像送快遞一樣，需要選擇正確路線，才能送到你家。

2.4、數(shù)據(jù)鏈路層

數(shù)據(jù)鏈路層包含了軟件與硬件的接口部分，以及各種網(wǎng)絡設備的硬件，也就是整個網(wǎng)絡通信過程中最底層的基礎設施。

一個HTTP請求的響應過程：

簡單了解了每一層的作用之后，我們試著串起來，摸索一下一次整體的http請求到響應的過程。
拿訪問google做個例子：

0.訪問google.com，按下回車。

1.應用層準備好請求報文，通過DNS服務進行域名解析，得到google的ip地址，并將報文發(fā)到傳輸層。

2.傳輸層收到報文后，會將請求的數(shù)據(jù)包進行拆分，打包，并對每個包裹打上tag。在請求報文的基礎上，加上一層TCP的首部信息，然后發(fā)往網(wǎng)絡層。

3.到了網(wǎng)絡層以后，IP協(xié)議就發(fā)揮了巨大的作用，IP協(xié)議中需要兩個比較重要的信息，那就是ip地址和mac地址。ip已經(jīng)在應用層通過dns解析出來了，那mac怎么辦。。。真尷尬，然而這時ARP協(xié)議又冒了出來，它可以根據(jù)ip地址反向查詢到目標主機的mac地址。好了，現(xiàn)在啥都有了，打包帶走，把數(shù)據(jù)發(fā)到數(shù)據(jù)鏈路層。

4.終于走到基礎設施這里了，此時數(shù)據(jù)包就在一根根光纖中旋轉跳躍的奔向目的地，當然，整個過程不一定是直達的，可能需要經(jīng)過各種中轉站，就跟坐火車轉車一樣的。

5.請求到達服務器后，先從數(shù)據(jù)鏈路層往上走，并驗證消去以太網(wǎng)首部信息，在網(wǎng)絡層消去IP首部，在傳輸層消去TCP首部，就像剝洋蔥一樣一層一層去皮，最后剩下的就請求報文。在應用層對請求做出處理之后，需要對請求返回一個響應。而整個響應的傳輸過程就和請求一樣，一層一層的封裝，響應到達客戶端時再一層一層的消去首部，最后呈現(xiàn)響應的結果。

簡而言之，他們可以概括為一張這樣的圖：

二、HTTP/HTTPS協(xié)議

?在了解這兩個之前，我們先來看兩張圖：


從這兩張圖片來看，http協(xié)議和https協(xié)議有一個最顯而易見的區(qū)別：https比http要安全。

1、基本概念

1.1、http

HTTP：是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議，是一個客戶端和服務器端請求和應答的標準（基于TCP/IP協(xié)議），用于從WWW服務器傳輸超文本到本地瀏覽器的傳輸協(xié)議，它可以使瀏覽器更加高效，使網(wǎng)絡傳輸減少。

HTTP 是一個屬于應用層的面向對象的協(xié)議，HTTP 協(xié)議一共有五大特點：
1、支持客戶/服務器模式；
2、簡單快速；
3、靈活；
4、無連接；
5、無狀態(tài)。

其中我們主要了解一下無連接和無狀態(tài)這兩個特點：

1、無連接
無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。

早期這么做的原因是 HTTP 協(xié)議產生于互聯(lián)網(wǎng)，因此服務器需要處理同時面向全世界數(shù)十萬、上百萬客戶端的網(wǎng)頁訪問，但每個客戶端（即瀏覽器）與服務器之間交換數(shù)據(jù)的間歇性較大（即傳輸具有突發(fā)性、瞬時性），并且網(wǎng)頁瀏覽的聯(lián)想性、發(fā)散性導致兩次傳送的數(shù)據(jù)關聯(lián)性很低，大部分通道實際上會很空閑、無端占用資源。

因此 HTTP 的設計者有意利用這種特點將協(xié)議設計為請求時建連接、請求完釋放連接，以盡快將資源釋放出來服務其他客戶端。

但是，隨著時間的推移，網(wǎng)頁變得越來越復雜，里面可能嵌入了很多圖片，這時候每次訪問圖片都需要建立一次 TCP 連接就顯得很低效。后來，Keep-Alive 被提出用來解決這效率低的問題。

Keep-Alive 功能使客戶端到服務器端的連接持續(xù)有效，當出現(xiàn)對服務器的后繼請求時，Keep-Alive
功能避免了建立或者重新建立連接。市場上的大部分 Web 服務器，包括 iPlanet、IIS 和 Apache，都支持 HTTP
Keep-Alive。對于提供靜態(tài)內容的網(wǎng)站來說，這個功能通常很有用。但是，對于負擔較重的網(wǎng)站來說，這里存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一臺機器上運行時，Keep-Alive
功能對資源利用的影響尤其突出。

這樣一來，客戶端和服務器之間的 HTTP 連接就會被保持，不會斷開（超過 Keep-Alive
規(guī)定的時間，意外斷電等情況除外），當客戶端發(fā)送另外一個請求時，就使用這條已經(jīng)建立的連接。

2、無狀態(tài)
無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態(tài)。

即我們給服務器發(fā)送 HTTP 請求之后，服務器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不會記錄任何信息。

HTTP 是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨立的，Keep-Alive 沒能改變這個結果。

缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

HTTP 協(xié)議這種特性有優(yōu)點也有缺點：

1、優(yōu)點在于解放了服務器，每一次請求“點到為止”不會造成不必要連接占用
2、缺點在于每次請求會傳輸大量重復的內容信息。

客戶端與服務器進行動態(tài)交互的 Web 應用程序出現(xiàn)之后，HTTP 無狀態(tài)的特性嚴重阻礙了這些應用程序的實現(xiàn)，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在之前選擇了什么商品。

于是，兩種用于保持 HTTP 連接狀態(tài)的技術就應運而生了，一個是 Cookie，而另一個則是 Session。

3、Cookie和 Session：

1、Cookie：
Cookie可以保持登錄信息到用戶下次與服務器的會話，換句話說，下次訪問同一網(wǎng)站時，用戶會發(fā)現(xiàn)不必輸入用戶名和密碼就已經(jīng)登錄了（當然，不排除用戶手工刪除Cookie）。而還有一些Cookie在用戶退出會話的時候就被刪除了，這樣可以有效保護個人隱私。

Cookies 最典型的應用是判定注冊用戶是否已經(jīng)登錄網(wǎng)站，用戶可能會得到提示，是否在下一次進入此網(wǎng)站時保留用戶信息以便簡化登錄手續(xù)，這些都是 Cookies 的功用。
另一個重要應用場合是“購物車”之類處理。用戶可能會在一段時間內在同一家網(wǎng)站的不同頁面中選擇不同的商品，這些信息都會寫入 Cookies，以便在最后付款時提取信息。

2、 Session：

它是通過服務器來保持狀態(tài)的。

當客戶端訪問服務器時，服務器根據(jù)需求設置 Session，將會話信息保存在服務器上，同時將標示 Session 的 SessionId 傳遞給客戶端瀏覽器，瀏覽器將這個 SessionId 保存在內存中，我們稱之為無過期時間的 Cookie。瀏覽器關閉后，這個 Cookie 就會被清掉，它不會存在于用戶的 Cookie 臨時文件。

以后瀏覽器每次請求都會額外加上這個參數(shù)值，服務器會根據(jù)這個 SessionId，就能取得客戶端的數(shù)據(jù)信息。

如果客戶端瀏覽器意外關閉，服務器保存的 Session 數(shù)據(jù)不是立即釋放，此時數(shù)據(jù)還會存在，只要我們知道那個 SessionId，就可以繼續(xù)通過請求獲得此 Session 的信息，因為此時后臺的 Session 還存在，當然我們可以設置一個 Session 超時時間，一旦超過規(guī)定時間沒有客戶端請求時，服務器就會清除對應 SessionId 的 Session 信息。

1.2、https

HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

那么https協(xié)議是怎么用SSL加密的呢？
其實SSL也是一種協(xié)議，SSL/TLS 在 TCP 之上加了一層加密等處理，不影響原有的 TCP 和 HTTP，上下都是透明的，用來實現(xiàn)安全傳輸。
其過程如圖所示：

SSL/TLS 概述

1、主要功能：

• 防冒充(pretending): 驗證交互雙方（通常只是對服務端）身份的真實性； 防竊聽(eavesdropping):
• 對傳輸?shù)臄?shù)據(jù)進行加密，即使被截獲也無法被識別； 防篡改(tampering):
• 確保接收方收到的數(shù)據(jù)是原始未篡改過的，若被篡改能識別出來并丟棄；

2、SSL/TLS 交互過程（加密過程）：
這里有個重要依據(jù)是RSA公鑰加密算法：

• 對于數(shù)據(jù)交換雙方，都擁有自身的公鑰和私鑰，私鑰都為自己私藏，公鑰都向對方公開；
• 同樣一個數(shù)據(jù)，發(fā)送方使用自身的私鑰加密，接收方收到后可以用發(fā)送方的公鑰解密。

在連接的時候，會有以下操作：

1. 服務端：向客戶端發(fā)送服務端證書(證書中包含服務端公鑰)，并向客戶端索要客戶端證書；
2. 客戶端：收到服務端證書后，驗證其身份有效性(可信機構頒發(fā)、域名一致、未過期等)，如驗證失敗則握手失敗，如成功則從中取出服務端公鑰；
3. 客戶端：向服務端發(fā)送客戶端證書(證書中包含客戶端公鑰)；
4. 服務端：收到客戶端證書后，驗證其身份真實性，如驗證失敗則握手失敗。

2、http和https的區(qū)別

由上圖我們可以知道，http和https最顯而易見的區(qū)別，就是一個安全一個不安全。

那么為什么他們會有這樣的區(qū)別呢？
答：HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私
信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設計SSL（Secure 
Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密，從而就誕生了HTTPS。簡
單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)
議，要比http協(xié)議安全。

HTTPS和HTTP的區(qū)別主要如下：

1、https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。

2、http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。

3、http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

4、http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，比http協(xié)議安全。

3、https的優(yōu)缺點

3.1、https協(xié)議的優(yōu)點

其實，HTTPS也并非絕對安全。掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構下最安全的解決方案，主要有以下幾個好處：

（1）使用HTTPS協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；

（2）HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網(wǎng)絡協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。

（3）HTTPS是現(xiàn)行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

（4）谷歌曾在2014年8月份調整搜索引擎算法，并稱“比起同等HTTP網(wǎng)站，采用HTTPS加密的網(wǎng)站在搜索結果中的排名將會更高”。

3.2、https的缺點

雖然說HTTPS有很大的優(yōu)勢，但其相對來說，還是存在不足之處的：

（1）HTTPS協(xié)議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；

（2）HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；

（3）SSL證書需要錢，功能越強大的證書費用越高，個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

（4）SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。

（5）HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。最關鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。文章來源地址http://www.zghlxwxcb.cn/news/detail-777521.html

到了這里，關于計算機網(wǎng)絡-網(wǎng)絡協(xié)議的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！