https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術(shù)進行客戶端與服務器的數(shù)據(jù)加密傳輸，最終達到保證整個通信的安全性。點擊這里弄懂 https 的 9 個問題。

SSL/TLS協(xié)議作用：

• 認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器;
• 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取;
• 維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。

Http協(xié)議由什么組成?

請求報文包括三部分：

• 請求行:包含請求方法,URI,HTTP版本協(xié)議
• 請求首部字段
• 請求內(nèi)容實體

響應報文包含三部分：

• 狀態(tài)行:包含HTTP版本,狀態(tài)碼,狀態(tài)碼原因短語
• 響應首部字段
• 響應內(nèi)容實體

冪等

一個冪等操作的特點是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。冪等函數(shù)，或冪等方法，是指可以使用相同參數(shù)重復執(zhí)行，并能獲得相同結(jié)果的函數(shù)。這些函數(shù)不會影響系統(tǒng)狀態(tài)，也不用擔心重復執(zhí)行會對系統(tǒng)造成改變。例如，“getUsername()和setTrue()”函數(shù)就是一個冪等函數(shù).

長連接

1. 基于http協(xié)議的長連接

在HTTP1.0和HTTP1.1協(xié)議中都有對長連接的支持。其中HTTP1.0需要在request中增加”Connection： keep-alive“ header才能夠支持，而HTTP1.1默認支持.

http1.0請求與服務端的交互過程：

• 客戶端發(fā)出帶有包含一個header：”Connection： keep-alive“的請求
• 服務端接收到這個請求后,根據(jù)http1.0和”Connection： keep-alive“判斷出這是一個長連接,就會在response的header中也增加”Connection： keep-alive“,同是不會關(guān)閉已建立的tcp連接.
• 客戶端收到服務端的response后,發(fā)現(xiàn)其中包含”Connection： keep-alive“，就認為是一個長連接，不關(guān)閉這個連接。并用該連接再發(fā)送request.轉(zhuǎn)到a)，點擊這里了解 http 1.0 vs 2.0 區(qū)別。

2. 發(fā)心跳包。每隔幾秒就發(fā)一個數(shù)據(jù)包過去

Http協(xié)議中Http1.0和1.1區(qū)別?

在http1.0中，當建立連接后，客戶端發(fā)送一個請求，服務器端返回一個信息后就關(guān)閉連接，當瀏覽器下次請求的 時候又要建立連接，顯然這種不斷建立連接的方式，會造成很多問題。

Http協(xié)議實現(xiàn)的原理機制：

• 域名解析過程:
• 三次握手過程
• 發(fā)起Http請求
• 響應Http請求并得到HTML代碼
• 瀏覽器解析HTML代碼
• 瀏覽器對頁面進行渲染呈現(xiàn)給用戶

Cookie是否會被覆蓋,localStorage是否會被覆蓋

Cookie是可以覆蓋的，如果重復寫入同名的Cookie，那么將會覆蓋之前的Cookie。

如果要刪除某個Cookie，只需要新建一個同名的Cookie，并將maxAge設(shè)置為0，并添加到response中覆蓋原來的Cookie。注意是0而不是負數(shù)。負數(shù)代表其他的意義。

localStorage存儲在一個對象中，有鍵值對。

什么是localStorage,在HTML5中，新加入了一個localStorage特性，這個特性主要是用來作為本地存儲來使用的，解決了cookie存儲空間不足的問題(cookie中每條cookie的存儲空間為4k)，localStorage中一般瀏覽器支持的是5M大小，這個在不同的瀏覽器中l(wèi)ocalStorage會有所不同。

localStorage的優(yōu)勢

• localStorage拓展了cookie的4K限制
• localStorage會可以將第一次請求的數(shù)據(jù)直接存儲到本地，這個相當于一個5M大小的針對于前端頁面的數(shù)據(jù)庫，相比于cookie可以節(jié)約帶寬，但是這個卻是只有在高版本的瀏覽器中才支持的

localStorage的局限

