ESP8266入門指南-ESP8266 Web Server

如果從技術角度來看，能夠ping通ESP是一項很大的成就，只是對於大多數人來說，這些結果並不令人興奮，也沒有真正的用處。本篇將介紹Web Server的基礎知識，並教您如何在ESP上託管網頁。

內容目錄

Web Servers

Web Server是儲存和提供文件的Internet連接設備。客戶端可以請求這樣的文件或其他數據，然後服務器將正確的數據/文件發送回客戶端。使用HTTP發出請求。

HTTP

HTTP或超文本傳輸協定是用於與（Web）服務器通信的基於文本的協定。HTTP請求方法有多種，這裏只介紹兩種使用最廣泛的方法：GET和POST。

HTTP GET

GET請求用於從服務器（例如網頁）中檢索數據。它不更改服務器上的任何內容，而只是從服務器獲取數據，而沒有其他作用。在瀏覽器中打開網頁時，它將獲取URL並將其放入HTTP GET請求中。這只是純文本。接著它將使用TCP將請求發送到正確的服務器。服務器讀取請求，檢查URL，並將該URL的正確HTTP回應發送回瀏覽器。

GET請求的剖析

GET請求中最重要的部分是request line和host header。讓我們看一個例子：如果您點擊以下鏈接：https : //www.w3.org/Protocols/rfc2616/rfc2616-sec5.html，您的瀏覽器將發出以下HTTP請求：

GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
DNT: 1
Referer: https://www.google.be/
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8

第一行是request line：它包含request method： GET（在這種情況下為URI或統一資源標識符：/Protocols/rfc2616/rfc2616-sec5.html）和HTTP版本：1.1。第二行是host header，它指定主機（服務器）的域名。還有許多其他標頭，但在使用ESP8266時它們並不重要。大多數服務器將檢查URI是否是其文件系統上的文件，如果是這種情況，會發送該文件作為回應。

在瀏覽器中查看HTTP標頭

如果要檢查瀏覽器發送的標題，可以按F12鍵，轉到”Network”選項，重新刷新頁面，然後點擊要檢查的請求。如果需要，可以點擊”查看源始碼”，這將向您顯示實際的HTTP文本。這是在Chrome中的外觀：

發送額外的信息到服務器

有時，您可能想向GET請求中添加其他信息。您可以通過在URI後加上問號（？），然後再加上key = value來發送鍵值配對。多個配對之間用＆分隔。例如：

GET /get-phone-number.php?firstName=Terry&lastName=Lee HTTP/1.1
Host: www.phonebook.example.com
...

如果在鍵或值名稱中使用任何特殊字符，則必須對其進行URL編碼。

HTTP POST

POST請求用於將數據發送到服務器，例如，在登錄或上傳照片時將用戶名和密碼發送到服務器。與GET不同，POST可以更改服務器上的數據或服務器的狀態。
POST的正文可以包含發送到服務器的數據。

POST請求的剖析

例如，當您輸入憑據並點擊登錄按鈕時，網站的登錄頁面會發送如下信息：

POST /login.php HTTP/1.1
Host: www.example.com
Connection: keep-alive
Content-Length: 480
Origin: http://www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryQNEJOasMvgAOg8Kt
...

如您所見，request line現在具有POST方法，並且仍然跟隨著URI / login.php和HTTP版本1.1。該host header仍然只包含域名。真正的差別是request body：GET請求沒有有效負載(payload)，而您可以向POST請求的正文中添加大量數據。這些數據可以是普通的鍵值對，例如用戶名和密碼，也可以是正在上傳的實際文件。還要注意Content-Type標頭：它告訴服務器在POST請求的正文中可以找到哪種數據。讓我們看一下登錄範例的body：

------WebKitFormBoundaryQNEJOasMvgAOg8Kt
Content-Disposition: form-data; name="username"
Terry Lee
------WebKitFormBoundaryQNEJOasMvgAOg8Kt
Content-Disposition: form-data; name="password"
p@ssw0rd123
------WebKitFormBoundaryQNEJOasMvgAOg8Kt
Content-Disposition: form-data; name="token"
9i9ZoLHl5pkRAeuKCEu76TbaCnMphwYkPEovEUY9PHk=
------WebKitFormBoundaryQNEJOasMvgAOg8Kt--

可以看到，body內部有三個參數，每個參數都有一個名稱（例如，用戶名）和一個值（例如，Terry Lee）。您還可以使用在向GET請求中增加參數時使用的相同語法：

POST /add-user.php HTTP/1.1
Host: www.example.com
Content-Length: 27
Content-Type: application/x-www-form-urlencoded
...

和有效負載(payload)：

firstName=Terry&lastName=Lee

可以看到，Content-Type標頭是不同的，表示有效負載中值的編碼是不同的。

HTTP狀態碼

服務器回覆會使用HTTP狀態代碼回答所有請求。這是一個三位數的數字，指示請求是否成功，或者告訴客戶端發生了什麼問題。下面這張表格包含一些最重要和最有用的訊息。

狀態碼	含義
200	OK：請求成功
303	查看其他：例如，在POST請求之後，用於重新導向到其他URI
400	錯誤的請求：服務器無法理解該請求，因為語法不正確
401	未經授權：需要用戶驗證
403	禁止：服務器拒絕執行請求，授權無濟於事
404	找不到：找不到請求的URI
500	內部服務器錯誤：服務器遇到意外情況，無法滿足請求

TCP和UDP Ports

在大多數情況下，一台設備具有許多不同的服務，例如，Web服務器，電子郵件服務器，FTP服務器，Spotify串流服務，…如果設備只有一個IP地址，就不可能知道數據包發送到哪個應用程序。這就是每個服務都有Port號碼的原因。它是單個設備上所有不同服務或應用程序的標識符。在上面的示例中，Web服務器的port是80只會在這個port上監聽請求，電子郵件服務器只在port 25上監聽，FTP服務器監聽的port是20，Spotify是在port 4371上接收串流…要指定某個埠口，可以在域名後的IP地址後使用冒號。但是大多數時候，您不必顯式添加它。例如，所有Web服務器都監聽port 80，因此Web瀏覽器將始終連接到port 80。