計(jì)算機(jī)網(wǎng)絡(luò)

一、OSI七層網(wǎng)絡(luò)協(xié)議：

應(yīng)用層——表示層——會(huì)話層——傳輸層——網(wǎng)絡(luò)層——數(shù)據(jù)鏈路層——物理層

五層體系機(jī)構(gòu)：

應(yīng)用層——傳輸層（TCP報(bào)文、UDP數(shù)據(jù)包）——網(wǎng)絡(luò)層（IP數(shù)據(jù)報(bào)或分組）——數(shù)據(jù)鏈路層（幀）——物理層（比特流）

?

二、TCP和UDP的區(qū)別？

1.TCP是面向連接的，UDP面向無(wú)連接

2.TCP是可靠的連接，保證數(shù)據(jù)的正確性；UDP可能丟包

3.TCP連接只能是點(diǎn)到點(diǎn)的，UDP可以一對(duì)一，一對(duì)多，多對(duì)一和多對(duì)多交互通信

4.TCP傳輸速度慢，要求系統(tǒng)資源多，UDP傳輸速度快，要求系統(tǒng)資源少

5.FTP、HTTP、Telnet、SMTP、POP3、HTTPS是基于TCP的， DNS、SNMP、NFS是基于UDP的

?

三、TCP如何保證可靠性

1. 校驗(yàn)和:?發(fā)送方在發(fā)送數(shù)據(jù)之前計(jì)算檢驗(yàn)和（ 發(fā)送的數(shù)據(jù)包的二進(jìn)制相加然后取反），并進(jìn)行校驗(yàn)和的填充。?接收方收到數(shù)據(jù)后，對(duì)數(shù)據(jù)以同樣的方式進(jìn)行計(jì)算，求出校驗(yàn)和，與發(fā)送方的進(jìn)行比對(duì)。

注意：如果接收方比對(duì)校驗(yàn)和與發(fā)送方不一致，那么數(shù)據(jù)一定傳輸有誤。但是如果接收方比對(duì)校驗(yàn)和與發(fā)送方一致，數(shù)據(jù)不一定傳輸成功

2. 流量控制( 滑動(dòng)窗口協(xié)議)： TCP 連接的每一方都有固定大小的緩沖空間?，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當(dāng)接收方來(lái)不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失

3.擁塞控制：?當(dāng)

網(wǎng)絡(luò)擁塞時(shí)，減少數(shù)據(jù)的發(fā)送

4. 超時(shí)重傳：雙方在發(fā)送一部分?jǐn)?shù)據(jù)后，都會(huì)等待接收方發(fā)送的ACK報(bào)文，并解析ACK報(bào)文，判斷數(shù)據(jù)是否傳輸成功，如果沒(méi)有的接收到ACK報(bào)文的話，會(huì)重新發(fā)送請(qǐng)求

5. 重排序失序數(shù)據(jù): TCP傳輸時(shí)將每個(gè)字節(jié)的數(shù)據(jù)都進(jìn)行了編號(hào)，這就是序列號(hào),?在傳輸?shù)倪^(guò)程中，每次接收方收到數(shù)據(jù)后，都會(huì)對(duì)傳輸方發(fā)送ACK報(bào)文。

?

四、cookie 和session 的區(qū)別詳解

1.cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

2.cookie不是很安全，別人可以分析存放在本地的COOKIE并進(jìn)行COOKIE欺騙考慮到安全應(yīng)當(dāng)使用session。

3.session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問(wèn)增多，會(huì)比較占用你服務(wù)器的性能考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE。

4.單個(gè)cookie保存的數(shù)據(jù)不能超過(guò)4K，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie。

5.所以個(gè)人建議： 將登陸信息等重要信息存放為SESSION, 其他信息如果需要保留，可以放在COOKIE中

?

?

五、GET和POST本質(zhì)上有什么區(qū)別

1.最直接的區(qū)別，GET請(qǐng)求的參數(shù)是放在URL里的，密碼信息不要用Get方式發(fā)送請(qǐng)求，POST請(qǐng)求參數(shù)是放在請(qǐng)求body里的

