一扮叨、http協(xié)議和TCP/IP協(xié)議用于客戶端和服務(wù)器端之間的通訊缤弦。
二、通過請(qǐng)求和響應(yīng)的交換達(dá)成通信彻磁。
? ? HTTP協(xié)議規(guī)定碍沐，請(qǐng)求從客戶端發(fā)出，最后服務(wù)器響應(yīng)該請(qǐng)求并返回衷蜓。換句話說累提，肯定是先從客戶端開始建立通信的，服務(wù)器端在沒有接收到請(qǐng)求之前不會(huì)發(fā)送響應(yīng)磁浇。
1.請(qǐng)求報(bào)文圖
2.響應(yīng)報(bào)文圖
三斋陪、HTTP是不保存狀態(tài)的協(xié)議。
? ? HTTP是一種不保存狀態(tài)置吓，即無狀態(tài)（stateless）協(xié)議无虚。HTTP協(xié)議自身不對(duì)請(qǐng)求和響應(yīng)之間的通信狀態(tài)進(jìn)行保存。也就是說在HTTP這個(gè)級(jí)別衍锚，協(xié)議對(duì)于發(fā)送過的請(qǐng)求和響應(yīng)都不做持久化處理友题。
使用HTTP協(xié)議，每當(dāng)有新的請(qǐng)求產(chǎn)生時(shí)戴质，就會(huì)有對(duì)應(yīng)的新響應(yīng)產(chǎn)生度宦。協(xié)議本身并不保留之前一切的請(qǐng)求或響應(yīng)報(bào)文的信息踢匣，這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性戈抄，而特意把HTTP協(xié)議設(shè)計(jì)得如此簡(jiǎn)單离唬。
四、請(qǐng)求URI定位資源
? ? HTTP協(xié)議使用URI定位互聯(lián)網(wǎng)上的資源划鸽。正是因?yàn)閁RI的特定功能输莺，再互聯(lián)網(wǎng)上任意位置的資源都能訪問到。
除此以外漾稀，如果不是訪問特定資源而是對(duì)服務(wù)器本身發(fā)起請(qǐng)求模闲，可以用一個(gè)*來代替請(qǐng)求URI。
五崭捍、告知服務(wù)器意圖的HTTP方法
1.get 獲取資源
????get方法用來請(qǐng)求訪問已被URI識(shí)別的資源尸折。指定的資源經(jīng)服務(wù)器端解析后返回的內(nèi)容，也就是說殷蛇，如果請(qǐng)求的資源是文本实夹，那就保持原樣返回；如果是像CGI（common Gateway Interface粒梦，通用網(wǎng)關(guān)接口）那樣的程序亮航，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。
使用GET方法的請(qǐng)求響應(yīng)的例子
2.POST：傳輸實(shí)體請(qǐng)求
? ? 雖然用GET方法也可以傳輸實(shí)體的主體匀们，但一般不用GET方法進(jìn)行傳輸缴淋，而是用POST方法。雖說POST的功能與GET很相似泄朴，但POST的主要目的并不是獲取響應(yīng)的主體內(nèi)容重抖。
3.PUT：傳輸文件
? ? PUT方法用來傳輸文件。就像FTP協(xié)議的文件上傳一樣祖灰，要求在請(qǐng)求報(bào)文的主體中包含的內(nèi)容钟沛，然后保存到請(qǐng)求URI指定的位置。但是局扶，鑒于HTTP/1.1 的PUT方法自身不帶驗(yàn)證機(jī)制恨统，任何人都可以上傳文件，存在安全性問題三妈，因此一般的Web網(wǎng)站不使用該方法畜埋。若配合web應(yīng)用程序的驗(yàn)證機(jī)制，或架構(gòu)設(shè)計(jì)采用REST（REpresentational State Transfer,表示狀態(tài)轉(zhuǎn)移）標(biāo)椎的同類web網(wǎng)站畴蒲，就可能會(huì)開放使用PUT方法由捎。
4.HEAD 獲取報(bào)文首部
????HEAD方法和GET方法一樣，只是不返回報(bào)文主體部分饿凛。用于確認(rèn)URI的有效性及資源更新的日期時(shí)間等狞玛。
5.DELETE 刪除文件
? ? delete 方法用來刪除文件，是與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ī)制，或遵循RESR標(biāo)準(zhǔn)時(shí)還是有可能會(huì)開放使用的戴已。
6.options：查詢支持的方法
? ? OPTIONS方法用來查詢針對(duì)請(qǐng)求URI指定的資源支持的方法固该。
7.TRACT 追蹤路徑
????TRACE方法是讓web服務(wù)器將之前的請(qǐng)求通信環(huán)回給客戶端的方法。
????發(fā)送請(qǐng)求時(shí)糖儡，再M(fèi)ax-Forwards首部字段中填入數(shù)值伐坏，每經(jīng)過一個(gè)服務(wù)器端就將該數(shù)字減1，當(dāng)數(shù)值剛好減到0時(shí)握联，就停止繼續(xù)傳播桦沉，最后接收到請(qǐng)求的服務(wù)器端則返回狀態(tài)碼200 OK 的響應(yīng)。
? ? 客戶端通過TRACT方法可以查詢發(fā)送出去的請(qǐng)求時(shí)怎樣被加工修改 /篡改的金闽。這是因?yàn)榇柯叮?qǐng)求想要連接到源目標(biāo)服務(wù)器可能會(huì)通過代理中轉(zhuǎn)，TRACE方法就是用來確認(rèn)連接過程中發(fā)生的一系列操作代芜。但是TEACE方法本來就不怎么常用埠褪，再加上它容易引發(fā)XST（cross-site Tracing， 跨站追蹤）攻擊挤庇，通常就不會(huì)用到了钞速。
8.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連接狭郑。以當(dāng)年的通信情況來說，因?yàn)槎际切┤萘亢苄〉奈谋緜鬏敾阍冢约词惯@樣也沒有多大問題翰萨。可隨著HTTP的普及糕殉，文檔中包含大量圖片的情況多了起來亩鬼。
? ? 比如殖告，使用瀏覽器瀏覽一個(gè)包含多張圖片的HTML頁面時(shí)，在發(fā)送請(qǐng)求訪問HTML頁面資源的同時(shí)雳锋，也會(huì)請(qǐng)求該HTML頁面里包含的其他資源黄绩。因此，每次的請(qǐng)求都會(huì)造成無所謂的TCP連接建立和斷開玷过，增加通信量的開銷爽丹。
? ? 為了解決上述TCP連接的問題，HTTP/1.1 和一部分的HTTP/1.0想出了持久連接（HTTP Persistent Connections ,也稱為HTTP keep-alive 或HTTP connection reuse）的方法辛蚊。持久連接的特點(diǎn)是粤蝎。只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)袋马。
? ? 持續(xù)連接的好處在于減少了TCP連接的重復(fù)建立和斷開所造成的額外開銷初澎，減輕了服務(wù)器端的負(fù)載。另外飞蛹，減少開銷的那部分時(shí)間谤狡，使HTTP請(qǐng)求和響應(yīng)能否更早地結(jié)束，這樣web頁面的顯示速度也就相應(yīng)提高了卧檐。
? ? 在HTTP1.1中墓懂，所有的連接默認(rèn)都是持久連接，但在HTTP/1.0內(nèi)并未標(biāo)準(zhǔn)化霉囚。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接捕仔，但服務(wù)器端不一定能夠支持持久化鏈接。毫無疑問盈罐，除了服務(wù)器端榜跌，客戶端也需要支持持久連接。
? ? 管線化
? ? 持久連接使得多數(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)了奠骄，
比如豆同，當(dāng)請(qǐng)求一個(gè)包含10張圖片的HTML web頁面，與挨個(gè)連接相比含鳞，用持久化鏈接可以讓請(qǐng)求更快結(jié)束影锈，而管線化技術(shù)則比持久連接還要快。請(qǐng)求數(shù)越多，時(shí)間差就越明顯鸭廷。
七枣抱、使用cookie 的狀態(tài)管理
? ? HTTP是無狀態(tài)協(xié)議，它不對(duì)之前發(fā)生過的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理靴姿。也就是說沃但，無法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。假如要求登錄認(rèn)證的web 頁面本身無法進(jìn)行狀態(tài)的管理（不記錄已登錄的狀態(tài)）佛吓，那么每次跳轉(zhuǎn)新頁面不是要再次登錄，就是要在每次請(qǐng)求報(bào)文中附加參數(shù)來管理登錄狀態(tài)垂攘。
? ? 不可否認(rèn)维雇，無狀態(tài)協(xié)議當(dāng)然也有它的優(yōu)點(diǎn)，由于不必保存狀態(tài)晒他，自然可減少服務(wù)器的CPU及內(nèi)存資源的消耗吱型。從另一個(gè)側(cè)面來說，也正是因?yàn)镠TTP協(xié)議本身是非常簡(jiǎn)單的陨仅，所以才會(huì)被應(yīng)用在各種場(chǎng)景里津滞。
? ? 寶麗路無狀態(tài)協(xié)議這個(gè)特征的同時(shí)又要解決類似的矛盾問題，于是引入可cookie技術(shù)灼伤。cookie技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入cookie信息來控制客戶端的狀態(tài)触徐，
? ? cookie會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做set-cookie的首部字段信息，通知客戶端保存cookie狐赡。當(dāng)下次客戶端在往該服務(wù)器發(fā)送請(qǐng)求時(shí)撞鹉，服務(wù)端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入cookie后，會(huì)去檢查究竟是從哪一個(gè)客戶端發(fā)來的連接請(qǐng)求颖侄，然后對(duì)比服務(wù)器上的記錄鸟雏，最后得到之前狀態(tài)信息。
