HTTP是面向事務的拷泽，即它傳輸?shù)臄?shù)據(jù)是一個整體疫鹊，要么全部收到，要么全部收不到司致。

每一次HTTP請求就需要建立一次TCP連接和釋放TCP連接拆吆。

HTTP是無連接，無狀態(tài)的脂矫。每一次請求都是作為一次新請求枣耀。

HTTP/1.0 缺點: 無連接，每一次請求都要重新建立TCP連接庭再，所以每一次HTTP請求都要花費2倍RTT時間(一次TCP請求捞奕，一次HTTP請求)

HTTP/1.1: 使用持續(xù)連接，即保持TCP連接一段時間拄轻。

HTTP/1.1持續(xù)工作的兩種工作方式 : 非流水線方式和流水線方式

????● 非流水線方式 : 收到一個請求的響應再發(fā)下一個請求颅围，效率低，浪費資源

????●?流水線方式 : 能夠同時發(fā)送多個請求恨搓，效率高

HTTP協(xié)議包括哪些請求院促？

GET：請求讀取由URL所標志的信息。

POST：給服務器添加信息（如注釋）斧抱。

PUT：在給定的URL下存儲一個文檔常拓。

DELETE：刪除給定的URL所標志的資源。

GET與POST之間的區(qū)別主要包括如下五個方面：

(1). 從功能上講夺姑，GET一般用來從服務器上獲取資源墩邀，POST一般用來更新服務器上的資源；

(2). 從REST服務角度上說盏浙，GET是冪等的眉睹，即讀取同一個資源，總是得到相同的數(shù)據(jù)废膘，而POST不是冪等的竹海，因為每次請求對資源的改變并不是相同的；進一步地丐黄，GET不會改變服務器上的資源斋配，而POST會對服務器資源進行改變；

(3). 從請求參數(shù)形式上看，GET請求的數(shù)據(jù)會附在URL之后艰争，即將請求數(shù)據(jù)放置在HTTP報文的 請求頭 中坏瞄，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連甩卓。特別地鸠匀，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送逾柿；否則缀棍，會將其編碼為application/x-www-form-urlencoded MIME 字符串(如果是空格，轉(zhuǎn)換為+机错，如果是中文/其他字符爬范，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD弱匪，其中％XX中的XX為該符號以16進制表示的ASCII)青瀑；而POST請求會把提交的數(shù)據(jù)則放置在是HTTP請求報文的 請求體中。

(4). 就安全性而言痢法，POST的安全性要比GET的安全性高狱窘，因為GET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上杜顺，而且POST請求參數(shù)則被包裝到請求體中财搁，相對更安全。

(5). 從請求的大小看躬络，GET請求的長度受限于瀏覽器或服務器對URL長度的限制尖奔，允許發(fā)送的數(shù)據(jù)量比較小，而POST請求則是沒有大小限制的穷当。

Session提茁、Cookie與Application

Cookie和Session都是客戶端與服務器之間保持狀態(tài)的解決方案，具體來說馁菜，cookie機制采用的是在客戶端保持狀態(tài)的方案茴扁，而session機制采用的是在服務器端保持狀態(tài)的方案。

(1).Cookie

HTTP 協(xié)議是無狀態(tài)的汪疮，主要是為了讓 HTTP 協(xié)議盡可能簡單峭火，使得它能夠處理大量事務。HTTP/1.1 引入 Cookie 來保存狀態(tài)信息智嚷。

Cookie 是服務器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)卖丸，它會在瀏覽器之后向同一服務器再次發(fā)起請求時被攜帶上，用于告知服務端兩個請求是否來自同一瀏覽器盏道。由于之后每次請求都會需要攜帶 Cookie 數(shù)據(jù)稍浆，因此會帶來額外的性能開銷（尤其是在移動環(huán)境下）。

Cookie 曾一度用于客戶端數(shù)據(jù)的存儲，因為當時并沒有其它合適的存儲辦法而作為唯一的存儲手段衅枫，但現(xiàn)在隨著現(xiàn)代瀏覽器開始支持各種各樣的存儲方式嫁艇，Cookie 漸漸被淘汰。新的瀏覽器 API 已經(jīng)允許開發(fā)者直接將數(shù)據(jù)存儲到本地弦撩，如使用 Web storage API（本地存儲和會話存儲）或 IndexedDB裳仆。

