前端網(wǎng)絡(luò)知識(shí)點(diǎn)總結(jié)

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