也談HTTP協議

HTTP（HyperText Transfer Protocol，超文轉移協議，超文本傳輸協議的譯法並不嚴謹。）

1、網絡基礎 TCP/IP

1.1 TCP/IP 協議族

TCP/IP 協議族是互聯網相關聯的協議的集合。從電纜的規格到IP地址的選定方法、尋找異地用戶的方法、雙方創建通訊的順序，以及Web頁面顯示須要處理的步驟，等等。而HTTP是屬於它內部的一個子集。

1.2 TCP/IP 的分層管理

TCP/IP 協議族按層次分別分爲如下 4 層：應用層、傳輸層、網絡層和數據鏈路層。 分層的好處：把各層之間的接口部分規劃好以後，每一個層次內部的設計就可以自由改動了。並且，層次化以後，設計也變得相對簡單。處於應用層上的應用能夠只考慮分派給本身的任務，而無需弄清對方在地球上哪一個地方、對方的傳輸路線、是否能確保傳輸送達等問題。

• 應用層：決定了向用戶提供應用服務時通訊的活動。 TCP/IP 協議族預存了各種通用的應用服務。如 FTP（File Transfer Protocol）、DNS（Domain Name System）和 HTTP。
• 傳輸層：該層對上層應用層，提供處於網絡鏈接中的兩臺計算機之間的數據傳輸。TCP（Transmission Control Protocol）和 UDP（User Data Protocol，用戶數據報協議）。
• 網絡層：網絡層用來處理在網絡上流動的數據包。數據包是網絡傳輸的最小數據單位。該層規定了經過怎麼樣的路徑到達對方計算機，並把數據包傳送給對方。
• 鏈路層：用來處理網絡的硬件部分。

1.3 TCP/IP 通訊傳輸流

利用 TCP/IP 協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則往應用層往上走。

用HTTP 舉例來講：首先做爲發送端的客戶端在應用層（HTTP協議）發出一個HTTP請求。 接着，在傳輸層（TCP協議）把從應用層處收到的數據（HTTP請求報文）進行分隔，並在各個報文上打上標記序號及端口號後轉發給網絡層。 在網絡層（IP協議），增長做爲通訊目的地的MAC地址後轉發給鏈路層。這就讓發往網絡的通訊請求準備齊全了。 接收端的服務器在鏈路層接收到數據後，按序往上層發送，一直到應用層。當傳輸到應用層，才能算真正接收到客戶端發送過來的HTTP請求。

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。 把數據信息包裝起來的作法稱爲封裝。

2、與HTTP關係密切的協議：IP、TCP和DNS

2.1 負責傳輸的 IP 協議

IP（網際協議）位於網絡層。該協議的做用是把各類數據包傳送給對方。而要保證確實傳送到對方那裏，則須要知足各種條件。其中最重要的兩個條件是 IP 地址和 MAC地址。 IP 地址指明瞭節點被分配到的地址，MAC地址是指網卡所屬的固定地址。IP地址能夠和MAC地址進行配對。

使用ARP協議憑藉MAC地址進行通訊 IP間通訊通訊依賴MAC地址。通訊的雙方一般會通過多臺計算機和網絡設備中轉才能鏈接到對方，而在進行中轉時，會利用下一站中轉設備的MAC地址來搜索下一個中轉目標。這時，會採用ARP協議。該協議是一種用以解析地址的協議，根據通訊方的IP地址就能夠反查出對應的MAC地址。

2.2 確保可靠性的TCP協議

TCP屬於傳輸層，提供可靠的字節流服務。 字節流服務是指：爲了方便傳輸，將大塊數據分割成以報文段爲單位的數據包進行管理。 這就是爲何下載高清大圖時，圖片會一塊一塊地加載。

三次握手 爲了準確無誤地將數據送達目標處，TCP協議在發送數據的準備階段採用了三次握手策略（若在握手過程當中某個階段中斷，TCP協議會再次以相同的順序發送相同的數據包）。

固然，除了三次握手，TCP還有其它各類手段確保通訊的可靠性。

2.3 負責域名解析的 DNS 服務

DNS服務提供域名到IP 地址之間的解析服務。 便可經過域名查找IP，或逆向從IP地址反查域名服務。

由於域名解析也須要時間，因此能夠 提早獲取DNS來提高網頁加載速度。

3、URI和URL

 

URI（uniform Resource Identifier） Uniform：規定統一的格式可方便處理多種不一樣類型的資源。 Resource：可標識的任何東西 Identifier：標識符

URL(Uniform Resource Locator)：統一資源定位符，正是使用 Web 瀏覽器訪問 Web 頁面時須要輸入的網頁地址。

URI就是某個協議方案表示的資源的定位標識符。協議方案是指訪問資源所使用的協議類型名稱，如http、ftp。

URI 用字符串標識某一個互聯網資源，而URL表示資源的地點。URL是URI的子集。

表示指定的URI，要使用涵蓋所有必要信息的絕對URI、絕對URL以及相對URL。相對URL是指從瀏覽器中基本URI處指定的URL，如 /image/logo.gif。

絕對URI的格式以下：

4、HTTP協議

HTTP協議規定，先從客戶端開始創建通訊，服務端在沒有接收到請求以前不會發送響應。

請求報文由請求方法、請求URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文基本上由協議版本、狀態碼、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。

4.1 HTTP是不保存狀態的協議

HTTP是無狀態協議。自身不對請求和響應之間通訊狀態進行保存（即不作持久化處理）。 HTTP之因此設計得如此簡單，是爲了更快地處理大量事物，確保協議的可伸縮性。 HTTP/1.1 隨時無狀態協議，但可經過 Cookie 技術保存狀態。

4.2 告知服務器意圖的HTTP方法

• GET：獲取資源

 

• POST：傳輸實體主體

• PUT：傳輸文件

• HEAD：得到報文首部，與GET方法同樣，只是不返回報文主體內容。用於確認URI的有效性及資源更新的日期時間等。

• DELETE：刪除文件，與PUT相反（響應返回204 No Content）。

• OPTIONS：詢問支持的方法，查詢針對請求URI指定的資源支持的方法（Allow:GET、POST、HEAD、OPTIONS）。

一種應用的場景 發送非簡單的cors請求時 瀏覽器會首先發送options方法來詢問服務器支持的方法。參見https://segmentfault.com/a/11...

• TRACE：追蹤路徑
• CONNECT：要求用隧道協議鏈接代理（主要使用SSL（Secure Sockets Layer，安全套接層）和TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸）。

向請求URI指定的資源發送請求報文時，採用稱爲方法的命令。方法名區分大小寫，主要要用大寫字母。

