?

學(xué)習(xí)了這么久的java技術(shù), 但是這5個 socket/WebSocket/WebService/http/https? 概念還不是很清楚, 總是很模糊,或者是弄混. 慚愧! !

?

學(xué)習(xí)之前, 要對這個網(wǎng)絡(luò)七層協(xié)議有個了解

網(wǎng)絡(luò)七層協(xié)議從低到高：1、物理層（Physical Layer）、2、數(shù)據(jù)鏈路層（Data Link Layer）、3、網(wǎng)絡(luò)層（Network Layer）、4、傳輸層（Transport Layer）、 ---------socket(發(fā)動機/提供了網(wǎng)絡(luò)通信的能力。socket是一切通過端口通信的基礎(chǔ)(包括http))5、會話層（Session Layer）、6、表示層（Presentation Layer）、7、應(yīng)用層（Application Layer） ---------http(轎車/提供了封裝或者顯示數(shù)據(jù)的具體形式(超文本傳輸協(xié)議)) /webSocket(是HTML5規(guī)范提出的一種協(xié)議,基于也是應(yīng)用層) /FTP協(xié)議（File Transfer Protocol，文件傳輸協(xié)議）

?最通俗易懂的網(wǎng)絡(luò)應(yīng)用層協(xié)議詳解 :https://blog.csdn.net/qq992817263/article/details/56669228

?

什么是協(xié)議? : 協(xié)議是一種約定，我們規(guī)定好一種信息的格式，如果發(fā)送方按照這種請求格式發(fā)送信息，那么接收端就要按照這樣的格式解析數(shù)據(jù)。這就是協(xié)議。

?

?

一.socket(傳輸控制層接口)

1.1 socket傳輸?shù)亩x

?所謂socket通常也稱作"套接字",實現(xiàn)服務(wù)器和客戶端之間的物理連接，并進行數(shù)據(jù)傳輸，主要有udp和tcp兩個協(xié)議。socket處于網(wǎng)絡(luò)協(xié)議的傳輸層。Socket其實并不是一個協(xié)議，而是為了方便使用TCP或UDP而抽象出來的一層，是位于應(yīng)用層和傳輸控制層之間的一組接口。
??? udp協(xié)議：廣播式數(shù)據(jù)傳輸，不進行數(shù)據(jù)驗證
??? tcp協(xié)議：傳輸控制協(xié)議，一種面向連接的協(xié)議，給用戶進程提供可靠的全雙工的字節(jié)流。

補充:

“Socket是應(yīng)用層與TCP/IP協(xié)議族通信的中間軟件抽象層，它是一組接口，提供一套調(diào)用TCP/IP協(xié)議的API。
在設(shè)計模式中，Socket其實就是一個門面模式，它把復(fù)雜的TCP/IP協(xié)議族隱藏在Socket接口后面，對用戶來說，一組簡單的接口就是全部，讓Socket去組織數(shù)據(jù)，以符合指定的協(xié)議。”

當兩臺主機通信時，必須通過Socket連接，Socket則利用TCP/IP協(xié)議建立TCP連接。TCP連接則更依靠于底層的IP協(xié)議，IP協(xié)議的連接則依賴于鏈路層等更低層次.

?

?1.2 socket傳輸?shù)奶攸c：
?? 優(yōu)點
?? 1) 傳輸數(shù)據(jù)為字節(jié)級，傳輸數(shù)據(jù)可自定義，數(shù)據(jù)量小（對于手機應(yīng)用講：費用低）
?? 2) 傳輸數(shù)據(jù)時間短，性能高
?? 3) 適合于客戶端和服務(wù)器端之間信息實時交互
?? 4) 可以加密,數(shù)據(jù)安全性強
?? 缺點：
?? 1) 需對傳輸?shù)臄?shù)據(jù)進行解析，轉(zhuǎn)化成應(yīng)用級的數(shù)據(jù)
?? 2) 對開發(fā)人員的開發(fā)水平要求高
?? 3) 相對于http協(xié)議傳輸，增加了開發(fā)量

1.3 ?socket傳輸適用范圍

? 基于socket傳輸?shù)奶攸c : socket 傳輸方式適合于對傳輸速度，安全性，實時交互，費用等要求高的應(yīng)用中，如網(wǎng)絡(luò)游戲，手機應(yīng)用，銀行內(nèi)部交互等

?

