1、先從網絡模型的層面：
cilent與server通過http協議通訊，http協議屬於應用層協議，http基於tcp協議，所以cilent與server主要通過socket進行通訊；tcp屬於運輸層協議，如果走https還需要會話層TLS、SSL等協議；同時還需要DNS域名解析等；傳輸層之下網絡層，這里主要是路由協議OSPF、RIP等進行路由轉發之類的。再向下數據鏈路層主要是ARP、RARP協議完成IP和MAC地址的互解析，再向下到最底層物理層基本就是IEEE802.X等協議進行數據比特流轉成高低電瓶的一些定義等等。
http：協議無狀態，基於TCP，屬於應用層協議
DNS：域名解析系統，通過域名或主機名，最終得到該域名或主機名對應的IP地址的過程叫做域名解析(RDNS就是將IP地址反向查詢為域名，成為反向域名解析)，DNS協議運行在UDP協議之上，使用端口號53。DNS會有一些策略將靜態的東西直接返回給瀏覽器，只有動態部分才繼續向后面傳遞。
SSL：安全套接字協議、TSL：安全傳輸層協議，在傳輸層上給非安全的應用層協議提供加密保護，比如https
TCP：傳輸控制協議，屬於傳輸層協議
OSPF：優先開放最短路徑。基於鏈路狀態的自治內部路由協議，進行路由轉發。
ARP：地址解析協議，工作在數據鏈路層，ARP解決的是同一個局域網上的主機或者路由器的IP地址映射問題。
RARP：反向地址解析協議，負責將局域網中主機的物理地址轉換為Ip地址。
當瀏覽器發出請求，首先進行數據封包，然后數據鏈路層解析IP與MAC地址的映射，查找ARP表，然后找到對應目標路由器，路由器收到數據報，通過DNS協議解析的目標IP，進行路由尋址，到達傳輸層，傳輸層進行TCP三次握手、四次揮手建立和斷開連接，再進入應用層，http進行數據交換。
DNS域名解析如下(本機向本地域名使用遞歸查詢，本地域名向根域名使用迭代查詢)：
2、應用層方面
數據交換主要通過http/https協議。http協議是無狀態協議，這里可以談一下post和get兩種方式：
get方式：是以實體的方式得到有請求URL所指定資源的信息，如果請求URL只是一個數據產生的過程，那么最終要在響應實體中返回的是處理過程的結果所指向的資源，而不是處理過程的描述。
post方式：用來向目的服務器發出請求，要求接受被附在請求后的實體，並把它當做請求隊列中請求URI所指定資源的附加新子項，post被設計成統一的方法實現下列功能：
① 對象有資源的解釋；
② 向電子公告欄、新聞組、郵件列表或類似討論組發信息；
③ 提交數據塊
④ 通過附加操作來擴充數據庫
get是向服務器發索取數據的一種請求，而psot是向服務器提交數據的一種請求，要提交的數據位於信息頭后面的實體中
post和get的區別有：
① 安全性問題；在客戶端，get方式再通過url提交數據，數據在url中可以看到；post方式，數據放置在html的header內提交。
② get方式提交數據最多只有1024字節，而post方式則沒有限制。
③ 安全的和冪等的。所謂安全的意味着該操作用於獲取信息而非修改信息。冪等的意味着對同一 URL 的多個請求應該返回同樣的結果。完整的定義並不像看起來那樣嚴格。換句話說，GET 請求一般不應產生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。POST 請求就不那么輕松了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST 請求實現，因為在注解提交之后站點已經不同了（比方說文章下面出現一條注解）。
通過https進行數據交換，一般通過post方式，https本身並非協議，而是標准的HTTP協議架在SSL/TLS協議之上的一種結構。由於HTTP協議是基於TCP/IP進行通訊的，所以HTTPS必須暴露IP和端口，這部分不加密。
https在傳輸數據前需要客戶端與服務器進行一次握手，在握手的過程中將確立雙方加密傳輸數據的密碼信息。握手的時候一般使用非對稱加密和哈希算法，握手后數據傳輸才用對稱加密。握手過程如下：
1、瀏覽器將自己支持的一套加密規則發送給網站。
2、網站從中選出一組加密算法和hash算法，並將自己的身份信息用證書的形式發送給瀏覽器。證書里面包括了網站地址，加密公約，以及證書的頒發機構等信息。
3、獲得網站證書后瀏覽器要做以下工作：
① 驗證證書的合法性(頒發證書機構是否合法、證書是否過期、證書中地址是否與正在訪問的地址一致)：如果證書受信任，則瀏覽器里面會顯示一個小鎖頭，否則會給出證書不受信任的提示。
② 如何證書受信任，或者用戶接受了不受信任的證書，瀏覽器會生成一串隨機密碼，用最開始約定好的hash方式，把握手消息hash值，然后用證書中提供的公鑰加密“握手消息+握手消息hash值”發送給服務器。
③ 服務端拿到客戶端傳來密碼，用自己的私鑰來解密握手消息取出隨機密碼，再用隨機數密碼解密握手消息與hash值，並與傳過來的hash值做對比確認是否一致。然后服務端自己也生成一個隨機密碼加密一段握手消息(握手消息+握手消息hash值)給客戶端。
④ 客戶端用隨機數解密並計算握手消息hash，如果與服務器發出hash一致，此時握手過程結束，之后的所有通信數據將有之前瀏覽器和服務器生成的隨機碼生成的一個新的隨機密碼並利用對稱加密算法進行加密。利用客戶端和服務端的隨機碼來生成數據傳輸的隨機碼是為了防止寫死的假隨機碼帶來的安全隱患，使用對稱加密是因為對稱加密的加密加密過程比非對稱快得多。
非對稱加密算法：RSA DSA DSS
對稱加密：AES RC4 3DES HASH
算法：MD5 SHA1 SHA256
3、服務器方面(Ngin為例)
server 這邊 Nginx 拿到請求，進行一些驗證，比如黑名單攔截之類的，然后 Nginx 直接處理靜態資源請求，其他請求 Nginx 轉發給后端服務器，這里我用 uWSGI, 他們之間通過 uwsgi 協議通訊，uWSGI 拿到請求，可以進行一些邏輯， 驗證黑名單、判斷爬蟲等，根據 wsgi 標准，把拿到的 environs 參數扔給 Django ，Django 根據 wsgi 標准接收請求和 env， 然后開始 startresponse ，先跑 Django 相關后台邏輯，Django 拿到請求執行 request middleware 內的相關邏輯，然后路由到相應 view 執行邏輯，出錯執行 exception middleware 相關邏輯，接着 response 前執行 response middleware 邏輯，最后通過 wsgi 標准構造 response， 拿到需要返回的東西，設置一些 headers，或者 cookies 之類的，最后 finishresponse 返回，再通過 uWSGI 給 Nginx ，Nginx 返回給瀏覽器。
參考文章：
https://blog.csdn.net/w_rcss/article/details/79890294
https://www.cnblogs.com/xiexj/p/6439775.html
https://www.cnblogs.com/yifugui/p/8430707.html