4.3 持久鏈接節省通訊量

HTTP1.1和HTTP1.0相比較而言，最大的區別就是增長了持久鏈接支持(貌似最新的 http1.0 能夠顯示的指定 keep-alive),但仍是無狀態的，或者說是不能夠信任的。在http1.0中使用Connection:keep-alive來標記此次請求是長鏈接的請求。
因此 若是web服務器端看到這裏的值爲「Keep-Alive」，或者看到請求使用的是HTTP 1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。
長鏈接vs短鏈接
所謂長鏈接指創建SOCKET鏈接後無論是否使用都保持鏈接，但安全性較差， 
所謂短鏈接指創建SOCKET鏈接後發送後接收完數據後立刻斷開鏈接，通常銀行都使用短鏈接

4.3.1 持久鏈接

HTTP協議的初始版本中，每進行一次HTTP通訊就要斷開一次TCP鏈接。

發送請求一份包含多張圖片的HTML文檔對應的Web頁面，會產生大量通訊開銷。

爲了解決上述TCP鏈接的問題，HTTP/1.1和一部分的HTTP/1.0想出了持久鏈接（HTTP Persistent Connections，也稱爲HTTP keep-alive 或 HTTP Connection resue）的方法。 持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持TCP鏈接狀態。

持久鏈接的好處在於減小了TCP鏈接的重複創建和斷開所形成的額外開銷，減輕了服務器端的負載。另外，減小開銷的那部分時間，使HTTP請求和響應可以更早地結束，這樣Web頁面的顯示速度也相應提升了。

在HTTP/1.1中，全部鏈接默認都是持久鏈接，但在HTTP/1.0內並未標準化。 毫無疑問，除了服務器端，客戶端也須要支持持久鏈接。

4.3.2 管線化

持久鏈接使得多數請求以管線化方式發送成爲可能。之前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求（並行發送多個請求）。

注意：儘管HTTP管線化能夠克服同域並行請求限制帶來的阻塞， 但HTTP/1.x 有嚴格的串行返回響應機制，服務器經過 TCP 鏈接返回響應時，就是必須 按照客戶端的請求順序進行響應 ，前一個響應沒有完成，下一個響應就不能返回。因此使用「 HTTP 管道」技術時，萬一第一個響應時間很長，那麼後面的響應處理完了也沒法發送，只能被緩存起來，佔用服務器內存，這就是傳說中的「隊首阻塞」。

• 每一個瀏覽器支持的請求併發數不一樣，但可在頁面中使用多個域名加大併發量（由於瀏覽器是基於domain的併發控制，而不是page），不過過多的散佈會致使DNS解析上付出額外的代價。

4.4 使用Cookie的狀態管理

Cookie技術經過在請求和響應報文中寫入cookie信息來控制客戶端的狀態。 Cookie會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入Cookie值後發送出去。

若是您在cookie中設置了HttpOnly屬性，那麼經過js腳本將沒法讀取到cookie信息，這樣能有效的防止XSS攻擊。

• Cookie-free Domains：用戶在請求靜態資源時，也會發送cookie信息。對於一個擁有多個靜態資源的網站，這無疑會產生沒必要要的流量。所以咱們能夠啓用與主站不一樣的域名（包括子域名）來放置靜態資源。

瀏覽器第一次向服務器發起請求

 

瀏覽器第二次向該服務器發送請求

下面是步驟1 2 3分別對應的報文
一、請求報文
GET /reader/HTTP/1.1
HOST:hackr.jp
二、響應報文
HTTP/1.1 200 OK
Date:Tur,12 jul 2012 07:12:20 GMT
Server Apache
<set-cookie:sid=12211212121 ;path=/ expires=wed,10-0ct-12 >
Content-Type:text/plain charset=UTF-8
三、請求報文 
GET /image /http/1.1
Host : hacker.jsp
Cokkie:sid=12211212121

4.4.1 http中爲cookie設置的首部

一、set-cookie：響應報文中 服務器向客戶端設置cookie
set-cookie有如下的屬性值：
[1]expires：date
指定cookie的過時時間，若是沒有爲cookie的expire賦值的話 cookie的有效期僅限於會話期間
[2]secure 沒有值
限制web網頁僅在https安全鏈接時 才能夠發送cookie
[3]httpOnly 沒有值
這個屬性會使js沒法更改cookie

4.5 Session 技術

• 概念： Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態，這個數據能夠保存在集羣、數據庫、文件中。
• 如何工做：session 由服務端存儲，在一次登錄操做後，服務器將登錄的帳戶信息等做爲一個session 寫入在特定等文件裏，在回包報文中使用set-cookies爲客戶端設置sessionId，最終，客戶端在發送下一次請求的時候，會帶上session信息，從而達到狀態保存的目的。因此，當客戶端禁用了cookie，sessoin也沒法工做。

4.6 其餘的認證技術-token

• token驗證的大體過程是：客戶端和服務器端約定了一種特定的加密方式，好比以cookie中的某個字段經過特定的位運算，加密編碼成一串字符串。最終在請求中做爲參數傳遞給服務器，服務器在收到請求時，再使用一樣的加密方式，獲取加密串，與傳過來的參數進行對比。從而達到身份認證的關係。因爲同源的關係，cookie沒法被盜取，而加密手段也是自定義的，從而保證了安全性。

5、HTTP報文內的HTTP信息

用於HTTP協議交互的信息被稱爲HTTP報文。請求端的HTTP報文叫作請求報文，響應端的叫作響應報文。HTTP報文自己是由多行（用CR+LF作換行符）數據構成的字符串文本。

HTTP報文大體可分爲報文首部和報文主體兩部塊。二者由最初出現的空行（CR+LF、回車符+換行符）來劃分。一般，並不必定要有報文主體。

5.1 編碼提高傳輸速率

HTTP在傳輸數據時能夠按照數據原貌直接傳輸，但也能夠在傳輸過程當中經過編碼提高傳輸速率，但這會消耗更多的CPU等資源。

5.1.1 報文主體和實體主體的差別

報文：是HTTP通訊中的基本單位，由8位組字節流組成，經過HTTP通訊傳輸。 實體：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。

HTTP報文的主體用於傳輸請求或響應的實體主體。 一般，報文主體等於實體主體。只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別。

5.1.2 壓縮傳輸的內容編碼

內容編碼指明應用在實體內容上的編碼格式，並保持實體信息原樣壓縮。內容編碼後的實體由客戶端接收並負責解碼。 常見的內容編碼有：gzip（GNU zip）、compress（UNIX系統的標準壓縮）、deflate（zlib）、identity（不進行編碼）

