溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“作為一個程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“作為一個程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”吧！
面試過程中經(jīng)常會被問到計算機網(wǎng)絡(luò)相關(guān)的知識，就打算寫一篇博客不斷總結(jié)一些計算機網(wǎng)絡(luò)的基礎(chǔ)點以及面試中常問的考點。如果文檔中存在錯誤歡迎指出，有任何補充留言私信均可以，我會不定期的添加上去。話不多說，直接進(jìn)入主題：
OSI網(wǎng)絡(luò)體系結(jié)構(gòu)分為七層：
從下到上分為：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡(luò)層、傳輸層、會話層、表示層、應(yīng)用層
TCP/IP協(xié)議結(jié)構(gòu)分為四層：
從下到上分為：網(wǎng)絡(luò)接口層、網(wǎng)際層、傳輸層、應(yīng)用層
網(wǎng)絡(luò)接口層對應(yīng)于OSI的物理層和數(shù)據(jù)鏈路層，應(yīng)用層對應(yīng)于OSI的會話層、表示層、應(yīng)用層。
Http協(xié)議運行在TCP之上，明文傳輸，客戶端與服務(wù)器端都無法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行于SSL上，SSL運行于TCP之上，是添加了加密和認(rèn)證機制的HTTP。二者之間存在如下不同：
端口不同：Http與Http使用不同的連接方式，用的端口也不一樣，前者是80，后者是443；
資源消耗：和HTTP通信相比，Https通信會由于加減密處理消耗更多的CPU和內(nèi)存資源；
開銷：Https通信需要證書，而證書一般需要向認(rèn)證機構(gòu)購買；
Https的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。
HTTP協(xié)議格式
http請求協(xié)議部分?jǐn)?shù)據(jù)
GET /user HTTP/1.1 Host: localhost:8080 Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3 Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9 <html>...
第一部分：請求行：請求類型，資源路徑以及http版本（上述第一行）
第二部分：請求頭：緊接在請求行之后，用于說明服務(wù)器需要使用的附加信息（第二到第八行）
第三部分：空行（請求頭和主體之間必須有換行）
第四部分：主體數(shù)據(jù)，可以添加任意數(shù)據(jù)
http響應(yīng)協(xié)議
HTTP/1.1 200 Content-Type：text/html OK
第一部分：狀態(tài)行，http版本，狀態(tài)碼，狀態(tài)信息（第一行）
第二部分：響應(yīng)報文頭部，說明服務(wù)器需要用到的附加信息（第二行）
第三部分：空行（第三行）
第四部分：響應(yīng)正文（第四行）
TCP是傳輸層協(xié)議，TCP提供了數(shù)據(jù)的可靠連接，通過面向連接、端到端和可靠的字節(jié)流服務(wù)。
UDP是傳輸層協(xié)議，UDP在數(shù)據(jù)傳輸前不會建立連接，不能保證數(shù)據(jù)連接的可靠性，傳輸速度快。
第一次揮手：客戶端進(jìn)程發(fā)出連接釋放報文，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報文首部，F(xiàn)IN=1，其序列號為seq=u（等于前面已經(jīng)傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），此時，客戶端進(jìn)入FIN-WAIT-1（終止等待1）狀態(tài)。 TCP規(guī)定，F(xiàn)IN報文段即使不攜帶數(shù)據(jù)，也要消耗一個序號。
第二次揮手：服務(wù)器收到連接釋放報文，發(fā)出確認(rèn)報文，ACK=1，ack=u+1，并且?guī)献约旱男蛄刑杝eq=v，此時，服務(wù)端就進(jìn)入了CLOSE-WAIT（關(guān)閉等待）狀態(tài)。TCP服務(wù)器通知高層的應(yīng)用進(jìn)程，客戶端向服務(wù)器的方向就釋放了，這時候處于半關(guān)閉狀態(tài)，即客戶端已經(jīng)沒有數(shù)據(jù)要發(fā)送了，但是服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。客戶端收到服務(wù)器的確認(rèn)請求后，此時，客戶端就進(jìn)入FIN-WAIT-2（終止等待2）狀態(tài)，等待服務(wù)器發(fā)送連接釋放報文（在這之前還需要接受服務(wù)器發(fā)送的最后的數(shù)據(jù)）。
第三次揮手：服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報文，F(xiàn)IN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時的序列號為seq=w，此時，服務(wù)器就進(jìn)入了LAST-ACK（最后確認(rèn)）狀態(tài)，等待客戶端的確認(rèn)。
第四次揮手：客戶端收到服務(wù)器的連接釋放報文后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進(jìn)入了TIME-WAIT（時間等待）狀態(tài)。注意此時TCP連接還沒有釋放，必須經(jīng)過2??MSL（最長報文段壽命）的時間后，當(dāng)客戶端撤銷相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷TCB后，就結(jié)束了這次的TCP連接?？梢钥吹剑?wù)器結(jié)束TCP連接的時間要比客戶端早一些。
因為當(dāng)Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應(yīng)答的，SYN報文是用來同步的。但是關(guān)閉連接時，當(dāng)Server端收到FIN報文時，很可能并不會立即關(guān)閉SOCKET，所以只能先回復(fù)一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。
雖然按道理，四個報文都發(fā)送完畢，我們可以直接進(jìn)入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡(luò)是不可靠的，有可能最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā)送出最后的ACK回復(fù)，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復(fù)發(fā)送FIN片段。所以Client不能立即關(guān)閉，它必須確認(rèn)Server接收到了該ACK。Client會在發(fā)送出ACK之后進(jìn)入到TIME_WAIT狀態(tài)。Client會設(shè)置一個計時器，等待2MSL的時間。如果在該時間內(nèi)再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡(luò)中最大的存活時間，2MSL就是一個發(fā)送和一個回復(fù)所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經(jīng)被成功接收，則結(jié)束TCP連接。
3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準(zhǔn)備工作(雙方都知道彼此已準(zhǔn)備好)，也要允許雙方就初始序列號進(jìn)行協(xié)商，這個序列號在握手過程中被發(fā)送和確認(rèn)。
現(xiàn)在把三次握手改成僅需要兩次握手，當(dāng)?shù)诙挝帐趾螅捶?wù)器發(fā)送給客戶端）的請求客戶端沒收到時，服務(wù)器會認(rèn)為已經(jīng)建立了連接，開始發(fā)送數(shù)據(jù)，但是客戶端沒收到連接請求，會認(rèn)為連接未建立，繼續(xù)發(fā)送連接信息。這時就導(dǎo)致了死鎖。
至于為什么不改成四次，當(dāng)三次連接后，服務(wù)器和客戶機都能確定之前的通信情況，但是無法確認(rèn)之后的情況，可靠的通信協(xié)議是根本不存在的，因此再增加一次也是徒勞。
TCP還設(shè)有一個?；钣嫊r器，顯然，客戶端如果出現(xiàn)故障，服務(wù)器不能一直等下去，白白浪費資源。服務(wù)器每收到一次客戶端的請求后都會重新復(fù)位這個計時器，時間通常是設(shè)置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會發(fā)送一個探測報文段，以后每隔75秒鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。
網(wǎng)絡(luò)層
IP協(xié)議：網(wǎng)際協(xié)議
ICMP協(xié)議：Internet控制報文協(xié)議
ARP協(xié)議:地址解析協(xié)議
RARP協(xié)議：逆地址解析協(xié)議
傳輸層
UDP協(xié)議：用戶數(shù)據(jù)報協(xié)議
TCP協(xié)議：傳輸控制協(xié)議
應(yīng)用層
FTP：文件傳送協(xié)議
Telenet：遠(yuǎn)程登錄協(xié)議
DNS：域名解析協(xié)議
POP3：郵局協(xié)議
HTTP協(xié)議：超文本傳輸協(xié)議
SMTP：簡單郵件傳送協(xié)議
SNMP：簡單網(wǎng)絡(luò)管理協(xié)議
TFTP：簡單文件傳送協(xié)議
DDoS攻擊
DDoS全稱Distributed Denial of Service，中文意思為“分布式拒絕服務(wù)”，就是利用大量合法的分布式服務(wù)器對目標(biāo)發(fā)送請求，從而導(dǎo)致正常合法用戶無法獲得服務(wù)。
常見的攻擊方式如TCP攻擊：
客戶端向服務(wù)端發(fā)送請求鏈接數(shù)據(jù)包
服務(wù)端向客戶端發(fā)送確認(rèn)數(shù)據(jù)包
客戶端不向服務(wù)端發(fā)送確認(rèn)數(shù)據(jù)包，服務(wù)器一直等待來自客戶端的確認(rèn)
DDoS預(yù)防
限制同時打開SYN半鏈接的數(shù)目
縮短SYN半鏈接的Time out 時間
關(guān)閉不必要的服務(wù)
SQL注入
攻擊者不是將標(biāo)準(zhǔn)數(shù)據(jù)提交到文本框或其他數(shù)據(jù)輸入字段，而是輸入SQL語句來誘騙應(yīng)用程序顯示或操縱其數(shù)據(jù)。
SQL注入預(yù)防措施
不要使用動態(tài)SQL
不要將敏感數(shù)據(jù)保留在純文本中。
限制數(shù)據(jù)庫權(quán)限和特權(quán)
避免直接向用戶顯示數(shù)據(jù)庫錯誤
對訪問數(shù)據(jù)庫的Web應(yīng)用程序使用Web應(yīng)用程序防火墻（WAF）
定期測試與數(shù)據(jù)庫交互的Web應(yīng)用程序
將數(shù)據(jù)庫更新為最新的可用修補程序
XSS 攻擊
XSS 攻擊，即跨站腳本攻擊（Cross Site Scripting），它是 web 程序中常見的漏洞。 攻擊者破壞易受攻擊的網(wǎng)站或Web應(yīng)用程序并注入惡意代碼。當(dāng)頁面加載時，代碼在用戶的瀏覽器上執(zhí)行惡意腳本。
XSS預(yù)防
web 頁面用戶輸入的地方，對輸入的數(shù)據(jù)轉(zhuǎn)義、過濾處理。后臺輸出頁面的時候，也需要對輸出內(nèi)容進(jìn)行轉(zhuǎn)義、過濾處理（因為攻擊者可能通過其他方式把惡意腳本寫入數(shù)據(jù)庫）
前端對 html 標(biāo)簽屬性、css 屬性賦值的地方進(jìn)行校驗
CSRF 攻擊
跨站請求偽造（英語：Cross-site request forgery），是一種挾制用戶在當(dāng)前已登錄的Web應(yīng)用程序上執(zhí)行非本意的操作的攻擊方法。
CSRF預(yù)防
檢查Referer字段
HTTP頭中有一個Referer字段，這個字段用以標(biāo)明請求來源于哪個地址。在處理敏感數(shù)據(jù)請求時，通常來說，Referer字段應(yīng)和請求的地址位于同一域名下。以上文銀行操作為例，Referer字段地址通常應(yīng)該是轉(zhuǎn)賬按鈕所在的網(wǎng)頁地址，應(yīng)該也位于www.examplebank.com之下。而如果是CSRF攻擊傳來的請求，Referer字段會是包含惡意網(wǎng)址的地址，不會位于www.examplebank.com之下，這時候服務(wù)器就能識別出惡意的訪問。
添加校驗token
由于CSRF的本質(zhì)在于攻擊者欺騙用戶去訪問自己設(shè)置的地址，所以如果要求在訪問敏感數(shù)據(jù)請求時，要求用戶瀏覽器提供不保存在cookie中，并且攻擊者無法偽造的數(shù)據(jù)作為校驗，那么攻擊者就無法再運行CSRF攻擊。這種數(shù)據(jù)通常是窗體中的一個數(shù)據(jù)項。服務(wù)器將其生成并附加在窗體中，其內(nèi)容是一個偽隨機數(shù)。當(dāng)客戶端通過窗體提交請求時，這個偽隨機數(shù)也一并提交上去以供校驗。正常的訪問時，客戶端瀏覽器能夠正確得到并傳回這個偽隨機數(shù)，而通過CSRF傳來的欺騙性攻擊中，攻擊者無從事先得知這個偽隨機數(shù)的值，服務(wù)端就會因為校驗token的值為空或者錯誤，拒絕這個可疑請求。
TCP 是面向連接的，面向流的可靠協(xié)議；發(fā)送端為了將多個發(fā)往接收端的包，更有效的發(fā)到對方，使用了優(yōu)化方法（Nagle算法），將多次間隔較小且數(shù)據(jù)量小的數(shù)據(jù)，合并成一個大的數(shù)據(jù)塊，然后進(jìn)行封包。這樣，接收端，就難于分辨出來了，就會出現(xiàn)所謂的粘包問題。
產(chǎn)生粘包的原因：
(1)發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去，造成粘包（發(fā)送數(shù)據(jù)時間間隔很短，數(shù)據(jù)了很小，會合到一起，產(chǎn)生粘包）
(2)接收方不及時接收緩沖區(qū)的包，造成多個包接收（客戶端發(fā)送了一段數(shù)據(jù)，服務(wù)端只收了一小部分，服務(wù)端下次再收的時候還是從緩沖區(qū)拿上次遺留的數(shù)據(jù)，產(chǎn)生粘包）
粘包的解決方案：
（1）定長發(fā)送
在進(jìn)行數(shù)據(jù)發(fā)送的時候采用固定長度的設(shè)計，無論多大的數(shù)據(jù)包都分成固定的長度進(jìn)行發(fā)送，這種方式的弊端在于，最后一個包的長度往往會被填充為空格，接收方可能無法辨別無效部分。
（2）設(shè)置尾部的標(biāo)記
在一個包結(jié)束的位置增加一個特殊的標(biāo)記，當(dāng)接收方讀取到這個標(biāo)記后就說明數(shù)據(jù)包讀取完畢，這種方式的弊端在于取什么樣的數(shù)據(jù)作為標(biāo)志位是一件很難找到恰當(dāng)答案的事情。
（3）在頭部增加標(biāo)記標(biāo)明數(shù)據(jù)包長度
在頭部標(biāo)記一個長度，讀取時先讀取這個長度再接受數(shù)據(jù)，這樣就不用擔(dān)心數(shù)據(jù)包丟失的問題。
感謝各位的閱讀，以上就是“作為一個程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對作為一個程序員需要了解網(wǎng)絡(luò)方面的基礎(chǔ)有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼
