WEB服務與NGINX(1)-HTTP協議基礎


WEB服務與NGINX(1)



1. HTTP協議

HTTP(Hyper Text Transfer Protocol),超文本的傳輸協議。

HTTP是一種能夠獲取如 HTML 這樣的網絡資源的通訊協議。它是在 Web 上進行數據交換的基礎,是一種 C/S架構模型。HTTP協議就是將客戶端請求的WEB資源從WEB等相關服務器上傳輸到客戶端的一種協議。

1.1 WEB資源

一個網頁由多個資源構成,打開一個頁面,會有多個資源展示出來,但是每個資源都要單獨請求。因此,一個“Web 頁面”通常並不是單個資源,而是一組資源的集合。像是文本、布局描述、圖片、視頻、腳本等等,這些不同類型的資源可能存放在不同的服務器上。

資源分為靜態文件和動態文件兩種:

  • 靜態文件:無需服務端做出額外處理,直接以原樣發送給客戶端。
    • 文件后綴:.jpg, .html, .txt, .js, .css, .mp3, .avi
  • 動態文件:服務端執行相應程序,返回執行的結果
    • 文件后綴:.asp, .php, .jsp

image

一個WEB網頁常常用到HTML,CSS,JAVA SCRIPT,MIME等前端語言編寫。
image

  • html(Hyper Text Markup Language )

    http協議傳輸使用的文件大部分為html(也可以封裝傳輸其他類型文件),使用超文本標記語言編程語言編寫,里面包含了多個URL資源。

    #簡單的HTML語言示例
    <html>
    <head>
    <title>html語言
    </title>
    </head>
    
    <body>
    <img src="http://www.alidns.com/static/img/logo.png" >
    <h1>標題1</h1>
    <p><a href=http://www.alidns.com/>linux</a>welcome</p>
    </body>
    </html>
    
  • CSS (Cascading Style Sheet )

    層疊樣式表:控制網頁樣式並允許將樣式信息與網頁內容分離的一種標記性語言,相當於定義一個標准,可以應用於其他頁面,不需要每個頁面重復編制。

  • js javascript(與java沒有關系)

    JavaScript:一種直譯式腳本語言,是一種動態類型、弱類型、基於原型的語言,內置支持類型,在網頁上使用時,用來給HTML網頁增加動態功能。

  • MIME(Multipurpose Internet Mail Extensions)

    多用途互聯網郵件擴展 :服務器將MIME標志符放入傳送的數據中來告訴瀏覽器使用哪種插件讀取相關文件,進而實現以文本方式編碼發送非文本格式的文件,例如圖片,音樂,視頻等,HTML支持了MIME之后才可以用來傳輸音樂,圖片,視頻等資源。

1.2 URI簡介

HTTP 請求的內容通稱為"資源"。”資源“這一概念非常寬泛,它可以是一份文檔,一張圖片,或所有其他你能夠想到的格式。每個資源都由一個URI來進行標識。

URI稱為統一資源標志符,是指定在Internet上可以找到資源的位置的文本字符串。主要有URL和URN兩種形式。

  • URL:統一資源定位符,用於描述某服務器某特定資源位置。
  • URN:統一資源命名,典型的就是P2P下載使用的磁力鏈接,將需求資源標識為名字,而不是指向一個地址,通過搜索資源名,在互聯網上找哪些主機上有此資源,然后發起並行連接,連接到所有有資源的主機上,進行下載。

URL的組成格式為:

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

例如:https://list.jd.com/list.html?cat=670,671,672&ev=149_2992&sort=sort_totalsales15_desc&trans=1