5.1.3 分隔發送的分塊傳輸編碼

在HTTP通訊過程當中，請求的編碼實體資源還沒有所有傳輸完成以前，瀏覽器沒法顯示請求頁面。在傳輸大容量數據時，經過把數據分割成多塊，可以讓瀏覽器逐步顯示頁面。 這種把實體主體分塊的功能稱爲分塊傳輸編碼（Chunked Transfer Coding）。

分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0（CR+LF）」來標記。

使用分塊傳輸編碼的實體主體會由接收的客戶端負責解碼，恢復到編碼前的實體主體。

5.2 發送多種數據的多部分對象集合

HTTP協議中採納了多部分對象集合，發送的一份報文主體內可含有多類型實體。一般是在圖片或文本文件等上傳時使用。

5.3 獲取部份內容的範圍請求

下載大尺寸的圖片的過程當中，若是網絡中斷，則須要從新下載。所以須要一種可恢復的機制。 實現該功能須要指定下載的實體範圍，像這樣，指定範圍發送的請求叫作範圍請求。 執行範圍請求時，會用到首部字段Range來指定資源的byte範圍。響應會返回狀態碼206 Partial Content。

若是服務器端沒法響應範圍請求，則會返回狀態碼200 OK和完整的實體內容。

5.4 內容協商返回最合適的內容

內容協商機制是指客戶端和服務器端就響應的資源內容進行交涉，而後提供給客戶端最爲適合的資源。內容協商會以響應資源的語言、字符集、編碼方式等做爲判斷的基準。

5.5 返回結果的HTTP狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。 狀態碼如200 OK，以3爲數字和緣由短語組成。 數字中的第一位定義了響應類別，後兩位無分類。響應類別有如下五種：

	類別	緣由短語
1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	須要進行附加操做以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器沒法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

只要遵照狀態碼類別的定義，即便改變 RFC2616 中定義的狀態碼，或服務器端自行建立狀態碼都沒問題。

5.5.1 經常使用的狀態碼14種：

2XX 成功

• 200 OK：請求被正常處理
• 204 No Content：通常在只需從客戶端往服務器發送信息，而對客戶端不須要發送新信息內容的狀況下使用。
• 206 Partial Content：客戶端進行範圍請求

3XX 重定向

• 301 Moved Permanently：永久重定向。表示請求的資源已被分配了新的URI，之後應使用資源如今所指的URI。 也就是說，若是已經把資源對應的URI保存爲書籤了，這時應該按Location首部字段提示的URI從新保存。
• 302 Found：臨時性重定向。表示請求的資源已被分配了新的URI，但願用戶（本次）能使用新的URI訪問。 和301 Moved Permanently狀態碼類似，但302狀態碼錶明的資源不是被永久移動，只是臨時性質的。換句話說，已移動的資源對應的URI未來還有可能發生改變。好比，用戶把URI保存成書籤，但不會像301狀態碼出現時那樣去更新書籤，而是仍舊保留返回302狀態碼的頁面對應的URI（在Chrome中，仍是會保存爲重定向後的URI，不解）。
• 303 See Other：表示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。這與302相似，但303明確表示客戶端應當採用GET方法獲取資源。
• 304 Not Modified：該狀態碼錶示客戶端發送附帶條件的請求（指採用GET方法的請求報文中包含If-Match,If-Modified-Since，If-None-March，If-Range，If-Unmodified-Since中任一首部。）時，服務器端容許請求訪問資源，但因發生請求爲知足條件的狀況後，直接返回304（服務器端資源未改變，可直接使用客戶端未過時的緩存）。304狀態碼返回時，不包含任何響應的主體部分。
  304雖被劃分在3XX類別，可是和重定向沒有關係。
• 307 Temporary Redirect：臨時重定向。與302有相同含義。307遵照瀏覽器標準，不會從POST變成

就算是304，也須要發出請求與接收響應，也會耗費資源和時間。

4XX 客戶端錯誤

4XX的響應結果代表客戶端是發生錯誤的緣由所在。

• 400 Bad Request：表示請求報文中存在語法錯誤。
• 401 Unauthorized：表示發送的請求須要有經過HTTP認證（BASIC認證、DIGEST認證）的認證信息。
• 403 Forbidden：代表對請求資源的訪問被服務器拒絕了。服務器端可在實體的主體部分對緣由進行描述（可選）
• 404 Not Found：代表服務器上沒法找到請求的資源。除此以外，也能夠在服務器端拒絕請求且不想說明理由時時用。

5XX 服務器錯誤

5XX的響應結果代表服務器自己發生錯誤。

• 500 Interval Server Error：代表服務器端在執行請求時發生了錯誤。也有多是Web應用存在的bug或某些臨時的故障。
• 503 Service Unavailable：代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。若是事先得知解除以上情況須要的時間，最好寫入Retry-After首部字段再返回給客戶端。

6、與HTTP協做的Web服務器

6.1 用單臺虛擬主機實現多個域名

HTTP/1.1 規範容許一臺HTTP服務器搭建多個Web站點。這是利用虛擬主機（Virtual Host，又稱虛擬服務器）的功能。

在互聯網上，域名經過DNS服務映射到IP地址以後訪問目標網站。可見，當請求發送到服務器時，已是以IP地址形式訪問了。因此，當一臺託管了兩個域名的服務器接收到請求時就須要弄清楚究竟要訪問哪一個域名。 在相同的IP地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的Web網站，所以在發送HTTP請求時，必須在Host首部內完整指定主機名或域名的URI。

6.2 通訊數據轉發程序：代理、網關、隧道

HTTP通訊時，除客戶端和服務器之外，還有一些用於通訊數據轉發的應用程序，例如代理、網關、隧道。它們能夠配合服務器工做。

• 代理：是一種有轉發功能的應用程序，扮演了位於服務器和客戶端「中間人」的角色，接收由客戶端發送的請求並轉發給服務器，同時也接收服務器返回的響應並轉發給客戶端。
• 網關：是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。
• 隧道：是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。

6.2.1 代理

代理不改變請求URI，會直接發送給前方持有資源的目標服務器。 持有資源實體的服務器被稱爲源服務器。

例如：

每次經過代理服務器轉發請求或響應式，會追加寫入via首部信息。

使用代理服務器的理由有：利用緩存技術減小網絡帶寬的流量，組織內部針對特定網站的訪問控制，以獲取訪問日誌爲主要目的，等等。

代理有多種使用方法，按兩種基準分類。一種是是不是否使用緩存，另外一種是是否會修改報文。

