socket/WebSocket/WebService/http/https概念
學習了這麼久的java技術, 可是這5個 socket/WebSocket/WebService/http/https 概念還不是很清楚, 老是很模糊,或者是弄混. 慚愧! !html
學習以前, 要對這個網絡七層協議有個瞭解java
網絡七層協議從低到高： 1、物理層（Physical Layer）、 2、數據鏈路層（Data Link Layer）、 3、網絡層（Network Layer）、 四、傳輸層（Transport Layer）、 ---------socket(發動機/提供了網絡通訊的能力。socket是一切經過端口通訊的基礎(包括http)) 5、會話層（Session Layer）、 6、表示層（Presentation Layer）、 七、應用層（Application Layer） ---------http(轎車/提供了封裝或者顯示數據的具體形式(超文本傳輸協議)) /webSocket(是HTML5規範提出的一種協議,基於也是應用層) /FTP協議（File Transfer Protocol，文件傳輸協議）
最通俗易懂的網絡應用層協議詳解 :http://www.javashuo.com/article/p-kawfvytb-bg.htmlweb
什麼是協議? : 協議是一種約定，咱們規定好一種信息的格式，若是發送方按照這種請求格式發送信息，那麼接收端就要按照這樣的格式解析數據。這就是協議。ajax
一.socket(傳輸控制層接口)apache
1.1 socket傳輸的定義編程
所謂socket一般也稱做"套接字",實現服務器和客戶端之間的物理鏈接，並進行數據傳輸，主要有udp和tcp兩個協議。socket處於網絡協議的傳輸層。Socket其實並非一個協議，而是爲了方便使用TCP或UDP而抽象出來的一層，是位於應用層和傳輸控制層之間的一組接口。
udp協議：廣播式數據傳輸，不進行數據驗證
tcp協議：傳輸控制協議，一種面向鏈接的協議，給用戶進程提供可靠的全雙工的字節流。設計模式
補充:瀏覽器
「Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口，提供一套調用TCP/IP協議的API。
在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。」
當兩臺主機通訊時，必須經過Socket鏈接，Socket則利用TCP/IP協議創建TCP鏈接。TCP鏈接則更依靠於底層的IP協議，IP協議的鏈接則依賴於鏈路層等更低層次.
1.2 socket傳輸的特色：
優勢
1) 傳輸數據爲字節級，傳輸數據可自定義，數據量小（對於手機應用講：費用低）
2) 傳輸數據時間短，性能高
3) 適合於客戶端和服務器端之間信息實時交互
4) 能夠加密,數據安全性強
缺點：
1) 需對傳輸的數據進行解析，轉化成應用級的數據
2) 對開發人員的開發水平要求高
3) 相對於http協議傳輸，增長了開發量安全
1.3 socket傳輸適用範圍服務器
基於socket傳輸的特色 : socket 傳輸方式適合於對傳輸速度，安全性，實時交互，費用等要求高的應用中，如網絡遊戲，手機應用，銀行內部交互等
二. WebSocket(應用層協議)
1.1 WebSocket協議是什麼?
WebSocket是HTML5規範提出的一種協議；目前除了IE瀏覽器，其餘瀏覽器都基本支持。和HTTP協議是並存的兩種協議(Websocket和HTTP有關係，可是關係不大, websocket在首次創建鏈接時要使用下http協議（服務器返回101，則表示c/s由http協議升級websocket協議成功）。可是值得注意的是，這只是他們之間惟一的僅有的相同點。除此以外，他們徹底不一樣。,如圖:
)。
WebSocket是HTML5中的協議。HTML5 Web Sockets規範定義了Web Sockets API，支持頁面使用Web Socket協議與遠程主機進行全雙工的通訊。它引入了WebSocket接口而且定義了一個全雙工的通訊通道，經過一個單一的套接字在Web上進行操做。HTML5 Web Sockets以最小的開銷高效地提供了Web鏈接。相較於常常須要使用推送實時數據到客戶端甚至經過維護兩個HTTP鏈接來模擬全雙工鏈接的舊的輪詢或長輪詢（Comet）來講，這就極大的減小了沒必要要的網絡流量與延遲。
1.2 WebSocket協議有什麼特色?
♥ Websocket是基於HTTP協議的.可是和http最大的不一樣是:
a. WebSocket是一種雙向通訊協議。在創建鏈接後，WebSocket服務器端和客戶端都能主動向對方發送或接收數據，就像Socket同樣；(而http服務端不能主動聯繫客戶端，只能有客戶端發起,太被動啦)
b. WebSocket須要像TCP同樣，先創建鏈接，鏈接成功後才能相互通訊
補充: 傳統http是 一發一收關閉,每次請求-應答都須要客戶端與服務端創建鏈接的模式(每次都要從新發起鏈接請求).
而一旦WebSocket鏈接創建後,在客戶端斷開WebSocket鏈接或Server端中斷鏈接前，不須要客戶端和服務端從新發起鏈接請求。
♥ Websocket是一個持久化的協議.
(只要創建一次HTTP請求，就能夠接二連三的獲得服務器推送的消息，節省帶寬和服務器端的壓力,也能夠用 和 來 模擬出相似的效果)
eg: 客戶端：我要創建websocket鏈接
服務器端：好的，已經切換到websocket協議，websocket鏈接已經創建
客戶端： 有什麼消息要及時告訴（推送）我
服務器端：好的
服務器端：xxxxxx
服務器端：yyyyyyy
。。。。。long pollajax 輪詢
1.3 WebSocket 協議案例
首先咱們來看個典型的 Websocket 握手
GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com
熟悉HTTP的同窗可能發現了，這段相似HTTP協議的握手請求中，多了幾個東西。我會順便講解下做用。
Upgrade: websocket Connection: Upgrade
這個就是Websocket的核心了，告訴 Apache 、 Nginx 等服務器：注意啦，我發起的是Websocket協議，快點幫我找到對應的助理處理~不是那個老土的HTTP。
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13
首先， Sec-WebSocket-Key 是一個 Base64 encode 的值，這個是瀏覽器隨機生成的，告訴服務器：不要忽悠窩，我要驗證你是否是真的是Websocket助理。
而後， Sec_WebSocket-Protocol 是一個用戶定義的字符串，用來區分同URL下，不一樣的服務所須要的協議。簡單理解：今天我要服務A，別搞錯啦~
最後， Sec-WebSocket-Version 是告訴服務器所使用的 Websocket Draft（協議版本）.
而後服務器會返回下列東西，表示已經接受到請求， 成功創建Websocket啦！
HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat
這裏開始就是HTTP最後負責的區域了，告訴客戶，我已經成功切換協議啦~
Upgrade: websocket Connection: Upgrade
摘抄於: https://blog.csdn.net/frank_good/article/details/50856585 和 https://www.zhihu.com/question/20215561
1.4 Websocket應用場景
能夠實現客戶端與服務器端的通訊，實現服務器的推送功能.
補充:（在程序設計中，這種設計叫作回調，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你 ）
三. WebService(服務)
1.1 什麼是WebService?(建議看百度百科,有更詳細的介紹)
WebService是一種跨編程語言和跨操做系統平臺的遠程調用技術。
所謂跨編程語言和跨操做平臺，就是說服務端程序採用java編寫，客戶端程序則能夠採用其餘編程語言編寫，反之亦然！跨操做系統平臺則是指服務端程序和客戶端程序能夠在不一樣的操做系統上運行。
所謂遠程調用，就是一臺計算機a上 的一個程序能夠調用到另一臺計算機b上的一個對象的方法。
1.2 WebService平臺技術
XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。
• XML+XSD
WebService採用HTTP協議傳輸數據，採用XML格式封裝數據（即XML中說明調用遠程服務對象的哪一個方法，傳遞的參數是什麼，以及服務對象的 返回結果是什麼）。XML是WebService平臺中表示數據的格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關 的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。
XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底表明什麼？16位，32位，64位？這 些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。WebService平臺就 是用XSD來做爲其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，爲了符合WebService標準，所 有你使用的數據類型都必須被轉換爲XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你極可能會根據你的須要修改一下轉換過程。
• SOAP
WebService經過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都採用XML格式封裝，並增長了一些特定的HTTP消息頭，以說明 HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標準的RPC方法來調用Web Service
SOAP協議 = HTTP協議 + XML數據格式
SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。打個比 喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防禦欄，SOAP就是普通公路通過加隔離帶和防禦欄改造過的高速公路。
• WSDL
比如咱們去商店買東西，首先要知道商店裏有什麼東西可買，而後再來購買，商家的作法就是張貼廣告海報。 WebService也同樣，WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務裏有什麼方 法能夠調用，因此，WebService務器端首先要經過一個WSDL文件來講明本身家裏有啥服務能夠對外調用，服務是什麼（服務中有哪些方法，方法接受 的參數是什麼，返回值是什麼），服務的網絡地址用哪一個url地址表示，服務經過什麼方式來調用。
WSDL(Web Services Description Language)就是這樣一個基於XML的語言，用於描述Web Service及其函數、參數和返回值。它是WebService客戶端和服務器端都 能理解的標準格式。由於是基於XML的，因此WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的 Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應WebService的代理類代碼。
WSDL 文件保存在Web服務器上，經過一個url地址就能夠訪問到它。客戶端要調用一個WebService服務以前，要知道該服務的WSDL文件的地址。 WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址：1.註冊到UDDI服務器，以便被人查找；2.直接告訴給客戶端調用者。
1.3 WebService 開發
WebService開發能夠分爲服務器端開發和客戶端開發兩個方面
• 服務端開發：把公司內部系統的業務方法發佈成WebService服務，供遠程合做單位和我的調用。
• 客戶端開發：調用別人發佈的WebService服務。
1.4 WebService 的工做調用原理
對客戶端而言，咱們給這各種WebService客戶端API傳遞wsdl文件的url地址，這些API就會建立出底層的代理類，我調用 這些代理，就能夠訪問到webservice服務。代理類把客戶端的方法調用變成soap格式的請求數據再經過HTTP協議發出去，並把接收到的soap 數據變成返回值返回。對服務端而言，各種WebService框架的本質就是一個大大的Servlet，當遠程調用客戶端給它經過http協議發送過來 soap格式的請求數據時，它分析這個數據，就知道要調用哪一個java類的哪一個方法，因而去查找或建立這個對象，並調用其方法，再把方法返回的結果包裝成 soap格式的數據，經過http響應消息回給客戶端。
1.5 WebService與Socket的區別
本身去網上找一下.理解一下.
1.6 WebService的優勢 / 缺點:
Webservcie因爲是遵循標準的soap協議，soap 協議的內容格式固定，soap協議傳遞的內容是xml數據，因爲webservice是基於http的，因此簡單理解爲soap=http+xml，適用於沒有性能要求狀況下且數據傳輸量小，推薦在公開接口上使用webservice，由於soap協議的標準的。
優勢以下:
• 可操做的的分佈式應用程序
能夠實現不一樣應用程序和在不一樣系統平臺上開發出來的應用程序之間通訊。與RMI、DOCM、CORBA最大的不一樣就是：Web Service 以 SOAP 做爲基本通訊協議從而避免了複雜的協議轉換.
• Web Service 甚至能夠穿越防火牆，真正的自由通訊
通常要訪問的Web服務器以及要訪問的Web Service的客戶端極可能位於防火牆後面，都默認關閉其它端口而開放HTTP端口，而Web service 正是基於HTTP的，因此它能夠穿越防火牆.
• 廣泛性、使用HTTP和XML進行通訊
任何支持HTTP和XML 技術的設備均可以擁有和訪問Web Service，不一樣平臺不一樣開發語言照樣能夠調用咱們發佈的Web Service.
• 應用程序集成
企業級的應用程序開發者都知道，企業裏常常都要把用不一樣語言寫成的、在不一樣平臺上運行的各類程序集成起來，而這種集成將花費很大的開發力量。應用程序常常須要從運行在IBM 主機上的程序中獲取數據；或者把數據發送到主機或UNIX 應用程序中去。即便在同一個平臺上，不一樣軟件廠商生產的各類軟件也經常須要集成起來。經過WebService ，應用程序能夠用標準的方法把功能和數據「 暴露」 出來，供其它應用程序使用。
• B2B 的集成
用WebService 集成應用程序，可使公司內部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界限時會怎麼樣呢？跨公司的商務交易集成一般叫作B2B 集成。WebService 是B2B 集成成功的關鍵。經過WebService ，公司能夠把關鍵的商務應用「 暴露」 給指定的供應商和客戶。
缺點以下:
缺點一：單機應用程序
目前，企業和我的還使用着不少桌面應用程序。其中一些只須要與本機上的其它程序通訊。在這種狀況下，最好就不要用WebService ，只要用本地的 API 就能夠了。COM 很是適合於在這種狀況下工做，由於它既小又快。運行在同一臺服務器上的服務器軟件也是這樣。最好直接用COM 或其它本地的API 來 進行應用程序間的調用。固然WebService 也能用在這些場合，但那樣不只消耗太大，並且不會帶來任何好處。
缺點二：局域網的同構應用程序
在許多應用中，全部的程序都是用VB 或VC 開發的，都在Windows 平臺下使用COM ，都運行在同一個局域網上。例如，有兩個服務器應用程序須要相互通訊，或者有一個Win32 或WinForm 的客戶程序要鏈接局域網上另外一個服務器的程序。在這些程序裏，使用DCOM(docm: 分佈式組件對象模型,分佈式組件對象模式) 會比SOAP/HTTP 有效得多。 與此相相似，若是一個.NET 程序要鏈接到局域網上的另外一個.NET 程序，應該使用.NETremoting 。有趣的是，在.NETremoting 中， 也能夠指定使用SOAP/HTTP 來進行WebService 調用。不過最好仍是直接經過TCP 進行RPC(rpc: 遠程過程調用) 調用，那樣會有效得多。
對WebService做補充:
1、WebService是什麼？
1. 基於Web的服務：服務器端整出一些資源讓客戶端應用訪問（獲取數據） 2. 一個跨語言、跨平臺的規範（抽象） 3. 多個跨平臺、跨語言的應用間通訊整合的方案（實際） 2、爲何要用Web service？ web service能解決： 跨平臺調用 跨語言調用 遠程調用 3、何時使用web Service? 1. 同一家公司的新舊應用之間 2. 不一樣公司的應用之間 3. 一些提供數據的內容聚合應用：天氣預報、股票行情
4、WebService中的幾個重要術語 4.1、WSDL(web service definition language) WSDL是webservice定義語言, 對應.wsdl文檔, 一個webservice會對應一個惟一的wsdl文檔, 定義了客戶端與服務端發送請求和響應的數據格式和過程 4.2、SOAP(simple object access protocal) SOAP是"簡單對象訪問協議" 1.是一種簡單的、基於HTTP和XML的協議, 用於在WEB上交換結構化的數據 2.soap消息：請求消息和響應消息
4.3、SEI(WebService EndPoint Interface) SEI是web service的終端接口，就是WebService服務器端用來處理請求的接口 4.四、CXF(Celtix + XFire) 一個apache的用於開發webservice服務器端和客戶端的框架。
五.總結
Web service是建立可互操做的分佈式應用程序的新平臺。Web service 的主要目標是跨平臺的可互操做性。爲了達到這一目標，Web service 是徹底基於XML、XSD等獨立於平臺、獨立於軟件供應商的標準的。
Web service在應用程序跨平臺和跨網絡進行通訊的時候是很是有用的。Web service適用於應用程序集成、B2B集成、代碼和數據重用，以及經過Web進行客戶端和服務器的通訊的場合。
固然，Web service也不是萬能的，你不能處處濫用Web service.在有些狀況下，Web service 會下降應用程序的性能，而不會帶來任何好處。
例如，一臺機器或一個局域網裏面運行的同構應用程序就不該該用Web service 進行通訊
優秀博文(建議關注這個大佬博客獲取跟多Webservice好文):
http://www.javashuo.com/article/p-yrpzuzqc-bv.html
http://www.javashuo.com/article/p-fwrdrtrc-bm.html
四. http(應用層協議)
1.http 是什麼?
http :超文本傳輸協議（HTTP，HyperText Transfer Protocol) ,是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。
是一種創建在TCP上的無狀態鏈接，整個基本的工做流程是客戶端發送一個HTTP請求，說明客戶端想要訪問的資源和請求的動做，服務端收到請求以後，服務端開始處理請求，並根據請求作出相應的動做訪問服務器資源，最後經過發送HTTP響應把結果返回給客戶端。
補充: HTTP中永遠是這樣，也就是說一個request只能有一個response。並且這個response也是被動的，不能主動發起。(且每次都要從新創建鏈接,這點不及WebSocket協議優秀)
2.http請求 和 響應
• 請求:
HTTP請求是客戶端往服務端發送請求動做，告知服務器本身的要求。
HTTP請求由狀態行、請求頭、請求正文三部分組成：
狀態行：包括請求方式Method(GET、POST、PUT上傳、DELETE刪除)、資源路徑URL、協議版本Version；
請求頭：包括一些訪問的域名、用戶代理、Cookie等信息；
請求正文：就是HTTP請求的數據。
• 響應:
服務器收到了客戶端發來的HTTP請求後，根據HTTP請求中的動做要求，服務端作出具體的動做，將結果迴應給客戶端，稱爲HTTP響應.
HTTP響應由三部分組成：狀態行、響應頭、響應正文.
狀態行：包括協議版本Version、狀態碼Status Code、迴應短語；
響應頭：包括搭建服務器的軟件，發送響應的時間，迴應數據的格式等信息；
響應正文：就是響應的具體數據。
補充:HTTP響應的狀態碼 : http://www.javashuo.com/article/p-erawawdi-hy.html
3.http的優缺點
優勢: 1.支持客戶/服務器模式。 2.簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。 3.靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type（Content-Type是HTTP包中用來表示內容類型的標識）加以標記。 4.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。 5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。 缺點: 1.通訊使用明文(不加密),內容可能會被竊聽 • HTTP 報文使用明文（指未通過加密的報文）方式發送. eg:被人抓包 2.不驗證通訊方的身份, 所以可能遭遇假裝 • 沒法斷定請求是來自何方、出自誰手 • 無心義的請求也會照單全收 HTTP 協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中 URI 真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題(解決這個問題,要用ssl:https://baike.baidu.com/item/ssl/320778?fr=aladdin)。 在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求! 另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒有被 Web 服務器設定限制訪問的前提下,相似於白名單）. 3.沒法證實報文的完整性, 因此有可能已遭篡改 所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。 因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。換句話說，沒有任何辦法確認，發出的請求 / 響應和接收到的請求 / 響應是先後相同的。 4. 缺點補充 1) 傳輸速度慢，數據包大（http協議中包含輔助應用信息,eg:header頭中帶着大量信息） 2) 如實時交互，服務器性能壓力大。 3) 數據傳輸安全性差
4.http1.0 和1.1版本的區別
發展到現在有2個版本: HTTP 1.0版本 / HTTP 1.1版本(廣泛使用) / HTTP 2.0. http幾個版本重點區別以下:
1.HTTP 1.0須要使用keep-alive參數來告知服務器端要創建一個長鏈接，而HTTP1.1默認支持長鏈接。
補充長鏈接和短鏈接的區別: https://blog.csdn.net/q547550831/article/details/50445385
HTTP1.1默認支持長鏈接的優勢: HTTP是基於TCP/IP協議的，建立一個TCP鏈接是須要通過三次握手的,有必定的開銷，若是每次通信都要從新創建鏈接的話，對性能有影響。所以最好能維持一個長鏈接，能夠用個長鏈接來發多個請求。節省帶寬但安全性較差.
2. .............
5. http優秀的資料必看
百度百科 :https://baike.baidu.com/item/http/243074?fr=aladdin
http總結 :http://www.cnblogs.com/ranyonsue/p/5984001.html
五. https(應用層協議)
1.1 https是什麼?
https 是超文本傳輸安全協議,是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。
即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用於安全的HTTP數據傳輸。https:URL代表它使用了HTTP，但HTTPS存在不一樣於HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統的最初研發由網景公司(Netscape)進行，並內置於其瀏覽器Netscape Navigator中，提供了身份驗證與加密通信方法。如今它被普遍用於萬維網上安全敏感的通信，例如交易支付方面.
補充:已經有了http , 爲何還要用https?
1.2 https 和 http 的區別?
•http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
•https協議須要到ca申請證書，通常免費證書不多，須要交費。
•http是超文本傳輸協議，信息是明文傳輸，https 則是具備安全性的ssl加密傳輸協議。
•http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全
1.3 https參考資料
百度百科: https://baike.baidu.com/item/https/285356?fr=aladdin
這幾天作了一個搬運工, 同時也對 socket/WebSocket/WebService/http/https (或許不應放一塊兒比較,原諒我,由於我是發現這5個惟一的共同點 :就是能讓客戶端和服務器進行通訊)有了一個更加全面的分析和認識度, 這5個 哈哈哈, 根本不是同一個東西, 之前不明確,老是覺得都差很少, 細細認知下來, 天大的差異. 感謝大v們在網上的分享.謝謝您們!
溫故而知新, 加油!
- 1. 概念
- 2. web概念概述
- 3. AngularJS_03_概念概述
- 4. JavaWeb概念概述
- 5. 【kubernetes/k8s概念】 nfs 概念與原理
- 6. Python基礎概念_2_基礎概念
- 7. K8S基礎概念 K8S基礎概念
- 8. 模塊的概念，組建地概念？
- 9. 基本概念
- 10. 概念釐清
- 更多相關文章...
- • 數據庫是什麼？數據庫的概念 - MySQL教程
- • Rust 基礎語法 - RUST 教程
- • Java Agent入門實戰（二）-Instrumentation源碼概述
- • 適用於PHP初學者的學習線路和建議
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 概念
- 2. web概念概述
- 3. AngularJS_03_概念概述
- 4. JavaWeb概念概述
- 5. 【kubernetes/k8s概念】 nfs 概念與原理
- 6. Python基礎概念_2_基礎概念
- 7. K8S基礎概念 K8S基礎概念
- 8. 模塊的概念，組建地概念？
- 9. 基本概念
- 10. 概念釐清