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