• 代理緩存：代理轉發響應時，緩存代理（Caching Proxy）會預先將資源的副本（緩存）保存在代理服務器上。當代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源，而是將以前緩存的資源做爲響應返回。
• 透明代理：轉發請求或響應時，不對報文作任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。

6.2.2 網關

網關的工做機制和代理十分類似。而網關能使通訊線路上的服務器提供非HTTP協議服務。 利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。好比，網關能夠鏈接數據庫，使用SQL語句查詢數據。另外，在Web購物網站上進行信用卡結算時，網關能夠和信用卡結算系統聯動。

 

6.2.3 隧道

隧道可按要求創建起一條與其餘服務器的通訊線路，屆時使用SSL等加密手段進行通訊。隧道的目的是確保客戶端與服務器進行安全的通訊。

隧道自己不會去解析HTTP請求。請求保持原樣中轉給以後的服務器。隧道會在通訊雙方斷開鏈接時結束。

 

6.3 保存資源的緩存

緩存是指代理服務器或客戶端本地磁盤內保存的資源副本。利用緩存可減小對源服務器的訪問，節省通訊流量和時間。

緩存服務器是代理服務器的一種。當代理轉發從服務器返回的響應時，代理服務器將會保存一份資源的副本。

緩存服務器的優點在於利用緩存可避免屢次從源服務器轉發資源。所以客戶端可就近從緩存服務器上獲取資源，而源服務器也沒必要屢次處理相同的請求了。

6.3.1 緩存的有效期限

對於緩存服務器和客戶端瀏覽器，當斷定緩存過時或客戶端要求，會向源服務器確認資源的有效性。若失效，瀏覽器會再次請求新資源。

即使緩存服務器內有緩存，也不能保證每次都會返回對同資源的請求。由於這關係到被緩存資源的有效性問題。

即便存在緩存，也會由於客戶端的要求、緩存的有效期等因素，向源服務器確認資源的有效性。若判斷緩存失效，緩存服務器會再次從源服務器上獲取"新"資源。

 

6.3.2 客戶端的緩存

緩存不只能夠存在於緩存服務器內，也能夠存在客戶端瀏覽器中。

瀏覽器緩存若是有效，就沒必要再向服務器請求相同的資源了，能夠直接從本地磁盤內讀取。

另外，和緩存服務器相同的一點是，當斷定緩存過時後，會向源服務器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。

7、HTTP首部

HTTP協議的請求和響應報文中一定包含HTTP首部。首部內容爲客戶端和服務器端分別處理請求和響應提供所須要的信息。

HTTP請求報文：由方法、URI、HTTP版本、HTTP首部字段等構成。 HTTP響應報文：由HTTP版本、狀態碼（數字和緣由短語）、HTTP首部字段 3 部分組成。

7.1 HTTP首部字段

使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

7.1.1 4種HTTP首部字段類型

HTTP首部字段根據實際通途被分爲如下4種類型：

• 通用首部字段（General Header Fileds）：請求報文和響應報文兩方都會使用的首部
• 請求首都字段（Request Header Fields）：從客服端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
• 響應首部字段（Response Header Fields）：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
• 實體首部字段（Entity Header Fields）：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

7.1.2 HTTP/1.1首部字段一覽

7.1.2.1 通用首部字段

首部字段名	說明
Cache-Control	控制緩存行爲
Connection	逐跳首部、鏈接的管理
Date	建立報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其餘協議
Via	代理服務器的相關信息
Warning	錯誤通知

Cache-Control的no-cache指令表明不緩存過時的資源，而不是不緩存。no-store纔是真正不進行緩存。 Connection首部字段的值爲close時，表明服務器想明確斷開鏈接（HTTP/1.1默認都是持久鏈接）

7.1.2.2 請求首部字段

首部字段名	說明
Accept	用戶代理可處理的媒體類型
Accept-Charset	優先的字符集
Accept-Encoding	優先的內容編碼
Accept-Language	優先的語言
Authorization	Web認證信息
Expect	期待服務器的行爲
From	用戶的電子郵箱地址
Host	請求資源所在服務器
If-Match	比較實體標記（ETag）
If-Modified-Since	比較資源的更新時間
If-Node-Match	比較實體標記（與If-Match相反）
If-Range	資源未更新時發送實體Byte的範圍請求
If-Unmodified-Since	比較資源的更新時間（與If-Modified-Since相反）
Max-Forwards	最大傳輸逐跳數
Proxy-Authorization	代理服務器要求客戶端的認證信息
Range	實體的字節範圍請求
Referer	對請求中URI的原始獲取方
TE	傳輸編碼的優先級
User-Agent	HTTP客戶端程序的信息

該表的Accept*字段均可以指定權重q（0-1）。當服務器提供多種內容時，將會首先返回權重最高的。 If-xxx請求首部字段都稱爲條件請求，服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔回執行請求。 Referer 的正確拼寫應該是Referrer。當直接在瀏覽器的地址欄輸入URI時，或處於安全考慮時，可不發該首部字段。

7.1.2.3 響應首部字段

首部字段名	說明
Accept-Ranges	是否接受字節範圍請求
Age	推算資源建立通過時間
ETag	資源的匹配信息
Location	令客戶端重定向至指定URI
Proxy-Authenticate	代理服務器對客戶端的認證信息
Retry-After	對再次發起請求的時機要求
Server	HTTP服務器的安裝信息
Vary	代理服務器緩存的管理信息
WWW-Authenticate	服務器對客戶端的認證信息

幾乎全部瀏覽器在接收到包含首部字段Location的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。

7.1.2.4 實體首部字段

首部字段名	說明
Allow	資源可支持的HTTP方法
Content-Encoding	實體主體適用的編碼方式
Content-Language	實體主體的天然語言
Content-Length	實體主體的大小（字節）
Content-Location	替代對應資源的URI
Content-MD5	實體主體的報文摘要
Content-Range	實體主體的位置範圍
Content-Type	實體主體的媒體類型
Expires	實體主體過時的日期時間
Last-Modified	資源的最後修改日期時間

 

7.1.2.5 爲Cookie服務的首部字段

首部字段名	說明	首部類型
Set-Cookie	開始狀態管理所使用的Cookie信息	響應首部字段
Cookie	服務器接收到的Cookie信息	請求首部字段

 

7.1.2.6 Set-Cookie字段的屬性

屬性	說明
NAME=VALUE	賦予Cookie的名稱和其值（必需項）
expires=DATE	Cookie的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
path=Path	將服務器上的文件目錄做爲Cookie的適用對象（若不指定則默認爲文檔所在的文件目錄）
domain=域名	做爲Cookie適用對象的域名（若不指定則默認爲建立Cookie的服務器的域名）
Secure	僅在HTTPS安全通訊時纔會發送Cookie
HttpOnly	加以限制，使Cookie不能被JavaSript腳本訪問

