參考小林coding

HTTP基本概念

HTTP是超文本傳輸協(xié)議。所謂的超文本，就是超越了普通文本的文本，最關(guān)鍵的是有超鏈接，能從一個(gè)超文本跳轉(zhuǎn)到另一個(gè)超文本。

HTML是最常見(jiàn)的超文本，本身是純文字文件，但是內(nèi)部使用很多標(biāo)簽定義圖片、視頻等鏈接，再經(jīng)過(guò)瀏覽器的解釋，呈現(xiàn)出來(lái)的就是一個(gè)由文字、畫(huà)面的網(wǎng)頁(yè)了。

HTTP是兩點(diǎn)之間傳輸，可以是服務(wù)器到本地瀏覽器，也可以是服務(wù)器和服務(wù)器之間。

HTTP和HTTPS的區(qū)別

• HTTP是沒(méi)有加密的，也就是明文的，所以HTTP很不安全；HTTPS使用SSL+HTTP協(xié)議，可以加密傳輸、身份認(rèn)證，安全。
• HTTPS協(xié)議因?yàn)樾枰狢A證書(shū)，一般免費(fèi)證書(shū)比較少，需要一定費(fèi)用。
• HTTP和HTTPS使用不同的連接方式，用的端口不一樣：HTTP80，HTTPS443

HTTPS解決HTTP哪些問(wèn)題？

竊聽(tīng)風(fēng)險(xiǎn)—混合加密

采用對(duì)稱加密和非對(duì)稱加密。通信建立前采用非對(duì)稱加密（使用兩個(gè)密鑰，公鑰和私鑰），通信過(guò)程中使用對(duì)稱加密。

篡改風(fēng)險(xiǎn)—摘要算法和數(shù)字簽名

使用==摘要算法（哈希函數(shù)）==計(jì)算出內(nèi)容哈希值，這個(gè)哈希值是唯一的：

我們對(duì)內(nèi)容計(jì)算出一個(gè)“指紋”，連同內(nèi)容一起傳輸給對(duì)方，對(duì)方收到之后，對(duì)內(nèi)容也計(jì)算出一個(gè)“指紋”，跟發(fā)送方的“指紋”做一個(gè)比較，如果指紋相同，說(shuō)明內(nèi)容沒(méi)有被篡改。

但是這種會(huì)出現(xiàn)（內(nèi)容+哈希值）被中間人替換的風(fēng)險(xiǎn)。所以可以使用非對(duì)稱加密算法來(lái)解決。

非對(duì)稱加密算法

一個(gè)是公鑰，一個(gè)是私鑰。

• 公鑰加密，私鑰解密：保證傳輸內(nèi)容安全，因?yàn)橹挥谐钟兴借€的人，才能解密出實(shí)際內(nèi)容。
• 私鑰加密，公鑰解密：保證消息不被冒充。因?yàn)樗借€是不可以泄露的，如果公鑰可以解密出私鑰加密的內(nèi)容，說(shuō)明這個(gè)消息來(lái)源于持有私鑰身份的人發(fā)送。

冒充風(fēng)險(xiǎn)—數(shù)字證書(shū)

如果公鑰是被偽造的怎么辦呢？可以引入數(shù)字證書(shū)。
在計(jì)算機(jī)里，有一個(gè)權(quán)威機(jī)構(gòu)叫做CA（數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)）。服務(wù)器的運(yùn)營(yíng)人員向CA提出公開(kāi)密鑰申請(qǐng)，CA 在判明申請(qǐng)者的身份之后，會(huì)對(duì)已經(jīng)申請(qǐng)的公開(kāi)密鑰做出數(shù)字簽名，然后分配這個(gè)已經(jīng)簽名的公開(kāi)密鑰，并將這個(gè)公開(kāi)密鑰放入公開(kāi)密鑰證書(shū)后綁定在一起。
進(jìn)行HTTP通信的時(shí)候，服務(wù)器把證書(shū)發(fā)給客戶端，客戶端取得其中的公開(kāi)密鑰之后，先用數(shù)字簽名進(jìn)行驗(yàn)證，如果驗(yàn)證通過(guò)，就可以開(kāi)始通信了。

