web框架簡介, 以及 HTTP協議初步了解
所有的Web應用本質上就是一個socket服務端，而用戶的瀏覽器就是一個socket客戶端。 這樣我們就可以自己實現Web框架了
##################
# #
# #
# socket服務端 #
# #
# #
##################
import socket
sk = socket.socket()
sk.bind(("127.0.0.1", 80))
sk.listen()
while True:
conn, addr = sk.accept()
data = conn.recv(8096)
conn.send(b"OK")
conn.close()
可以說Web服務本質上都是在這十幾行代碼基礎上擴展出來的。這段代碼就是它們的祖宗。
用戶在瀏覽器中輸入網址，瀏覽器會向服務端發送數據，那瀏覽器會發送什麽數據？怎麽發？這個誰來定？ 你這個網站是這個規定，他那個網站按照他那個規定，那互聯網還能玩麽？
所以，必須有一個統一的規則，讓大家發送消息、接收消息的時候都有個格式依據，不能隨便寫。
這個規則就是HTTP協議，以後瀏覽器發送請求信息也好，服務器回復響應信息也罷，都要按照這個規則來。
HTTP協議主要規定了客戶端和服務器之間的通信格式，那HTTP協議是怎麽規定消息格式的呢？
讓我們首先打印下我們在服務端接收到的消息是什麽。
import socket
sk = socket.socket()
sk.bind(("127.0.0.1", 80))
sk.listen()
while True:
conn, addr = sk.accept()
data = conn.recv(8096)
print(data) # 將瀏覽器發來的消息打印出來
conn.send(b"OK")
conn.close()
輸出:
b‘GET / HTTP/1.1\r\nHost: 127.0.0.1:8080\r\nConnection: keep-alive\r\nCache-Control: max-age=0\r\nUpgrade-Insecure-Requests: 1\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3355.4 Safari/537.36\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8\r\nAccept-Encoding: gzip, deflate, br\r\nAccept-Language: zh-CN,zh;q=0.9\r\nCookie: csrftoken=CtHePYARJOKNx5oNVwxIteOJXpNyJ29L4bW4506YoVqFaIFFaHm0EWDZqKmw6Jm8\r\n\r\n‘
將\r\n 替換成換行看看清楚:
GET / HTTP/1.1
Host: 127.0.0.1:8080
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3355.4 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Cookie: csrftoken=CtHePYARJOKNx5oNVwxIteOJXpNyJ29L4bW4506YoVqFaIFFaHm0EWDZqKmw6Jm8
這就是請求體;
當得到請求體後, 我們需要根據相對應的 url 來進行響應, 同時我們需要遵循http協議才能將數據響應到客戶的瀏覽器上, 在這裏,我們就需要了解一些HTTP協議了.
然後我們再看一下我們訪問博客園官網時瀏覽器收到的響應信息是什麽。
響應相關信息可以在瀏覽器調試窗口的Network標簽頁中看到。
點擊view source之後顯示如下圖：
我們發現收發的消息需要按照一定的格式來，這裏就需要了解一下HTTP協議了。
HTTP協議介紹
HTTP協議對收發消息的格式要求
每個HTTP請求和響應都遵循相同的格式，一個HTTP包含Header和Body兩部分，其中Body是可選的。
HTTP響應的Header中有一個 Content-Type表明響應的內容格式。它的值如text/html; charset=utf-8。
text/html則表示是網頁，charset=utf-8則表示編碼為utf-8。
HTTP協議 初識
一. HTTP協議簡介:
超文本傳輸協議（英文：Hyper Text Transfer Protocol，HTTP）是一種用於分布式、協作式和超媒體信息系統的應用層協議。HTTP是萬維網的數據通信的基礎。HTTP有很多應用，但最著名的是用於web瀏覽器和web服務器之間的雙工通信。
HTTP的發展是由蒂姆·伯納斯-李於1989年在歐洲核子研究組織（CERN）所發起。HTTP的標準制定由萬維網協會（World Wide Web Consortium，W3C）和互聯網工程任務組（Internet Engineering Task Force，IETF）進行協調，最終發布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定義了HTTP協議中現今廣泛使用的一個版本——HTTP 1.1。
2014年12月，互聯網工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組將HTTP/2標準提議遞交至IESG進行討論，於2015年2月17日被批準。 HTTP/2標準於2015年5月以RFC 7540正式發表，取代HTTP 1.1成為HTTP的實現標準。
推薦書籍：HTTP權威指南
二. HTTP協議概述
HTTP是一個客戶端終端（用戶）和服務器端（網站）請求和應答的標準（TCP）。通過使用網頁瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個HTTP請求到服務器上指定端口（默認端口為80）。我們稱這個客戶端為用戶代理程序（user agent）。應答的服務器上存儲著一些資源，比如HTML文件和圖像。我們稱這個應答服務器為源服務器（origin server）。在用戶代理和源服務器中間可能存在多個“中間層”，比如代理服務器、網關或者隧道（tunnel）。
盡管TCP/IP協議是互聯網上最流行的應用，HTTP協議中，並沒有規定必須使用它或它支持的層。事實上，HTTP可以在任何互聯網協議上，或其他網絡上實現。HTTP假定其下層協議提供可靠的傳輸。因此，任何能夠提供這種保證的協議都可以被其使用。因此也就是其在TCP/IP協議族使用TCP作為其傳輸層。
通常，由HTTP客戶端發起一個請求，創建一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監聽客戶端的請求。一旦收到請求，服務器會向客戶端返回一個狀態，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的文件、錯誤消息、或者其它信息。
三. HTTP工作原理:
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。
以下是 HTTP 請求/響應的步驟：
1. 客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.luffycity.com。
2. 發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
3. 服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4. 釋放連接TCP連接
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;
5. 客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行，查看表明請求是否成功的狀態代碼。然後解析每一個響應頭，響應頭告知以下為若幹字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。
在瀏覽器地址欄鍵入URL，按下回車之後會經歷以下流程：
- 瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
- 解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器建立TCP連接;
- 瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的數據發送給服務器;
- 服務器對瀏覽器請求作出響應，並把對應的 html 文本發送給瀏覽器;
- 釋放 TCP連接;
- 瀏覽器將該 html 文本並顯示內容;
四. HTTP請求方法:
HTTP/1.1協議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：
GET
向指定的資源發出“顯示”請求。使用GET方法應該只用在讀取數據，而不應當被用於產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
HEAD
與GET方法一樣，都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在於，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中“關於該資源的信息”（元信息或稱元數據）。
POST
向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會創建新的資源或修改現有資源，或二者皆有。
PUT
向指定資源位置上傳其最新內容。
DELETE
請求服務器刪除Request-URI所標識的資源。
TRACE
回顯服務器收到的請求，主要用於測試或診斷。
OPTIONS
這個方法可使服務器傳回該資源所支持的所有HTTP請求方法。用‘*‘來代替資源名稱，向Web服務器發送OPTIONS請求，可以測試服務器功能是否正常運作。
CONNECT
HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。通常用於SSL加密服務器的鏈接（經由非加密的HTTP代理服務器）。
註意事項：
- 方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed），當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
- HTTP服務器至少應該實現GET和HEAD方法，其他方法都是可選的。當然，所有的方法支持的實現都應當匹配下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP服務器還能夠擴展自定義的方法。例如PATCH（由 RFC 5789 指定的方法）用於將局部修改應用到資源。
五. HTTP狀態碼:
所有HTTP響應的第一行都是狀態行，依次是當前HTTP版本號，3位數字組成的狀態代碼，以及描述狀態的短語，彼此由空格分隔。
狀態代碼的第一個數字代表當前響應的類型：
- 1xx消息——請求已被服務器接收，繼續處理
- 2xx成功——請求已成功被服務器接收、理解、並接受
- 3xx重定向——需要後續操作才能完成這一請求
- 4xx請求錯誤——請求含有詞法錯誤或者無法被執行
- 5xx服務器錯誤——服務器在處理某個正確請求時發生錯誤
雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，但是WEB開發者仍然能夠自行決定采用何種短語，用以顯示本地化的狀態描述或者自定義信息。
六. URL
超文本傳輸協議（HTTP）的統一資源定位符將從因特網獲取信息的五個基本元素包括在一個簡單的地址中：
- 傳送協議。
- 層級URL標記符號(為[//],固定不變)
- 訪問資源需要的憑證信息（可省略）
- 服務器。（通常為域名，有時為IP地址）
- 端口號。（以數字方式表示，若為HTTP的默認值“:80”可省略）
- 路徑。（以“/”字符區別路徑中的每一個目錄名稱）
- 查詢。（GET模式的窗體參數，以“?”字符為起點，每個參數以“&”隔開，再以“=”分開參數名稱與數據，通常以UTF8的URL編碼，避開字符沖突的問題）
- 片段。以“#”字符為起點
以http://www.luffycity.com:80/news/index.html?id=250&page=1 為例, 其中：
http，是協議；
www.luffycity.com，是服務器；
80，是服務器上的網絡端口號；
/news/index.html，是路徑；
?id=250&page=1，是查詢。
大多數網頁瀏覽器不要求用戶輸入網頁中“http://”的部分，因為絕大多數網頁內容是超文本傳輸協議文件。同樣，“80”是超文本傳輸協議文件的常用端口號，因此一般也不必寫明。一般來說用戶只要鍵入統一資源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。
七. HTTP請求格式:
八. HTTP響應格式:
web框架簡介, 以及 HTTP協議初步了解