跟Coy學運維—http原理和IO模型

Nginx (web server,web reverse proxy)
重點是反向代理
http協議:80/tcp  超文本傳輸協議,爲了傳輸超文本例如html
html:超文本標記語言
文本:HTTP/1.0,MIME

一,MIME                                                                      

MIME:  Multipurpose Internet Mail Extension  多功能因特網郵件擴展,也能過支持多媒體
MIME類型是由一個媒體類型和一個子類型組成。媒體類型和子類型用一個斜槓(/)分隔開,例如text/css,它會告訴瀏覽器文件是純文本文件,也是一個CSS樣式表。每個媒體類型都表示一種文件類型,媒體類型及說明見下表。
一 媒體類型及說明
 
MIME類型
 

二,web服務器url解析,請求報文及響應報文      

web服務器,若是訪問資源,必須靠url標記
  1. <scheme>://<user>:<password>@<host>:<port>/<path>:<params>?<query>#<frag>
  2. 最重要的3個部分:
  1. scheme:方案,訪問服務器以獲取資源時要使用哪一種協議,如:http 【最重要】
  2. host:主機,資源宿主服務器的主機名,ip地址 【最重要】
  3. path:路徑,服務端上的資源本地名,由斜槓分割開來,如:index.html 【最重要】
  4. user:password,訪問資源時須要的用戶名和密碼,中間冒號不能丟
  5. port:端口,默認端口爲80
  6. params:參數,參數爲名/值對(如:name='xiaodeng'),url能夠包含多個參數字段,他們之間以及與路徑的其他部分之間用‘&’分隔。
  7. query:查詢,用字符‘?’將其與url的其餘部分分割開來
經過url來標記衆多資源,所以互聯網的資源至少有一個標識
 
用戶代理跟服務器資源交互,這一次叫http事物
 基本流程:
  a. 域名解析
  b. 發起TCP的3次握手
  c. 創建TCP鏈接後發起http請求
  d. 服務器端響應http請求,瀏覽器獲得html代碼
  e. 瀏覽器解析html代碼,並請求html代碼中的資源
  f. 瀏覽器對頁面進行渲染呈現給用戶
 
報文:
有兩部分組成:request Message(請求報文)response Message(響應報文)
請求方通常是有用戶代理髮起的,響應服務器端進行響應,爲了可以兩者以前的請求響應可以互相通訊,要藉助於底層的tcp/ip協議通訊子網來完成通訊
但http本身的工做流程則在應用層協議,http請求協議的報文中得以維持和包含
http請求報文格式:
 
一個HTTP請求報文由請求行(request line)、請求頭部(header)、空行和請求數據4個部分組成
請求行:<method> <URL> <version>
請求頭部 <HEADERS>#請求頭部
               
請求主體: <body>#post有boby 
 
請求行:
由3部分組成,分別爲:請求方法、URL(見備註1)以及協議版本,之間由空格分隔
請求方法包括GET(從服務器請求資源)、HEAD(和GET同樣只是返回響應首部,不會返回主體)、PUT(上傳資源的)、POST(瀏覽器或者User-agent一方提交表單的)、TRACE(跟蹤資源中間經歷過的代理服務器)、OPTIONS(看到資源用的那些請求方法)、DELETE(刪除某一資源)以及擴展方法,固然並非全部的服務器都實現了全部的方法,部分方法即使支持,處於安全性的考慮也是不可用的協議版本的格式爲:HTTP/主版本號.次版本號,經常使用的有HTTP/1.0和HTTP/1.1
請求頭部:
請求頭部爲請求報文添加了一些附加信息,由「名/值」對組成,每行一對,名和值之間使用冒號分隔
常見請求頭以下:
If-Modified-Since 
If-None-Match
在緩存中做用比較大
 
例子:
GAT
POST
 
http響應報文格式:
一個HTTP請求報文由狀態行、響應頭部、空行和響應主體4個部分組成
請求行:<version> <status> <reason phrase>
響應頭部: <HEADERS>
 
響應主體:<body>
 
