計算機網絡

一、OSI七層網絡協議：

應用層——表示層——會話層——傳輸層——網絡層——數據鏈路層——物理層

五層體系機構：

應用層——傳輸層（TCP報文、UDP數據包）——網絡層（IP數據報或分組）——數據鏈路層（幀）——物理層（比特流）

?

二、TCP和UDP的區別？

1.TCP是面向連接的，UDP面向無連接

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

3.TCP連接只能是點到點的，UDP可以一對一，一對多，多對一和多對多交互通信

4.TCP傳輸速度慢，要求系統資源多，UDP傳輸速度快，要求系統資源少

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

?

三、TCP如何保證可靠性

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

注意：如果接收方比對校驗和與發送方不一致，那么數據一定傳輸有誤。但是如果接收方比對校驗和與發送方一致，數據不一定傳輸成功

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

3.擁塞控制：?當

網絡擁塞時，減少數據的發送

4. 超時重傳：雙方在發送一部分數據后，都會等待接收方發送的ACK報文，并解析ACK報文，判斷數據是否傳輸成功，如果沒有的接收到ACK報文的話，會重新發送請求

5. 重排序失序數據: TCP傳輸時將每個字節的數據都進行了編號，這就是序列號,?在傳輸的過程中，每次接收方收到數據后，都會對傳輸方發送ACK報文。

?

四、cookie 和session 的區別詳解

1.cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

2.cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙考慮到安全應當使用session。

3.session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能考慮到減輕服務器性能方面，應當使用COOKIE。

4.單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。

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

?

?

五、GET和POST本質上有什么區別

1.最直接的區別，GET請求的參數是放在URL里的，密碼信息不要用Get方式發送請求，POST請求參數是放在請求body里的

2.GET請求的URL傳參有長度限制，而POST請求沒有長度限制

3.GET請求的參數只能是ASCII碼，所以中文需要URL編碼，而POST請求傳參沒有這個限制

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

?

?

六、Http 與 Https 的區別

1.HTTP協議以明文方式發送內容，不提供任何方式的數據加密。HTTPS在HTTP的基礎上加入了SSL/TLS協議，依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密；

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

3. https協議需要到CA申請證書，一般免費證書較少，因而需要一定費用。

4. http的連接很簡單，是無狀態的；HTTPS協議是由SSL/TLS+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全

?

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

?圖解如下：

SYN：同步序列編號（Synchronize Sequence Numbers）；

ACK：確認序列包

SYN_SENT?：(同步發送狀態)

SYN_RECV：(同步接受狀態)

ESTABLISHED：（TCP連接成功）

1.第一次握手：建立連接時，客戶端發送syn包（syn=j）到服務器，并進入SYN_SENT（同步發送）狀態，等待服務器確認；

2. 第二次握手：服務器收到syn包，必須確認客戶的SYN（ACK =j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV（同步接受）狀態；

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

問題：

為什么不能用兩次握手進行連接(為什么TCP要發送最后一次確認)？

主要防止已經失效的連接請求報文突然又傳送到了服務器，?兩者兩次握手后連接沒有數據傳輸，造成資源浪費。

假設有這樣一種場景，客戶端發送了第一個請求連接并且沒有丟失，只是因為在網絡結點中滯留的時間太長了，由于TCP的客戶端遲遲沒有收到確認報文，以為服務器沒有收到，此時重新向服務器發送這條報文，此后客戶端和服務器經過兩次握手完成連接，傳輸數據，然后關閉連接。此時此前滯留的那一次請求連接，網絡通暢了到達了服務器，這個報文本該是失效的，但是，兩次握手的機制將會讓客戶端和服務器再次建立連接，這將導致不必要的錯誤和資源的浪費

?

四次揮手-連接終止協議

?

1）客戶端進程發出連接釋放報文 (FIN )，并且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等于前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入終止等待1?(FIN-WAIT-1)狀態。?

2）服務器收到連接釋放報文(FIN),發出確認報文ACK=1，ack=u+1，并且帶上自己的序列號seq=v，此時，服務端就進入了關閉等待(CLOSE-WAIT )狀態。服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個關閉等待(CLOSE-WAIT )狀態持續的時間。

3）客戶端收到服務器的確認請求后，此時，客戶端就進入終止等待2(FIN-WAIT-2 )狀態，等待服務器發送連接釋放報文

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

5）客戶端收到服務器的連接釋放報文(FIN)后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了時間等待(TIME-WAIT)狀態。注意此時TCP連接還沒有釋放，?客戶端等待 2MSL（最長報文段壽命)后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。

6）服務器只要收到了客戶端發出的確認，立即進入CLOSED狀態。同樣，撤銷TCB后，就結束了這次的TCP連接。可以看到，服務器結束TCP連接的時間要比客戶端早一些。

問題：

為什么連接的時候是三次握手，關閉的時候卻是四次握手？

服務器收到對方的FIN報文時，僅僅表示對方不再發送數據了但是還能接收數據，而自己也未必全部數據都發送給對方了，所以己方可以立即關閉，也可以發送一些數據給對方后，再發送FIN報文給對方來表示同意現在關閉連接，因此，己方ACK和FIN一般都會分開發送，從而導致多了一次

為什么客戶端最后還要等待2MSL（最長報文段壽命 ）？

保證客戶端發送的最后一個ACK報文能夠到達服務器，因為這個ACK報文可能丟失?。如果丟失了，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端還沒有給我回應，應該是我發送的請求斷開報文它沒有收到，于是服務器又會重新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，并且會重啟2MSL計時器

如果已經建立了連接，但是客戶端突然出現故障了怎么辦？

TCP還設有一個保活計時器，服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數據，服務器就會發送一個探測報文段，以后每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

?

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。