NGINX 基礎入門篇 一

1、nginx的優點：

1.發展趨勢：
2016年：
2019年：
2.nginx的logo：
3.nginx的簡介：Nginx (engine x) 是一個高性能的HTTP(解決C10k的問題)和反向代理服務器，也是一個IMAP/POP3/SMTP服務器。
4.nginx的web優點：
（1）IO多路複用：
①：理論方法
第一個種方法：最傳統的多進程併發模型 (每進來一個新的I/O流會分配一個新的進程管理。)
第二種方法：I/O多路複用 (單個線程，經過記錄跟蹤每一個I/O流(sock)的狀態，來同時管理多個I/O流 。)發明它的緣由，是儘可能多的提升服務器的吞吐能力。在同一個線程裏面， 經過撥開關的方式，來同時傳輸多個I/O流
②：技術類型：
select：select是第一個實現 (1983 左右在BSD裏面實現的)。
select 被實現之後，很快就暴露出了不少問題。
• select 會修改傳入的參數數組，這個對於一個須要調用不少次的函數，是很是不友好的。
• select 若是任何一個sock(I/O stream)出現了數據，select 僅僅會返回，可是並不會告訴你是那個sock上有數
據，因而你只能本身一個一個的找，10幾個sock可能還好，要是幾萬的sock每次都找一遍...
• select 只能監視1024個連接。
• select 不是線程安全的，若是你把一個sock加入到select, 而後忽然另一個線程發現，這個sock不用，要收
回，這個select 不支持的，若是你喪心病狂的居然關掉這個sock, select的標準行爲是不可預測的

• poll：
  因而14年之後(1997年）一幫人又實現了poll, poll 修復了select的不少問題，好比
  • poll 去掉了1024個連接的限制，因而要多少連接呢， 主人你開心就好。
  • poll 從設計上來講，再也不修改傳入數組，不過這個要看你的平臺了，因此行走江湖，仍是當心爲 妙。
  其實拖14年那麼久也不是效率問題， 而是那個時代的硬件實在太弱，一臺服務器處理1千多個連接簡直就是神
  同樣的存在了，select很長段時間已經知足需求。
  可是poll仍然不是線程安全的， 這就意味着，無論服務器有多強悍，你也只能在一個線程裏面處理一組I/O流。
  你固然能夠那多進程來配合了，不過而後你就有了多進程的各類問題。
  epoll：
  因而5年之後, 在2002, 大神 Davide Libenzi 實現了epoll.
  epoll 能夠說是I/O 多路複用最新的一個實現，epoll 修復了poll 和select絕大部分問題, 好比：
  • epoll 如今是線程安全的。
  • epoll 如今不只告訴你sock組裏面數據，還會告訴你具體哪一個sock有數據，你不用本身去找了。
  特色：異步，非阻塞
  （2） 時分多路複用 :CPU時鐘/中斷設計
  (3)* ADSL

---

2、HTTP詳解：

1.HTTP：HTTP--Hyper Text Transfer Protocol，超文本傳輸協議，是一種創建在TCP上的無狀態鏈接，整個基本的工做流程是客戶端發送一個HTTP請求，說明客戶端想要訪問的資源和請求的動做，服務端收到請求以後，服務端開始處理請求，並根據請求作出相應的動做訪問服務器資源，最後經過發送HTTP響應把結果返回給客戶端。其中一個請求的開始到一個響應的結束稱爲事務，當一個事物結束後還會在服務端添加一條日誌條目。
2.URL：
①：簡介：統一資源標識符(Uniform Resource Identifier,或URI) : HTTP 請求的內容通稱爲"資源"。」資源「這一律念很是寬泛，它能夠是你可以想到的格式。每一個資源都由一個 (URI) 來進行標識。URL即統一資源定位符，它是 URI 的一種。一份文檔，一張圖片，或全部其餘。URI包含URL,URN
②：URL 用於定位 ：全稱叫作:統一資源定位符(URL,英語Uniform Resource Locator的縮寫)也被稱爲網頁地址
③：URN：

3.三者關係圖：
經過下面的例子（源自 Wikipedia），咱們能夠很好地理解URN 和 URL之間的區別。若是是一我的，咱們會想到他的姓名和住址。

URL相似於住址，它告訴你一種尋找目標的方式（在這個例子中，是經過街道地址找到一我的）。要知道，上述定義同時也是一個URI。

相對地，咱們能夠把一我的的名字看做是URN；所以能夠用URN來惟一標識一個實體。因爲可能存在同名（姓氏也相同）的狀況，因此更準確地說，人名這個例子並非十分恰當。更爲恰當的是書籍的ISBN碼和產品在系統內的序列號，儘管沒有告訴你用什麼方式或者到什麼地方去找到目標，可是你有足夠的信息來檢索到它。

關於URL：

URL是URI的一種，不只標識了Web 資源，還指定了操做或者獲取方式，同時指出了主要訪問機制和網絡位置。
關於URN：

URN是URI的一種，用特定命名空間的名字標識資源。使用URN能夠在不知道其網絡位置及訪問方式的狀況下討論資源。
如今，若是到Web上去看一下，你會找出不少例子，這比其餘東西更容易讓人困惑。我只展現一個例子，很是簡單清楚地告訴你在互聯網中URI 、URL和URN之間的不一樣。
咱們一塊兒來看下面這個虛構的例子。
這是一個URI：「http://bitpoetry.io/posts/hello.html#intro」
「http://」是定義如何訪問資源的方式。
「bitpoetry.io/posts/hello.html」是資源存放的位置。
「#intro」是資源。
URL是URI的一個子集，告訴咱們訪問網絡位置的方式。在咱們的例子中，URL應該以下所示：
「http://bitpoetry.io/posts/hello.html」
URN是URI的子集，包括名字（給定的命名空間內），可是不包括訪問方式，以下所示：
「bitpoetry.io/posts/hello.html#intro」
就是這樣。如今你應該可以辨別出URL和URN之間的不一樣。

若是你忘記了這篇文章的內容，至少要記住一件事：URI能夠被分爲URL、URN或二者的組合。若是你一直使用URI這個術語，就不會有錯。

4.統一資源標識符的語法 (URL)
（1）協議：
①：tp://" 告訴瀏覽器使用何種協議。對於大部分 Web 資源，一般使用 HTTP 協議或其安全版本，HTTPS 協議。
另外，瀏覽器也知道如何處理其餘協議。例如， 「mailto:」 協議指示瀏覽器打開郵件客戶端；「ftp:」協議指示瀏覽
器處理文本傳輸。
②：常見的方案有：
（2）:主機：
①：www.example.com 既是一個域名，也表明管理該域名的機構。它指示了須要向網絡上的哪一臺主機發起請
求。固然，也能夠直接向主機的 IP address 地址發起請求。但直接使用 IP 地址的場景並不常見。
（3）：端口：
:80 是端口。它表示用於訪問 Web 服務器上資源的技術「門」。若是訪問的該 Web 服務器使用HTTP協議的標準
端口（HTTP爲80，HTTPS爲443）授予對其資源的訪問權限，則一般省略此部分。不然端口就是 URI 必須的部分。
（4）：路徑：
/path/to/myfile.html 是 Web 服務器上資源的路徑。在 Web 的早期，相似這樣的路徑表示 Web 服務器上的物理文件位置。如今，它主要是由沒有任何物理實體的 Web 服務器抽象處理而成的。
(5):查詢：
?key1=value1&key2=value2 是提供給 Web 服務器的額外參數。這些參數是用 & 符號分隔的鍵/值對列表。Web 服務器能夠在將資源返回給用戶以前使用這些參數來執行額外的操做。每一個 Web 服務器都有本身的參數規則，想知道特定 Web 服務器如何處理參數的惟一可靠方法是詢問該 Web 服務器全部者。
（6）：片斷：
#SomewhereInTheDocument 是資源自己的某一部分的一個錨點。錨點表明資源內的一種「書籤」，它給予瀏覽器顯示位於該「加書籤」點的內容的指示。 例如，在HTML文檔上，瀏覽器將滾動到定義錨點的那個點上；在視頻或音頻文檔上，瀏覽器將轉到錨點表明的那個時間。值得注意的是 # 號後面的部分，也稱爲片斷標識符，永遠不會與請求一塊兒發送到服務器。

5.HTTP protocol 概述：
①：
咱們得到的圖像，影音，廣告都是由web服務器 get而來。
②：概覽：HTTP是一種可以獲取如 HTML 這樣的網絡資源的通信協議。它是 Web 上數據交換的基礎，是一種
client-server 協議，也就是說請求一般是由像瀏覽器這樣的接受方發起的。一個完整的web文檔是由不一樣的子文檔從新組建而成的，像是文本、佈局描述、圖片、視頻、腳本等等。
HTTP被設計於上20世紀90年代初期，是一種可擴展性的協議。它是應用層的協議，雖然理論上它
能夠經過任何可靠的傳輸協議來發送，可是它仍是經過TCP，或者是TLS－加密的TCP鏈接來發送。由於
它很好的擴展性，時至今日它不只被用來傳輸超文本文檔，還用來傳輸圖片、視頻或者向服務器發送如
HTML表單這樣的信息。HTTP還能夠根據網頁需求，來獲取部分web文檔的內容來更新網頁。
③：requests： 客戶端和服務端經過交換各自的消息來進行交互。一般由像瀏覽器這樣的客戶端發出的消息叫作
requests，那麼被服務端迴應的消息就叫作 responses。

組件系統：
（1）：HTTP是一個client-server協議：請求經過一個實體被髮出，實體也就是用戶代理。大多數狀況下，這
個用戶代理都是指瀏覽器，固然它也多是任何東西，好比一個爬取網頁來生成和維護搜索引擎索引的機器。
每個發送到服務器的請求，都會被服務器處理而且返回一個消息，也就是response。在client與server之
間，還有許許多多的被稱爲proxies的實體，他們的做用與表現各不相同，好比有些是網關，還有些是caches等。
（2）:
(3):客戶端：user-agent
嚴格意義來講，user-agent就是任何可以爲用戶發起行爲的工具。但實際上，這個角色一般都是由瀏覽器
來扮演。對於發起請求來講，瀏覽器老是做爲發起一個請求的實體。
要渲染出一個網頁，瀏覽器首先要發送第一個請求來獲取這個頁面的HTML文檔，再解析它並根據文檔中的
資源信息發送其餘的請求來獲取腳本信息，或者CSS來進行頁面佈局渲染，還有一些其它的頁面資源（如圖片
和視頻等）。而後，它把這些資源結合到一塊兒，展示出來一個完整的文檔，也就是網頁。打開一個網頁後，瀏
覽器還能夠根據腳本內容來獲取更多的資源來更新網頁。
一個網頁就是一個超文本文檔，也就是說有一部分顯示的文本多是連接，啓動它（一般是鼠標的點擊）就
能夠獲取一個新的網頁。網頁使得用戶能夠控制它的user-agent來導航Web。瀏覽器來負責翻譯HTTP請求的命
令，並翻譯HTTP的返回消息讓用戶能明白返回消息的內容。
(4):Web服務端
在上述通訊過程的另外一端，就是一個Web Server來服務並提供客戶端請求的文檔。Server只是虛擬意義上：
它能夠是許多共同分擔負載（負載平衡）的一組服務器組成的計算機羣，也能夠是一種複雜的軟件，經過向其餘
計算機發起請求來獲取部分或所有資源的軟件。
(5): 在瀏覽器和服務器之間，有許多計算機和其餘設備轉發了HTTP的消息。由於Web棧層次結構的緣由，它們大多數都出如今傳輸層、網絡層和物理層上，對於HTTP的應用層來講就是透明的（雖然它們可能會對應用層的性能有重要影響）。而還有一部分表如今應用層上的，就叫作proxies了。Proxies既能夠表現得透明，又能夠不透明（看請求是否經過它們），主要表如今這幾個功能上：
報文：
（1）：請求：
①例子to.com/images/blog/202009/22/3cd5f12c1edbc410105f04da3b4e8421.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)
②：元素：一個HTTP的method，常常是由一個動詞像GET, POST 或者一個名詞像OPTIONS，HEAD來定義客戶端的動
做行爲的。一般客戶端的操做都是獲取資源（用GET方法）或者發送一個HTML form表單的值（用POST方法），
雖然在一些狀況下也會有其餘的操做。
• 要獲取的資源的路徑，一般是上下文中就很明顯的元素資源的URL，它沒有protocol （http://），domain（developer.mozilla.org），或是TCP的port（HTTP是80端口）。
• HTTP協議的版本號。
• 爲服務端表達其餘信息的可選擇性的headers。
（2）：迴應
①：例子：
②：元素：
• HTTP的版本號。
• 一個狀態碼（status code），來告知對應的請求發送成功或失敗，以及失敗的緣由。
• 一個狀態信息，這個信息是非權威的狀態碼描述信息，也就是說能夠由服務端自行設定的。
• HTTP headers，與請求的很像。
• 可選的，可是比在請求報文中更加常見地包含獲取資源的body。

6.HTTP headers:實驗分析http報頭信息
(1):目的:wget下載一個源碼包,分析HTTP頭部的信息
(2):執行下載:wget -d http://nginx.org/download/nginx-1.12.1.tar.gz
(3):分析Debug信息:

(4):相關資料：