Django的次日

時間  2019-11-18
標籤 django 次日 欄目 Python 简体版
原文   原文鏈接

  1. HTTP協議html

    1.1 簡介
 超文本傳輸協議：分佈式、協做式和超媒體信息系統的應用層協議，是萬維網的數據通訊的基礎。
 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的實現標準。
    1.2 協議概述
 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"，以及返回的內容，如請求的文件、錯誤消息、或者其它信息。
    1.3 工做原理
 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，按下回車以後會經歷如下流程：

1. 瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
   2. 解析出 IP 地址後，根據該 IP 地址和默認端口 80，和服務器創建TCP鏈接;
      3. 瀏覽器發出讀取文件(URL 中域名後面部分對應的文件)的HTTP 請求，該請求報文做爲 TCP 三次握手的第三個報文的數據發送給服務器;
      4. 服務器對瀏覽器請求做出響應，並把對應的 html 文本發送給瀏覽器;
      5. 釋放 TCP鏈接;
      6. 瀏覽器將該 html 文本並顯示內容; 　

    1.4 http協議是基於TCP/IP協議上的應用層協議python

    基於請求-響應的模式
 HTTP協議規定,請求從客戶端發出,最後服務器端響應該請求並 返回。換句話說,確定是先從客戶端開始創建通訊的,服務器端在沒有 接收到請求以前不會發送響應
    無狀態保存
 HTTP是一種不保存狀態,即無狀態(stateless)協議。HTTP協議 自身不對請求和響應之間的通訊狀態進行保存。也就是說在HTTP這個 級別,協議對於發送過的請求或響應都不作持久化處理。
 使用HTTP協議,每當有新的請求發送時,就會有對應的新響應產 生。協議自己並不保留以前一切的請求或響應報文的信息。這是爲了更快地處理大量事務,確保協議的可伸縮性,而特地把HTTP協議設計成 如此簡單的。但是,隨着Web的不斷髮展,因無狀態而致使業務處理變得棘手 的狀況增多了。好比,用戶登陸到一家購物網站,即便他跳轉到該站的 其餘頁面後,也須要能繼續保持登陸狀態。針對這個實例,網站爲了能 夠掌握是誰送出的請求,須要保存用戶的狀態。HTTP/1.1雖然是無狀態協議,但爲了實現指望的保持狀態功能, 因而引入了Cookie技術。有了Cookie再用HTTP協議通訊,就能夠管 理狀態了。
 Cookie技術
    無鏈接
 無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間，而且能夠提升併發性能，不能和每一個用戶創建長久的鏈接，請求一次相應一次，服務端和客戶端就中斷了。可是無鏈接有兩種方式，早期的http協議是一個請求一個響應以後，直接就斷開了，可是如今的http協議1.1版本不是直接就斷開了，而是等幾秒鐘，這幾秒鐘是等什麼呢，等着用戶有後續的操做，若是用戶在這幾秒鐘以內有新的請求，那麼仍是經過以前的鏈接通道來收發消息，若是過了這幾秒鐘用戶沒有發送新的請求，那麼就會斷開鏈接，這樣能夠提升效率，減小短期內創建鏈接的次數，由於創建鏈接也是耗時的，默認的好像是3秒中如今，可是這個時間是能夠經過我們後端的代碼來調整的，本身網站根據本身網站用戶的行爲來分析統計出一個最優的等待時間。

    1.5 HTTP請求方法(HTTP/1.1協議中共定義了八種方法(也叫‘動做’)來以不一樣方式操做指定的資源)數據庫

    GET:
 向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取數據，而不該當被用於產生「反作用」的操做中，例如在Web Application中。其中一個緣由是GET可能會被網絡蜘蛛等隨意訪問。 

HEAD:
 與GET方法同樣，都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在於，使用這個方法能夠在沒必要傳輸所有內容的狀況下，就能夠獲取其中「關於該資源的信息」（元信息或稱元數據）。

POST:
 向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會建立新的資源或修改現有資源，或兩者皆有。

PUT:向指定資源位置上傳其最新內容。

DELETE:請求服務器刪除Request-URI所標識的資源。

TRACE:   回顯服務器收到的請求，主要用於測試或診斷。

OPTIONS: 
 這個方法可以使服務器傳回該資源所支持的全部HTTP請求方法。用'*'來代替資源名稱，向Web服務器發送OPTIONS請求，能夠測試服務器功能是否正常運做

CONMECT:
 HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接（經由非加密的HTTP代理服務器）。

注意事項：
 1.方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed），當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
 2.HTTP服務器至少應該實現GET和HEAD方法，其餘方法都是可選的。固然，全部的方法支持的實現都應當匹配下述的方法各自的語義定義。此外，除了上述方法，特定的HTTP服務器還可以擴展自定義的方法。例如PATCH（由 RFC 5789 指定的方法）用於將局部修改應用到資源。
    請求方式：get與post請求
 GET提交的數據會放在URL以後，也就是請求行裏面，以?分割URL和傳輸數據，參數之間以&相連，如EditBook?name=test1&id=123456.（請求頭裏面那個content-type作的這種參數形式，後面講） POST方法是把提交的數據放在HTTP包的請求體中.
 GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
 GET與POST請求在服務端獲取請求數據方式不一樣，就是咱們本身在服務端取請求數據的時候的方式不一樣了，這句廢話昂。

    1.6 HTTP狀態碼django

    全部HTTP響應的第一行都是狀態行，依次是當前HTTP版本號，3位數字組成的狀態代碼，以及描述狀態的短語，彼此由空格分隔。

