前端網(wǎng)絡知識點總結

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