複習-網路程式設計和併發程式設計
阿新 • • 發佈：2018-11-23
網路程式設計
簡述OSI 7層模型。
1）應用層 應用層 應用層 使用者進層 表示層 會話層 Socket是應用層與TCP/IP協議族通訊的中間軟體抽象層，它是一組介面。 在設計模式中，Socket其實就是一個門面模式，他把複雜的TCP/IP協議族隱藏在Socket介面後面。 對使用者來說，一組簡單的介面就是全部，以符合制定的協議。 2）傳輸層 傳輸層 傳輸層 TCP協議/UDP協議3）網路層 網路層 網路層 ICPM/IP協議 4)資料鏈路層 資料鏈路層 ARP/硬體介面/RARP/arp協議 5)物理層 物理層
TCP 三次握手 和 四次揮手。
建立連線協議（三次握手） （1）客戶端傳送一個帶SYN標誌的TCP報文到伺服器 （2） 伺服器端迴應客戶端的 （3） 客戶必須再次迴應服務段一個ACK報文 連線終止協議（四次揮手） （1） TCP客戶端傳送一個FIN，用來關閉客戶到伺服器的資料傳送 （2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1 （3） 伺服器關閉客戶端的連線，傳送一個FIN給客戶端 （4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1
TCP和UDP區別？
TCP 可靠的、面向連線的協議、傳輸效率低、雙全工通訊（傳送快取/接受快取）、面向位元組流。 使用TCP的應用：Web瀏覽器/電子郵件/檔案傳輸程式 UDP 不可靠、無連線的服務，傳輸效率高（傳送前延時小），一對一、一對多、多對一、多對多、面向報文，盡最大努力服務，無擁塞控制。 使用UDP的應用：域名系統（DNS）/視訊流/IP語音
黏包現象
基於tcp協議出現的黏包現象，指的是：傳送過來的一整條資訊，由於server端沒有及時接收，導致後來傳送的資料和之前沒有接收完的資料黏在了一起。 造成這種現象的的原因是：緩衝區+連續傳送資料 解決：struct模組實現資料封包：頭(資料長度)+資料
Http協議
- 基於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，201、202 - 300 - 400 - 500 - 響應體 - 使用者看到的內容。
Websocket協議（伺服器向客戶端主動推送訊息）
- 基於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位元組）+資料 - 返回資料加密。
Http協議與websocket協議的區別：
1.連線方式的不同：http一次請求一次響應就斷開連線，但是websocket連線之後不斷開 2.資料加密：http傳送接收資料不加密，但是websocket進行傳送資料要加密。 3.握手資訊：http連線之後不需要握手，websocket連線之後需要先進行握手。
Https
到現在為止，我們已瞭解到 HTTP 具有相當優秀和方便的一面，然而 HTTP 並非只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉如下。 1、通訊使用明文（ 不加密） ， 內容可能會被竊聽 2、不驗證通訊方的身份， 因此有可能遭遇偽裝 3、無法證明報文的完整性， 所以有可能已遭篡改 這些問題不僅在 HTTP 上出現，其他未加密的協議中也會存在這類問題。 除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 伺服器和特定的 Web 瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等程式語言開發的 Web 應用也可能存在安全漏洞。
所以就有了https
在 HTTP 協議中有可能存在資訊竊聽或身份偽裝等安全問題。使用 HTTPS 通訊機制可以有效地防止這些問題。
HTTP+ 加密 + 認證 + 完整性保護 =HTTPS
HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS
如果在 HTTP 協議通訊過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來說，伺服器也好，客戶端也好，都是沒有辦法確認通訊方的。
因為很有可能並不是和原本預想的通訊方在實際通訊。並且還需要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱為 HTTPS （HTTP Secure）。
經常會在 Web 的登入頁面和購物結算介面等使用 HTTPS 通訊。使用 HTTPS 通訊時，不再用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web網站時，瀏覽器的位址列內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。
程序、執行緒、協程區別？
程序，計算機中資源分配的最小單元。 執行緒，計算機cpu排程的最小單元。一個程序中中可以建立多線執行緒，程序用於維護一個空間，執行緒則在此空間內進行工作。 協程，在計算機中不存在，是由開發者人為創造出來的，也可以稱為“微執行緒”。（人為控制一個執行緒在函式見進行切換執行），單純的協程無法提供效能。 協程 !=> 效能提高 協程 + IO切換 => 效能提高
GIL鎖
1、GIL，全域性直譯器鎖。
2、GIL鎖，保證一個程序中同一時刻只有一個執行緒可以被CPU排程。
Python： 計算型的操作（利用cpu）：多程序。 IO性操作：多執行緒、協程 應用： 爬蟲，程序+協程。 注意：C Python中才有GIL。
GIL鎖可以保證資料安全嗎？
無法保證資料安全，想要資料安全必須使用：Lock、RLock、Condition、Event...
IO多路複用？
為什麼要用I/O多路複用：就是因為在單執行緒中，多個伺服器無法監聽多個客戶端的請求，所以要用。 作用：幫助開發者監聽多個“IO控制代碼”發生變化（連線、收發部署）。簡單來說就是（幫助開發者監聽多個socket是否發生變化） 實現IO多路複用： windows： select linux： select， 個數最多1024個;輪詢檢測。 poll，輪詢檢測。（一個一個挨著問）（水平觸發） epoll，回自動調通知。（邊緣觸發） 應用場景： wsgiref，socket uwsgi，socket+IO多路複用 nginx，IO多路複用
網路程式設計
簡述OSI 7層模型。
1）應用層 應用層 應用層 使用者進層 表示層 會話層 Socket是應用層與TCP/IP協議族通訊的中間軟體抽象層，它是一組介面。 在設計模式中，Socket其實就是一個門面模式，他把複雜的TCP/IP協議族隱藏在Socket介面後面。 對使用者來說，一組簡單的介面就是全部，以符合制定的協議。 2）傳輸層 傳輸層 傳輸層 TCP協議/UDP協議 3）網路層 網路層 網路層 ICPM/IP協議 4)資料鏈路層 資料鏈路層 ARP/硬體介面/RARP/arp協議 5)物理層 物理層
TCP 三次握手 和 四次揮手。
建立連線協議（三次握手） （1）客戶端傳送一個帶SYN標誌的TCP報文到伺服器 （2） 伺服器端迴應客戶端的 （3） 客戶必須再次迴應服務段一個ACK報文 連線終止協議（四次揮手） （1） TCP客戶端傳送一個FIN，用來關閉客戶到伺服器的資料傳送 （2） 伺服器收到這個FIN，它發回一個ACK，確認序號為收到的序號加1 （3） 伺服器關閉客戶端的連線，傳送一個FIN給客戶端 （4） 客戶段發回ACK報文確認，並將確認序號設定為收到序號加1
TCP和UDP區別？
TCP 可靠的、面向連線的協議、傳輸效率低、雙全工通訊（傳送快取/接受快取）、面向位元組流。 使用TCP的應用：Web瀏覽器/電子郵件/檔案傳輸程式 UDP 不可靠、無連線的服務，傳輸效率高（傳送前延時小），一對一、一對多、多對一、多對多、面向報文，盡最大努力服務，無擁塞控制。 使用UDP的應用：域名系統（DNS）/視訊流/IP語音
黏包現象
基於tcp協議出現的黏包現象，指的是：傳送過來的一整條資訊，由於server端沒有及時接收，導致後來傳送的資料和之前沒有接收完的資料黏在了一起。 造成這種現象的的原因是：緩衝區+連續傳送資料 解決：struct模組實現資料封包：頭(資料長度)+資料
Http協議
- 基於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，201、202 - 300 - 400 - 500 - 響應體 - 使用者看到的內容。
Websocket協議（伺服器向客戶端主動推送訊息）
- 基於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位元組）+資料 - 返回資料加密。
Http協議與websocket協議的區別：
1.連線方式的不同：http一次請求一次響應就斷開連線，但是websocket連線之後不斷開 2.資料加密：http傳送接收資料不加密，但是websocket進行傳送資料要加密。 3.握手資訊：http連線之後不需要握手，websocket連線之後需要先進行握手。
Https
到現在為止，我們已瞭解到 HTTP 具有相當優秀和方便的一面，然而 HTTP 並非只有好的一面，事物皆具兩面性，它也是有不足之處的。HTTP 主要有這些不足，例舉如下。 1、通訊使用明文（ 不加密） ， 內容可能會被竊聽 2、不驗證通訊方的身份， 因此有可能遭遇偽裝 3、無法證明報文的完整性， 所以有可能已遭篡改 這些問題不僅在 HTTP 上出現，其他未加密的協議中也會存在這類問題。 除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 伺服器和特定的 Web 瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等程式語言開發的 Web 應用也可能存在安全漏洞。
所以就有了https
在 HTTP 協議中有可能存在資訊竊聽或身份偽裝等安全問題。使用 HTTPS 通訊機制可以有效地防止這些問題。
HTTP+ 加密 + 認證 + 完整性保護 =HTTPS
HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS
如果在 HTTP 協議通訊過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
另外，對於 HTTP 來說，伺服器也好，客戶端也好，都是沒有辦法確認通訊方的。
因為很有可能並不是和原本預想的通訊方在實際通訊。並且還需要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。
為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把添加了加密及認證機制的 HTTP 稱為 HTTPS （HTTP Secure）。
經常會在 Web 的登入頁面和購物結算介面等使用 HTTPS 通訊。使用 HTTPS 通訊時，不再用 http://，而是改用 https://。另外，當瀏覽器訪問 HTTPS 通訊有效的 Web網站時，瀏覽器的位址列內會出現一個帶鎖的標記。對 HTTPS 的顯示方式會因瀏覽器的不同而有所改變。
程序、執行緒、協程區別？
程序，計算機中資源分配的最小單元。 執行緒，計算機cpu排程的最小單元。一個程序中中可以建立多線執行緒，程序用於維護一個空間，執行緒則在此空間內進行工作。 協程，在計算機中不存在，是由開發者人為創造出來的，也可以稱為“微執行緒”。（人為控制一個執行緒在函式見進行切換執行），單純的協程無法提供效能。 協程 !=> 效能提高 協程 + IO切換 => 效能提高
GIL鎖
1、GIL，全域性直譯器鎖。
2、GIL鎖，保證一個程序中同一時刻只有一個執行緒可以被CPU排程。
Python： 計算型的操作（利用cpu）：多程序。 IO性操作：多執行緒、協程 應用： 爬蟲，程序+協程。 注意：C Python中才有GIL。
GIL鎖可以保證資料安全嗎？
無法保證資料安全，想要資料安全必須使用：Lock、RLock、Condition、Event...
IO多路複用？
為什麼要用I/O多路複用：就是因為在單執行緒中，多個伺服器無法監聽多個客戶端的請求，所以要用。 作用：幫助開發者監聽多個“IO控制代碼”發生變化（連線、收發部署）。簡單來說就是（幫助開發者監聽多個socket是否發生變化） 實現IO多路複用： windows： select linux： select， 個數最多1024個;輪詢檢測。 poll，輪詢檢測。（一個一個挨著問）（水平觸發） epoll，回自動調通知。（邊緣觸發） 應用場景： wsgiref，socket uwsgi，socket+IO多路複用 nginx，IO多路複用