1)應用層 應用層 應用層 用戶進層 表示層 會話層 Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層,它是一組接口。 在設計模式中,Socket其實就是一個門面模式,他把複雜的TCP/IP協議族隱藏在Socket接口後面。 對用戶來講,一組簡單的接口就是所有,以符合制定的協議。 2)傳輸層 傳輸層 傳輸層 TCP協議/UDP協議 3)網絡層 網絡層 網絡層 ICPM/IP協議 4)數據鏈路層 數據鏈路層 ARP/硬件接口/RARP/arp協議 5)物理層 物理層
創建鏈接協議(三次握手) (1)客戶端發送一個帶SYN標誌的TCP報文到服務器 (2) 服務器端迴應客戶端的 (3) 客戶必須再次迴應服務段一個ACK報文 鏈接終止協議(四次揮手) (1) TCP客戶端發送一個FIN,用來關閉客戶到服務器的數據傳送 (2) 服務器收到這個FIN,它發回一個ACK,確認序號爲收到的序號加1 (3) 服務器關閉客戶端的鏈接,發送一個FIN給客戶端 (4) 客戶段發回ACK報文確認,並將確認序號設置爲收到序號加1
TCP 可靠的、面向鏈接的協議、傳輸效率低、雙全工通訊(發送緩存/接受緩存)、面向字節流。 使用TCP的應用:Web瀏覽器/電子郵件/文件傳輸程序 UDP 不可靠、無鏈接的服務,傳輸效率高(發送前延時小),一對1、一對多、多對1、多對多、面向報文,盡最大努力服務,無擁塞控制。 使用UDP的應用:域名系統(DNS)/視頻流/IP語音
基於tcp協議出現的黏包現象,指的是:發送過來的一整條信息,因爲server端沒有及時接收,致使後來發送的數據和以前沒有接收完的數據黏在了一塊兒。 形成這種現象的的緣由是:緩衝區+連續發送數據 解決:struct模塊實現數據封包:頭(數據長度)+數據
- 基於TCP協議實現 - 一次請求一次響應後斷開鏈接。 - 格式: 請求 - 請求頭 - user-agent,告訴服務器個人設備信息。 - accept,告訴服務器我能接受返回數據的格式。 - content-type,告訴服務器我發送的請求體的格式(數據類型) - cookies,瀏覽器端的cookie信息。 - host,主機信息 - Connection,值keepalive,告訴服務器保持鏈接狀態。 - referer,將瀏覽器上一次訪問的地址發送給服務器(能夠作圖片防盜鏈)。 - 請求方法:GET/POST/DELETE/PUT/PATCH/OPTIONS - 請求體 "GET /yuanchenqi/articles/9993188.html http1.1\r\nuser-agent:k1\r\nhost:cnblogs.com...\r\n\r\n" "POST /yuanchenqi/articles/9993188.html http1.1\r\nuser-agent:k1\r\nhost:cnblogs.com...\r\n\r\nk1=123&k2=456" 響應: - 響應頭 - location,讓用戶重定向到指定url。 - set-cookies,給用戶瀏覽器設置cookie。 - 狀態碼: - 200,20一、202 - 300 - 400 - 500 - 響應體 - 用戶看到的內容。
- 基於TCP實現的協議。 - 鏈接以後不斷開 - 鏈接以後須要先進行握手 - 獲取客戶端發送過來的隨機字符串:在請求Sec-WebSocket-Key中獲取,如:mnwFxiOlctXFN/DeMt1Amg== - base64.b64encode(hashlib.sha1(mnwFxiOlctXFN/DeMt1Amg== + magic string)) - 返回給客戶瀏覽器,在響應頭中設置:Sec-WebSocket-Accept: 加密後的值 - 握手經過後,進行收發數據(加密): - 127: 2+8字節 MASK(4字節)+數據 - 126: 2+2字節 MASK(4字節)+數據 - 125: 2字節 MASK(4字節)+數據 - 返回數據加密。
1.鏈接方式的不一樣:http一次請求一次響應就斷開鏈接,可是websocket鏈接以後不斷開 2.數據加密:http發送接收數據不加密,可是websocket進行發送數據要加密。 3.握手信息:http鏈接以後不須要握手,websocket鏈接以後須要先進行握手。
到如今爲止,咱們已瞭解到 HTTP 具備至關優秀和方便的一面,然而 HTTP 並不是只有好的一面,事物皆具兩面性,它也是有不足之處的。HTTP 主要有這些不足,例舉以下。 1、通訊使用明文( 不加密) , 內容可能會被竊聽 2、不驗證通訊方的身份, 所以有可能遭遇假裝 3、沒法證實報文的完整性, 因此有可能已遭篡改 這些問題不只在 HTTP 上出現,其餘未加密的協議中也會存在這類問題。 除此以外,HTTP 自己還有不少缺點。並且,還有像某些特定的 Web 服務器和特定的 Web 瀏覽器在實際應用中存在的不足(也能夠說成是脆弱性或安全漏洞),另外,用 Java 和 PHP 等編程語言開發的 Web 應用也可能存在安全漏洞。
因此就有了httpshtml
在 HTTP 協議中有可能存在信息竊聽或身份假裝等安全問題。使用 HTTPS 通訊機制能夠有效地防止這些問題。
HTTP+ 加密 + 認證 + 完整性保護 =HTTPS
HTTP 加上加密處理和認證以及完整性保護後便是 HTTPS
若是在 HTTP 協議通訊過程當中使用未經加密的明文,好比在 Web 頁面中輸入信用卡號,若是這條通訊線路遭到竊聽,那麼信用卡號就暴露了。
另外,對於 HTTP 來講,服務器也好,客戶端也好,都是沒有辦法確認通訊方的。
由於頗有可能並非和本來預想的通訊方在實際通訊。而且還須要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
爲了統一解決上述這些問題,須要在 HTTP 上再加入加密處理和認證等機制。咱們把添加了加密及認證機制的 HTTP 稱爲 HTTPS (HTTP Secure)。
常常會在 Web 的登陸頁面和購物結算界面等使用 HTTPS 通訊。使用 HTTPS 通訊時,再也不用 http://,而是改用 https://。另外,當瀏覽器訪問 HTTPS 通訊有效的 Web網站時,瀏覽器的地址欄內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不一樣而有所改變。
進程,計算機中資源分配的最小單元。 線程,計算機cpu調度的最小單元。一個進程中中能夠建立多線線程,進程用於維護一個空間,線程則在此空間內進行工做。 協程,在計算機中不存在,是由開發者人爲創造出來的,也能夠稱爲「微線程」。(人爲控制一個線程在函數見進行切換執行),單純的協程沒法提供性能。 協程 !=> 性能提升 協程 + IO切換 => 性能提升
1、GIL,全局解釋器鎖。
二、GIL鎖,保證一個進程中同一時刻只有一個線程能夠被CPU調度。
Python: 計算型的操做(利用cpu):多進程。 IO性操做:多線程、協程 應用: 爬蟲,進程+協程。 注意:C Python中才有GIL。
沒法保證數據安全,想要數據安全必須使用:Lock、RLock、Condition、Event...
爲何要用I/O多路複用:就是由於在單線程中,多個服務器沒法監聽多個客戶端的請求,因此要用。 做用:幫助開發者監聽多個「IO句柄」發生變化(鏈接、收發部署)。簡單來講就是(幫助開發者監聽多個socket是否發生變化) 實現IO多路複用: windows: select linux: select, 個數最多1024個;輪詢檢測。 poll,輪詢檢測。(一個一個挨着問)(水平觸發) epoll,回自動調通知。(邊緣觸發) 應用場景: wsgiref,socket uwsgi,socket+IO多路複用 nginx,IO多路複用
隊列、管道、消息隊列