URL

URI格式

這里理解三個(gè)概念尽棕，絕對(duì)URI薪寓，絕對(duì)URL且改，相對(duì)URL。
絕對(duì)URI

URI

• 使用 http: 或 https: 等協(xié)議方案名獲取訪問資源時(shí)要指定協(xié)議類型持舆。不區(qū)分字母大小寫色瘩，最后附一個(gè)冒號(hào)（:），也可使用 data: 或 javascript: 這類指定數(shù)據(jù)或腳本程序的方案名逸寓。
• 指定用戶名和密碼作為從服務(wù)器端獲取資源時(shí)必要的登錄信息（身份認(rèn)證）居兆。此項(xiàng)是可選項(xiàng)。
• 指定服務(wù)器連接的網(wǎng)絡(luò)端口號(hào)竹伸。此項(xiàng)也是可選項(xiàng)史辙，若用戶省略則自動(dòng)使用默認(rèn)端口號(hào)。
• 指定服務(wù)器上的文件路徑來(lái)定位特指的資源佩伤。這與 UNIX 系統(tǒng)的文件目錄結(jié)構(gòu)相似聊倔。
• 針對(duì)已指定的文件路徑內(nèi)的資源，可以使用查詢字符串傳入任意參數(shù)生巡。此項(xiàng)可選耙蔑。
• 使用片段標(biāo)識(shí)符通常可標(biāo)記出已獲取資源中的子資源（文檔內(nèi)的某個(gè)位置）孤荣。但在 RFC 中并沒有明確規(guī)定其使用方法甸陌。該項(xiàng)也為可選項(xiàng)。

絕對(duì)URL和相對(duì)URL：
前者就是完整的訪問地址盐股，后者是相對(duì)當(dāng)前位置的地址钱豁。

HTTP協(xié)議

HTTP 是一種不保存狀態(tài)，即無(wú)狀態(tài)（stateless）協(xié)議疯汁。 HTTP 協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存牲尺。 也就是說(shuō)在 HTTP 這個(gè)級(jí)別，協(xié)議對(duì)于發(fā)送過的請(qǐng)求或響應(yīng)都不做持久化處理。

客戶端請(qǐng)求
發(fā)送請(qǐng)求的時(shí)候谤碳，方式有很多溃卡。

Paste_Image.png

方法命令

其中LINK，UNLINE 已經(jīng)廢棄蜒简。

方法命令

GET
GET 方法用來(lái)請(qǐng)求訪問已被 URI 識(shí)別的資源瘸羡。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。 也就是說(shuō)搓茬，如果請(qǐng)求的資源是文本犹赖，那就保持原樣返回； 如果是像 CGI（Common Gateway Interface卷仑，通用網(wǎng)關(guān)接口）那樣的程序峻村，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。

GET

POST
POST 方法用來(lái)傳輸實(shí)體的主體系枪。
響應(yīng)的意思其實(shí)是請(qǐng)求執(zhí)行成功了雀哨，但無(wú)數(shù)據(jù)返回磕谅。

POST

**HEAD:獲得報(bào)文首部
HEAD 方法和 GET 方法一樣私爷，只是不返回報(bào)文主體部分。用于確認(rèn)URI 的有效性及資源更新的日期時(shí)間等膊夹。

HEAD

DELETE：刪除文件
DELETE 方法用來(lái)刪除文件衬浑，是與 PUT 相反的方法。 DELETE 方法按請(qǐng)求 URI 刪除指定的資源放刨。

但是工秩， HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗(yàn)證機(jī)制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法进统。當(dāng)配合 Web 應(yīng)用程序的驗(yàn)證機(jī)制助币，或遵守 REST 標(biāo)準(zhǔn)時(shí)還是有可能會(huì)開放使用的。

DELETE

OPTIONS：詢問支持的方法
OPTIONS 方法用來(lái)查詢針對(duì)請(qǐng)求 URI 指定的資源支持的方法螟碎。

OPTIONS

TRACE：追蹤路徑
TRACE 方法是讓 Web 服務(wù)器端將之前的請(qǐng)求通信環(huán)回給客戶端的方法眉菱。

發(fā)送請(qǐng)求時(shí)， 在 Max-Forwards 首部字段中填入數(shù)值掉分，每經(jīng)過一個(gè)服務(wù)器端就將該數(shù)字減 1俭缓， 當(dāng)數(shù)值剛好減到 0 時(shí)，就停止繼續(xù)傳輸酥郭，最后接收到請(qǐng)求的服務(wù)器端則返回狀態(tài)碼 200 OK 的響應(yīng)华坦。

客戶端通過 TRACE 方法可以查詢發(fā)送出去的請(qǐng)求是怎樣被加工修改 / 篡改的。這是因?yàn)椴淮樱?qǐng)求想要連接到源目標(biāo)服務(wù)器可能會(huì)通過代理中轉(zhuǎn)惜姐， TRACE 方法就是用來(lái)確認(rèn)連接過程中發(fā)生的一系列操作。

但是椿息， TRACE 方法本來(lái)就不怎么常用载弄，再加上它容易引發(fā) XST（Cross-Site Tracing耘拇，跨站追蹤）攻擊，通常就更不會(huì)用到了宇攻。

TRACE

CONNECT：要求用隧道協(xié)議連接代理

CONNECT 方法要求在與代理服務(wù)器通信時(shí)建立隧道惫叛，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行 TCP 通信。主要使用 SSL（Secure Sockets Layer逞刷，安全套接層）和 TLS（Transport Layer Security嘉涌，傳輸層安全）協(xié)議把通信內(nèi)容加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

CONNECT

持久連接節(jié)省通信量

HTTP 協(xié)議的初始版本中夸浅，每進(jìn)行一次 HTTP 通信就要斷開一次TCP 連接仑最。可隨著 HTTP 的普及帆喇，文檔中包含大量圖片的情況多了起來(lái)警医。如果按照以前的方式，就會(huì)造成無(wú)謂的TCP連接斷開坯钦，增大開銷预皇。

為解決上述 TCP 連接的問題， HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections婉刀，也稱為 HTTP keep-alive 或HTTP connection reuse）的方法吟温。持久連接的特點(diǎn)是，只要任意一端沒有明確提出斷開連接突颊，則保持 TCP 連接狀態(tài)鲁豪。

在 HTTP/1.1 中， 所有的連接默認(rèn)都是持久連接律秃。

管線化
持久連接使得多數(shù)請(qǐng)求以管線化（pipelining）方式發(fā)送成為可能爬橡。從前發(fā)送請(qǐng)求后需等待并收到響應(yīng)， 才能發(fā)送下一個(gè)請(qǐng)求棒动。管線化技術(shù)出現(xiàn)后糙申，不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求。

這樣就能夠做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求迁客， 而不需要一個(gè)接一個(gè)地等待響應(yīng)了郭宝。

Cookie

HTTP 是無(wú)狀態(tài)協(xié)議，它不對(duì)之前發(fā)生過的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理掷漱。也就是說(shuō)粘室，無(wú)法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。

保留無(wú)狀態(tài)協(xié)議這個(gè)特征的同時(shí)又要解決類似的矛盾問題卜范，于是引入了 Cookie 技術(shù)衔统。 Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來(lái)控制客戶端的狀態(tài)。

Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie的首部字段信息， 通知客戶端保存 Cookie锦爵。當(dāng)下次客戶端再往該服務(wù)器發(fā)送請(qǐng)求時(shí)舱殿，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出去。

服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來(lái)的 Cookie 后险掀， 會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來(lái)的連接請(qǐng)求沪袭， 然后對(duì)比服務(wù)器上的記錄，最后得到之前的狀態(tài)信息樟氢。

第一個(gè)請(qǐng)求報(bào)文

響應(yīng)報(bào)文

第二個(gè)請(qǐng)求報(bào)文