expires：一旦Cookie從服務器端發送至客戶端，服務器端就不存在能夠顯示刪除Cookie的方法。但可經過覆蓋已過時的Cookie，實現對客戶端Cookie的實質性刪除操做。 path：用來指定cookie被髮送到服務器的哪個目錄路徑下（即被服務器哪一個路徑接收cookie），其中"/"指的是站點根目錄，可在同一臺服務器（即便有多個應用）內共享該cookie。

8、確保Web安全的HTTPS

8.1. 什麼是HTTPS？

HTTPS是 HTTP+ SSL +TLS 的產物，用於對通訊的加密、認證、完整性保護。它並非一種新的協議，而是HTTP的某些部分由SSL和TLS代理。

8.2 HTTPS如何保證通訊安全（原理）？

8.2.1 原理

咱們先來了解一下經常使用的兩種加密方式：

• 對稱加密： 加密和解密都是用同一把密鑰。
• 非對稱加密： 加密和解密是兩把不一樣的密鑰。

HTTPS 使用混合加密機制，即先經過非對稱加密交換通訊密鑰，拿到密鑰後再使用對稱加密的方式進行後續的通訊。可是如何保證第一步中，客戶端獲取到的公共密鑰是正確的呢？這時候，就須要用到咱們的數字證書了。

證書是由第三方機構提供認證的，服務器先去第三方機構申請公共密鑰，而後會得到公共密鑰和使用第三方數字簽名，在非對稱加密的過程當中，將數字證簽名和包含的公共密鑰一塊兒發給客戶端，客戶端經過第三方機構的公共密鑰對證書上的簽名進行驗證，一旦經過，則說明公共密鑰是正確的。

 

8.2.2 請求過程

下面看看具體的安全通訊創建過程：

 

1. 客戶端發起client hello 報文， 攜帶客戶端支持的ssl版本、加密相關的約定（密鑰長度和加密算法）。
2. 服務器響應 server hello 報文， 表示能夠進行ssl通訊，並攜帶相關加密約定。
3. 服務器發送 certificate 報文, 攜帶了公共密鑰的證書。
4. 服務器發送 server hello done，表示最初的ssl協商部分結束。
5. 客戶端發起 Client Key Exchange 報文，並攜帶使用第一階段協商以後獲得的Pre-master

secret加密隨機串（對稱密鑰）。

1. 客戶端發起 Change Cipher Spec 報文，表示以後的請求將使用Pre-master secret進行加密通訊
2. 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。
3. 服務器發送 Change Cipher Spec 報文，表示解密成功，下面將使用協商的密鑰進行安全通訊。
4. 服務器發送 Finished 報文，至此，一個安全的通訊已經簡歷。
5. 應用層協議通訊，即發送 HTTP 響應。
6. 最後由客戶端發送 close_notify 報文斷開鏈接。

8.3 HTTPS存在的缺陷

• SSL加密緻使的速度的下降和服務器負載的增大。
• 申請證書須要的開銷
• 通訊使用明文可能會被竊聽
• 不驗證通訊方的身份就可能遭受假裝
• 沒法驗證報文完整性，可能已遭篡改

HTTP+加密+認證+完整性保護 = HTTPS

8.4 確認訪問用戶身份的認證

覈對的信息一般是指如下這些：

• 密碼：只有本人才會知道的字符串信息
• 動態令牌：僅限本人持有的設備內顯示的一次性密碼
• 數字證書：僅限本人（終端）持有的信息
• 生物認證：指紋和虹膜等本人的生理信息
• IC卡等：僅限本人持有的信息

HTTP/1.1 使用的認證方式以下所示：

• BASIC認證（基本認證）
• DIGEST 認證（摘要認證）w
• SSL 客戶端認證
• FormBase認證（基於表單認證）

9、基於HTTP的功能追加協議

9.1 HTTP的瓶頸

使用HTTP協議探知服務器上是否有內容更新，就必須頻繁地從客戶端到服務器端進行確認。若是服務器上沒有內容更新，那麼就會產生徒勞的通訊。 若想在現有Web實現所需的功能，一下這些HTTP標準就會成爲瓶頸：

• 一條鏈接上只可發送一個請求（前面講到，持久化可保持TCP鏈接狀態，但仍完成一次請求/響應後才能進行下一次請求/響應，而管線化方式可以讓一個TCP鏈接並行發送多個請求。）
• 請求只能從客戶端開始。客戶端不能夠接收除響應之外的指令
• 請求/響應首部未經壓縮就發送。首部信息越多延遲越大
• 發送冗長的首部。每次互相發送相同的首部形成的浪費較多
• 可任意選擇數據壓縮格式。非強制壓縮發送

9.2 Comet 的解決方法

一般，服務器接收到請求，在處理完畢後就當即返回響應，但爲了實現推送功能，Comet會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。 內容上雖然能夠作到實時更新，但爲了保留響應，一次鏈接的持續時間也變長了。期間，爲了維持鏈接會消耗更多的資源。另外，Comet仍未解決HTTP協議的自己存在的問題。

9.3 SPDY

Google 在2010年發佈了 SPDY，其開發目標旨在解決HTTP的性能瓶頸，縮短Web頁面的加載時間。 SPDY沒有徹底改寫HTTP協議，而是在TCP/IP的應用層與運輸層之間經過新加會話層的形式運做。同時，考慮到安全性問題，SPDY規定通訊中使用SSL。

SPDY以會話層的形式加入，控制對數據的流動，但仍是採用HTTP創建通訊鏈接。所以，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP報文等。

使用 SPDY後，HTTP協議額外得到如下功能。

• 多路複用流：經過單一的TCP鏈接，能夠無限制處理多個HTTP請求。全部請求的處理都在一條TCP鏈接上完成，所以TCP的處理效率獲得提升。
• 賦予請求優先級：SPDY不只能夠無限制地併發處理請求，還能夠給請求逐個分配優先級順序。這樣主要是爲了在發送多個請求時，解決因帶寬低而致使響應變慢的問題。
• 壓縮HTTP首部：壓縮HTTP請求和響應的首部。
• 推送功能：支持服務器主動向客戶端推送數據的功能。
• 服務器提示功能：服務器能夠主動提示客戶端請求所需的資源。因爲在客戶端發現資源以前就能夠獲知資源的存在，所以在資源已緩存等狀況下，能夠避免發送沒必要要的請求。

9.4 使用瀏覽器進行全雙工通訊的 WebSocket

