HTTP跨域、HTTP狀態碼、HTTP請求方式、C/S和B/S模式


1.跨域基本概念

   只要協議、域名、端口有任何一個不同,都被當作是不同的域。
   由於瀏覽器的同源策略,其限制之一是不能通過ajax的方法請求不同源的文檔。第二個限制是瀏覽器中不同域的框架(iframe)間是不能進行js的交互操作的。

2.跨域方式有哪些

   1.通過document.domain跨域

     修改document.domain的方式只適用於不同子域的框架間的交互。

   2.通過location.hash跨域

     因為父窗口可以對iframe進行URL讀寫,iframe也可以讀寫父窗口的URL,URL有一部分被稱為hash,就是#號及其后面的字符,它一般用於瀏覽器錨點定位,Server端並不關心這部分,應該說HTTP請求過程中不會攜帶hash,所以這部分的修改不會產生HTTP請求,但是會產生瀏覽器歷史記錄。

     此方法的原理就是改變URL的hash部分來進行雙向通信。每個window通過改變其他 window的location來發送消息(由於兩個頁面不在同一個域下IE、Chrome不允許修改parent.location.hash的值,所以要借助於父窗口域名下的一個代理iframe),並通過監聽自己的URL的變化來接收消息。

     這個方式的通信會造成一些不必要的瀏覽器歷史記錄,而且有些瀏覽器不支持onhashchange事件,需要輪詢來獲知URL的改變,最后,這樣做也存在缺點,諸如數據直接暴露在了url中,數據容量和類型都有限等。

   3.通過HTML5的postMessage方法跨域

     高級瀏覽器Internet Explorer 8+, chrome,Firefox , Opera 和 Safari 都將支持這個功能。

     這個功能主要包括接受信息的"message"事件和發送消息的"postMessage"方法。比如damonare.cn域的A頁面通過iframe嵌入了一個google.com域的B頁面,可以通過以下方法實現A和B的通信

   4.通過jsonp跨域

     以上幾種都是雙向通信的,即兩個iframe,頁面與iframe或是頁面與頁面之間的。

     通過script標簽引入的js是不受同源策略的限制的。所以我們可以通過script標簽引入一個js或者是一個其他后綴形式(如php,jsp等)的文件,此文件返回一個js函數的調用。

      JSONP的優缺點:

          優點:它不像XMLHttpRequest對象實現的Ajax請求那樣受到同源策略的限制;它的兼容性更好,在更加古老的瀏覽器中都可以運行,不需要XMLHttpRequest或ActiveX的支持;並且在請求完畢后可以通過調用callback的方式回傳結果。

          缺點:它只支持GET請求而不支持POST等其它類型的HTTP請求;它只支持跨域HTTP請求這種情況,不能解決不同域的兩個頁面之間如何進行JavaScript調用的問題。 

   5.通過CORS跨域

     CORS(Cross-Origin Resource Sharing)跨域資源共享,定義了必須在訪問跨域資源時,瀏覽器與服務器應該如何溝通。CORS背后的基本思想就是使用自定義的HTTP頭部讓瀏覽器與服務器進行溝通,從而決定請求或響應是應該成功還是失敗。目前,所有瀏覽器都支持該功能,IE瀏覽器不能低於IE10。整個CORS通信過程,都是瀏覽器自動完成,不需要用戶參與。對於開發者來說,CORS通信與同源的AJAX通信沒有差別,代碼完全一樣。瀏覽器一旦發現AJAX請求跨源,就會自動添加一些附加的頭信息,有時還會多出一次附加的請求,但用戶不會有感覺。   

     CORS與JSONP的對比:

        JSONP只能實現GET請求,而CORS支持所有類型的HTTP請求。

        使用CORS,開發者可以使用普通的XMLHttpRequest發起請求和獲得數據,比起JSONP有更好的錯誤處理。

        JSONP主要被老的瀏覽器支持,它們往往不支持CORS,而絕大多數現代瀏覽器都已經支持了CORS

3.后端修改請求頭,實現cros跨域時,在發送post請求之前會先發送什么

     第一次是OPTIONS請求方式, 第二次才是正常的POST

     OPTIONS就是相當於在正式請求接口之前去獲取以下header, 就是所設置的那些header. 如果在這次OPTIONS請求中服務器有返回正確的header, 這時才會執行后面真正的請求; 否則請求將會被拒絕, 並拋出錯誤.