HTTPS如何建立連接

SSL/TLS協(xié)議建立

基本思路就是采用公鑰加密法，也就是說(shuō)，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文之后，用自己的私鑰解密。

• ClientHello:客戶端向服務(wù)器發(fā)起加密通信請(qǐng)求。
  發(fā)送支持的TLS版本，客戶端產(chǎn)生的隨機(jī)數(shù)（后續(xù)用于生成會(huì)話密鑰），客戶端支持的密碼套件列表（RSA加密算法，是TLS 1.0版本的，現(xiàn)在流行的TLS 1.2已經(jīng)稱為主流）

• ServerHello:服務(wù)器收到客戶端請(qǐng)求之后，向客戶端發(fā)送響應(yīng)。
  回應(yīng)內(nèi)容包括確認(rèn)TLS協(xié)議版本（如果瀏覽器不支持，關(guān)閉加密通信），服務(wù)器產(chǎn)生的隨機(jī)數(shù)，確認(rèn)的密碼套件列表，服務(wù)器的數(shù)字證書(shū)

• 客戶端回應(yīng)：首先通過(guò)瀏覽器或者操作系統(tǒng)中的CA公鑰，確認(rèn)服務(wù)器數(shù)字證書(shū)的真實(shí)性，如果證書(shū)沒(méi)有問(wèn)題，客戶端會(huì)從數(shù)字證書(shū)中取出服務(wù)器公鑰，然后使用它加密報(bào)文。
  向服務(wù)器發(fā)送一個(gè)隨機(jī)數(shù)（這個(gè)隨機(jī)數(shù)會(huì)被服務(wù)器公鑰加密，這個(gè)隨機(jī)數(shù)客戶端和服務(wù)端都是一樣的），加密通信算法改變通知（表示隨后的信息都將用會(huì)話密鑰加密通信），客戶端握手結(jié)束通知，同時(shí)把之前所有內(nèi)容的發(fā)生數(shù)據(jù)做個(gè)摘要，用來(lái)提供服務(wù)端校驗(yàn)。

• 服務(wù)器最后回應(yīng)：服務(wù)器收到客戶端第三個(gè)隨機(jī)數(shù)之后，通過(guò)協(xié)商的加密算法（私鑰），計(jì)算出本次通信的會(huì)話密鑰。
  然后向客戶端發(fā)送最后的消息：前面三個(gè)隨機(jī)數(shù)生成的對(duì)話密鑰用來(lái)加密接下來(lái)的整個(gè)對(duì)話過(guò)程；加密通信算法改變通知，表示隨后的信息都將用會(huì)話密鑰加密通信；服務(wù)器握手結(jié)束通知，表示服務(wù)器握手階段已經(jīng)結(jié)束，同時(shí)把之前所有內(nèi)容的發(fā)生的數(shù)據(jù)做個(gè)摘要用來(lái)給客戶端提供校驗(yàn)。

HTTP狀態(tài)碼

1XX

客戶端可以繼續(xù)發(fā)送請(qǐng)求或者忽略這個(gè)相應(yīng)

2XX

• 200：OK
• 204：請(qǐng)求成功，但是==返回的響應(yīng)報(bào)文不包含實(shí)體的主體部分。
• 206：表示客戶端進(jìn)行范圍請(qǐng)求，響應(yīng)報(bào)文包含content -Range指定范圍的實(shí)體內(nèi)容

3XX

• 301：永久重定向
• 302：臨時(shí)性重定向
• 303：臨時(shí)性重定向，但是客戶端應(yīng)該采用GET方法獲取資源
• 304：請(qǐng)求報(bào)文會(huì)包含一些條件，比如if-match,if-none-match，如果不滿足條件，則返回304
• 307 ：臨時(shí)重定向，與302的含義類似，但是307要求瀏覽器不會(huì)把重定向請(qǐng)求的POST方法改成GET方法。

4XX