二. WebSocket(應(yīng)用層協(xié)議)

1.1 WebSocket協(xié)議是什么?

WebSocket是HTML5規(guī)范提出的一種協(xié)議；目前除了IE瀏覽器，其他瀏覽器都基本支持。和HTTP協(xié)議是并存的兩種協(xié)議(Websocket和HTTP有關(guān)系，但是關(guān)系不大, websocket在首次建立連接時要使用下http協(xié)議（服務(wù)器返回101，則表示c/s由http協(xié)議升級websocket協(xié)議成功）。但是值得注意的是，這只是他們之間唯一的僅有的相同點。除此之外，他們完全不同。,如圖:

)。

?

WebSocket是HTML5中的協(xié)議。HTML5 Web Sockets規(guī)范定義了Web Sockets API，支持頁面使用Web Socket協(xié)議與遠程主機進行全雙工的通信。它引入了WebSocket接口并且定義了一個全雙工的通信通道，通過一個單一的套接字在Web上進行操作。HTML5 Web Sockets以最小的開銷高效地提供了Web連接。相較于經(jīng)常需要使用推送實時數(shù)據(jù)到客戶端甚至通過維護兩個HTTP連接來模擬全雙工連接的舊的輪詢或長輪詢（Comet）來說，這就極大的減少了不必要的網(wǎng)絡(luò)流量與延遲。

?

1.2 WebSocket協(xié)議有什么特點?

? Websocket是基于HTTP協(xié)議的.但是和http最大的不同是:
　　a. WebSocket是一種雙向通信協(xié)議。在建立連接后，WebSocket服務(wù)器端和客戶端都能主動向?qū)Ψ桨l(fā)送或接收數(shù)據(jù)，就像Socket一樣；(而http服務(wù)端不能主動聯(lián)系客戶端，只能有客戶端發(fā)起,太被動啦)
　　b. WebSocket需要像TCP一樣，先建立連接，連接成功后才能相互通信

補充: 傳統(tǒng)http是 一發(fā)一收關(guān)閉,每次請求-應(yīng)答都需要客戶端與服務(wù)端建立連接的模式(每次都要重新發(fā)起連接請求).
而一旦WebSocket連接建立后,在客戶端斷開WebSocket連接或Server端中斷連接前，不需要客戶端和服務(wù)端重新發(fā)起連接請求。

? Websocket是一個持久化的協(xié)議.
(只要建立一次HTTP請求，就可以連續(xù)不斷的得到服務(wù)器推送的消息，節(jié)省帶寬和服務(wù)器端的壓力,也可以用long poll?和?ajax 輪詢?來 模擬出類似的效果)
eg: 客戶端：我要建立websocket連接　
服務(wù)器端：好的，已經(jīng)切換到websocket協(xié)議，websocket連接已經(jīng)建立
　　　　 客戶端： 有什么消息要及時告訴（推送）我
　　　　 服務(wù)器端：好的
　　　　 服務(wù)器端：xxxxxx
服務(wù)器端：yyyyyyy
。。。。。

?

1.3 WebSocket 協(xié)議案例

首先我們來看個典型的?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的同學(xué)可能發(fā)現(xiàn)了，這段類似HTTP協(xié)議的握手請求中，多了幾個東西。我會順便講解下作用。

Upgrade: websocket Connection: Upgrade

?這個就是Websocket的核心了，告訴?Apache?、?Nginx?等服務(wù)器：注意啦，我發(fā)起的是Websocket協(xié)議，快點幫我找到對應(yīng)的助理處理~不是那個老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

?首先，?Sec-WebSocket-Key?是一個?Base64 encode?的值，這個是瀏覽器隨機生成的，告訴服務(wù)器：不要忽悠窩，我要驗證你是不是真的是Websocket助理。

然后，?Sec_WebSocket-Protocol?是一個用戶定義的字符串，用來區(qū)分同URL下，不同的服務(wù)所需要的協(xié)議。簡單理解：今天我要服務(wù)A，別搞錯啦~

最后，?Sec-WebSocket-Version?是告訴服務(wù)器所使用的?Websocket Draft（協(xié)議版本）.

然后服務(wù)器會返回下列東西，表示已經(jīng)接受到請求， 成功建立Websocket啦！

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat

?

這里開始就是HTTP最后負責(zé)的區(qū)域了，告訴客戶，我已經(jīng)成功切換協(xié)議啦~

