讀書筆記_圖解HTTP

圖解HTTP 上野宣2014年

閱讀順序應爲:《圖解HTTP》->《HTTP權威指南》->《TCP/IP詳解》
《圖解HTTP》下載地址:
http://www.java1234.com/a/javabook/javabase/2017/0712/8420.html
截止2017.10.14,HTTP協議版本爲1.1,HTTP/2.0還在開發中。

第1章 瞭解Web及網絡基礎

  • HTTP依賴於IP、TCP、DNS。

  • 標準的URI協議方案有30種左右,如ftp、http、ldap、mailto、news、tel、telnet、urn等。

  • URI格式:
    http://user:[email protected]:80/dir/index.html?uid=1#ch1
    協議方案名:登錄信息@服務器地址:服務器端口號/帶層次的文件路徑?查詢字符串#片段標識符。

第2章 簡單的HTTP協議

  • 請求報文結構:方法、URL、協議版本、請求首部字段(Host、Connection、Content-Type、Content-Length)、內容實體。

  • 響應報文結構:協議版本、狀態碼、狀態碼的原因短語、響應首部字段(Date、Content-Length、Content-type),主體。

  • HTTP是無狀態了,但是爲了實現期望保持狀態功能,於是引入了Cookie技術。

  • HTTP方法:GET(獲取資源),POST(傳輸實體主體),PUT(傳輸文件),HEAD(獲得報文首部),DELETE(刪除文件),OPTIONS(詢問支持的方法),TRACE(追蹤路徑,不常用且容易引發XST攻擊),CONNECT(要求用隧道協議連接代理,主要是SSL和TLS)。PUT和DELETE不帶驗證機制。

  • 持久連接節省通信量,只要任意一段沒有明確提出斷開連接則保持TCP連接狀態。

  • 管線化方式發送,基於持久連接,可以同時並行發送多個請求。

  • 使用Cookie的狀態管理。

第3章 HTTP報文內的HTTP信息

  • HTTP報文大致可以分爲報文首部和報文主體兩塊,有空行CR+LF劃分(CR(Carriage Return,回車符:16進制0x0d)和LF(Line Feed,換行符,16進制0x0a))。
  • 請求報文首部:請求行、請求首部字段、通用首部字段。實體首部字段,其他。
  • 響應報文首部:狀態行、響應首部字段、通用首部字段、實體首部字段、其他。
  • 編碼提升傳輸速率。常用的內容編碼有:gzip(GNU zip), compress(UNIX系統的標準壓縮),deflate(zlib),identity(不進行編碼)。分割發送的分塊傳輸編碼。
  • 多部分對象集合:multipart/form-data(Web表單文件上傳時使用)、multipart/byteranges(狀態碼206(Partial Content,部分內容)相應報文包含了多個範圍的內容時使用),首部字段需要加上Content-type。

  • 獲取部分內容的範圍請求(Range Request):5001~10000字節爲Range: bytes=5001-10000,從5001字節之後全部的爲Range: bytes=5001-,從一開始到3000字節和5000~7000字節的多重範圍爲Range: byte=-3000, 5000-7000。針對範文請求,響應會返回狀態碼爲206 Partial Content的響應報文,對於多重反胃的範圍請求,響應會在首部字段Content-Type標明multipart/byteranges後返回響應報文,如果服務器端無法響應範圍請求則會返回狀態碼200 OK和完整的實體內容。

  • 內容協商(Content Negotiation)返回最合適的內容(如英語版和中文版的Web頁面)。判斷基準有:Accept、Accept-Charset、Accept-Encoding、Accept-Language、Content-Language。內容協商技術有3種類型:服務器驅動協商(服務器端自動處理),客戶端驅動協商(用戶選擇或者JavaScript選擇或者按照OS類型或者瀏覽器類型),透明協商(服務器端驅動和客戶端驅動的結合體,各自進行內容協商)。

第4章 返回結果的HTTP狀態碼

  • 狀態碼:告知從服務器端返回的請求結果。

  • 狀態碼類別:1XX,Informational(信息性狀態碼),接收的請求正在處理;2XX,Success(成功狀態碼),請求正常處理完畢;3XX,Redirection(重定向狀態碼),需要進行附加操作以完成請求;4XX,Client
    Error(客戶端錯誤狀態碼),服務器無法處理請求;5XX,Server Error(服務器錯誤狀態碼),服務器處理請求出錯。

  • RFC2616上的HTTP狀態碼有40種,加上WebDAV和附加HTTP狀態碼,數量達60餘種,但是常用的大概只有14種。
    200 OK:請求被正常處理了。
    204 Not Content:請求處理成功但返回響應報文中不含實體的主體部分也不允許返回任何實體的主體。
    206 Partial Content:客戶端進行了範圍請求,服務器成功執行了這部分GET請求,響應報文中包含Content-Range指定範圍的實體內容。
    301 Moved Permanently:永久性重定向,表示請求的資源已被分配了新的URL,指定資源路徑最後忘記添加斜槓就會產生301狀態碼。
    302 Found:臨時性重定向。
    303 See Other:表示由於請求對應的資源存在着另一個URI,應使用GET方法定向獲取請求的資源,與302類似,但是指定了GET方法。
    304 Not Modified:表示客戶端發送附帶條件的請求(GET方法請求報文中含If-Match、If-Modified-Since、If-Node-Match、If-Range、If-Unmodified-Since中任一個首部)時,服務器端允許請求訪問資源,但未滿足條件的情況。與重定向實際上沒有關係。
    307 Temporary Redirect:臨時重定向,與302差不多,但是遵照瀏覽器標準,不會從POST變成GET。
    400 Bad Request:表示請求報文中存在語法錯誤,需修改請求的內容後再次發送,但是瀏覽器會像200 OK一樣對待該狀態碼。
    401 Unauthorized:表示發送請求需要通過HTTP認證(BASIC認證、DIGEST認證)的認證信息,如果之前已進行過一次請求則表示用戶認證失敗。
    403 Forbidden:表示請求資源的訪問被服務器拒絕了,服務器沒有必要給出拒絕的詳細理由,如果想做說明的話可以在實體的主體部分對原因進行描述。未獲得文件系統的訪問授權、訪問權限出現某些問題(從未授權的發送源IP地址試圖訪問)等都可發生403。
    404 Not Found:表明服務器上無法找到請求的資源,如果服務器拒絕請求且不想說明理由時也可以使用。
    500 Internal Server Error:表名服務器在執行請求時發生了錯誤,也有可能是Web應用存在的bug或某些臨時的故障。
    503 Service Unavailable:表名服務器暫時處於超負載或者正在進行停機維護,現在無法處理請求。如果事先得知解除以上狀況需要的時間,最好寫入RetryAfter首部字段再返回給客戶端。
    狀態碼和狀況可能是不對應的,但是用戶可能察覺不到這點。

第5章 與HTTP協作的Web服務器

  • 一臺Web服務器可搭建多個獨立域名的Web網站,也可作爲通信路徑的中轉服務器提升傳輸效率。

  • 用單臺虛擬技術及實現多個域名。

  • 通信數據轉發程序:代理(有轉發功能的應用程序)、網關(轉發其他服務器通信數據的服務器)、隧道(在相隔甚遠的客戶端和服務器兩者之間進行中轉並保持雙方通信連接的應用程序)。

  • 代理服務器:不改變請求的URI,會直接發送給前方持有資源的目標服務器(源服務器),源服務器返回給代理服務器,代理服務器再傳給客戶端。每次通過代理服務器轉發請求或者響應時會追加寫入Via首部信息。代理服務器可以級聯多臺,Via會標記出經過的主機信息。使用代理的理由:利用緩存技術減少網絡帶寬的流量,組織內部針對特定網站的訪問控制,以獲取訪問日誌爲只要目的等等。代理有多種使用方法,按兩種基準分類,一種是是否使用緩存,另一種是是否會修改報文,對應緩存代理和透明代理。

  • 網關:利用管管可以由HTTP請求轉化爲其他協議通信。工作機制與代理十分相似。利用網關能夠提高通信的安全性,因爲可以在客戶端域網關之間的通信線路上加密以確保連接的安全。比如網關可以連接數據庫使用SQL語句查詢數據,另外在Web購物網站進行信用卡結算時網關可以和信用卡結算系統聯動。

  • 隧道:可按要求建立起一條與其他服務器的通信線路,屆時使用SSL等加密手段進行通信,目的是確保客戶端能與服務器進行安全的通信。隧道本身不會去解析HTTP請求,通道本身是透明的。

  • 保存資源的緩存:緩存是指代理服務器或客戶端本地磁盤保存的資源副本。利用緩存可減少對源服務器的訪問,因此也就節省了通信流量和通信時間。緩存服務器的緩存有效期限,失效則從源服務器更新。客戶端緩存也有有效期限,失效則更新。

第6章 HTTP首部

  • HTTP請求報文的報文首部的請求行(方法、URI、HTTP版本),請求首部字段和通用首部字段以及實體首部字段合爲HTTP首部字段。HTTP響應報文類似,狀態行包含HTTP版本、狀態碼,響應首部字段和通用首部字段以及實體首部字段爲HTTP首部字段。

  • 使用首部字段是爲了給瀏覽器和服務器提供報文主題大小、所使用的語言、認證信息等內容。

  • 首部字段格式(首部字段名:字段值),如果HTTP首部字段重複了,有些瀏覽器可能處理第一次出現的首部字段,有些則優先處理最後出現的首部字段。

  • 通用首部字段:Cache-Control(控制緩存的行爲),Connection(逐跳首部、連接的管理),Date(創建報文的日期時間),Pragma(報文指令),Trailer(報文末端的首部一覽),Transfer-Encoding(指定報文主體的傳輸編碼方式),Upgrade(升級爲其他協議),Via(代理服務器的相關信息),Warning(錯誤通知)。

  • 請求首部字段:Accept(用戶代理可處理的媒體類型),Accept-Charset(優先的字符集),Accept-Encoding(優先的內容編碼),Accept-Language(優先的語言),Authorization(Web認證信息),Expect(期待服務器的特定行爲),From(用戶的電子郵箱地址),Host(請求資源所在服務器),If-Match(比較試題標記ETag),If-Modified-Since(比較資源的更新時間),If-None-Match(比較實體標記,域If-Match相反),If-Range(資源未更新時發送實體Byte的範圍請求),If-Unmodified-Since(比較資源的更新時間,域If-Modified-Since相反),Max-Forwards(最大傳輸逐跳數),Proxy-Authorization(代理服務器要求客戶端的認證信息),Range(實體的字節範圍請求),Referer(對請求中URI的原始獲取方),TE(傳輸編碼的優先級),User-Agent(HTTP客戶端程序的信息)。

  • 響應首部字段:Accept-Ranges(是否接受字節範圍請求),Age(推算資源創建經過時間),ETag(資源的匹配信息),Location(令客戶端重定向至指定URI),Proxy-Authenticate(代理服務器對客戶端的認證信息),Retry-After(對再次發起請求的時機要求),Server(HTTP服務器的安裝信息),Vary(代理服務器緩存的管理信息),WWW-Authenticate(服務器對客戶端的認證信息)。

  • 實體首部字段:Allow(資源可支持的HTTP方法),Content-Encoding(實體主體適用的編碼方式),Content-Language(實體主體的自然語言),Content-Length(實體主體的大小,單位爲字節),Content-Location(替代對應資源的URI),Content-MD5(實體主體的報文摘要),Content-Range(實體主體的位置範圍),Content-Type(實體主體的媒體類型),Expires(實體主體過期的日期時間),Last-Modified(資源的最後修改日期時間)。

  • 非HTTP/1.1首部字段:不限於RFC2616中是定義的47種首部字段,還有Cookie、Set-Cookie和Content-Disposition等使用頻率也很高,這些非正式的首部字段統一歸納在RFC4229HTTP Header Field Registrations中。

  • End-to-end首部:端到端首部,分在此類別中的首部會轉發請求/響應對應的最終接收目標,且必須保存在由緩存生成的響應中,另外規定它必須被轉發。

  • Hop-by-hop首部:逐跳首部,分在此類別中的首部只對單次轉發有效,會因通過緩存或代理而不再轉發,使用hop-by-hop首部,需提供Connection首部字段。

通用首部字段:

  • Cache-Control:多個參數用逗號隔開
    這裏寫圖片描述
    這裏寫圖片描述
  • Connection:控制不再轉發給代理的首部字段、管理持久連接,值:Upgrade、close、keep-alive。
  • Date:創建報文的日期和時間,GMT爲準。
  • Pragma:歷史遺留字段,值:no-cache。
  • Trailer:值Expires。
  • Transfer-Encoding:值chunked。
  • Upgrade:值爲通信協議,需要Connection: Upgrade,響應狀態碼可爲101 Switching Protocols。
  • Via:追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。
  • Warning:通常會告知用戶一些與緩存相關的警告,值格式爲[警告碼][警告的主機:端口號]”[警告內容]”([日期時間])。
    這裏寫圖片描述