• 400：請(qǐng)求報(bào)文存在語(yǔ)法錯(cuò)誤
• 401：這個(gè)狀態(tài)碼表示發(fā)送的請(qǐng)求需要有認(rèn)證信息（BASIC認(rèn)證，DIGSET認(rèn)證）。如果之前已經(jīng)進(jìn)行過(guò)一次請(qǐng)求，則表示用戶認(rèn)證失敗。
• 403：請(qǐng)求被拒絕
• 404：表示請(qǐng)求的資源在服務(wù)器上面不存在或者未找到，所以無(wú)法提供給客戶端。

5XX

• 500：與400類似是一個(gè)籠統(tǒng)的錯(cuò)誤碼，服務(wù)器發(fā)生了什么 錯(cuò)誤，我們并不知道
• 501：客戶端請(qǐng)求的功能目前還不支持
• 502 Bad Gateway:服務(wù)器作為網(wǎng)關(guān)或者代理的時(shí)候返回的錯(cuò)誤碼，表示服務(wù)器自身工作正常，訪問(wèn)后端服務(wù)器發(fā)生錯(cuò)誤。
• 503：表示服務(wù)器當(dāng)前很忙，暫時(shí)無(wú)法響應(yīng)客戶端。

HTTP緩存

對(duì)于一些重復(fù)的HTTP請(qǐng)求，每次請(qǐng)求到的數(shù)據(jù)都是一樣的，那么可以把這對(duì)請(qǐng)求響應(yīng)的數(shù)據(jù)緩存在本地，那么下次就可以直接讀取本地?cái)?shù)據(jù)，不需要通過(guò)網(wǎng)絡(luò)獲取服務(wù)器響應(yīng)。HTTP有兩種緩存：強(qiáng)制緩存和協(xié)商緩存。

為什么緩存？

降解服務(wù)器壓力，降低客戶端獲取資源的延遲：緩存通常位于內(nèi)存中，讀取緩存的速度更快?？梢宰尨矸?wù)器緩存或者讓客戶端瀏覽器進(jìn)行緩存。

強(qiáng)制緩存和協(xié)商緩存

強(qiáng)制緩存

只要瀏覽器判斷緩存沒(méi)有過(guò)期，就直接使用瀏覽器的本地緩存，決定是否使用緩存的主動(dòng)性在瀏覽器這邊(from disk cache)。如果過(guò)期，就會(huì)重新請(qǐng)求服務(wù)器。服務(wù)器再次受到請(qǐng)求之后，會(huì)再次更新響應(yīng)頭部的Cache-Control。
強(qiáng)制緩存利用兩個(gè)HTTP響應(yīng)頭部字段實(shí)現(xiàn)：Cache-Control和Expires。前者是一個(gè)相對(duì)時(shí)間，后者是絕對(duì)是件，前者的優(yōu)先級(jí)高于后者。

協(xié)商緩存

某些請(qǐng)求的響應(yīng)碼是304，這個(gè)是告訴瀏覽器可以使用本地緩存的資源。通常這種服務(wù)端告知客戶端是否可以使用緩存的方式被稱為協(xié)商緩存。可以通過(guò)If-Modified-Since和If-None-Match來(lái)實(shí)現(xiàn)。參考小coding:

• ETag優(yōu)先級(jí)更高的原因是沒(méi)有修改文件內(nèi)容就不用重新請(qǐng)求；而且If-Modified-Since能檢查到的粒度是秒級(jí)的，使用Etag可以保證一些秒級(jí)修改以內(nèi)的可以刷新；而且有的服務(wù)器不能精確獲取文件最后修改時(shí)間。
  

禁用緩存和確認(rèn)緩存

HTTP/1.1通過(guò)Cache-Control首部字段來(lái)控制緩存。通過(guò)no-store進(jìn)行禁止緩存；通過(guò)no-chche指令規(guī)定緩存服務(wù)器需要先向源服務(wù)器驗(yàn)證緩存資源有效性，只有緩存資源有效的時(shí)候才能使用該緩存對(duì)客戶端的請(qǐng)求進(jìn)行響應(yīng)。

HTTP緩存中公有字段和私有字段

私有

private 指令規(guī)定了將資源作為私有緩存，只能被單獨(dú)用戶使用，一般存儲(chǔ)在用戶瀏覽器中。

Cache-Control: private

公有