其中各個字段的意義如下:

  • schame

    訪問服務器獲取資源時要使用哪種協議,告訴負責解析URL的應用程序應該使用什么協議;由一個字母符號開始,由第一個[ : ]將其與URL的其余部分分隔開,方案名不區分大小寫,常見協議有http,https,ftp等。

  • user

    用戶,訪問資源時需要的用戶名,可省略。

  • password

    密碼,用戶對應的密碼,中間用:分隔

  • Host

    主機,資源宿主服務器的主機名或IP地址或FQDN

  • port

    端口,資源宿主服務器正在監聽的端口號,很多方案有默認端口號,例如http使用80端口,https默認使用443端口,當使用默認端口時可省略。

  • path

    路徑,服務器資源的目錄名和文件名,由一個/將其與前面的URL組件分隔,稱為短URL。

  • query

    查詢,用於傳遞參數給程序。例如:?key1=value1&key2=value2 ,是提供給 Web 服務器的額外參數。這些參數是用 & 符號分隔的鍵/值對列表。Web 服務器可以在將資源返回給用戶之前使用這些參數來執行額外的操作。

  • frag

    片段,當一個網頁很大時,使用frag進行分頁標識,快速定位,一小片或一部分資源的名字,此組件在客戶端使用,用[ # ]分隔。是資源本身的某一部分的一個錨點。錨點代表資源內的一種“書簽”,它給予瀏覽器顯示位於該“加書簽”點的內容的指示。 例如,在HTML文檔上,瀏覽器將滾動到定義錨點的那個點上;在視頻或音頻文檔上,瀏覽器將轉到錨點代表的那個時間。值得注意的是 # 號后面的部分,也稱為片段標識符,永遠不會與請求一起發送到服務器。

1.3 WEB服務請求處理過程

用戶在瀏覽器中輸入網址獲取網頁資源的過程如下圖:

image

詳細的過程如下:

  1. 客戶端瀏覽器分析URL,首先查找瀏覽器本地緩存,若有緩存則直接加載頁面。

  2. DNS解析

    客戶端發出訪問www.xxx.com請求,先從本地host文件解析,不能解析,交給本機DNS緩存;

    本機沒有解析記錄的話,發送給本地解析服務器,本地DNS服務器查詢緩存,是否有記錄可以回應;

    本地DNS服務器緩存沒有記錄,發往DNS根服務器開始尋址,根服務器返回一級域名.com;

    本地DNS服務器拿到一級域名后,訪問一級域DNS服務器,返回二級域名xxx.com;

    本地DNS服務器訪問二級域名,得到IP地址www.xxx.com,本地DNS服務器將全稱域名緩存至本地,然后發送給客戶;

  3. 建立連接

    用戶向服務器端發送一個數據包SYN=1,seq=x;

    如果服務器端可以收到,則發送SYN=1,ACK=1,seq=y,ack=x+1;

    客戶收到服務器端的回應包,再發送ACK=1,seq=x+1,ack=y+1,服務器端收到后,則建立成功;

  4. web服務請求回應

    (1)建立連接

    客服向服務器發起請求,此請求包括一些數據報文的頭部,包括(method:GET、POST/PUT/HEAD/DELECT等);

    (2)接收請求(可能會拒絕)

    接收客戶端請求報文中對某資源的一次請求的過程;

    (3)處理請求

    服務器對請求報文進行解析,並獲取請求的資源及請求方法等相關信息,根據方法,資源,首部和可選的主體部分對請求進行處理;

    (4)訪問資源

    服務器獲取請求報文中請求的資源web服務器,即存放了web資源的服務器,負責向請求者提供對方請求的靜態資源,或動態運行后生成的資源;

    (5)構建響應報文

    一旦Web服務器識別出了資源,就執行請求方法中描述的動作,並返回響應報文。響應報文中 包含有響應狀態碼、響應首部,如果生成了響應主體的話,還包括響應主體;

    (6)發送響應報文

    Web服務器通過連接發送數據時也會面臨與接收數據一樣的問題。服務器可能有很多條到各個客戶端的連接,有些是空閑的,有些在向服務器發送數據,還有一些在向客戶端回送響應數據。服務器要記錄連接的狀態,還要特別注意對持久連接的處理。對非持久連接而言,服務器應該在發送了整條報文之后,關閉自己這一端的連接。對持久連接來說,連接可能仍保持打開狀態,在這種情況下,服務器要正確地計算Content-Length首部,不然客戶端就無法知道響應什么時候結束了;

    (7)記錄日志

    最后,當事務結束時,Web服務器會在日志文件中添加一個條目,來描述已執行的事務。

1.4 HTTP報文結構

HTTP主要有request報文和response報文,下面介紹報文的內容。

1.4.1 request報文

request報文語法格式如下:

<method> <request-URL> <version>
<headers>
   //此處空行為必須
<entity-body>

request請求的示例如下:

image

其中各個字段的意義如下:

  • method:請求方法,標明客戶端希望服務器對資源執行的動作,常見的method如下:
    • GET:用於獲取URI對應的資源;
    • HEAD:只從服務器獲取文檔的響應首部,沒有entity-body信息;
    • POST:向服務器發送要處理的數據,用於提交請求,可以更新或創建資源,是非冪等的,類似發布朋友圈;
    • PUT:用於向指定的URI傳送更新資源,如上傳文件,是冪等的,類似於更新朋友圈;
    • DELETE:請求刪除服務器上指定的資源;
    • TRACE:追蹤請求到達服務器中間經過的代理服務器;
    • OPTIONS:請求服務器返回對指定資源支持使用的請求方法;
  • PATH:請求的資源路徑
  • version:http協議版本:HTTP/<major>.<minor>
  • headers:報文首部,每個請求或響應報文可包含任意個首部;每個首部都有首部名稱,后面跟一個冒號,而后跟一個可選空格,接着是一個值;
  • entity-body:請求時附加的數據或響應時附加的數據;

請求的headers內容如下:

:authority:	www.web1.com
:method: GET                                          <==請求的方法
:path: /                                              <==請求的路徑
:scheme: https                                        <==使用的協議
Accept:	text/html,                            		  <==請求的類型						
Accept-Encoding: gzip, deflate                        <==啟用壓縮			
Accept-Language: zh-CN,zh;q=0.9						  <==請求的語言							
Cache-Control: max-age=0							  <==啟用緩存											
Connection:	keep-alive								  <==啟用TCP長連接
Host: www.web1.com                                    <==請求的域名
If-Modified-Since:Fri,04 May 2019 02:13:23 GMT	      <==修改的時間
User-Agent:	Mozilla/5.0								  <==客戶端瀏覽器類型
“=== 空行 ===”
“=== 請求主題部分 ===”                                                                

1.4.2 response報文

response報文語法格式:

<version> <status> <reason-phrase>
<headers>
   //此處空行為必須
<entity-body>

response的示例如下:

image

其中各個字段的意義如下:

  • version:http協議版本:HTTP/<major>.<minor>;
  • status code:服務器的狀態碼,代表服務端的狀態;
  • reason-phrase:狀態碼所標記的狀態的簡要描述
1.4.2.1 http協議狀態碼

http協議狀態碼由3位數字組成,用來表示請求是否成功,以及錯誤類型等。

  • 1xx:100-101 信息提示,服務器收到信息,需要請求者繼續執行操作;
  • 2xx:200-206 成功,操作被成功接收並處理;
    • 200:成功,請求數據通過響應報文的entity-body部分發送給客戶端;
    • 206:客戶端發完請求后,服務端只是返回了部分數據,就會出現206,例如當下載一個較大的文件,下載沒有完成前就會提示206狀態碼;
  • 3xx:300-305 重定向,需要進一步的操作以完成請求;
    • 301:永久重定向。請求的URL指向的資源已經被刪除;但在響應報文中通過首部Location指明了資源現在所處的新位置;Moved Permanently
    • 302:臨時重定向。與301相似,但在響應報文中通過Location指明資源現在所處臨時新位置; Found
    • 304:客戶端發出了條件式請求,詢問服務器客戶端本地緩存內容是否有更新,當服務器上的資源未曾發生改變時,則通過響應此響應狀態碼通知客戶端;客戶端上有緩存,直接從緩存返回結果;Not Modified
  • 4xx:400-415 錯誤類信息,客戶端錯誤,請求包含語法錯誤或無法完成請求;
    • 400:客戶端語法有錯誤,服務端無法理解;
    • 401:服務端開啟了用戶認證,需要輸入賬號和密碼認證方能訪問資源,而客戶端未提供正確的認證信息;Unauthorized
    • 403:請求被網站禁止,服務端不允許客戶端訪問,或沒有找到默認返回頁面;Forbidden
    • 404:服務器無法找到客戶端請求的資源;Not Found
  • 5xx:500-505 錯誤類信息,服務器端錯誤,服務器在處理請求的過程中發生錯誤;
    • 500:服務器內部錯誤;Internal Server Error
    • 502:服務器充當代理時,后端被代理的服務器不可用或沒有正常回應;Bad Gateway
    • 503:服務不可用,臨時服務器維護或過載,服務器暫時無法處理請求;
    • 504:服務器充當代理時,后端服務器響應超時;

1.4.3 HTTP首部字段

首部字段同時存在於請求和響應報文內,並涵蓋 HTTP 報文相關的內容信息。使用首部字段是為了給客服端和服務器端提供報文主體大小、所使用的語言、認證信息等內容。

首部字段結構:HTTP 首部字段是由首部字段名和字段值構成的,中間用冒號“:”分隔,字段值對應單個 HTTP 首部字段可以有多個值。

報文首部中出現了兩個或以上具有相同首部字段名的首部字段時,在規范內尚未明確,根據瀏覽器內部處理邏輯的不同,優先處理的順序可能不同,結果可能並不一致。

首部的分類

  • 1、通用首部:請求報文和響應報文兩方都會使用的首部

    • Date 報文的創建時間
    • Connection 連接狀態,如keep-alive(長連接), close(短連接)
    • Via 顯示報文經過的中間節點(代理,網關),用於排查哪個緩存服務器不能訪問
    • Cache-Control 控制緩存,如緩存時長
    • MIME-Version 發送端使用的MIME版本
    • Warning 錯誤通知
  • 2、請求首部:從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、請求內容相關優先級等信息

    • Accept 通知服務器自己可接受的媒體類型
    • Accept-Charset 客戶端可接受的字符集
    • Accept-Encoding 客戶端可接受編碼格式,如gzip
    • Accept-Language 客戶端可接受的語言
    • Client-IP 請求的客戶端IP
    • Host 請求的服務器名稱和端口號
    • Referer 跳轉至當前URI的前一個URL
    • User-Agent 客戶端代理,瀏覽器版本
  • 條件式請求首部

    • Expect 允許客戶端列出某請求所要求的服務器行為
    • If-Modified-Since 自從指定的時間之后,請求的資源是否發生過修改
    • If-Unmodified-Since 與上面相反
    • If-None-Match 本地緩存中存儲的文檔的ETag標簽是否與服務器文檔的Etag不匹配
    • If-Match 與上面相反
  • 安全請求首部

    • Authorization 向服務器發送認證信息,如賬號和密碼
    • Cookie 客戶端向服務器發送cookie
    • Cookie2 用於說明請求端支持的cookie版本
  • 代理請求首部

    • Proxy-Authorization 向代理服務器認證
  • 3、響應首部

    • 從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容,也會要求客戶端附加額外的內容信息
    • Age 從最初創建開始,響應持續時長
    • Server 服務器程序軟件名稱和版本,會泄露服務器端隱私。
  • 協商首部:某資源有多種表示方法時使用

    • Accept-Ranges 服務器可接受的請求范圍類型
    • Vary 服務器查看的其它首部列表
  • 安全響應首部:

    • Set-Cookie 向客戶端設置cookie
    • Set-Cookie2 以上面相似
    • WWW-Authenticate 來自服務器對客戶端的質詢列表
  • 4、實體首部:針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的的信息

    • Allow 列出對此資源實體可使用的請求方法
    • Location 告訴客戶端真正的實體位於何處
    • Content-Encoding 對主體執行的編碼
    • Content-Language 理解主體時最適合的語言
    • Content-Length 主體的長度
    • Content-Location 實體真正所處位置
    • Content-Type 主體的對象類型,如text
  • 緩存相關:

    • ETag 實體的擴展標簽
    • Expires 實體的過期時間
    • Last-Modified 最后一次修改的時間

1.5 HTTP的連接管理

HTTP的連接管理在很大程度上影響着網站和 Web 應用程序的性能,HTTP/1.X版本主要的連接模型有短連接,長連接和HTTP流水線。

三種連接模型示意圖如下:

image

  • 短連接

    HTTP 最早期的模型,也是 HTTP/1.0 的默認模型。每一個 HTTP 請求都由它自己獨立的連接完成;這意味着發起每一個 HTTP 請求之前都會有一次 TCP三次 握手,請求結束之后進行TCP四次揮手;下次發起請求又需要進行TCP三次握手和四次揮手,對資源是很大的浪費。

  • 長連接

    HTTP/1.1版本的默認模型,一個TCP的長連接會保持一段時間,重復用於客戶端發送一系列請求,節省了新建 TCP 連接握手的時間,還可以利用 TCP 的性能增強能力。當然這個連接也不會一直保留着,連接在空閑一段時間后會被關閉(服務器可以使用 Keep-Alive 協議頭來指定一個最小的連接保持時間)。

    長連接也還是有缺點的;就算是在空閑狀態,它還是會消耗服務器資源,而且在重負載時,還有可能遭受 DoS attacks 攻擊。這種場景下,可以使用非長連接,即盡快關閉那些空閑的連接,也能對性能有所提升。

1.6 HTTP無狀態解決方案

HTTP協議是無狀態(stateless)的。HTTP協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別,協議對於發送過的請求或響應都不做持久化處理。這是為了更快地處理大量事務,確保協議的可伸縮性,而特意把 HTTP 協議設計成如此簡單的。可是隨着 Web 的不斷發展,很多業務都需要對通信狀態進行保存。於是引入了 Cookie 和session技術。

  • Cookie

    Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息,通知客戶端保存Cookie。

    當下次客戶端再往該服務器發送請求時,客戶端會自動在請求報文中加入 Cookie 值后發送出去。服務器端發現客戶端發送過來的 Cookie 后,會去檢查究竟是從哪一個客戶端發來的連接請求,然后對比服務器上的記錄,最后得到之前的狀態信息。

    安全性隱患:在Web應用中,Cookie常用來標記用戶或授權會話。因此,如果Web應用的Cookie被竊取,可能導致授權用戶的會話受到攻擊,例如跨站請求偽造(CSRF),對於敏感信息的cookie只能擁有較短的生命期。

  • session

    服務器端記錄用戶狀態的機制,用戶與服務器建立連接的同時,服務器會自動為其分配一個SessionId,此ID以cookie的鍵值形式發送給用戶(key為JSSIONID,value為ID)。

    session用於存儲用戶會話所需的屬性及配置信息,當用戶在應用程序的 Web 頁之間跳轉時,存儲在 Session 對象中的變量將不會丟失,而是在整個用戶會話中一直存在下去。

    多web服務器session同步的解決方案

    • 在調度器中記錄cookie的id,始終將其分配到第一次訪問的服務器

    • 讓服務器之間復制session信息,每台服務器都存放所有服務器的session

    • 搭專用的session服務器(用到redis),需要實現主從,提高容錯

  • cookie和session區別

    cookie是存放在客戶端,session存放在服務器。

    cookie通常有大小限制(常見4k)以及數量限制(部分瀏覽器為20個),session大小和硬件有關,通常沒有規定大小。

1.7 網站訪問量相關術語

  • IP(獨立IP)

    即Internet Protocol,指獨立IP數。一天內來自相同客戶機IP地址只計算一次,記錄遠程客戶機IP地址的計算機訪問網站的次數,是衡量網站流量的重要指標

  • PV(訪問量)

    即Page View, 頁面瀏覽量或點擊量,用戶每次刷新即被計算一次,PV反映的是瀏覽某網站的頁面數,PV與來訪者的數量成正比,PV並不是頁面的來訪者數量,而是網站被訪問的頁面數量,注意:一個頁面包含多個資源。

  • UV(獨立訪客)

    即Unique Visitor,訪問網站的一台電腦為一個訪客。一天內相同的客戶端只被計算一次。可以理解成訪問某網站的電腦的數量。網站判斷來訪電腦的身份是通過來訪電腦的cookies實現的。如果更換了IP后但不清除cookies,再訪問相同網站,該網站的統計中UV數是不變的。

    網站統計:http://www.alexa.cn/rank/

  • QPS(request per second,每秒請求數)

    QPS= PV* 頁面衍生連接次數/ 統計時間(86400)

    頁面衍生連接數:一個頁面的資源數

  • 並發連接數

    並發連接數 =QPS * http平均響應時間

  • 峰值時間

    每天80%的訪問集中在20%的時間里,這20%時間為峰值時間

    峰值時間每秒請求數(QPS)=( 總PV數 頁⾯衍⽣連接次數)80% ) / ( 每天秒數 * 20% )

  • 網站訪問統計示例

    甲乙丙三人在同一台通過ADSL上網的電腦上(中間沒有斷網),分別訪問www.magedu.com網站,並且每人各瀏覽了2個頁面,那么網站的流量統計是:

    IP: 1 PV:6 UV:1

    若三人都是ADSL重新撥號后,各瀏覽了2個頁面,則

    IP: 3 PV:6 UV:1

  • 用戶速度體驗的1-3-10原則,即01秒最優,13秒較優,3~10秒比較慢,10秒以上用戶無法接受。用戶放棄一個產品的代價很低,只是換一個URL而已

  • 性能對用戶的行為的影響

    79%的用戶表示不太可能再次打開一個緩慢的網站

    47%的用戶期望網頁能在2秒鍾以內加載

    40%的用戶表示如果加載時間超過三秒鍾,就會放棄這個網站

    頁面加載時間延遲一秒可能導致轉換損失7%,頁面瀏覽量減少11%

    8秒定律:用戶訪問一個網站時,如果等待網頁打開的時間超過8秒,會有超過30%的用戶放棄等待