請求首部字段:

  • Accept:例子 text/html,application/xhtml+xml,application/xml;q=0.3。
  • Accept-Charset:例子iso-8859-5, unicode-1-1;q=0.8。
  • Accept-Encoding:例子gzip, deflate。(有gzip、compress、deflate、identity)。
  • Accept-Language:例子zh-cn,zh;q=0.7,en-us,en;q=0.3。
  • Authorization:例子Basic dWVub3NlbjpwYXNzd29yZA==。
  • Expect:例子100-continue。
  • Form:例子[email protected]
  • Host:例子www.pifutan.com
  • If-Match:例子”123456”。
  • If-Modified-Since:後面接指定的日期時間。
  • If-None-Match:例子*。
  • If-Range:例子”123456”。
  • If-Unmodified-Since:後面接指定日期時間。
  • Max-Forwards:最大轉發次數,值變爲0時返回響應。
  • Proxy-Authorization:例子Basic dGlwOjkpNLAGfFY5。
  • Range:例子bytes=5001-10000。
  • Referer:後面接網址,實際上正確拼寫是Referrer,但是錯誤被沿用下來了。
  • TE:例子gzip, deflate;q=0.5。
  • User-Agent:用於擦宏達瀏覽器的種類,例子Mozilla/5.0 (Windows NT 6.1; WOW64;
    rv:13.0) Gec。

響應首部字段:

  • Accept-Range:值爲bytes或none。
  • Age:告知客戶端源服務器在多久前創建了響應,字段值單位爲秒。
  • ETag:告知客戶端實體標識,爲服務器資源唯一性標識。
  • Location:URI位置。
  • Proxy-Authenticate:例子Basic realm=”Usagidesign Auth”。
  • Retry-After:告知客戶端在多久後再次發送請求,單位爲秒或具體的日期時間。
  • Server:HTTP服務器應用程序的信息。例子Apache/2.2.6 (Unix) PHP/5.2.5。
  • Vary:例子Accept-Language。
  • WWW-Authenticate:例子Basic realm=”Usagidesign Auth”。

實體首部字段:

  • Allow:例子GET, HEAD。
  • Content-Encoding:例子gzip。
  • Content-Language:例子zh-CN。
  • Content-Length:實體主體部分的大小,單位爲字節。
  • Content-Location:值爲URI。
  • Content-MD5:值爲MD5算法生成的值,用於檢查報文主體在傳輸過程中是否保持完整以確認傳輸到達。
  • Content-Range:例子bytes 5001-10000/10000。
  • Content-Type:例子text/html; charset=UTF-8。
  • Expires:資源失效的日期。
  • Last-Modified:資源最終修改的時間。

爲Cookie服務的首部字段:

  • Set-Cookie:屬於響應首部字段,表示開始狀態管理所使用的Cookie信息。例子status=enable; expires=Tue, 05 Jul 2011 07:26:31。
    這裏寫圖片描述
  • Cookie:屬於請求首部字段,表示服務器接收的Cookie信息。例子status=enable。

其他首部字段:

  • X-Frame-Options:屬於響應首部字段,用於控制網站內容在其他Web網站的Frame標籤內的顯示問題,主要目的是爲了防止點擊劫持動機,值爲DENY或SAMEORIGIN。
  • X-XSS-Protection:屬於響應首部字段,針對跨站腳本攻擊XSS的一種策略,用於控制瀏覽器XSS防護機制的開關,值爲0(XSS過濾設置爲無效狀態)或1(有效)。
  • DNT:屬於請求首部字段,DNT是Do Not Track的簡稱,爲拒絕個人信息被手機,表示拒絕被精準廣告追蹤的一種方法,值爲0(同意被追蹤)或1(拒絕)。
  • P3P:屬於響應首部字段,利用P3P(The Platform for Privacy
    Prefereces,在線隱私偏好平臺)技術,可以讓Web網站上的個人隱私編程一種僅供程序可理解的形式,已達到保護用戶隱私的目的。例子CP=”CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa。