Upgrade: websocket Connection: Upgrade

摘抄于: https://blog.csdn.net/frank_good/article/details/50856585 和 ?? https://www.zhihu.com/question/20215561

?

1.4 Websocket應(yīng)用場景

可以實現(xiàn)客戶端與服務(wù)器端的通信，實現(xiàn)服務(wù)器的推送功能.

補充:（在程序設(shè)計中，這種設(shè)計叫做回調(diào)，即：你有信息了再來通知我，而不是我傻乎乎的每次跑來問你?）

?

?

三. WebService(服務(wù))

1.1 什么是WebService?(建議看百度百科,有更詳細的介紹)

WebService是一種跨編程語言和跨操作系統(tǒng)平臺的遠程調(diào)用技術(shù)。
所謂跨編程語言和跨操作平臺，就是說服務(wù)端程序采用java編寫，客戶端程序則可以采用其他編程語言編寫，反之亦然！跨操作系統(tǒng)平臺則是指服務(wù)端程序和客戶端程序可以在不同的操作系統(tǒng)上運行。

所謂遠程調(diào)用，就是一臺計算機a上 的一個程序可以調(diào)用到另外一臺計算機b上的一個對象的方法。

?

1.2 WebService平臺技術(shù)

XML+XSD,SOAP和WSDL就是構(gòu)成WebService平臺的三大技術(shù)。

??XML+XSD

WebService采用HTTP協(xié)議傳輸數(shù)據(jù)，采用XML格式封裝數(shù)據(jù)（即XML中說明調(diào)用遠程服務(wù)對象的哪個方法，傳遞的參數(shù)是什么，以及服務(wù)對象的 返回結(jié)果是什么）。XML是WebService平臺中表示數(shù)據(jù)的格式。除了易于建立和易于分析外，XML主要的優(yōu)點在于它既是平臺無關(guān)的，又是廠商無關(guān) 的。無關(guān)性是比技術(shù)優(yōu)越性更重要的：軟件廠商是不會選擇一個由競爭對手所發(fā)明的技術(shù)的。

XML解決了數(shù)據(jù)表示的問題，但它沒有定義一套標準的數(shù)據(jù)類型，更沒有說怎么去擴展這套數(shù)據(jù)類型。例如，整形數(shù)到底代表什么？16位，32位，64位？這 些細節(jié)對實現(xiàn)互操作性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數(shù)據(jù)類型，并給出了一種語言來擴展這套數(shù)據(jù)類型。WebService平臺就 是用XSD來作為其數(shù)據(jù)類型系統(tǒng)的。當你用某種語言(如VB.NET或C#)來構(gòu)造一個Web?service時，為了符合WebService標準，所 有你使用的數(shù)據(jù)類型都必須被轉(zhuǎn)換為XSD類型。你用的工具可能已經(jīng)自動幫你完成了這個轉(zhuǎn)換，但你很可能會根據(jù)你的需要修改一下轉(zhuǎn)換過程。

? SOAP

WebService通過HTTP協(xié)議發(fā)送請求和接收結(jié)果時，發(fā)送的請求內(nèi)容和結(jié)果內(nèi)容都采用XML格式封裝，并增加了一些特定的HTTP消息頭，以說明 HTTP消息的內(nèi)容格式，這些特定的HTTP消息頭和XML內(nèi)容格式就是SOAP協(xié)議。SOAP提供了標準的RPC方法來調(diào)用Web Service

?SOAP協(xié)議 = HTTP協(xié)議 + XML數(shù)據(jù)格式

SOAP協(xié)議定義了SOAP消息的格式，SOAP協(xié)議是基于HTTP協(xié)議的，SOAP也是基于XML和XSD的，XML是SOAP的數(shù)據(jù)編碼方式。打個比 喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防護欄，SOAP就是普通公路經(jīng)過加隔離帶和防護欄改造過的高速公路。

? WSDL

好比我們?nèi)ド痰曩I東西，首先要知道商店里有什么東西可買，然后再來購買，商家的做法就是張貼廣告海報。 WebService也一樣，WebService客戶端要調(diào)用一個WebService服務(wù)，首先要有知道這個服務(wù)的地址在哪，以及這個服務(wù)里有什么方 法可以調(diào)用，所以，WebService務(wù)器端首先要通過一個WSDL文件來說明自己家里有啥服務(wù)可以對外調(diào)用，服務(wù)是什么（服務(wù)中有哪些方法，方法接受 的參數(shù)是什么，返回值是什么），服務(wù)的網(wǎng)絡(luò)地址用哪個url地址表示，服務(wù)通過什么方式來調(diào)用。