1.8 curl命令

curl工具是基於URL語法在命令行方式下工作的文件傳輸工具,它支持FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE及LDAP等協議。

curl支持HTTPS認證,並且支持HTTP的POST、PUT等方法, FTP上傳, kerberos認證,HTTP上傳,代理服務器,cookies,用戶名/密碼認證, 下載文件斷點續傳,上載文件斷點續傳, http代理服務器管道( proxy tunneling),還支持IPv6,socks5代理服務器,通過http代理服務器上傳文件到FTP服務器等,功能十分強大。

curl命令的語法為:

curl [options...] <url>

curl的常用選項如下:

選項 說明
-A/--user-agent <string> 在服務器日志文件中一般會記錄客戶端使用的瀏覽器,該選項用於偽造客戶端瀏覽器。
-e/--referer <URL> 用於偽造客戶端跳轉地址,即訪問目標網站是從其他網站點擊鏈接跳轉過來的。
--cacert <file> 指定CA證書 (SSL) 驗證服務器端證書
-k 允許忽略證書進行 SSL 連接
--compressed 要求返回是壓縮的格式,需要服務器端支持壓縮
-H/--header <line> 自定義首部信息傳遞給服務器
-i 顯示頁面內容,包括報文首部信息
-I/--head 只顯示響應報文首部信息
-D/--dump-header <file> 將url的header信息存放在指定文件中
--basic 使用HTTP基本認證
-u/--user <user[:password]> 設置服務器的用戶和密碼,在http認證時使用
-L 如果有3xx響應碼(重定向),重新發請求到新位置
-O 使用URL中默認的文件名保存文件到本地
-o <file> 將網絡文件保存為指定的文件中,不可以下載二進制文件,可能會出錯
--limit-rate <rate> 設置傳輸速度
-0/--http1.0 指定使用HTTP 1.0
-C 可對文件使用斷點續傳功能
-c/--cookie-jar <file name> 將url中cookie存放在指定文件中
-x/--proxy <proxyhost[:port]> 指定代理服務器地址
-X/--request <command> 向服務器發送指定請求方法
-U/--proxy-user <user:password> 指定代理服務器用戶和密碼

