天天看點

nginx基礎(1)

目錄

  • 一、概念
    • 基礎概念
    • 響應碼
    • 請求和響應封包的格式
    • http無連接配接

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

張賀,多年網際網路行業工作經驗,擔任過網絡工程師、系統內建工程師、LINUX系統運維工程師

個人網站:www.zhanghehe.cn

筆者微信:zhanghe15069028807,現居濟南曆下區

OSI七層參考模型與TCP協定棧的差別 :OSI的七層參考模型隻是參考模型,隻是紙上談兵罷了,而TCP/IP是以OSI七層模式為基礎演化而來的實際使用的模型,是實戰派。OSI七層參考模式的上三層是資源子網,而下四層為通信子網。

主機與主機之間的通信:在linux的核心當中,下四層的通信功能都是在核心當中實作,主機與主機之間的通信依靠核心與核心就可以完成,也就是直接在核心空間就可以完成,根本用不上使用者空間的參與,事實上,的确有此種程式,這是一種結構。

還有另一種結構,把應用程式建立在使用者空間,使用者空間的程式想要完成通信的話就必須依靠核心空間當中通信子網,也就是說使用者空間的程式想要完成通信的話就必須依靠核心的通信子網。

套接字:套接字是為了實作程序與程序之意的通信的一種機制,主要目的在于允許同一主機或者不同主機的不同程序之意進行通信。套接字其實有兩種類型。一般來講,一在個主機上,一個完整套接字由特定的IP+特定的端口組成,想要實作這種套接字需要核心當中的tcp/ip協定棧參與封裝封包,這隻是一般來講,而事實上,套接字是分為兩種類型的,第一種就是IP+端口的方式,這種類型的套接字主要是為了完成主機之間的通信,IP用來辨別不同的主機,而端口用來辨別不同的服務。此外還有一種套接字,這種套接字叫做unix sock,它存在的目的是為了完成同一個主機上程序之間的通信,比如說可以把一個程式的輸出定向到一個檔案當中,然後下一個程式去這個檔案當中取出資料,這其實是通過檔案系統實作的,而檔案系統又是核心實作的,這種基于檔案系統或者檔案的套接字就被稱為unix sock.

raw套接字:不基于tcp也不基于udp而是應用程式自行控制維護封包的傳輸,這種奇怪的應用程式是存在的,其實這就意味着有的應用程式可以繞過傳輸層,但是無論如此也繞不過網絡層。 這樣的話套接字就有了三種。

主機與主機之間傳輸檔案的簡略過程:這個檔案被使用者空間送入核心空間後,首先是由網絡層進行封裝,每一個資料包的總大小大不能超過16位,也就是65535個位元組(B),而這65535個位元組是包含IP首部,而IP的首部最少是20個位元組,最大是60個位元組,是以一個IP資料包除去首部之後要傳輸的資料大小範圍為:65475B-----65515B之間,也就是說一個IP資料包要傳輸的檔案大小範圍在0.65M左右。

這一個資料包到達下一層資料鍊路層的時候還要切片,鍊路層資料的最大傳輸單元是大于等于46位元組小于等于1500個位元組,加上幀頭與幀尾固定的18個位元組,也就是一個資料幀的大小範圍是大于等于64個位元組小于等于1518個位元組,也就是一個資料幀的大小介于0.064KB到1.518KB之間。

等到到達目的主機之後根據辨別标志片偏移合并起來最終送出給使用者空間的應用層。

TCP與UDP:tcp的全稱是transmisson control protocol傳輸控制協定,也稱做是面向連接配接的協定。udp的全稱是user datagram protocol 使用者資料報協定,無連接配接,也稱做是不可靠的連接配接。它們兩個差別就是tcp在建立連接配接時需要首先建立虛連接配接(三四)。

實體層與資料鍊路層實際是由網絡硬體裝置與其對應的驅動程式組成,比如一個網卡加上這個網卡的驅動程式就隻可以實作實體層與鍊路層的功能,而驅動實際上又工作在核心空間當中,由核心直接調用,TCP/IP協定棧也在核心當中 ,是以我們說通信子網(下4層)實際上全部都是核心當中的。