第7章 確保Web安全的HTTPS

  • HTTP不足:(1)通信使用明文(不加密),內容可能會被竊聽(2)不驗證通信的身份,因此有可能遭遇僞裝(或者遭遇海量請求下的DoS攻擊)(3)無法證明報文的完整性,所以有可能已遭篡改(4)其他缺點。

  • 互聯網上的任何角落都存在通信內容被竊聽的風險,用抓包(Packet Capture)或嗅探器(Sniffer)工具即可,如Wireshark( www.wireshark.org )。

  • 與SSL組合使用的HTTP被稱爲HTTPS(HTTP Secure,超文本傳輸安全協議)或HTTP over SSL。這種屬於通信的加密,還可以對通信的內容本身加密的方式,對內容加密則要求客戶端和服務器端同時具備加密和解密機制。SSL提供證書,而僞造證書從技術角度來說是異常困難的。

  • HTTPS=HTTP+加密+認證+完整性保護。Web的登錄頁面和購物階段界面等使用HTTPS通信。HTTPS並非新協議,知識HTTP通信接口部分用SSL和TLS協議代替而已即先和SSL通信,再由SSL和TCP通信。SSL是獨立於HTTP的洗衣,也可以域SMTP和Telnet等協議結合使用,可以說SSL是當今世界上應用最爲廣泛的網絡安全技術。

  • HTTPS採用混合加密機制:在交換密鑰環節使用公開密鑰(非對稱加密,域似有密鑰結合使用)加密方式,之後的建立通信交換報文階段則使用共享密鑰(加密和解密共用一個密鑰,也稱爲對稱加密)加密方式。

  • 證明公開密鑰正確性的證書:公開密鑰可能被替換了,第三方機構,如威瑞信VeriSign,申請得到數字證書(也稱爲公鑰證書或直接叫證書)。

  • 可證明組織真實性的EV SSL證書:證明作爲通信乙方的服務器是否規範。 用以確認客戶端的客戶端證書。用戶需要自行安裝證書。

  • 由自認證機構頒發的證書稱爲自簽名證書。

  • HTTPS通信:
    步驟1:客戶端通過發送Client
    Hello報文開始SSL通信,報文中包含客戶端支持的SSL的指定版本、加密組件列表(所使用的加密算法及密鑰長度等)。
    步驟2:服務器可進行SSL通信時,會以Server
    Hello報文作爲應答,和客戶端一樣報文中包含SSL版本以及加密組件,服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
    步驟3:之後服務器發送Certificate報文,報文中包含公開密鑰證書。
    步驟4:最後服務器發送Server Hello Done報文通知客戶端,最初階段的SSL握手協商部分結束。
    步驟5:SSL第一次握手結束後,客戶端以Client Key Exchange報文作爲迴應。報文中包含通信加密中使用的一種被稱作Pre-master secret的隨機密碼串,該報文已用步驟3中的公開密鑰進行加密。
    步驟6:接着客戶端繼續發送Change Cipher Spec報文,該報文會提示服務器,再次保溫之後的通信會採用Pre-master secret密鑰加密。
    步驟7:客戶端發送Finished報文,包含連接至今全部報文的整體校驗值,這次握手協商能夠成功要以服務器是否能夠正確機密該報文作爲判定標準。
    步驟8:服務器同樣發送Change Cipher Spec報文。
    步驟9:服務器同樣發送Finished報文。
    步驟10:服務器和客戶端的Finished報文交換完畢之後,SSL連接就算建立完成了,當然通信會受到SSL的保護,從此處開始進行應用層協議的通信,即發送HTTP請求。
    步驟11:應用層協議通信,即發送HTTP響應。
    步驟12:最後由客戶端斷開連接,且發送close_notify報文,這步之後再發送TCP FIN報文來關閉與TCP的通信。 以上流程中,應用層發送數據時會附加一種加做MAC(Message Authentication Code)的報文摘要,MAC能夠查知報文是否遭到篡改,從而保護報文的完整性。

  • HTTPS比HTTP要慢2到100倍。SSL速度慢有兩種原因,一種是通信慢,另一種是由於大量消費CPU及內存等資源,導致處理速度變慢。速度變慢的問題並沒有根本性的解決方案,只能用SSL加速器(專用服務器)來改善情況。因此並不會一直使用HTTPS,包含敏感信息時才使用HTTPS加密通信。另外購買證書的開銷也是原因之一。

