第一章
IP協(xié)議
ip協(xié)議里重要的是IP地址和MAC地址
使用 ARP 協(xié)議憑借 MAC 地址進(jìn)行通信
“（Address Resolution Protocol）。ARP 是一種用以解析地址的協(xié)議愈涩，根據(jù)通信方的 IP 地址就可以反查出對(duì)應(yīng)的 MAC 地址焚廊。”
TCP
“按層次分荧缘，TCP 位于傳輸層，提供可靠的字節(jié)流服務(wù)。
所謂的字節(jié)流服務(wù)（Byte Stream Service）是指推溃，為了方便傳輸，將大塊數(shù)據(jù)分割成以報(bào)文段（segment）為單位的數(shù)據(jù)包進(jìn)行管理届腐。而可靠的傳輸服務(wù)是指铁坎，能夠把數(shù)據(jù)準(zhǔn)確可靠地傳給對(duì)方”
DNS（Domain Name System）
“DNS（Domain Name System）服務(wù)是和 HTTP 協(xié)議一樣位于應(yīng)用層的協(xié)議。它提供域名到 IP 地址之間的解析服務(wù)犁苏∮财迹”
URI 和 URL
URL（Uniform Resource Locator）是URI（Uniform Resource Identifier）的子集
URI 格式
“第 2 章 簡(jiǎn)單的 HTTP 協(xié)議”
http為無(wú)狀態(tài)協(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ā)送過(guò)的請(qǐng)求或響應(yīng)都不做持久化處理÷蛐撸”
持久連接
管線(xiàn)化袁勺，并發(fā)請(qǐng)求
“第 3 章 HTTP 報(bào)文內(nèi)的 ”
“HTTP 報(bào)文本身是由多行（用 CR+LF 作換行符）數(shù)據(jù)構(gòu)成的字符串文本⌒笃眨”
“HTTP 報(bào)文大致可分為報(bào)文首部和報(bào)文主體兩塊期丰。兩者由最初出現(xiàn)的空行（CR+LF）來(lái)劃分。通常漠嵌，并不一定要有報(bào)文主體咐汞。”
- 報(bào)文（message）
是 HTTP 通信中的基本單位儒鹿，由 8 位組字節(jié)流（octet sequence化撕，其中 octet 為 8 個(gè)比特）組成，通過(guò) HTTP 通信傳輸约炎。
- 實(shí)體（entity）
作為請(qǐng)求或響應(yīng)的有效載荷數(shù)據(jù)（補(bǔ)充項(xiàng)）被傳輸植阴，其內(nèi)容由實(shí)體首部和實(shí)體主體組成』常”
HTTP 報(bào)文的主體用于傳輸請(qǐng)求或響應(yīng)的實(shí)體主體掠手。
通常，報(bào)文主體等于實(shí)體主體狸捕。只有當(dāng)傳輸中進(jìn)行編碼操作時(shí)喷鸽，實(shí)體主體的內(nèi)容發(fā)生變化，才導(dǎo)致它和報(bào)文主體產(chǎn)生差異灸拍。
發(fā)送多種數(shù)據(jù)的多部分對(duì)象集合
- multipart/form-data
在 Web 表單文件上傳時(shí)使用做祝。
- multipart/byteranges
狀態(tài)碼 206（Partial Content，部分內(nèi)容）響應(yīng)報(bào)文包含了多個(gè)范圍的內(nèi)容時(shí)使用鸡岗。
- multipart/form-data
“Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="field1"
Joe Blow
--AaB03x
Content-Disposition: form-data; name="pics"; filename="file1.txt"
Content-Type: text/plain
...（file1.txt的數(shù)據(jù)）...”
摘錄來(lái)自: 上野宣混槐、于均良. “圖解HTTP”。 iBooks.
- multipart/byteranges
HTTP/1.1 206 Partial Content
Date: Fri, 13 Jul 2012 02:45:26 GMT
Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000
...（范圍指定的數(shù)據(jù)）...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000
...（范圍指定的數(shù)據(jù)）...
--THIS_STRING_SEPARATES--
使用 boundary 字符串來(lái)劃分多部分對(duì)象集合指明的各類(lèi)實(shí)體轩性。在 boundary 字符串指定的各個(gè)實(shí)體的起始行之前插入“--”標(biāo)記（例如：--AaB03x声登、--THIS_STRING_SEPARATES），而在多部分對(duì)象集合對(duì)應(yīng)的字符串的最后插入“--”標(biāo)記（例如：--AaB03x--揣苏、--THIS_STRING_SEPARATES--）作為結(jié)束悯嗓。
“第 4 章 返回結(jié)果的 HTTP 狀態(tài)碼”
2XX
- 200 OK
- 204 No Content
- 206 Part Content
3XX 重定向
301 Moved Permanently
永久性重定向。該狀態(tài)碼表示請(qǐng)求的資源已被分配了新的 URI舒岸，以后應(yīng)使用資源現(xiàn)在所指的 URI302 Found
臨時(shí)性重定向.該狀態(tài)碼表示請(qǐng)求的資源已被分配了新的 URI绅作，希望用戶(hù)（本次）能使用新的 URI 訪(fǎng)問(wèn)。
和 301 Moved Permanently 狀態(tài)碼相似蛾派，但 302 狀態(tài)碼代表的資源不是被永久移動(dòng)俄认，只是臨時(shí)性質(zhì)的个少。換句話(huà)說(shuō)，已移動(dòng)的資源對(duì)應(yīng)的 URI 將來(lái)還有可能發(fā)生改變眯杏。
- 303 See Other
該狀態(tài)碼表示由于請(qǐng)求對(duì)應(yīng)的資源存在著另一個(gè) URI夜焦，應(yīng)使用 GET 方法定向獲取請(qǐng)求的資源。
當(dāng) 301岂贩、302茫经、303 響應(yīng)狀態(tài)碼返回時(shí)，幾乎所有的瀏覽器都會(huì)把 POST 改成 GET萎津，并刪除請(qǐng)求報(bào)文內(nèi)的主體卸伞，之后請(qǐng)求會(huì)自動(dòng)再次發(fā)送。
301锉屈、302 標(biāo)準(zhǔn)是禁止將 POST 方法改變成 GET 方法的荤傲，但實(shí)際使用時(shí)大家都會(huì)這么做。
4XX 客戶(hù)端錯(cuò)誤
400 Bad Request
該狀態(tài)碼表示請(qǐng)求報(bào)文中存在語(yǔ)法錯(cuò)誤颈渊。當(dāng)錯(cuò)誤發(fā)生時(shí)遂黍，需修改請(qǐng)求的內(nèi)容后再次發(fā)送請(qǐng)求。另外俊嗽，瀏覽器會(huì)像 200 OK 一樣對(duì)待該狀態(tài)碼雾家。401 Unauthorized
該狀態(tài)碼表示發(fā)送的請(qǐng)求需要有通過(guò) HTTP 認(rèn)證（BASIC 認(rèn)證、DIGEST 認(rèn)證）的認(rèn)證信息绍豁。另外若之前已進(jìn)行過(guò) 1 次請(qǐng)求芯咧，則表示用 戶(hù)認(rèn)證失敗。
返回含有 401 的響應(yīng)必須包含一個(gè)適用于被請(qǐng)求資源的
WWW-Authenticate 首部用以質(zhì)詢(xún)（challenge）用戶(hù)信息竹揍。當(dāng)瀏覽器初次接收到 401 響應(yīng)唬党，會(huì)彈出認(rèn)證用的對(duì)話(huà)窗口。403 Forbidden
該狀態(tài)碼表明對(duì)請(qǐng)求資源的訪(fǎng)問(wèn)被服務(wù)器拒絕了鬼佣。服務(wù)器端沒(méi)有必要給出拒絕的詳細(xì)理由，但如果想作說(shuō)明的話(huà)霜浴，可以在實(shí)體的主體部分對(duì)原因進(jìn)行描述晶衷，這樣就能讓用戶(hù)看到了。404 Not Found
該狀態(tài)碼表明服務(wù)器上無(wú)法找到請(qǐng)求的資源阴孟。除此之外晌纫，也可以在服務(wù)器端拒絕請(qǐng)求且不想說(shuō)明理由時(shí)使用。
5XX 服務(wù)器錯(cuò)誤
500 Internal Server Error
該狀態(tài)碼表明服務(wù)器端在執(zhí)行請(qǐng)求時(shí)發(fā)生了錯(cuò)誤永丝。也有可能是 Web 應(yīng)用存在的 bug 或某些臨時(shí)的故障锹漱。503 Service Unavailable
該狀態(tài)碼表明服務(wù)器暫時(shí)處于超負(fù)載或正在進(jìn)行停機(jī)維護(hù)，現(xiàn)在無(wú)法處理請(qǐng)求慕嚷。如果事先得知解除以上狀況需要的時(shí)間哥牍，最好寫(xiě)入 RetryAfter 首部字段再返回給客戶(hù)端毕泌。
狀態(tài)碼和狀況的不一致
不少返回的狀態(tài)碼響應(yīng)都是錯(cuò)誤的，但是用戶(hù)可能察覺(jué)不到這點(diǎn)嗅辣。比如 Web 應(yīng)用程序內(nèi)部發(fā)生錯(cuò)誤撼泛，狀態(tài)碼依然返回 200 OK，這種情況也經(jīng)常遇到澡谭。
第 5 章 與 HTTP 協(xié)作的 Web 服務(wù)器
用單臺(tái)虛擬主機(jī)實(shí)現(xiàn)多個(gè)域名
通信數(shù)據(jù)轉(zhuǎn)發(fā)程序 ：代理愿题、網(wǎng)關(guān)、隧道
代理
代理服務(wù)器的基本行為就是接收客戶(hù)端發(fā)送的請(qǐng)求后轉(zhuǎn)發(fā)給其他服務(wù)器蛙奖。代理不改變請(qǐng)求 URI潘酗，會(huì)直接發(fā)送給前方持有資源的目標(biāo)服務(wù)器。
緩存代理
透明代理 不對(duì)報(bào)文加工
非透明代理 對(duì)報(bào)文加工
網(wǎng)關(guān)
保存資源的緩存
緩存是指代理服務(wù)器或客戶(hù)端本地磁盤(pán)內(nèi)保存的資源副本雁仲。利用緩存可減少對(duì)源服務(wù)器的訪(fǎng)問(wèn)仔夺，因此也就節(jié)省了通信流量和通信時(shí)間。
第 6 章 HTTP 首部
HTTP 報(bào)文首部
請(qǐng)求報(bào)文
響應(yīng)報(bào)文
HTTP 首部字段
使用首部字段是為了給瀏覽器和服務(wù)器提供報(bào)文主體大小伯顶、所使用的語(yǔ)言囚灼、認(rèn)證信息等內(nèi)容。
4 種 HTTP 首部字段類(lèi)型
HTTP 首部字段根據(jù)實(shí)際用途被分為以下 4 種類(lèi)型祭衩。
- 通用首部字段（General Header Fields）
請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部灶体。
- 請(qǐng)求首部字段（Request Header Fields）
從客戶(hù)端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部。補(bǔ)充了請(qǐng)求的附加內(nèi)容掐暮、客戶(hù)端信息蝎抽、響應(yīng)內(nèi)容相關(guān)優(yōu)先級(jí)等信息。
Accept
文本文件
text/html, text/plain, text/css ...
application/xhtml+xml, application/xml ...
圖片文件
image/jpeg, image/gif, image/png ...
視頻文件
video/mpeg, video/quicktime ...
應(yīng)用程序使用的二進(jìn)制文件
application/octet-stream, application/zip ..
若想要給顯示的媒體類(lèi)型增加優(yōu)先級(jí)路克，則使用 q= 來(lái)額外表示權(quán)重值 1樟结，用分號(hào)（;）進(jìn)行分隔。權(quán)重值 q 的范圍是 0~1（可精確到小數(shù)點(diǎn)后 3 位）精算，且 1 為最大值瓢宦。不指定權(quán)重 q 值時(shí)，默認(rèn)權(quán)重為 q=1.0灰羽。
Accept-Encoding
Authorization
Host
首部字段 Host 和以單臺(tái)服務(wù)器分配多個(gè)域名的虛擬主機(jī)的工作機(jī)制有很密切的關(guān)聯(lián)，這是首部字段 Host 必須存在的意義廉嚼。
If-match
If-Modified-Since
If-None-Match
在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資源玫镐。因此，這與使用首部字段 If-Modified-Since 時(shí)有些類(lèi)似怠噪。
If-Range
If-Unmodified-Since
首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反恐似。
Max-Forwards
防止無(wú)限轉(zhuǎn)發(fā)，也可以
Referer
因?yàn)樵假Y源的 URI 中的查詢(xún)字符串可能含有 ID 和密碼等保密信息傍念，要是寫(xiě)進(jìn) Referer 轉(zhuǎn)發(fā)給其他服務(wù)器矫夷，則有可能導(dǎo)致保密信息的泄露葛闷。
TE
首部字段 TE 會(huì)告知服務(wù)器客戶(hù)端能夠處理響應(yīng)的傳輸編碼方式及相對(duì)優(yōu)先級(jí)。它和首部字段 Accept-Encoding 的功能很相像口四，但是用于傳輸編碼
首部字段 TE 除指定傳輸編碼之外孵运，還可以指定伴隨 trailer 字段的分塊傳輸編碼的方式。應(yīng)用后者時(shí)蔓彩，只需把 trailers 賦值給該字段值治笨。
- 響應(yīng)首部字段（Response Header Fields）
從服務(wù)器端向客戶(hù)端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容赤嚼，也會(huì)要求客戶(hù)端附加額外的內(nèi)容信息旷赖。
Accept-Ranges
Age
ETag
Proxy-Authenticate
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate
- 實(shí)體首部字段（Entity Header Fields）
針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息更卒。
Allow
首部字段 Allow 用于通知客戶(hù)端能夠支持 Request-URI 指定資源的所有 HTTP 方法等孵。當(dāng)服務(wù)器接收到不支持的 HTTP 方法時(shí)，會(huì)以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回蹂空。與此同時(shí)俯萌，還會(huì)把所有能支持的 HTTP 方法寫(xiě)入首部字段 Allow 后返回。
Content-Encoding
首部字段 Content-Encoding 會(huì)告知客戶(hù)端服務(wù)器對(duì)實(shí)體的主體部分選用的內(nèi)容編碼方式上枕。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮咐熙。
gzip
compress
deflate
identity
Content-Language
Content-Length
首部字段 Content-Length 表明了實(shí)體主體部分的大小（單位是字節(jié)）辨萍。對(duì)實(shí)體主體進(jìn)行內(nèi)容編碼傳輸時(shí)棋恼，不能再使用 Content-Length 首部字段。由于實(shí)體主體大小的計(jì)算方法略微復(fù)雜锈玉，所以在此不再展開(kāi)爪飘。讀者若想一探究竟，可參考 RFC2616 的 4.4拉背。
Content-MD5
Content-Range
Content-Type
Expire
源服務(wù)器不希望緩存服務(wù)器對(duì)資源緩存時(shí)师崎，最好在 Expires 字段內(nèi)寫(xiě)入與首部字段 Date 相同的時(shí)間值。
但是椅棺，當(dāng)首部字段 Cache-Control 有指定 max-age 指令時(shí)抡诞，比起首部字段 Expires，會(huì)優(yōu)先處理 max-age 指令土陪。
Last-Modified
- 為 Cookie 服務(wù)的首部字段
![Upload Paste_Image.png failed. Please try again.]
第 7 章 確保 Web 安全的 HTTPS
HTTP+ 加密 + 認(rèn)證 + 完整性保護(hù) =HTTPS
HTTPS 并非是應(yīng)用層的一種新協(xié)議。只是 HTTP 通信接口部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協(xié)議代替而已肴熏。
通常鬼雀，HTTP 直接和 TCP 通信。當(dāng)使用 SSL 時(shí)蛙吏，則演變成先和 SSL 通信源哩，再由 SSL 和 TCP 通信了鞋吉。簡(jiǎn)言之，所謂 HTTPS励烦，其實(shí)就是身披 SSL 協(xié)議這層外殼的 HTTP谓着。
HTTPS 采用混合加密機(jī)制
HTTPS 采用共享密鑰加密和公開(kāi)密鑰加密兩者并用的混合加密機(jī)制。若密鑰能夠?qū)崿F(xiàn)安全交換坛掠，那么有可能會(huì)考慮僅使用公開(kāi)密鑰加密來(lái)通信赊锚。但是公開(kāi)密鑰加密與共享密鑰加密相比，其處理速度要慢屉栓。
所以應(yīng)充分利用兩者各自的優(yōu)勢(shì)舷蒲，將多種方法組合起來(lái)用于通信。在交換密鑰環(huán)節(jié)使用公開(kāi)密鑰加密方式友多，之后的建立通信交換報(bào)文階段則使用共享密鑰加密方式牲平。
第 8 章 確認(rèn)訪(fǎng)問(wèn)用戶(hù)身份的認(rèn)證
HTTP 使用的認(rèn)證方式
HTTP/1.1 使用的認(rèn)證方式如下所示。
BASIC 認(rèn)證（基本認(rèn)證）
DIGEST 認(rèn)證（摘要認(rèn)證）
SSL 客戶(hù)端認(rèn)證
FormBase 認(rèn)證（基于表單認(rèn)證）
Session 管理及 Cookie 應(yīng)用
一般會(huì)使用 Cookie 來(lái)管理 Session（會(huì)話(huà)）域滥。
基于表單認(rèn)證本身是通過(guò)服務(wù)器端的 Web 應(yīng)用纵柿，將客戶(hù)端發(fā)送過(guò)來(lái)的用戶(hù) ID 和密碼與之前登錄過(guò)的信息做匹配來(lái)進(jìn)行認(rèn)證的。
但鑒于 HTTP 是無(wú)狀態(tài)協(xié)議启绰，之前已認(rèn)證成功的用戶(hù)狀態(tài)無(wú)法通過(guò)協(xié)議層面保存下來(lái)昂儒。即，無(wú)法實(shí)現(xiàn)狀態(tài)管理酬土，因此即使當(dāng)該用戶(hù)下一次繼續(xù)訪(fǎng)問(wèn)荆忍，也無(wú)法區(qū)分他與其他的用戶(hù)。于是我們會(huì)使用 Cookie 來(lái)管理 Session撤缴，以彌補(bǔ) HTTP 協(xié)議中不存在的狀態(tài)管理功能刹枉。
如果 Session ID 被第三方盜走，對(duì)方就可以偽裝成你的身份進(jìn)行惡意操作了屈呕。因此必須防止 Session ID 被盜微宝，或被猜出。為了做到這點(diǎn)虎眨，Session ID 應(yīng)使用難以推測(cè)的字符串蟋软，且服務(wù)器端也需要進(jìn)行有效期的管理，保證其安全性嗽桩。
另外岳守，為減輕跨站腳本攻擊（XSS）造成的損失，建議事先在 Cookie 內(nèi)加上 httponly 屬性碌冶。
使用瀏覽器進(jìn)行全雙工通信的 WebSocket
WebSocket湿痢，即 Web 瀏覽器與 Web 服務(wù)器之間全雙工通信標(biāo)準(zhǔn)。其中，WebSocket 協(xié)議由 IETF 定為標(biāo)準(zhǔn)譬重，WebSocket API 由 W3C 定為標(biāo)準(zhǔn)拒逮。仍在開(kāi)發(fā)中的 WebSocket 技術(shù)主要是為了解決 Ajax 和 Comet 里 XMLHttpRequest 附帶的缺陷所引起的問(wèn)題。
由于是建立在 HTTP 基礎(chǔ)上的協(xié)議臀规，因此連接的發(fā)起方仍是客戶(hù)端滩援，而一旦確立 WebSocket 通信連接，不論服務(wù)器還是客戶(hù)端塔嬉，任意一方都可直接向?qū)Ψ桨l(fā)送報(bào)文玩徊。