• 瀏覽器的大小不統(tǒng)一，并且在IE8以上的IE版本才支持localStorage這個屬性
• 目前所有的瀏覽器中都會把localStorage的值類型限定為string類型，這個在對我們?nèi)粘１容^常見的JSON對象類型需要一些轉(zhuǎn)換
• localStorage在瀏覽器的隱私模式下面是不可讀取的
• localStorage本質(zhì)上是對字符串的讀取，如果存儲內(nèi)容多的話會消耗內(nèi)存空間，會導致頁面變卡
• localStorage不能被爬蟲抓取到

localStorage與sessionStorage的唯一一點區(qū)別就是localStorage屬于永久性存儲，而sessionStorage屬于當會話結(jié)束的時候，sessionStorage中的鍵值對會被清空

Cookie和Session的區(qū)別

HTTP 是一種無狀態(tài)的連接，客戶端每次讀取 web頁面時，服務器都會認為這是一次新的會話。但有時候我們又需要持久保持某些信息，比如登錄時的用戶名、密碼，用戶上一次連接時的信息等。這些信息就由 Cookie 和 Session 保存。

1. Cookie

cookie實際上是一小段文本信息。客戶端請求服務器，如果服務器需要記錄該用戶狀態(tài)，就使用response向客戶端瀏覽器頒發(fā)一個cookie，客戶端瀏覽器會把cookie保存起來，當瀏覽器再次請求訪問該網(wǎng)站時，瀏覽器把請求的網(wǎng)站連同該cookie一同提交給服務器，服務器檢查該cookie，以此來辨認用戶狀態(tài)。

簡單來說，cookie的工作原理可總結(jié)如下：

• client連接server
• client生成cookie(有效期),再次訪問時攜帶cookie
• server根據(jù)cookie的信息識別用戶身份

2. Session

Session是服務器端使用的一種記錄客戶端狀態(tài)的機制，使用上比Cookie簡單一些。同一個客戶端每次和服務端交互時，不需要每次都傳回所有的 Cookie 值，而是只要傳回一個 ID，這個 ID 是客戶端第一次訪問服務器的時候生成的，而且每個客戶端是唯一的。這樣每個客戶端就有了一個唯一的 ID，客戶端只要傳回這個 ID 就行了，這個 ID 通常是 name為 JSESIONID 的一個 Cookie。Session依據(jù)這個id來識別是否為同一用戶(只認ID不認人)。

Cookies是一種能夠讓網(wǎng)站服務器把少量數(shù)據(jù)儲存到客戶端的硬盤或內(nèi)存，或是從客戶端的硬盤讀取數(shù)據(jù)的一種技術(shù)。Cookies是當你瀏覽某網(wǎng)站時，由Web服務器置于你硬盤上的一個非常小的文本文件，它可以記錄你的用戶ID、密碼、瀏覽過的網(wǎng)頁、停留的時間等信息。session: 當用戶請求來自應用程序的 Web 頁時，如果該用戶還沒有會話，則 Web 服務器將自動創(chuàng)建一個 Session 對象。當會話過期或被放棄后，服務器將終止該會話。cookie機制：采用的是在客戶端保持狀態(tài)的方案，而session機制采用的是在服務端保持狀態(tài)的方案。同時我們看到由于服務器端保持狀態(tài)的方案在客戶端也需要保存一個標識，所以session機制可能需要借助cookie機制來達到保存標識的目的。

Session是服務器用來跟蹤用戶的一種手段，每個Session都有一個唯一標識：session ID。當服務器創(chuàng)建了Session時，給客戶端發(fā)送的響應報文包含了Set-cookie字段，其中有一個名為sid的鍵值對，這個鍵值Session ID。客戶端收到后就把Cookie保存瀏覽器，并且之后發(fā)送的請求報表都包含SessionID。HTTP就是通過Session和Cookie這兩個發(fā)送一起合作來實現(xiàn)跟蹤用戶狀態(tài)，Session用于服務端，Cookie用于客戶端：

• cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上。
• cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙。考慮到安全應當使用session。
• session會在一定時間內(nèi)保存在服務器上。當訪問增多，會比較占用你服務器的性能 考慮到減輕服務器性能方面，應當使用COOKIE。
• 單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。

Http與Https的區(qū)別：

• HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 標準端口是80 ，而 HTTPS 的標準端口是443
• 在OSI 網(wǎng)絡(luò)模型中，HTTP工作于應用層，而HTTPS 的安全傳輸機制工作在傳輸層
• HTTP 無法加密，而HTTPS 對傳輸?shù)臄?shù)據(jù)進行加密
• HTTP無需證書，而HTTPS 需要CA機構(gòu)wosign的頒發(fā)的SSL證書

什么是Http協(xié)議無狀態(tài)協(xié)議?怎么解決Http協(xié)議無狀態(tài)協(xié)議?

無狀態(tài)協(xié)議對于事務處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息

也就是說，當客戶端一次HTTP請求完成以后，客戶端再發(fā)送一次HTTP請求，HTTP并不知道當前客戶端是一個”老用戶“。

可以使用Cookie來解決無狀態(tài)的問題，Cookie就相當于一個通行證，第一次訪問的時候給客戶端發(fā)送一個Cookie，當客戶端再次來的時候，拿著Cookie(通行證)，那么服務器就知道這個是”老用戶“。

URI和URL的區(qū)別

1. URI

URI，是uniform resource identifier，統(tǒng)一資源標識符，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是一個來URI來定位的

URI一般由三部組成：

• 訪問資源的命名機制
• 存放資源的主機名
• 資源自身的名稱，由路徑表示，著重強調(diào)于資源。

2. URL

URL是uniform resource locator，統(tǒng)一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何locate這個資源。

URL是Internet上用來描述信息資源的字符串，主要用在各種WWW客戶程序和服務器程序上，特別是著名的Mosaic。

采用URL可以用一種統(tǒng)一的格式來描述各種信息資源，包括文件、服務器的地址和目錄等。

URL一般由三部組成：

• 協(xié)議(或稱為服務方式)
• 存有該資源的主機IP地址(有時也包括端口號)
• 主機資源的具體地址。如目錄和文件名等

URN，uniform resource name，統(tǒng)一資源命名，是通過名字來標識資源，比如mailto:java-net@java.sun.com。

URI是以一種抽象的，高層次概念定義統(tǒng)一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統(tǒng)地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統(tǒng)一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一個URI實例可以代表絕對的，也可以是相對的，只要它符合URI的語法規(guī)則。而URL類則不僅符合語義，還包含了定位該資源的信息，因此它不能是相對的。

在Java類庫中，URI類不包含任何訪問資源的方法，它唯一的作用就是解析。

相反的是，URL類可以打開一個到達資源的流。

HTTP之URL

HTTP使用統(tǒng)一資源標識符(Uniform Resource Identifiers, URI)來傳輸數(shù)據(jù)和建立連接。URL是一種特殊類型的URI，包含了用于查找某個資源的足夠的信息

URL,全稱是UniformResourceLocator, 中文叫統(tǒng)一資源定位符,是互聯(lián)網(wǎng)上用來標識某一處資源的地址。以下面這個URL為例，介紹下普通URL的各部分組成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個完整的URL包括以下幾部分：

• 協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁使用的是HTTP協(xié)議。在Internet中可以使用多種協(xié)議，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議。在"HTTP"后面的“//”為分隔符
• 域名部分：該URL的域名部分為“www.aspxfans.com”。一個URL中，也可以使用IP地址作為域名使用
• 端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，將采用默認端口
• 虛擬目錄部分：從域名后的第一個“/”開始到最后一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
• 文件名部分：從域名后的最后一個“/”開始到“?”為止，是文件名部分，如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止，是文件部分，如果沒有“?”和“#”，那么從域名后的最后一個“/”開始到結(jié)束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用默認的文件名
• 錨部分：從“#”開始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
• 參數(shù)部分：從“?”開始到“#”為止之間的部分為參數(shù)部分，又稱搜索部分、查詢部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