第8章 確認訪問用戶身份的認證

  • 認證覈對的信息通常指:密碼、動態令牌、數字證書、生物認證、IC卡等。

  • HTTP/1.1認證方式:BASIC認證(基本認證),DIGEST認證(摘要認證),SSL客戶端認證,FormBase認證(基於表單認證),以及Windows統一認證(Keberos認證、NTLM認證)。

  • BASIC認證:(Base64編碼處理,不夠便捷靈活,不夠安全,不常用)
    步驟1:當請求的資源需要BASIC認證時,服務器會返回狀態碼401 Authorization Required且返回WWW-Authenticate(包含認證的方式及Request-URI安全域字符串realm)首部字段的響應。
    步驟2:接收狀態碼401的客戶端爲了通過BASIC認證,需要將用戶ID和密碼中間加上冒號(:)再經過Base64編碼處理。
    步驟3:接收到包含收不Authorization請求的服務器,會對認證信息的正確性進行驗證,通過的話則返回一條包含Request-URI資源的響應。

    質詢響應方式:一開始一方會先發送認證要求給另一方,接着使用從另一方那接收到的質詢碼計算生成響應碼,最後將響應碼返回給對方進行認證的方式。

  • DIGEST認證:
    步驟1:請求需認證的資源時,服務器會隨着狀態碼401返回WWW-Authenticate(包含質問響應方式認證所需的臨時質詢碼(隨機數,nonce,推薦有Base64編碼的16進制數組成形式)和realm)。
    步驟2:接收到401裝填嗎的客戶端,返回的響應中包含DIGEST認證必須的收不字段Authorization信息。
    步驟3:接收到包含首部字段Authorization請求的服務器,會確認認證信息的正確新,認證通過後返回包含Request-URI資源的響應。

  • SSL客戶端認證:
    步驟1:接收到需要認證資源的請求,服務器會發送Certificate Request報文,要求客戶端提供客戶端證書。
    步驟2:用戶選擇將發送的客戶端證書後,客戶端會吧客戶端證書信息以Client Certificate報文方式發送給服務器。
    步驟3:服務器驗證客戶端證書驗證通過後方可領取證書內客戶端的公開密鑰,然後開始HTTPS加密通信。

  • SSL客戶端認證採用雙因素認證:證書加上表單認證。

  • 基於表單認證:用戶ID和密碼等登錄信息發送認證。這種方式佔了很大部分。

  • Session管理以及Cookie應用:
    步驟1:客戶端把用戶ID和密碼等登錄信息放入報文的實體部分,通常是以POST方法把請求發送給服務器,這時會用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數據的發送。
    步驟2:服務器會發放用以識別用戶的SessionID,通過驗證從客戶端發送過來的登錄信息進行身份認證,然後把用戶的認證狀態與SessionID綁定後記錄在服務器。(爲減輕跨站腳本攻擊XSS造成的損失,建議事先在Cookie內加上httponly的屬性)
    步驟3:客戶端接收到服務器端發來的SessionID後,會將其作爲Cookie保存在本地,下次向服務器發送請求時,瀏覽器會自動發送Cookie,所以SessionID也會隨之發送到服務器,服務器端可通過驗證接收到的SessionID識別用戶和其認證狀態。

  • 密碼一般用加鹽(salt)的方式增加額外信息,在使用散列函數計算出散列後保存。