　WSDL(Web Services Description Language)就是這樣一個基于XML的語言，用于描述Web?Service及其函數(shù)、參數(shù)和返回值。它是WebService客戶端和服務(wù)器端都 能理解的標準格式。因為是基于XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發(fā)工具既能根據(jù)你的 Web?service生成WSDL文檔，又能導(dǎo)入WSDL文檔，生成調(diào)用相應(yīng)WebService的代理類代碼。

　　WSDL 文件保存在Web服務(wù)器上，通過一個url地址就可以訪問到它。客戶端要調(diào)用一個WebService服務(wù)之前，要知道該服務(wù)的WSDL文件的地址。 WebService服務(wù)提供商可以通過兩種方式來暴露它的WSDL文件地址：1.注冊到UDDI服務(wù)器，以便被人查找；2.直接告訴給客戶端調(diào)用者。

?

1.3 WebService 開發(fā)

WebService開發(fā)可以分為服務(wù)器端開發(fā)和客戶端開發(fā)兩個方面

? 服務(wù)端開發(fā)：把公司內(nèi)部系統(tǒng)的業(yè)務(wù)方法發(fā)布成WebService服務(wù)，供遠程合作單位和個人調(diào)用。

? 客戶端開發(fā)：調(diào)用別人發(fā)布的WebService服務(wù)。

?

1.4 WebService 的工作調(diào)用原理

對客戶端而言，我們給這各類WebService客戶端API傳遞wsdl文件的url地址，這些API就會創(chuàng)建出底層的代理類，我調(diào)用 這些代理，就可以訪問到webservice服務(wù)。代理類把客戶端的方法調(diào)用變成soap格式的請求數(shù)據(jù)再通過HTTP協(xié)議發(fā)出去，并把接收到的soap 數(shù)據(jù)變成返回值返回。對服務(wù)端而言，各類WebService框架的本質(zhì)就是一個大大的Servlet，當遠程調(diào)用客戶端給它通過http協(xié)議發(fā)送過來 soap格式的請求數(shù)據(jù)時，它分析這個數(shù)據(jù)，就知道要調(diào)用哪個java類的哪個方法，于是去查找或創(chuàng)建這個對象，并調(diào)用其方法，再把方法返回的結(jié)果包裝成 soap格式的數(shù)據(jù)，通過http響應(yīng)消息回給客戶端。

1.5 WebService與Socket的區(qū)別

?自己去網(wǎng)上找一下.理解一下.

1.6 WebService的優(yōu)點 / 缺點:

Webservcie由于是遵循標準的soap協(xié)議，soap 協(xié)議的內(nèi)容格式固定，soap協(xié)議傳遞的內(nèi)容是xml數(shù)據(jù)，由于webservice是基于http的，所以簡單理解為soap=http+xml，適用于沒有性能要求情況下且數(shù)據(jù)傳輸量小，推薦在公開接口上使用webservice，因為soap協(xié)議的標準的。

優(yōu)點如下:

? 可操作的的分布式應(yīng)用程序可以實現(xiàn)不同應(yīng)用程序和在不同系統(tǒng)平臺上開發(fā)出來的應(yīng)用程序之間通信。與RMI、DOCM、CORBA最大的不同就是：Web Service 以 SOAP 作為基本通信協(xié)議從而避免了復(fù)雜的協(xié)議轉(zhuǎn)換.? Web Service 甚至可以穿越防火墻，真正的自由通信 一般要訪問的Web服務(wù)器以及要訪問的Web Service的客戶端很可能位于防火墻后面，都默認關(guān)閉其它端口而開放HTTP端口，而Web service 正是基于HTTP的，所以它可以穿越防火墻.? 普遍性、使用HTTP和XML進行通信 任何支持HTTP和XML 技術(shù)的設(shè)備都可以擁有和訪問Web Service，不同平臺不同開發(fā)語言照樣可以調(diào)用我們發(fā)布的Web Service.? 應(yīng)用程序集成企業(yè)級的應(yīng)用程序開發(fā)者都知道，企業(yè)里經(jīng)常都要把用不同語言寫成的、在不同平臺上運行的各種程序集成起來，而這種集成將花費很大的開發(fā)力量。應(yīng)用程序經(jīng)常需要從運行在IBM 主機上的程序中獲取數(shù)據(jù)；或者把數(shù)據(jù)發(fā)送到主機或UNIX 應(yīng)用程序中去。即使在同一個平臺上，不同軟件廠商生產(chǎn)的各種軟件也常常需要集成起來。通過WebService ，應(yīng)用程序可以用標準的方法把功能和數(shù)據(jù)“ 暴露” 出來，供其它應(yīng)用程序使用。? B2B 的集成用WebService 集成應(yīng)用程序，可以使公司內(nèi)部的商務(wù)處理更加自動化。但當交易跨越供應(yīng)商和客戶、突破公司的界限時會怎么樣呢？跨公司的商務(wù)交易集成通常叫做B2B 集成。WebService 是B2B 集成成功的關(guān)鍵。通過WebService ，公司可以把關(guān)鍵的商務(wù)應(yīng)用“ 暴露” 給指定的供應(yīng)商和客戶。

