記錄一次面試中的HTTP請求相關問題

1.HTTP中的狀態碼分別表明什麼

比較基礎，自行百度。

 

2.HTTP請求，響應頭部content-length用來作什麼的

答：Content-Length首部告訴瀏覽器報文中實體主體的大小。這個大小是包含了內容編碼的，好比對文件進行了gzip壓縮，Content-Length就是壓縮後的大小，而不是原始大小。除非使用了分塊編碼（chunked），不然Content-Length首部就是帶有實體主體的報文必須使用的。使用Content-Length首部是爲了可以檢測出服務器崩潰而致使的報文截尾，並對共享持久鏈接的多個報文進行正確分段.

 

另外Content-Length首部對於長鏈接是必不可少的，長鏈接表明在鏈接期間會有多個http請求響應在排隊，而服務器不可以關閉鏈接，客戶端只能經過Content-Length知道一條報文在哪裏結束，下一條報文在哪裏開始。

 

除非使用了分塊編碼Transfer-Encoding: chunked，不然響應頭首部必須使用Content-Length首部。（HTTP1.1必須支持chunk模式。由於當不肯定消息長度的時候，能夠經過chunk機制來處理這種狀況。也就是有chunk就不能有content-length 。） [摘自http權威指南]

 

那麼擴展一下就是，若是使用chunked編碼的時候，就不用Content-length，以及，若是使用非長鏈接keep-alive的時候也能夠不要，由於能夠直接經過服務器關閉鏈接來肯定消息的傳輸長度

 

3.HTTP中上傳文件是怎麼上傳的

http://www.javashuo.com/article/p-senpdgtg-bu.html

 

4.TCP爲何是三次握手，爲何不是兩次或者四次

答：這是一個頗有意思的問題~  

　　首先，咱們要知道TCP是全雙工的，即客戶端在給服務器端發送信息的同時，服務器端也能夠給客戶端發送信息。而半雙工的意思是A能夠給B發，B也能夠給A發，可是A在給B發的時候，B不能給A發，即不一樣時，爲半雙工。 單工爲只能A給B發，B不能給A發； 或者是隻能B給A發，不能A給B發。

　　咱們假設A和B是通訊的雙方。我理解的握手實際上就是通訊，發一次信息就是進行一次握手。

• 第一次握手： A給B打電話說，你能夠聽到我說話嗎？
• 第二次握手： B收到了A的信息，而後對A說： 我能夠聽獲得你說話啊，你能聽獲得我說話嗎？  
• 第三次握手： A收到了B的信息，而後說能夠的，我要給你發信息啦！

　　在三次握手以後，A和B都能肯定這麼一件事： 我說的話，你能聽到； 你說的話，我也能聽到。 這樣，就能夠開始正常通訊了。

 

　　注意： HTTP是基於TCP協議的，因此每次都是客戶端發送請求，服務器應答，可是TCP還能夠給其餘應用層提供服務，便可能A、B在創建連接以後，誰均可能先開始通訊。

　　　　

　　若是兩次，那麼B沒法肯定B的信息A是否能收到，因此若是B先說話，可能後面的A都收不到，會出現問題 。

　　若是四次，那麼就形成了浪費，由於在三次結束以後，就已經能夠保證A能夠給B發信息，A能夠收到B的信息； B能夠給A發信息，B能夠收到A的信息。

原答案網址：http://www.javashuo.com/article/p-swvqtzls-b.html

 

5.HTTP頭部裏有哪些Content-Type？

 MediaType，便是Internet Media Type，互聯網媒體類型；也叫作MIME類型，在Http協議消息頭中，使用Content-Type來表示具體請求中的媒體類型信息。

常見的媒體格式類型以下：

•     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數據格式（Java後臺能夠經過@RequestBody進行接收，適配主流RestApi風格）
•    application/pdf       ：pdf格式  
•    application/msword  ： Word文檔格式
•    application/octet-stream ： 二進制流數據（如常見的文件下載）
•    application/x-www-form-urlencoded ： <form encType=」」>中默認的encType，form表單數據被編碼爲key/value格式發送到服務器（表單默認的提交數據的格式，常見的以key1=value1&keys=value2，拼接在url後面，java後臺可使用getParameter（‘key’）的方式接收）

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

•     multipart/form-data ： 須要在表單中進行文件上傳時，就須要使用該格式(java後臺可使用request.getInputStream()得到數據，而後再經過一些開源組件的api得到指定項數據)

     以上就是咱們在平常的開發中，常常會用到的若干content-type的內容格式。

 

 

6.DNS用來作什麼

DNS就是把域名和IP地址聯繫在一塊兒的服務，有了DNS服務器，你就不用輸入IP地址來訪問一個網站，能夠經過輸入網址訪問。

更符合人類的記憶習慣。

 

7.HTTP劫持有哪些類型

答：說道HTTP劫持，咱們能夠聯想到DNS劫持，這兩種劫持都是，運營商經過某些方式篡改了用戶正常訪問的網頁，插入廣告或者其餘一些雜七雜八的東西。

DNS劫持：

通常而言，用戶上網的DNS服務器都是運營商分配的，因此，在這個節點上，運營商能夠隨心所欲。