public 指令規(guī)定了將資源作為公共緩存，可以被多個(gè)用戶使用，一般存儲(chǔ)在代理服務(wù)器中。

Cache-Control: public

緩存過(guò)期機(jī)制

可以保證緩存是最新的。max-age指令(在 HTTP/1.1 中，會(huì)優(yōu)先處理 max-age 指令；
在 HTTP/1.0 中，max-age 指令會(huì)被忽略掉)出現(xiàn)在相應(yīng)報(bào)文，表示緩存資源在緩存服務(wù)器中保存的時(shí)間。

Cache-Control: max-age=31536000

Expires 首部字段也可以用于告知緩存服務(wù)器該資源什么時(shí)候會(huì)過(guò)期。

Expires: Wed, 04 Jul 2012 08:26:05 GMT

HTTP請(qǐng)求

HTTP請(qǐng)求過(guò)程

• 域名解析
• 發(fā)起TCP3次握手
• 建立TCP連接之后發(fā)起http請(qǐng)求
• 服務(wù)器響應(yīng)http請(qǐng)求，瀏覽器得到html代碼
• 瀏覽器解析html代碼，請(qǐng)求html中的資源
• 瀏覽器對(duì)頁(yè)面進(jìn)行渲染呈現(xiàn)給用戶

HTTP請(qǐng)求方法

客戶端發(fā)送的請(qǐng)求報(bào)文第一行為請(qǐng)求行，包含了方法字段。
圖片來(lái)源阿秀的學(xué)習(xí)筆記

GET和POST區(qū)別

• GET的語(yǔ)義是從服務(wù)器獲取指定的資源。
• POST是根據(jù)請(qǐng)求負(fù)荷（報(bào)文body）對(duì)指定資源作出處理。

• GET請(qǐng)求的參數(shù)一般是寫(xiě)在URL中，URL規(guī)定只支持ASCII，所以GET請(qǐng)求的參數(shù)只允許ASCII字符，而且瀏覽器會(huì)對(duì)URL長(zhǎng)度有限制（2K，實(shí)際取決于瀏覽器和服務(wù)器。瀏覽器就不說(shuō)了，服務(wù)器因?yàn)樘幚黹L(zhǎng)URL需要消耗比較多的資源，為了性性能和安全會(huì)給URL長(zhǎng)度加上限制）。（HTTP協(xié)議本身對(duì)URL長(zhǎng)度沒(méi)有規(guī)定）
• POST請(qǐng)求攜帶數(shù)據(jù)的位置一般是寫(xiě)在報(bào)文中，body中可以是任何格式的數(shù)據(jù)，只要客戶端與服務(wù)端協(xié)商好就可以，而且瀏覽器一般不會(huì)對(duì)body大小作出限制。但是實(shí)際上POST所能傳遞的數(shù)據(jù)量取決于服務(wù)器設(shè)置和內(nèi)存大小。一半POST數(shù)據(jù)量很少有超過(guò)MB的，因?yàn)樯蟼魑募臅r(shí)候，如果要上傳比較大的數(shù)據(jù)或者文件到服務(wù)器，有可能上傳不上去。

安全性和冪等性

• GET是安全和冪等的。因?yàn)?strong>只讀性，無(wú)論操作多少次，數(shù)據(jù)都是安全的。（可以對(duì)GET請(qǐng)求的數(shù)據(jù)做緩存，這個(gè)緩存可以放到瀏覽器上面或者代理比如nginx，還可以保存為書(shū)簽）
• POST會(huì)修改數(shù)據(jù)所以不安全，多次提交數(shù)據(jù)就會(huì)創(chuàng)建多個(gè)資源，所以不是冪等的。

但是如果開(kāi)發(fā)者不按照RFC規(guī)范語(yǔ)義來(lái)實(shí)現(xiàn)GET和POST方法，那GET和POST的安全性和冪等性就不能保證了

其實(shí)，從傳輸?shù)慕嵌葋?lái)說(shuō)，GET和POST都是不安全的，因?yàn)镠TTP在網(wǎng)絡(luò)上是明文傳輸?shù)模灰诰W(wǎng)絡(luò)節(jié)點(diǎn)上面捉包，就可以完整的獲取數(shù)據(jù)報(bào)文。要實(shí)現(xiàn)真正的安全傳輸，就只有加密，也就是HTTPS。

