56 Django--HTTP協議與Django下載使用

目錄

• HTTP協議
  • HTTP工做原理：
  • HTTP特色：
  • HTTP請求方式：
  • URL : 統一資源定位符
  • HTTP請求格式
  • HTTP響應協議
  • HTTP狀態碼
    • 301和302區別
• Django下載及簡單示例
  • 基於Django實現一個簡單示例
• MVC和MTV框架
  • mvc
  • MTV

HTTP協議

超文本傳輸協議(HyperText Transfer Protocol,HTTP)是一種用於分佈式、協做式和超媒體信息系統的應用層協議。HTTP是萬維網的數據通訊的基礎。

1999年6月公佈的 RFC 2616，定義了HTTP協議中現今普遍使用的一個版本——HTTP 1.1。

HTTP工做原理：

HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

1. 客戶端鏈接到Web服務器
   一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。
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 文本並顯示內容; 　

HTTP特色：

　http協議是基於TCP/IP協議之上的應用層協議。

1. 基於請求-響應 的模式：HTTP協議規定,請求從客戶端發出,最後服務器端響應該請求並 返回。換句話說,確定是先從客戶端開始創建通訊的,服務器端在沒有 接收到請求以前不會發送響應。

2. 無狀態保存：HTTP是一種不保存狀態,即無狀態(stateless)協議。HTTP協議 自身不對請求和響應之間的通訊狀態進行保存。也就是說在HTTP這個級別,協議對於發送過的請求或響應都不作持久化處理。

   ​ 使用HTTP協議,每當有新的請求發送時,就會有對應的新響應產生。協議自己並不保留以前一切的請求或響應報文的信息。這是爲了更快地處理大量事務,確保協議的可伸縮性,而特地把HTTP協議設計成 如此簡單的。

3. 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間，而且能夠提升併發性能，不能和每一個用戶創建長久的鏈接，請求一次響應一次，服務端和客戶端就中斷了。可是無鏈接有兩種方式，早期的http協議是一個請求一個響應以後，直接就斷開了，可是如今的http協議1.1版本不是直接就斷開了，而是等幾秒鐘，這幾秒鐘是等什麼呢，等着用戶有後續的操做，若是用戶在這幾秒鐘以內有新的請求，那麼仍是經過以前的鏈接通道來收發消息，若是過了這幾秒鐘用戶沒有發送新的請求，那麼就會斷開鏈接，這樣能夠提升效率，減小短期內創建鏈接的次數，由於創建鏈接也是耗時的，默認的好像是3秒中如今，可是這個時間是能夠經過我們後端的代碼來調整的，本身網站根據本身網站用戶的行爲來分析統計出一個最優的等待時間。

HTTP請求方式：

1. GET : 向指定的資源發出「顯示」請求。使用GET方法應該只用在讀取數據，而不該當被用於產生「反作用」的操做中。
2. POST : 向指定資源提交數據，請求服務器進行處理(提交表單或者上傳文件)。數據被包含在請求本文中。
3. HEAD : 與GET方法同樣，都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在於，使用這個方法能夠在沒必要傳輸所有內容的狀況下，就能夠獲取其中「關於該資源的信息」（元信息或稱元數據）。
4. PUT : 向指定資源位置上傳其最新內容。
5. DELETE : 請求服務器刪除Request-URI所標識的資源。
6. TRACE : 回顯服務器收到的請求，主要用於測試或診斷。
7. OPTIONS : 這個方法可以使服務器傳回該資源所支持的全部HTTP請求方法。用'*'來代替資源名稱，向Web服務器發送OPTIONS請求，能夠測試服務器功能是否正常運做。
8. CONNECT : HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。一般用於SSL加密服務器的連接（經由非加密的HTTP代理服務器）。
9. patch

注意事項：

1. 方法名稱是區分大小寫的。當某個請求所針對的資源不支持對應的請求方法的時候，服務器應當返回狀態碼405（Method Not Allowed），當服務器不認識或者不支持對應的請求方法的時候，應當返回狀態碼501（Not Implemented）。
2. HTTP服務器至少應該實現GET和HEAD方法，其餘方法都是可選的。固然，全部的方法支持的實現都應當匹配各自的語義定義。此外，除了上述方法，特定的HTTP服務器還可以擴展自定義的方法。例如PATCH（由 RFC 5789 指定的方法）用於將局部修改應用到資源。

請求方式: get與post請求（form表單示例）

• GET提交的數據會放在URL以後，也就是請求行裏面，以?分割URL和傳輸數據，參數之間以&相連，如EditBook?name=test1&id=123456.（請求頭裏面那個content-type作的這種參數形式，後面講） POST方法是把提交的數據放在HTTP包的請求體中.

• GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制。

• GET與POST請求在服務端獲取請求數據方式不一樣，就是咱們本身在服務端取請求數據的時候的方式不一樣了。

  get通常用於獲取數據；post通常用於提交數據。

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。從技術上來講這樣省略後的網頁地址其實是一個不一樣的網頁地址，瀏覽器自己沒法決定這個新地址是否通，服務器必須完成重定向的任務。

