前端網(wǎng)絡(luò)知識點總結(jié)_第1頁
前端網(wǎng)絡(luò)知識點總結(jié)_第2頁
前端網(wǎng)絡(luò)知識點總結(jié)_第3頁
前端網(wǎng)絡(luò)知識點總結(jié)_第4頁
前端網(wǎng)絡(luò)知識點總結(jié)_第5頁
已閱讀5頁,還剩13頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

前端網(wǎng)絡(luò)知識點總結(jié)一、HTTP協(xié)議1、什么是TCP/IP協(xié)議不同的硬件、操作系統(tǒng)之間進(jìn)行通信,需要一種規(guī)則,我們把這種規(guī)則稱做協(xié)議,網(wǎng)絡(luò)傳輸?shù)母鱾€階段有不同的協(xié)議,這些協(xié)議的集合總稱為TCP/IP協(xié)議。http協(xié)議是TCP/IP協(xié)議的子集。2、TCP/IP分層及各層的作用?分為四層:應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層。應(yīng)用層:http協(xié)議屬于這一層,在這一層根據(jù)http協(xié)議生成針對目標(biāo)服務(wù)器的http請求報文,服務(wù)器端根據(jù)http解析報文。傳輸層:TCP協(xié)議屬于這一層,在這一層將根據(jù)TCP協(xié)議將http的請求報文分割成報文段,在服務(wù)器端會根據(jù)TCP協(xié)議合并報文段。建立和斷開TCP連接的過程就是三次握手,四次揮手。網(wǎng)絡(luò)層:IP協(xié)議屬于這一層,網(wǎng)絡(luò)層的作用是確定數(shù)據(jù)傳輸?shù)穆肪€。根據(jù)IP協(xié)議搜索對方地址,并一邊中轉(zhuǎn)一邊傳送。IP地址指明了節(jié)點被分配的地址,MAC地址是網(wǎng)卡所屬的固定地址,IP地址可以變,MAC一般不變。整個中轉(zhuǎn)的過程像是送快遞,用戶把數(shù)據(jù)送到快遞站,快遞公司再送到一個個大型中轉(zhuǎn)站。鏈路層:網(wǎng)絡(luò)傳輸過程中的硬件部分。過程:客戶端發(fā)出請求->應(yīng)用層發(fā)送http請求報文->傳輸層建立TCP連接,將報文分成報文段->網(wǎng)絡(luò)層根據(jù)請求的ip地址,進(jìn)行處理并加上MAC地址后交給鏈路層->鏈路層將數(shù)據(jù)送到請求的ip地址->請求ip的服務(wù)器根據(jù)IP,TCP,HTTP協(xié)議對數(shù)據(jù)進(jìn)行拼接等處理->服務(wù)器收到請求。3、DNS是什么?DNS是和http一樣位于應(yīng)用層的協(xié)議,用于解析域名,DNS協(xié)議提供通過域名查找IP地址或者IP地址反查域名的服務(wù)。URI和URL的區(qū)另UURI是統(tǒng)一資源標(biāo)識符,URL是統(tǒng)一資源定位符,URL是URI的子集。URI格式:協(xié)議名/方案名+登錄信息(可選)+服務(wù)器地址(網(wǎng)址或ip)+端口號(可選)+文件路徑+參數(shù)(可選)+片段標(biāo)識符(可選,哈希值)兩者區(qū)別就就是URL是確定了文件的路徑,而URI只是唯一的標(biāo)識出文件,但是不一定是該文件的路徑。5、什么是持久連接?如果一個請求就建立一次TCP連接,那么過程太費時間,資源,效率低下。所以,持久化連接就是三次握手建立TCP連接后,一直保持連接,直到四次揮手,才斷開連接。6、什么是管線化?因為持久連接,所以不必等一個請求響應(yīng)后再發(fā)起下一個請求,可以同時發(fā)送多個請求。大大節(jié)省了時間。7、cookie的誕生原因?http協(xié)議是無狀態(tài)的,不會保存之前一切請求的報文信息,所以假設(shè)有一個網(wǎng)站需要登錄,用戶登錄之后,在之后的訪問過程中怎么保持登錄狀態(tài),就成為一個問題。解決方法就是引入cookie技術(shù)。8、關(guān)于cookie的知識cookie是為了用戶識別和狀態(tài)管理,web網(wǎng)站為了管理用戶狀態(tài),會把一些數(shù)據(jù)臨時寫入用戶的計算機(jī)內(nèi),當(dāng)用戶訪問該網(wǎng)站時,可取回之前存放的cookie。cookie是不可跨域的,每個域名下的cookie是單獨保存的,不會混用。在一個頁面下發(fā)送的請求,帶的都是當(dāng)前域名下的cookie。cookie的重要屬性name:cookie的名字,同域名下name不能相同,否則會被覆蓋value:cookie的彳直path:路由secure:打鉤時,只會在https等安全協(xié)議下傳輸這個cookieHttpOnly:打鉤時,則不能通過js獲取,防止xss攻擊Expires/Max-age:cookie有效期,當(dāng)為session時,關(guān)閉瀏覽器(非頁面)就會清除。若為過期時間,則到時間時瀏覽器自動刪除。復(fù)制代碼3)服務(wù)端一旦通過set-cookie將cookie存儲到客戶端,就沒有方法可以直接刪除,而只能通過覆蓋的方式刪除。9、狀態(tài)碼狀態(tài)碼分為5大類:1XX:信息狀態(tài)類2XX:成功類3XX:重定向類4XX:客戶端錯誤類5XX:服務(wù)端錯誤類復(fù)制代碼不能完全相信狀態(tài)碼,有時候返回的狀態(tài)碼和實際情況是不一致的??!200:正常處理301:永久重定向,瀏覽器自動再次發(fā)送新的請求302:臨時重定向,瀏覽器自動再次發(fā)送新的請求303:與302相似,但表示客戶端應(yīng)該采用get方法獲取新的資源,瀏覽器自動再次發(fā)送新的請求304:附帶條件未滿足,和重定向沒有關(guān)系,服務(wù)器可通過此狀態(tài)碼高速客戶端,使用本地緩存403:服務(wù)端拒絕了請求,但沒有給具體原因404:服務(wù)器上沒有請求的資源500:服務(wù)器在執(zhí)行的時候發(fā)生了錯誤503:服務(wù)器超負(fù)載或停機(jī)維護(hù)復(fù)制代碼10、一臺服務(wù)器多個域名,IP地址一樣,怎么區(qū)分利用虛擬主機(jī)的技術(shù),可以實現(xiàn)一臺物理服務(wù)器上,部署多個域名,但是用DNS服務(wù)解析多個域名的時候,解析成的ip地址是一樣的,那怎么區(qū)分請求的是哪個資源呢?利用請求頭里的host字段來指定主機(jī)名或者是域名的URI,host一般只是發(fā)送域名,而referer則是完整的url地址,origin則是跨域的時候發(fā)送的。11、代理服務(wù)器代理服務(wù)器:接收客戶端請求,轉(zhuǎn)發(fā)給其他服務(wù)器,代理服務(wù)器根據(jù)兩個維度,可分為緩存代理,非緩存代理。透明代理和非透明代理(對數(shù)據(jù)進(jìn)行處理)。12、常用報文頭部字段cache-control:控制緩存的行為connection:管理連接,keep-alive持久連接cookie:set-cookie:設(shè)置cookiereferer:當(dāng)前請求的原始頁面cache-control:控制瀏覽器緩存Last-Modified:最后一次更新時間if-Modified-SinceEtagIf-None-Match復(fù)制代碼13、get和post的區(qū)別get和post是http協(xié)議中規(guī)定的,告知服務(wù)器意圖的方法。使用get方法用來請求已被URI識別的資源,而post方法用來傳輸實體主體,但get請求也可以發(fā)送實體,post請求也可以在url上加參數(shù)。本質(zhì)上,兩者都是TCP連接,區(qū)別是get發(fā)送一次數(shù)據(jù)包,post發(fā)送兩次數(shù)據(jù)包。在表面上,get和post的區(qū)別如下:1、關(guān)于傳入?yún)?shù)的大小限制,http協(xié)議里沒有規(guī)定,只不過是瀏覽器和服務(wù)器的約定俗稱。2、關(guān)于傳遞參數(shù)的安全性,get請求的url是在服務(wù)器上有日志記錄,在瀏覽器也能查到歷史記錄,但是post請求的參數(shù)都在body里面,服務(wù)器日志記錄不到,瀏覽器歷史也記錄不到,所以相對來說安全些。3、get請求可以緩存,post請求不能緩存14、localstorage、sessionstorage、cookiewindow.localStorage/sessionStorage.setItem( "key","value")window.localStorage/sessionStorage.getItem( "key")window.localStorage/sessionStorage.removeItem("key")復(fù)制代碼15、http的缺點,https如何保證安全?1、通信不加密,可能被竊聽2、不驗證通信方身份,可能有偽裝情況3、無法證明報文的完整性。可能被篡改SSL和TLS協(xié)議解決了以上的缺點,讓http更加安全SSL/TLS協(xié)議和http協(xié)議組合,就是https。https實際上就是披著SSL/TLS的http協(xié)議。https并不是直接通過非對稱加密傳輸過程,而是有握手過程,握手過程主要是和服務(wù)器做通訊,生成私有秘鑰,最后通過該秘鑰對稱加密傳輸數(shù)據(jù)。還有驗證證書的正確性。證書驗證過程保證了對方是合法的,并且中間人無法通過偽造證書方式進(jìn)行攻擊,HTTPS相對于HTTP性能上差點,因為多了SSL/TLS的幾次握手和加密解密的運算處理,但是加密解密的運算處理已經(jīng)可以通過特有的硬件來加速處理。16、三次握手,四次揮手1、何為三次握手在建立TCP連接的時候,客戶端和服務(wù)端一共要發(fā)送三次報文,才會成功的建立連接。客戶端->服務(wù)端->客戶端。2、為什么需要三次握手,而不是兩次如果出現(xiàn)以下場景:客戶端發(fā)出去的第一個連接請求由于某些原因在網(wǎng)絡(luò)節(jié)點中滯留了導(dǎo)致延遲,直到連接釋放的某個時間點才到達(dá)服務(wù)端,這是一個早已失效的報文,但是此時服務(wù)端仍然認(rèn)為這是客戶端的建立連接請求第一次握手,于是服務(wù)端回應(yīng)了客戶端,此時如果僅有兩次握手的話,連接就建立了,這肯定是浪費資源的行為。為什么不是四次或更多次握手呢?因為每一次握手都是耗費時間和資源的事,四次握手或者更多次當(dāng)然也是可以的,但考慮到成本,三次就夠了。3、何為四次揮手當(dāng)要斷開TCP連接時,客戶端或服務(wù)器均可主動發(fā)起揮手動作,發(fā)起方發(fā)起一個報文,表明我不再發(fā)起數(shù)據(jù)了,但是我還可以接收數(shù)據(jù)。接收方可能也有消息要繼續(xù)發(fā)送,所以接收方分兩次發(fā)送給發(fā)起方,一次報文是可以帶著數(shù)據(jù),還有一次是表示關(guān)閉TCP,發(fā)起方接收到這兩個報文后,回復(fù)給接收方,TCP鏈接中斷。為什么不是一次,兩次,三次,五次?原理其實和三次握手類似的。17、從輸入網(wǎng)址到顯示網(wǎng)頁,經(jīng)過哪些步驟1、瀏覽器查詢域名對應(yīng)的IP地址 2、獲取到IP地址后,就開始建立客戶端和服務(wù)器的TCP連接,首先判斷是不是https的,如果是,則HTTPS其實是HTTP+SSL/TLS兩部分組成,也就是在HTTP上又加了一層處理加密信息的模塊。HTTP協(xié)議是三次握手的過程,https協(xié)議則在三次握手的基礎(chǔ)上還有SSL握手過程。3、建立好TCP連接后,開始發(fā)送HTTP請求。4、服務(wù)端處理后,返回HTTP響應(yīng)。5、當(dāng)http響應(yīng)返回完畢后,TCP并沒有斷開,HTTP/1.1中,Connection:keep-alive是默認(rèn)啟用的,表示持久連接。在反向代理軟件Nginx中,持久連接超時時間默認(rèn)值為75秒,如果75秒內(nèi)沒有新到達(dá)的請求,則斷開與客戶端的連接。同時,瀏覽器每隔45秒會向服務(wù)器發(fā)送TCPkeep-alive探測包,來判斷TCP連接狀況,如果沒有收到ACK應(yīng)答,則主動斷開與服務(wù)器的連接。6、斷開TCP連接,四次揮手。7、瀏覽器渲染頁面二、緩存1、與緩存相關(guān)的報文頭部Expires:服務(wù)端返回的數(shù)據(jù)到期時間,時間是GMT格式的標(biāo)準(zhǔn)時間,如Fri,01Jan199000:00:00GMT。Cache-Control:有很多屬性,不同的屬性代表的意義也不同。private:客戶端可以緩存public:客戶端和代理服務(wù)器都可以緩存max-age=t:緩存內(nèi)容將在t秒后失效no-cache:需要使用協(xié)商緩存來驗證緩存數(shù)據(jù)no-store:所有內(nèi)容都不會緩存。Cache-Contro優(yōu)先級高于ExpiresLast-Modified:資源最近修改時間,由服務(wù)器告訴瀏覽器。if-Modified-Since:從xxx時間開始,是否被修改過,由瀏覽器告訴服務(wù)器。if-Unmodified-Since:從xxx時間開始,是否沒有被修改過,由瀏覽器告訴服務(wù)器。Etag:資源標(biāo)識,由服務(wù)器告訴瀏覽器。If-None-Match:緩存資源標(biāo)識,由瀏覽器告訴服務(wù)器。Etag和If-None-Match的作用:復(fù)制代碼2、Last-Modified和Etag的作用和區(qū)別通過If-None-Match請求頭帶上了之前服務(wù)端返回的Etag的值。服務(wù)端收到第二次請求的時候,發(fā)現(xiàn)攜帶了If-None-Match字段,就重新計算服務(wù)器對應(yīng)資源的Etag,如果二者匹配了,就認(rèn)為資源沒有發(fā)生變化,直接給客戶端相應(yīng)304,讓客戶端讀取緩存中的數(shù)據(jù)Last-Modified先出現(xiàn),但是在使用過程中發(fā)現(xiàn)了一個問題:有時候,資源雖然更新了,但是最后更新時間沒有改變,導(dǎo)致客戶端獲取不到最新的數(shù)據(jù)。所以后來發(fā)明了Etag,直接來判斷文件是否有變化。3、緩存的過程1、瀏覽器請求a.js。2、服務(wù)器返回a.js,同時告訴瀏覽器過期絕對時間(Expires)以及相對時間(Cache-Control:max-age=10),以及a.js上次修改時間Last-Modified,以及a.js的Etag。3、Cache-Contro優(yōu)先級高于Expires。10秒內(nèi)瀏覽器再次請求a.js,不再請求服務(wù)器,直接使用本地緩存。4、11秒時,瀏覽器再次請求a.js,請求服務(wù)器,報文中帶上If-Modified-Since (對應(yīng)Last-Modified)和If-None-Match(對應(yīng)Etag)。5、服務(wù)器收到瀏覽器的If-Modified-Since和If-None-Match,發(fā)現(xiàn)有If-None-Match,則比較If-None-Match和a.js的Etag值,忽略If-Modified-Since的比較。6、a.js文件內(nèi)容沒變化,則Etag和If-None-Match一致,服務(wù)器告訴瀏覽器繼續(xù)使用本地緩存(304)。如此往復(fù)。三、網(wǎng)絡(luò)安全1、前端常見的攻擊XSS、CSRFXSS攻擊的原理是,攻擊者通過注入某些代碼,來執(zhí)行某些惡意操作。比如,用戶再輸入框里輸入一些html的代碼,網(wǎng)頁展示的時候,網(wǎng)頁本身的代碼和用戶輸入的html代碼混在一起,導(dǎo)致瀏覽器執(zhí)行了用戶輸入的惡意代碼。1、所有用戶輸入的地方都不安全2、所有展示用戶輸入的地方都不安全3、js里不要用eval4、不要用innerHTMLCSRF攻擊的原理是,攻擊者構(gòu)造網(wǎng)站后臺某個功能接口的請求地址,誘導(dǎo)用戶去點擊或者用特殊方法讓該請求地址自動加載。用戶在登錄狀態(tài)下這個請求被服務(wù)端接收后會被誤以為是用戶合法的操作。四、跨域1、什么是跨域前端通常說的跨域是指狹義的跨域,是指因為瀏覽器同源策略引起的一種限制訪問場景。2、什么是同源策略瀏覽器為了安全(防止XSS等攻擊),瀏覽器會限制從腳本內(nèi)發(fā)起的跨源HTTP請求。跨源即不同協(xié)議、域名(子域不同也不行)、端口。瀏覽器并不是拒絕所有的跨域請求,通常瀏覽器允許進(jìn)行跨域?qū)懖僮骱唾Y源嵌入操作,如鏈接,重定向,img、css、script標(biāo)簽。而不允許通過腳本發(fā)起的跨域操作:如ajax或fetch請求,并且瀏覽器會限制不同源的Cookie、LocalStorage的讀??;不同源的DOM和JS對象也無法獲取。3、為什么我們需要跨域的需求工程服務(wù)化后,不同職責(zé)的服務(wù)分散在不同的工程中,往往這些工程的域名是不同的,但一個需求可能需要對應(yīng)到多個服務(wù),這時便需要調(diào)用不同服務(wù)的接口,因此會出現(xiàn)跨域。4、跨域的常用解決策略1、jsonpjsonp的核心就是利用script標(biāo)簽請求不同源的資源這一特性。而我們可以將我們想要的資源通過js代碼的形式返回給我們,即返回一段js代碼,是調(diào)用我們本地的一個函數(shù),我們想要的數(shù)據(jù)通過參數(shù)傳遞過來,這樣我們就可以在本地的函數(shù)里獲取到這些數(shù)據(jù)了。jsonp只支持GET請求jq里jsonp的簡單實現(xiàn)functionjsonp({url,jsonp,data,success,error}){var_script=document.createElement('script')varhead=document.getElementsByTagName('head')[0]window[jsonp]=function(arg){head.removeChild(script)if(arg.isSuccess==true){success(arg)}else{error(arg)}window[jsonp]=null}_script.src=url+format(data)head.appendChild(script)functionformat(params){letarr=[]for(letiteminparams){arr.push('${item}=params[item]')}returnarr.join('&')}}復(fù)制代碼2、CORSCORS(Cross-originresourcesharing )跨域資源共享,一種跨域技術(shù),它使用額外的HTTP頭來告訴瀏覽器讓W(xué)eb應(yīng)用被準(zhǔn)許訪問來自不同源服務(wù)器上的指定的資源。所以,同源策略是瀏覽器的限制,而CORS技術(shù)就是通過一些http頭部字段,讓瀏覽器允許跨域!跨域請求可以分為兩種,瀏覽器針對這兩種請求的處理方式是不一樣的:1)簡單請求,滿足以下所有條件:-請求方法是以下三種方法之一:GET、HEAD、POST-請求頭的Content-Type的值是下列三者之一:text/plain(純文本)、multipart/form-data(表單數(shù)據(jù))、application/x-www-form-urlencoded跨域請求或者是post請求時,請求頭中會包含Origin字段,它用于表示請求的來源頁面,和referer的區(qū)別在于它沒有路徑,只有協(xié)議、域名和端口。服務(wù)器端收到簡單請求后,會檢測請求頭中的Origin字段,如果服務(wù)器端判斷可以訪問,則在響應(yīng)頭中加入Access-Control-Allow-Origin字段。當(dāng)其值為*或者時與Origin相同時,表示可以訪問外域資源,瀏覽器就會把響應(yīng)報文顯示出來。否則會爆出一個錯誤。2)復(fù)雜請求:滿足以下任意條件:-使用了下面任一HTTP方法:PUT、DELETE、CONNECT、OPTIONS、TRACE、PATCH-Content-Type的彳直不屬于下列之一:application/x-www-form-urlencoded、multipart/form-data、text/plain-人為設(shè)置了對CORS安全的首部字段集合之外的其他首部字段,即頭部字段超出了以下范圍。該集合為:Accept、Accept-Language、Content-Language、Content-Type(需要注意額外的限制)、DPR、Downlink、Save-Data、Viewport-Width、Width瀏覽器在檢測到跨域請求為復(fù)雜請求時,就會自動先發(fā)送一次預(yù)檢請求,該請求的方法為option方法,請求頭部會包含兩個字段:Origin:http://foo.example<!--用來告訴服務(wù)器,實際的請求將會采用什么方法-->Access-Control-Request-Method:POST<!--告知服務(wù)器,實際請求,頭部會攜帶哪些自定義的字段-->Access-Control-Request-Headers:X-PINGOTHER,Content-Type復(fù)制代碼服務(wù)器則會判斷是否允許請求。如果允許請求,返回的響應(yīng)頭中會包含以下字段://允許來自http://foo.example的訪問Access-Control-Allow-Origin:http://foo.example<!--允許的請求方法-->Access-Control-Allow-Methods:POST,GET,OPTIONS<!--允許的自定義頭-->Access-Control-Allow-Headers:X-PINGOTHER,Content-Type<!--該響應(yīng)的有效時間為86400秒,在有效時間內(nèi),瀏覽器無須為同一請求再次發(fā)起預(yù)檢請求-->Access-Control-Max-Age: 86400復(fù)制代碼3)關(guān)于跨域時的cookie將XMLHttpRequest的withCredentials標(biāo)志設(shè)置為true,從而向服務(wù)器發(fā)送Cookies。但是,服務(wù)端響應(yīng)頭必須包含Access-Control-Allow-Credentials:true,否則瀏覽器將不會將響應(yīng)內(nèi)容發(fā)送給請求者,如果要發(fā)送Cookie,Access-Control-Allow-Origin就不能設(shè)為星號,必須指定明確的、與請求網(wǎng)頁一致的域名。總結(jié)關(guān)于跨域的http字段:請求頭部字段:Origin:<origin>//表明預(yù)檢請求或?qū)嶋H請求的源站。Access-Control-Request-Method:<method>〃將實際請求所使用的HTTP方法告訴服務(wù)器。Access-Control-Request-Headers:<field-name>[,<field-name>]*〃將實際請求所攜帶的首部字段告訴服務(wù)器。復(fù)制代碼響應(yīng)頭部字段:Access-Control-Allow-Origin:<origin>|*Access-Control-Expose-Headers:X-My-Custom-Header,X-Another-Custom-HeaderAccess-Control-Max-Age:<delta-seconds>Access-Control-Allow-Credentials: trueAccess-Control-Allow-Methods:<method>[,<method>]*Access-Control-Allow-Headers:<field-name>[,<field-name>]*

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論