Http協議面試題

當輸入www.google.com時，頁面發生了哪些事情：

 

1.域名解析

域名解析檢查順序爲：瀏覽器自身DNS緩存---》OS自身的DNS緩存--》讀取host文件--》本地域名服務器--》權限域名服務器--》根域名服務器。若是有且沒有過時，則結束本次域名解析。域名解析成功以後，進行後續操做

2.tcp3次握手創建鏈接

3.創建鏈接後，發起http請求

4.服務器端響應http請求，瀏覽器獲得到http請求的內容；

5.瀏覽器解析html代碼，並請求html代碼中的資源

6.瀏覽器對頁面進行渲染，展示在用戶面前。

一、說一下什麼是Http協議？

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

二、什麼是Http協議無狀態協議？怎麼解決Http協議無狀態協議？（曾經去某創業公司問到）

• 無狀態協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息
• 無狀態協議解決辦法： 經過一、Cookie 二、經過Session會話保存。

三、說一下Http協議中302狀態(阿里常常問)

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

四、Http協議有什麼組成？

  請求報文包含三部分：

• 請求行：包含請求方法、URI、HTTP版本信息
• 請求首部字段
• 請求內容實體

  響應報文包含三部分：

• 狀態行：包含HTTP版本、狀態碼、狀態碼的緣由短語
• 響應首部字段
• 響應內容實體

說一下網絡傳輸的過程

五、Http協議中有那些請求方式？

• GET： 用於請求訪問已經被URI（統一資源標識符）識別的資源，能夠經過URL傳參給服務器
• POST：用於傳輸信息給服務器，主要功能與GET方法相似，但通常推薦使用POST方式。
• PUT： 傳輸文件，報文主體中包含文件內容，保存到對應URI位置。
• HEAD： 得到報文首部，與GET方法相似，只是不返回報文主體，通常用於驗證URI是否有效。
• DELETE：刪除文件，與PUT方法相反，刪除對應URI位置的文件。
• OPTIONS：查詢相應URI支持的HTTP方法。

六、Http協議中Http1.0與1.1區別？

• 在http1.0中，當創建鏈接後，客戶端發送一個請求，服務器端返回一個信息後就關閉鏈接，當瀏覽器下次請求的時候又要創建鏈接，顯然這種不斷創建鏈接的方式，會形成不少問題。
• 在http1.1中，引入了持續鏈接的概念，經過這種鏈接，瀏覽器能夠創建一個鏈接以後，發送請求並獲得返回信息，而後繼續發送請求再次等到返回信息，也就是說客戶端能夠連續發送多個請求，而不用等待每個響應的到來。

七、get與post請求區別？（初級程序員必備問題）

區別一：

• get重點在從服務器上獲取資源。
• post重點在向服務器發送數據。

區別二：

• get傳輸數據是經過URL請求，以field（字段）= value的形式，置於URL後，並用"?"鏈接，多個請求數據間用"&"鏈接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程用戶是可見的。
• post傳輸數據經過Http的post機制，將字段與對應值封存在請求實體中發送給服務器，這個過程對用戶是不可見的。

區別三：

• Get傳輸的數據量小，由於受URL長度限制，但效率較高。
• Post能夠傳輸大量數據，因此上傳文件時只能用Post方式。

區別四：

• get是不安全的，由於URL是可見的，可能會泄露私密信息，如密碼等。
• post較get安全性較高。

區別五：

• get方式只能支持ASCII字符，向服務器傳的中文字符可能會亂碼。
• post支持標準字符集，能夠正確傳遞中文字符。

九、常見Http協議狀態？

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

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

十、Http協議首部字段？

a、請求行

請求的第一行是「方法、URL、協議/版本」：

POST http://xg.mediportal.com.cn/health/sms/verify/telephone HTTP/1.1

以上代碼中「POST」表明請求方法，「http://xg.mediportal.com.cn/health/sms/verify/telephone」表示URI，「HTTP/1.1表明協議和協議的版本。

根據HTTP標準，HTTP請求可使用多種請求方法。例如：HTTP1.1目前支持7種請求方法：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE。

 

GET	請求獲取由Request-URI所標識的資源
POST	在Request-URI所標識的資源後附加新的數據
HEAD	請求獲取由Request-URI所標識的資源的響應消息報頭
OPTIONS	請求查詢服務器的性能，或查詢與資源相關的選項和需求
PUT	請求服務器存儲一個資源，並用Request-URI做爲其標識
DELETE	請求服務器刪除由Request-URI所標識的資源
TRACE	請求服務器回送收到的請求信息，主要用語測試或診斷

b、請求頭（請求頭包含許多有關的客戶端環境和請求正文的有用信息。例如，請求頭能夠聲明瀏覽器所用的語言，請求正文的長度等）

• Content-Type	是返回消息中很是重要的內容，表示後面的文檔屬於什麼MIME類型。Content-Type: [type]/[subtype]; parameter。例如最多見的就是text/html，它的意思是說返回的內容是文本類型，這個文本又是HTML格式的。原則上瀏覽器會根據Content-Type來決定如何顯示返回的消息體內容
  Host	指定請求資源的Intenet主機和端口號，必須表示請求url的原始服務器或網關的位置。HTTP/1.1請求必須包含主機頭域，不然系統會以400狀態碼返回
  Accept	瀏覽器可接受的MIME類型
  Accept-Charset	瀏覽器可接受的字符集
  Accept-Encoding	瀏覽器可以進行解碼的數據編碼方式，好比gzip。Servlet可以向支持gzip的瀏覽器返回經gzip編碼的HTML頁面。許多情形下這能夠減小5到10倍的下載時間
  Accept-Language	瀏覽器所但願的語言種類，當服務器可以提供一種以上的語言版本時要用到
  Authorization	受權信息，一般出如今對服務器發送的WWW-Authenticate頭的應答中
  Connection	表示是否須要持久鏈接。若是Servlet看到這裏的值爲「Keep- Alive」，或者看到請求使用的是HTTP1.1（HTTP 1.1默認進行持久鏈接），它就能夠利用持久鏈接的優勢，當頁面包含多個元素時（例如Applet，圖片），顯著地減小下載所須要的時間。要實現這一點，Servlet須要在應答中發送一個Content-Length頭，最簡單的實現方法是：先把內容寫入 ByteArrayOutputStream，而後在正式寫出內容以前計算它的大小
  Content-Length	表示請求消息正文的長度
  Cookie	這是最重要的請求頭信息之一
  From	請求發送者的email地址，由一些特殊的Web客戶程序使用，瀏覽器不會用到它
  Host	初始URL中的主機和端口
  If-Modified-Since	只有當所請求的內容在指定的日期以後又通過修改才返回它，不然返回304「Not Modified」應答
  Pragma	指定「no-cache」值表示服務器必須返回一個刷新後的文檔，即便它是代理服務器並且已經有了頁面的本地拷貝
  Referer	包含一個URL，用戶從該URL表明的頁面出發訪問當前請求的頁面
  User-Agent	瀏覽器類型，若是Servlet返回的內容與瀏覽器類型有關則該值很是有用
  UA-Pixels，UA-Color，UA-OS，UA-CPU	由某些版本的IE瀏覽器所發送的非標準的請求頭，表示屏幕大小、顏色深度、操做系統和CPU類型

 常見的MIME類型以下：

•     text/html ： HTML格式
•     text/plain ：純文本格式      
•     text/xml ：  XML格式
•     image/gif ：gif圖片格式    
•     image/jpeg ：jpg圖片格式 
•     image/png：png圖片格式

  以application開頭的媒體格式類型：

•    application/xhtml+xml ：XHTML格式
•    application/xml     ： XML數據格式
•    application/atom+xml  ：Atom XML聚合格式    
•    application/json    ： JSON數據格式
•    application/pdf       ：pdf格式  
•    application/msword  ： Word文檔格式
•    application/octet-stream ： 二進制流數據（如常見的文件下載）
•    application/x-www-form-urlencoded ： <form encType=」」>中默認的encType，form表單數據被編碼爲key/value格式發送到服務器（表單默認的提交數據的格式）

   另一種常見的媒體格式是上傳文件之時使用的：

•     multipart/form-data ： 須要在表單中進行文件上傳時，就須要使用該格式

（3）請求正文

請求頭和請求正文之間是一個空行，這個行很是重要，它表示請求頭已經結束，接下來的是請求正文。請求正文中能夠包含客戶提交的查詢字符串信息：

telephone=15527177736&userType=1&

 

http響應格式

HTTP應答與HTTP請求類似，HTTP響應也由3個部分構成，分別是：

一、狀態行

二、響應頭(Response Header)

三、響應正文

 

HTTP/1.1 200 OK   //狀態行
Server: nginx
Date: Tue, 31 May 2016 02:09:24 GMT
Content-Type: application/json;charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: X-Requested-With,access_token,access-token,content-type,multipart/form-data,application/x-www-form-urlencoded
Access-Control-Allow-Methods: GET,POST,OPTIONS
Content-Length: 49

{"resultCode":1,"resultMsg":"手機號未註冊"}   //正文

 

（1）狀態行

由協議版本、數字形式的狀態代碼、及相應的狀態描述，各元素之間以空格分隔。

狀態代碼：

狀態代碼由3位數字組成，表示請求是否被理解或被知足。

狀態描述：

狀態描述給出了關於狀態代碼的簡短的文字描述。

狀態代碼的第一個數字定義了響應的類別，後面兩位沒有具體的分類。

第一個數字有五種可能的取值：

- 1xx:   指示信息—表示請求已接收，繼續處理。

- 2xx:   成功—表示請求已經被成功接收、理解、接受。

- 3xx:   重定向—要完成請求必須進行更進一步的操做。

- 4xx:   客戶端錯誤—請求有語法錯誤或請求沒法實現。

- 5xx: 服務器端錯誤—服務器未能實現合法的請求。