Cookie實際上是一小段的文本信息」虑眨客戶端請求服務器歧斟，如果服務器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個Cookie偏形，而客戶端瀏覽器會把Cookie保存起來静袖。當瀏覽器再請求該網(wǎng)站時，瀏覽器把請求的網(wǎng)址連同該Cookie一同提交給服務器俊扭，服務器檢查該Cookie队橙，以此來辨認用戶狀態(tài)。服務器還可以根據(jù)需要修改Cookie的內(nèi)容萨惑。

(2). Session

除了可以將用戶信息通過Cookie 存儲在用戶瀏覽器中捐康，也可以利用 Session 存儲在服務器端，存儲在服務器端的信息更加安全庸蔼。

Session 可以存儲在服務器上的文件解总、數(shù)據(jù)庫或者內(nèi)存中。也可以將 Session 存儲在 Redis 這種內(nèi)存型數(shù)據(jù)庫中姐仅，效率會更高花枫。

使用Session 維護用戶登錄狀態(tài)的過程如下：

●?用戶進行登錄時，用戶提交包含用戶名和密碼的表單掏膏，放入 HTTP 請求報文中劳翰；

●?服務器驗證該用戶名和密碼，如果正確則把用戶信息存儲到 Redis 中馒疹，它在 Redis 中的 Key 稱為Session ID佳簸；

●?服務器返回的響應報文的 Set-Cookie 首部字段包含了這個 Session ID，客戶端收到響應報文之后將該 Cookie 值存入瀏覽器中颖变；

●?客戶端之后對同一個服務器進行請求時會包含該 Cookie 值生均，服務器收到之后提取出 Session ID，從 Redis 中取出用戶信息悼做，繼續(xù)之前的業(yè)務操作疯特。

應該注意Session ID 的安全性問題，不能讓它被惡意攻擊者輕易獲取肛走，那么就不能產(chǎn)生一個容易被猜到的 Session ID 值漓雅。此外，還需要經(jīng)常重新生成 Session ID。在對安全性要求極高的場景下邻吞，例如轉(zhuǎn)賬等操作组题，除了使用 Session 管理用戶狀態(tài)之外，還需要對用戶進行重新驗證抱冷，比如重新輸入密碼崔列，或者使用短信驗證碼等方式。

瀏覽器禁用Cookie

此時無法使用Cookie 來保存用戶信息旺遮，只能使用 Session赵讯。除此之外，不能再將 Session ID 存放到 Cookie 中耿眉，而是使用 URL 重寫技術(shù)边翼，將Session ID 作為 URL 的參數(shù)進行傳遞。

(3).

Session 與 Cookie 的對比與選擇

對比：

實現(xiàn)機制：Session的實現(xiàn)常常依賴于Cookie機制鸣剪，通過Cookie機制回傳SessionID组底；

大小限制：Cookie有大小限制并且瀏覽器對每個站點也有cookie的個數(shù)限制，Session沒有大小限制筐骇，理論上只與服務器的內(nèi)存大小有關(guān)债鸡；

安全性：Cookie存在安全隱患，通過攔截或本地文件找得到cookie后可以進行攻擊铛纬，而Session由于保存在服務器端厌均，相對更加安全；

服務器資源消耗：Session是保存在服務器端上會存在一段時間才會消失饺鹃，如果session過多會增加服務器的壓力

Cookie 與 Session 選擇

Cookie 只能存儲 ASCII 碼字符串莫秆，而 Session 則可以存取任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復雜性時首選 Session悔详；

Cookie 存儲在瀏覽器中，容易被惡意查看惹挟。如果非要將一些隱私數(shù)據(jù)存在 Cookie 中茄螃，可以將 Cookie 值進行加密，然后在服務器進行解密连锯；

對于大型網(wǎng)站归苍，如果用戶所有的信息都存儲在 Session 中，那么開銷是非常大的运怖，因此不建議將所有的用戶信息都存儲到 Session 中拼弃。

(4).Application

