Node.js隨手筆記（二）：基本模塊HTTP

前言

要理解Web服務器程序的工做原理，首先，咱們要對HTTP協議有基本的瞭解。
HTTP（Hypertext Transfer Protocol, 超文本傳輸協議）是在網絡上進行通訊時所使用的協議方案，瀏覽器、服務器和相關的web應用程序都是經過HTTP相互通訊的。HTTP就是現代全球網路中使用的公共語言。

HTTP概述

天天，都有數以億萬計的圖片、html、文本文件、電影、音頻、小程序和其餘資源在網絡上傳輸着。HTTP能夠從遍及全球的服務器上把這些信息迅速、便捷的搬移到你面前的瀏覽器上。

HTTP使用的是可靠的數據傳輸協議，即便數據來自地球的另外一端，它也可以確保數據在傳輸的過程當中不會被損壞或者產生混亂。

聯想到咱們平常上網衝浪的需求，可知HTTP在其中扮演着舉足輕重的角色。

那這時候我就很好奇了，客戶端和服務器，或者web應用程序之間是如何利用HTTP進行通訊的，HTTP又是如何完成其傳輸的工做。

客戶端與服務器是如何通訊的

服務器所使用的是HTTP協議，所以也常常被稱爲HTTP服務器。客戶端向服務器發送HTTP請求，服務器會在HTTP響應中回送所請求的數據。如此，HTTP客戶端和HTTP服務器共同構成了網絡的基本組件。

咱們天天都在使用HTTP客戶端。最多見的客戶端就是瀏覽器，向服務器請求HTTP對象，並將這些對象顯示在屏幕上。好比瀏覽一個網頁（www.91wutong.com），瀏覽器會向服務器www.91wutong.com發送一條HTTP請求。服務器會去尋找所指望的對象，若是成功，就將對象、對象類型、對象長度以及其餘一些信息放在HTTP響應中發送給客戶端。

Web內容資源來自何方

咱們平常請求的內容都是存儲在服務器上的，服務器就是請求資源的宿主。最簡單的web資源就是服務器文件系統中的靜態文件。好比福星有一臺static7.com的服務器，我每次把我要使用的圖片發給他，讓他放進服務器，只要他的服務器還在維護，這樣我就能夠在地球任意角落經過url訪問獲得。還有一些資源是根據須要生成內容的軟件程序，好比股票交易，關鍵字搜索數據，或者在線購買商品。全部可以提供內容的東西都是web資源。

web事務是怎樣工做的

一條HTTP事務由一條請求命令（從客戶端發往服務器的）和一個響應結果（從服務器發回客戶端的）組成。這種通訊是經過名爲HTTP報文的格式化數據塊進行的。

方法

HTTP支持多種不一樣的請求命令，這些命令被稱爲HTTP方法。每條HTTP的請求報文都包含一個方法。

• GET 從服務器向客戶端發送命名資源
• PUT 未來自客戶端的數據存儲到一個命名的服務器資源中去
• DELETE 從服務器中刪除命名資源
• POST 將客戶端數據發送到一個服務器網關應用程序
• HEAD 僅發送命名資源響應中的HTTP首部

狀態碼

每條HTTP響應報文返回時都會攜帶一個狀態碼。狀態碼是一個三位數字的代碼，告知客戶端請求是否成功，或者是否須要採起其餘動做。

一些常見的HTTP狀態碼：

• 200 ok
• 302 Redirect 重定向 到其餘地方去獲取資源
• 404 Not Found 沒找到 沒法找到這個資源
• ...

狀態碼	範圍	描述
2xx	200 - 206	success
3xx	300 - 305	redirect
4xx	400 - 415	客戶端error
5xx	500 - 505	服務器error

HTTP通訊所使用的報文格式

至此，咱們已經瞭解到了HTTP通訊須要客戶端發送HTTP請求，服務器收到請求後，尋找期待的資源，返回響應對象。其中一來一回的請求與響應組成了一條http事務，這個通訊過程是由名爲HTTP報文的格式化數據塊進行的。一個完整的HTTP報文包括：起始行，首部字段，主體。起始行說明了請求報文要作些什麼，響應報文中出現了什麼狀況；首部字段都包含一個名字一個值，以冒號分隔，說明了請求或響應對象的類型數據量等信息；主體部分，請求主體中包含了要發送給服務器的數據，響應主體中裝載了要返回給客戶端的數據。

那通訊過程大概是這樣，但是我又在想了，客戶端是怎樣創建的這條通訊呢，怎麼就連通了能夠互相來電呢？就像找對象同樣，天天看着旁邊的人和對象你儂我儂的，他們當初是怎麼好上的呢。想要了解這一點，就要了解一下互聯網協議。

互聯網協議

在客戶端向服務端發送報文以前，首先像平常打電話撥通對方的號碼同樣，創建客戶端與服務器之間的TCP（傳輸控制協議）鏈接。從一個地方傳送數據到另一個地方，中間互相不知道彼此的物理位置，你不以爲這是很神奇的事情嗎？是怎麼作到的呢？這就是互聯網協議能夠作到的事情。

互聯網的核心是一系列協議，總稱爲「互聯網協議」。它們對電腦如何鏈接和組網，作出了詳盡的規定。

層模型

互聯網就像生活中的建築物同樣，是一個多層模型，一層依賴一層，每一層都依靠着下一層的支持，每一層又有着本身的功能。

關於互聯網分層的說法不少，七層模型、五層模型，名字也不盡相同。可是從功能來講，名字叫什麼無所謂，只要知道互聯網是分紅若干層次的就能夠了。咱們以五層來分析看：

• 應用層
• 傳輸層
• 網絡層
• 數據鏈路層
• 物理層（實體層）

最頂上的是用戶接觸到的應用層，最底層是實體層。中間三層自下而上是連接層、網絡層、傳輸層。越往下面的層，越靠近硬件；越往上面的層越靠近用戶。

每一層都是爲了完成特定的功能，爲了實現功能，就須要你們都遵循共同的規則，約定好協議。每一層裏都定義了不少協議，這些協議統稱爲互聯網協議，是互聯網的核心。

咱們平常接觸到最多的是應用層，根本感受不到下面的樓層。要想理解互聯網，必須自下而上地理解每一層的功能。

物理層（實體層）

電腦要組網，第一件事要幹什麼？固然是把電腦連起來，能夠用光纜、電纜、雙絞線、無線電波等方式。實體層的做用就是把電腦鏈接起來的物理手段，做用是負責傳送電信號。你們猜一下這裏傳輸的信號會是什麼東西呢？固然是二進制數據，0和1這樣的電信號。

鏈路層

位於實體層的上方，肯定了0和1的分組方式。解讀0和1，多少個電信號爲一組，每一個信號位是什麼意義。這裏就很像接收電報後的翻譯了，等等等等，多少個爲一組，這一組是什麼意思。

以太網協議

早期的時候，每家公司都有本身的電信號分組方式，後來名爲以太網的協議佔據主導地位，做爲解讀標準。
以太網規定，一組電信號構成一個數據包，叫作「幀」。每一幀分紅兩個部分：head 和 data。

• 標頭head：包含數據包的一些說明項，好比發送者，接收者，以及數據類型；長度固定爲18字節
• 數據data：數據包的具體內容；長度最小爲46字節，最長爲1500字節。

所以整個「幀」最短爲64字節，最長爲1518字節。若是數據很長，就必須分割成多個幀進行發送。

MAC地址

數據我知道，可是標頭的信息怎麼來的呢？
標頭，包括了發送者和接收者的信息，那這兩個是用什麼作標識的呢？以太網規定，連入網絡的全部設備都必須有「網卡」接口。數據包必須從一塊網卡傳送到另一塊網卡。網卡的地址，就是數據包的發送地址和接收地址，這就叫作MAC地址。每塊網卡出廠的時候都有一個全世界惟一的MAC地址，長度爲48個二進制位，一般以12個十六進制位表示。

廣播的發送方式

一塊網卡怎麼會知道另外一塊網卡的MAC地址？（ARP協議）若是知道了這個地址，怎樣才能把數據包準確送到接收方？
以太網採用了一種很「原始」的方式，它不是把數據點對點傳過去，而是向本網絡內全部計算機發送，讓每臺計算機本身拿數據包的標頭信息去判斷是不是接收方。這種方式就叫作「廣播」。

有了數據包的定義、網卡的MAC地址、廣播的發送方式、「連接層」就能夠在多臺計算機之間傳送數據了。
可是全部的電腦人手一「包」去廣播找對應的機器，效率低並且侷限於發送者所在的子網絡內。若是全部的機器都在一個子網絡裏，每一個機器都會收到全部的數據包而後去比對MAC地址，這簡直是災難。互聯網應該是由無數個子網絡共同組成的一個巨型網絡，這便致使了「網絡層」的誕生。

網絡層

它的做用是引進一套新的地址，使得咱們可以區分不一樣的計算機是否屬於同一個子網絡。這套地址就叫作「網絡地址」，簡稱「網址」。因而，每臺計算機就有了兩個地址，一個網絡地址，一個MAC地址，兩個地址之間沒有相互的聯繫。網址幫助咱們肯定計算機所在的子網絡，MAC地址則將數據包發送到子網絡中的目標網卡。

從邏輯上來看，這兩個地址的處理順序是先網路地址後MAC地址了。

IP協議

規定網絡地址的協議，叫作IP協議。被它定義的地址稱爲IP地址。網絡上的每一臺電腦，都會被分配到一個IP地址，這個地址分紅兩個部分，前一部分表明網絡，後一部分表明主機。處於經過一子網絡的電腦，它們IP地址的網絡部分一定是相同的。

可是如今有個問題，但從IP地址上來看，咱們沒法判斷網絡部分。以192.168.20.8爲例，他的網絡部分，究竟是前24位，仍是前16位，這是看不出來的。那麼怎麼樣才能從IP地址上判斷兩臺機器是否在一個網路內呢？這還要用到另一個參數「子網掩碼」。

所謂「子網掩碼」，就是表示子網絡特徵的一個參數。它在形式上等同於IP地址，也是一個32位的二進制數字，它的網絡部分所有爲1，主機部分所有爲0。好比192.168.20.8，已知子網掩碼爲11111111.11111111.11111111.00000000寫成十進制就是255.255.255.0。

知道了「子網掩碼」，咱們就能判斷任意兩個IP地址是否處在同一個子網絡內。方法是將兩個IP地址與子網掩碼分別進行AND運算。（兩個數位都爲1，運算結果爲1，不然爲0），而後比較結果是否相同，若是是的話，就代表它們在同一個子網絡中，不然就不是。

IP協議的做用主要有兩個，一個是爲每一臺計算機分配IP地址，另外一個是肯定哪些地址在同一個子網絡。

IP數據包

根據IP協議發送的數據，就叫作IP數據包，其中一定是要包括IP地址信息的。前面說過以太網數據包只包含MAC地址，並無IP地址的欄位，這時候IP信息是怎麼添加進數據包的呢？

咱們能夠把IP數據包直接放進以太網數據包的"數據"部分，所以徹底不用修改以太網的規格。這就是互聯網分層結構的好處：上層的變更徹底不涉及下層的結構。

ARP協議

IP數據包放在以太網數據包裏發送，因此咱們必須知道兩個地址，一個是對方的MAC地址，另外一個是對方的IP地址。一般狀況下，對方的IP地址是已知的（後文會解釋），可是咱們不知道它的MAC地址。

因此，咱們須要一種機制，可以從IP地址獲得MAC地址。

這裏又能夠分紅兩種狀況。第一種狀況，若是兩臺主機不在同一個子網絡，那麼事實上沒有辦法獲得對方的MAC地址，只能把數據包傳送到兩個子網絡鏈接處的"網關"（gateway），讓網關去處理。

第二種狀況，若是兩臺主機在同一個子網絡，那麼咱們能夠用ARP協議，獲得對方的MAC地址。ARP協議也是發出一個數據包（包含在以太網數據包中），其中包含它所要查詢主機的IP地址，在對方的MAC地址這一欄，填的是FF:FF:FF:FF:FF:FF，表示這是一個"廣播"地址。它所在子網絡的每一臺主機，都會收到這個數據包，從中取出IP地址，與自身的IP地址進行比較。若是二者相同，都作出回覆，向對方報告本身的MAC地址，不然就丟棄這個包。

總之，有了ARP協議以後，咱們就能夠獲得同一個子網絡內的主機MAC地址，能夠把數據包發送到任意一臺主機之上了。

傳輸層

有了MAC地址和IP地址，咱們已經能夠在互聯網上任意兩臺主機上創建通訊。

接下來的問題是，同一臺主機上有許多程序都須要用到網絡，好比，你一邊瀏覽網頁，一邊與朋友在線聊天。當一個數據包從互聯網上發來的時候，你怎麼知道，它是表示網頁的內容，仍是表示在線聊天的內容？

"傳輸層"的功能，就是創建"端口到端口"的通訊。相比之下，"網絡層"的功能是創建"主機到主機"的通訊。只要肯定主機和端口，咱們就能實現程序之間的交流。

UDP協議

如今，咱們必須在數據包中加入端口信息，放在IP數據包之中，而前面說過，IP數據包又是放在以太網數據包之中的，因此整個以太網數據包如今變成了下面這樣：

這就是UDP協議。簡單易實現，可是可靠性較差，一旦數據包發出，沒法知道對方是否收到。爲了解決這個問題，提升網絡可靠性，TCP協議就誕生了。

TCP協議

TCP協議很是複雜，但能夠近似認爲，它就是有確認機制的UDP協議，可以確保數據不會遺失，每發出一個數據包都要求確認。若是有一個數據包遺失，就收不到確認，發出方就知道有必要重發這個數據包了。

只要創建了 TCP 鏈接，客戶端和服務器之間的報文交換就不會丟失、不會被破壞，也不會在接收時出現錯序了。

應用層

應用程序收到"傳輸層"的數據，接下來就要進行解讀。因爲互聯網是開放架構，數據來源五花八門，必須事先規定好格式，不然根本沒法解讀。

"應用層"的做用，就是規定應用程序的數據格式。

舉例來講，TCP協議能夠爲各類各樣的程序傳遞數據，好比Email、WWW、FTP等等。那麼，必須有不一樣協議規定電子郵件、網頁、FTP數據的格式，這些應用程序協議就構成了"應用層"。

這是最高的一層，直接面對用戶。它的數據就放在TCP數據包的"數據"部分。所以，如今的以太網的數據包就變成下面這樣。

一個實例：訪問網頁

node基本模塊HTTP