利用Ajax和Comet技術進行通訊能夠提高Web的瀏覽速度。但問題在於通訊若使用HTTP協議，就沒法完全解決瓶頸問題。

WebSocket技術主要是爲了解決Ajax和Comet裏XMLHttpRequst附帶的缺陷所引發的問題。

一旦Web服務器與客戶端之間創建起WebSocket協議的通訊鏈接，以後全部的通訊都依靠這個專用協議進行。通訊過程當中可互相發送JSON、XML、HTML或圖片等任意格式的數據。

WebSocket的主要特色：

• 推送功能：支持由服務器向客戶端推送數據。
• 減小通訊量：和HTTP相比，不但每次鏈接時的總開銷減小，並且因爲WebSocket的首部信息很小，通訊量也相應較少。

爲了實現WebSocket通訊，在HTTP鏈接創建以後，須要完成一次「握手」的步驟。

• 握手·請求：爲了實現WebSocket通訊，須要用到HTTP的Upgrade首部字段，告知服務器通訊協議發生改變，以達到握手的目的。
• 握手·響應：對於以前的請求，返回狀態碼101 Switching Protocols 的響應。

成功握手確立WebSocket鏈接後，通訊時再也不使用HTTP的數據幀，而採用WebSocket獨立的數據幀。

因爲是創建在HTTP基礎上的協議，所以鏈接的發起方還是客戶端，而一旦確立WebSocket通訊鏈接，不論服務器端仍是客戶端，任意一方均可直接向對方發送報文。

10、HTTP/2.0

10.1 歷史痛點

10.1.1 HTTP1.0 時代最大的兩個問題就是：

• 鏈接沒法複用 : 每次請求都須要從新創建tcp通道，經歷三次握手的過程。
• 隊頭阻塞：請求通道如一個獨木橋，多個請求一塊兒發出，只能先等第一個請求得到回包以後才能開始第二個請求，不然就只能排隊等候。

10.1.2 那些年的解決之道：

10.1.2.1 解決鏈接沒法複用：

基於tcp的長連接:

通常APP會基於TCP造一個長鏈接的通訊協議，門檻較高，可是一旦完成，帶來的回報也是很是大的。信息的推送和更新變得及時，且在一些請求爆發點，相較於傳統HTTP重複創建請求的耗時，也能減輕服務器的壓力。如今業界的成熟方案如：google的protobuf。

http long-polling:

long-polling請求就是在客戶端初始化的時候發起一個polling請求到服務器，而後請求一直等待中，當服務器有資源更新的時候，再返回數據，數據放回時，再次發起一個polling請求繼續監聽。固然，polling請求也有一些缺陷，好比 長時間的鏈接會增長服務器壓力，複雜的業務場景下須要考慮如何才能創建健康的請求通道等。此外，這種方式有個致命的缺陷是：數據通訊是單向的，主動權在服務端這邊，客戶端只能根據服務端被動的接受數據，有新的業務請求的時候沒法及時傳送。

http streaming:

與http-polling 不一樣的是， http-streaming 在初始化的的時候就發起一個不會斷開的請求，持續監聽服務器的回包，服務器有數據更新時就經過這個請求通道返回數據。此種方式跟http-polling同樣是單向的，streaming是經過在server response的頭部裏增長」Transfer Encoding: chunked」來告訴客戶端後續還會有新的數據到來。固然，streaming 也有缺陷: 業務數據沒法按照請求來作分割，因此客戶端沒收到一塊數據都須要本身作協議解析，也就是說要作本身的協議定製。

websocket:

WebSocket和傳統的tcp socket鏈接類似，也是基於tcp協議，提供雙向的數據通道。WebSocket優點在於提供了message的概念，比基於字節流的tcp socket使用更簡單，同時又提供了傳統的http所缺乏的長鏈接功能。websocket 通常在數據須要實時更新的場景中使用。

10.1.2.2 解決隊頭阻塞:

http pipelining（管線化）

管線化的前提是長鏈接的創建，keep-alive的多個請求使用同一個tcp鏈接使請求並行成爲可能，pipelining與傳統的請求能夠形象的比喻爲 串行和並行 ， 多個請求同時發起，無需等待上一個請求的回包。可是它並非救世主，也存在着缺陷：

• pipelining只適用與HTTP1.1，而且須要服務器端支持
• 隊頭阻塞的問題並無根本的解決，由於服務端要響應要遵循先進先出的原則，第一個請求的回包發出以後，纔會響應第二個請求。

10.2 新的改變(HTTP2)

HTTP1.0和1.1的普及程度使得HTTP2必須得在不改變原有方式的狀況下解決上述問題，即HTTP2 並不能像angular2那樣放飛自我。因此，HTTP2的使用方式和原來的差很少，HTTP2的改變至關之多，這裏主要講一下對咱們影響較大的幾點：

10.2.1 二進制

http2.0的協議解析決定採用二進制格式，實現方便且健壯。每個請求都有這些公共字段：Type, Length, Flags, Steam Identifier和frame payload。http2.0的格式定義更接近tcp層的方式，length定義了整個frame的開始到結束，type定義frame的類型（一共10種），flags用bit位定義一些重要的參數，stream id用做流控制，剩下的payload就是request的正文了。

 

10.2.2 多路複用

多路複用是HTTP2.0主要解決的一個問題，一個request對應一個stream並分配一個id，這樣一個鏈接上能夠有多個stream，每一個stream的frame能夠隨機的混雜在一塊兒，接收方能夠根據stream id將frame再歸屬到各自不一樣的request裏面。

10.2.3 頭部壓縮

無狀態的HTTP致使每次請求都須要攜帶服務器所須要的參數，而一些頭部信息基本上是固定的，這部分重複的信息恰好能夠用於壓縮，減小報文體積。

10.2.4 鏈接重置

HTTP 1.1的有一個缺點是：當一個含有確切值的Content-Length的HTTP消息被送出以後，你就很難中斷它了。固然，一般你能夠斷開整個TCP連接（但也不老是能夠這樣），但這樣致使的代價就是須要從新經過三次握手創建一個新的TCP鏈接。一個更好的方案是隻終止當前傳輸的消息並從新發送一個新的。在http2裏面，咱們能夠經過發送RST_STREAM幀來實現這種需求，從而避免浪費帶寬和中斷已有的鏈接。

10.2.5 依賴與優先級

每一個流都包含一個優先級，優先級被用來告訴對端哪一個流更重要。從而實現資源的有效分配。

10.2.6 服務器推送

當一個客戶端請求資源X，而服務器知道它極可能也須要資源Z的狀況下，服務器能夠在客戶端發送請求前，主動將資源Z推送給客戶端。這個功能幫助客戶端將Z放進緩存以備未來之需。

10.2.7 流量控制

http2上面每一個流都擁有本身的公示的流量窗口，它能夠限制另外一端發送數據。

11、Web攻擊技術

簡單的HTTP協議自己並不存在安全性問題，所以協議自己幾乎不會成爲攻擊的對象。應用HTTP協議的服務器和客戶端，以及運行在服務器上的Web應用等資源纔是攻擊目標。

HTTP不具有必要的安全功能，就拿遠程登陸時會用到的SSH協議來講，SSH具有協議級別的認證及會話管理等功能，HTTP協議則沒有。另外在架設SSH服務方面，任何人均可以輕易地建立安全等級高的服務。而HTTP即便已假設好服務器，但開發者須要自行設計並開發認證及會話管理功能來知足Web應用的安全。而自行設計就意味着會出現各類形形色色的實現，可仍在運做的Web應用背後就會隱藏着各類容易被攻擊者濫用的安全漏洞的Bug。

11.1 因輸出值轉義不徹底引起的安全漏洞

• 跨站腳本攻擊（Cross-Site Scripting, XSS）：主要是指在用戶瀏覽器內運行了非法的 HTML 標籤或 JavaScript 腳本。好比富文本編輯器，若是不過濾用戶輸入的數據直接顯示用戶輸入的HTML內容的話，就會有可能運行惡意的 JavaScript 腳本，致使頁面結構錯亂，Cookies 信息被竊取等問題。
• SQL注入攻擊（SQL Injection）：是指針對 Web 應用使用的數據庫，經過運行非法的SQL而產生的攻擊。
• OS命令攻擊（OS Command Injection）：是指經過 Web 應用，執行非法的操做系統命令達到攻擊的目的。 只要在能調用 Shell 函數的地方就有存在被攻擊的風險。
• HTTP首部注入攻擊（HTTP Header Injection）：是指攻擊者經過在響應首部字段內插入換行，添加任意響應首部或主體的一種攻擊。
• HTTP 響應截斷攻擊：是用在 HTTP 首部注入的一種攻擊。攻擊順序相同，可是要將兩個 %0D%0A%0D%0A 並排插入字符串後 發送。利用兩個連續的換行就可做出 HTTP 首部與主體分隔所需的空行了，這樣 就能顯示僞造的主體，達到攻擊的目的。
• 郵件首部注入攻擊（Mail Header Injection）：是指 Web 應用中的郵件發送功能，攻擊者經過向郵件首部 To 或 Subject 內任意添加非法內容發起的攻擊。利用存在安全漏洞的Web網站，可對任意郵件地址發送廣告郵件或 病毒郵件。
• 目錄遍歷攻擊（Directory Traversal）：是指對本無心公開的文件目錄，經過非法截斷其目錄路徑後，達成訪問目的的一種攻擊。好比，經過 ../ 等相對路徑定位到 /etc/passwd 等絕對路徑上。
• 遠程文件包含漏洞（Remote File Inclusion）： 是指當部分腳本內容須要從其餘文件讀入時，攻擊者利用指定外部服務器的URL充當依賴文件，讓腳本讀取以後，就可運行任意腳本的一種攻擊。

11.2 因設置或設計上的缺陷引起的安全漏洞

• 強制瀏覽（Forced Browsing）：是指，從安置在Web服務器的公開目錄下的文件中，瀏覽那些本來非自願公開的文件。好比，沒有對那些須要保護的靜態資源增長權限控制。
• 不正確的錯誤消息處理（Error Handling Vulerability）：指Web應用的錯誤信息內包含對攻擊者有用 的信息。
• 開放重定向（Open Redirect）：是一種對指定的任意URL做重定向跳轉的功能。而於此功能相關聯的安全漏洞是指， 假如指定的重定向 URL 到某個具備惡意的 Web 網站，那麼用戶就會被誘導至那個 Web 網站。

11.3 因會話管理疏忽引起的安全漏洞

• 會話劫持（Session Hijiack）：是指攻擊者經過某種手段拿到了用戶的會話 ID，並不是法使用此會話 ID 假裝成用戶，達到攻擊的目的。
• 會話固定攻擊（Session Fixation）：對以竊取目標會話ID爲主動攻擊手段的會話劫持而言，會強制用戶使用攻擊者指定的會話 ID，屬於被動攻擊。
• 跨站點請求僞造（Cross-Site Request Forgeries, CSRF）：是指攻擊者經過設置好陷阱，強制對已完成認證的用戶進行非預期的我的信息或設定等某些狀態更新，屬於被動攻擊。

11.4 其它安全漏洞

• 密碼破解：①經過網絡進行密碼試錯（窮舉法和字典攻擊）；②對已加密密碼的破解（經過窮舉法·字典攻擊進行類推、彩虹表、拿到加密時使用的密鑰、加密算法的漏洞）
• 點擊劫持：是指利用透明的按鈕或連接作成陷阱，覆蓋在Web頁面之上。而後誘使用戶在不知情的狀況下， 單擊那個連接訪問內容的一種攻擊手段。這種行爲又稱爲界面假裝（UI Redressing）。
• Dos攻擊：是一種讓運行中的服務呈中止狀態的攻擊。有時也叫作服務中止攻擊或拒絕服務攻擊。多臺計算機發起的 Dos 攻擊稱爲 DDoS 攻擊（Distributed Denial of Service attach） 。
• 後門程序：是指開發設置的隱藏入口（如開發階段做爲Debug調用的後門程序），可不按正常步驟使用受限功能。利用後門程序就可以使用本來受限的功能。

12、常見面試題

1. ]URI與URL的區別
   答：URI 用字符串（包括地址）標識某一個互聯網資源，而URL表示資源的地點。所以URL是URI的子集。
2. 輸入URL後，瀏覽器發生哪些變化
   下圖須要補充：在從DNS服務器獲取IP後，進行3次握手。 
   從服務器獲取相應資源後，瀏覽器就會對這些資源進行相應的解析，具體可看Google Developers。
3. GET與POST的區別
   能夠看看這篇文章 淺談HTTP中Get與Post的區別。我我的認爲主要的一點是：URL不存在參數上限的問題，HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。 關於URL和queryString長度限制的相關連接：

• What is the maximum length of a URL in different browsers?
• What is the maximum possible length of a query string?
  所以對於GET請求時，URL超出瀏覽器或者服務器限制的狀況，建議改爲POST請求。

4. 301與302區別
   答：301是永久性重定向，搜索引擎在抓取新內容的同時也將舊的網址替換爲重定向以後的網址。 302是臨時性重定向，搜索引擎會抓取新的內容而保留舊的網址。由於服務器返回302代碼，搜索引擎認爲新的網址只是暫時的。
5. 爲何三次握手，二次不能夠嗎？
   答：不能夠，只有完成3次才能進行後續操做，若在握手過程當中某個階段中斷，TCP協議會再次以相同的順序發送相同的數據包。並且，第三次握手是客戶端爲了讓服務器知道它是否接收到響應，確保鏈接創建成功。
6. 爲何有時候下載高清大圖時，圖片會一塊一塊地加載。
   答：這就是由於設置了http請求的長度，這樣就能夠分塊的加載資源文件。 　　在請求報文中使用Range屬性，在響應報文中使用Content-Type屬性均可以指定必定字節範圍的http請求。

7. 說一下什麼是Http協議

   對器客戶端和 服務器端之間數據傳輸的格式規範，格式簡稱爲「超文本傳輸協議」。

8. 什麼是Http協議無狀態協議?怎麼解決Http協議無狀態協議?

       (1)、無狀態協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息

       （2)、無狀態協議解決辦法： 經過一、Cookie 二、經過Session會話保存。

   9.說一下Http協議中302狀態

        http協議中，返回狀態碼302表示重定向。這種狀況下，服務器返回的頭部信息中會包含一個 Location 字段，內容是要重定向到的Url

   10.Http協議由什麼組成?

      請求報文包括三部分:

       (1).請求行:包含請求方法,URI,HTTP版本協議

       (2).請求首部字段

       (3).請求內容實體

     響應報文包含三部分:

       (1).狀態行:包含HTTP版本,狀態碼,狀態碼緣由短語

       (2).響應首部字段

       (3).響應內容實體

    11.Http協議中有哪些請求方式?

  　　　　GET:用於請求訪問已經被URI(統一資源標識符)識別的資源,能夠經過URL傳參給服務器

　　　　　 POST:用於傳輸信息給服務器,主要功能與GET方法相似,但通常推薦使用POST方式

　　　　 　PUT:傳輸文件,報文主體中包含文件內容,保存到對應URI位置

　　　   HEAD:得到報文首部,與GET方法相似,只是不返回報文主體,通常用於驗證URI是否有效

       DELETE:刪除文件,與PUT方法相反,刪除對應URI位置的文件

       OPTIONS:查詢響應URI支持的HTTP方法

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

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

    13.get與post請求的區別?

       區別一:get重點在從服務器上獲取資源,post重點在想服務器發送數據;

       區別二:get傳輸數據是經過URL請求,以filed(字段)=value的形式,置於URL後,並用"?"鏈接,多個請求數據之間用

            "&"鏈接,如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的

       區別三:get傳輸量小,由於受URL長度限制,但效率較低，post能夠傳輸大量數據,因此上傳文件時只能用post方式

       區別四:get是不安全的,由於URL是可見的,可能會泄露私密信息,如密碼等，post較get安全

   14.常見的Http協議狀態

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

  15.Http協議首部字段

• a、通用首部字段（請求報文與響應報文都會使用的首部字段）
• Date：建立報文時間
• Connection：鏈接的管理
• Cache-Control：緩存的控制
• Transfer-Encoding：報文主體的傳輸編碼方式
• b、請求首部字段（請求報文會使用的首部字段）
• Host：請求資源所在服務器
• Accept：可處理的媒體類型
• Accept-Charset：可接收的字符集
• Accept-Encoding：可接受的內容編碼
• Accept-Language：可接受的天然語言
• c、響應首部字段（響應報文會使用的首部字段）
• Accept-Ranges：可接受的字節範圍
• Location：令客戶端從新定向到的URI
• Server：HTTP服務器的安裝信息
• d、實體首部字段（請求報文與響應報文的的實體部分使用的首部字段）
• Allow：資源可支持的HTTP方法
• Content-Type：實體主類的類型
• Content-Encoding：實體主體適用的編碼方式
• Content-Language：實體主體的天然語言
• Content-Length：實體主體的的字節數
• Content-Range：實體主體的位置範圍，通常用於發出部分請求時使用

  16.Http與Https優缺點?

     (1).通訊使用明文不加密,內容可能被竊聽,也就是被抓包分析

     (2).不驗證通訊方身份,可能遭到假裝

     (3).沒法驗證報文完整性,可能被篡改

     Https就是Http加上加密處理(通常是SSL安全通訊線路)+認證+完整性保護

  16.Http優化

     利用負載均衡優化和加速HTTP應用

     利用HTTP Cache來優化網站

  17.Http協議有哪些特徵?

     一、支持客戶/服務器模式；二、簡單快速；三、靈活；四、無鏈接；五、無狀態；

 18.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中的鍵值對會被清空

 19.簡述http請求的7個步驟

• 一、 創建TCP鏈接
• 二、 Web瀏覽器發送請命令
• 三、 Web瀏覽器發送請求頭信息
• 四、 Web服務器應答,(應答第一部分是協議的版本號和應答狀態碼)
• 五、 Web服務器向瀏覽器發送應答頭信息（發送被請求的文檔和本身的數據）
• 六、 Web服務器向瀏覽器發送數據（發送頭信息後，會發送一個空白行來表示頭信息的發送到此結束，接着就以Content-Type應答頭信息描述的格式發送用戶請求的實際數據）
• 七、 Web服務器關閉TCP鏈接
• 注： 通常狀況系，服務器在發送數據以後就會關閉TCP鏈接，而後若是瀏覽器或者服務器在其頭部信息加入 Connection:keep-alive TCP鏈接在發送後仍然保持打開狀態，因而，瀏覽器能夠經過想用的連接發送請求，節省新創建鏈接所需時間，節省帶寬。

 20.簡述瀏覽器輸入地址按回車鍵以後瀏覽器的執行操做

• 一、 創建tcp鏈接
• 二、 找到域名對應的ip
• 訪問首先要找出其對應的ip地址，查找過程：在瀏覽器緩存中查找，而後在系統緩存查找，前面的請求發送給路由器，通常路由器會有本身的DNS緩存，系統緩存中沒有就回去路由器緩存中查找，而後去ISP緩存的DNS服務器中查找，都找不到的時候
• 三、 向服務器發送http請求請求頭請求體
• 四、 服務器檢查處理請求
• 五、 服務器發送應答頭
• 六、 服務器發送數據
• 七、 服務器關閉tcp
• 八、 瀏覽器讀取數據
• 九、 解析成dom生成虛擬的dom樹
• 十、 創建別的http請求下載css js圖片其餘文件
• 十一、 渲染頁面
• 十二、 重繪頁面