缺點如下:

缺點一：單機應(yīng)用程序

目前，企業(yè)和個人還使用著很多桌面應(yīng)用程序。其中一些只需要與本機上的其它程序通信。在這種情況下，最好就不要用WebService ，只要用本地的 API 就可以了。COM 非常適合于在這種情況下工作，因為它既小又快。運行在同一臺服務(wù)器上的服務(wù)器軟件也是這樣。最好直接用COM 或其它本地的API 來 進行應(yīng)用程序間的調(diào)用。當然WebService 也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。

?

缺點二：局域網(wǎng)的同構(gòu)應(yīng)用程序

在許多應(yīng)用中，所有的程序都是用VB 或VC 開發(fā)的，都在Windows 平臺下使用COM ，都運行在同一個局域網(wǎng)上。例如，有兩個服務(wù)器應(yīng)用程序需要相互通信，或者有一個Win32 或WinForm 的客戶程序要連接局域網(wǎng)上另一個服務(wù)器的程序。在這些程序里，使用DCOM(docm: 分布式組件對象模型,分布式組件對象模式) 會比SOAP/HTTP 有效得多。 與此相類似，如果一個.NET 程序要連接到局域網(wǎng)上的另一個.NET 程序，應(yīng)該使用.NETremoting 。有趣的是，在.NETremoting 中， 也可以指定使用SOAP/HTTP 來進行WebService 調(diào)用。不過最好還是直接通過TCP 進行RPC(rpc: 遠程過程調(diào)用) 調(diào)用，那樣會有效得多。

?

對WebService作補充:

一、WebService是什么？1. 基于Web的服務(wù)：服務(wù)器端整出一些資源讓客戶端應(yīng)用訪問（獲取數(shù)據(jù)）2. 一個跨語言、跨平臺的規(guī)范（抽象）3. 多個跨平臺、跨語言的應(yīng)用間通信整合的方案（實際）二、為什么要用Web service？web service能解決：跨平臺調(diào)用跨語言調(diào)用遠程調(diào)用 三、什么時候使用web Service?1. 同一家公司的新舊應(yīng)用之間2. 不同公司的應(yīng)用之間 　　3. 一些提供數(shù)據(jù)的內(nèi)容聚合應(yīng)用：天氣預(yù)報、股票行情
四、WebService中的幾個重要術(shù)語 4.1、WSDL(web service definition language) 　　WSDL是webservice定義語言, 對應(yīng).wsdl文檔, 一個webservice會對應(yīng)一個唯一的wsdl文檔, 定義了客戶端與服務(wù)端發(fā)送請求和響應(yīng)的數(shù)據(jù)格式和過程 4.2、SOAP(simple object access protocal) SOAP是"簡單對象訪問協(xié)議" 　　1.是一種簡單的、基于HTTP和XML的協(xié)議, 用于在WEB上交換結(jié)構(gòu)化的數(shù)據(jù) 　　2.soap消息：請求消息和響應(yīng)消息
4.3、SEI(WebService EndPoint Interface) 　　SEI是web service的終端接口，就是WebService服務(wù)器端用來處理請求的接口 4.4、CXF(Celtix + XFire) 　　一個apache的用于開發(fā)webservice服務(wù)器端和客戶端的框架。