第9章 基於HTTP的功能追加協議

  • Google在2010年發佈了SPDY,旨在解決HTTP的性能瓶頸,縮短Web頁面的加載時間(50%),http://www.chromium.org/spdy

  • HTTP瓶頸:(1)一條連接上只可發送一個請求(2)請求只能從客戶端開始,客戶端不可以接受除響應以外的指令(3)請求/響應首部未經壓縮就發送,首部信息越多延遲越大(4)發送冗長的首部,每次互相發送相同的首部造成的浪費較多(5)可任意選擇數據壓縮格式,非強制壓縮發送。

  • Ajax的解決辦法:利用JavaScript和DOM操作局部Web頁面替換加載的一步通信手段,減少了通信量,但是實時獲取有可能會導致大量請求產生,並未解決HTTP協議本身存在的問題。

  • Comet的解決辦法:一旦服務器端有內容更新了,Comet不會讓請求等待,而是直接給客戶端返回響應,這是一種通過延遲應答模擬實現服務器端向客戶端推送的功能。爲了實現推送功能,Comet會將請求的響應置於掛起狀態,服務器內容更新了再返回該響應,連接的持續時間變長,維持連接會消耗更多的資源,並未解決HTTP協議本身存在的問題。

  • SPDY的解決:沒有完全改寫HTTP協議,而是在TCP/IP的應用層與運輸層之間通過新加會話層(SPDY會話層)的形式運作,並且SPDY規定通信中使用SSL,但還是HTTP方式建立通信連接。可獲得功能:多路複用流(單一TCP連接可以無限制處理多個HTTP請求),賦予請求優先級),壓縮HTTP首部,推送功能(支持服務器主動向客戶端推送數據的功能),服務器提示功能(服務器可以主動提示客戶端請求所需的資源)。

  • SPDY消除Web瓶頸了嗎?使用SPDY時Web瀏覽器和Web服務器都要爲對應SPDY做出一定程度上的改動,但是SPDY的技術導入進展不佳,因爲SPDY基本上只是將打個域名(IP地址)通信多路複用,所以當一個Web網站上使用多個域名下的資源,改善效果就會收到限制。SPDY確實是一種可以有效消除HTTP瓶頸的技術,但很多Web網站存在的問題並非僅僅是由HTTP瓶頸所導致(如Web內容的編寫方式)。

  • WebSocket爲解決HTTP瓶頸問題在2011年12月應運而生,WebSocket即Web瀏覽器與Web服務器之間全雙工通信標準,主要是爲了解決Ajax和Comet裏XMLHttpRequest附帶的缺陷所引起的問題。

  • WebSocket特點:推送功能(支持服務器向客戶端推送數據的推送功能),減少通信量(只要建立起WebSocket連接就希望一直保持連接狀態,且首部信息小),一次握手(需要Upgrade:websocket首部字段,返回狀態碼101 Switch Prorocols)。

  • HTTP/2.0在路上:7項技術討論:多路複用、TLS義務化、協商、客戶端拉/服務器推、流量控制、WebSocket。

  • WebDAV(Web-based Distributed Authoring and Versioning,基於萬維網的分佈式創作和版本控制)是一個可對Web服務器上的內容直接進行文件複製、編輯等操作的分佈式文件系統。追加方法:PROPFIND(獲取屬性)、PROPPATCH(修改屬性)、MKCOL(創建集合)、COPY(複製資源及屬性)、MOVE(移動資源)、LOCK(資源加鎖)、UNLOCK(資源解鎖),相應的狀態碼也擴展:102 Processing、207 Multi-Status、422 Unprocessible Entity、423 Locked、424 Failed Dependency、507 Insufficient Storage。

第10章 構建Web內容的技術

  • 動態HTML:指使用客戶端腳本語言將靜態的HTML內容變成動態的技術的總稱。

  • CGI(Common Gateway Interface,通用網關接口):指Web服務器在接收到客戶端發送過來的請求後轉發給程序的一組機制。

  • 因Java而普及的Servlet:Servlet是一種能在服務器上創建動態內容的程序,是Web容器或說Servlet容器。

  • 數據發佈的格式及語言:XML、RSS/Atom、JSON。