HTTP請求格式

請求格式：

​ 請求行 請求頭部 空行 請求數據

請求行：

​ 請求方式（GET/POST） 路由url（路徑） HTTP/1.1

HTTP響應協議

響應格式：

​ 狀態行 響應頭部 空行 響應正文

狀態行：

​ HTTP/1.1 200 OK

HTTP狀態碼

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

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

• 1xx消息——請求已被服務器接收，繼續處理
• 2xx成功——請求已成功被服務器接收、理解、並接受
• 3xx重定向——須要後續操做才能完成這一請求
• 4xx請求錯誤——請求含有詞法錯誤或者沒法被執行
• 5xx服務器錯誤——服務器在處理某個正確請求時發生錯誤

類型	類別	緣由短語
1XX	Informational(信息性狀態碼)	接收的請求正在處理
2XX	Success(成功狀態碼)	請求正常處理完畢
3XX	Redirection(從新定向狀態碼)	須要進行附加操做以完成請求
4XX	Client Error(客戶端錯誤狀態碼)	服務器沒法處理請求
5XX	Server Error(服務器錯誤狀態碼)	服務器處理請求出錯

301和302區別

301是永久重定向，302是臨時重定向。

1）301和302的區別。

　　301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址能夠從響應的Location首部中獲取
  （用戶看到的效果就是他輸入的地址A瞬間變成了另外一個地址B）——這是它們的共同點。

　　他們的不一樣在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換爲重定向以後的網址；

　　302表示舊地址A的資源還在（仍然能夠訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。 SEO302好於301

 

2）重定向緣由：
（1）網站調整（如改變網頁目錄結構）；
（2）網頁被移到一個新地址；
（3）網頁擴展名改變(如應用須要把.php改爲.Html或.shtml)。
        這種狀況下，若是不作重定向，則用戶收藏夾或搜索引擎數據庫中舊地址只能讓訪問客戶獲得一個404頁面錯誤信息，訪問流量白白喪失；再者某些註冊了多個域名的
    網站，也須要經過重定向讓訪問這些域名的用戶自動跳轉到主站點等。

Django下載及簡單示例

下載安裝：

pip3 install django == 1.11.9

pip3 install django == 1.11.9 -i https://pypi.tuna.tsinghua.edu.cn/simple/  # 清華源下載

建立項目：

1. 命令行：   django-admin startproject 項目名

2. pycharm：File--New Project--Django--location中寫項目路徑及文件名、選擇Existing interpreter(添加python解釋器)

建立應用：

python manage.py startapp 應用名

須要在setting配置文件中，installapps的列表中，添加一個app名稱做爲配置。

應用下有幾個文件：
    models.py ：以前咱們寫的那個名爲model的文件就是建立表用的，這個文件就是存放與該app(應用)相關的表結構的。
    views.py ：存放與該app相關的視圖函數的（邏輯）。

啓動項目：

python manage.py runserver          # 默認是127.0.0.1:8000

python manage.py runserver  127.0.0.1   # 設置ip，端口默認8000

python manage.py runserver  127.0.0.1:80    # 全設置，不用寫80端口

基於Django實現一個簡單示例

url控制器

from django.conf.urls import url
from django.contrib import admin

from app01 import views

urlpatterns = [
    url(r'^admin/', admin.site.urls),
    url(r'^home/', views.home),]

視圖views

from django.shortcuts import render,HttpResponse

def home(request):  # request -- 請求相關的信息對象
    
    return render(request, 'home.html') 
    #模板渲染 模板就是html頁面 渲染就是字符串替換 
    #第一個參數:request  第二個參數是html頁面路徑
    #return HttpResponse('str')     # 返回字符串數據

template文件夾下home.html 模板

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<h1>24期官網</h1>
</body>
{#<script src="jquery.js"></script>#}
</html>

啓動項目後，執行效果以下：

若是報如下錯誤：

如今只須要作一步，在settings配置文件裏面將這一行註釋掉，這是django給你加的一個csrf的認證，如今不須要。

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

MVC和MTV框架

mvc

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

MTV

Django的MTV模式本質上和MVC是同樣的，也是爲了各組件間保持鬆耦合關係，只是定義上有些許不一樣，Django的MTV分別是值：

• M 表明模型（Model）： 負責業務對象和數據庫的關係映射(ORM)。
• T 表明模板 (Template)：負責如何把頁面展現給用戶(html)。
• V 表明視圖（View）： 負責業務邏輯，並在適當時候調用Model和Template。

　　除了以上三層以外，還須要一個URL分發器，它的做用是將一個個URL的頁面請求分發給不一樣的View處理，View再調用相應的Model和Template，MTV的響應模式以下所示：

​ 通常是用戶經過瀏覽器向咱們的服務器發起一個請求(request)，這個請求會去訪問視圖函數，（若是不涉及到數據調用，那麼這個時候視圖函數返回一個模板也就是一個網頁給用戶），視圖函數調用模型，模型去數據庫查找數據，而後逐級返回，視圖函數把返回的數據填充到模板中空格中，最後返回網頁給用戶。