五.總結(jié)
　　Web service是創(chuàng)建可互操作的分布式應(yīng)用程序的新平臺。Web service 的主要目標是跨平臺的可互操作性。為了達到這一目標，Web service 是完全基于XML、XSD等獨立于平臺、獨立于軟件供應(yīng)商的標準的。

　　Web service在應(yīng)用程序跨平臺和跨網(wǎng)絡(luò)進行通信的時候是非常有用的。Web service適用于應(yīng)用程序集成、B2B集成、代碼和數(shù)據(jù)重用，以及通過Web進行客戶端和服務(wù)器的通信的場合。

　　當然，Web service也不是萬能的，你不能到處濫用Web service.在有些情況下，Web service 會降低應(yīng)用程序的性能，而不會帶來任何好處。
例如，一臺機器或一個局域網(wǎng)里面運行的同構(gòu)應(yīng)用程序就不應(yīng)該用Web service 進行通信

優(yōu)秀博文(建議關(guān)注這個大佬博客獲取跟多Webservice好文):

https://www.cnblogs.com/xdp-gacl/p/4259109.html

https://www.cnblogs.com/ShaYeBlog/p/4129427.html

?

?

四. http(應(yīng)用層協(xié)議)

1.http 是什么?

http :超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol) ,是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個標準。

是一種建立在TCP上的無狀態(tài)連接，整個基本的工作流程是客戶端發(fā)送一個HTTP請求，說明客戶端想要訪問的資源和請求的動作，服務(wù)端收到請求之后，服務(wù)端開始處理請求，并根據(jù)請求做出相應(yīng)的動作訪問服務(wù)器資源，最后通過發(fā)送HTTP響應(yīng)把結(jié)果返回給客戶端。

補充:? HTTP中永遠是這樣，也就是說一個request只能有一個response。而且這個response也是被動的，不能主動發(fā)起。(且每次都要重新建立連接,這點不及WebSocket協(xié)議優(yōu)秀)

?

2.http請求 和 響應(yīng)

? 請求:

HTTP請求是客戶端往服務(wù)端發(fā)送請求動作，告知服務(wù)器自己的要求。??

HTTP請求由狀態(tài)行、請求頭、請求正文三部分組成：
狀態(tài)行：包括請求方式Method(GET、POST、PUT上傳、DELETE刪除)、資源路徑URL、協(xié)議版本Version； 請求頭：包括一些訪問的域名、用戶代理、Cookie等信息； 請求正文：就是HTTP請求的數(shù)據(jù)。

? 響應(yīng):

服務(wù)器收到了客戶端發(fā)來的HTTP請求后，根據(jù)HTTP請求中的動作要求，服務(wù)端做出具體的動作，將結(jié)果回應(yīng)給客戶端，稱為HTTP響應(yīng).

HTTP響應(yīng)由三部分組成：狀態(tài)行、響應(yīng)頭、響應(yīng)正文.
狀態(tài)行：包括協(xié)議版本Version、狀態(tài)碼Status Code、回應(yīng)短語； 響應(yīng)頭：包括搭建服務(wù)器的軟件，發(fā)送響應(yīng)的時間，回應(yīng)數(shù)據(jù)的格式等信息； 響應(yīng)正文：就是響應(yīng)的具體數(shù)據(jù)。

補充:HTTP響應(yīng)的狀態(tài)碼 : https://blog.csdn.net/dufufd/article/details/53112184

?

3.http的優(yōu)缺點