狀態行:
由3部分組成,分別爲:協議版本,狀態碼,狀態碼描述,之間由空格分隔
狀態代碼爲3位數字,200~299的狀態碼錶示成功,300~399的狀態碼指資源重定向,400~499的狀態碼指客戶端請求出錯,500~599的狀態碼指服務端出錯(HTTP/1.1向協議中引入了信息性狀態碼,範圍爲100~199)
1**(信息類):表示接收到請求而且繼續處理
    100——客戶必須繼續發出請求
    101——客戶要求服務器根據請求轉換HTTP協議版本
  2**(響應成功):表示動做被成功接收、理解和接受
    200——代表該請求被成功地完成,所請求的資源發送回客戶端
    201——提示知道新文件的URL
    202——接受和處理、但處理未完成
    203——返回信息不肯定或不完整
    204——請求收到,但返回信息爲空
    205——服務器完成了請求,用戶代理必須復位當前已經瀏覽過的文件
    206——服務器已經完成了部分用戶的GET請求
 
  3**(重定向類):爲了完成指定的動做,必須接受進一步處理
    300——請求的資源可在多處獲得
    301——本網頁被永久性轉移到另外一個URL
    302——請求的網頁被轉移到一個新的地址,但客戶訪問仍繼續經過原始URL地址,重定向,新的URL會在response中的Location中返回,瀏覽器將會使用新的URL發出新的Request。
    303——建議客戶訪問其餘URL或訪問方式
    304——自從上次請求後,請求的網頁未修改過,服務器返回此響應時,不會返回網頁內容,表明上次的文檔已經被緩存了,還能夠繼續使用
    305——請求的資源必須從服務器指定的地址獲得
    306——前一版本HTTP中使用的代碼,現行版本中再也不使用
    307——申明請求的資源臨時性刪除
 
  4**(客戶端錯誤類):請求包含錯誤語法或不能正確執行
       400——客戶端請求有語法錯誤,不能被服務器所理解
       401——請求未經受權,這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
         HTTP 401.2 - 未受權:服務器配置問題致使登陸失敗
      HTTP 401.3 - ACL 禁止訪問資源
      HTTP 401.4 - 未受權:受權被篩選器拒絕
        HTTP 401.5 - 未受權:ISAPI 或 CGI 受權失敗
        402——保留有效ChargeTo頭響應
        403——禁止訪問,服務器收到請求,可是拒絕提供服務
        HTTP 403.1 禁止訪問:禁止可執行訪問
      HTTP 403.2 - 禁止訪問:禁止讀訪問
      HTTP 403.3 - 禁止訪問:禁止寫訪問
      HTTP 403.4 - 禁止訪問:要求 SSL
      HTTP 403.5 - 禁止訪問:要求 SSL 128
      HTTP 403.6 - 禁止訪問:IP 地址被拒絕
      HTTP 403.7 - 禁止訪問:要求客戶證書
      HTTP 403.8 - 禁止訪問:禁止站點訪問
      HTTP 403.9 - 禁止訪問:鏈接的用戶過多
      HTTP 403.10 - 禁止訪問:配置無效
      HTTP 403.11 - 禁止訪問:密碼更改
      HTTP 403.12 - 禁止訪問:映射器拒絕訪問
      HTTP 403.13 - 禁止訪問:客戶證書已被吊銷
      HTTP 403.15 - 禁止訪問:客戶訪問許可過多
      HTTP 403.16 - 禁止訪問:客戶證書不可信或者無效
        HTTP 403.17 - 禁止訪問:客戶證書已經到期或者還沒有生效
    404——一個404錯誤代表可鏈接服務器,但服務器沒法取得所請求的網頁,請求資源不存在。eg:輸入了錯誤的URL
    405——用戶在Request-Line字段定義的方法不容許
    406——根據用戶發送的Accept拖,請求資源不可訪問
    407——相似401,用戶必須首先在代理服務器上獲得受權
    408——客戶端沒有在用戶指定的餓時間內完成請求
    409——對當前資源狀態,請求不能完成
    410——服務器上再也不有此資源且無進一步的參考地址
    411——服務器拒絕用戶定義的Content-Length屬性請求
    412——一個或多個請求頭字段在當前請求中錯誤
    413——請求的資源大於服務器容許的大小
    414——請求的資源URL長於服務器容許的長度
    415——請求資源不支持請求項目格式
    416——請求中包含Range請求頭字段,在當前請求資源範圍內沒有range指示值,請求也不包含If-Range請求頭字段
    417——服務器不知足請求Expect頭字段指定的指望值,若是是代理服務器,多是下一級服務器不能知足請求長。
 
  5**(服務端錯誤類):服務器不能正確執行一個正確的請求
        HTTP 500 - 服務器遇到錯誤,沒法完成請求
      HTTP 500.100 - 內部服務器錯誤 - ASP 錯誤
      HTTP 500-11 服務器關閉
      HTTP 500-12 應用程序從新啓動
      HTTP 500-13 - 服務器太忙
      HTTP 500-14 - 應用程序無效
      HTTP 500-15 - 不容許請求 global.asa
      Error 501 - 未實現
       HTTP 502 - 網關錯誤
HTTP 503:因爲超載或停機維護,服務器目前沒法使用,一段時間後可能恢復正常
 
常見的:
響應頭部
與請求頭部相似,爲響應報文添加了一些附加信息
常見響應頭部以下:
例子:
三,IO模型                                       
 
web頁面,由多個資源組成
打開任何一個網站,都是先主頁面,有多是html,php,jsp,裏面有各個資源,爲了可以快速的訪問站內站外,引用了緩存是瀏覽器私有緩存,
event支持時間驅動因此這裏有IO模型
IO模型
一方提供服務,一方須要調用別人的服務,調用向被調用方請求一個運行一個庫調用或者系統調用,被調用方在本地在處理結束後返回,怎麼知道何時處理完
同步和異步:synchronous,asyncronous
同步:調用發出後不會當即返回,但一旦返回,則返回便是最終結果:
異步:調用發出後,被調用方當即返回消息,但返回的並不是最終結果,被調用者經過狀態、通知機制等來通知調用者,或經過回調函數來處理結果
         
 
阻塞和非阻塞
 

 

 