狀態代碼 狀態描述    說明

   200  OK    客戶端請求成功

   400  Bad Request   因爲客戶端請求有語法錯誤，不能被服務器所理解。

   401  Unauthonzed   請求未經受權。這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用

   403   Forbidden   服務器收到請求，可是拒絕提供服務。服務器一般會在響應正文中給出不提供服務的緣由

   404   Not Found   請求的資源不存在，例如，輸入了錯誤的URL。

   500  Internal Server Error 服務器發生不可預期的錯誤，致使沒法完成客戶端的請求。

  503  Service Unavailable   服務器當前不可以處理客戶端的請求，在一段時間以後，服務器可能會恢復正常

（2）響應頭 

響應頭可能包括：

Location： 

Location響應報頭域用於重定向接受者到一個新的位置。例如：客戶端所請求的頁面已不存在原先的位置，爲了讓客戶端重定向到這個頁面新的位置，服務 器端能夠發回Location響應報頭後使用重定向語句，讓客戶端去訪問新的域名所對應的服務器上的資源。當咱們在JSP中使用重定向語句的時候，服務器 端向客戶端發回的響應報頭中，就會有Location響應報頭域。

Server：  

Server響應報頭域包含了服務器用來處理請求的軟件信息。它和User-Agent請求報頭域是相對應的，前者發送服務器端軟件的信息，後者發送客戶 端軟件(瀏覽器)和操做系統的信息。下面是Server響應報頭域的一個例子：Server: Apache-Coyote/1.1

WWW-Authenticate：

WWW-Authenticate響應報頭域必須被包含在401(未受權的)響應消息中，這個報頭域和前面講到的Authorization請求報頭域是 相關的，當客戶端收到401響應消息，就要決定是否請求服務器對其進行驗證。若是要求服務器對其進行驗證，就能夠發送一個包含了 Authorization報頭域的請求，下面是WWW-Authenticate響應報頭域的一個例子：WWW-Authenticate: Basic realm="Basic Auth Test!"

從這個響應報頭域，能夠知道服務器端對咱們所請求的資源採用的是基本驗證機制。

Content-Encoding：

Content-Encoding實體報頭域被使用做媒體類型的修飾符，它的值指示了已經被應用到實體正文的附加內容編碼，於是要得到Content- Type報頭域中所引用的媒體類型，必須採用相應的解碼機制。Content-Encoding主要用語記錄文檔的壓縮方法，下面是它的一個例子： Content-Encoding: gzip。若是一個實體正文采用了編碼方式存儲，在使用以前就必須進行解碼。

Content-Language：

Content-Language實體報頭域描述了資源所用的天然語言。Content-Language容許用戶遵守自身的首選語言來識別和區分實體。 若是這個實體內容僅僅打算提供給丹麥的閱讀者，那麼能夠按照以下的方式設置這個實體報頭域：Content-Language: da。

若是沒有指定Content-Language報頭域，那麼實體內容將提供給因此語言的閱讀者。

Content-Length：

Content-Length實體報頭域用於指明正文的長度，以字節方式存儲的十進制數字來表示，也就是一個數字字符佔一個字節，用其對應的ASCII碼存儲傳輸。

       要注意的是：這個長度僅僅是表示實體正文的長度，沒有包括實體報頭的長度。

Content-Type :

     Content-Type實體報頭域用語指明發送給接收者的實體正文的媒體類型。例如：

Content-Type: text/html;charset=ISO-8859-1

   Content-Type: text/html;charset=GB2312

Last-Modified :

     Last-Modified實體報頭域用於指示資源最後的修改日期及時間。

Expires :

     Expires實體報頭域給出響應過時的日期和時間。一般，代理服務器或瀏覽器會緩存一些頁面。當用戶再次訪問這些頁面時，直接從緩存中加載並顯示給用 戶，這樣縮短了響應的時間，減小服務器的負載。爲了讓代理服務器或瀏覽器在一段時間後更新頁面，咱們可使用Expires實體報頭域指定頁面過時的時 間。當用戶又一次訪問頁面時，若是Expires報頭域給出的日期和時間比Date普通報頭域給出的日期和時間要早(或相同)，那麼代理服務器或瀏覽器就 不會再使用緩存的頁面而是從服務器上請求更新的頁面。不過要注意，即便頁面過時了，也並不意味着服務器上的原始資源在此時間以前或以後發生了改變。

      Expires實體報頭域使用的日期和時間必須是RFC 1123中的日期格式，例如：

 Expires: Thu, 15 Sep 2005 16:00:00 GMT

       HTTP1.1的客戶端和緩存必須將其餘非法的日期格式(也包括0)看做已過時。例如，爲了讓瀏覽器不要緩存頁面，咱們也能夠利用Expires實體報頭 域，設置它的值爲0，以下(JSP)：response.setDateHeader("Expires",0);

 

十一、Http與Https優缺點？

• 通訊使用明文不加密，內容可能被竊聽，也就是被抓包分析。
• 不驗證通訊方身份，可能遭到假裝
• 沒法驗證報文完整性，可能被篡改
• HTTPS就是HTTP加上加密處理（通常是SSL安全通訊線路）+認證+完整性保護

十二、Http優化

• 利用負載均衡優化和加速HTTP應用
• 利用HTTP Cache來優化網站

1三、Http協議有那些特徵？

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