第11章 Web的攻擊技術

  • 簡單的HTTP協議本身不存在安全性問題,因此協議本身幾乎不會成爲攻擊的對象。應用HTTP協議的服務器和客戶端以及運行在服務器上的Web應用等資源纔是攻擊目標。

  • 針對Web的攻擊技術:HTTP不具備必要的安全功能,在客戶端即可篡改請求;主動攻擊(以服務器爲目標,通過直接訪問Web應用把攻擊代碼傳入的攻擊模式,需要能訪問到那些資源,代表爲SQL注入攻擊和OS命令注入攻擊),被動攻擊(以服務器爲目標,利用全套策略執行攻擊代碼的攻擊模式,不直接對目標Web應用訪問發起攻擊,代表爲跨站腳本攻擊和跨站點請求僞造),利用用戶的身份攻擊企業內部網絡。

  • 因輸出值轉義不完全引發的安全漏洞:
    跨站腳本攻擊XSS:通過存在安全漏洞的Web網站註冊用戶的瀏覽器內運行非法的HTML標籤或JavaScript進行的一種攻擊,可以:利用虛假輸入表單片區用戶個人信息,利用腳本竊取用戶的Cookie值使得被害者在不知情的情況下幫助攻擊者發送惡意請求,顯示僞造的文章或圖片。
    SQL注入攻擊:針對Web應用使用的數據庫通過運行非法的SQL而產生的攻擊,可能引發極大的威脅有時直接導致個人信息及機密信息的泄露,可以:非法查看或篡改數據庫內的數據庫,規避認證,執行和數據庫服務器業務關聯的程序。
    OS命令注入攻擊:通過Web應用執行非法的操作系統命令達到攻擊的目的,只要能調用Shell函數的地方就有存在被攻擊的風險。
    HTTP首部注入攻擊:攻擊者通過在響應首部字段插入換行添加任意響應首部或主體的一種攻擊,可以:設置任何Cookie信息、重定向至任意URL、顯示任意的主體即HTTP響應截斷攻擊。
    郵件首部注入攻擊:攻擊者通過向郵件首部To或Subject內任意添加非法內容發起的攻擊,利用存在安全漏洞的Web網站可對任意郵件地址發送廣告郵件或病毒郵件。
    目錄遍歷攻擊:對本無意公開的文件目錄通過非法截斷其目錄路徑後達成訪問目的的一種攻擊,也稱路徑遍歷攻擊。
    遠程文件包含漏洞:當部分腳本內容需要從其他文件讀入時攻擊者利用指定外部服務器的URL充當依賴文件,讓腳本讀取之後就可運行任意腳本的一種攻擊,主要是PHP存在的安全漏洞。

  • 因設置或設計上的缺陷引發的安全漏洞:
    強制瀏覽安全漏洞:從安置在Web服務器的公開目錄愛的文件中瀏覽那些原本非自願公開的文件,可能:泄露顧客的個人信息等中啊喲情報、泄露原本需要具有訪問權限的用戶纔可查閱的信息內容、泄露未外連到外界的文件。
    不正確的錯誤消息處理安全漏洞:Web應用的錯誤信息內包含對攻擊者有用的信息,錯誤信息有:Web應用拋出的錯誤消息、數據庫等系統拋出的錯誤消息。
    開放重定向:一種對指定的任意URL作重定向跳轉的功能,開放重定向安全漏洞指重定向URL到某個具有惡意的Web網站。

    因會話管理疏忽引發的安全漏洞:
    會話劫持:攻擊者通過某種手段拿到了用戶的會話ID並非法使用此會話ID僞裝成用戶達到攻擊的目的。可通過非正規的生成方法推測會話ID、可通過竊聽或XSS攻擊盜取會話ID、可通過會話固定攻擊強行獲取會話ID。
    會話固定攻擊:對以竊取目標會話ID爲主動攻擊手段的會話劫持而言,會話固定攻擊會強制用戶使用攻擊者指定的會話ID,屬於被動攻擊。
    跨站點請求僞造:攻擊者通過設置好的陷阱強制對已完成認證的用戶進行非預期的個人信息或設定信息等某些狀態更新,屬於被動攻擊,可以:利用已通過認證的用戶權限更新設定信息等、利用已通過認證的用戶權限購買商品、利用已通過認證的用戶權限在留言板上發表言論。

  • 其他安全漏洞:
    密碼破解:算出密碼突破認證。可通過網絡的密碼試錯(窮舉法、字典攻擊)或者對已加密密碼的破解(指攻擊者入侵系統,已獲得加密或散列處理的密碼數據的情況)(窮舉法字典攻擊、彩虹表、拿到密鑰、加密算法的漏洞)。
    點擊劫持:利用透明的按鈕或鏈接做成陷阱,覆蓋在Web頁面智商,然後誘使用戶在不知情的情況下,點擊那個鏈接訪問內容的一種攻擊手段,也稱界面僞裝。
    DoS攻擊(Denial of Service attack):一種讓運行中的服務呈停止狀態的攻擊,兩種方式(1)集中利用訪問請求造成資源過載、資源用盡的同時,實際上服務也就呈停止狀態,即發送大量的合法請求(2)通過攻擊安全漏洞使服務停止。
    後門程序:開發設置的隱藏入口,可不按正常步驟使用受限功能,通常有3種:開發階段作爲Debug調用的後門程序、開發者爲了自身利益植入的後門程序、攻擊者通過某種方法設置的後門程序。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章