a. wsgi, 創建socket服務端，用於接收用戶請求並對請求進行初次封裝。
b. 中間件，對所有請求到來之前，響應之前定製一些操作。
c. 路由匹配，在url和視圖函數對應關係中，根據當前請求url找到相應的函數。
d. 執行視圖函數，業務處理【通過ORM去數據庫中獲取數據，再去拿到模板，然後將數據和模板進行渲染】
e. 再經過所有中間件。
f. 通過wsgi將響應返回給用戶。
一個 HTTP 請求，首先被轉化成一個 HttpRequest 對象，然後該對象被傳遞給
Request 中間件處理，如果該中間件返回了Response，則直接傳遞給
Response 中間件做收尾處理。否則的話 Request 中間件將訪問 URL 配置，確
定哪個 view 來處理，在確定了哪個 view 要執行，但是還沒有執行該 view 的時
候，系統會把 request 傳遞給 View 中間件處理器進行處理，如果該中間件返回
了Response，那麼該Response 直接被傳遞給 Response 中間件進行後續處
理，否則將執行確定的 View 函數處理並返回 Response，在這個過程中如果引
發了異常並拋出，會被 Exception 中間件處理器進行處理。
ORM，全拼Object-Relation Mapping，意爲對象-關係映射
實現了數據模型與數據庫的解耦，通過簡單的配置就可以輕鬆更換數據庫，而不需要修改代碼只需要面
向對象編程,orm操作本質上會根據對接的數據庫引擎，翻譯成對應的sql語句,所有使用Django開發的項
目無需關心程序底層使用的是MySQL、Oracle、sqlite....，如果數據庫遷移，只需要更換Django的數據
庫引擎即可
django的get方法是從數據庫的取得一個匹配的結果，返回一個對象，如果記錄不存在的話，它會報錯。
django的filter方法是從數據庫的取得匹配的結果，返回一個對象列表，如果記錄不存在的話，它會返回[]。
get
只能取出一條數據,如果滿足條件的數據有多條,拋出異常
沒有數據,也會拋出異常
filter
如果有數據,就返回QuerySet(類似於可以遍歷的數組) 如果沒有數據,返回empty(不會拋異常)
緩存是將一些常用的數據保存內存或者memcache中,在一定的時間內有人來訪問這些數據時,則不再去
執行數據庫及渲染等操作,而是直接從內存或memcache的緩存中去取得數據,然後返回給用戶.django提
供了6中內存緩存機制，分別爲：
開發調試緩存（爲開發調試使用，實際上不使用任何操作）；
內存緩存（將緩存內容緩存到內存中）；
文件緩存（將緩存內容寫到文件 ）；
數據庫緩存（將緩存內容存到數據庫）；
memcache緩存（包含兩種模塊，python-memcached或pylibmc.）。
以上緩存均提供了三種粒度的應用。
只包含字母、數字、下劃線和連接符，通常用於urls
在類中總共有三種方法：普通方法（需要參數，使用時默認將類的實例對象傳進去，類調用的時候需要
傳遞實例對象），@staticmethod裝飾的靜態方法與普通函數相同（實例和類均可調用，沒有默認的參
數傳遞進去），@classmethod裝飾的類方法（需要參數，使用時將調用的類傳進去，或者實例對象調
用時是將實例對應的類傳進去。
socket是在應用層和傳輸層之間的一個抽象層，它把TCP/IP層複雜的操作抽象爲
幾個簡單的接口供應用層調用以實現進程在網絡中通信。
Cookie概念
在瀏覽某些 網站 時,這些網站會把 一些數據存在 客戶端 , 用於使用網站 等跟蹤用戶實現用戶自定
義 功能.
是否設置過期時間:
如果不設置 過期時間,則表示這個 Cookie生命週期爲 瀏覽器會話期間 , 只要關閉瀏覽器,cookie就消失了.
這個生命期爲瀏覽會話期的cookie,就是會話Cookie;
存儲: 一般保存在 內存,不在硬盤;
如果設置了過期時間, 瀏覽器會把cookie保存在硬盤上,關閉再打開瀏覽器, 這些cookie 依然有效直到 超
過的設置過期時間;
Session的概念
作用：實現網頁之間數據傳遞，是一個存儲在服務器端的對象集合。
原理：當用戶請求一個Asp.net頁面時，系統將自動創建一個Session;退出應用程序或關閉服務器
時，該Session撤銷。系統在創建Session時將爲其分配一個長長的字符串標識，以實現對Session進
行管理與跟蹤。
cookie 和session 的區別：
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上.
簡單的說，當你登錄一個網站的時候，如果web服務器端使用的是session,那麼所有的數據都保存
在服務器上面，
客戶端每次請求服務器的時候會發送 當前會話的session_id，服務器根據當前session_id判斷相應的用
戶數據標誌，以確定用戶是否登錄，或具有某種權限。
由於數據是存儲在服務器 上面，所以你不能僞造，但是如果你能夠獲取某個登錄用戶的session_id，用
特殊的瀏覽器僞造該用戶的請求也是能夠成功的。
session_id是服務 器和客戶端鏈接時候隨機分配的，一般來說是不會有重複，但如果有大量的併發請
求，也不是沒有重複的可能性，我曾經就遇到過一次。
登錄某個網站，開始顯示的 是自己的信息，等一段時間超時了，一刷新，居然顯示了別人的信息。
Session是由應用服務器維持的一個服務器端的存儲空間，用戶在連接服務器時，會由服務器生成一個
唯一的SessionID,用該SessionID 爲標識符來存取服務器端的Session存儲空間。而SessionID這一數據
則是保存到客戶端，用Cookie保存的，用戶提交頁面時，會將這一 SessionID提交到服務器端，來存取
Session數據。這一過程，是不用開發人員干預的。所以一旦客戶端禁用Cookie，那麼Session也會失
效。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙考慮到安全應當使用
session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能考慮到減輕服務
器性能方面，應當使用COOKIE。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。(Session對
象沒有對存儲的數據量的限制，其中可以保存更爲複雜的數據類型)
1.使用預編譯綁定變量的SQL語句
2.嚴格加密處理用戶的機密信息
3.不要隨意開啓生產環境中Webserver的錯誤顯示
4.使用正則表達式過濾傳入的參數
5.字符串過濾
6.檢查是否包函非法字符
windows查看端口占用
在windows命令行窗口下執行：
netstat -aon|findstr "8080"
linux系統
先使用 netstat命令，再用 ps命令
執行命令： netstat -anp|grep 8080
輸出結果： tcp 0 0 :::8080 :::* LISTEN 12006/java
執行命令： ps -ef | grep 12006
django.middleware.security.SecurityMiddleware’
一些安全設置，比如XSS腳本過濾。
django.contrib.sessions.middleware.SessionMiddleware
session支持中間件，加入這個中間件，會在數據庫中生成一個django_session的表。
django.middleware.common.CommonMiddleware
通用中間件，會處理一些URL，比如baidu.com會自動的處理成www.baidu.com。比如/blog/111會處理
成/blog/111/自動加上反斜槓
django.middleware.csrf.CsrfViewMiddleware
跨域請求僞造中間件。加入這個中間件，在提交表單的時候會必須加入csrf_token，cookie中也會生成一
個名叫csrftoken的值，也會在header中加入一個HTTP_X_CSRFTOKEN的值來放置CSRF攻擊
django.contrib.auth.middleware.AuthenticationMiddleware
用戶授權中間件。他會在每個HttpRequest對象到達view之前添加當前登錄用戶的user屬性，也就是你可
以在view中通過request訪問user
django.contrib.messages.middleware.MessageMiddleware
消息中間件。展示一些後臺信息給前端頁面。如果需要用到消息，還需要在INSTALLED_APPS中添加
django.contrib.message纔能有效。如果不需要，可以把這兩個都刪除
django.middleware.clickjacking.XFrameOptionsMiddleware
防止通過瀏覽器頁面跨Frame出現clickjacking（欺騙點擊）攻擊出現。
CSRF（Cross-site request forgery），中文名稱：跨站請求僞造，也被稱爲：one click attack/
sessionriding，縮寫爲：CSRF/XSRF。
你這可以這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。CSRF能夠做的事情
包括：以你名義發送郵件，發消息，盜取你的賬號，甚至於購買商品，虛擬貨幣轉賬......造成的問題包
括：個人隱私泄露以及財產安全。
要完成一次CSRF攻擊，受害者必須依次完成兩個步驟：
1.登錄受信任網站A，並在本地生成Cookie。
2.在不登出A的情況下，訪問危險網站B。
Representational State Transfer "表現層狀態轉化"
restful其實就是一套編寫接口的協議，協議規定如何編寫以及如何設置返回值、狀態碼等信息。
restful: 給用戶一個url，根據method不同在後端做不同的處理，比如：post 創建數據、get獲取數據、put
和patch修改數據、delete刪除數據。
（1）每一個URI代表一種資源；
（2）客戶端和服務器之間，傳遞這種資源的某種表現層；
（3）客戶端通過四個HTTP動詞，對服務器端資源進行操作，實現"表現層狀態轉化"。
我們常用的狀態碼：
200 請求成功
301 永久重定向
302 臨時重定向
403 權限問題
404 找不到頁面
500 服務器問題
FBV（function base views） 就是在視圖裏使用函數處理請求。
CBV（class base views） 就是在視圖裏使用類處理請求。
如果我們要寫一個處理GET方法的view，用函數寫的話是下面這樣。
from django.http import HttpResponse
def my_view(request):
if request.method == 'GET':
return HttpResponse('OK')
如果用class-based view寫的話，就是下面這樣
from django.http import HttpResponse
from django.views import View
class MyView(View):
def get(self, request):
return HttpResponse('OK')
Django的url是將一個請求分配給可調用的函數的，而不是一個class。針對這個問題，class-based view提
供了一個as_view()靜態方法（也就是類方法），
在url中，就這麼寫：
# urls.py
from django.conf.urls import url
from myapp.views import MyView
urlpatterns = [
url(r'^index/$', MyView.as_view()),
]
自動生成符合 RESTful 規範的 API
支持 OPTION、HEAD、POST、GET、PATCH、PUT、DELETE
根據 Content-Type 來動態的返回數據類型（如 text、json）
Django Rest framework 的流程大概是這樣的
1.建立 Models
2.依靠 Serialiers 將數據庫取出的數據 Parse 爲 API 的數據（可用於返回給客戶端，也可用於瀏覽器
顯示）
3.ViewSet 是一個 views 的集合，根據客戶端的請求（GET、POST等），返回 Serialiers 處理的數據
權限 Premissions 也在這一步做處理
4.ViewSet 可在 Routers 進行註冊，註冊後會顯示在 Api Root 頁上
5.在 urls 裏註冊 ViewSet 生成的 view，指定監聽的 url
#1.Django是走大而全的方向，它最出名的是其全自動化的管理後臺：只需要使用起ORM，做簡單的對象
定義，它就能自動生成數據庫結構、以及全功能的管理後臺。
#2.Django內置的ORM跟框架內的其他模塊耦合程度高。
#應用程序必須使用Django內置的ORM，否則就不能享受到框架內提供的種種基於其ORM的便利；
#理論上可以切換掉其ORM模塊，但這就相當於要把裝修完畢的房子拆除重新裝修，倒不如一開始就去毛
胚房做全新的裝修。
#3.Django的賣點是超高的開發效率，其性能擴展有限；採用Django的項目，在流量達到一定規模後，都
需要對其進行重構，才能滿足性能的要求。
#4.Django適用的是中小型的網站，或者是作爲大型網站快速實現產品雛形的工具。
#5.Django模板的設計哲學是徹底的將代碼、樣式分離； Django從根本上杜絕在模板中進行編碼、處理數
據的可能。
#1.Django走的是大而全的方向,開發效率高。它的MTV框架,自帶的ORM,admin後臺管理,自帶的sqlite數據
庫和開發測試用的服務器
#給開發者提高了超高的開發效率
#2.Flask是輕量級的框架,自由,靈活,可擴展性很強,核心基於Werkzeug WSGI工具和jinja2模板引擎
#3.Tornado走的是少而精的方向,性能優越。它最出名的是異步非阻塞的設計方式
#Tornado的兩大核心模塊：
# 1.iostraem：對非阻塞式的socket進行簡單的封裝
# 2.ioloop：對I/O多路複用的封裝，它實現了一個單例
#WSGI:
# web服務器網關接口,是一套協議。用於接收用戶請求並將請求進行初次封裝，然後將請求交給web框架
# 實現wsgi協議的模塊：
# 1.wsgiref,本質上就是編寫一個socket服務端，用於接收用戶請求(django)
# 2.werkzeug,本質上就是編寫一個socket服務端，用於接收用戶請求(flask)
#uwsgi:
# 與WSGI一樣是一種通信協議，它是uWSGI服務器的獨佔協議,用於定義傳輸信息的類型
#uWSGI:
# 是一個web服務器,實現了WSGI協議,uWSGI協議,http協議,
#1.wsgi,請求封裝後交給web框架 （Flask、Django）
#2.中間件，對請求進行校驗或在請求對象中添加其他相關數據，例如：csrf、request.session -
#3.路由匹配 根據瀏覽器發送的不同url去匹配不同的視圖函數
#4.視圖函數，在視圖函數中進行業務邏輯的處理，可能涉及到：orm、templates => 渲染 -
#5.中間件，對響應的數據進行處理。
#6.wsgi,將響應的內容發送給瀏覽器。
#FBV和CBV本質是一樣的
#基於函數的視圖叫做FBV，基於類的視圖叫做CBV
#在python中使用CBV的優點：
#1.提高了代碼的複用性，可以使用面嚮對象的技術，比如Mixin（多繼承）
#2.可以用不同的函數針對不同的HTTP方法處理，而不是通過很多if判斷，提高代碼可讀性
#引入method_decorator模塊
#1.直接在類上加裝飾器
#@method_decorator(test,name='dispatch')
#class Loginview(View):
# pass
#2.直接在處理的函數前加裝飾器
#@method_decorator(test)
# def post(self,request,*args,**kwargs):pass
#MVC軟件系統分爲三個基本部分：模型(Model)、視圖(View)和控制器(Controller)
#Model：負責業務對象與數據庫的映射(ORM)
#View：負責與用戶的交互
#Control：接受用戶的輸入調用模型和視圖完成用戶的請求
#Django框架的MTV設計模式借鑑了MVC框架的思想,三部分爲：Model、Template和View
#Model(模型)：負責業務對象與數據庫的對象(ORM)
#Template(模版)：負責如何把頁面展示給用戶
#View(視圖)：負責業務邏輯，並在適當的時候調用Model和Template
#此外,Django還有一個urls分發器,
#它將一個個URL的頁面請求分發給不同的view處理,view再調用相應的Model和Template
#用於反向解析路由,相當於給url取個別名，只要這個名字不變,即使對應的url改變
#通過該名字也能找到該條url
#1.Admin是對model中對應的數據表進行增刪改查提供的組件
#2.model組件：負責操作數據庫
#3.form組件：1.生成HTML代碼2.數據有效性校驗3校驗信息返回並展示
#4.ModelForm組件即用於數據庫操作,也可用於用戶請求的驗證
#中間件是介於request與response處理之間的一道處理過程,用於在全局範圍內改變Django的輸入和輸出。
#簡單的來說中間件是幫助我們在視圖函數執行之前和執行之後都可以做一些額外的操作
#例如：
#1.Django項目中默認啓用了csrf保護,每次請求時通過CSRF中間件檢查請求中是否有正確#token值
#2.當用戶在頁面上發送請求時，通過自定義的認證中間件，判斷用戶是否已經登陸，未登陸就去登陸。
#3.當有用戶請求過來時，判斷用戶是否在白名單或者在黑名單裏
#1.process_request : 請求進來時,權限認證
#2.process_view : 路由匹配之後,能夠得到視圖函數
#3.process_exception : 異常時執行
#4.process_template_responseprocess : 模板渲染時執行
#5.process_response : 請求有響應時執行
#class WSGIHandler(base.BaseHandler):
# request = self.request_class(environ)
#請求走到WSGIHandler類的時候，執行__cell__方法，將environ封裝成了request
#1.使用HttpResponseRedirect
#from django.http import HttpResponseRedirect
#2.使用redirect和reverse
#狀態碼：301和302
#301和302的區別：
#相同點：都表示重定向，瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址
#不同點：
#301比較常用的場景是使用域名跳轉。比如，我們訪問 http://www.baidu.com 會跳轉到
https://www.baidu.com
#表示舊地址A的資源已經被永久地移除了
#302用來做臨時跳轉，比如未登陸的用戶訪問用戶中心重定向到登錄頁面。表示舊地址A的資源還在
（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B
#-- XSS攻擊是向網頁中注入惡意腳本，用在用戶瀏覽網頁時，在用戶瀏覽器中執行惡意腳本的攻擊。
# -- XSS分類，反射型xss ，存儲型xss
# -- 反射型xss又稱爲非持久型xss，攻擊者通過電子郵件等方式將包含注入腳本的鏈接發送給受害者，
# 受害者通過點擊鏈接，執行注入腳本，達到攻擊目的。
# -- 持久型xss跟反射型的最大不同是攻擊腳本將被永久的存放在目標服務器的數據庫和文件中，
多見於論壇
# 攻擊腳本連同正常信息一同注入到帖子內容當中，當瀏覽這個被注入惡意腳本的帖子的時候，
惡意腳本會被執行
# -- 防範措施 1 輸入過濾 2 輸出編碼 3 cookie防盜
# 1，輸入過濾 用戶輸入進行檢測 不允許帶有js代碼
# 2，輸出編碼 就是把我們的腳本代碼變成字符串形式輸出出來
# 3，cookie加密
#向頁面注入惡意的代碼,這些代碼被瀏覽器執行
#XSS攻擊能做些什麼：
# 1.竊取cookies
# 2.讀取用戶未公開的資料，如果：郵件列表或者內容、系統的客戶資料，聯繫人列表
#解決方法:
# 1.客戶度端：表單提交之前或者url傳遞之前,對需要的參數進行過濾
# 2.服務器端：檢查用戶輸入的內容是否有非法內容
#第一步：django第一次響應來自某個客戶端的請求時,後端隨機產生一個token值，把這個token保存在
SESSION狀態中;同時,後端把這個token放到cookie中交給前端頁面；
#第二步：下次前端需要發起請求（比如發帖）的時候把這個token值加入到請求數據或者頭信息中,一起
傳給後端；Cookies:{csrftoken:xxxxx}
#第三步：後端校驗前端請求帶過來的token和SESSION裏的token是否一致；
#1.後端將csrftoken傳到前端，發送post請求時攜帶這個值發送
data: {
csrfmiddlewaretoken: '{{ csrf_token }}'
},
#2.獲取form中隱藏標籤的csrftoken值，加入到請求數據中傳給後端
data: {
csrfmiddlewaretoken:$('[name="csrfmiddlewaretoken"]').val()
},
#3.cookie中存在csrftoken,將csrftoken值放到請求頭中
headers:{ "X-CSRFtoken":$.cookie("csrftoken")}，
#1.runserver方法是調試 Django 時經常用到的運行方式，它使用Django自帶的
#WSGI Server 運行，主要在測試和開發中使用，並且 runserver 開啓的方式也是單進程 。
#2.uWSGI是一個Web服務器，它實現了WSGI協議、uwsgi、http 等協議。注意uwsgi是一種通信協議，
而uWSGI是實現uwsgi協議和WSGI協議的 Web 服務器。
#uWSGI具有超快的性能、低內存佔用和多app管理等優點，並且搭配着Nginx就是一個生產環境了，能夠
將用戶訪問請求與應用 app 隔離開，實現真正的部署 。
#相比來講，支持的併發量更高，方便管理多進程，發揮多核的優勢，提升性能。
#1.cookie:
# cookie是保存在瀏覽器端的鍵值對,可以用來做用戶認證
#2.session：
# 將用戶的會話信息保存在服務端,key值是隨機產生的自符串,value值時session的內容
# 依賴於cookie將每個用戶的隨機字符串保存到用戶瀏覽器上
#Django中session默認保存在數據庫中：django_session表
#flask,session默認將加密的數據寫在用戶的cookie中
#<1> all(): 查詢所有結果
#<2> filter(**kwargs): 它包含了與所給篩選條件相匹配的對象。獲取不到返回None
#<3> get(**kwargs): 返回與所給篩選條件相匹配的對象，返回結果有且只有一個。獲取不到會
抱胸
#如果符合篩選條件的對象超過一個或者沒有都會拋出錯誤。
#<4> exclude(**kwargs): 它包含了與所給篩選條件不匹配的對象
#<5> order_by(*field): 對查詢結果排序
#<6> reverse(): 對查詢結果反向排序
#<8> count(): 返回數據庫中匹配查詢(QuerySet)的對象數量。
#<9> first(): 返回第一條記錄
#<10> last(): 返回最後一條記錄
#<11> exists(): 如果QuerySet包含數據，就返回True，否則返回False
#<12> values(*field): 返回一個ValueQuerySet——一個特殊的QuerySet，運行後得到的並不是一
系model的實例化對象，而是一個可迭代的字典序列
#<13> values_list(*field): 它與values()非常相似，它返回的是一個元組序列，values返回的是一個
字典序列
#<14> distinct(): 從返回結果中剔除重複紀錄
#only:從數據庫中只取指定字段的內容
#defer：指定字段的內容不被檢索
#有外鍵存在時，可以很好的減少數據庫請求的次數,提高性能
#select_related通過多表join關聯查詢,一次性獲得所有數據,只執行一次SQL查詢
#prefetch_related分別查詢每個表,然後根據它們之間的關係進行處理,執行兩次查詢
python面試基礎知識(二) python面試基礎知識(四) 網絡部分