狀態代碼的第一個數字表明當前響應的類型：

1xx消息——請求已被服務器接收，繼續處理
2xx成功——請求已成功被服務器接收、理解、並接受
3xx重定向——須要後續操做才能完成這一請求
4xx請求錯誤——請求含有詞法錯誤或者沒法被執行
5xx服務器錯誤——服務器在處理某個正確請求時發生錯誤
雖然 RFC 2616 中已經推薦了描述狀態的短語，例如"200 OK"，"404 Not Found"，可是WEB開發者仍然可以自行決定採用何種短語，用以顯示本地化的狀態描述或者自定義信息。

    1569310104383

    1.7 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，是路徑（URI：直接定位到對應的資源）；
?id=250&page=1，是查詢。
大多數網頁瀏覽器不要求用戶輸入網頁中「http://」的部分，由於絕大多數網頁內容是超文本傳輸協議文件。一樣，「80」是超文本傳輸協議文件的經常使用端口號，所以通常也沒必要寫明。通常來講用戶只要鍵入統一資源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就能夠了。

因爲超文本傳輸協議容許服務器將瀏覽器重定向到另外一個網頁地址，所以許多服務器容許用戶省略網頁地址中的部分，好比 www。從技術上來講這樣省略後的網頁地址其實是一個不一樣的網頁地址，瀏覽器自己沒法決定這個新地址是否通，服務器必須完成重定向的任務。

    1.8 HTTP請求格式(請求協議)瀏覽器

1569310186102

​ URL包含：/index/index2?a=1&b=2；路徑和參數都在這裏。服務器

1569310217444

​ 1.9 HTTP響應格式(響應協議)網絡

​ 1569310460281

1569310477505

  1. MVC和MTV框架模式
2.1 MVC框架模式
    Web服務器開發領域裏著名的MVC模式，所謂MVC就是把Web應用分爲模型(M)，控制器(C)和視圖(V)三層，他們之間以一種插件式的、鬆耦合的方式鏈接在一塊兒，模型負責業務對象與數據庫的映射(ORM)，視圖負責與用戶的交互(頁面)，控制器接受用戶的輸入調用模型和視圖完成用戶的請求，其示意圖以下所示：

1569310669431

2.2 MTV框架模式
    Django的MTV模式本質上和MVC是同樣的，也是爲了各組件間保持鬆耦合關係，只是定義上有些許不一樣，Django的MTV分別是值：
M 表明模型（Model）： 負責業務對象和數據庫的關係映射(ORM)。
T 表明模板 (Template)：負責如何把頁面展現給用戶(html)。
V 表明視圖（View）：   負責業務邏輯，並在適當時候調用Model和Template。
　　除了以上三層以外，還須要一個URL分發器，它的做用是將一個個URL的頁面請求分發給不一樣的View處理，View再調用相應的Model和Template，MTV的響應模式以下所示：

1569310708930

通常是用戶經過瀏覽器向咱們的服務器發起一個請求(request)，這個請求回去訪問視圖函數，（若是不涉及到數據調用，那麼這個時候視圖函數返回一個模板也就是一個網頁給用戶），視圖函數調用模型，模型去數據庫查找數據，而後逐級返回，視圖函數把返回的數據填充到模板中空格中，最後返回網頁給用戶。
  1. django下載安裝
下載
    pip3 install django==1.11.9 
    pip3 install django==1.11.9 -i http://xxxxxx  指定源
建立項目
    django-admin startproject mysite   建立了一個名爲"mysite"的Django 項目
啓動項目
    python manage.py runserver  默認是127.0.0.1:8000
    python manage.py runserver 127.0.0.1  默認端口號是8000
    python manage.py runserver 127.0.0.1:8001

django的url路由分發併發

url(r'^articles/(\d+)/(\d+)/', views.articles), #articles/2019/9/

視圖函數
    def articles(request,year,month):  # 位置參數 2019  9
        print(year,type(year)) #2019 <class 'str'>  #匹配出來的全部數據都是字符串
        print(month)

        return HttpResponse(year+'年'+ month +'月' +'全部文章')
    

# 有名分組參數
url(r'^articles/(?P<xx>\d+)/(?P<oo>\d+)/', views.articles), #articles/2019/9/
#xx=2019  oo=9  關鍵字傳參

def articles(request,oo,xx):  # 關鍵字傳參 2019  9
    print(xx,type(xx)) #2019 <class 'str'>  #匹配出來的全部數據都是字符串
    print(oo)
    return HttpResponse(xx+'年'+ oo +'月' +'全部文章')
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程