(原文：http://blog.csdn.net/ergouge/article/details/8185219 )

HTTPS工作原理

• 首先HTTP請求服務端生成證書，客戶端對證書的有效期、合法性、域名是否與請求的域名一致、證書的公鑰(RSA加密)等進行校驗;
• 客戶端如果校驗通過后，就根據(jù)證書的公鑰的有效， 生成隨機數(shù)，隨機數(shù)使用公鑰進行加密(RSA加密);
• 消息體產(chǎn)生的后，對它的摘要進行MD5(或者SHA1)算法加密，此時就得到了RSA簽名;
• 發(fā)送給服務端，此時只有服務端(RSA私鑰)能解密。
• 解密得到的隨機數(shù)，再用AES加密，作為密鑰(此時的密鑰只有客戶端和服務端知道)。

一次完整的HTTP請求所經(jīng)歷的7個步驟

HTTP通信機制是在一次完整的HTTP通信過程中，Web瀏覽器與Web服務器之間將完成下列7個步驟：

1. 建立TCP連接

在HTTP工作開始之前，Web瀏覽器首先要通過網(wǎng)絡(luò)與Web服務器建立連接，該連接是通過TCP來完成的，該協(xié)議與IP協(xié)議共同構(gòu)建 Internet，即著名的TCP/IP協(xié)議族，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應用層協(xié)議，根據(jù)規(guī)則， 只有低層協(xié)議建立之后才能，才能進行更層協(xié)議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。

Web瀏覽器向Web服務器發(fā)送請求行

一旦建立了TCP連接，Web瀏覽器就會向Web服務器發(fā)送請求命令。例如：GET /sample/hello.jsp HTTP/1.1。

2. Web瀏覽器發(fā)送請求頭

瀏覽器發(fā)送其請求命令之后，還要以頭信息的形式向Web服務器發(fā)送一些別的信息，之后瀏覽器發(fā)送了一空白行來通知服務器，它已經(jīng)結(jié)束了該頭信息的發(fā)送。

3. Web服務器應答

客戶機向服務器發(fā)出請求后，服務器會客戶機回送應答， HTTP/1.1 200 OK ，應答的第一部分是協(xié)議的版本號和應答狀態(tài)碼。

4. Web服務器發(fā)送應答頭

正如客戶端會隨同請求發(fā)送關(guān)于自身的信息一樣，服務器也會隨同應答向用戶發(fā)送關(guān)于它自己的數(shù)據(jù)及被請求的文檔。

5. Web服務器向瀏覽器發(fā)送數(shù)據(jù)

Web服務器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此為結(jié)束，接著，它就以Content-Type應答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù)。

6. Web服務器關(guān)閉TCP連接

一般情況下，一旦Web服務器向瀏覽器發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果瀏覽器或者服務器在其頭信息加入了這行代碼：

7. Connection:keep-alive

TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。

建立TCP連接->發(fā)送請求行->發(fā)送請求頭->(到達服務器)發(fā)送狀態(tài)行->發(fā)送響應頭->發(fā)送響應數(shù)據(jù)->斷TCP連接

常見的HTTP相應狀態(tài)碼

• 200：請求被正常處理
• 204：請求被受理但沒有資源可以返回
• 206：客戶端只是請求資源的一部分，服務器只對請求的部分資源執(zhí)行GET方法，相應報文中通過Content-Range指定范圍的資源。
• 301：永久性重定向
• 302：臨時重定向
• 303：與302狀態(tài)碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
• 304：發(fā)送附帶條件的請求時，條件不滿足時返回，與重定向無關(guān)
• 307：臨時重定向，與302類似，只是強制要求使用POST方法
• 400：請求報文語法有誤，服務器無法識別
• 401：請求需要認證
• 403：請求的對應資源禁止被訪問
• 404：服務器無法找到對應資源
• 500：服務器內(nèi)部錯誤
• 503：服務器正忙

HTTP工作原理

HTTP協(xié)議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請求/響應模型。客戶端向服務器發(fā)送一個請求報文，請求報文包含請求的方法、URL、協(xié)議版本、請求頭部和請求數(shù)據(jù)。服務器以一個狀態(tài)行作為響應，響應的內(nèi)容包括協(xié)議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數(shù)據(jù)。

以下是 HTTP 請求/響應的步驟：

• 客戶端連接到Web服務器：一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口(默認為80)建立一個TCP套接字連接。例如，http://www.oakcms.cn。
• 發(fā)送HTTP請求：通過TCP套接字，客戶端向Web服務器發(fā)送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數(shù)據(jù)4部分組成。
• 服務器接受請求并返回HTTP響應：Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態(tài)行、響應頭部、空行和響應數(shù)據(jù)4部分組成。
• 釋放連接TCP連接