crul命令的使用示例如下:

#示例一:不加參數訪問網頁內容
[root@xuzhichao ~]# curl http://192.168.20.20
welcome to nginx-server01

#示例二:使用-A選項偽造客戶端
#正常情況下服務器上記錄的客戶端瀏覽器類型如下:
[root@nginx01 ~]# cat /var/log/nginx/access.log
192.168.20.17 - - [11/Jun/2021:22:42:49 +0800] "GET / HTTP/1.1" 200 26 "-" "curl/7.29.0" "-"

#偽造IE10瀏覽器
[root@xuzhichao ~]# curl -A 'IE 10' http://192.168.20.20
welcome to nginx-server01

[root@nginx01 ~]# cat /var/log/nginx/access.log
192.168.20.17 - - [11/Jun/2021:22:50:19 +0800] "GET / HTTP/1.1" 200 26 "-" "IE 10" "-"

#示例三:偽造跳轉地址,訪問目標網站是從baidu上跳轉過來的
[root@xuzhichao ~]# curl -e "www.baidu.com" http://192.168.20.20
welcome to nginx-server01

[root@nginx01 ~]# cat /var/log/nginx/access.log
192.168.20.17 - - [11/Jun/2021:22:55:58 +0800] "GET / HTTP/1.1" 200 26 "www.baidu.com" "curl/7.29.0" "-"

#示例四:顯示訪問網站的首部信息
[root@xuzhichao ~]# curl -I http://192.168.20.20
HTTP/1.1 200 OK
Server: nginx/1.16.1
Date: Fri, 11 Jun 2021 14:42:55 GMT
Content-Type: text/html
Content-Length: 26
Last-Modified: Fri, 11 Jun 2021 14:42:29 GMT
Connection: keep-alive
ETag: "60c37655-1a"
Accept-Ranges: bytes

#示例五:顯示重定向后的頁面
#當訪問網站被跳轉時,使用curl正常訪問只會返回網站被跳轉信息
[root@xuzhichao ~]# curl www.taobao.com
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<h1>301 Moved Permanently</h1>
<p>The requested resource has been assigned a new permanent URI.</p>
<hr/>Powered by Tengine</body>
</html>

#加上-L會顯示跳轉后的頁面
[root@xuzhichao ~]# curl -L www.taobao.com
......(真實網頁)

#示例六:向服務端發送指定的請求方法
[root@xuzhichao ~]# curl -I -X OPTIONS 192.168.20.20
Allow: GET,HEAD,POST,OPTIONS,TRACE


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM