http協(xié)議和https協(xié)議有什么關(guān)系嗎？感謝邀請(qǐng)，對(duì)于你的問(wèn)題：HTTP與HTTPS有什么區(qū)別？我的回答如下：HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不

http協(xié)議和https協(xié)議有什么關(guān)系嗎？

感謝邀請(qǐng)，對(duì)于你的問(wèn)題：HTTP與HTTPS有什么區(qū)別？

我的回答如下：

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS。簡(jiǎn)單來(lái)說(shuō)，HTTPS協(xié)議是由SSL HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全。

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

1、https協(xié)議需要到ca申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。

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

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

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

謝謝采納！

微服務(wù)調(diào)用為啥用RPC框架，http不更簡(jiǎn)單嗎？

簡(jiǎn)單點(diǎn)，HTTP是協(xié)議，RPC是概念！實(shí)現(xiàn)RPC可以基于HTTP協(xié)議（Feign），TCP協(xié)議(Netty)，RMI協(xié)議（Soap），WebService（XML—RPC）框架。傳輸過(guò)程中，也因?yàn)樾蛄谢绞降牟煌钟幸恍┛蚣芎蛥f(xié)議，比如Dubbo中的Dubbo協(xié)議，gRpc—Protobuf序列化協(xié)議等等。其實(shí)，都是基于遠(yuǎn)程調(diào)用的概念，何為遠(yuǎn)程調(diào)用？

重點(diǎn)是，RPC就是遠(yuǎn)程調(diào)用，遠(yuǎn)程調(diào)用就是客戶端把調(diào)用的接口，參數(shù)，參數(shù)類型，方法，返回值，返回值類型等（這些稱為方法簽名），通過(guò)如上的協(xié)議，發(fā)送給服務(wù)端，告知服務(wù)端需要調(diào)用的接口方法，這個(gè)過(guò)程就是RPC的實(shí)現(xiàn)過(guò)程！HTTP和RPC是不同層面的兩個(gè)東西！

性能方面，HTTP本身是基于TCP協(xié)議的，屬于應(yīng)用層協(xié)議，所以HTTP協(xié)議本身在實(shí)現(xiàn)過(guò)程中就會(huì)占用大量的資源（內(nèi)存，帶寬等），性能上肯定沒(méi)有通過(guò)TCP直接實(shí)現(xiàn)RPC協(xié)議快，不管HTTP如何優(yōu)化肯定的是不如TCP的！而TCP則是依靠字節(jié)碼，現(xiàn)在普遍采用的是將客戶端調(diào)用的接口信息，序列化的方式發(fā)送給服務(wù)端，序列化框架又包含很多（Hession，Protobuf，Kryo等等，序列化性能最高的是Kryo，序列化后字節(jié)碼最小的是Protobuf），序列化后的字節(jié)碼越小，占用帶寬越少，序列化時(shí)間越短，線程IO等待時(shí)間就會(huì)越小。所以，在具體應(yīng)用層面有很多可探討的技術(shù)，可以根據(jù)自己的硬件能力來(lái)選擇相應(yīng)的技術(shù)就可以了！

歡迎熱愛(ài)技術(shù)的人來(lái)探討！

假設(shè)我拿到了別的用戶的淘寶網(wǎng)站的cookie，我放到自己的http請(qǐng)求里，我就可以冒充這個(gè)用戶嗎？

大家都知道，Cookie是會(huì)話保持技術(shù)方案的一種，從理論上說(shuō)拿到了Cookie是可以冒充用戶的。下面具體分析下：

Cookie的機(jī)制原理

我們知道HTTP協(xié)議本身就是無(wú)狀態(tài)的，服務(wù)器端默認(rèn)情況下是無(wú)法分辨用戶的，這樣顯然是不合理的，所以我們需要給每個(gè)訪客加上一個(gè)“標(biāo)識(shí)口令”。當(dāng)分配了標(biāo)識(shí)口令給客戶端后，客戶端瀏覽器后續(xù)發(fā)起的請(qǐng)求都會(huì)把這個(gè)“標(biāo)識(shí)口令”附帶在請(qǐng)求頭參數(shù)里，這樣服務(wù)器端就能分辨哪些請(qǐng)求是同一個(gè)用戶了。

這個(gè)“標(biāo)識(shí)口令”由服務(wù)器端生成，放置在客戶端瀏覽器Cookie中，而服務(wù)器端對(duì)應(yīng)會(huì)有一個(gè)Session，這個(gè)Session的唯一標(biāo)識(shí)（SessionID）也是存儲(chǔ)在Cookie中。

篡改Cookie可以冒用請(qǐng)求

上面講到了，服務(wù)器端的SessionID是存儲(chǔ)在客戶端Cookie中的，這樣一來(lái)其它用戶一旦拿到Cookie中的SessionID后，是可以冒充原始用戶發(fā)起請(qǐng)求的。

這看上去是不合理的！

但是，Cookie和Session的機(jī)制如此。我們說(shuō)Cookie禁用后Session可能不能正常使用，但是我們可以將SessionID以GET方式傳遞給服務(wù)器端，所以SessionID如果明文傳輸就存在安全隱患。

拿到了淘寶的Cookie是無(wú)法冒充用戶的

正因?yàn)镃ookie是存儲(chǔ)在客戶端且不安全的，所以我們將用戶數(shù)據(jù)存儲(chǔ)在Cookie中時(shí)都會(huì)對(duì)數(shù)據(jù)進(jìn)行加密。比如會(huì)驗(yàn)證用戶的IP、終端特征標(biāo)識(shí)等。即使其他用戶偽造了Cookie依舊是無(wú)法驗(yàn)證通過(guò)的。