1,阻塞

 
 
read爲例:
  (1)進程發起read,進行recvfrom系統調用;
  (2)內核開始第一階段,準備數據(從磁盤拷貝到緩衝區),進程請求的數據並非一下就能準備好;準備數據是要消耗時間的;
  (3)與此同時,進程阻塞(進程是本身選擇阻塞與否),等待數據ing;
  (4)直到數據從內核拷貝到了用戶空間,內核返回結果,進程解除阻塞。
  也就是說,內核準備數據和數據從內核拷貝到進程內存地址這兩個過程都是阻塞的。
例如:
阻塞I/O, 一天早上你大老早去找報攤老伯買當天報紙,結果告訴你,你來得太早了想要的報紙尚未(也就是進程想要讀取的數據被其餘佔用了,不能立刻獲得想要的數據),這個時候你就乾脆等着,等老闆何時拿到報紙再給你,老闆給你一張小板凳,你什麼事情都不作,坐等拿到報紙後就撤退!這裏的阻塞分了兩部分,一個是你等老闆(IO的請求),另外一個是老闆也在等送報人按照訂購清單派發後清點種類和數量(IO操做,內核從磁盤提取數據),大家兩我的都在等,因此兩個階段都是阻塞的。
 
 
2,非阻塞

 

  (1)當用戶進程發出read操做時,若是kernel中的數據尚未準備好;
  (2)那麼它並不會阻塞用戶進程,而是馬上返回一個error,從用戶進程角度講 ,它發起一個read操做後,並不須要等待,而是立刻就獲得了一個結果;
  (3)用戶進程判斷結果是一個error時,它就知道數據尚未準備好,因而它能夠再次發送read操做。一旦kernel中的數據準備好了,而且又再次收到了用戶進程的system call;
  (4)那麼它立刻就將數據拷貝到了用戶內存,而後返回。
  因此,nonblocking IO的特色是用戶進程在內核準備數據的階段須要不斷的主動詢問數據好了沒有。
例子:
非阻塞I/O, 這種狀況是你老闆沒有小板凳,而你也不想一直等着,等着的時間浪費了還不如干點其餘事情。因此你先離開了,而後每隔一段時間就跑回來看看想要的報紙有沒有,這種不是一直等待的就是非阻塞,但是對於老闆來講他也要等着從送報員手中收到報紙,這過程對於老闆也算是阻塞(你最後一次問老闆,老闆告訴你報紙已經有了,就至關於數據已經複製到內核的緩衝區),而老闆雖然告訴你已經有你要報紙,可是老闆最後還須要從一堆報紙中找到給你(這是IO的實際操做了,至關於內核從磁盤讀取數據,讀取完以後再進行的第二個個步驟,從內核複製到進程內存),老闆找的過程你就一直等待,因此雖然是非阻塞,但由於第二個步驟你要等待即爲同步。
 
io 複用
也叫多路複用,事件驅動
#######必須是從非阻塞才能到多路複用
I/O多路複用實際上就是用select, poll, epoll監聽多個io對象,當io對象有變化(有數據)的時候就通知用戶進程。好處就是單個進程能夠處理多個socket。
 

 

  (1)當用戶進程調用了select思萊科特,那麼整個進程會被block;
  (2)而同時,kernel會「監視」全部select負責的socket;
  (3)當任何一個socket中的數據準備好了,select就會返回;
  (4)這個時候用戶進程再調用read操做,將數據從kernel拷貝到用戶進程。
例子:
I/O多路複用, 上面第二種方式能夠發現有很大缺陷了,你須要不斷地去看報紙送到老闆手上了沒有,一來二去的想一想都累,尤爲是當你要的多份報紙要在幾個地方纔能買到(多路複用更適用於多個IO的情景),這樣你就須要每一個地方反覆的去看一遍有沒有到貨,累成狗了吧。這個時候多路複用的功能就是,你找我的來幫你跑,這我的會定時地將每一個報亭的報紙是否有庫存記錄下來,你要作的事情只須要老老實實待在你和中介的見面點喝茶(阻塞,進程受阻於select調用),一旦發現中介跑回來的就向他詢問,當某次得知全部報亭都已經到貨,你就能夠走一圈買到全部報紙。
 
異步io
 

 

  (1)用戶進程發起read操做以後,馬上就能夠開始去作其它的事。
  (2)而另外一方面,從kernel的角度,當它受到一個asynchronous read以後,首先它會馬上返回,因此不會對用戶進程產生任何block。
  (3)而後,kernel會等待數據準備完成,而後將數據拷貝到用戶內存,當這一切都完成以後,kernel會給用戶進程發送一個signal,告訴它read操做完成了。
相關文章
相關標籤/搜索