- 學習過程對書本的內容的摘要以及總結,逐步完善,帶有我的理解成分。
Web 及網絡基礎
使用 HTTP 協議訪問 Web
- 客戶端:經過獲取請求獲取服務資源的 Web 瀏覽器等
- HTTP 全稱:HtyperText Transfer Protocol
- WWW 全稱:Wrold Wide Web
- SGML 標準通用標記語言 全稱:Standard Generalized Markup Language
網絡基礎 TCP/IP
- TCP/IP 協議族,或指TCP、IP
- 協議族常見協議:TCP、UDP、IP、PPPoE、DNS、SNMP、ICMP 等
TCP/IP 的分層管理
分爲四層:應用層、傳輸層、網絡層、數據鏈路層html
應用層
- 決定了向用戶提供應用服務時通訊的活動
- 預存了各種通用的應用服務。如:DNS、FTP
- HTTP 協議也在該層
傳輸層
- 對上層應用層,提供處於網絡鏈接中的兩臺計算機之間的數據傳輸協議
- TCP、UDP在其中
網絡層(網絡互連層)
- 處理網絡上的流動數據包。
- 數據包:網絡傳輸的最小單位。
- 規定了經過了怎樣的傳輸路徑(傳輸路線)到達對方的計算機,並把數據包給對方。
鏈路層(數據鏈路層、網絡接口層)
- 處理鏈接網絡的硬件部分。
- 例如:控制操做系統、硬件的設備驅動、光纖等,硬件範圍。
TCP/IP 通訊傳輸流
- 發送端:應用層往下走。接受端相反
- 發送端:層與層之間傳輸數據的時候會把對應的首部信息打上。反之消去首部。
- 把數據包裝起來的作法叫封裝。
與 HTTP 密切相關的協議:IP、TCP 和 DNS
負責傳輸的 IP 協議
- IP:Internet Protocol 位於網絡層的網際協議。
- 把各自數據包傳送給對方。
- 要保證確實傳輸到對方那裏,須要知足各種條件。其中兩個重要的是:IP 地址和 MAC 地址(Media Access Control Address)。IP 地址指明瞭節點被分配的地址,MAC 地址是指網卡所屬的固定地址。
- IP 地址可和 MAC 地址相互匹配,IP 地址可變換, MAC 地址基本上不會更改。
使用ARP協議(Address Resolution Protrocol)協議
- 是一種用以解析地址的協議。
- 根據通訊方的IP地址就能夠反查出對應的 MAC 地址。
確保可靠性的 TCP 協議
負責域名解析的 DNS 服務
- DNS(Domain Name System)是位於應用層的協議。同 HTTP 同樣。
- 提供域名到 IP 地址之間的解析服務。可逆向查詢。
- 計算機可被賦予 IP 地址,也可被賦予 主機名和域名。一般用主機名或域名,由於符合人類記憶習慣。
各類服務與 HTTP 協議的關係
URI 和 URL
- URI:Uniform Resource Identifier 統一資源標識符。
-
- Uniform 規定統一的格式,方便處理多種不一樣類型的資源。
- Resource 資源的定義是「可標識的任何東西」。除文檔文件、圖形或服務等可以區別與其餘的,所有可作資源。資源不只可單一,也能夠是多數的集合體。
- Identifier 表示可標識的對象。也稱標識符。
- 就是由某個協議方案表示的資源定位符。協議方案是指訪問資源時使用的協議的類型名稱。例如:採用 HTTP 協議的時候,協議方案就是 http。除此以外,還有ftp、file等30多種。
URI 用字符串標識着某一互聯網資源,URL 表示資源的地點。cookie
可見,URL 是 URI 的子集。網絡
- URL:Uniform Resource Locator 統一資源定位符。
URI 格式
- 表示指定的 URL ,要使用涵蓋所有必要信息的 絕對 URL 、絕對 URL 以及相對 URL 以及相對 URL 。相對 URL ,是指從瀏覽器中基本 URL 處指定的 URL,形如 /image/logo.gif
絕對 URL 的格式:less
http:// user:pass @ www. exanple.jp: 80 / dir/index.htm ? uid=1 # ch1jsp
- http:// 協議方案名。不區分大小寫。
- user:pass 登陸信息(認證)。可選信息。
- www. exanple.jp: 服務器地址。
-
- 使用絕對的URL必須指定待訪問的服務器地址。
- 地址能夠是相似 hackr.jp 這種DNS 可解析的名稱,也能夠是 192.168.1.1 這種相似 IPv4 地址名,還能夠是 [0:0:0:0:0:0:0:1]這種方括號括起來的 IPv6 地址名。
- 80 服務器端口號。可選項。省略則使用默認的端口號。
- dir/index.htm 帶層次的文件路徑。與 UNIX 系統的文件目錄結構相似。
- uid=1 查詢字符串。針對已指定的文件路徑內的資源。可選。
- ch1 片斷標識符。一般可標記出已獲取資源的子資源。可選。 RFC 中沒有規定其使用方法。
RFC(Request for COmments)徵求修正意見書tcp
制定 HTTP 協議技術標準的文檔。
簡單的 HTTP 協議
HTTP 協議用於客戶端和服務端之間的通訊
- 一定是一端擔任客戶端角色,另外一端擔任服務器角色。
經過請求和響應的交換達成通訊
實例:
客戶端發給某個服務器的請求報文中的內容。
GET /index.htm HTTP/1.1
Host : hacker.jp
- GET 請求訪問服務器的類型,稱爲方法(method)。
- /index.htm 指明瞭訪問的資源對象。稱爲 請求URI(request-URI)。
- HTTP/1.1 是 HTTP 的版本號。
意思是:請求訪問某臺 HTTP 服務器上的 /index/htm 頁面資源
// 服務器
HTTP/1.1 200 OK
Date: Tue, 1 Jan 2020 08:00:01 GMT
Content-Length: 362
Content-Type: text/html
...
請求報文是由請求方法、請求URL、協議版本、可選的請求首部字段和內容實體構成。
- HTTP/1.1 表示服務對應的 HTTP 版本。
- 200 OK 表示請求的處理結果的狀態碼(status code)和緣由短語(reason-phrase)。
- 下一行顯示響應的時間,是首部字段(header field)內的一個屬性。
- 接下來,空一行 分隔,以後的內容稱爲資源實體的主體(enntity field)
- GMT 是響應首部字段。
HTTP 是不保存狀態的協議
- 無狀態協議(stateless)
- HTTP 這個級別,協議對於發送請求或響應都不作持久化處理。
- 每當有新的請求,即產生新的響應,不保存以前的響應報文信息。
- 爲了保持狀態,引入 Cookie 技術。
請求 URL 定位資源
若是不是訪問特定的資源,而是對服務器自己發起請求,能夠用一個 * 來代替請求URI。例如:
OPTIONS * HTTP/1.1
告知服務器意圖的 HTTP 方法
GET :獲取資源
- GET 方法用來請求訪問已被 URI 識別的資源。
- 指定的資源經服務端解析後返回響應內容。若是請求資源是文本,那就保持原樣返回;若是是像 CGI(Common Gateway Interface) 通用網關接口那樣的程序,則返回通過執行後的輸出結果。
例子:
請求 |
Get /index.html http/1.1 |
響應 |
返回 index.html 的頁面資源 |
請求 |
Get /index.html http/1.1 Host: www.hackr. jp if-modified-since: thu, 1 jan 2020 08:20:01 gmt |
響應 |
僅返回2020年1月1日8點20分之後更新過的index頁面資源。 |
POST:傳輸實體主體
例子:
請求 |
post /submit.cgi http/1.1 Host: www.hackr. jp content-length:1560(1560字節的數據) |
響應 |
返回 submit.cgi 接收數據的處理結果 |
PUT:傳輸文件
- 傳輸文件,像 FTP 同樣。
- 要求在請求報文主體中包含文件內容,而後保存到請求 URI 制定的位置。
- HTTP/1.1 自身不帶驗證機制。存在安全問題,通常不用。
- 若配合 Web 應用程序的驗證機制,或採用 REST(REpresentational State Transfer,表徵狀態轉移) 標準的同類 Web 網站,可能會使用。
例子:
請求 |
put /example.html http/1.1 host: www.hackr .jp content-type: text/html content-length: 1560 (1560字節的數據) |
響應 |
響應返回狀態碼 204 Not Content (好比:該 html 已存在於服務器上) |
HEAD:得到報文首部
- HEAD 方法和 GET 方法同樣,不返回報文主體部分。
- 用於確認 URL 的有效性及資源更新的日期時間等。
例子:
請求 |
head /index.html http/1.1 host: www.hackr .jsp |
響應 |
返回 index.html有關的響應首部 |
DELETE:刪除文件
- 用來刪除文件,是與 PUT 相反的方法。
- 可是和 HTTP/1.1 同樣,不帶驗證機制,因此通常的 Web 網站也不使用 DELETE 方法。
- 當配合 Web 應用程序的驗證機制,或遵循 REST 標準時仍是有可能會開放使用。
例子:
請求 |
DELETE /example.html HTTP/1.1 |
響應 |
響應返回狀態碼 204 No Content (好比:該 html 已從該服務器上刪除) |
OPTIONS:詢問支持的方法
例子:
請求 |
OPTIONS * HTTP/1.1 Host:www.hackr .jp |
響應 |
HTTP/1.1 200 OK Allow: GET, POST, HEAD, OPTIONS(返回服務器支持的方法) |
TRACE:追蹤路徑
- 讓 Web 服務器端將以前的請求經過通訊迴環給客戶端的方法。
- 在 Max-Forwards 首部字段中填入數值,每通過一個服務器就將該數字減1,當數字減到 0 時,就返回狀態碼 200 OK 的響應。
- 客戶端經過 TRACE 方法查詢發送出去的請求是怎樣被加工修改/篡改的。由於請求鏈接到源目標服務器可能會經過代理中轉,TRACE 方法就是用來確認鏈接過程當中發生的一系列操做。
- 不經常使用。易引起 XST(Cross-Site Tracing,跨站追蹤)攻擊。
例子:
請求 |
TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 |
響應 |
HTTP/1.1 200 OK Content-Type: message/http
TRACE / HTTP/1.1 Host: hackr.jp Max-Forwards:2 (返回響應包含的請求內容) |
CONNECT:要求要用隧道協議鏈接代理
- 要求在與代理服務器通訊時創建隧道,實現用隧道協議進行 TCP 通訊。
- 主要使用 SSL (Secure Sockets Layer,安全套接層) 和 TLS(Transport Layer Security,傳輸層安全)協議把通訊內容加密後經網絡隧道傳輸。
- 語法格式:CONNECT 代理服務名:端口號 HTTP版本
例子:
請求 |
CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp |
響應 |
HTTP/1.1 200 OK(以後進入網絡隧道) |
使用方法下達命令
- 向請求 URI 制定的資源發送請求報文時,採用成爲方法的命令。
- 方法的做用在於,能夠指定請求的資源定期望產生某種行爲。方法中有 GET、POST 和 HEAD 等。
支持的方法
方法 |
說明 |
支持的 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 |
TRACE |
追蹤路徑 |
1.1 |
CONNECT |
要求用隧道協議鏈接代理 |
1.1 |
LINK |
創建和資源之間的聯繫 |
1.0 |
UNLINE |
斷開鏈接關係 |
1.0 |
持久鏈接節省通訊量
- 以前的狀況:每進行一次 HTTP 通訊就要斷開一次 TCP 鏈接。
持久鏈接
- 持久鏈接(HTTP Persistent Connections),也稱爲 HTTP keep-alive 或 HTTP connection reuse。
- 特色:只要任意一端沒有明確提出斷開鏈接,則保持 TCP 鏈接狀態。
- 在 HTTP/1.1 中全部的鏈接默認都是持久鏈接。
管線化
- 使用管線化技術,不用等待響應便可直接發送下一個請求
使用 Cookie 的狀態管理
- HTTP 協議,無協議也有好處,簡單纔會被更多的應用。
Cookie 技術:經過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。
Cookie 會根據從服務器端發送的響應報文內的一個叫 Set-Cookie 的首部字段信息,通知客戶端保存 Cookie。
下次再客戶端再往該服務器發送請求時,客戶端會自動再請求報文中加入 Cookie 值後發送出去。
1.請求報文(沒有 Cookie 信息的狀態)
GET /reader/ HTTP/1.1
Host: hackr.jp
2.響應報文(服務器端生成 Cookie 信息)
HTTP /1.1 200 OK
Date: Tue, 1 Jan 2020 08:10:01 GMT
Sever: Apache
<Set-Cookie:sid=13420770140226734; pa+10-jan-11 08:10:01 GMT>
content-Type: text/plain; charaset=UTF-8
3.請求報文
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724