跨主機的通信: 網際網路上絕大多數的跨主機通信都是c/s架構的。所謂的服務端的使用者空間的服務程式在啟動是會向核心注冊申請一個套接字,這種套接字通常是特定的IP+特定端口,當服務程式向核心申請注冊以後,核心就有一個“職責”,核心要時刻等待來通路此套接字的資料,一旦識别資料包通路的是此套接的話,核心就會根據其資訊知道到底是哪個程序注冊了此套接字,進而會把此資料包送出給使用者空間的應用程式。

那麼核心是怎樣識别資料包通路的是哪個程序呢?一個主機上有那多的程序,套接字有那麼多,核心是怎樣辦到的呢?TCP/IP協定棧就位于核心當中,當核心在解封裝的時候就會識别出來,通過網絡層識别通路的主機,通過傳輸層識别通路的是哪個程序。

主動與被動:服務端因為是要提供服務的,相當于醫院當中醫生坐診,要等待使用者通路,不能主動出去拉客,那麼這就是被動,而被動需要一個具體的位址等待客戶的請求,是以伺服器要申請偵聽的套接字都是比較固定的。用戶端則不同,用戶端不需要等待别人通路,是以用戶端也就沒有必要申請一個固定的套接字使用,隻要選擇一個沒有被使用的端口即可。

用戶端的IP加上端口、服務端的IP加上端口,這四種元素就可以辨別一個完整的連接配接,這四種元素隻要變化其一種,就可以辨別一種不同的連接配接。

應用層協定:假設一個ftp的用戶端要與smtp的服務端進行通信可以成功嗎?smtp可以識别ftp的請求嗎?當然是不可以的,這些程式在設計的時候都是遵守一定的規範來設計編寫,能識别的請求是特定的請求,其實也就是說隻能識别按照某一種特定規範編寫的請求,那麼這種規範是什麼?其實這種規範就叫做應用層協定。舉個例子httpd程式是根據http協定設計編寫的,那麼它能識别的用戶端的請求也隻能是根據http協定開發出的用戶端請求,如果一個ftp的用戶端去通路httpd程序的話,httpd是不會識别的,因為httpd服務隻能根據根據http協定開發的程式發出的請求。

應用層的協定是特定的,而傳輸層的協定是通用的 。核心當中的通信子網隻是負責傳輸的,就像通用的軟體,各種應用都可以進行調用,因為它隻負責通信,是以它不管上層的應用是否能夠識别資訊,能夠識别請求資訊取決應用層協定。

nginx基礎(1)

何為http? hypertest transport protocol超文本傳輸協定。那麼什麼樣的文本就是超文本呢?遵守html格式編寫的語言就是超文本。什麼是html?hypertest mark language超文本标記語言。

URI和URL : URL(uniform resource locator)是統一資源定位符,而URI(uniform resorce identifier)是統一資源辨別符,URI存在的意就是為了辨別資源的唯一性。URL是URI的子集,因為URL隻是實作了URI規定的一部分功能,一個完整的URL通過是這樣的:

http://www.magedu.com/image/logo.jpg    #完整的URL示例
           

Ø http:// 是方案、我們通過将其了解成為協定,其實就是通過哪個方式擷取資源,通過ftp也可以呀!

Ø www是主機而不是域名

Ø magedu.com這是是域名

Ø /image/logo.jpg指的是通路資源的路徑,這是絕對路徑。

用戶端和服務端:http的用戶端叫做browser(浏覽器),服務端就是一個遵守http協定的應用程式。那麼用戶端是怎樣通路服務端的呢?浏覽器它會提供一個位址欄讓使用者輸入URL來擷取資源,常用的http的浏覽器有兩種類型是GUI和CLI。

nginx基礎(1)

html :上面的标記語言是為讓用戶端的浏覽器友善顯示的,具體的效果,比如文本顔色和文本大小的微調需要css的參與才可以,使用html和css開發的網頁都是靜态的網頁。此外還有動态網頁,所謂的動态網頁就是不僅有html和css組成,此外還有程式腳本。網頁程式腳本分為兩種,一種是在用戶端執行,一種是在服務端執行,現在最常見的就是在伺服器執行的腳本,因為如果在用戶端執行腳本的話很不安全。當一個用戶端通路一個提供動态網頁時的伺服器時,伺服器會在本地把腳本執行一下,然後通過html标記以後把結果傳回給用戶端。