4.常見HTTP狀態碼(HTTP狀態碼是服務器和客戶端之間交流信息的語言)   

    1XX系列

    指定客戶端應相應的某些動作,代表請求已被接受,需要繼續處理。由於在HTTP/1.0協議中沒有定義任何1xx狀態碼,所以除非在某些試驗條件下,服務器禁止向此類客戶端發送 1xx 響應。

    2XX系列

    代表請求已成功被服務器接收、理解、並接受。這系列中最常見的有200、201狀態碼。(http://jlyy0831.com)

    200狀態碼

    表示請求已成功,請求所希望的響應頭或數據體將隨此響應返回。

    201狀態碼

    表示請求成功並且服務器創建了新的資源,且其URI已經隨Location頭信息返回。假如需要的資源無法及時建立的話,應當返回【202 Accepted】。

    202狀態碼

    服務器已接受請求,但尚未處理。

    3XX系列

    代表需要客戶端采取進一步的操作才能完成請求,這些狀態碼用來重定向,后續的請求地址(重定向目標)在本次響應的Location域中指明。這系列中最常見的有301、302狀態碼。

    301狀態碼

    被請求的資源已永久移動到新位置。服務器返回此響應(對GET或HEAD請求的響應)時,會自動將請求者轉到新位置。

    302狀態碼

    請求的資源臨時從不同的URI響應請求,但請求者應繼續使用原有位置來進行以后的請求。(http://www.jl3652999.com)

    304狀態碼

    自從上次請求后,請求的網頁未修改過。服務器返回此響應時,不會返回網頁內容。 如果網頁自請求者上次請求后再也沒有更改過,您應將服務器配置為返回此響應(稱為If-Modified-Since HTTP標頭)。

    4XX系列

    表示請求錯誤。代表了客戶端看起來可能發生了錯誤,妨礙了服務器的處理。常見有:401、404狀態碼。

    401狀態碼

    請求要求身份驗證。 對於需要登錄的網頁,服務器可能返回此響應。

    403狀態碼

    服務器已經理解請求,但是拒絕執行它。與401響應不同的是,身份驗證並不能提供任何幫助,而且這個請求也不應該被重復提交。

    404狀態碼

    請求失敗,請求所希望得到的資源未被在服務器上發現。沒有信息能夠告訴用戶這個狀況到底是暫時的還是永久的。假如服務器知道情況的話,應當使用410狀態碼來告知舊資源因為某些內部的配置機制問題,已經永久的不可用,而且沒有任何可以跳轉的地址。404這個狀態碼被廣泛應用於當服務器不想揭示到底為何請求被拒絕或者沒有其他適合的響應可用的情況下。

    5xx系列

    代表了服務器在處理請求的過程中有錯誤或者異常狀態發生,也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處理。常見有500、503狀態碼。

    500狀態碼

    服務器遇到了一個未曾預料的狀況,導致了它無法完成對請求的處理。一般來說,這個問題都會在服務器的程序碼出錯時出現。

    503狀態碼

    由於臨時的服務器維護或者過載,服務器當前無法處理請求。通常,這個是暫時狀態,一段時間會恢復。

    504狀態碼

    504錯誤代表網關超時 (Gateway timeout),是指服務器作為網關或代理,但是沒有及時從上游服務器收到請求。

5.從瀏覽器輸入地址到頁面渲染完成之間發生了什么   

    1.DNS解析:將域名地址解析為IP地址;
    2.TCP連接:TCP三次握手
      -第一次握手,由瀏覽器發起,告訴服務器我要發送請求了;
      -第二次握手,由服務器發起,告訴瀏覽器我准備接收了;
      -第三次握手,有瀏覽器發起,告訴服務器,我即將發送;
    3.發送請求;(請求報文)
    4.接受響應;(響應報文)
    5.渲染頁面
      -瀏覽器用響應的解析器解析HTML、CSS、JS文件
    6斷開連接:TCP四次揮手
      -第一次揮手:由瀏覽器發起,告訴服務器請求報文發送完了,准備關閉;
      -第二次揮手:由服務器發起,告訴瀏覽器請求報文接收完了,准備關閉;
      -第三次揮手:由服務器發起,告訴瀏覽器響應報文發送完了,准備關閉;
      -第四次揮手:由瀏覽器發起,告訴服務器響應報文接收完了,准備關閉。

6.http請求方式(8種)

    HTTP/1.1協議中共定義了八種方法(有時也叫“動作”),來表明Request-URL指定的資源不同的操作方式

    HTTP1.0定義了三種請求方法: GET, POST 和 HEAD方法。

    HTTP1.1新增了五種請求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法  

     1、OPTIONS
      返回服務器針對特定資源所支持的HTTP請求方法,也可以利用向web服務器發送‘*’的請求來測試服務器的功能性
     2、HEAD
      向服務器索取與GET請求相一致的響應,只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下,就可以獲取包含在響應小消息頭中的元信息。
     3、GET
      向特定的資源發出請求。注意:GET方法不應當被用於產生“副作用”的操作中,例如在Web Application中,其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。Loadrunner中對應get請求函數:web_link和web_url
     4、POST
      向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函數:web_submit_data,web_submit_form
     5、PUT
      向指定資源位置上傳其最新內容
     6、DELETE
      請求服務器刪除Request-URL所標識的資源
     7、TRACE
      回顯服務器收到的請求,主要用於測試或診斷
     8、CONNECT
      HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
     注意:
      1)方法名稱是區分大小寫的,當某個請求所針對的資源不支持對應的請求方法的時候,服務器應當返回狀態碼405(Mothod Not Allowed);當服務器不認識或者不支持對應的請求方法時,應返回狀態碼501(Not Implemented)。
      2)HTTP服務器至少應該實現GET和HEAD/POST方法,其他方法都是可選的,此外除上述方法,特定的HTTP服務器支持擴展自定義的方法。    

  請求響應步驟:

    客戶端連接到Web服務器->發送Http請求->服務器接受請求並返回HTTP響應->釋放連接TCP連接->客戶端瀏覽器解析HTML內容  

  http是超文本傳輸協議,默認端口號為80,客戶端是動態的,瀏覽器會自動默認為80

  https默認端口號為443

7.簡述C/S和B/S模式的區別  

    C / S 也稱為客戶端/服務器模式。服務器通常使用高性能PC,工作站或小型計算機,並使用大型數據庫系統,如Oracle,Sybase,Informix或SQL Server。客戶端需要安裝專用的客戶端軟件。

    B / S 是Brower / Server的縮寫。客戶端只需要安裝瀏覽器,例如Netscape Navigator或Internet Explorer。服務器安裝Oracle,Sybase,Informix或SQL Server等數據庫。瀏覽器通過Web服務器與數據庫交互。

  不同的硬件環境:   

    C / S 一般建立在專用網絡,小范圍的網絡環境中,然后通過專用LAN服務器提供連接和數據交換服務。

    B / S 建立在WAN上。它不必是專用的網絡硬件環境。例如,它連接到互聯網,租用設備。信息由其自身管理。適應范圍比C / S更強。通常,只要有操作系統和瀏覽器。

  不同的安全要求:   

    C / S 通常面向相對固定的用戶組,並且對信息安全具有很強的控制力。通常,高度機密的信息系統采用C / S結構。它可以通過B / S部分發布。

    B / S 建立在WAN上,其安全控制能力相對較弱,並且是一個不可知的用戶組。

  不同的程序架構:   

    C / S 程序可以更加注重進程,可以檢查多級權限,並可以較少考慮系統的運行速度。

    B / S 對安全性和訪問速度的多重考慮是基於對更多優化的需求。從MS的.Net系列開始,具有比C / S更高要求的程序架構是一種發展趨勢。 BizTalk 2000 Exchange 2000等,完全支持網絡組件構建系統。 SUN和IBM推出JavaBean組件技術等,使B / S更加成熟。

  軟件重用是不同的:

    C / S 程序不可避免地被視為一個整體,並且組件的可重用性不如B / S要求下的組件的可重用性。

    B / S 對的多重結構需要相對獨立的組件功能。它可以相對較好地重復使用。購買的桌子可以重復使用,而不是牆上的石桌。

 

8.HTTP協議、TCP協議、IP協議分別在應用層,傳輸層,網絡層。

9.http2.0與http1.x相比有哪些優化/http發展歷程  

    1.新的二進制格式(Binary Format)

      HTTP1.x的解析是基於文本。基於文本協議的格式解析存在天然缺陷,文本的表現形式有多樣性,要做到健壯性考慮的場景必然很多,二進制則不同,只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定采用二進制格式,實現方便且健壯。

    2.多路復用(MultiPlexing)

      即連接共享,即每一個request都是是用作連接共享機制的。一個request對應一個id,這樣一個連接上可以有多個request,每個連接的request可以隨機的混雜在一起,接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。

    3.header壓縮

      HTTP1.x的header帶有大量信息,而且每次都要重復發送,HTTP2.0使用encoder來減少需要傳輸的header大小,通訊雙方各自cache一份header fields表,既避免了重復header的傳輸,又減小了需要傳輸的大小。

    4.服務端推送(server push)

      同SPDY一樣,HTTP2.0也具有server push功能。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM