HTTP基礎的簡單理解
在了解HTTP協議之前，我們先了解下TCP/IP的參考模型，TCP/IP參考模型分為四層：應用層、傳輸層、網絡層、鏈路層(數據鏈路層)。
應用層：為不同的網絡應用提供所需的服務。
傳輸層：為應用層實體提供端到端的通信/傳輸功能，確保數據包的按順序傳送及數據的完整性。
網絡層：處理網絡上流動的數據包，它所包含的協議涉及到數據包在整個網絡上的邏輯傳輸。
鏈路層：監控數據交換，處理網絡連接的硬件部分。
TCP/IP通信傳輸流如下圖所示：
HTTP在各層的封裝處理：
與HTTP協議密切相關的協議/服務：IP，TCP，DNS
IP協議負責數據包的傳送，當然，這需要配合IP地址和MAC地址，IP間的通信依賴MAC地址，這就涉及到用以解析地址的ARP協議了。
TCP提供了可靠的字節流服務，對要發送的大塊數據進行分割成小數據包以易於傳輸，並且該協議可確認數據包是否送達到目的方。
DNS服務負責解析域名
URI(統一資源標識符)和URL(統一資源定位符)
URI：一個用於標識某一互聯網資源名稱的字符串。組成：主機名(含端口號)+相對路徑+標識符
URL：對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標准資源的地址。組成：協議+主機名(含端口號)+相對路徑
區別：URI表示請求資源在互聯網上存在的位置，URL在表示請求資源的位置同時還要說明如何訪問到這個資源，URL是URI的一個子集。參考資源：URL和URI的區別
Cookies
HTTP協議用於客戶端和服務端之間通過請求和響應的交換所達成的通信，並且它是一種無狀態的協議，不會對請求和響應之間的通信狀態進行保存(無法根據前一次請求對這次請求做出處理)，但為了能夠有保存狀態的功能，引入了cookies技術。
持久連接
HTTP初始版本時，每進行一次HTTP請求就會斷開一次TCP連接，這情況在早期傳輸文本很小的時候倒也不覺得如何，但是隨着時代的進步，所需傳輸的內容種類越來越多和內容越來越大了，每次連接后都會斷開請求就大幅度的增加了通信量的開銷了。幸好，自HTTP/1.1和部分HTTP/1.0來，有了持久連接這么個神奇的東西，它規定了只要任何一方沒有明確的提出斷開連接，那么就保持TCP連接狀態。而在維持的TCP連接期間，可以多次進行HTTP請求來傳輸需要的內容。
HTTP/1.1默認保持持久連接，在HTTP的頭部信息中會有Connection: Keep-alive屬性，我們也可以通過瀏覽器開發工具的NetWork面板查看這個屬性的狀態及HTTP請求信息：
如何關閉持久連接：在響應頭設置Connection屬性為close.
得益於持久連接，HTTP實現了管線化，能夠做到同時並行發送多個請求，而無需一個接一個的等待響應。
HTTP請求的內容結構
HTTP協議交互的信息稱為HTTP報文，通過下面的圖來看看HTTP報文的結構：
除卻空行(回車符、換行符)，大致分為報文首部和報文主體。報文首部包含請求行(請求的方法、URI、HTTP版本)和狀態行(響應狀態碼、原因短語、HTTP版本)，首部字段(請求和響應的條件和屬性)，其他(未定義的首部)。
首部字段
首部字段規定了客戶端如何處理請求和服務端如何處理響應，根據用途可分為四種：請求首部(請求報文使用的首部)，響應首部(響應報文使用的首部)，通用首部(請求和響應通用的首部)，實體首部(報文實體部分使用的首部)。
HTTP/1.1首部字段列表
通用首部字段
首部字段名 說明 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 代理服務器對客戶端的認證信息 Reter-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 資源的最后修改日期時間
此外，還有一些如Cookie、Set-Cookie和Content-Disposition等在其他RFC中定義的首部字段也經常會被用到。
傳輸編碼
HTTP傳輸數據的時候可以傳輸原數據，也可以在傳輸過程中編碼以提升傳輸速率。通過傳輸時的編碼處理，能有效的處理大量的訪問請求。常用的內容編碼有以下幾種
· gzip(GUN zip)
· compress(UNIX系統的標准壓縮)
· deflate(zlib)
· identity(不進行編碼)
多部分對象集合
HTTP協議中采納了多部分對象集合，允許發送的報文主體內可含有多類型實體。多用於上傳文件或者圖片時使用，可以設置Content-Type屬性對其進行規定。如以下幾種常見的形式：
Text：用於標准化地表示的文本信息，文本消息可以是多種字符集和或者多種格式的
Multipart：用於連接消息體的多個部分構成一個消息，這些部分可以是不同類型的數據
Application：用於傳輸應用程序數據或者二進制數據
范圍請求
實現這項功能需要指定下載的實體范圍，如：一份1000字節大小的文件，想取300-3000字節范圍內的資源，可以設置Range:bytes=300-3000;想取300-3000字節和5000字節到最后的資源，可以設置Range:bytes=300-3000,5000-
內容協商
內容協商機制是指客戶端和服務端就響應資源內容進行交涉，然后提供給客戶最為適合的資源，內容協商會以響應資源的語言、字符集、編碼方式等作為判斷的基准。涉及到以下首部字段：
· Accept
· Accept-Charset
· Accept-Encoding
· Accept-Language
· Content-Language
內容協商技術又分為三種類型
服務器驅動協商：服務端以請求的首部字段作為參考，在服務端處理並且返回對應資源。
客戶端驅動協商：用戶通過瀏覽器提供的可選列表進行手動選擇，或者利用js腳本在web頁面上自行選擇。
透明協商：服務器驅動協商和代理驅動協商的結合體，當一個緩存被提供了構成響應的一系列可得的表現形式，並且維度的差異能完全被緩存理解，那么此緩存變得有能力代表源服務器為那個資源的后續請求去執行服務器驅動協商
內容協商可參考：內容協商
HTTP方法及狀態碼
HTTP方法
HTTP中也包含了一些方法，用於指定請求的資源按期望產生某種行為。對於這些方法，其中用的最多的是get和post，大家也一定很熟悉了~
HTTP/1.1和HTTP/1.0支持的方法
方法 說明 HTTP版本(支持) GET 資源獲取 1.0、1.1 POST 資源實體主體 1.0、1.1 PUT 傳輸文件 1.0、1.1 HEAD 獲得報文首部 1.0、1.1 DELETE 刪除文件 1.0、1.1 OPTIONS 詢問支持的方法 1.1 TRANCE 追蹤路徑 1.1 CONNECT 要求用隧道協議連接代理 1.1 LINK 建立和資源之間的聯系 1.0(廢棄) UNLINK 斷開連接關系 1.0(廢棄)
HTTP狀態碼
HTTP狀態碼表示客戶端HTTP請求的返回結果，通過狀態碼，用戶可以知道HTTP請求是否出現問題，問題出在哪，下面簡單羅列一些HTTP狀態碼：
狀態碼類別 狀態碼性質 1XX 信息性狀態碼 2XX 成功狀態碼 3XX 重定向狀態碼 4XX 客戶端錯誤狀態碼 5XX 服務器錯誤狀態碼
一些常見的狀態碼：
200 ok 正常處理請求 204 no content 服務端接收請求並成功處理，但返回的響應報文不含實體的主體部分 206 partial content 客戶端進行范圍請求，服務端成功執行這部分范圍的get請求 301 moved permanently 永久性重定向 302 found 臨時性重定向 303 see other 表示由於請求對於的資源存在另一個URI，應使用GET方法定向獲取請求的資源 304 not modified 客戶端發送附帶條件的請求，服務端允許訪問資源，但為滿足條件 401 unauthorized 表示發送的請求需要有通過HTTP認證的認證信息 403 forbidden 請求資源的訪問被服務端拒絕 404 not found 服務端無法找到請求的資源 500 internal server error 服務端執行請求時發生錯誤 503 service unavailable 服務端處於無法處理請求狀態
HTTP代理及緩存
代理
代理指的是具有轉發功能的應用程序，接收客戶端的請求轉發給服務端，也接收服務端的響應轉發給客戶端。代理不會改變請求的URI，會直接發送給持有資源的服務器。
在HTTP通信過程中可以級聯多台代理服務器，並且轉發時需要附加Via首部字段以標記經過的主機信息。
緩存
緩存是代理服務器或客戶端本地磁盤內保存的資源副本，利用緩存來減少對源服務器的訪問以便於節省通信流量和通信時間，也可以達到更好的交互體驗。
請求的資源如果已經被緩存則直接由緩存服務器返回給客戶端，或者客戶端直接從本地磁盤讀取。緩存可以設置有效時間，當判斷緩存過期后，客戶端/緩存服務器可像源服務器重新請求新資源。
HTTP安全升級--HTTPS
講了一些HTTP的優點后，來看看HTTP的缺點
· 通信使用明文(未經加密)，內容可能被竊聽
· 不驗證通信方的身份，請求/響應會遭偽裝
· 無法證明報文的完整性，存在被篡改的可能
互聯網的任何角落都存在通信內容被竊聽的風險
按照TCP/IP協議的工作機制，通信內容在所有的通信線路上都有可能遭受窺視。即使是加密處理過的通信，也會被窺視到通信內容，只是經過了加密，就有可能讓人無法破解出正確完整的報文信息含義，加密后的報文信息本身內容還是會被看到。
一般來說，竊聽通信是通過收集在互聯網上流動的數據包來做解析，這些可以通過抓包和嗅探工具實現，這也使得一些使用公共wifi賬號被盜的事情時有發生。
針對明文傳輸這點，也可以對報文主體(傳輸內容)進行加密處理
針對身份驗證這點，可通過在本地安裝證書，存儲身份認證信息等
針對確保信息完整性，MD5/SHA-1的散列值校驗，數字簽名等
HTTP => HTTPS
HTTP不帶加密機制，但可以通過和SSL(安全 套接層...標注下閱讀時的停頓)或TLS(安全層傳輸協議)的組合使用，用SSL建立安全通信線路后，就可以在這條線路上歡快的進行HTTP通信了。由於結合了SSL，HTTP升級成為HTTPS(或者 HTTP over SSL)，然而這還不能說是個完整的HTTPS。
完整的HTTPS = HTTP + 加密 + 認證 + 完整性保護
一次完整的HTTPS請求
1.客戶端發送Client Hello報文開始SSL通信，報文中包含客戶端支持的SSL的指定版本、加密組件列表等
2.服務端可進行SSL通信時，會以Serve rHello報文作為應答
3.服務端發送Certificate報文，報文包含公開密鑰證書
4.服務端發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束
5.SSL第一次握手結束后，客戶端以Client Key Exchange報文作為回應，其中包含通信加密中使用的隨機密碼串
6.客戶端發送Change Cipher Spec報文，提示服務端此報文之后的通信采用符合上一步的隨機密碼串的密鑰加密
7.客戶端發送Finished報文，其中包含連接至今全部報文的整體校驗值
8.服務端發送Change Cipher Spec報文
9.服務端發送Finished報文
10.Finished報文交換完畢后，SSL連接建立完成
11.應用層協議通信，HTTP
12.客戶端斷開連接，發送close notify
WebSocket 和 http/2.0
WebSocket
WebSocket實現了再Web客戶端和服務端之間的全雙工通信，一旦Web服務端與客戶端之間建立WebSocket協議的通信連接，之后的所有通信都依賴這個專用協議進行。
WebSocket具有推送功能，服務端可直接向客戶端推送數據，不必等待客戶端的請求；由於WebSocket一直保持連接狀態，並且首部信息小，使得通信量也相應的減少。
為了實現WebSocket通信。需要用到前面說到的HTTP首部字段Upgrade，達到告知服務端通信協議發生改變，當成功握手確立WebSocket連接之后，通信時不再使用HTTP的數據幀，而采用WebSocket獨立的數據幀。
HTTP/2.0
核心優勢/特性
多路復用：多個請求都是通過一個 TCP 連接並發完成(HTTP/1.1管線化在多個請求之間的響應會被阻塞，HTTP/2.0解決了這問題，並且支持優先級和流量控制)
頭部壓縮：報文頭部壓縮處理，數通信量更小
服務端推送：服務端能夠更快的把資源推送給客戶端
語義改進：采用二進制格式傳輸數據
Web的攻擊技術
以服務器為目標的主動攻擊，代表性的有SQL注入和OS命令注入,SQL注入是指攻擊者通過直接訪問Web應用，把攻擊的SQL代碼傳入服務端以執行數據庫來獲取所需的數據信息或篡改數據庫信息(調用SQL語句的方式所產生的漏洞)；OS命令攻擊指的是在服務端執行非法的操作系統命令達到攻擊的目的。
以服務器為目標的被動攻擊，其模式如下:
1.攻擊者誘導用戶觸發已經設置好的陷阱，啟動發送已嵌入攻擊代碼的HTTP請求
2.含有攻擊代碼的HTTP發送到服務端並允許
3.運行完攻擊代碼后，存在安全漏洞的Web應用便會成為攻擊者的跳板，導致個人信息被竊取(網絡安全課的知識全還給老師了...起初看到這些，一臉懵逼...)
以客戶端為目標的主動攻擊，代表性的跨站腳步攻擊(XSS)，通過存在安全漏洞的Web網站注冊用戶的瀏覽器內運行非法的HTML標簽或者JavaScript代碼進行的一種攻擊方式，該攻擊可獲取用戶個人信息等
還有HTTP首部注入攻擊、郵件首部注入攻擊、目錄遍歷攻擊、遠程文件所包含的漏洞等
設置或設計導致的安全漏洞
強制瀏覽，從安置在Web服務端的公開目錄下的文件中瀏覽那些原本非自願公開的文件，導致個人信息/內部文件信息的泄露
拋出錯誤信息導致的漏洞，暴露出系統的出錯點，給攻擊者提供了攻擊的突破點
開放重定向，對任意URL作重定向跳轉的功能，攻擊者可誘導用戶到具有惡意的Web站點
會話管理疏忽導致的安全漏洞
會話劫持，攻擊者通過一些手段拿到用戶會話ID，並使用此會話ID偽裝成用戶達到攻擊的目的
攻擊者可能獲得會話ID的一些方式：
· 通過非正規的生成方法推測出會話ID
· 通過竊聽或XSS攻擊盜取會話ID
· 通過會話固定攻擊強行獲取會話ID
會話固定攻擊，大致模式為：攻擊者訪問站點拿到未認證的會話ID，設置陷阱強制用戶使用這個會話ID前去認證，一旦用戶觸發陷阱並完成認證，攻擊者就可使用用戶的身份順利登陸網站
跨站點請求偽造，攻擊者通過設置的陷阱強制對已完成認證的用戶進行非預期的信息某些狀態的更新
其他安全漏洞
密碼破解，獲取密碼，突破認證(通過網絡密碼試錯或者對已加密的密碼進行破解)，密碼破解如字典攻擊、彩虹表、獲取密鑰、加密算法漏洞等
點擊劫持，又稱界面偽裝，大多以透明層元素作為陷阱以達到攻擊目的
Dos攻擊，讓服務端的服務呈停止狀態(利用訪問請求造成資源過載，資源用盡以停止服務；通過攻擊安全漏洞停止服務)
后門程序，開發者debug的程序，開發者為自身利益植入的程序等