能否攜帶body

POST請(qǐng)求攜帶數(shù)據(jù)的位置一般是在body中，其實(shí)RFC規(guī)范并沒(méi)有規(guī)定GET請(qǐng)求不能攜帶body，但是GET一般是用來(lái)獲取資源的，所以不需要body。

產(chǎn)生TCP數(shù)據(jù)包

• GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包
• POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100continue；瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200ok。（但是在Chrome上面實(shí)際測(cè)試之后發(fā)現(xiàn)，header和body不會(huì)分開(kāi)發(fā)送。這說(shuō)明分開(kāi)發(fā)送是部分瀏覽器或者框架的請(qǐng)求方法，不屬于POST的必然行為。）

GET方法參數(shù)

在約定中，參數(shù)是寫(xiě)在?后面，用&分割。我們也可以自己約定參數(shù)，只要服務(wù)端可以解釋出來(lái)就行。

Cookie和Session

cookie和session的區(qū)別

cookie

什么是cookie

HTTP 協(xié)議是無(wú)狀態(tài)的，主要是為了讓 HTTP 協(xié)議盡可能簡(jiǎn)單，使得它能夠處理大量事務(wù)，HTTP/1.1 引入 Cookie 來(lái)保存狀態(tài)信息。

cookie是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器之后向同一服務(wù)器再次發(fā)起請(qǐng)求的時(shí)候被攜帶上，用于告知服務(wù)端兩個(gè)請(qǐng)求是否來(lái)自于同一個(gè)瀏覽器

cookie 的出現(xiàn)是因?yàn)?HTTP 是無(wú)狀態(tài)的一種協(xié)議，換句話說(shuō)，服務(wù)器記不住你，可能你每刷新一次網(wǎng)頁(yè)，就要重新輸入一次賬號(hào)密碼進(jìn)行登錄。這顯然是讓人無(wú)法接受的，cookie 的作用就好比服務(wù)器給你貼個(gè)標(biāo)簽，然后你每次向服務(wù)器再發(fā)請(qǐng)求時(shí)，服務(wù)器就能夠 cookie 認(rèn)出你。

除了上面提到的這些，Cookie在客戶端的保存形式可以有兩種，一種是會(huì)話Cookie一種是持久Cookie，會(huì)話Cookie就是將服務(wù)器返回的Cookie字符串保持在內(nèi)存中，關(guān)閉瀏覽器之后自動(dòng)銷毀，持久Cookie則是存儲(chǔ)在客戶端磁盤(pán)上，其有效時(shí)間在服務(wù)器響應(yīng)頭中被指定，在有效期內(nèi)，客戶端再次請(qǐng)求服務(wù)器時(shí)都可以直接從本地取出。需要說(shuō)明的是，存儲(chǔ)在磁盤(pán)中的Cookie是可以被多個(gè)瀏覽器代理所共享的。

cookie用途

• 會(huì)話狀態(tài)管理：用戶登錄狀態(tài)、購(gòu)物車、游戲分?jǐn)?shù)或者其他需要記錄的信息
• 個(gè)性化設(shè)置：用戶自定義設(shè)置、主題等
• 瀏覽器行為跟蹤：跟蹤分析用戶行為等

session

session工作原理

session的工作原理是客戶端登錄完成之后，服務(wù)器會(huì)創(chuàng)建對(duì)應(yīng)的session，創(chuàng)建完之后會(huì)把session的id發(fā)送給客戶端，客戶端再存儲(chǔ)到瀏覽器中。這樣客戶端每次訪問(wèn)服務(wù)器的時(shí)候，都會(huì)帶著session id，服務(wù)器拿到session id之后，在內(nèi)存找到與之對(duì)應(yīng)的session就可以正常工作了。