2.GET請(qǐng)求的URL傳參有長(zhǎng)度限制，而POST請(qǐng)求沒(méi)有長(zhǎng)度限制

3.GET請(qǐng)求的參數(shù)只能是ASCII碼，所以中文需要URL編碼，而POST請(qǐng)求傳參沒(méi)有這個(gè)限制

4.GET能被緩存，POST不能被緩存

?

?

六、Http 與 Https 的區(qū)別

1.HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密。HTTPS在HTTP的基礎(chǔ)上加入了SSL/TLS協(xié)議，依靠證書(shū)來(lái)驗(yàn)證服務(wù)器的身份，并為瀏覽器和服務(wù)器之間的通信加密；

2. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。

3. https協(xié)議需要到CA申請(qǐng)證書(shū)，一般免費(fèi)證書(shū)較少，因而需要一定費(fèi)用。

4. http的連接很簡(jiǎn)單，是無(wú)狀態(tài)的；HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全

?

七、TCP/IP三次握手四次揮手

?圖解如下：

SYN：同步序列編號(hào)（Synchronize Sequence Numbers）；

ACK：確認(rèn)序列包

SYN_SENT?：(同步發(fā)送狀態(tài))

SYN_RECV：(同步接受狀態(tài))

ESTABLISHED：（TCP連接成功）

1.第一次握手：建立連接時(shí)，客戶端發(fā)送syn包（syn=j）到服務(wù)器，并進(jìn)入SYN_SENT（同步發(fā)送）狀態(tài)，等待服務(wù)器確認(rèn)；

2. 第二次握手：服務(wù)器收到syn包，必須確認(rèn)客戶的SYN（ACK =j+1），同時(shí)自己也發(fā)送一個(gè)SYN包（syn=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN_RECV（同步接受）狀態(tài)；

3.第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(ACK =k+1），此包發(fā)送完畢，客戶端和服務(wù)器進(jìn)入ESTABLISHED(建立連接)狀態(tài)，完成三次握手。

問(wèn)題：

為什么不能用兩次握手進(jìn)行連接(為什么TCP要發(fā)送最后一次確認(rèn))？

主要防止已經(jīng)失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)器，?兩者兩次握手后連接沒(méi)有數(shù)據(jù)傳輸，造成資源浪費(fèi)。

假設(shè)有這樣一種場(chǎng)景，客戶端發(fā)送了第一個(gè)請(qǐng)求連接并且沒(méi)有丟失，只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了，由于TCP的客戶端遲遲沒(méi)有收到確認(rèn)報(bào)文，以為服務(wù)器沒(méi)有收到，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文，此后客戶端和服務(wù)器經(jīng)過(guò)兩次握手完成連接，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時(shí)此前滯留的那一次請(qǐng)求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個(gè)報(bào)文本該是失效的，但是，兩次握手的機(jī)制將會(huì)讓客戶端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)

?

四次揮手-連接終止協(xié)議

?

1）客戶端進(jìn)程發(fā)出連接釋放報(bào)文 (FIN )，并且停止發(fā)送數(shù)據(jù)。釋放數(shù)據(jù)報(bào)文首部，FIN=1，其序列號(hào)為seq=u（等于前面已經(jīng)傳送過(guò)來(lái)的數(shù)據(jù)的最后一個(gè)字節(jié)的序號(hào)加1），此時(shí)，客戶端進(jìn)入終止等待1?(FIN-WAIT-1)狀態(tài)。?

2）服務(wù)器收到連接釋放報(bào)文(FIN),發(fā)出確認(rèn)報(bào)文ACK=1，ack=u+1，并且?guī)献约旱男蛄刑?hào)seq=v，此時(shí)，服務(wù)端就進(jìn)入了關(guān)閉等待(CLOSE-WAIT )狀態(tài)。服務(wù)器若發(fā)送數(shù)據(jù)，客戶端依然要接受。這個(gè)狀態(tài)還要持續(xù)一段時(shí)間，也就是整個(gè)關(guān)閉等待(CLOSE-WAIT )狀態(tài)持續(xù)的時(shí)間。