優(yōu)點: 1.支持客戶/服務(wù)器模式。2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type（Content-Type是HTTP包中用來表示內(nèi)容類型的標識）加以標記。4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。缺點: 1.通信使用明文(不加密),內(nèi)容可能會被竊聽 ? HTTP 報文使用明文（指未經(jīng)過加密的報文）方式發(fā)送. eg:被人抓包2.不驗證通信方的身份, 因此可能遭遇偽裝 ? 無法判定請求是來自何方、出自誰手 ? 無意義的請求也會照單全收 HTTP 協(xié)議中的請求和響應(yīng)不會對通信方進行確認。也就是說存在“服務(wù)器是否就是發(fā)送請求中 URI 真正指定的主機，返回的響應(yīng)是否真的返回到實際提出請求的客戶端”等類似問題(解決這個問題,要用ssl:https://baike.baidu.com/item/ssl/320778?fr=aladdin)。 在 HTTP 協(xié)議通信時，由于不存在確認通信方的處理步驟，任何人都可以發(fā)起請求! 另外，服務(wù)器只要接收到請求，不管對方是誰都會返回一個響應(yīng)（但也僅限于發(fā)送端的 IP 地址和端口號沒有被 Web 服務(wù)器設(shè)定限制訪問的前提下,類似于白名單）.3.無法證明報文的完整性, 所以有可能已遭篡改 所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。 由于 HTTP 協(xié)議無法證明通信的報文完整性，因此，在請求或響應(yīng)送出之后直到對方接收之前的這段時間內(nèi)，即使請求或響應(yīng)的內(nèi)容遭到篡改，也沒有辦法獲悉。換句話說，沒有任何辦法確認，發(fā)出的請求 / 響應(yīng)和接收到的請求 / 響應(yīng)是前后相同的。4. 缺點補充 1) 傳輸速度慢，數(shù)據(jù)包大（http協(xié)議中包含輔助應(yīng)用信息,eg:header頭中帶著大量信息） 2) 如實時交互，服務(wù)器性能壓力大。 3) 數(shù)據(jù)傳輸安全性差

?

4.http1.0 和1.1版本的區(qū)別

發(fā)展到如今有2個版本: HTTP 1.0版本?? /?? HTTP 1.1版本(普遍使用)? / HTTP 2.0. ? http幾個版本重點區(qū)別如下:

1.HTTP 1.0需要使用keep-alive參數(shù)來告知服務(wù)器端要建立一個長連接，而HTTP1.1默認支持長連接。
補充長連接和短連接的區(qū)別: https://blog.csdn.net/q547550831/article/details/50445385
HTTP1.1默認支持長連接的優(yōu)點: HTTP是基于TCP/IP協(xié)議的，創(chuàng)建一個TCP連接是需要經(jīng)過三次握手的,有一定的開銷，如果每次通訊都要重新建立連接的話，對性能有影響。因此最好能維持一個長連接，可以用個長連接來發(fā)多個請求。節(jié)省帶寬但安全性較差.
2. .............

5. http優(yōu)秀的資料必看

百度百科 :https://baike.baidu.com/item/http/243074?fr=aladdin

http總結(jié) :http://www.cnblogs.com/ranyonsue/p/5984001.html

?

?

五. https(應(yīng)用層協(xié)議)

1.1 https是什么?

https 是超文本傳輸安全協(xié)議,是以安全為目標的HTTP通道，簡單講是HTTP的安全版。

即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL。 它是一個URI scheme（抽象標識符體系），句法類同http:體系。用于安全的HTTP數(shù)據(jù)傳輸。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默認端口及一個加密/身份驗證層（在HTTP與TCP之間）。這個系統(tǒng)的最初研發(fā)由網(wǎng)景公司(Netscape)進行，并內(nèi)置于其瀏覽器Netscape Navigator中，提供了身份驗證與加密通訊方法。現(xiàn)在它被廣泛用于萬維網(wǎng)上安全敏感的通訊，例如交易支付方面.

補充:已經(jīng)有了http , 為什么還要用https?

超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息。HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協(xié)議不適合傳輸一些敏感信息，比如信用卡號、密碼等。 為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議HTTPS。為了數(shù)據(jù)傳輸?shù)陌踩?#xff0c;HTTPS在HTTP的基礎(chǔ)上加入了SSL協(xié)議，SSL依靠證書來驗證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密。

?

1.2 https?? 和 http 的區(qū)別?

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

?https協(xié)議需要到ca申請證書，一般免費證書很少，需要交費。

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

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

?

1.3 https參考資料

百度百科: https://baike.baidu.com/item/https/285356?fr=aladdin

?

?

?

?

?

?

?

?

?

這幾天做了一個搬運工, 同時也對 socket/WebSocket/WebService/http/https (或許不該放一起比較,原諒我,因為我是發(fā)現(xiàn)這5個唯一的共同點 :就是能讓客戶端和服務(wù)器進行通信)有了一個更加全面的分析和認識度, 這5個 哈哈哈, 根本不是同一個東西, 以前不明確,總是以為都差不多, 細細認知下來, 天大的差別. ? 感謝大v們在網(wǎng)上的分享.謝謝您們!

溫故而知新, 加油!

?

轉(zhuǎn)載于:https://www.cnblogs.com/PinkPink/p/10138843.html

總結(jié)

以上是生活随笔為你收集整理的socket/WebSocket/WebService/http/https概念的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。