http協議屬於TCP/IP協議族中的一員，TCP/IP是互聯網中各類協議的總稱，分層管理，共有4層。
應用層：application層，決定了向用戶提供應用服務時的通信活動，或者是實現某類應用。運行在用戶空間的。
常見應用層協議有：
1.HTTP:用於瀏覽網頁，基於TCP端口號80
2.HTTPS:安全的超文本傳輸協議，用於安全的瀏覽網頁，基於TCP端口號443.
3.FTP 文本傳輸協議，用來上傳和下載大批量的文件數據，基於TCP端口20,21，20用於建立虛擬信道，21用於傳輸（常見21）
4.DNS 域名解析服務 將域名解析爲IP，基於UDP端口53.
5.SMTP (Simple Mail Transfer Protocol)簡單郵件傳輸協議 用來發送email，基於TCP端口25
6.POP3 (Post Office Protocol - Version 3)郵局協議第三版 用來接受email，基於UDP端口110
7.Exchange 即可收email又可發email
8.DHCP:動態主機配置協議 讓PC和服務器或網絡設備自動接受ip地址，子網掩碼，網關，基於UDP端口號68
9.TFTP 簡單文件傳輸協議 用來傳輸小批量數據文件，基於UDP端口號69
10.telnet 終端仿真協議 用來讓網管pc通過網絡遠程網管網絡設備，基於TCP端口號23，不安全
11.SSH 安全外殼 加密RSA，基於TCP端口號22
12.SNMP:簡單網絡管理協議 （更方便的讓網管pc管理大企業所有網絡設備）
13.NTP 網絡時間協議 讓網絡設備與NTP服務器同步時鐘，基於UDP端口號123
傳輸層：提供處於網絡連接中的兩個計算機的數據通信，host-to-host
常見協議：
TCP:傳輸控制協議，面向連接服務，提供可靠的應用程序數據流轉發工作
UDP:用戶數據報協議
ICMP:因特網控制消息協議
網絡層：internet層，網絡上流動的數據包
常見協議：
ipv4
ipv6
概念:
IP地址：網絡位+主機位
分段：
classA 0.x.x.x - 127.x.x.x
classB 128.x.x.x - 191.x.x.x
classC 192.x.x.x - 223.x.x.x
classD 224.x.x.x - 239.x.x.x
classE 240.x.x.x - 255.x.x.x
其中私有IP取自ABC段中的一部分：
10.x.x.x - 10.255.255.255
172.16.x.x - 172.31.255.255
192.168.x.x - 192.168.255.255
劃分網絡區段：Netmask子網掩碼
鏈路層：network-interface網絡接口層，連接網絡中的硬件設備
廣域網中常見設備：ADSL調制解調器、光纖、寬帶等；
局域網中常見設備：以太網絡硬件接口/光纖；
以太網的傳輸協議CSMA/CD標準，網卡對網卡的數據傳遞；
當客戶端發送http請求時，由瀏覽器數據包由http協議打包，傳給傳輸層添加tcp報頭(協議+端口)，傳給網絡層添加ip報頭(ip地址)，傳給鏈路層(若爲以太網根據CSMA/CD標準，報文增加mac地址)，發送到客戶端依次解包。
URI 統一資源標識符，Uniform Resource Identifier，標識某一個互聯網資源。
Uniform：協議方案，訪問資源使用的協議名稱，有http協議、ftp、telnet、file等；
Resource：可標識的任何東西；
Identifier：可標識的對象；
URL統一資源定位符，標識資源的位置；
http協議：必須是存在客戶端和服務器的，客戶端發送請求到服務器，服務器返回數據到客戶端。所以有請求報文(客戶端發送)和響應報文(服務器返回)。
請求報文：由請求行、請求頭部、空行、請求數據四部分組成；
而請求行、請求頭部(http首部字段)這兩部分又稱爲報文首部；
請求頭部又稱：http首部字段；
請求行：包含請求方法、URI、http版本
請求頭部：字段:值 組成
空行：標識不再有請求頭部
請求數據：POST方法中使用，與請求數據相關的請求頭是Content-Type和Content-Length
請求方法：GET(獲取資源)、POST(傳輸實體的主體，主要目的不是獲取響應的主體內容，將信息告知服務器)、PUT (傳輸文件)、HEAD(獲取報文首部)、DELETE(刪除文件)、OPTIONS(獲取支持的方法)、TRACE(追蹤路徑)、CONNECT(使用安全隧道協議連接代理ssl/tls)
Host: apache.org Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1
http首部字段：由鍵:值組或鍵:值，值多個值組成，其中有4種http首部字段類型：
1.通用首部字段，請求報文和響應報文都會使用的字段；
cache-control控制緩存行爲
connection 逐跳首部、鏈接管理，控制不再轉發給代理的首部字段和管理持久連接；
date創建報文的日期時間
pragma報文指令，可設置爲no-cache讓所有中間服務器不返回緩存的資源；
trailer報文末端的首部一覽
transfer-encoding報文主體的傳輸編碼方式
warning錯誤通知
upgrade升級爲其他協議
via代理服務器信息
2.請求首部字段，客戶端發送請求報文時，補充請求的附加內容、客戶端信息等信息；
accept用戶代理可處理的媒體類型，客戶端要求返回資源的類型，如文本文件、圖片文件、視頻文件、二進制文件，若瀏覽器不支持圖片，則不能使用圖片文件類型；
accept-charset優先的字符集
accept-encoding優先的內容編碼，告訴服務器用戶代理支持的內容編碼及內容編碼優先級順序，如gzip、compress、deflate、identity；
accept-language優先語言
authorization Web認證信息
expect期待服務器特定行爲
from用戶的電子郵箱
host請求資源所在服務器
if-match附帶條件請求
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range只需獲取部分資源的範圍請求
Referer告知服務器請求的原始資源的 URI
TE告知服務器客戶端能夠處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像，但是用於傳輸編碼
user-agent Http客戶端程序的信息
Cookie
3.響應首部字段，服務器返回響應報文時，補充響應的附加內容、要求客戶端附加額外的信息；
accept-ranges是否接受字節範圍請求
age推算資源創建經過時間
etag資源的匹配信息，服務器會爲每份資源使用etag標識
location令客戶端重定向指定uri
proxy-authenticate代理服務器對客戶端的認證信息
retry-after對再次發送請求的時機要求
server服務器安裝信息
vary代理服務器緩存信息
www-authenticate www服務器對客戶端的認證信息
set-cookie
4.實體首部字段，請求報文和響應報文的實體部分實用的首部；
allow 資源可支持的http方法
content-encoding 實體主體適用的編碼方式，內容編碼在不丟失的前提下進行壓縮；
content-language 實體主體使用的語言
content-length實體主體的大小
content-location替代對應資源的uri
content-md5實體主體的報文摘要
content-range實體主體的內容範圍(範圍請求)
content-type實體主體的媒體類型
expires實體主體過期的日期時間
last-modified資源的最後修改日期時間
響應報文：由狀態行、各首部字段、空行、報文主體組成；
狀態行、各首部字段又稱報文首部；
各首部字段又稱：http首部報文；
狀態碼：由3位數字組成；
1xx：表示請求正在處理；
2xx：表示請求返回成功；
3xx：重定向狀態碼，表示需要進行附加操作以完成請求；
4xx：客戶端錯誤狀態碼，表示服務器無法處理請求；
5xx：服務器錯誤狀態碼，表示服務器處理請求錯誤；
常見狀態碼：
200 ok 處理成功
204 處理成功但無資源返回
206 客戶端發送範圍請求，服務器執行返回範圍數據
301 永久重定向
302 臨時重定向
400 客戶端錯誤，存在語法錯誤
401 用戶認證失敗
403 請求被服務器拒絕
404 頁面不存在
500 服務器內部錯誤
503 服務器超負荷
HTTP/1.0 200 OK Date: Fri, 30 Nov 2018 03:04:01 GMT Server: Apache/2.4.18 (Ubuntu) Last-Modified: Mon, 26 Nov 2018 22:08:32 GMT ETag: "f2e8-57b9892db4d5c-gzip" Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Cache-Control: max-age=3600 Expires: Fri, 30 Nov 2018 04:04:01 GMT Content-Length: 14438 Connection: close Content-Type: text/html
報文主體、實體主體區別：
報文：是http通信中基本單位；
報文主體用於傳輸請求或響應的實體主體，請求頭部、空行、請求數據/各首部字段、空行、報文主體3部分組成；
實體：作爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成；
實體主體：報文主體；
爲了高效傳輸，採用壓縮傳輸的內容編碼和分割發送分塊傳輸編碼：
內容編碼：內容編碼是應用在實體內容上的編碼格式，並保持實體信息的完整性，由客戶端接收並負責解碼；
常見格式：gzip、compress、deflate、identity(不進行編碼)；
分塊傳輸編碼：將實體內容分塊傳輸；
範圍請求：從上次中斷下載點處開始下載稱爲範圍請求，使用首部字段 Range 來指定資源的 byte 範圍，如下：
Range: bytes=-3000, 5000-7000
http協議版本：
http 1.0 短暫鏈接
http 1.1 持久鏈接，減少了TCP連接時3次握手和4次揮手的開銷；
管線化技術：可同時發送多個請求；如下圖
HTTP缺點：
通信使用明文，內容會被竊聽；
不驗證通信方身份，可能會僞裝；
無法證明報文的文正，可能會被篡改；
1.通信使用明文，內容被竊聽，加密處理防止竊聽；
通信加密-->使用ssl和tls加密http，http+ssl=https，在安全的通信線路上進行傳輸請求和響應；
內容加密-->在報文主體中加密，client和server端都需要有加解密機制；
2.不驗證通信方身份，可能會僞裝，
客戶端僞裝
web服務器僞裝
使用ssl證書機制；
3.無法證明報文的存在，可能會被篡改；
接受到的內容可能被篡改；
如何防止被篡改，使用數字證書即md5和sha算法校驗方法；
HTTP+加密+認證+完整保護=HTTPS，即HTTP通信接口使用ssl或tls協議；
加密技術：
1.對稱密鑰加密
加解密使用相同的密鑰，會被竊聽，只要有密鑰就可以加解密了；
2.非對稱密鑰加密
使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。利用這種方式，不需要發送用來解密的私有
密鑰，也不必擔心密鑰被***者竊聽而盜走。
HTTPS使用混合加密機制；
HTTPS通信步驟：
1.客戶端通過發送 Client Hello 報文開始 SSL 通信。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）；
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 的通信；
HTTPS缺點，處理速度會慢2-100倍；處理慢分爲2種：
1.通信慢；
2.大量消耗cpu和內存資源，負載高；
解決方法：
1.SSL加速器；
2.非敏感信息使用http通信；
認證：只爲某部分人可訪問服務器；
覈對登錄人的方法：密碼、動態令牌(一次性密碼)、數字證書(僅限本人/終端使用)、生物認證(人臉指紋等)、IC卡；
HTTP使用的認證方法：
BASIC認證（基本認證），非常用；
DIGEST認證（摘要認證），非常用；
SSL客戶端認證，需支付費用；
FormBase 認證（基於表單認證）：常用，使用cookie來管理session。
基於表單認證本身是通過服務器端的 Web 應用，將客戶端發送過來的用戶 ID 和密碼與之前登錄過的信息做匹配來進行認證的。但鑑於 HTTP 是無狀態協議，之前已認證成功的用戶狀態無法通過協議層面保存下來。即無法實現狀態管理，因此即使當該用戶下一次繼續訪問，也無法區分他與其他的用戶。於是我們會使用 Cookie 來管理Session，以彌補 HTTP 協議中不存在的狀態管理功能。
HTTP瓶頸：
微信、QQ、微博等SNS平臺，當有海量信息公佈，服務器要通知每個需送達的客戶端，http無法妥善的處理這些信息；
web服務器使用http，會遇到以下瓶頸：
1.一條連接上只可發送一個請求。
2.請求只能從客戶端開始。客戶端不可以接收除響應以外的指令。
3.請求 / 響應首部未經壓縮就發送。首部信息越多延遲越大。
4.發送冗長的首部。每次互相發送相同的首部造成的浪費較多。
5.可任意選擇數據壓縮格式。非強制壓縮發送。
解決方法：
Ajax：異步JavaScript和XML技術，是一種有效利用 JavaScript 和DOM（Document Object Model，文檔對象模型）的操作，以達到局部 Web 頁面替換加載的異步通信手段。和以前的同步通信相比，由於它只更新一部分頁面，響應中傳輸的數據量會因此而減少，藉由這種手段，就能從已加載完畢的 Web 頁面上發起請求，只更新局部頁面。
缺點：利用 Ajax 實時地從服務器獲取內容，有可能會導致大量請求產生。
comet：一旦服務器更新後，comet不會讓請求等待，而是直接給客戶端返回響應，這種延遲的應答，模擬實現服務器向客戶端推送，但爲了實現推送功能，Comet 會先將響應置於掛起狀態，當服務器端有內容更新時，再返回該響應。因此，服務器端一旦有更新，就可以立即反饋給客戶端。但爲了保留響應，一次連接的持續時間也變長了。期間，爲了維持連接會消
耗更多的資源。
WebSocket，即 Web 瀏覽器與 Web 服務器之間全雙工通信標準，主要是爲了解決 Ajax 和 Comet 裏XMLHttpRequest 附帶的缺陷所引起的問題。
一旦瀏覽器和服務器建立websocket協議，以後的所有通信多依靠這個專用協議進行；
WebSocket協議的主要特點：
推送功能，支持由服務器向客戶端推送數據功能；
減少通信量，一旦建立WebSocket鏈接，就一直保持連接；
握手請求(一次)
握手響應
web技術
HTML超文本傳輸協議，標記語言是指通過在文檔的某部分穿插特別的字符串標籤，用來修飾文檔的語言，這種特殊字符串稱爲HTML標籤；
設計應用CSS，層疊樣式表，如何展現html內的各種元素；
CSS 的理念就是讓文檔的結構和設計分離，達到解耦的目的；
動態HTML：使用客戶端的腳本語言使靜態的HTML內容變成動態的技術的總稱；
動態 HTML 技術是通過調用客戶端腳本語言 JavaScript，實現對 HTML 的 Web 頁面的動態改造，利用DOM（Document Object Model，文檔對象模型）可指定欲發生動態變化的 HTML 元素；
DOM：用以操作HTML和XML文檔的API(應用編程接口)，使用DOM可以將HTML內的元素當做對象操作，如取出元素內的字符串、改變那個 CSS 的屬性等，使頁面的設計發生改變；
web初期：由客戶端發起請求後，服務器返回實現準備好的內容，隨着web普及後，引入了動態創建HTML內容；
CGI通用網關接口：web服務器在接收到客戶端的請求後轉發給程序的一套機制，在CGI的作用下，程序會根據請求內容動態作出相應的動作，如創建HTML內容；
CGI程序：PHP、C、perl等；CGI程序被用來解釋處理來自表單的輸入信息，並在服務器產生相應的處理，或將相應的信息反饋給瀏覽器。CGI程序使網頁具有交互功能，每次接到請求，程序都要跟着啓動一次。因此一旦訪問量過大，Web 服務器要承擔相當大的負載；
servlet是java語言實現的接口，是一種能在服務器上動態創建內容的程序，Servlet 常駐內存因此在每次請求時，可啓動相對進程級別更爲輕量的 Servlet，程序的執行效率從而變得更高；
數據發佈的格式與語言：
XML可擴展標記語言，是一種可按應用目標進行擴展的通用標記語言。
發佈更新信息的 RSS/Atom
Javascript的JSON