3）客戶端收到服務(wù)器的確認(rèn)請(qǐng)求后，此時(shí)，客戶端就進(jìn)入終止等待2(FIN-WAIT-2 )狀態(tài)，等待服務(wù)器發(fā)送連接釋放報(bào)文

4）服務(wù)器將最后的數(shù)據(jù)發(fā)送完畢后，就向客戶端發(fā)送連接釋放報(bào)文(FIN)，FIN=1，ack=u+1，由于在半關(guān)閉狀態(tài)，服務(wù)器很可能又發(fā)送了一些數(shù)據(jù)，假定此時(shí)的序列號(hào)為seq=w，此時(shí)，服務(wù)器就進(jìn)入了最后確認(rèn)(LAST-ACK )狀態(tài)，等待客戶端的確認(rèn)。

5）客戶端收到服務(wù)器的連接釋放報(bào)文(FIN)后，必須發(fā)出確認(rèn)，ACK=1，ack=w+1，而自己的序列號(hào)是seq=u+1，此時(shí)，客戶端就進(jìn)入了時(shí)間等待(TIME-WAIT)狀態(tài)。注意此時(shí)TCP連接還沒(méi)有釋放，?客戶端等待 2MSL（最長(zhǎng)報(bào)文段壽命)后，當(dāng)客戶端撤銷(xiāo)相應(yīng)的TCB后，才進(jìn)入CLOSED狀態(tài)。

6）服務(wù)器只要收到了客戶端發(fā)出的確認(rèn)，立即進(jìn)入CLOSED狀態(tài)。同樣，撤銷(xiāo)TCB后，就結(jié)束了這次的TCP連接。可以看到，服務(wù)器結(jié)束TCP連接的時(shí)間要比客戶端早一些。

問(wèn)題：

為什么連接的時(shí)候是三次握手，關(guān)閉的時(shí)候卻是四次握手？

服務(wù)器收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來(lái)表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開(kāi)發(fā)送，從而導(dǎo)致多了一次

為什么客戶端最后還要等待2MSL（最長(zhǎng)報(bào)文段壽命 ）？

保證客戶端發(fā)送的最后一個(gè)ACK報(bào)文能夠到達(dá)服務(wù)器，因?yàn)檫@個(gè)ACK報(bào)文可能丟失?。如果丟失了，站在服務(wù)器的角度看來(lái)，我已經(jīng)發(fā)送了FIN+ACK報(bào)文請(qǐng)求斷開(kāi)了，客戶端還沒(méi)有給我回應(yīng)，應(yīng)該是我發(fā)送的請(qǐng)求斷開(kāi)報(bào)文它沒(méi)有收到，于是服務(wù)器又會(huì)重新發(fā)送一次，而客戶端就能在這個(gè)2MSL時(shí)間段內(nèi)收到這個(gè)重傳的報(bào)文，接著給出回應(yīng)報(bào)文，并且會(huì)重啟2MSL計(jì)時(shí)器

如果已經(jīng)建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？

TCP還設(shè)有一個(gè)保活計(jì)時(shí)器，服務(wù)器每收到一次客戶端的請(qǐng)求后都會(huì)重新復(fù)位這個(gè)計(jì)時(shí)器，時(shí)間通常是設(shè)置為2小時(shí)，若兩小時(shí)還沒(méi)有收到客戶端的任何數(shù)據(jù)，服務(wù)器就會(huì)發(fā)送一個(gè)探測(cè)報(bào)文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個(gè)探測(cè)報(bào)文仍然沒(méi)反應(yīng)，服務(wù)器就認(rèn)為客戶端出了故障，接著就關(guān)閉連接。

?

總結(jié)

以上是生活随笔為你收集整理的后台开发人员面试内容——计算机网络(五)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。