《图解 HTTP》读书笔记(未完待续)
ARP 協(xié)議(Address Resolution Protocol)一種以解析地址的協(xié)議,根據(jù)通信雙方的 IP 地址就可以查出對(duì)應(yīng)的 MAC 地址。
MAC( Media Access Control Address)地址是指網(wǎng)卡所屬的固定的地址
MIME,多部分對(duì)象集合(Multipurpose Internet Mail Extensions,多用途因特網(wǎng)郵件擴(kuò)展),它是一種允許處理文本、圖片、視頻等多種不同類型的數(shù)據(jù)。
第一章:了解 Web 及網(wǎng)絡(luò)基礎(chǔ)
在瀏覽器地址欄輸入 URL 時(shí),可以看到 Web 頁面。當(dāng)然 Web 頁面是不能憑空顯示出來,它需要根據(jù)指定的 URL 到服務(wù)器獲取文件資源,然后讓瀏覽器顯示 Web 頁面。
Web 使用一種名為 HTTP 的協(xié)議作為規(guī)范。HTTP 全稱 HyperText Transfer Protocol,超文本傳輸協(xié)議。
網(wǎng)絡(luò)基礎(chǔ) TCP/IP
TCP/IP 協(xié)議族
什么是協(xié)議?
定義如何探測(cè)到通信目標(biāo),由哪一方發(fā)起通信,使用什么語言通信,怎樣結(jié)束通信,不同的硬件、操作系統(tǒng)之間的通信的規(guī)則。
TCP/IP 是互聯(lián)網(wǎng)相關(guān)的各類協(xié)議族的總稱,包括各式內(nèi)容,從電纜規(guī)格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序、以及 Web 頁面顯示需要處理的步驟等
TCP/IP 的分層管理
TCP/IP 協(xié)議族分為4層:應(yīng)用層、傳輸層、網(wǎng)絡(luò)層和數(shù)據(jù)鏈路層
作用:
- 應(yīng)用層:決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng),HTTP 協(xié)議也處于該層
- 傳輸層:對(duì)上層應(yīng)用層,提供處于網(wǎng)絡(luò)連接中的兩臺(tái)計(jì)算機(jī)之間的數(shù)據(jù)傳輸
- 網(wǎng)絡(luò)層:又名網(wǎng)絡(luò)互聯(lián)層,用來處理在網(wǎng)絡(luò)上流動(dòng)的數(shù)據(jù)包
- 鏈路層:又名數(shù)據(jù)鏈路層、網(wǎng)絡(luò)接口層,用來處理連接網(wǎng)絡(luò)硬件部分(屬于硬件范圍)
TCP/IP 通信傳輸流
利用 TCP/IP 協(xié)議族進(jìn)行網(wǎng)絡(luò)通信時(shí),發(fā)送端(客戶端)從應(yīng)用層往下走,接收端(服務(wù)端)從鏈路層網(wǎng)上走
用 HTTP 舉例:
發(fā)送端在每層之間傳輸時(shí),會(huì)打上該層所屬的首部信息;接收端在曾與層之間傳輸時(shí),每經(jīng)過一層會(huì)刪除對(duì)應(yīng)的首部信息。
這種把數(shù)據(jù)包轉(zhuǎn)起來的做法叫做封裝
與 HTTP 關(guān)系密切的協(xié)議:IP、TCP 和 DNS
負(fù)責(zé)傳輸?shù)?IP 協(xié)議
TCP/IP 協(xié)議族中的 IP 指的是網(wǎng)際協(xié)議。IP 協(xié)議的作用是把各種數(shù)據(jù)包傳送給對(duì)方,要保證確實(shí)傳送到對(duì)方哪里,需要滿足各類條件。其中兩個(gè)重要條件是 IP 地址和 MAC 地址(Media Access Control Address)。
IP 地址指明了節(jié)點(diǎn)被分配到的地址,MAC 地址是指網(wǎng)卡所屬的固定的地址。IP 地址可以和 MAC 地址進(jìn)行配對(duì)。IP 地址可變換,MAC 地址基本不會(huì)變。
使用 ARP 協(xié)議憑借 MAC 地址進(jìn)行通信
IP 間的通信依賴 MAC 地址。在網(wǎng)絡(luò)上,通常是經(jīng)過多臺(tái)計(jì)算機(jī)和網(wǎng)絡(luò)設(shè)備中轉(zhuǎn)才能連接到對(duì)方,在中轉(zhuǎn)時(shí),會(huì)利用下一站中轉(zhuǎn)設(shè)備的 MAC 地址來搜索下一個(gè)中轉(zhuǎn)目標(biāo),這是會(huì)采用 ARP 協(xié)議
(Address Resolution Protocol)。ARP 協(xié)議是一種以解析地址的協(xié)議,根據(jù)通信雙方的 IP 地址就可以查出對(duì)應(yīng)的 MAC 地址。
確保可靠的 TCP 協(xié)議
TCP 協(xié)議位于傳輸層,提供可靠的字節(jié)流服務(wù),所謂字節(jié)流服務(wù)是將大塊數(shù)據(jù)分割層以報(bào)文段為單位的數(shù)據(jù)包進(jìn)行管理,方便傳輸。
為了確保準(zhǔn)確無誤的送達(dá)目的地,TCP 采用三次握手策略,數(shù)據(jù)發(fā)送出去之后,一定的會(huì)向?qū)Ψ酱_認(rèn)是否成功送達(dá)。握手的過程中采用 TCP 的標(biāo)志——SYN(synchronize)和 ACK(acknowledgement)。
發(fā)送端首先發(fā)送一個(gè)帶 SYN 標(biāo)志的數(shù)據(jù)包給對(duì)方;接收端收到后,回傳一個(gè)帶有 SYN/ACK 標(biāo)志的數(shù)據(jù)包以示表達(dá)確認(rèn)信息,最后發(fā)送端在回傳一個(gè)帶 ACK 標(biāo)志的數(shù)據(jù)包,代表握手結(jié)束。
如果某個(gè)階段莫名結(jié)束,TCP 協(xié)議會(huì)再次以相同順序發(fā)送相同的數(shù)據(jù)包。
負(fù)責(zé)域名解析的 DNS 服務(wù)
DNS(Domain Name System)服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)。
用戶通常通過域名來訪問網(wǎng)站,相比于 IP 地址,域名更符合人類的記憶習(xí)慣。DNS 服務(wù)便應(yīng)運(yùn)而生,逆向從 IP 地址反查域名服務(wù)。
各協(xié)議與 HTTP 協(xié)議的關(guān)系
URI 和 URL
URI(Uniform Resource Identifier)統(tǒng)一資源標(biāo)識(shí)符
URL(Uniform Resource Locator)統(tǒng)一資源定位符
- 登錄信息:指定用戶名和密碼作為服務(wù)器端獲取資源時(shí)必要的登錄信息(可選)
- 服務(wù)器地址:必須指定待訪問的服務(wù)器地址
- 服務(wù)器端口號(hào):指定服務(wù)器連接的網(wǎng)絡(luò)端口號(hào)(可選,省略的話使用默認(rèn)端口號(hào))
- 帶層次的文件路徑:指定服務(wù)器上的文件路徑來定位特指的資源
- 查詢字符串:針對(duì)已指定的文件路徑內(nèi)的資源,可以使用查詢字符串傳入任意參數(shù)(可選)
- 片斷標(biāo)識(shí)符:使用片段標(biāo)識(shí)符通常可標(biāo)記出以獲取資源中的資資源(可選)
第二章:簡(jiǎn)單的 HTTP 協(xié)議
請(qǐng)求訪問文本或圖像等資源的一端稱為客戶端,提供資源響應(yīng)的一端稱為服務(wù)器端。
HTTP 協(xié)議規(guī)定,請(qǐng)求從客戶端發(fā)出,服務(wù)端響應(yīng)該請(qǐng)求并返回。
請(qǐng)求報(bào)文是由請(qǐng)求方法、請(qǐng)求URI、協(xié)議版本、可選的請(qǐng)求首部字段和內(nèi)容實(shí)體構(gòu)成的。
響應(yīng)報(bào)文基本上由協(xié)議版本、狀態(tài)碼(表示成功或失敗的代碼)、以及解釋狀態(tài)碼的原因短語、可選的響應(yīng)首部字段以及實(shí)體主體構(gòu)成。
HTTP 不保存狀態(tài)協(xié)議
HTTP 是一種不保存狀態(tài),即無狀態(tài)協(xié)議。它自身不具備保存之前發(fā)送過的請(qǐng)求或響應(yīng)的功能,為了實(shí)現(xiàn)保持狀態(tài)的功能,引入了 Cookie 技術(shù)。
告知服務(wù)器意圖的 HTTP 方法
| GET | 獲取資源 | |
| POST | 傳輸實(shí)體主體 | |
| PUT | 傳輸文件 | |
| HEAD | 獲取報(bào)文首部 | |
| DELETE | 刪除文件 | 響應(yīng)返回的狀態(tài)碼是 204 |
| OPTIONS | 詢問支持的方法 | |
| TRACE | 追蹤路徑 | |
| CONNECT | 要求用隧道協(xié)議連接代理 |
向請(qǐng)求 URI 指定的資源發(fā)送請(qǐng)求報(bào)文時(shí),采用稱為方法的命令。方法名要用大寫字母。
持久連接節(jié)省通信量
在 HTTP 初始版本中,由于傳輸數(shù)據(jù)容量比較小,每進(jìn)行一次 HTTP 通信就要斷開一次 TCP 連接;
隨著 HTTP 普及,傳輸數(shù)據(jù)越來越大,未解決 TCP 連接問題,引入了持久連接(HTTP Persistent Connections,也成為 HTTP keep-alive 或 HTTP connection reuse),特點(diǎn)是:只要任意一端沒有明確提出斷開連接,則保持 TCP 連接狀態(tài)。
管線化
持久化連接是的多數(shù)請(qǐng)求以管線化方式發(fā)送稱為可能,可以同時(shí)并行發(fā)送多個(gè)請(qǐng)求,而不需要一個(gè)接一個(gè)等待響應(yīng)。
使用 Cookie 的狀態(tài)管理
Cookie 技術(shù)通過在請(qǐng)求和響應(yīng)報(bào)文中寫入 Cookie 信息來控制客戶端的狀態(tài)。
服務(wù)器在接受到請(qǐng)求后,在響應(yīng)報(bào)文內(nèi)加入 Set-Cookie,通知客戶端保存 Cookie,當(dāng)下次在發(fā)送請(qǐng)求時(shí),會(huì)在請(qǐng)求報(bào)文中加入 Cookie 后發(fā)送出去。服務(wù)器在根據(jù)發(fā)送過來的 Cookie 去對(duì)比,從而保存狀態(tài)信息。
第三章:HTTP 報(bào)文內(nèi)的 HTTP 信息
用于 HTTP 協(xié)議交互的信息被稱為 HTTP 報(bào)文,請(qǐng)求端(客戶端)的報(bào)文叫做請(qǐng)求報(bào)文,響應(yīng)端(服務(wù)端)的叫做響應(yīng)報(bào)文。
請(qǐng)求報(bào)文及響應(yīng)報(bào)文的結(jié)構(gòu)
HTTP 報(bào)文 大致可分為報(bào)文首部和報(bào)文主體,兩者之間由空行(CR+LF)來劃分。
請(qǐng)求報(bào)文
響應(yīng)報(bào)文
- 請(qǐng)求行:包含用于請(qǐng)求的方法,請(qǐng)求 URI 和 HTTP 版本
- 狀態(tài)行:包含表明響應(yīng)結(jié)果的狀態(tài)碼,原因短語和 HTTP 版本
- 首部字段:包含表明請(qǐng)求和響應(yīng)的各種條件和屬性的各類首部,一般有4種首部:通用首部、請(qǐng)求首部、響應(yīng)首部、實(shí)體首部
- 其他:可能包含 HTTP 的 RFC 里未定義 的首部,如:Cookie
編碼提升傳輸速率
HTTP 在傳輸數(shù)據(jù)時(shí)可以按照數(shù)據(jù)原貌直接傳輸,也可以在傳輸時(shí)通過編碼提升傳輸速率,但這樣會(huì)消耗更多的 CPU 等資源
報(bào)文主體和實(shí)體主體的差異
- 報(bào)文:是 HTTP 通信中的基本單位,由8位組字節(jié)流(octet sequence,其中 octet 為8個(gè)比特)組成,通過 HTTP 通信傳輸。
- 實(shí)體:作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)(補(bǔ)充項(xiàng))被傳輸,其內(nèi)容由實(shí)體首部和實(shí)體主體組成。
通常報(bào)文主體等于實(shí)體主體,只有當(dāng)傳輸中進(jìn)行編碼操作時(shí),實(shí)體主體的內(nèi)容發(fā)生變化才會(huì)導(dǎo)致它和報(bào)文主體產(chǎn)生差異。
壓縮傳輸?shù)膬?nèi)容編碼
內(nèi)容編碼指明應(yīng)用在實(shí)體內(nèi)容上的編碼格式,并保存實(shí)體信息原樣壓縮。內(nèi)容編碼后的實(shí)體由客戶端接收并負(fù)責(zé)編碼。
常用的內(nèi)容編碼
- gzip(GNU zip)
- compress(UNIX 系統(tǒng)的標(biāo)準(zhǔn)壓縮)
- deflate(zlib)
- identity(不進(jìn)行編碼)
分割發(fā)送的分塊傳輸編碼
在 HTTP 通信過程中,在傳輸大容量數(shù)據(jù)時(shí),通過把數(shù)據(jù)分割成多塊,能夠讓瀏覽器逐步顯示頁面的功能稱為分塊傳輸編碼(Chunked Transfer Coding)。
發(fā)送多種數(shù)據(jù)的多部分對(duì)象集合
HTTP 協(xié)議采用了多部分對(duì)象集合——MIME機(jī)制(Multipurpose Internet Mail Extensions,多用途因特網(wǎng)郵件擴(kuò)展),它是一種允許處理文本、圖片、視頻等多種不同類型的數(shù)據(jù)。
在 HTTP 報(bào)文中使用 多部分對(duì)象集合時(shí),需要在首部字段里加上 Content-type,使用 boundary 字符串來劃分各個(gè)實(shí)體的起始行,需要在起始行前插入 "--" 標(biāo)記,,最后以 "--" 結(jié)束。
獲取部分內(nèi)容的范圍請(qǐng)求
指定范圍發(fā)送的請(qǐng)求叫做范圍請(qǐng)求
執(zhí)行范圍請(qǐng)求會(huì)用到首部字段 Range 來指定資源的 byte 范圍
請(qǐng)求: Range: bytes = 5001-10000響應(yīng): Content-Range: bytes 5001-10000/10000針對(duì)范圍請(qǐng)求,響應(yīng)會(huì)返回狀態(tài)碼為 206 Partial Content 的響應(yīng)報(bào)文,如果服務(wù)器無法響應(yīng)范圍請(qǐng)求,則會(huì)返回狀態(tài)碼 200 OK 和完成的實(shí)體內(nèi)容。
內(nèi)容協(xié)商返回最合適的內(nèi)容
同一個(gè) Web 網(wǎng)站可能會(huì)存在多份相同內(nèi)容的頁面,比如英文版和中文版,當(dāng)瀏覽器默認(rèn)語言為中文時(shí),訪問 URI 的 Web 頁面時(shí),則會(huì)顯示中文版的 Web 頁面,這種機(jī)制稱為內(nèi)容協(xié)商(Content Negotiation)。
內(nèi)容協(xié)商機(jī)制會(huì)在請(qǐng)求報(bào)文中用到下面首部字段:
- Accept
- Accept-Charset
- Accept-Encoding
- Accept-Language
- Content-Language
內(nèi)容協(xié)商技術(shù)有3種類型:
- 服務(wù)器驅(qū)動(dòng)協(xié)商:由服務(wù)器端進(jìn)行內(nèi)容協(xié)商。以請(qǐng)求的首部字段為參考,在服務(wù)端自動(dòng)處理。
- 客戶端驅(qū)動(dòng)協(xié)商:由客戶端進(jìn)行內(nèi)容協(xié)商。用戶利用瀏覽器提供的可選項(xiàng)列表手動(dòng)選擇;還可以利用 JavaScript 腳本在 Web 頁面上自動(dòng)進(jìn)行選擇。
- 透明協(xié)商:是服務(wù)器驅(qū)動(dòng)和客戶端驅(qū)動(dòng)的結(jié)合體,是由服務(wù)器端和客戶端各自進(jìn)行內(nèi)容協(xié)商的一種方法。
第四章:返回結(jié)果的 HTTP 狀態(tài)碼
狀態(tài)碼告知從服務(wù)器端返回的請(qǐng)求結(jié)果
狀態(tài)碼的職責(zé)是當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求時(shí),描述返回的請(qǐng)求結(jié)果。
狀態(tài)碼由三位數(shù)字和原因短語組成,其中數(shù)字第一位指定了相應(yīng)類別,后兩位無分類。
| 1XX | Informational(信息性狀態(tài)碼) | 接收的請(qǐng)求正在處理 |
| 2XX | Success(成功狀態(tài)碼) | 請(qǐng)求正常處理完畢 |
| 3XX | Redirection(重定向狀態(tài)碼) | 需要進(jìn)行附加操作以完成請(qǐng)求 |
| 4XX | Client Error(客戶端錯(cuò)誤狀態(tài)碼) | 服務(wù)器無法處理請(qǐng)求 |
| 5XX | Server Error(服務(wù)器錯(cuò)誤狀態(tài)碼) | 服務(wù)器處理請(qǐng)求出錯(cuò) |
狀態(tài)碼
2XX 成功:表示請(qǐng)求被正常處理了
- 200 OK 表示從客戶端發(fā)來的請(qǐng)求在服務(wù)器端被正常處理了。
- 204 No Content 請(qǐng)求處理成功,返回的響應(yīng)報(bào)文中不含實(shí)體的主體部分
- 206 Partial Content 表示客戶端進(jìn)行范圍請(qǐng)求
3XX 重定向:表明瀏覽器需要執(zhí)行某些特殊處理以正確處理請(qǐng)求
- 301 Moved Permanently 永久重定向
- 302 Found 臨時(shí)重定向
- 303 See Other 表示由于請(qǐng)求對(duì)應(yīng)的資源存在著另一個(gè) URI,應(yīng)使用 GET 方法定向獲取請(qǐng)求的資源
- 304 Not Modified 表示客戶端發(fā)送附帶條件的請(qǐng)求,服務(wù)器端允許請(qǐng)求訪問資源,但因發(fā)生請(qǐng)求未滿足條件的情況后,直接返回 304 Not Modified。304 狀態(tài)碼返回時(shí),不包含任何響應(yīng)的主體部分,304 雖然被劃分在 3XX 類別中,但和重定向沒有關(guān)系
- 307 Temporary Redirect 臨時(shí)重定向,和 302 差不多,它不會(huì)把 POST 變成 GET
4XX 客戶端錯(cuò)誤:表明客戶端發(fā)生錯(cuò)誤的原因所在
- 400 Bad Request:表示請(qǐng)求報(bào)文中存在語法錯(cuò)誤
- 401 Unauthorized:表示發(fā)送的請(qǐng)求需要有通過 HTTP 認(rèn)證的認(rèn)證信息
- 403 Forbidden:表示請(qǐng)求資源被服務(wù)器拒絕了
- 400 Not Found:表示服務(wù)器上無法找到請(qǐng)求資源
5XX 服務(wù)器錯(cuò)誤:表明服務(wù)器本身發(fā)生錯(cuò)誤
- 500 Internal Server Error:表示服務(wù)器在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤
- 503 Serveice Unavailable:表示服務(wù)器暫時(shí)處于超負(fù)荷或正在停機(jī)維護(hù),無法處理請(qǐng)求。
第五章:與 HTTP 協(xié)作的 Web 服務(wù)器
HTTP/1.1 允許一臺(tái) HTTP 服務(wù)器搭建多個(gè) Web 站點(diǎn)
在互聯(lián)網(wǎng)上,域名通過 DNS 服務(wù)映射到 IP 地址之后訪問目標(biāo)網(wǎng)站,在相同 IP 下,發(fā)送 HTTP 請(qǐng)求時(shí),必須在 Host 首部?jī)?nèi)完整指定主機(jī)名和域名的 URI
通信數(shù)據(jù)轉(zhuǎn)發(fā)程序:代理、網(wǎng)關(guān)、隧道
- 代理:是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序,它扮演了位于服務(wù)器和客戶端“中間人”的角色
- 網(wǎng)關(guān):網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器,接受從客戶端發(fā)來的請(qǐng)求時(shí),它就像自己擁有資源的源服務(wù)器一樣對(duì)請(qǐng)求進(jìn)行處理
- 隧道:相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn),并保持雙方通信連接的應(yīng)用程序
代理
使用代理服務(wù)器的理由:利用緩存技術(shù)減少網(wǎng)絡(luò)帶寬的流量,組織內(nèi)部針對(duì)特定網(wǎng)站的訪問控制,以獲取訪問日志為主要目的
緩存代理:代理轉(zhuǎn)發(fā)時(shí),緩存代理會(huì)預(yù)先將資源的副本緩存到代理服務(wù)器上,當(dāng)代理再次接收到相同資源的請(qǐng)求時(shí),就可以不從源服務(wù)器那里獲取資源,而是將緩存的資源作為響應(yīng)返回
透明代理:轉(zhuǎn)發(fā)請(qǐng)求或響應(yīng)時(shí),不對(duì)報(bào)文做任何加工的代理類型稱為透明代理
網(wǎng)關(guān):
網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非 HTTP 協(xié)議服務(wù)。
利用網(wǎng)關(guān)能提高通信的安全性
隧道
隧道的目的是確保客戶端能與服務(wù)器進(jìn)行安全的通信,隧道本身不會(huì)去解析 HTTP 請(qǐng)求,隧道會(huì)在通信雙方斷開連接時(shí)結(jié)束
保存資源的緩存
緩存是指代理服務(wù)器或客戶端本地磁盤內(nèi)保存的資源副本。利用緩存可減少對(duì)源服務(wù)器的訪問,因此也節(jié)省了通信流量和通信時(shí)間。
緩存的有效期
緩存服務(wù)器內(nèi)緩存室友有效期的,如果資源更新,緩存就沒有用了,需要重新獲取新的資源
客戶端的緩存同緩存服務(wù)器一樣
第六章:HTTP 首部
HTTP 協(xié)議的請(qǐng)求和響應(yīng)報(bào)文中必須必定包含 HTTP 首部。首部?jī)?nèi)容為請(qǐng)求或響應(yīng)所需要的信息
HTTP 請(qǐng)求報(bào)文由方法、URI、HTTP 版本、HTTP 首部字段等部分構(gòu)成
HTTP 響應(yīng)報(bào)文由 HTTP 版本、狀態(tài)碼、HTTP 首部字段組成
HTTP 首部字段
HTTP 首部字段是構(gòu)成 HTTP 報(bào)文的要素之一。使用首部字段是為了給瀏覽器和服務(wù)器提供報(bào)文主體大小、所使用的語言、認(rèn)證信息等內(nèi)容。
4種 HTTP 首部字段類型
- 通用首部字段:請(qǐng)求報(bào)文和響應(yīng)報(bào)文都會(huì)使用的首部
- 請(qǐng)求首部字段:從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部
- 響應(yīng)首部字段:從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部
- 實(shí)體首部字段:針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部
通用首部字段
| 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é)范圍 |
| 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í)間 |
第七章:確保 Web 安全的 HTTPS
HTTP的缺點(diǎn):
- 通信使用明文(不加密),內(nèi)容可能會(huì)被竊聽
- 不驗(yàn)證通信方的身份,因此有可能遭遇偽裝
- 無法證明報(bào)文的完整性,所以有可能已遭篡改
通信的加密
HTTP 和 SSL(Secure Socket Layer,安全套連接)或 TLS(Transport Layer Security,安全傳輸層協(xié)議)組合使用,被稱為 HTTPS(HTTP Secure,超文本傳輸安全協(xié)議)
內(nèi)容的加密
把 HTTP 報(bào)文里所含的內(nèi)容進(jìn)行加密,前提需要客戶端和服務(wù)器同時(shí)具備加密和解密機(jī)制
HTTP + 加密 + 認(rèn)證 + 完整性保護(hù) = HTTPS
未完待續(xù)...
總結(jié)
以上是生活随笔為你收集整理的《图解 HTTP》读书笔记(未完待续)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 怎样用原生js配合css的transit
- 下一篇: Unexpected end of JS