溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下python中計算機網絡相關知識點有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
OSI分層（7層） 物理層、數據鏈路層、網絡層、運輸層、會話層、表示層、應用層 TCP/IP分層（4層） 網絡接口層、網絡層、運輸層、應用層 五層協議（5層） 物理層、數據鏈路層、網絡層、運輸層、應用層
TCP提供面向連接的、可靠的數據流傳輸，而UDP提供的是非面向連接的、不可靠的數據流傳輸
TCP對應的協議：
（1） FTP：定義了文件傳輸協議，使用21端口。
（2） Telnet：一種用于遠程登陸的端口，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基于DOS模式下的通信服務。
（3） SMTP：郵件傳送協議，用于發送郵件。服務器開放的是25號端口。
（4） POP3：它是和SMTP對應，POP3用于接收郵件。POP3協議所用的是110端口。
（5）HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。
UDP對應的協議：
（1） DNS：用于域名解析服務，將域名地址轉換為IP地址。DNS用的是53號端口。
（2） SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由于網絡設備很多，無連接的服務就體現出其優勢。
（3） TFTP(Trival File Transfer Protocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。
評論
第一次握手：客戶端發送syn包(syn=x)到服務器，并進入SYN_SEND狀態，等待服務器確認；
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=x+1），同時自己也發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；
第三次握手：客戶端收到服務器的SYN＋ACK包，向服務器發送確認包ACK(ack=y+1)，此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢后，客戶端與服務器才正式開始傳送數據。理想狀態下，TCP連接一旦建立
與建立連接的“三次握手”類似，斷開一個TCP連接則需要“四次揮手”。
第一次揮手：主動關閉方發送一個FIN，用來關閉主動方到被動關閉方的數據傳送，也就是主動關閉方告訴被動關閉方：我已經不會再給你發數據了(當然，在fin包之前發送出去的數據，如果沒有收到對應的ack確認報文，主動關閉方依然會重發這些數據)，但是，此時主動關閉方還可以接受數據。
第二次揮手：被動關閉方收到FIN包后，發送一個ACK給對方，確認序號為收到序號+1（與SYN相同，一個FIN占用一個序號）。
第三次揮手：被動關閉方發送一個FIN，用來關閉被動關閉方到主動關閉方的數據傳送，也就是告訴主動關閉方，我的數據也發送完了，不會再給你發數據了。
第四次揮手：主動關閉方收到FIN后，發送一個ACK給被動關閉方，確認序號為收到序號+1，至此，完成四次揮手。
一、防止第四次揮手的報文段丟失，服務器端無法正常關閉。如果第四次揮手丟失，服務器端會重新發送第三次揮手的報文，請求斷開連接。
二、2MSL時間可以保證本次連接所有報文失效失效，防止“已失效的連接請求報文段”出現在本連接中，避免被服務器端認為是一個新的連接請求。
粘包產生原因：
先說TCP：由于TCP協議本身的機制（面向連接的可靠地協議-三次握手機制）客戶端與服務器會維持一個連接（Channel），數據在連接不斷開的情況下，可以持續不斷地將多個數據包發往服務器，但是如果發送的網絡數據包太小，那么他本身會啟用Nagle算法（可配置是否啟用）對較小的數據包進行合并（基于此，TCP的網絡延遲要UDP的高些）然后再發送（超時或者包大小足夠）。那么這樣的話，服務器在接收到消息（數據流）的時候就無法區分哪些數據包是客戶端自己分開發送的，這樣產生了粘包；服務器在接收到數據庫后，放到緩沖區中，如果消息沒有被及時從緩存區取走，下次在取數據的時候可能就會出現一次取出多個數據包的情況，造成粘包現象（確切來講，對于基于TCP協議的應用，不應用包來描述，而應 用 流來描述），個人認為服務器接收端產生的粘包應該與linux內核處理socket的方式 select輪詢機制的線性掃描頻度無關
現有的一些開源資料做了如下總結（常用的解決方案）：
一個是采用分隔符的方式，即我們在封裝要傳輸的數據包的時候，采用固定的符號作為結尾符（數據中不能含結尾符），這樣我們接收到數據后，如果出現結尾標識，即人為的將粘包分開，如果一個包中沒有出現結尾符，認為出現了分包，則等待下個包中出現后 組合成一個完整的數據包，這種方式適合于文本傳輸的數據，如采用/r/n之類的分隔符；
另一種是采用在數據包中添加長度的方式，即在數據包中的固定位置封裝數據包的長度信息（或可計算數據包總長度的信息），服務器接收到數據后，先是解析包長度，然后根據包長度截取數據包（此種方式常出現于自定義協議中），但是有個小問題就是如果客戶端第一個數據包數據長度封裝的有錯誤，那么很可能就會導致后面接收到的所有數據包都解析出錯（由于TCP建立連接后流式傳輸機制），只有客戶端關閉連接后重新打開才可以消除此問題，我在處理這個問題的時候對數據長度做了校驗，會適時的對接收到的有問題的包進行人為的丟棄處理（客戶端有自動重發機制，故而在應用層不會導致數據的不完整性）；
UDP不存在粘包問題，是由于UDP發送的時候，沒有經過Negal算法優化，不會將多個小包合并一次發送出去。另外，在UDP協議的接收端，采用了鏈式結構來記錄每一個到達的UDP包，這樣接收端應用程序一次recv只能從socket接收緩沖區中讀出一個數據包。也就是說，發送端send了幾次，接收端必須recv幾次（無論recv時指定了多大的緩沖區）。
什么是 close_wait：關閉 TCP 連接過程中，第 1 次揮手服務器接收客戶端的 FIN 報文段，第 2 次揮手時，服務器發送了 ACK 報文段之后，服務器會進入 close_wait 狀態。
（具體是第 2 次揮手還是第 3 次揮手時，是發送了 ACK 報文段還是 FIN 報文段之后，尚待考證）
過多的close_wait可能是什么原因：
程序問題：說的具體一點，服務器端的代碼，沒有寫 close 函數關閉 socket 連接，也就不會發出 FIN 報文段；或者出現死循環，服務器端的代碼永遠執行不到 close。 客戶機響應太慢或者 timeout 設置過小：。。。
Linux的網絡通信先后推出了select、poll、epoll三種模式。
select有以下三個問題：
（1）每次調用select，都需要把fd集合從用戶態拷貝到內核態，這個開銷在fd很多時會很大。
（2）同時每次調用select都需要在內核遍歷傳遞進來的所有fd，這個開銷在fd很多時也很大。
（3）select支持的文件描述符數量太小了，默認是1024。
poll解決了第三個問題，select保存描述符fd的數據結構是數組，poll改成了鏈表，突破了fd的個數限制。
但是第1和第2個問題依然存在。
epoll在poll的基礎上，又解決了前兩個問題：
（1）對第一個問題，epoll每次注冊新的事件到epoll句柄中時（在epoll_ctl中指定EPOLL_CTL_ADD），會把所有的fd拷貝進內核，而不是在epoll_wait的時候重復拷貝。這樣epoll保證了每個fd在整個過程中只會拷貝一次。
（2）對第二個問題，epoll單獨設置了一個就緒鏈表，當fd就緒(可讀/可寫)之后，放入就緒鏈表。epoll_wait只需要遍歷就緒鏈表，而不需要遍歷所有的fd，從而節省大量的CPU時間。
epoll有LT和ET兩種工作模式，默認工作模式是LT（水平觸發），高速工作模式是ET（邊緣觸發）。
LT是fd只要處于可讀或可寫狀態，就會通知用戶；ET只有不可讀變為可讀，或不可寫變為可寫之時，才會通知用戶。
ET對系統的調用，比LT要少得多，所以ET是高速工作模式，效率高很多。
用戶使用ET模式時，讀/寫fd的時候，必須連續讀/寫完（直到返回EAGAIN錯誤）。否則如果未讀/寫完，系統會認為狀態沒有變化，就不會再重復通知，這樣這個fd就死掉了。
21 ftp
22 ssh
23 telnet
53 dns
3306 mysql
redis 6079
80 http
443 https
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等。 一次HTTP操作稱為一個事務，其工作整個過程如下： 1 ) 、地址解析， 如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm 從中分解出協議名、主機名、端口、對象路徑等部分，對于我們的這個地址，解析得到的結果如下： 協議名：http 主機名：localhost.com 端口：8080 對象路徑：/index.htm 在這一步，需要域名系統DNS解析域名localhost.com,得主機的IP地址。 2）、封裝HTTP請求數據包 把以上部分結合本機自己的信息，封裝成一個HTTP請求數據包 3）封裝成TCP包，建立TCP連接（TCP的三次握手） 在HTTP工作開始之前，客戶機（Web瀏覽器）首先要通過網絡與服務器建立連接，該連接是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之后才能，才能進行更層協議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。這里是8080端口 4）客戶機發送請求命令 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可內容。 5）服務器響應 服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。 實體消息是服務器向瀏覽器發送頭信息后，它會發送一個空白行來表示頭信息的發送到此為結束，接著，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據 6）服務器關閉TCP連接 一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然后如果瀏覽器或者服務器在其頭信息加入了這行代碼 Connection:keep-alive
TCP連接在發送后將仍然保持打開狀態，于是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網絡帶寬。
請求報文HTTP請求報文由請求行、請求頭、空行和請求內容4個部分構成。
1、GET請求一般用去請求獲取數據，
POST一般作為發送數據到后臺時使用
2、GET請求也可傳參到后臺，但是其參數在瀏覽器的地址欄的url中可見，所以隱私性安全性較差，且參數長度也是有限制的
POST請求傳遞參數放在Request body中，不會在url中顯示，比GET要安全，且參數長度無限制
3、GET請求刷新瀏覽器或回退時沒有影響
POST回退時會重新提交數據請求
4、GET 請求可被緩存
POST 請求不會被緩存
5、GET 請求保留在瀏覽器歷史記錄中
POST 請求不會保留在瀏覽器歷史記錄中
6、GET 請求可被收藏為書簽
POST 不能被收藏為書簽
7、GET請求只能進行url編碼（application/x-www-form-urlencoded）
POST支持多種編碼方式（application/x-www-form-urlencoded 或 multipart/form-data。為二進制數據使用多重編碼。）
8、GET請求比較常見的方式是通過url地址欄請求
POST最常見是通過form表單發送數據請求
在HTTP 中〃狀態碼 301、302、401、403、404、500 、504的含義是；
301（永久移動）
請求的網頁已永久移動到新位置。服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。您應使用此代碼告訴 Googlebot 某個網頁或網站已永久移動到新位置。
302（臨時移動）
服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來響應以后的請求。此代碼與響應 GET 和 HEAD 請求的 301 代碼類似，會自動將請求者轉到不同的位置，但您不應使用此代碼來告訴 Googlebot 某個網頁或網站已經移動，因為 Googlebot 會繼續抓取原有位置并編制索引。
400（錯誤請求）
服務器不理解請求的語法。
401（未授權）
請求要求身份驗證。對于登錄后請求的網頁，服務器可能返回此響應。
403（禁止）
服務器拒絕請求。如果您在 Googlebot 嘗試抓取您網站上的有效網頁時看到此狀態碼（您可以在 Google 網站管理員工具診斷下的網絡抓取頁面上看到此信息），可能是您的服務器或主機拒絕了 Googlebot 訪問。
404（未找到）
服務器找不到請求的網頁。例如，對于服務器上不存在的網頁經常會返回此代碼。
如果您的網站上沒有 robots.txt 文件，而您在 Google 網站管理員工具“診斷”標簽的 robots.txt 頁上看到此狀態碼，則這是正確的狀態碼。但是，如果您有 robots.txt 文件而又看到此狀態碼，則說明您的 robots.txt 文件可能命名錯誤或位于錯誤的位置（該文件應當位于頂級域，名為 robots.txt）。
如果對于 Googlebot 抓取的網址看到此狀態碼（在”診斷”標簽的 HTTP 錯誤頁面上），則表示 Googlebot 跟隨的可能是另一個頁面的無效鏈接（是舊鏈接或輸入有誤的鏈接）。
500（服務器內部錯誤）
服務器遇到錯誤，無法完成請求。
501（尚未實施）
服務器不具備完成請求的功能。例如，服務器無法識別請求方法時可能會返回此代碼。
502（錯誤網關）
服務器作為網關或代理，從上游服務器收到無效響應。
503（服務不可用）
服務器目前無法使用（由于超載或停機維護）。通常，這只是暫時狀態。
http協議和https協議的區別：傳輸信息安全性不同、連接方式不同、端口不同、證書申請方式不同
一、傳輸信息安全性不同
1、http協議：是超文本傳輸協議，信息是明文傳輸。如果***者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息。
2、https協議：是具有安全性的ssl加密傳輸協議，為瀏覽器和服務器之間的通信加密，確保數據傳輸的安全。
http和https有什么區別?
http和https有什么區別?在windowsserver2003遠程中端服務里,windowsserver2003是一共支持2個遠程用戶同時連接還是默認支持兩個如果需要多個要付費呢?https怎么加密?如何解密?能說一下...
展開
我來答 分享
舉報
18個回答
#春節# 今年春節在家聚還是出去嗨？
憶江南憶夢
2019-08-08
http協議和https協議的區別：傳輸信息安全性不同、連接方式不同、端口不同、證書申請方式不同
一、傳輸信息安全性不同
1、http協議：是超文本傳輸協議，信息是明文傳輸。如果***者截取了Web瀏覽器和網站服務器之間的傳輸報文，就可以直接讀懂其中的信息。
2、https協議：是具有安全性的ssl加密傳輸協議，為瀏覽器和服務器之間的通信加密，確保數據傳輸的安全。
二、連接方式不同
1、http協議：http的連接很簡單，是無狀態的。
2、https協議：是由SSL＋HTTP協議構建的可進行加密傳輸、身份認證的網絡協議。
三、端口不同
1、http協議：使用的端口是80。
2、https協議：使用的端口是443．
四、證書申請方式不同
1、http協議：免費申請。
2、https協議：需要到ca申請證書，一般免費證書很少，需要交費。
.應用層：客戶端瀏覽器通過DNS解析到www.baidu.com的IP地址220.181.27.48，通過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到220.161.27.48，然后通過TCP進行封裝數據包，輸入到網絡層。
DNS解析IP:
HTTP訪問服務器：
2、傳輸層:在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。然后使用IP層的IP地址查找目的端。
3、客戶端的網絡層不用關心應用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達服務器，期間可能經過多個路由器，這些都是由路由器來完成的工作，通過查找路由表決定通過那個路徑到達服務器,其中用到路由選擇協議
路由選擇協議:
因特網有兩大類路由選擇協議:
內部網關協議IGP(Interior Gateway Protocol)即在一個自治系統內部使用的路由選擇協議。目前這類路由選擇協議使用得最多，如RIP和OSPF協議。外部網關協議EGP(External Gateway Protocol)若源站和目的站處在不同的自治系統中，當數據報傳到一個自治系統的邊界時，就需要使用一種協議將路由選擇信息傳遞到另一個自治系統中。這樣的協議就是外部網關協議EGP。在外部網關協議中目前使用最多的是BGP-4。
1）RIP協議
工作原理：
路由信息協議RIP是內部網關協議IGP中最先得到廣泛使用的協議。RIP是一種分布式的基于距離向量的路由選擇協議。RIP協議要求網絡中的每一個路由器都要維護從它自己到其他每一個目的網絡的距離記錄。距離的解釋：從一路由器到直接連接的網絡的距離定義為1。從一個路由器到非直接連接的網絡的距離定義為所經過的路由器數加1。RIP協議中的“距離”也稱為“跳數”(hop count)，因為每經過一個路由器，跳數就加1。這里的“距離”實際上指的是“最短距離”。RIP認為一個好的路由就是它通過的路由器的數目少，即“距離短”。RIP允許一條路徑最多只能包含15個路由器。“距離”的最大值為16時即相當于不可達。可見RIP只適用于
小型互聯網。RIP不能在兩個網絡之間同時使用多條路由。RIP選擇一個具有最少路由器的路由（即最短路由）哪怕還存在另一條高速(低時延)但路由器較多的路由。
2）內部網關協議OSPF(Open Shortest Path First)
基本特點：
“開放”表明OSPF協議不是受某一家廠商控制，而是公開發表的。“最短路徑優先”是因為使用了Dijkstra提出的最短路徑算法SPF。OSPF只是一個協議的名字，它并不表示其他的路由選擇協議不是“最短路徑優先”。是分布式的鏈路狀態協議。
工作原理：
向本自治系統中所有路由器發送信息，這里使用的方法是洪泛法。發送的信息就是與本路由器相鄰的所有路由器的鏈路狀態，但這只是路由器所知道的部分信息。“鏈路狀態”就是說明本路由器都和哪些路由器相鄰，以及該鏈路的“度量”(metric)。
只有當鏈路狀態發生變化時，路由器才用洪泛法向所有路由器發送此信息。
3）外部網關協議 BGP
BGP是不同自治系統的路由器之間交換路由信息的協議。邊界網關協議BGP只能是力求尋找一條能夠到達目的網絡且比較好的路由（不能兜圈子），而并非要尋找一條最佳路由。
BGP發言人：每一個自治系統的管理員要選擇至少一個路由器作為該自治系統的“BGP發言人”。一般說來，兩個BGP發言人都是通過一個共享網絡連接在一起的，而BGP發言人往往就是BGP邊界路由器，但也可以不是BGP邊界路由器。
BGP交換路由信息：
一個BGP發言人與其他自治系統中的BGP發言人要交換路由信息，就要先建立TCP連接，然后在此連接上交換BGP報文以建立BGP會話(session)，利用BGP會話交換路由信息。使用TCP連接能提供可靠的服務也簡化了路由選擇協議。使用TCP連接交換路由信息的兩個BGP發言人，彼此成為對方的鄰站或對等站。
4、客戶端的鏈路層，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然后發送ARP請求查找目的地址，如果得到回應后就可以使用ARP的請求應答交換的IP數據包現在就可以傳輸了，然后發送IP數據包到達服務器的地址。
ARP(地址解析協議)
不管網絡層使用的是什么協議，在實際網絡的鏈路上傳送數據幀時，最終還是必須使用硬件地址。每一個主機都設有一個 ARP 高速緩存(ARP cache)，里面有所在的局域網上的各主機和路由器的 IP 地址到硬件地址的映射表。當主機 A 欲向本局域網上的某個主機 B 發送 IP 數據報時，就先在其 ARP 高速緩存中查看有無主機 B 的 IP 地址。如有，就可查出其對應的硬件地址，再將此硬件地址寫入 MAC 幀，然后通過局域網將該 MAC 幀發往此硬件地址。
對稱加密算法
對稱加密算法采用單密鑰加密，在通信過程中，數據發送方將原始數據分割成固定大小的塊，經過密鑰和加密算法逐個加密后，發送給接收方；接收方收到加密后的報文后，結合密鑰和解密算法解密組合后得出原始數據。由于加解密算法是公開的，因此在這過程中，密鑰的安全傳遞就成為了至關重要的事了。而密鑰通常來說是通過雙方協商，以物理的方式傳遞給對方，或者利用第三方平臺傳遞給對方，一旦這過程出現了密鑰泄露，不懷好意的人就能結合相應的算法攔截解密出其加密傳輸的內容。
對稱加密算法原理
對稱加密算法擁有著算法公開、計算量小、加密速度和效率高得特定，但是也有著密鑰單一、密鑰管理困難等缺點。
常見的對稱加密算法有：
DES：分組式加密算法，以64位為分組對數據加密，加解密使用同一個算法。
3DES：三重數據加密算法，對每個數據塊應用三次DES加密算法。
AES：高級加密標準算法，是美國聯邦政府采用的一種區塊加密標準，用于替代原先的DES，目前已被廣泛應用。
Blowfish：Blowfish算法是一個64位分組及可變密鑰長度的對稱密鑰分組密碼算法，可用來加密64比特長度的字符串。
非對稱加密算法
非對稱加密算法采用公鑰和私鑰兩種不同的密碼來進行加解密。公鑰和私鑰是成對存在，公鑰是從私鑰中提取產生公開給所有人的，如果使用公鑰對數據進行加密，那么只有對應的私鑰才能解密，反之亦然。
下圖為簡單非對稱加密算法的常見流程：
非對稱加密流程
發送方Bob從接收方Alice獲取其對應的公鑰，并結合相應的非對稱算法將明文加密后發送給Alice；Alice接收到加密的密文后，結合自己的私鑰和非對稱算法解密得到明文。這種簡單的非對稱加密算法的應用其安全性比對稱加密算法來說要高，但是其不足之處在于無法確認公鑰的來源合法性以及數據的完整性。
非對稱加密算法具有安全性高、算法強度負復雜的優點，其缺點為加解密耗時長、速度慢，只適合對少量數據進行加密，其常見算法包括：
RSA：RSA算法基于一個十分簡單的數論事實：將兩個大素數相乘十分容易，但那時想要對其乘積進行因式分解卻極其困難，因此可以將乘積公開作為加密密鑰，可用于加密，也能用于簽名。
DSA：數字簽名算法，僅能用于簽名，不能用于加解密。
DSS：數字簽名標準，技能用于簽名，也可以用于加解密。
ELGamal：利用離散對數的原理對數據進行加解密或數據簽名，其速度是最慢的。
單向加密
單向加密算法常用于提取數據指紋，驗證數據的完整性。發送者將明文通過單向加密算法加密生成定長的密文串，然后傳遞給接收方。接收方在收到加密的報文后進行解密，將解密獲取到的明文使用相同的單向加密算法進行加密，得出加密后的密文串。隨后將之與發送者發送過來的密文串進行對比，若發送前和發送后的密文串相一致，則說明傳輸過程中數據沒有損壞；若不一致，說明傳輸過程中數據丟失了。單向加密算法只能用于對數據的加密，無法被解密，其特點為定長輸出、雪崩效應。常見的算法包括：MD5、sha1、sha224等等，其常見用途包括：數字摘要、數字簽名等等。
單向加密校驗過程
密鑰交換
密鑰交換IKE（Internet Key Exchange）通常是指雙方通過交換密鑰來實現數據加密和解密，常見的密鑰交換方式有下面兩種：
1、公鑰加密，將公鑰加密后通過網絡傳輸到對方進行解密，這種方式缺點在于具有很大的可能性被攔截破解，因此不常用；
2、Diffie-Hellman，DH算法是一種密鑰交換算法，其既不用于加密，也不產生數字簽名。DH算法的巧妙在于需要安全通信的雙方可以用這個方法確定對稱密鑰。然后可以用這個密鑰進行加密和解密。但是注意，這個密鑰交換協議/算法只能用于密鑰的交換，而不能進行消息的加密和解密。雙方確定要用的密鑰后，要使用其他對稱密鑰操作加密算法實際加密和解密消息。DH算法通過雙方共有的參數、私有參數和算法信息來進行加密，然后雙方將計算后的結果進行交換，交換完成后再和屬于自己私有的參數進行特殊算法，經過雙方計算后的結果是相同的，此結果即為密鑰。
如：
A 有p和g兩個參數，A還有一個屬于自己的私有參數x； B 有p和g兩個參數，A還有一個屬于自己的私有參數y； A和B均使用相同的加密算法計算其對應的值：value_A=px%g，value_B=py%g 隨后雙方交換計算后的值，然后再分別使用自己的私有參數對去求次方，如： A拿到value_B值后，對其求x次方得(py%g)x=p^xy%g； B拿到value_A值后，對其求y次方得(px%g)y=p^xy%g； 最終得到的結果是一致的。
在整個過程中，第三方人員只能獲取p、g兩個值，AB雙方交換的是計算后的結果，因此這種方式是很安全的。
公鑰基礎設施（PKI）
公鑰基礎設施是一個包括硬件、軟件、人員、策略和規程的集合，用于實現基于公鑰密碼機制的密鑰和證書的生成、管理、存儲、分發和撤銷的功能，其組成包括：簽證機構CA、注冊機構RA、證書吊銷列表CRL和證書存取庫CB。
PKI采用證書管理公鑰，通過第三方可信任CA中心，把用戶的公鑰和其他用戶信息組生成證書，用于驗證用戶的身份。
公鑰證書是以數字簽名的方式聲明，它將公鑰的值綁定到持有對應私鑰的個人、設備或服務身份。公鑰證書的生成遵循X.509協議的規定，其內容包括：證書名稱、證書版本、序列號、算法標識、頒發者、有效期、有效起始日期、有效終止日期、公鑰 、證書簽名等等的內容。
CA證書認證的流程如下圖，Bob為了向Alice證明自己是Bob和某個公鑰是自己的，她便向一個Bob和Alice都信任的CA機構申請證書，Bob先自己生成了一對密鑰對（私鑰和公鑰），把自己的私鑰保存在自己電腦上，然后把公鑰給CA申請證書，CA接受申請于是給Bob頒發了一個數字證書，證書中包含了Bob的那個公鑰以及其它身份信息，當然，CA會計算這些信息的消息摘要并用自己的私鑰加密消息摘要（數字簽名）一并附在Bob的證書上，以此來證明這個證書就是CA自己頒發的。Alice得到Bob的證書后用CA的證書（自簽署的）中的公鑰來解密消息摘要，隨后將摘要和Bob的公鑰發送到CA服務器上進行核對。CA在接收到Alice的核對請求后，會根據Alice提供的信息核對Bob的證書是否合法，如果確認合法則回復Alice證書合法。Alice收到CA的確認回復后，再去使用從證書中獲取的Bob的公鑰加密郵件然后發送給Bob，Bob接收后再以自己的私鑰進行解密。
小技巧
ctrl + shift + 放大終端窗口的字體顯示 ctrl + - 縮小終端窗口的字體顯示
自動補全
在敲出 文件／目錄／命令 的前幾個字母之后，按下 tab 鍵 如果輸入的沒有歧義，系統會自動補全 如果還存在其他 文件／目錄／命令，再按一下 tab 鍵，系統會提示可能存在的命令
重定向命令：>
將命令執行結果重定向到一個文件，本應顯示在終端上的內容保存到指定文件中。
注意： >輸出重定向會覆蓋原來的內容，>>輸出重定向則會追加到文件的尾部
管道：|
管道：一個命令的輸出可以通過管道做為另一個命令的輸入
管道我們可以理解現實生活中的管子，管子的一頭塞東西進去，另一頭取出來，這里“ | ”的左右分為兩端，左端塞東西(寫)，右端取東西(讀)
建立鏈接文件：ln
軟鏈接：軟鏈接不占用磁盤空間，源文件刪除則軟鏈接失效
ln 源文件 鏈接文件
硬鏈接：硬鏈接只能鏈接普通文件，不能鏈接目錄。
ln -s 源文件 鏈接文件
注意：如果軟鏈接文件和源文件不在同一個目錄，源文件要使用絕對路徑，不能使用相對路徑
文本搜索：grep
grep命令是一種強大的文本搜索工具，grep允許對文本文件進行模式查找。如果找到匹配模式， grep打印包含模式的所有行
在grep命令中輸入字符串參數時，最好引號或雙引號括起來。
grep [-選項] ‘搜索內容串’文件名
選項 含義
-v 顯示不包含匹配文本的所有行（相當于求反）
-n 顯示匹配行及行號
-i 忽略大小寫
grep搜索內容串可以是正則表達式
查找文件：find
通常用來在特定的目錄下搜索符合條件的文件，也可以用來搜索特定用戶屬主的文件
命令 含義
find ./ -name test.sh 查找當前目錄下所有名為test.sh的文件
find ./ -name '.sh' 查找當前目錄下所有后綴為.sh的文件
find ./ -name "[A-Z]" 查找當前目錄下所有以大寫字母開頭的文件
打包及壓縮：tar
tar使用格式 : tar [選項] 打包文件名 文件
選項 含義
-c 生成檔案文件，創建打包文件
-v 列出歸檔解檔的詳細過程，顯示進度
-f 指定檔案文件名稱，f后面一定是.tar文件，所以必須放選項最后
-x 解開檔案文件
-z 壓縮
gz壓縮格式
tar這個命令并沒有壓縮的功能，它只是一個打包的命令
但是在tar命令中增加一個選項(-z)可以調用gzip實現了一個壓縮的功能
壓縮用法：tar -zcvf 壓縮包包名 文件1 文件2 ...
-z:指定壓縮包的格式為：file.tar.gz
解壓用法： tar -zxvf 壓縮包包名
-z:指定壓縮包的格式為：file.tar.gz
bz2壓縮格式
壓縮用法： tar -jcvf 壓縮包包名 文件
解壓用法： tar -jxvf 壓縮包包名
zip壓縮格式
通過zip壓縮文件的目標文件不需要指定擴展名，默認擴展名為zip。
壓縮文件：zip 目標文件(沒有擴展名) 源文件
解壓文件：unzip -d 解壓后目錄文件 壓縮文件
解釋型語言編寫的程序不需要編譯，在執行的時候，專門有一個解釋器能夠將VB語言翻譯成機器語言，每個語句都是執行的時候才翻譯。這樣解釋型語言每執行一次就要翻譯一次，效率比較低。
用編譯型語言寫的程序執行之前，需要一個專門的編譯過程，通過編譯系統，把源高級程序編譯成為機器語言文件，翻譯只做了一次，運行時不需要翻譯，所以編譯型語言的程序執行效率高，但也不能一概而論
在說這個問題之前，先說兩個概念，PyCodeObject和pyc文件。
其實PyCodeObject則是python編譯器真正編譯成的結果
當python程序運行時，編譯的結果則是保存在位于內存中的PyCodeObject中，當python程序運行結束時，python解釋器則將PyCodeObject寫回到pyc文件中。 當python程序第二次運行時，首先程序會在硬盤中尋找pyc文件，如果找到，則直接載入，否則就重復上面的過程。 所以我們應該這樣來定位PyCodeObject和pyc文件，我們說pyc文件其實是PyCodeObject的一種持久化保存方式
可變對象：對象存放在地址中的值不會被改變（所謂的改變是創建了一塊新的地址并把新的對象的值放在新地址中原來的對象并沒有發生變化）
不可變對象：對象存放在地址中的值會原地改變
int str float tuple 都屬于不可變對象 其中tuple有些特殊（下文解釋）
dict set list 屬于可變對象
“+”低效的原因：Python中通過“+”進行字符串連接的方法效率極其低下，其根源在于Python中的PyStringObject對象是一個不可變對象。這就意味著當進行字符串連接時，實際上是必須要創建一個新的PyStringObject對象。這樣，如果要連接N個PyStringObject對象，那么就必須進行 N-1 次的內存申請及內存搬運的工作。毫無疑問，這將嚴重影響Python的執行效率。
官方推薦：做法是通過利用PyStringObject對象的join操作來對存儲在list或者tuple中的一組PyStringObject對象進行連接操作，這種做法只需要分配一次內存，執行效率將大大提高。
join執行過程：執行join操作時，會首先統計出在list中一共有多少個PyStringObject對象，并統計這些PyStringObject對象所維護的字符串一共有多長，然后申請內存，將list中所有的PyStringObject對象維護的字符串都拷貝到新開辟的內存空間中。注意：這里只進行了一次內存空間的申請，就完成了N個PyStringObject對象的連接操作。相比于“+”操作符，待連接的PyStringObject對象越多，效率的提升也會越明顯。
字典是通過散列表或說哈希表實現的。字典也被稱為關聯數組，還稱為哈希數組等。也就是說，字典也是一個數組，但數組的索引是鍵經過哈希函數處理后得到的散列值。哈希函數的目的是使鍵均勻地分布在數組中，并且可以在內存中以O(1)的時間復雜度進行尋址，從而實現快速查找和修改。哈希表中哈希函數的設計困難在于將數據均勻分布在哈希表中，從而盡量減少哈希碰撞和沖突。由于不同的鍵可能具有相同的哈希值，即可能出現沖突，高級的哈希函數能夠使沖突數目最小化。Python中并不包含這樣高級的哈希函數，幾個重要（用于處理字符串和整數）的哈希函數是常見的幾個類型。通常情況下建立哈希表的具體過程如下：
數據添加：把key通過哈希函數轉換成一個整型數字，然后就將該數字對數組長度進行取余，取余結果就當作數組的下標，將value存儲在以該數字為下標的數組空間里。 數據查詢：再次使用哈希函數將key轉換為對應的數組下標，并定位到數組的位置獲取value。
哈希函數就是一個映射，因此哈希函數的設定很靈活，只要使得任何關鍵字由此所得的哈希函數值都落在表長允許的范圍之內即可。本質上看哈希函數不可能做成一個一對一的映射關系，其本質是一個多對一的映射，這也就引出了下面一個概念–哈希沖突或者說哈希碰撞。哈希碰撞是不可避免的，但是一個好的哈希函數的設計需要盡量避免哈希碰撞。
is 和 == 的區別
is 是身份運算符 == 是比較運算符
至于，我們一般說is 和 == 的區別，無非就是說，到底比較的是什么
is 比較的是變量的id地址是否相同，即是否指向同一塊內存地址 == 比較的是變量的值是否相同，即不管是否是同一塊內存地址，只要其存的值相同即可
淺拷貝
淺拷貝是會將對象的每個屬性進行依次復制，但是當對象的屬性值是引用類型時，實質復制的是其引用，當引用指向的值改變時也會跟著變化。 Object.assign、 擴展運算符 ... 、 Array.prototype.slice()、 Array.prototype.concat() 等
深拷貝
深拷貝復制變量值，對于引用數據，則遞歸至基本類型后，再復制。 深拷貝后的對象與原來的對象是完全隔離的，互不影響，對一個對象的修改并不會影響另一個對象
在編寫代碼時只寫框架思路，具體實現還未編寫就可以用 pass 進行占位，使程序不報錯，不會進行任何操作。
當我們不知道向函數傳遞多少參數時，比如我們向傳遞一個列表或元組，我們就使用*args
當我們不知道該傳遞多少關鍵字參數時，使用**kwargs來收集關鍵字參數
什么是迭代器協議
對象需要提供next方法,它要么返回迭代中的下一項,要么就引起一個StopIteration異常,終止迭代.
可迭代對象
實現了迭代器協議的對象就是可迭代對象(實現方式是,實現iter方法)
協議
協議是一種規定,可迭代對象實現迭代器協議,Python的內置工具(如for,sum,min,max,in)就可以使用迭代器協議訪問對象.例如文件之所以可以被for循環遍歷,就是因為文件對象實現了迭代器協議,也就是說它有next()方法.
迭代器
定義
就是實現了iter() 和 next()方法的對象.其中iter()返回迭代器本身,而next()返回容器的下一個元素,在結尾處引發StopInteration異常.
生成器
定義
生成器（Generator）是創建迭代器的簡單而強大的工具。它們寫起來就像是正規的函數，只是在需要返回數
據的時候使用 yield 語句。每次 next()被調用時，生成器會返回它脫離的位置（它記憶語句最后一次執行的位置
和所有的數據值）。
生成器對延遲操作提供了支持.所謂延遲操作,是指在需要的時候才產生結果,而不是立即產生結果。
創建方式
生成器表達式
類似于列表推導式,是用()代替了原來的[].生成器返回按需產生結果的一個對象,而不是一次構建一個結果列表
生成器函數
和常規函數定義一樣,但是返回語句return被yield語句代替了.yield語句一次返回一個結果,在每個結果中間,掛起函數的狀態,以便下次從它離開的地方繼續執行.
不同點總結如下：
1) 返回值類型不同：
a) return 返回其后面表達式的值可以是任何類型，暫稱其為T類型；
b) 而yield return 返回IEnumerable<T>類型，總是個可枚舉的對象，yield return 后面的表達式為T類型。
那么如何構成可枚舉對象呢？就看yield return 語句執行多少次，執行多少次最終的可枚舉對象就有多少個元素，怎么執行多少次我想不用我說了，比如循環，甚至簡單的復制幾遍。要說明的是每個yield return 后的表達式應該是相同或相兼容的類型，都為T類型。
2）程序控制流程不同：
a) return 語句使方法返回，后面再有語句都不執行了。
b) yield return 則不會使方法返回，繼續執行后面的語句，只是計算記錄最終返回的可枚舉對象的一個元素值。
在一些語言中，在函數中可以（嵌套）定義另一個函數時，如果內部的函數引用了外部的函數的變量，則可能產生閉包。閉包可以用來在一個函數與一組“私有”變量之間創建關聯關系。在給定函數被多次調用的過程中，這些私有變量能夠保持其持久性。—— 維基百科
用比較容易懂的人話說，就是當某個函數被當成對象返回時，夾帶了外部變量，就形成了一個閉包。
裝飾器是Python語言中的高級語法。主要的功能是對一個函數、方法、或者類進行加工，作用是為已經存在的對象添加額外的功能，提升代碼的可讀性。
裝飾器是設計模式的一種，被用于有切面需求的場景，較為經典的有插入日志、性能測試、事務處理等
1 map()函數的簡介以及語法：
map是python內置函數，會根據提供的函數對指定的序列做映射。
map()函數的格式是：
map(function,iterable,...)
第一個參數接受一個函數名，后面的參數接受一個或多個可迭代的序列，返回的是一個集合。
把函數依次作用在list中的每一個元素上，得到一個新的list并返回。注意，map不改變原list，而是返回一個新list。
簡單地說，allocator 預先向系統申請一定數量的內存空間并格式化，每當有滿足條件的內存請求時，allocator直接從這些格式化的內存中選擇一塊滿足條件的分配給這個需求。如果預先申請的內存已經耗盡，那么 allocator會再向系統申請更多的內存并格式化（前提是不能超過預先設置的內存池最大容量），然后分配內存。當對象被回收時，如果所占內存之前由allocator 從內存池分配，那么回收的內存同樣被歸還給內存池，以供下次內存請求使用。如果應用的內存需求大于 pymalloc設置的閾值，那么解釋器再將這個請求交給底層的 C 函數來實現
面向過程編程就是一步一步的按照過程來進行,面向流程的;簡單來說就是先分析出解決問題所需要的步驟,然后用函數一步步的調用實現。 例如:你需要網上購物,那么你首先需要進入到這個網站,然后再輸入用戶名和密碼等實現登錄,然后再實現購物支付等的功能…而實現這些的步驟就是一個面向過程編程
以上是“python中計算機網絡相關知識點有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
