HTTP(Hyper Text Transfer Protocol)<超文本傳輸協(xié)議>的縮寫.是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議.HTTP是一個(gè)應(yīng)用層協(xié)議,由請(qǐng)求和響應(yīng)構(gòu)成,是一個(gè)標(biāo)準(zhǔn)的個(gè)客戶端和服務(wù)器模型

1. http協(xié)議發(fā)展史

HTTP/0.9
HTTP 于 1990 年問世秆吵。那時(shí)的 HTTP 并沒有作為正式的標(biāo)準(zhǔn)被建立≌⒉停現(xiàn)在的 HTTP 其實(shí)含有 HTTP1.0 之前 版本的意思蔬芥，因此被稱為 HTTP/0.9休吠。

該版本只有一個(gè)命令GET粟耻，沒有header等描述數(shù)據(jù)的信息隅肥，服務(wù)器只能回應(yīng)HTML格式的字符串，不能回應(yīng)別的格式椿肩。服務(wù)器發(fā)送完畢，就關(guān)閉tcp連接豺谈。

HTTP/1.0
HTTP 正式作為標(biāo)準(zhǔn)被公布是在 1996 年的 5 月郑象，版本被命名為 HTTP/1.0，并記載于 RFC1945茬末。

首先厂榛，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字丽惭，還能傳輸圖像击奶、視頻、二進(jìn)制文件责掏。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)正歼。
其次，除了GET命令拷橘，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動(dòng)手段喜爷。
再次冗疮，HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分檩帐，每次通信都必須包括頭信息（HTTP header）术幔，用來描述一些元數(shù)據(jù)。
其他的新增功能還包括狀態(tài)碼（status code）湃密、多字符集支持诅挑、多部分發(fā)送（multi-part type）、權(quán)限（authorization）泛源、緩存（cache）拔妥、內(nèi)容編碼（content encoding）等。

HTTP/1.0 版的主要缺點(diǎn)是达箍，每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求没龙。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉缎玫，如果還要請(qǐng)求其他資源硬纤，就必須再新建一個(gè)連接。TCP連接的新建成本很高赃磨，因?yàn)樾枰蛻舳撕头?wù)器三次握手筝家，并且開始時(shí)發(fā)送速率較慢（slow start）。所以邻辉，HTTP 1.0版本的性能比較差溪王。隨著網(wǎng)頁(yè)加載的外部資源越來越多腮鞍，這個(gè)問題就愈發(fā)突出了。
為了解決這個(gè)問題在扰，有些瀏覽器在請(qǐng)求時(shí)缕减，用了一個(gè)非標(biāo)準(zhǔn)的Connection字段。這個(gè)字段要求服務(wù)器不要關(guān)閉TCP連接芒珠，以便其他請(qǐng)求復(fù)用桥狡。服務(wù)器同樣回應(yīng)這個(gè)字段。Connection: keep-alive一個(gè)可以復(fù)用的TCP連接就建立了皱卓，直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接裹芝。但是，這不是標(biāo)準(zhǔn)字段娜汁，不同實(shí)現(xiàn)的行為可能不一致嫂易，因此不是根本的解決辦法。

HTTP/1.1
1997 年 1 月公布的 HTTP/1.1, 比1.0版本晚了半年掐禁，它進(jìn)一步完善了HTTP協(xié)議怜械，是目前主流的 HTTP 協(xié)議版本。

1.1 版增加了請(qǐng)求命令（OPTIONS傅事、PUT缕允、PATCH、DELETE蹭越、TRACE障本、CONNECTION∠炀椋客戶端請(qǐng)求的頭信息新增了Host字段驾霜，用來指定服務(wù)器的域名。
1.1 版的最大變化买置，就是引入了持久連接（persistent connection）粪糙，即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用忿项，不用聲明Connection: keep-alive猜旬。
客戶端和服務(wù)器發(fā)現(xiàn)對(duì)方一段時(shí)間沒有活動(dòng)，就可以主動(dòng)關(guān)閉連接倦卖。不過洒擦，規(guī)范的做法是，客戶端在最后一個(gè)請(qǐng)求時(shí)怕膛，發(fā)送Connection: close熟嫩，明確要求服務(wù)器關(guān)閉TCP連接。
目前褐捻，對(duì)于同一個(gè)域名掸茅，大多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接椅邓。

缺點(diǎn): 雖然1.1版允許復(fù)用TCP連接，但是同一個(gè)TCP連接里面昧狮，所有的數(shù)據(jù)通信是按次序進(jìn)行的景馁。服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)逗鸣。要是前面的回應(yīng)特別慢合住，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。這稱為隊(duì)頭堵塞撒璧。
為了避免這個(gè)問題透葛，只有兩種方法：一是減少請(qǐng)求數(shù)，二是同時(shí)多開持久連接卿樱。這導(dǎo)致了很多的網(wǎng)頁(yè)優(yōu)化技巧僚害，比如合并腳本和樣式表、將圖片嵌入CSS代碼繁调、域名分片（domain sharding）等等萨蚕。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的蹄胰。

HTTP/2.0
HTTP/2.0版本中所有數(shù)據(jù)以二進(jìn)制（最小數(shù)據(jù)單位是幀）傳輸岳遥，HTTP/1.1中大部分?jǐn)?shù)據(jù)通過字符串的形式；同一個(gè)連接里面發(fā)送多個(gè)請(qǐng)求不再需要按照順序來烤送；頭信息壓縮以及推送等提高效率的功能。 HTTP/2.0 正在制訂中糠悯，但要達(dá)到 較高的使用覆蓋率帮坚，仍需假以時(shí)日。

2. 網(wǎng)絡(luò)基礎(chǔ)

2.1經(jīng)典五層模型

五層模型_.pic.jpg