前端語言:前端語言就是指開發網頁時編寫腳本的語言,最常用的前端語言有php,asp.net,jsp這是三種最常見的,php用于中小型網站的開發,而大型網站要通過jsp開發,當然隻要是遵守CGI(common geteway interface通用網關接口協定)的語言都可以開發網頁,比如:C,C++,python等其實都可以可以的,比如C也可以開發網頁,而且開發出來的網頁跑的賊快!普通的語言需要解釋器,而C不用解釋器可以直接運作,但是為什麼不用C呢?因為C的主要還是用來開發作業系統的,開發網頁并不是太好用,開發和維護的成本相較于專門開發網頁腳本的PHP要大的多。

值得一提的是:flash動畫與動态網站是沒有一分錢的關系的。

一個網頁檔案可能是有多個對象存在的。還是以上一個html為例子,用戶端通過browser請求此html檔案,當把此檔案請求下來之後,用戶端的浏覽器會發現

nginx基礎(1)

還要加載一個圖檔于是還要再次向伺服器發送請求,把此圖檔再請求下來,總而言之,當我們請求一個網頁時并不是隻請求一次就夠的,圖檔與html是兩個檔案,并不是一個檔案。網頁當中的對象可以是伺服器本地的資源,比如圖檔,而且還可以是别的伺服器或者别的網站的圖檔,隻要用戶端的浏覽器能夠請求到都可以被顯示。明文這一點非常的重要。舉個例子,淘寶網頁上的圖上非常之多,難道這些圖檔都存在放伺服器的本地之下嗎?并不是這樣的,這些圖檔可能分散到多台伺服器,這樣很多使用者進行請求的時候就不會對單台伺服器産生太大的壓力,而谷歌和百度的界面并不是太花,因為要保證使用者的體驗盡可能的快,明白此理論對以後的調優意義重大。

超文本是通過http協定傳輸的文本,http是超文本傳輸協定,并不是超圖檔傳輸協定,那麼網頁當中的圖檔是通過怎樣的方式傳遞到用戶端的呢?當然是通過超連結鍊過去的,那麼這個圖檔是通過什麼協定加載到用戶端的本地的呢?圖檔是二進制編碼格式,而http協定隻能傳輸超文本,總不能把圖檔的二進制當成是文本通過http傳輸給用戶端吧!這樣肯定不行,因為到了用戶端那邊是不能夠還原的,用戶端會看到一堆的亂碼。怎樣辦呢?在解開這個謎團之前我們要先了解了一下http的版本。

http的版本:http于1991研制成功之後發展至今有三個版本。

l 0.9版本,此版本為第一版,僅僅支援html文檔,真心是不能傳輸圖檔。

l 1.0版本,此版本為第二版,不僅支援html文檔,還支援多媒體資料的傳輸,當然,不僅是增加此一項功能,這裡并不多講,http發展到這一個版本就其實就可以傳輸圖檔了。那麼它是怎樣實作的呢?說是http多媒體的實作不得不提的是smtp(簡單的郵件傳輸協定),引協定早先也隻能傳輸檔案,後來為了擴充功能加入了傳輸多媒體的機制:MIME:multpurpose internet mail extension,此中機制通過base64的編碼,實作了将二進制資料編碼當成文本發送,并能夠讓接收方還原回來的格式,而http1.0的版本也借用此機制。在1.0的版本上,還引入了緩存的機制,能夠保持連接配接(keep-alive),使得使用者體驗更加順暢。

l 1.1版本在1.0基礎上再次完善,更精确的緩存控制,更多的請求方法,原生支援持久連接配接。成為至今使用最為廣泛的版本。

事務:用戶端對http服務的一次請求加上http服務的一次響應就可以辨別一個http完整的連接配接,這個過程就是http的事務.

方法:用戶端對http的請求不僅一種,有時我們需要擷取頁面(get),有時我們需要向http送出頁面(put),有的時候僅需要知道有沒有這個封包希望http服務端響應一下就好,不用把頁面的資料傳送回來(head),有時需要送出表單(pust),删除頁面(delete),事實上常用的方法有8種,以上的5種比較常見.