Application（Java Web中的ServletContext）：與一個Web應用程序相對應，為應用程序提供了一個全局的狀態(tài)摇展，所有客戶都可以使用該狀態(tài)吻氧。

常見狀態(tài)碼及原因短語

HTTP請求結(jié)構(gòu)：請求方式 + 請求URI + 協(xié)議及其版本

HTTP響應結(jié)構(gòu)：狀態(tài)碼 + 原因短語 + 協(xié)議及其版本

1×× : 請求處理中，請求已被接受，正在處理

2×× : 請求成功盯孙，請求被成功處理

200 OK

3×× : 重定向鲁森，要完成請求必須進行進一步處理

301 : 永久性轉(zhuǎn)移

302 ：暫時性轉(zhuǎn)移

304 ： 已緩存

4×× : 客戶端錯誤，請求不合法

400：Bad

Request,請求有語法問題

403：拒絕請求

404：客戶端所訪問的頁面不存在

5×× : 服務器端錯誤振惰，服務器不能處理合法請求

500 ：服務器內(nèi)部錯誤

503 ： 服務不可用歌溉，稍等

各種協(xié)議與HTTP協(xié)議之間的關(guān)系

HTTP長連接、短連接

長連接只需要建立一次TCP 連接就能進行多次 HTTP 通信骑晶。

????●?從 HTTP/1.1 開始默認是長連接的痛垛，如果要斷開連接，需要由客戶端或者服務器端提出斷開桶蛔，使用 Connection : close榜晦；

????●?在 HTTP/1.1 之前默認是短連接的，如果需要使用長連接羽圃，則使用 Connection : Keep-Alive乾胶。

在HTTP/1.0中默認使用短連接。也就是說朽寞，客戶端和服務器每進行一次HTTP操作识窿，就建立一次TCP連接，任務結(jié)束就中斷連接脑融。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件喻频、圖像文件、CSS文件等）肘迎，每遇到這樣一個Web資源甥温，瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1.1起妓布，默認使用長連接姻蚓，用以保持連接特性。使用長連接的HTTP協(xié)議匣沼，會在響應頭加入這行代碼：Connection:keep-alive

在使用長連接的情況下狰挡，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉释涛，客戶端再次訪問這個服務器時加叁，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接唇撬，它有一個保持時間它匕，可以在不同的服務器軟件（如Apache）中設定這個時間。實現(xiàn)長連接需要客戶端和服務端都支持長連接窖认。

HTTP協(xié)議的長連接和短連接豫柬，實質(zhì)上是TCP協(xié)議的長連接和短連接告希。

Http和Https的區(qū)別

HTTP 有以下安全性問題：

●?竊聽風險：使用明文進行通信，內(nèi)容可能會被竊聽轮傍；

●?冒充風險：不驗證通信方的身份暂雹，通信方的身份有可能遭遇偽裝；

●?篡改風險：無法證明報文的完整性创夜，報文有可能遭篡改杭跪。

HTTPs 并不是新協(xié)議，而是讓 HTTP 先和 SSL（Secure

Sockets Layer）通信驰吓，再由 SSL 和 TCP 通信涧尿，也就是說HTTPs 使用了隧道進行通信。SSL/TLS協(xié)議就是為了解決這些風險而設計檬贰，希望達到：

（1）所有信息加密傳輸姑廉，防止三方竊聽通信內(nèi)容；

（2）具有校驗機制翁涤，內(nèi)容一旦被篡改桥言，通信雙方立刻會發(fā)現(xiàn)；

（3）配備身份證書葵礼，防止身份被冒充号阿。

通過使用SSL，HTTPs 具有了加密（防竊聽）鸳粉、認證（防偽裝）和完整性保護（防篡改）扔涧。

HTTPs 的加密方式

Https的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。也即使用非對稱密鑰加密用于傳輸對稱密鑰來保證傳輸過程的安全性届谈，之后使用對稱密鑰加密進行通信來保證通信過程的效率枯夜。

SSL加密原理：

基本思路是采用公鑰加密法（最有名的是RSA加密算法）。大概流程是艰山，客戶端向服務器索要公鑰湖雹，然后用公鑰加密信息，服務器收到密文程剥，用自己的私鑰解密劝枣。