例如，訪問http://jiankang.qq.com/index.html，正常DNS應該返回騰訊的ip，而DNS劫持後，會返回一個運營商的中間服務器ip。訪問該服務器會一致性的返回302，讓用戶瀏覽器跳轉到預處理好的帶廣告的網頁，在該網頁中再經過iframe打開用戶原來訪問的地址。

 

HTTP劫持：

在運營商的路由器節點上，設置協議檢測，一旦發現是HTTP請求，並且是html類型請求，則攔截處理。後續作法每每分爲2種，1種是相似DNS劫持返回302讓用戶瀏覽器跳轉到另外的地址，還有1種是在服務器返回的HTML數據中插入js或dom節點（廣告），實際是修改了數據流。

    在用戶角度，這些劫持的表現分爲：

    一、網址被無辜跳轉，多了推廣尾巴；在訪問地址後面多了？xxxx之類的推廣尾巴

    二、頁面出現額外的廣告（iframe模式或者直接同頁面插入了dom節點）

 

HTTP劫持的應對辦法是：

1.在頁面中作檢測，一但發現有dom植入或者檢測當前窗口層級，若是嵌套在iframe裏面，則需檢查url白名單，若是不是嵌套在白名單內的iframe裏，則調用location重定向

2.使用https，一勞永逸

 

 

8.301，302重定向的使用場景

301是永久重定向，使得搜索引擎在抓取新內容的同時將舊的網址替換爲重定向後的網址，可緩存。

而302是臨時重定向，使得搜索引擎會抓去新的內容卻保留舊的網址

 

適用場景

301：域名切換、HTTP遷移到HTTPS

302：未登陸用戶訪問我的中心時重定向到登陸頁面、404頁面提示後跳轉到首頁

 

場景：若是我有一短鏈接，用戶訪問的時候須要重定向到短鏈接對應的網址。這種狀況下，你會考慮用301仍是302？

當時沒有什麼思路，面試官的想法是，301雖然能夠緩存，可是我服務器又不值錢。。。 302的話，能夠獲取到一些用戶統計數據，

顯然數據更有價值。具體的，仍是看公司業務場景吧。

 

9.HTTP請求數量有限制嗎？HTTP請求數量限制是針對域名仍是什麼？

同一時間針對同一域名下的請求有必定數量限制。超過限制數目的請求會被阻塞。主流的瀏覽器好像是6-8個。這也是爲何有的網站，有些資源請求的會是另一個域名。

 

10.HTTP2.0跟HTTP1.1有什麼區別

1. HTTP/2採用二進制格式而非文本格式

2. HTTP/2是徹底多路複用的，而非有序並阻塞的——只需一個鏈接便可實現並行

3. 使用報頭壓縮，HTTP/2下降了開銷

4. HTTP/2讓服務器能夠將響應主動「推送」到客戶端緩存中

 

HTTP/2爲何是二進制？

比起像HTTP/1.x這樣的文本協議，二進制協議解析起來更高效、「線上」更緊湊，更重要的是錯誤更少。

 

爲何 HTTP/2 須要多路傳輸?

HTTP/1.x 有個問題叫線端阻塞(head-of-line blocking), 它是指一個鏈接(connection)一次只提交一個請求的效率比較高, 多了就會變慢。 HTTP/1.1 試過用流水線(pipelining)來解決這個問題, 可是效果並不理想(數據量較大或者速度較慢的響應, 會阻礙排在他後面的請求). 此外, 因爲網絡媒介(intermediary )和服務器不能很好的支持流水線, 致使部署起來困難重重。而多路傳輸(Multiplexing)能很好的解決這些問題, 由於它能同時處理多個消息的請求和響應; 甚至能夠在傳輸過程當中將一個消息跟另一個摻雜在一塊兒。因此客戶端只須要一個鏈接就能加載一個頁面。

 

消息頭爲何須要壓縮?

假定一個頁面有80個資源須要加載（這個數量對於今天的Web而言仍是挺保守的）, 而每一次請求都有1400字節的消息頭（着一樣也並很多見，由於Cookie和引用等東西的存在）, 至少要7到8個來回去「在線」得到這些消息頭。這還不包括響應時間——那只是從客戶端那裏獲取到它們所花的時間而已。這全都因爲TCP的慢啓動機制，它會基於對已知有多少個包，來肯定還要來回去獲取哪些包 – 這很明顯的限制了最初的幾個來回能夠發送的數據包的數量。相比之下，即便是頭部輕微的壓縮也能夠是讓那些請求只需一個來回就能搞定——有時候甚至一個包就能夠了。這種開銷是能夠被節省下來的，特別是當你考慮移動客戶端應用的時候，即便是良好條件下，通常也會看到幾百毫秒的來回延遲。

 

服務器推送的好處是什麼？

當瀏覽器請求一個網頁時，服務器將會發回HTML，在服務器開始發送JavaScript、圖片和CSS前，服務器須要等待瀏覽器解析HTML和發送全部內嵌資源的請求。服務器推送服務經過「推送」那些它認爲客戶端將會須要的內容到客戶端的緩存中，以此來避免往返的延遲。

 

答案網址：http://www.javashuo.com/article/p-msohsfnk-cc.html

 

全文完，以爲有幫助，不妨點個贊哦~