詳細介紹http

HTTP協議是Hyper Text Transfer Protocol(超文本傳輸協議)的縮寫,是用于從萬維網(WWW:World Wide Web )服務器傳輸超文本到本地瀏覽器的傳送協議。在 OSI 七層模型中，HTTP協議位于最頂層的應用層中。通過瀏覽器訪問網頁就直接使用了 HTTP 協議。使用 HTTP 協議時，客戶端首先與服務端的 80 端口建立一個 TCP 連接，然后在這個連接的基礎上進行請求和應答，以及數據的交換。

[[283611]]

HTTP 有兩個常用版本，分別是 HTTP1.0和 HTTP1.1。主要區別在于 HTTP1.0 中每次請求和應答都會使用一個新的 TCP 連接，而從 HTTP1.1 開始，運行在一個 TCP 連接上發送多個命令和應答。因此大幅度減少了 TCP 連接的建立和斷開，提高了效率。

特點

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
• 支持B/S及C/S模式。

請求消息Request

• 請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
• 請求頭部，緊接著請求行(即第一行)之后的部分，用來說明服務器要使用的附加信息從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,并且在每個請求中自動發送等等
• 空行，請求頭部后面的空行是必須的
• 請求數據也叫主體，可以添加任意的其他數據。

響應消息Response

• 狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。
• 消息報頭，用來說明客戶端要使用的一些附加信息
• 空行，消息報頭后面的空行是必須的
• 響應正文，服務器返回給客戶端的文本信息。

狀態碼

• 200 OK //客戶端請求成功
• 301 Moved Permanently //永久重定向,使用域名跳轉
• 302 Found // 臨時重定向,未登陸的用戶訪問用戶中心重定向到登錄頁面
• 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
• 401 Unauthorized //請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden //服務器收到請求，但是拒絕提供服務
• 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
• 500 Internal Server Error //服務器發生不可預期的錯誤
• 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常

http的方法

• get:客戶端向服務端發起請求，獲得資源。請求獲得URL處所在的資源。
• post:向服務端提交新的請求字段。請求URL的資源后添加新的數據。
• head:請求獲取URL資源的響應報告，即獲得URL資源的頭部
• patch：請求局部修改URL所在資源的數據項
• put：請求修改URL所在資源的數據元素。
• delete：請求刪除url資源的數據

https是如何保證數據傳輸的安全

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

SSL/TLS協議作用：

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

Http協議由什么組成?

請求報文包括三部分：

• 請求行:包含請求方法,URI,HTTP版本協議
• 請求首部字段
• 請求內容實體

響應報文包含三部分：

• 狀態行:包含HTTP版本,狀態碼,狀態碼原因短語
• 響應首部字段
• 響應內容實體

冪等

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

長連接

1. 基于http協議的長連接

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

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

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

2. 發心跳包。每隔幾秒就發一個數據包過去

Http協議中Http1.0和1.1區別?

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

Http協議實現的原理機制：

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

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

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

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

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

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

localStorage的優勢

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

localStorage的局限

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

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

Cookie和Session的區別

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

1. Cookie

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

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

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

2. Session

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

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

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

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

Http與Https的區別：

• HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭
• HTTP 是不安全的，而 HTTPS 是安全的
• HTTP 標準端口是80 ，而 HTTPS 的標準端口是443
• 在OSI 網絡模型中，HTTP工作于應用層，而HTTPS 的安全傳輸機制工作在傳輸層
• HTTP 無法加密，而HTTPS 對傳輸的數據進行加密
• HTTP無需證書，而HTTPS 需要CA機構wosign的頒發的SSL證書

什么是Http協議無狀態協議?怎么解決Http協議無狀態協議?

無狀態協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息

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

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

URI和URL的區別

1. URI

URI，是uniform resource identifier，統一資源標識符，用來唯一的標識一個資源。

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

URI一般由三部組成：

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

2. URL

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

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

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

URL一般由三部組成：

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

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

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

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

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

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

HTTP之URL

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

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

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

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

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

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

HTTPS工作原理

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

一次完整的HTTP請求所經歷的7個步驟

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

1. 建立TCP連接

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

Web瀏覽器向Web服務器發送請求行

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

2. Web瀏覽器發送請求頭

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

3. Web服務器應答

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

4. Web服務器發送應答頭

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

5. Web服務器向瀏覽器發送數據

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

6. Web服務器關閉TCP連接

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

7. Connection:keep-alive

TCP連接在發送后將仍然保持打開狀態，于是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網絡帶寬。

建立TCP連接->發送請求行->發送請求頭->(到達服務器)發送狀態行->發送響應頭->發送響應數據->斷TCP連接

常見的HTTP相應狀態碼

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

HTTP工作原理

HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

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

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