常見的方法

  1. GET:用戶端向伺服器請求擷取資源,需要伺服器回複響應封包。
  2. HEAD:與GET相似,僅要求伺服器端傳回首部資訊即可以,不需要将内容傳回,用于探測
  3. POST:支援HTML表單的送出,比如當使用者注冊的時候,使用者注冊的資訊會通過表單的形式發送到伺服器,由伺服器存儲到某個位置(例如發給處理程式做處理)
  4. PUT:也是送出,post偏向于送出建立,而PUT偏向于送出之後更新。
  5. DELETE:請求删除URL指向的資源
  6. OPTIONS:探測伺服器對某資源所支援的請求方法
  7. TRACE:跟蹤請求要經過的防火牆、代理或網關

200:成功

302:臨時跳轉

301:永久跳轉

403:沒有權限

404:頁面不存在

500:伺服器内部錯誤,通過是程式導緻

502:請求不到後端的資源

503:伺服器不可用

504:請求後端資源

1XX

1XX:1開頭的狀态碼都是資訊性狀态碼,沒什麼具體的含義,也很少見到

2XX

2XX:以2開頭有一個必須要記住200,200代表成功狀态,201代表送出成功

3XX

3XX:重定向狀态碼:

301:moved parmanently永久重定向,在伺服器響應時使用首部”location:URL”指定資源現在所處的位置,比如用戶端把URL指向伺服器上的一軟連結,伺服器給用戶端響應時會在首部告訴用戶端真正的檔案在什麼地方,讓用戶端再去連接配接。

302:found,臨時的重定向,在伺服器響應時使用首部”location:URL”指定資源現在所處的位置,看下來與永久重定向沒有什麼差別?事實上,差別還是很大的,一個永久重定向告訴用戶端真實檔案所在之處後,用戶端就可以直接使用真正的位置,而臨時重定向則不然,用戶端每次通路時也要先通路這個臨時重定向,每一次事務都要要如此,因為它是臨時,保不齊什麼時候又指向别的位置了呢。

總結:永久的重定向可以留給後面的連接配接用,而臨時的連接配接不能留給後面的連接配接使用

304:not modified沒有改變,當使用者使用浏覽器通路一個網站之後,會在本地有一個緩存,等到下次再通路的時候,伺服器端直接響應一個304告訴用戶端網頁沒有改變,這樣的話可以加快使用者的體驗。

4XX

4XX:用戶端的錯誤

403:forbidden請求被伺服器拒絕,可能沒有權限

404:not found 伺服器沒有找到請求的URL

405:不允許使用此方法請求相應的URL

5XX

5XX:伺服器錯誤

500:internal server error 伺服器内部錯誤

502:bad gateway代理伺服器或者網關路由出了問題,也可以從上遊收到了一條不能用的響應。

503:service unavailable伺服器此時無法提供服務,但将來可以使用

請求和響應:整體來講http的封包隻有兩種格式,一是請求,二是響應.無論是請求封包還是響應封包都是有特殊格式的.

請求封包格式:request

<method> <reqest-URL> <version>  #<方法><資源><版本>,因不同的版本特性不同,是以必須注明版本(http)資訊.

<headers>  是用來标記屬性的,每個請求或者響應封包可包含任意個首部;每個首部都有首部名稱,後面跟一個冒号,而後跟上一個可選空格,接着是一個值。

                               這個空白行是必須要有的

<entity-body>             #封包的主體,包含要請求的内容,請求封包的實體有可能為空,請求就應該為空,因為本來就不傳輸什麼。
           

資源可以是本地上的,也可以是别的伺服器或者站點上面的.版本号的格式是http/版本号,如http/1.1

響應封包格式:response

<version><status><reason-phrase>    #<版本><狀态><原因短語>,比如1.1 200 ok

<headers>                 		 #這指的是一個類:首部,其實首部就是指的是名稱+值的格式,可以有多個

                                   #這個空白行是必須要有的

<entity-body>                      #封包的主體,包含要回應的内容,如果是響應是一個檔案的話,那麼這個檔案就包含在entity-body裡面。
           

本小節概括:本小節主要介紹http的無連接配接機制,為什麼要加速?怎樣加速?