• 物理層主要作用是定義物理設(shè)備如何傳輸數(shù)據(jù)互艾，機(jī)器的硬件试和，網(wǎng)卡端口，網(wǎng)線等纫普。
• 數(shù)據(jù)鏈路層在通信的實(shí)體間建立數(shù)據(jù)鏈路連接阅悍，比如最基礎(chǔ)的數(shù)據(jù)傳輸數(shù)據(jù)流，可以自己選擇二進(jìn)制或者ASCII碼形式等昨稼。
• 網(wǎng)絡(luò)層為數(shù)據(jù)在結(jié)點(diǎn)之間傳輸創(chuàng)建邏輯鏈路节视，比如輸入百度，網(wǎng)絡(luò)層會(huì)為我們找到百度的網(wǎng)址假栓，如何尋找到的過程就是網(wǎng)絡(luò)層要做的事寻行。
• 傳輸層: 向用戶提供可靠的端到端（end-to-end）服務(wù)；傳輸層向高層屏蔽了下層數(shù)據(jù)通信的細(xì)節(jié)（比如一個(gè)post請(qǐng)求匾荆，如何分片如何發(fā)送使服務(wù)端很好接收到拌蜘，這個(gè)規(guī)則由傳輸層實(shí)現(xiàn)杆烁，應(yīng)用層的HTTP不用關(guān)心這些，但是適當(dāng)理解對(duì)HTTP更好地使用是很有幫助的）简卧。
• 應(yīng)用層: 為應(yīng)用軟件提供了很多服務(wù)兔魂，幫我們實(shí)現(xiàn)了HTTP協(xié)議，我們只要按照規(guī)則去使用HTTP協(xié)議举娩；它構(gòu)建于TCP協(xié)議之上析校；屏蔽了網(wǎng)絡(luò)傳輸相關(guān)細(xì)節(jié)。

2.2 DNS服務(wù)器的作用

用戶通常使用主機(jī)名稱或者域名來訪問對(duì)方的計(jì)算機(jī)晓铆，因?yàn)楦糜涀∩琢肌５怯?jì)算機(jī)更擅長(zhǎng)處理IP地址這樣的一串?dāng)?shù)字。DNS服務(wù)就是為了解決這個(gè)問題骄噪，DNS協(xié)議通過域名查找IP地址尚困，或者逆向從IP地址查詢域名的服務(wù)。

DNS服務(wù)的作用.png

2.3 TCP

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的链蕊、可靠的事甜、基于字節(jié)流的傳輸層通信協(xié)議。
建立起一個(gè)TCP連接需要經(jīng)過三次握手, 關(guān)閉TCP連接需要經(jīng)過四次揮手滔韵。

3. 三次握手與四次揮手

3.1 三次握手

三次握手.png

1）發(fā)送端首先發(fā)送一個(gè)帶有SYN（synchronize）標(biāo)志地?cái)?shù)據(jù)包給接收方逻谦。
2）接收方接收后，回傳一個(gè)帶有SYN/ACK標(biāo)志的數(shù)據(jù)包傳遞確認(rèn)信息陪蜻，表示我收到了邦马。
3）最后，發(fā)送方再回傳一個(gè)帶有ACK標(biāo)志的數(shù)據(jù)包宴卖，代表我知道了滋将，表示’握手‘結(jié)束。
通俗的說法
1）Client：嘿症昏，李四随闽，是我，聽到了嗎肝谭？
2）Server：我聽到了掘宪，你能聽到我的嗎?
3）Client：好的，我們互相都能聽到對(duì)方的話攘烛，我們的通信可以開始了魏滚。

其中 位碼即tcp標(biāo)志位,有6種標(biāo)示:

• SYN(synchronous建立聯(lián)機(jī))
• ACK(acknowledgement 確認(rèn))
• PSH(push傳送)
• FIN(finish結(jié)束)
• RST(reset重置)
• URG(urgent緊急)
• Sequence number(順序號(hào)碼)
• Acknowledge number(確認(rèn)號(hào)碼)

注：為什么是三次握手
因?yàn)榫W(wǎng)絡(luò)傳輸有延遲，客戶端發(fā)送請(qǐng)求到服務(wù)器端要求即那里連接坟漱，如果服務(wù)器直接返回的話可能會(huì)產(chǎn)生丟包的情況導(dǎo)致客戶端收不到數(shù)據(jù)栏赴，客戶端會(huì)因?yàn)槌瑫r(shí)就關(guān)閉了，可能就去發(fā)送新的請(qǐng)求了，然而服務(wù)器端并不知道丟包導(dǎo)致客戶端沒有接收數(shù)據(jù)须眷。服務(wù)器端t端口就一直開著竖瘾，造成額外的開銷。所以需要三次握手確認(rèn)這個(gè)過程花颗。

3.2. 四次揮手

四次揮手.png

1）第一次揮手：Client發(fā)送一個(gè)FIN捕传，用來關(guān)閉Client到Server的數(shù)據(jù)傳送，Client進(jìn)入FIN_WAIT_1狀態(tài)扩劝。
2）第二次揮手：Server收到FIN后庸论，發(fā)送一個(gè)ACK給Client，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同棒呛，一個(gè)FIN占用一個(gè)序號(hào)）聂示，Server進(jìn)入CLOSE_WAIT狀態(tài)。
3）第三次揮手：Server發(fā)送一個(gè)FIN簇秒，用來關(guān)閉Server到Client的數(shù)據(jù)傳送鱼喉，Server進(jìn)入LAST_ACK狀態(tài)。
4）第四次揮手：Client收到FIN后趋观，Client進(jìn)入TIME_WAIT狀態(tài)扛禽，接著發(fā)送一個(gè)ACK給Server，確認(rèn)序號(hào)為收到序號(hào)+1皱坛，Server進(jìn)入CLOSED狀態(tài)编曼，完成四次揮手
通俗的說法
1）Client：我所有東西都說完了。
2）Server：我已經(jīng)全部聽到了剩辟，但是等等我掐场，我還沒說完。
3）Server：好了贩猎，我已經(jīng)說完了熊户。
4）Client：好的硝拧，那我們的通信結(jié)束憋飞。

注：TCP為什么要進(jìn)行四次揮手
4次揮手的目的是終止數(shù)據(jù)傳輸，并回收資源，此時(shí)兩個(gè)端點(diǎn)兩個(gè)方向的序列號(hào)已經(jīng)沒有了任何關(guān)系噪馏，必須等待兩方向都沒有數(shù)據(jù)傳輸時(shí)才能拆除虛鏈路，不像初始化時(shí)那么簡(jiǎn)單绿饵，發(fā)現(xiàn)SYN標(biāo)志就初始化一個(gè)序列號(hào)并確認(rèn)SYN的序列號(hào)欠肾。因此必須單獨(dú)分別在一個(gè)方向上終止該方向的數(shù)據(jù)傳輸。

4. HTTP工作過程

一次HTTP操作稱為一個(gè)事務(wù)拟赊，其工作整個(gè)過程如下：
1 ) 地址解析如用客戶端瀏覽器請(qǐng)求這個(gè)頁(yè)面：http://localhost.com:8080/index.html
從中分解出協(xié)議名刺桃、主機(jī)名、端口吸祟、對(duì)象路徑等部分瑟慈，對(duì)于我們的這個(gè)地址桃移，解析得到的結(jié)果如下：
協(xié)議名：http
主機(jī)名：localhost.com
端口：8080
對(duì)象路徑：/index.htm
在這一步，需要域名系統(tǒng)DNS解析域名localhost.com,得主機(jī)的IP地址葛碧。
2）封裝HTTP請(qǐng)求數(shù)據(jù)包
把以上部分結(jié)合本機(jī)自己的信息借杰，封裝成一個(gè)HTTP請(qǐng)求數(shù)據(jù)包
3）封裝成TCP包，建立TCP連接（TCP的三次握手）
在HTTP工作開始之前进泼，客戶機(jī)（Web瀏覽器）首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接蔗衡，該連接是通過TCP來完成的，該協(xié)議與IP協(xié)議共同構(gòu)建Internet乳绕，即著名的TCP/IP協(xié)議族绞惦，因此Internet又被稱作是TCP/IP網(wǎng)絡(luò)。HTTP是比TCP更高層次的應(yīng)用層協(xié)議洋措，根據(jù)規(guī)則济蝉，只有低層協(xié)議建立之后才能進(jìn)行更高層協(xié)議的連接，因此呻纹，首先要建立TCP連接堆生，一般TCP連接的端口號(hào)是80。這里是8080端口
4）客戶機(jī)發(fā)送請(qǐng)求命令
建立連接后雷酪，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器淑仆，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URI：Uniform Resource Identifier）、協(xié)議版本號(hào)哥力，后邊是MIME信息包括請(qǐng)求修飾符蔗怠、客戶機(jī)信息和可能的內(nèi)容。
5）服務(wù)器響應(yīng)
服務(wù)器接到請(qǐng)求后吩跋，給予相應(yīng)的響應(yīng)信息寞射，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)锌钮、一個(gè)成功或錯(cuò)誤的代碼桥温，后邊是MIME信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容梁丘。
實(shí)體消息是服務(wù)器向?yàn)g覽器發(fā)送頭信息后侵浸，它會(huì)發(fā)送一個(gè)空白行來表示頭信息的發(fā)送到此結(jié)束，接著氛谜，它就以Content-Type應(yīng)答頭信息所描述的格式發(fā)送用戶所請(qǐng)求的實(shí)際數(shù)據(jù)
6）服務(wù)器關(guān)閉TCP連接
一般情況下掏觉，一旦Web服務(wù)器向?yàn)g覽器發(fā)送了請(qǐng)求數(shù)據(jù)，它就要關(guān)閉TCP連接值漫，然后如果瀏覽器或者服務(wù)器在其頭信息加入了這行代碼Connection:keep-alive
TCP連接在發(fā)送后將仍然保持打開狀態(tài)澳腹，于是，瀏覽器可以繼續(xù)通過相同的連接發(fā)送請(qǐng)求。保持連接節(jié)省了為每個(gè)請(qǐng)求建立新連接所需的時(shí)間酱塔，還節(jié)約了網(wǎng)絡(luò)帶寬沥邻。

經(jīng)典面試題【從輸入U(xiǎn)RL到頁(yè)面加載發(fā)生了什么？】

• DNS解析：如果地址包含域名通過DNS解析獲取服務(wù)器對(duì)應(yīng)的ip地址羊娃，如果輸入的URL不包含域名則不經(jīng)過這一步谋国。
• TCP連接 : 經(jīng)過DNS解析后獲取到了服務(wù)器的IP地址，在獲取到IP地址后迁沫，便會(huì)開始建立一次連接(三次握手)芦瘾。
• 發(fā)送HTTP請(qǐng)求: 在確認(rèn)與服務(wù)器建立連接后，便會(huì)發(fā)送一個(gè)HTTP請(qǐng)求集畅。
• 服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文: 服務(wù)器在收到瀏覽器發(fā)送的HTTP請(qǐng)求之后近弟，會(huì)將收到的HTTP報(bào)文封裝成HTTP的Request對(duì)象，并通過不同的Web服務(wù)器進(jìn)行處理挺智，處理完的結(jié)果以HTTP的Response對(duì)象返回祷愉，主要包括狀態(tài)碼，響應(yīng)頭赦颇，響應(yīng)報(bào)文三個(gè)部分二鳄。
• 瀏覽器解析渲染頁(yè)面
• 連接結(jié)束: 在頁(yè)面元素傳輸完成后，會(huì)選擇關(guān)閉連接(TCP四次揮手)媒怯。

5. http報(bào)文

報(bào)文(message)
報(bào)文是網(wǎng)絡(luò)中交換與傳輸?shù)臄?shù)據(jù)單元订讼，也是網(wǎng)絡(luò)傳輸?shù)膯卧?bào)文包含了將要發(fā)送的完整的數(shù)據(jù)信息扇苞，其長(zhǎng)短不需一致欺殿。報(bào)文在傳輸過程中會(huì)不斷地封裝成分組、包鳖敷、幀來傳輸脖苏，封裝的方式就是添加一些控制信息組成的首部，那些就是報(bào)文頭定踱。

http有兩種報(bào)文

• 請(qǐng)求報(bào)文： 請(qǐng)求行棍潘、首部字段、報(bào)文主體（請(qǐng)求正文）
• 響應(yīng)報(bào)文：狀態(tài)行崖媚、首部字段亦歉、報(bào)文主體（響應(yīng)正文）

請(qǐng)求行（HTTP請(qǐng)求報(bào)文的第一行）
請(qǐng)求行由方法字段、URL字段和HTTP協(xié)議版本字段至扰。其中鳍徽，方法字段嚴(yán)格區(qū)分大小寫资锰，當(dāng)前HTTP協(xié)議中的方法都是大寫敢课。

• 方法字段如下介紹如下（請(qǐng)求方法用來定義隊(duì)對(duì)資源的操作）
  1）GET:請(qǐng)求獲取Request-URI(URI:通用資源標(biāo)識(shí)符,URL是其子集，URI注重的是標(biāo)識(shí)，而URL強(qiáng)調(diào)的是位置直秆，可以將URL看成原始的URI),所標(biāo)識(shí)的資源
  2）POST：在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)濒募；支持HTML表單提交，表單中有用戶添入的數(shù)據(jù)圾结，這些數(shù)據(jù)會(huì)發(fā)送到服務(wù)器端瑰剃，由服務(wù)器存儲(chǔ)至某位置（例如發(fā)送處理程序）
  3）HEAD:請(qǐng)求Request-URI所標(biāo)識(shí)的資源響應(yīng)消息報(bào)頭，HEAD方法可以在響應(yīng)時(shí)不返回消息體筝野。
  4）PUT：與GET相反晌姚，請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源，并用Request-URI做為其標(biāo)識(shí)歇竟；例如發(fā)布系統(tǒng)挥唠。
  5）DELETE：請(qǐng)求刪除URL指向的資源
  6）OPTIONS：請(qǐng)求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)
  7）TRACE：跟蹤請(qǐng)求要經(jīng)過的防火墻焕议、代理或網(wǎng)關(guān)等宝磨，主要用于測(cè)試或診斷
  8）CONNECT保留將來使用

狀態(tài)行 HTTP響應(yīng)報(bào)文的第一行
狀態(tài)行包括三個(gè)字段：協(xié)議版本、狀態(tài)碼與原因短語

• 狀態(tài)碼
  狀態(tài)碼由三位數(shù)字組成盅安，第一個(gè)數(shù)字定義了響應(yīng)的類別唤锉， 且由5種取值：
  1）1xx: 指示消息--表示已接收，繼續(xù)處理
  2）2xx: 成功--表示請(qǐng)求已被成功接收别瞭、理解窿祥、接收
  3）3xx: 重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
  4）4xx: 客戶端錯(cuò)誤--請(qǐng)求有語法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)
  5）5xx：服務(wù)器端錯(cuò)誤--服務(wù)器端未能實(shí)現(xiàn)合法的請(qǐng)求

6. 跨域

1.?什么是跨域
????瀏覽器的同源策略限制了跨域請(qǐng)求資源。即當(dāng)一個(gè)請(qǐng)求url的協(xié)議蝙寨、域名壁肋、端口三者之間任意一與當(dāng)前頁(yè)面地址不同即為跨域。

2.?實(shí)現(xiàn)跨域的常用方法
(1) ? jsonp （JSON+Padding）將JSON數(shù)據(jù)填充進(jìn)回調(diào)函數(shù)
jsonp 是解決跨域問題的一種方案籽慢，不同于 json浸遗，其并不是一種數(shù)據(jù)交換格式，而只是一種繞過跨域的技巧箱亿。
簡(jiǎn)單來說就是創(chuàng)建一個(gè)回調(diào)函數(shù)跛锌，然后在遠(yuǎn)程服務(wù)上調(diào)用這個(gè)函數(shù)并且將JSON 數(shù)據(jù)形式作為參數(shù)傳遞，完成回調(diào)届惋。 因?yàn)樵贖TML標(biāo)簽里髓帽，一些標(biāo)簽比如script、img脑豹、iframe這樣的擁有src屬性獲取資源的標(biāo)簽是沒有跨域限制的郑藏。因此利用script加載預(yù)設(shè)的 callback 將內(nèi)容傳遞給 js。一般來說我們約定通過一個(gè)參數(shù)來告訴服務(wù)器 JSONP 返回時(shí)應(yīng)該調(diào)用的回調(diào)函數(shù)名瘩欺，然后拼接出對(duì)應(yīng)的 js必盖。以下為一個(gè)簡(jiǎn)單例子拌牲。
html頁(yè)面

<!DOCTYPE html>
<html>
  <head>
    <title></title>
    <script type="text/javascript">
      var infoHandler = function(data){
          console.log(data);
      };
    </script>
    <script type="text/javascript" src="http://a.com/info?name=a&callback=infoHandler"></script>
  </head>
  <body></body>
</html>

服務(wù)器端返回

# 服務(wù)器端通過獲取請(qǐng)求參數(shù)重的callback名稱， 拼出返回值歌粥。
 infoHandler({
  "name": "shirley",
  "age":18,
  "gender": "female",
  "idCard": "23213123231232ui323"
});

缺點(diǎn)是JSONP只能發(fā)GET請(qǐng)求塌忽，因?yàn)楸举|(zhì)上script加載資源就是GET請(qǐng)求

(2) ? CORS
CORS：是一個(gè)W3C標(biāo)準(zhǔn), Cross-origin resource sharing 即 “跨域資源共享”。它允許瀏覽器向跨源服務(wù)器失驶，發(fā)出XMLHttpRequest請(qǐng)求土居，從而克服了AJAX只能同源使用的限制。
CORS需要客戶端和服務(wù)端同時(shí)支持嬉探。目前擦耀，所有瀏覽器都支持該功能，IE瀏覽器不能低于IE10涩堤。整個(gè)CORS通信過程埂奈，都是瀏覽器自動(dòng)完成，不需要用戶參與定躏。因此账磺，實(shí)現(xiàn)CORS通信的關(guān)鍵是服務(wù)器。只要服務(wù)器實(shí)現(xiàn)了CORS接口痊远，就可以跨源通信垮抗。

• CORS請(qǐng)求分類
  瀏覽器將CORS請(qǐng)求分成兩類：請(qǐng)求簡(jiǎn)單請(qǐng)求（simple request）和非簡(jiǎn)單請(qǐng)求（not-so-simple request)。
  簡(jiǎn)單請(qǐng)求： 請(qǐng)求滿足以下兩個(gè)條件的就是簡(jiǎn)單請(qǐng)求
  ?1. 請(qǐng)求方法是以下三種方法之一：HEAD,GET,POST 碧聪。
  ?2. HTTP的頭信息不超出以下幾種字段
  ????Accept
  ????Accept-Language
  ????Content-Language
  ????Last-Event-ID
  ????Content-type：只限于三個(gè)值application/x-www-form-urlencoded冒版、multipart/form-data、text/plain
  非簡(jiǎn)單請(qǐng)求： 不滿足上面兩個(gè)條件的就是非簡(jiǎn)單請(qǐng)求逞姿。
  注意
  1辞嗡、對(duì)于簡(jiǎn)單請(qǐng)求，瀏覽器直接請(qǐng)求滞造，會(huì)在請(qǐng)求頭信息中续室，增加一個(gè)origin字段，來說明本次請(qǐng)求來自哪個(gè)源（協(xié)議+域名+端口）谒养。服務(wù)器根據(jù)這個(gè)值挺狰，來決定是否同意該請(qǐng)求，服務(wù)器返回的響應(yīng)會(huì)多幾個(gè)頭信息字段买窟。
  2丰泊、非簡(jiǎn)單請(qǐng)求是對(duì)那種對(duì)服務(wù)器有特殊要求的請(qǐng)求，都會(huì)在正式通信之前始绍，增加一次HTTP請(qǐng)求瞳购，稱之為預(yù)檢（options請(qǐng)求）。瀏覽器會(huì)先詢問服務(wù)器亏推，當(dāng)前網(wǎng)頁(yè)所在域名是否在服務(wù)器的許可名單之中学赛，服務(wù)器允許之后年堆，瀏覽器會(huì)發(fā)出正式的XMLHttpRequest請(qǐng)求，否則會(huì)報(bào)錯(cuò)罢屈。
  options請(qǐng)求: options請(qǐng)求是瀏覽器自發(fā)起的preflight request(預(yù)檢請(qǐng)求)，獲取響應(yīng)后發(fā)現(xiàn)可以跨域篇亭，接著就發(fā)送真實(shí)的請(qǐng)求缠捌。

• 服務(wù)器端實(shí)現(xiàn)跨域CORS接口

1、設(shè)置Access-Control-Allow-Origin

'Access-Control-Allow-Origin': 'http://XXX.com' // 設(shè)置接指定地址的請(qǐng)求或設(shè)置為'*' 表示接受任意域名的請(qǐng)求

2. 除get译蒂、post曼月、head請(qǐng)求方法和其它自定義的請(qǐng)求頭 即非簡(jiǎn)單請(qǐng)求時(shí)。預(yù)請(qǐng)求驗(yàn)證通過才能發(fā)送柔昼。

'Access-Control-Allow-Methods': 'POST,PUT,HEAD'

'Access-Control-Allow-Headers': 'X-Test-Cors', //設(shè)置自定義的請(qǐng)求頭

設(shè)置緩存, 允許瀏覽器在指定時(shí)間內(nèi)哑芹，無需再發(fā)送預(yù)檢請(qǐng)求，直接用本次結(jié)果即可捕透。

'Access-Control-Max-Age': '5',  //秒為單位 -1是不緩存 5秒一下chrome都默認(rèn)是5

設(shè)置是否可以攜帶cookie

'Access-Control-Allow-Credentials':  true聪姿，//如果Access-Control-Allow-Origin字段設(shè)置* 此字段設(shè)為true無效

(3) nginx反向代理
原理是：同源策略只是瀏覽器的安全策略，不是HTTP協(xié)議的一部分乙嘀。服務(wù)器端調(diào)用HTTP接口只是使用HTTP協(xié)議末购，不會(huì)執(zhí)行JS腳本，不需要同源策略虎谢，也就不存在跨越問題盟榴。

// Nginx配置如下：
 server{    
  # 監(jiān)聽8001端口
  listen 8001;
  # 域名是localhost
  server_name localhost;
  #凡是localhost:8001/api這個(gè)樣子的，都轉(zhuǎn)發(fā)到真正的服務(wù)端地址http://localhost:9001
  location ^~ /api {
      proxy_pass http://localhost:9001;
  } 

7. 首部字段

上面的HTTP報(bào)文介紹了首部字段婴噩。首部字段同時(shí)存在于請(qǐng)求和響應(yīng)報(bào)文內(nèi)擎场，并涵蓋 HTTP 報(bào)文相關(guān)的內(nèi)容信息。使用首部字段是為了給客服端和服務(wù)器端提供報(bào)文主體大小几莽、所使用的語言迅办、認(rèn)證信息等內(nèi)容。

• 首部字段結(jié)構(gòu)
  由首部字段名和字段值章蚣，中間用冒號(hào)分割礼饱。 例如 Content-Type：text/html
  注 : HTTP 報(bào)文首部中出現(xiàn)了兩個(gè)或以上具有相同首部字段名的首部字段時(shí)，這種情況在規(guī)范內(nèi)尚未明確究驴，根據(jù)瀏覽器內(nèi)部處理邏輯的不同镊绪，優(yōu)先處理的順序可能不同，結(jié)果可能并不一致洒忧。

• 首部字段類型
  HTTP 首部字段根據(jù)實(shí)際用途被分為以下 4 種類型：
  1. 通用首部字段（General Header Fields）
  請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部蝴韭。
  2. 請(qǐng)求首部字段（Request Header Fields）
  從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部。補(bǔ)充了請(qǐng)求的附加內(nèi)容熙侍、客戶端信息榄鉴、響應(yīng)內(nèi)容相關(guān)優(yōu)先級(jí)等信息履磨。
  3. 響應(yīng)首部字段（Response Header Fields）
  從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容庆尘，也會(huì)要求客戶端附加額外的內(nèi)容信息剃诅。
  4. 實(shí)體首部字段（Entity Header Fields）
  針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息驶忌。

• 通用首部字段 (HTTP/1.1)
  Cache-Control 控制緩存的行為
  Connection 逐挑首部矛辕、連接的管理
  Date 創(chuàng)建報(bào)文的日期時(shí)間
  Pragma 報(bào)文指令
  Trailer 報(bào)文末端的首部一覽
  Transfer-Encoding 指定報(bào)文主體的傳輸編碼方式
  Upgrade 升級(jí)為其他協(xié)議
  Via 代理服務(wù)器的相關(guān)信息
  Warning 錯(cuò)誤通知

• 請(qǐng)求首部字段
  Accept 用戶代理可處理的媒體類型
  Accept-Charset 優(yōu)先的字符集
  Accept-Encoding 優(yōu)先的內(nèi)容編碼
  Accept-Language 優(yōu)先的語言（自然語言）
  Authorization Web認(rèn)證信息
  Expect 期待服務(wù)器的特定行為
  From 用戶的電子郵箱地址
  Host 請(qǐng)求資源所在服務(wù)器
  If-Match 比較實(shí)體標(biāo)記（ETag）
  If-Modified-Since 比較資源的更新時(shí)間
  If-None-Match 比較實(shí)體標(biāo)記（與 If-Match 相反）
  If-Range 資源未更新時(shí)發(fā)送實(shí)體 Byte 的范圍請(qǐng)求
  If-Unmodified-Since 比較資源的更新時(shí)間（與If-Modified-Since相反）
  Max-Forwards 最大傳輸逐跳數(shù)
  Proxy-Authorization 代理服務(wù)器要求客戶端的認(rèn)證信息
  Range 實(shí)體的字節(jié)范圍請(qǐng)求
  Referer 對(duì)請(qǐng)求中 URI 的原始獲取方
  TE 傳輸編碼的優(yōu)先級(jí)
  User-Agent HTTP 客戶端程序的信息

• 響應(yīng)首部字段
  Accept-Ranges 是否接受字節(jié)范圍請(qǐng)求
  Age 推算資源創(chuàng)建經(jīng)過時(shí)間
  ETag 資源的匹配信息
  Location 令客戶端重定向至指定URI
  Proxy-Authenticate 代理服務(wù)器對(duì)客戶端的認(rèn)證信息
  Retry-After 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求
  Server HTTP 服務(wù)器的安裝信息
  Vary 代理服務(wù)器緩存的管理信息
  WWW-Authenticate 服務(wù)器對(duì)客戶端的認(rèn)證信息

• 實(shí)體首部字段
  Allow 資源可支持的HTTP方法
  Content-Encoding 實(shí)體主體適用的編碼方式
  Content-Language 實(shí)體主體的自然語言
  Content-Length 實(shí)體主體的大小（單位：字節(jié)）
  Content-Location 替代對(duì)應(yīng)資源的URI
  Content-MD5 實(shí)體主體的報(bào)文摘要
  Content-Range 實(shí)體主體的位置范圍
  Content-Type 實(shí)體主體的媒體類型
  Expires 實(shí)體主體過期的日期時(shí)間
  Last-Modified 資源的最后修改日期時(shí)間

7.1 Cache-Control

通過指定首部字段 Cache-Control 的指令付魔，就能操作緩存的工作機(jī)制聊品。指令的參數(shù)是可選的，多個(gè)指令之間通過“,”分隔几苍。比如： Cache-Control: private, max-age=0, no-cache?翻屈。

• 緩存請(qǐng)求指令

  
  
  緩存請(qǐng)求指令.png

• 緩存響應(yīng)指令

  
  
  緩存響應(yīng)指令.png

Pragma和Expires也與緩存相關(guān)，Pragma是舊產(chǎn)物妻坝，已經(jīng)逐步拋棄伸眶，有些網(wǎng)站為了向下兼容還保留了這兩個(gè)字段。優(yōu)先級(jí)從高到低是:Pragma -> Cache-Control -> Expires

Cache-Control除了在響應(yīng)中使用刽宪，在請(qǐng)求中也可以使用赚抡。我們用開發(fā)者工具來模擬下請(qǐng)求時(shí)帶上Cache-Control：勾選Disable cache，刷新頁(yè)面纠屋，可以看到Request Headers中有個(gè)字段Cache-Control: no-cache涂臣。

7.2 Connection

Connection 首部字段具備以下兩個(gè)作用：

1. 控制不再轉(zhuǎn)發(fā)的首部字段
   Connection: Upgrade
   在客戶端發(fā)送請(qǐng)求和服務(wù)器返回響應(yīng)中，使用 Connection 首部字段售担，可控制不再轉(zhuǎn)發(fā)給代理的首部字段赁遗，即刪除后再轉(zhuǎn)發(fā)（即Hop-by-hop首部）。

   
   
   747969-20170217214935269-1562584482.png
2. 管理持久連接

• Connection: close
  HTTP/1.1 版本的默認(rèn)連接都是持久連接族铆。當(dāng)服務(wù)器端想明確斷開連接時(shí)岩四，則指定 Connection 首部字段的值為 close。
• Connection: Keep-Alive
  HTTP/1.1 之前的 HTTP 版本的默認(rèn)連接都是非持久連接哥攘。為此剖煌，如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定 Connection 首部字段的值為 Keep-Alive逝淹。

7.3 Date

Date 表明創(chuàng)建 HTTP 報(bào)文的日期和時(shí)間

7.4 Accept

Accept: text/html, application/xhtml+xml, application/xml; q=0.5

• Accept 首部字段可通知服務(wù)器耕姊，用戶代理能夠處理的媒體類型及媒體類型的相對(duì)優(yōu)先級(jí)≌て希可使用 type/subtype 這種形式茉兰，一次指定多種媒體類型。
• 若想要給顯示的媒體類型增加優(yōu)先級(jí)欣簇，則使用 q=[數(shù)值] 來表示權(quán)重值规脸，用分號(hào)（;）進(jìn)行分隔坯约。權(quán)重值的范圍 0~1（可精確到小數(shù)點(diǎn)后三位），且 1 為最大值莫鸭。不指定權(quán)重值時(shí)闹丐，默認(rèn)為 1。當(dāng)服務(wù)器提供多種內(nèi)容時(shí)被因，將會(huì)首先返回權(quán)重值最高的媒體類型卿拴。

7.5 Accept-Encoding

Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先順序，并可一次性指定多種內(nèi)容編碼氏身。同樣使用 q=[數(shù)值] 來表示相對(duì)優(yōu)先級(jí)巍棱。也可使用星號(hào)（*）作為通配符惑畴，指定任意的編碼格式蛋欣。

7.6 Accept-Language

Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3
告知服務(wù)器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對(duì)優(yōu)先級(jí)如贷，可一次性指定多種自然語言集陷虎。同樣使用 q=[數(shù)值] 來表示相對(duì)優(yōu)先級(jí)。

7.7 Host

Host: localhost:8001?
首部字段 Host 會(huì)告知服務(wù)器杠袱，請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)尚猿。Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個(gè)必須被包含在請(qǐng)求內(nèi)的首部字段。
首部字段 Host 和以單臺(tái)服務(wù)器分配多個(gè)域名的虛擬主機(jī)的工作機(jī)制有很密切的關(guān)聯(lián)楣富，這是首部字段 Host 必須存在的意義

7.8 User-AgentUser-Agent

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36

• 首部字段 User-Agent 會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器凿掂。
• 由網(wǎng)絡(luò)爬蟲發(fā)起請(qǐng)求時(shí)，有可能會(huì)在字段內(nèi)添加爬蟲作者的電子郵件地址纹蝴。此外庄萎，如果請(qǐng)求經(jīng)過代理，那么中間也很可能被添加上代理服務(wù)器的名稱塘安。

7.9 Allow

Allow: GET, HEAD

• 首部字段 Allow 用于通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法糠涛。
• 當(dāng)服務(wù)器接收到不支持的 HTTP 方法時(shí)，會(huì)以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回兼犯。與此同時(shí)忍捡，還會(huì)把所有能支持的 HTTP 方法寫入首部字段 Allow 后返回。

7.10 Content-Encoding

Content-Encoding: gzip

• 首部字段 Content-Encoding 會(huì)告知客戶端服務(wù)器對(duì)實(shí)體的主體部分選用的內(nèi)容編碼方式切黔。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮砸脊。
• 主要采用這 4 種內(nèi)容編碼的方式（gzip、compress纬霞、deflate脓规、identity）。

7.11 Content-Language

Content-Language: zh-CN
首部字段 Content-Language 會(huì)告知客戶端险领，實(shí)體主體使用的自然語言（指中文或英文等語言）侨舆。

7.12 Content-Type

Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實(shí)體主體內(nèi)對(duì)象的媒體類型秒紧。和首部字段 Accept 一樣，字段值用 type/subtype 形式賦值挨下。參數(shù) charset 使用 iso-8859-1 或 euc-jp 等字符集進(jìn)行賦值熔恢。

7.13 Expires

Expires: Mon, 10 Jul 2017 15:50:06 GMT

• 首部字段 Expires 會(huì)將資源失效的日期告知客戶端。
• 緩存服務(wù)器在接收到含有首部字段 Expires 的響應(yīng)后臭笆，會(huì)以緩存來應(yīng)答請(qǐng)求叙淌，在 Expires 字段值指定的時(shí)間之前，響應(yīng)的副本會(huì)一直被保存愁铺。當(dāng)超過指定的時(shí)間后鹰霍，緩存服務(wù)器在請(qǐng)求發(fā)送過來時(shí)，會(huì)轉(zhuǎn)向源服務(wù)器請(qǐng)求資源茵乱。
• 源服務(wù)器不希望緩存服務(wù)器對(duì)資源緩存時(shí)茂洒，最好在 Expires 字段內(nèi)寫入與首部字段 Date 相同的時(shí)間值。

7.14 Cookie

服務(wù)器在響應(yīng)頭中用Set-Cookie頭將Cookie的內(nèi)容回送給客戶端瓶竭，客戶端在新的請(qǐng)求中將相同的內(nèi)容攜帶在cookie頭中發(fā)送給服務(wù)器督勺，從而實(shí)現(xiàn)會(huì)話的保持。

• 響應(yīng)首部字段
  setCookie: name=aaa; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/
  屬性 ????????????????????說明
  NAME=VALUE????賦予 Cookie 的名稱和其值（必需項(xiàng)）
  expires=DATE????Cookie 的有效期（若不明確指定則默認(rèn)為瀏覽器關(guān)閉前為止）
  path=PATH?????????將服務(wù)器上的文件目錄作為Cookie的適用對(duì)象（若不指定則默認(rèn)為文檔所在的文件目錄）
  domain=域名???????作為 Cookie 適用對(duì)象的域名 （若不指定則默認(rèn)為創(chuàng)建 Cookie的服務(wù)器的域名）
  Secure?????????????????僅在 HTTPS 安全通信時(shí)才會(huì)發(fā)送 Cookie
  HttpOnly??????????????加以限制斤贰，使 Cookie 不能被 JavaScript 腳本訪問
• 請(qǐng)求首部字段 Cookie
  Cookie: status=enable

首部字段 Cookie 會(huì)告知服務(wù)器智哀，當(dāng)客戶端想獲得 HTTP 狀態(tài)管理支持時(shí)，就會(huì)在請(qǐng)求中包含從服務(wù)器接收到的 Cookie荧恍。接收到多個(gè) Cookie 時(shí)瓷叫，同樣可以以多個(gè) Cookie 形式發(fā)送。

7.15 CSP(content-security-policy)內(nèi)容安全策略

實(shí)質(zhì)是建立報(bào)名單制度送巡，明確的告訴客戶端摹菠，哪些外部資源可以加載和執(zhí)行。所以使用 CSP 來防止 XSS攻擊(跨域腳本攻擊)授艰。

Content-Security-Policy： 'default-src \'self\'表示只能加載同域下資源辨嗽。
Content-Security-Policy： 'default-src \'self\'; report-uri /report' 表示只能加載同域下資源, 且會(huì)發(fā)送一個(gè)違例報(bào)告。默認(rèn)情況下淮腾，違規(guī)報(bào)告并不會(huì)發(fā)送糟需。為啟用發(fā)送違規(guī)報(bào)告，你需要指定 report-uri策略指令谷朝，并提供至少一個(gè)URI地址去遞交報(bào)告洲押。
如果我只想收集報(bào)告，但是不真正的去限制請(qǐng)求圆凰，那怎么辦杈帐？除了Content-Security-Policy，還有一個(gè)Content-Security-Policy-Report-Only字段，表示不執(zhí)行限選項(xiàng)挑童，只是記錄違反限制的行為累铅。將頭部改為這個(gè)即可。
注： default-src設(shè)置的是全局站叼，如果我只想限制js的請(qǐng)求娃兽，可以將default-src改為script-src, 限制圖片請(qǐng)求可用img-src

使用meta標(biāo)簽達(dá)到一樣的效果。
<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

詳細(xì)用法可以參考Content Security Policy

7.16 Sec-Fetch-*

簡(jiǎn)單來說尽楔，就是網(wǎng)絡(luò)請(qǐng)求的元數(shù)據(jù)描述投储，服務(wù)端根據(jù)這些補(bǔ)充數(shù)據(jù)進(jìn)行細(xì)粒度的控制響應(yīng)。瀏覽器自動(dòng)帶上的請(qǐng)求頭阔馋，都是Forbidden header玛荞，也就是不能被篡改的。
Sec-Fetch-Dest: 期望需要什么樣的資源,比如 script呕寝。
Sec-Fetch-Mode： 表明了一個(gè)請(qǐng)求的模式勋眯，比如是否跨域。
Sec-Fetch-Site: 請(qǐng)求發(fā)起者的來源與目標(biāo)資源來源之間的關(guān)系壁涎，比如跨域就為 cross-site凡恍。

7.17 其它首部字段

HTTP 首部字段是可以自行擴(kuò)展的志秃。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上怔球，會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。
例如: X-Frame-Options: 用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 iframe 標(biāo)簽內(nèi)的顯示問題浮还。

8. TCP長(zhǎng)連接

• 短連接的操作步驟是：
  建立連接——數(shù)據(jù)傳輸——關(guān)閉連接...建立連接——數(shù)據(jù)傳輸——關(guān)閉連接

• 長(zhǎng)連接的操作步驟是：
  建立連接——數(shù)據(jù)傳輸...（保持連接）...數(shù)據(jù)傳輸——關(guān)閉連接

• 持久的連接節(jié)省通信
  每次進(jìn)行HTTP請(qǐng)求的時(shí)候竟坛，都要先建立TCP連接，然后結(jié)束之后再斷開TCP連接钧舌。這樣如果在同一份HTML文檔中有大量的圖片等資源担汤，就會(huì)建立和斷開多次TCP連接，造成資源的浪費(fèi)洼冻。HTTP1.1和一部分HTTP1.0想出了持久連接崭歧。持久連接的特點(diǎn)：只要任意一端沒有明確斷開連接，就保持TCP的鏈接狀態(tài)撞牢。這樣不會(huì)因?yàn)轭l繁的建立和斷開TCP連接造成額外的開銷率碾，減輕了服務(wù)器的負(fù)載。同時(shí)減少了HTTP請(qǐng)求和響應(yīng)的時(shí)間屋彪。

  
  
  持久連接.png

• TCP connection
  Connection: keep-alive/close(開啟/關(guān)閉)
  HTTP2只需要建立一個(gè)TCP長(zhǎng)連接（同域下）

那是不是只需要建立一個(gè)TCP連接所宰，然后發(fā)送多個(gè)HTTP請(qǐng)求就可以了？ 不行畜挥。
HTTP/1.1 存在一個(gè)問題：?jiǎn)蝹€(gè) TCP 連接在同一時(shí)刻只能處理一個(gè)請(qǐng)求仔粥。如果一個(gè)網(wǎng)頁(yè)上有多個(gè)資源需要請(qǐng)求，肯定不能只開一個(gè)TCP連接，然后按請(qǐng)求順序下載躯泰，那樣用戶肯定等的很難受谭羔。
所以Chrome最多允許對(duì)同一個(gè) Host 建立六個(gè) TCP 連接。（不同的瀏覽器允許的連接數(shù)不同麦向。就解釋了之前我們所了解到的的瀏覽器請(qǐng)求的最大并發(fā)量是6個(gè)(以chrome為例)口糕。

相關(guān)文章
CORS
JSONP
HTTP
你知道一個(gè)TCP連接上能發(fā)起多少個(gè)HTTP請(qǐng)求嗎？