session保存在服務(wù)器上，可以保存在數(shù)據(jù)庫(kù)、文件或者內(nèi)存中，每個(gè)用戶有獨(dú)立的session用戶在客戶端上記錄用戶的操作。我們可以理解為每個(gè)用戶有一個(gè)獨(dú)一無(wú)二的Session ID作為Session文件的Hash鍵，通過(guò)這個(gè)值可以鎖定具體的Session結(jié)構(gòu)的數(shù)據(jù)，這個(gè)Session結(jié)構(gòu)中存儲(chǔ)了用戶操作行為。

session的過(guò)程

• 用戶登錄，用戶提交包含用戶名和密碼的表單，放入HTTP請(qǐng)求報(bào)文中；
• 服務(wù)器驗(yàn)證該用戶名和密碼，如果正確就把用戶信息存儲(chǔ)到redis中，它在redis中的key成為session id
• 服務(wù)器返回的響應(yīng)報(bào)文的set-cookie首部字段包含了這個(gè)session id，客戶端收到相應(yīng)報(bào)文之后將該cookie值存入瀏覽器中；
• 客戶端之后對(duì)同一個(gè)服務(wù)器進(jìn)行請(qǐng)求的時(shí)候會(huì)包含該cookie值，服務(wù)器收到之后，提取出session id ，從redis中提取出用戶信息，繼續(xù)之前業(yè)務(wù)操作

session id 的安全性問(wèn)題，不能讓他被惡意攻擊者輕易獲取，那么就不能產(chǎn)生一個(gè)容易被猜到的session id值。此外，還需要經(jīng)常生成session id 。在對(duì)安全性要求極高的場(chǎng)景下，例如轉(zhuǎn)賬等操作，除了使用 Session 管理用戶狀態(tài)之外，還需要對(duì)用戶進(jìn)行重新驗(yàn)證，比如重新輸入密碼，或者使用短信驗(yàn)證碼等方式。

cookie與session的對(duì)比

HTTP作為無(wú)狀態(tài)協(xié)議，必然需要在某種方式保持連接狀態(tài)。

Cookie是客戶端保持狀態(tài)的方法；session是服務(wù)器保持狀態(tài)的方法。

使用場(chǎng)景

Cookie 只能存儲(chǔ) ASCII 碼字符串，而 Session 則可以存儲(chǔ)任何類型的數(shù)據(jù)，因此在考慮數(shù)據(jù)復(fù)雜性時(shí)首選 Session；
Cookie 存儲(chǔ)在瀏覽器中，容易被惡意查看。如果非要將一些隱私數(shù)據(jù)存在 Cookie 中，可以將 Cookie 值進(jìn)行加密，然后在服務(wù)器進(jìn)行解密；
對(duì)于大型網(wǎng)站，如果用戶所有的信息都存儲(chǔ)在 Session 中，那么開(kāi)銷是非常大的，因此不建議將所有的用戶信息都存儲(chǔ)到 Session 中。

當(dāng)服務(wù)器需要識(shí)別客戶端時(shí)就需要結(jié)合Cookie了。每次HTTP請(qǐng)求的時(shí)候，客戶端都會(huì)發(fā)送相應(yīng)的Cookie信息到服務(wù)端。實(shí)際上大多數(shù)的應(yīng)用都是用Cookie來(lái)實(shí)現(xiàn)Session跟蹤的，第一次創(chuàng)建Session的時(shí)候，服務(wù)端會(huì)在HTTP協(xié)議中告訴客戶端，需要在Cookie里面記錄一個(gè)Session ID，以后每次請(qǐng)求把這個(gè)會(huì)話ID發(fā)送到服務(wù)器，我就知道你是誰(shuí)了。如果客戶端的瀏覽器禁用了Cookie，會(huì)使用一種叫做URL重寫(xiě)的技術(shù)來(lái)進(jìn)行會(huì)話跟蹤，即每次HTTP交互，URL后面都會(huì)被附加上一個(gè)諸如sid=xxxxx這樣的參數(shù)，服務(wù)端據(jù)此來(lái)識(shí)別用戶，這樣就可以幫用戶完成諸如用戶名等信息自動(dòng)填入的操作了。

SQL注入攻擊

什么是SQL注入文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-466730.html

到了這里，關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)—HTTP基本概念、HTTPS、HTTP狀態(tài)碼、HTTP緩存、HTTP請(qǐng)求的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！