為了防止公鑰被篡改，把公鑰放在數(shù)字證書中织鲸，證書可信則公鑰可信。公鑰加密計算量很大溪胶，為了提高效率搂擦，服務端和客戶端都生成對話密鑰，用它加密信息哗脖，而對話密鑰是對稱密鑰瀑踢，速度非嘲饣梗快。而公鑰用來加密對話私鑰橱夭。

Https加密過程：

http://www.mahaixiang.cn/internet/1233.html

自己簡述：

客戶端在瀏覽器中輸入一個https網(wǎng)址氨距，然后連接到server的443端口

采用https協(xié)議的server必須有一套數(shù)字證書（一套公鑰和密鑰）

首先server將證書（公鑰）傳送到客戶端，客戶端解析證書棘劣，驗證成功俏让，則生成一個隨機數(shù)（私鑰），并用證書將該隨機數(shù)加密后傳回server

server用密鑰解密后茬暇，獲得這個隨機值首昔，然后將要傳輸?shù)男畔⒑退借€通過某種算法混合在一起（加密）傳到客戶端

客戶端用之前的生成的隨機數(shù)（私鑰）解密服務器端傳來的信息

HTTPs的認證

通過使用證書 來對通信方進行認證。

數(shù)字證書認證機構(gòu)（CA糙俗，Certificate Authority）是客戶端與服務器雙方都可信賴的第三方機構(gòu)勒奇。

服務器的運營人員向CA 提出公開密鑰的申請，CA 在判明提出申請者的身份之后巧骚，會對已申請的公開密鑰做數(shù)字簽名赊颠，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公開密鑰證書后綁定在一起劈彪。

進行HTTPs 通信時竣蹦，服務器會把證書發(fā)送給客戶端》垭客戶端取得其中的公開密鑰之后草添，先使用數(shù)字簽名進行驗證，如果驗證通過扼仲，就可以開始通信了远寸。

HTTPs完整性保護

SSL 提供報文摘要功能來進行完整性保護。

HTTP 也提供了MD5 報文摘要功能屠凶，但不是安全的驰后。例如報文內(nèi)容被篡改之后，同時重新計算 MD5 的值矗愧，通信接收方是無法意識到發(fā)生了篡改灶芝。

HTTPs 的報文摘要功能之所以安全，是因為它結(jié)合了加密和認證這兩個操作唉韭。試想一下夜涕，加密之后的報文，遭到篡改之后属愤，也很難重新計算報文摘要女器，因為無法輕易獲取明文。

HTTPs 的缺點

●?因為需要進行加密解密等過程住诸，因此速度會更慢驾胆；

●?需要支付證書授權(quán)的高額費用涣澡。

HTTPS協(xié)議在HTTP協(xié)議的基礎上，在HTTP和TCP中間加入了一層SSL/TLS加密層丧诺，解決了HTTP不安全的問題:冒充入桂，篡改，竊聽三大風險驳阎。Http協(xié)議運行在TCP之上抗愁，明文傳輸，客戶端與服務器端都無法驗證對方的身份搞隐；Https是身披SSL(Secure

Socket Layer)外殼的Http驹愚，運行于SSL上，SSL運行于TCP之上劣纲，是添加了加密和認證機制的HTTP逢捺。

二者之間存在如下不同：

（1）端口不同：Http與Http使用不同的連接方式，用的端口也不一樣癞季，前者是80劫瞳，后者是443；

（2）資源消耗：和HTTP通信相比绷柒，Https通信會由于加減密處理消耗更多的CPU和內(nèi)存資源志于；

（3）開銷：Https通信需要證書，而證書一般需要向認證機構(gòu)購買废睦；

（4）Http協(xié)議建立連接的過程比Https協(xié)議快伺绽。因為Https除了TCP三次握手，還要經(jīng)過SSL握手嗜湃。連接建立之后的數(shù)據(jù)傳輸速度奈应，二者無明顯區(qū)別。

（5）Http連接是無狀態(tài)的购披，而Https采用Http+SSL構(gòu)建可進行加密傳輸杖挣、身份認證的網(wǎng)絡協(xié)議，更安全刚陡。