http是無連接配接的,何為無連接配接?即完成一次事務就必須斷開,就是收到一個請求然後做出一個回應之後就要斷開,這種機制其實是比較浪費資源的,效率低下,下文有一個例子,請仔細的體會:

當用戶端通路www.baidu.com的時候,除去DNS不談,第一步就是通過URL事務擷取一個網頁(一去一回),這一步僅僅是為獲得網頁的内容而已,僅這一個事務就經曆了三次握手和四次揮手,然後用戶端的浏覽器通過讀取獲得的html檔案得知還要獲得10個圖檔,然後還要經曆10個三次握手和四次揮手才能完整的顯示出百度的頁面.如果淘寶的網頁的話可能有上百個圖檔需要獲得,是以效率非常的低下.

因為無連接配接的http效率非常的低下,是以需要加速,其實加速的目的很簡單,就是為了讓使用者獲得更好的體驗,獲得網頁的速度能夠加快,那麼怎樣才能加速http呢?兩種方法,并行和保持連接配接.

所謂并行,就是用戶端一次發多個請求,而伺服器一次回應多個請求,假如當一個浏覽器讀取html檔案後發現還要獲得10個圖檔,用戶端會在建立三次握手之後 ,一次性發出5個請求,然後伺服器也同時響應這個5個請求,用戶端等到5個圖檔獲得之後再四次揮手,這樣話10張圖檔僅需要兩次三次握手和四次揮手,當然這是建立在所有的圖檔都得在同一個IP下,如果不在同一個IP下,一般來講都會在一個主機上,一般不會有那種10張圖檔分布10台伺服器的情況,如果10張圖檔都分布在10個伺服器上的話并行的機制就無法完成,就隻能一個事務一事物的連接配接,畢竟一次連接配接隻能用于一個IP.必須要提的是并行的機制是發生在獲得首頁面的前提下,任何加速方式都是在獲得主網頁的前提下實作的,而獲得首頁面的過程,用戶端和伺服器必須老老實實的完成一個事務.

所謂保持連接配接就非常好了解了,當獲得主要頁面之後,三次握手獲得一個圖檔之後并不進行四次揮手,而是一直保持着連接配接,來完成下面9張圖檔的傳輸,等到9張圖檔都傳輸完畢之後再進行四次揮手,這種方式的效率是很高的,但并不是完全沒有缺點,假如一個伺服器隻能同時接收5000個連接配接,但是同時進來了10000個請求,那麼5000連接配接就要被拒之門外,而已經連入的5000個請求因為要請求的資源很多,很長時間都不斷開的話,門外的5000個連接配接就沒有機會,我們深入想一想就會知道這種情況并不好,使用者體驗很差,使用者連接配接了幾次發現很驗證連上可能以後都不會這個網站了,上次考試報名的時候就遇到過這種情況 .是以為了保證服務品質和使用者體驗,是以http又有斷開的機制,下面就來講一下http的斷開機制.

斷開機制:保持連接配接,三次握手以後不斷開,完成之後終的斷開,并不是全都是好處,比如說當使用者通路淘寶的時候剛打開網頁卻恰好有事出去了,對于伺服器來并不知道,伺服器仍然以為有人在通路它,一個使用者無所謂,假如是成千上萬台都這樣做呢?有的攻擊方式就是這種原理,是以伺服器有一種機制來防止這種情況的發生,那就是斷開機制。

其實斷開機制是我們買車時候的保險是相似的,一台新車在3年或者10萬公裡内可以保修,那麼這個3年和10萬公裡是什麼意思?是這樣:

Ø 如果3年不到但是已經超過了10萬公裡,對不起,不保修!,因為違反了公裡限制!

Ø 如果3年到了但是沒有超過10萬公裡,對不起,不保修!因為這裡違反了時間限制!

Ø 隻有在3年以内而且沒有跑夠10萬公裡,才可以保修。

斷開的方式:逾時或者限制最大資源數

逾時:工程師規定連接配接到達10秒,就必須重新斷開

限制最大資源數:一旦連結後的請求資源達到100個就必須斷開,一秒到上限就一秒斷開,1分鐘到達上限就一分鐘斷開。

上一篇: if
下一篇: sed指令總結

繼續閱讀