30 道計(jì)算機(jī)網(wǎng)絡(luò)常考面試題總結(jié)

“

前面已經(jīng)寫過兩篇計(jì)算機(jī)網(wǎng)絡(luò)文章，涉及內(nèi)容較多較雜，因此爆肝總結(jié)了30道計(jì)網(wǎng)常考面試題進(jìn)行針對(duì)性復(fù)習(xí)，幫助大家更好的理解。

1、為什么TCP連接的時(shí)候是3次？2次不可以嗎？

考慮丟包問題

1. 因?yàn)樾枰紤]連接時(shí)丟包的問題，如果只握手2次，第二次握手時(shí)如果服務(wù)端發(fā)給客戶端的確認(rèn)報(bào)文段丟失，此時(shí)服務(wù)端已經(jīng)準(zhǔn)備好了收發(fā)數(shù)(可以理解服務(wù)端已經(jīng)連接成功)據(jù)，而客戶端一直沒收到服務(wù)端的確認(rèn)報(bào)文，所以客戶端就不知道服務(wù)端是否已經(jīng)準(zhǔn)備好了(可以理解為客戶端未連接成功)，這種情況下客戶端不會(huì)給服務(wù)端發(fā)數(shù)據(jù)，也會(huì)忽略服務(wù)端發(fā)過來的數(shù)據(jù)。

2. 如果是三次握手，即便發(fā)生丟包也不會(huì)有問題，比如如果第三次握手客戶端發(fā)的確認(rèn)ack報(bào)文丟失，服務(wù)端在一段時(shí)間內(nèi)沒有收到確認(rèn)ack報(bào)文的話就會(huì)重新進(jìn)行第二次握手，也就是服務(wù)端會(huì)重發(fā)SYN報(bào)文段，客戶端收到重發(fā)的報(bào)文段后會(huì)再次給服務(wù)端發(fā)送確認(rèn)ack報(bào)文。

保證序列號(hào)雙方確認(rèn)

1. 為了實(shí)現(xiàn)可靠數(shù)據(jù)傳輸， TCP 協(xié)議的通信雙方， 都必須維護(hù)一個(gè)序列號(hào)， 以標(biāo)識(shí)發(fā)送出去的數(shù)據(jù)包中， 哪些是已經(jīng)被對(duì)方收到的。三次握手的過程即是通信雙方相互告知序列號(hào)起始值， 并確認(rèn)對(duì)方已經(jīng)收到了序列號(hào)起始值的必經(jīng)步驟
2. 如果只是兩次握手， 至多只有連接發(fā)起方的起始序列號(hào)能被確認(rèn)， 另一方選擇的序列號(hào)則得不到確認(rèn)

2、為什么TCP連接的時(shí)候是3次，關(guān)閉的時(shí)候卻是4次？

因?yàn)橹挥性诳蛻舳撕头?wù)端都沒有數(shù)據(jù)要發(fā)送的時(shí)候才能斷開TCP。而客戶端發(fā)出FIN報(bào)文時(shí)只能保證客戶端沒有數(shù)據(jù)發(fā)了，服務(wù)端還有沒有數(shù)據(jù)發(fā)客戶端是不知道的。而服務(wù)端收到客戶端的FIN報(bào)文后只能先回復(fù)客戶端一個(gè)確認(rèn)報(bào)文來告訴客戶端我服務(wù)端已經(jīng)收到你的FIN報(bào)文了，但我服務(wù)端還有一些數(shù)據(jù)沒發(fā)完，等這些數(shù)據(jù)發(fā)完了服務(wù)端才能給客戶端發(fā)FIN報(bào)文(所以不能一次性將確認(rèn)報(bào)文和FIN報(bào)文發(fā)給客戶端，就是這里多出來了一次)。

3、為什么客戶端發(fā)出第四次揮手的確認(rèn)報(bào)文后要等2MSL的時(shí)間才能釋放TCP連接？

這里同樣是要考慮丟包的問題，如果第四次揮手的報(bào)文丟失，服務(wù)端沒收到確認(rèn)ack報(bào)文就會(huì)重發(fā)第三次揮手的報(bào)文，這樣報(bào)文一去一回最長時(shí)間就是2MSL，所以需要等這么長時(shí)間來確認(rèn)服務(wù)端確實(shí)已經(jīng)收到了。

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

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

5、time wait過多會(huì)出現(xiàn)什么問題？

對(duì)于網(wǎng)站來說，這樣的time_wait略顯偏高, 也就是說大量的關(guān)閉操作在等待2個(gè)MSL后結(jié)束，正常我們的tcp 端口是65535個(gè)，如果并發(fā)再高一些，可能會(huì)大量的socket不能及時(shí)被釋放，從而導(dǎo)致性能下降，

在高并發(fā)短連接的TCP服務(wù)器上，當(dāng)服務(wù)器處理完請(qǐng)求后立刻主動(dòng)正常關(guān)閉連接。這個(gè)場(chǎng)景下會(huì)出現(xiàn)大量socket處于TIME_WAIT狀態(tài)。如果客戶端的并發(fā)量持續(xù)很高，此時(shí)部分客戶端就會(huì)顯示連接不上。

所以我們可以通過linux內(nèi)核進(jìn)行一些網(wǎng)絡(luò)調(diào)整比如，開啟socket重用和快速回收

6、CLOSE_WAIT 過多會(huì)出現(xiàn)什么問題？

CLOSE_WAIT 過多導(dǎo)致服務(wù)器資源占用，客戶端在 FIN_WAIT_2 狀態(tài)超時(shí)大約 60s，自動(dòng)進(jìn)入 CLOSED狀態(tài)， 影響不大。但是服務(wù)端在 CLOSE_WAIT 的超時(shí)時(shí)間默認(rèn)為 43200秒，所以大量的 CLOSE_WAIT 積壓可能造成服務(wù)器無法分配出資源給新的連接。一般這種情況都是由于服務(wù)器沒有調(diào)用 close 造成的。程序員應(yīng)該主動(dòng)檢查代碼。

7、什么是HTTP、HTTPS？

1. HTTP 是一個(gè)在計(jì)算機(jī)世界里專門在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范

• 端口 ：HTTP的URL由“http://”起始且默認(rèn)使用端口80，而HTTPS的URL由“https://”起始且默認(rèn)使用端口443。
• 安全性和資源消耗：HTTP協(xié)議運(yùn)行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對(duì)方的身份。

1. HTTPS中的S表示SSL或者TLS，就是在原HTTP的基礎(chǔ)上加上一層用于數(shù)據(jù)加密、解密、身份認(rèn)證的安全層。HTTPS是運(yùn)行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運(yùn)行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對(duì)稱加密，但對(duì)稱加密的密鑰用服務(wù)器方的證書進(jìn)行了非對(duì)稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費(fèi)更多服務(wù)器資源。

• 對(duì)稱加密：密鑰只有一個(gè)，加密解密為同一個(gè)密碼，且加解密速度快，典型的對(duì)稱加密算法有DES、AES等；
• 非對(duì)稱加密：加密和解密使用不同的密鑰，這兩個(gè)密鑰形成有且僅有唯一的配對(duì)，叫公鑰和私鑰。數(shù)據(jù)用公鑰加密后必須用私鑰解密，數(shù)據(jù)用私鑰加密后必須用公鑰解密，相對(duì)對(duì)稱加密速度較慢，典型的非對(duì)稱加密算法有RSA、DSA等。

8、HTTP 與 HTTPS 的區(qū)別？

• https協(xié)議需要到ca申請(qǐng)證書，一般免費(fèi)證書很少，需要交費(fèi)。
• http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議。
• http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
• http的連接很簡(jiǎn)單,是無狀態(tài)的 。
• HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議， 要比http協(xié)議安全。

9、GET和POST區(qū)別？

瀏覽器和服務(wù)器的交互是通過HTTP協(xié)議執(zhí)行的，HTTP全稱為Hyper Text Transfer Protocol，中文翻譯為超文本傳輸協(xié)議，目的是保證瀏覽器與服務(wù)器之間的通信。而GET和POST也是HTTP協(xié)議中的兩種方法。

• GET：從服務(wù)器上獲取數(shù)據(jù)，也就是所謂的查，僅僅是獲取服務(wù)器資源，不進(jìn)行修改。
• POST：向服務(wù)器提交數(shù)據(jù)，這就涉及到了數(shù)據(jù)的更新，也就是更改服務(wù)器的數(shù)據(jù)。

區(qū)別

• get 方法一般用于請(qǐng)求，比如你在瀏覽器地址欄輸入 www.cxuanblog.com 其實(shí)就是發(fā)送了一個(gè) get 請(qǐng)求，它的主要特征是請(qǐng)求服務(wù)器返回資源，而 post 方法一般用于```表單`的提交，相當(dāng)于是把信息提交給服務(wù)器，等待服務(wù)器作出響應(yīng)，get 相當(dāng)于一個(gè)是 pull/拉的操作，而 post 相當(dāng)于是一個(gè) push/推的操作。
• get 方法是不安全的，因?yàn)槟阍诎l(fā)送請(qǐng)求的過程中，你的請(qǐng)求參數(shù)會(huì)拼在 URL 后面，從而導(dǎo)致容易被攻擊者竊取，對(duì)你的信息造成破壞和偽造；而 post 方法是把參數(shù)放在請(qǐng)求體 body 中的，這對(duì)用戶來說不可見。
• get 請(qǐng)求的 URL 有長度限制，這個(gè)限制是瀏覽器或者服務(wù)器給添加的，http協(xié)議并沒有對(duì)url長度進(jìn)行限制，目的是為了保證服務(wù)器和瀏覽器能夠正常運(yùn)行，防止有人惡意發(fā)送請(qǐng)求。而 post 請(qǐng)求會(huì)把參數(shù)和值放在消息體中，對(duì)數(shù)據(jù)長度沒有要求。
• get 請(qǐng)求會(huì)被瀏覽器主動(dòng) cache，而 post 不會(huì)，除非手動(dòng)設(shè)置。
• get 請(qǐng)求在發(fā)送過程中會(huì)產(chǎn)生一個(gè) TCP 數(shù)據(jù)包；post 在發(fā)送過程中會(huì)產(chǎn)生兩個(gè) TCP 數(shù)據(jù)包。對(duì)于 get 方式的請(qǐng)求，瀏覽器會(huì)把 http header 和 data 一并發(fā)送出去，服務(wù)器響應(yīng) 200（返回?cái)?shù)據(jù)）；而對(duì)于 post，瀏覽器先發(fā)送 header，服務(wù)器響應(yīng) 100 continue，瀏覽器再發(fā)送 data，服務(wù)器響應(yīng) 200 ok（返回?cái)?shù)據(jù)）。

10、瀏覽器關(guān)閉后,session還可以用嗎？

當(dāng)我們重新打開瀏覽器窗口時(shí)，之前的Cookie中存放的Sessionid已經(jīng)不存在了，此時(shí)

服務(wù)器從HttpServletRequest對(duì)象中沒有檢查到sessionid，服務(wù)器會(huì)再發(fā)送一個(gè)新的存

有Sessionid的Cookie到客戶端的瀏覽器中，此時(shí)對(duì)應(yīng)的是一個(gè)新的會(huì)話，而服務(wù)器上

原先的session等到它的默認(rèn)時(shí)間到之后，便會(huì)自動(dòng)銷毀。

當(dāng)在同一個(gè)瀏覽器中同時(shí)打開多個(gè)標(biāo)簽，發(fā)送同一個(gè)請(qǐng)求或不同的請(qǐng)求，仍是同一個(gè)session;

當(dāng)不在同一個(gè)窗口中打開相同的瀏覽器時(shí)，發(fā)送請(qǐng)求，仍是同一個(gè)session;

當(dāng)使用不同的瀏覽器時(shí)，發(fā)送請(qǐng)求，即使發(fā)送相同的請(qǐng)求，是不同的session;

11、如果客戶端禁止 cookie 能實(shí)現(xiàn) session 還能用嗎？

Cookie 與 Session，一般認(rèn)為是兩個(gè)獨(dú)立的東西，Session采用的是在服務(wù)器端保持狀態(tài)的方案，而Cookie采用的是在客戶端保持狀態(tài)的方案。

但為什么禁用Cookie就不能得到Session呢？因?yàn)镾ession是用Session ID來確定當(dāng)前對(duì)話所對(duì)應(yīng)的服務(wù)器Session，而Session ID是通過Cookie來傳遞的，禁用Cookie相當(dāng)于失去了Session ID，也就得不到Session了。

假定用戶關(guān)閉Cookie的情況下使用Session，其實(shí)現(xiàn)途徑有以下幾種：

• 最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。
• 用文件、數(shù)據(jù)庫等形式保存Session ID，在跨頁過程中手動(dòng)調(diào)用

12、介紹下了解的通信協(xié)議？

FTP ? ?文件傳輸協(xié)議（File Transfer Protocol）

SMTP：郵件傳送協(xié)議，

ARP ? ?協(xié)議是正向地址解析協(xié)議（Address Resolution Protocol），通過已知的 IP，尋找對(duì)應(yīng)主機(jī)的 MAC 地址

RARP ?協(xié)議是方向地址解析協(xié)議，通過 MAC 地址確定 IP地址

13、什么是ARP/RARP協(xié)議？

地址解析協(xié)議，即ARP（Address Resolution Protocol），是根據(jù)IP地址獲取物理地址的一個(gè)TCP/IP協(xié)議。主機(jī)發(fā)送信息時(shí)將包含目標(biāo)IP地址的ARP請(qǐng)求廣播到網(wǎng)絡(luò)上的所有主機(jī)，并接收返回消息，以此確定目標(biāo)的物理地址；收到返回消息后將該IP地址和物理地址存入本機(jī)ARP緩存中并保留一定時(shí)間，下次請(qǐng)求時(shí)直接查詢ARP緩存以節(jié)約資源。

逆地址解析協(xié)議，即RARP，功能和ARP協(xié)議相對(duì)，其將局域網(wǎng)中某個(gè)主機(jī)的物理地址轉(zhuǎn)換為IP地址，比如局域網(wǎng)中有一臺(tái)主機(jī)只知道物理地址而不知道IP地址，那么可以通過RARP協(xié)議發(fā)出征求自身IP地址的廣播請(qǐng)求，然后由RARP服務(wù)器負(fù)責(zé)回答。

14、地址欄輸入 URL 發(fā)生了什么

“

常考面試題，回答注意兩點(diǎn)，1是注意回答的條理性，2是注意回答內(nèi)容盡量詳細(xì)，展現(xiàn)知識(shí)的寬度和深度

• 首先，你需要在瀏覽器中的 URL 地址上，輸入你想訪問的地址，比如www.baidu.com

• 然后，瀏覽器會(huì)根據(jù)你輸入的 URL 地址，去查找域名是否被本地 DNS 緩存，不同瀏覽器對(duì) DNS 的設(shè)置不同，如果瀏覽器緩存了你想訪問的 URL 地址，那就直接返回 ip。如果沒有緩存你的 URL 地址，瀏覽器就會(huì)發(fā)起系統(tǒng)調(diào)用來查詢本機(jī) hosts 文件是否有配置 ip 地址，如果找到，直接返回。如果找不到，就向網(wǎng)絡(luò)中發(fā)起一個(gè) DNS 查詢。在由根域名服務(wù)器 -> 頂級(jí)域名服務(wù)器 -> 權(quán)威 DNS 服務(wù)器后，由權(quán)威服務(wù)器告訴本地服務(wù)器目標(biāo) IP 地址，再有本地 DNS 服務(wù)器告訴用戶需要訪問的 IP 地址。

• “

  DNS是域名系統(tǒng)(DomainNameSystem)的縮寫，該系統(tǒng)用于命名組織到域?qū)哟谓Y(jié)構(gòu)中的計(jì)算機(jī)和網(wǎng)絡(luò)服務(wù)，可以簡(jiǎn)單地理解為將URL轉(zhuǎn)換為IP地址。

• 第三步，瀏覽器需要和目標(biāo)服務(wù)器建立 TCP 連接，需要經(jīng)過三次握手的過程，TCP/IP 分為四層，在發(fā)送數(shù)據(jù)時(shí)，每層都要對(duì)數(shù)據(jù)進(jìn)行封裝：

  • 將數(shù)據(jù)段打包，并加入源及目標(biāo)的IP地址，并且負(fù)責(zé)尋找傳輸路線。
  • 判斷目標(biāo)地址是否與當(dāng)前地址處于同一網(wǎng)絡(luò)中，是的話直接根據(jù) Mac 地址發(fā)送，否則使用路由表查找下一跳地址，以及使用 ARP 協(xié)議查詢它的 Mac 地址。
  • 傳輸層會(huì)發(fā)起一條到達(dá)服務(wù)器的 TCP 連接，為了方便傳輸，會(huì)對(duì)數(shù)據(jù)進(jìn)行分割（以報(bào)文段為單位），并標(biāo)記編號(hào)，方便服務(wù)器接受時(shí)能夠準(zhǔn)確地還原報(bào)文信息。
  • 請(qǐng)求報(bào)頭（Request Header）：請(qǐng)求方法、目標(biāo)地址、遵循的協(xié)議等等
  • 請(qǐng)求主體（其他參數(shù)）
  • 1. 應(yīng)用層：發(fā)送 HTTP 請(qǐng)求
  • 在前面的步驟我們已經(jīng)得到服務(wù)器的 IP 地址，瀏覽器會(huì)開始構(gòu)造一個(gè) HTTP 報(bào)文，其中包括：
  • 2. 傳輸層：TCP 傳輸報(bào)文
  • 3. 網(wǎng)絡(luò)層：IP協(xié)議查詢Mac地址
  • 4. 鏈路層：以太網(wǎng)協(xié)議

• 在建立連接后，瀏覽器會(huì)向目標(biāo)服務(wù)器發(fā)起 HTTP-GET 請(qǐng)求，包括其中的 URL，HTTP 1.1 后默認(rèn)使用長連接，只需要一次握手即可多次傳輸數(shù)據(jù)。

• 如果目標(biāo)服務(wù)器只是一個(gè)簡(jiǎn)單的頁面，就會(huì)直接返回。但是對(duì)于某些大型網(wǎng)站的站點(diǎn)，往往不會(huì)直接返回主機(jī)名所在的頁面，而會(huì)直接重定向。返回的狀態(tài)碼就不是 200 ，而是 301,302 以 3 開頭的重定向碼，瀏覽器在獲取了重定向響應(yīng)后，在響應(yīng)報(bào)文中 Location 項(xiàng)找到重定向地址，瀏覽器重新第一步訪問即可。

• 然后瀏覽器重新發(fā)送請(qǐng)求，攜帶新的 URL，返回狀態(tài)碼 200 OK，表示服務(wù)器可以響應(yīng)請(qǐng)求，返回報(bào)文。

• 渲染頁面

15、中間人有可能篡改該證書嗎？

假設(shè)中間人篡改了證書的原文，由于他沒有CA機(jī)構(gòu)的私鑰，所以無法得到此時(shí)加密后簽名，無法相應(yīng)地篡改簽名。瀏覽器收到該證書后會(huì)發(fā)現(xiàn)原文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務(wù)器傳輸信息，防止信息泄露給中間人。

16、中間人有可能把證書掉包嗎？

1. 假設(shè)有另一個(gè)網(wǎng)站B也拿到了CA機(jī)構(gòu)認(rèn)證的證書，它想搞垮網(wǎng)站A，想劫持網(wǎng)站A的信息。于是它成為中間人攔截到了A傳給瀏覽器的證書，然后替換成自己的證書，傳給瀏覽器，之后瀏覽器就會(huì)錯(cuò)誤地拿到B的證書里的公鑰了，會(huì)導(dǎo)致上文提到的漏洞。
2. 其實(shí)這并不會(huì)發(fā)生，因?yàn)樽C書里包含了網(wǎng)站A的信息，包括域名，瀏覽器把證書里的域名與自己請(qǐng)求的域名比對(duì)一下就知道有沒有被掉包了。

17、為什么制作數(shù)字簽名時(shí)需要hash一次？

“

我初學(xué)HTTPS的時(shí)候就有這個(gè)問題，似乎以上過程中hash有點(diǎn)多余，把hash過程去掉也能保證證書沒有被篡改。

最顯然的是性能問題，前面我們已經(jīng)說了非對(duì)稱加密效率較差，證書信息一般較長，比較耗時(shí)。而hash后得到的是固定長度的信息（比如用md5算法hash后可以得到固定的128位的值），這樣加密解密就會(huì)快很多。

18、http協(xié)議實(shí)現(xiàn)了什么？

1. 客戶與服務(wù)器建立連接tcp
2. 客戶向服務(wù)器提出請(qǐng)求
3. 服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的文件作為應(yīng)答
4. 客戶與服務(wù)器關(guān)閉連接。

19、什么是無狀態(tài)協(xié)議，HTTP 是無狀態(tài)協(xié)議嗎，怎么解決？

1. 無狀態(tài)協(xié)議(Stateless Protocol) 就是指瀏覽器對(duì)于事務(wù)的處理沒有記憶能力。舉個(gè)例子來說就是比如客戶請(qǐng)求獲得網(wǎng)頁之后關(guān)閉瀏覽器，然后再次啟動(dòng)瀏覽器，登錄該網(wǎng)站，但是服務(wù)器并不知道客戶關(guān)閉了一次瀏覽器。

2. HTTP 就是一種無狀態(tài)的協(xié)議，他對(duì)用戶的操作沒有記憶能力。可能大多數(shù)用戶不相信，他可能覺得每次輸入用戶名和密碼登陸一個(gè)網(wǎng)站后，下次登陸就不再重新輸入用戶名和密碼了。這其實(shí)不是 HTTP 做的事情，起作用的是一個(gè)叫做 小甜餅(Cookie)的機(jī)制。它能夠讓瀏覽器具有記憶能力。

3. 那么我們保存用戶狀態(tài)呢？Session 機(jī)制的存在就是為了解決這個(gè)問題，Session 的主要作用就是通過服務(wù)端記錄用戶的狀態(tài)session登錄的認(rèn)證方案是看，用戶從客戶端傳遞用戶名和密碼登錄信息，服務(wù)端認(rèn)證后將信息儲(chǔ)存在session中，將session_id放入cookie中，以后訪問其他頁面，服務(wù)器都會(huì)帶著cookie，服務(wù)端會(huì)自動(dòng)從cookie中獲取session_id,在從session中獲取認(rèn)證信息。

4. 在服務(wù)端保存 Session 的方法很多，最常用的就是內(nèi)存和數(shù)據(jù)庫(比如是使用內(nèi)存數(shù)據(jù)庫redis保存)。既然 Session 存放在服務(wù)器端，那么我們?nèi)绾螌?shí)現(xiàn) Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個(gè) Session ID 來方式來跟蹤。

20、為什么使用非對(duì)稱加密和對(duì)稱加密？

對(duì)稱加密的問題在于這個(gè)密鑰怎么讓傳輸?shù)碾p方知曉，同時(shí)不被別人知道，依賴于非對(duì)稱加密將秘鑰進(jìn)行傳輸，非對(duì)稱加密耗時(shí)，所以采用非對(duì)稱加密和對(duì)稱加密組合的方式

21、TCP粘包是什么？

TCP粘包是指發(fā)送方發(fā)送的若干包數(shù)據(jù)到接收方接收時(shí)粘成一包，從接收緩沖區(qū)看，后一包數(shù)據(jù)的頭緊接著前一包數(shù)據(jù)的尾。

22、什么時(shí)候需要考慮粘包問題？

1. 如果利用tcp每次發(fā)送數(shù)據(jù)，就與對(duì)方建立連接，然后雙方發(fā)送完一段數(shù)據(jù)后，就關(guān)閉連接，這樣就不會(huì)出現(xiàn)粘包問題（因?yàn)橹挥幸环N包結(jié)構(gòu),類似于http協(xié)議）。

• 關(guān)閉連接主要是要雙方都發(fā)送close連接（參考tcp關(guān)閉協(xié)議）。如：A需要發(fā)送一段字符串給B，那么A與B建立連接，然后發(fā)送雙方都默認(rèn)好的協(xié)議字符如"hello give me sth abour yourself"，然后B收到報(bào)文后，就將緩沖區(qū)數(shù)據(jù)接收，然后關(guān)閉連接，這樣粘包問題不用考慮到，因?yàn)榇蠹叶贾朗前l(fā)送一段字符。

1. 如果發(fā)送數(shù)據(jù)無結(jié)構(gòu)，如文件傳輸，這樣發(fā)送方只管發(fā)送，接收方只管接收存儲(chǔ)就ok，也不用考慮粘包

2. 如果雙方建立連接，需要在連接后一段時(shí)間內(nèi)發(fā)送不同結(jié)構(gòu)數(shù)據(jù)，如連接后，有好幾種結(jié)構(gòu)，一般可能會(huì)在頭加一個(gè)數(shù)據(jù)長度之類的包，以確保接收

23、粘包出現(xiàn)原因？

出現(xiàn)粘包現(xiàn)象的原因是多方面的，它既可能由發(fā)送方造成，也可能由接收方造成。簡(jiǎn)單得說，在流傳輸中出現(xiàn)，UDP不會(huì)出現(xiàn)粘包，因?yàn)樗?strong style="color:rgb(71,193,168);">消息邊界(參考Windows網(wǎng)絡(luò)編程)

1. 發(fā)送端需要等緩沖區(qū)滿才發(fā)送出去，造成粘包

2. 接收方不及時(shí)接收緩沖區(qū)的包，造成多個(gè)包接收

具體來講：

1. 發(fā)送方引起的粘包是由TCP協(xié)議本身造成的，TCP為提高傳輸效率，發(fā)送方往往要收集到足夠多的數(shù)據(jù)后才發(fā)送一包數(shù)據(jù)。若連續(xù)幾次發(fā)送的數(shù)據(jù)都很少，通常TCP會(huì)根據(jù)優(yōu)化算法把這些數(shù)據(jù)合成一包后一次發(fā)送出去，這樣接收方就收到了粘包數(shù)據(jù)。

2. 接收方引起的粘包是由于接收方用戶進(jìn)程不及時(shí)接收數(shù)據(jù)，從而導(dǎo)致粘包現(xiàn)象。這是因?yàn)榻邮辗较劝咽盏降臄?shù)據(jù)放在系統(tǒng)接收緩沖區(qū)，用戶進(jìn)程從該緩沖區(qū)取數(shù)據(jù)，若下一包數(shù)據(jù)到達(dá)時(shí)前一包數(shù)據(jù)尚未被用戶進(jìn)程取走，則下一包數(shù)據(jù)放到系統(tǒng)接收緩沖區(qū)時(shí)就接到前一包數(shù)據(jù)之后，而用戶進(jìn)程根據(jù)預(yù)先設(shè)定的緩沖區(qū)大小從系統(tǒng)接收緩沖區(qū)取數(shù)據(jù)，這樣就一次取到了多包數(shù)據(jù)。

3. 粘包情況有兩種，一種是粘在一起的包都是完整的數(shù)據(jù)包，另一種情況是粘在一起的包有不完整的包。

4. 不是所有的粘包現(xiàn)象都需要處理，若傳輸?shù)臄?shù)據(jù)為不帶結(jié)構(gòu)的連續(xù)流數(shù)據(jù)（如文件傳輸），則不必把粘連的包分開（簡(jiǎn)稱分包）。但在實(shí)際工程應(yīng)用中，傳輸?shù)臄?shù)據(jù)一般為帶結(jié)構(gòu)的數(shù)據(jù)，這時(shí)就需要做分包處理。

5. 在處理定長結(jié)構(gòu)數(shù)據(jù)的粘包問題時(shí)，分包算法比較簡(jiǎn)單；在處理不定長結(jié)構(gòu)數(shù)據(jù)的粘包問題時(shí)，分包算法就比較復(fù)雜。特別是粘在一起的包有不完整的包的粘包情況，由于一包數(shù)據(jù)內(nèi)容被分在了兩個(gè)連續(xù)的接收包中，處理起來難度較大。實(shí)際工程應(yīng)用中應(yīng)盡量避免出現(xiàn)粘包現(xiàn)象。

24、如何避免粘包問題？

1. 對(duì)于發(fā)送方引起的粘包現(xiàn)象，用戶可通過編程設(shè)置來避免，TCP提供了強(qiáng)制數(shù)據(jù)立即傳送的操作指令push，TCP軟件收到該操作指令后，就立即將本段數(shù)據(jù)發(fā)送出去，而不必等待發(fā)送緩沖區(qū)滿；

2. 對(duì)于接收方引起的粘包，則可通過優(yōu)化程序設(shè)計(jì)、精簡(jiǎn)接收進(jìn)程工作量、提高接收進(jìn)程優(yōu)先級(jí)等措施，使其及時(shí)接收數(shù)據(jù)，從而盡量避免出現(xiàn)粘包現(xiàn)象；

3. 由接收方控制，將一包數(shù)據(jù)按結(jié)構(gòu)字段，人為控制分多次接收，然后合并，通過這種手段來避免粘包。

以上提到的三種措施，都有其不足之處。

1. 第一種編程設(shè)置方法雖然可以避免發(fā)送方引起的粘包，但它關(guān)閉了優(yōu)化算法，降低了網(wǎng)絡(luò)發(fā)送效率，影響應(yīng)用程序的性能，一般不建議使用。

2. 第二種方法只能減少出現(xiàn)粘包的可能性，但并不能完全避免粘包，當(dāng)發(fā)送頻率較高時(shí)，或由于網(wǎng)絡(luò)突發(fā)可能使某個(gè)時(shí)間段數(shù)據(jù)包到達(dá)接收方較快，接收方還是有可能來不及接收，從而導(dǎo)致粘包。

3. 第三種方法雖然避免了粘包，但應(yīng)用程序的效率較低，對(duì)實(shí)時(shí)應(yīng)用的場(chǎng)合不適合。

一種比較周全的對(duì)策是：接收方創(chuàng)建一預(yù)處理線程，對(duì)接收到的數(shù)據(jù)包進(jìn)行預(yù)處理，將粘連的包分開。

25、講一講拆包？

對(duì)于拆包目前最常用的是以下兩種方式：

1、動(dòng)態(tài)緩沖區(qū)暫存方式。

之所以說緩沖區(qū)是動(dòng)態(tài)的是因?yàn)?strong style="color:rgb(71,193,168);">當(dāng)需要緩沖的數(shù)據(jù)長度超出緩沖區(qū)的長度時(shí)會(huì)增大緩沖區(qū)長度。大概過程描述如下:

1. 為每一個(gè)連接動(dòng)態(tài)分配一個(gè)緩沖區(qū),同時(shí)把此緩沖區(qū)和SOCKET關(guān)聯(lián),常用的是通過結(jié)構(gòu)體關(guān)聯(lián).

2. 當(dāng)接收到數(shù)據(jù)時(shí)首先把此段數(shù)據(jù)存放在緩沖區(qū)中.

3. 判斷緩存區(qū)中的數(shù)據(jù)長度是否夠一個(gè)包頭的長度,如不夠,則不進(jìn)行拆包操作.

4. 根據(jù)包頭數(shù)據(jù)解析出里面代表包體長度的變量.

5. 判斷緩存區(qū)中除包頭外的數(shù)據(jù)長度是否夠一個(gè)包體的長度,如不夠,則不進(jìn)行拆包操作.

6. 取出整個(gè)數(shù)據(jù)包.這里的"取"的意思是不光從緩沖區(qū)中拷貝出數(shù)據(jù)包,而且要把此數(shù)據(jù)包從緩存區(qū)中刪除掉.刪除的辦法就是把此包后面的數(shù)據(jù)移動(dòng)到緩沖區(qū)的起始地址.

這種方法有兩個(gè)缺點(diǎn)：

1. 為每個(gè)連接動(dòng)態(tài)分配一個(gè)緩沖區(qū)增大了內(nèi)存的使用.

2. 有三個(gè)地方需要拷貝數(shù)據(jù),一個(gè)地方是把數(shù)據(jù)存放在緩沖區(qū),一個(gè)地方是把完整的數(shù)據(jù)包從緩沖區(qū)取出來,一個(gè)地方是把數(shù)據(jù)包從緩沖區(qū)中刪除.第二種拆包的方法會(huì)解決和完善這些缺點(diǎn).

可以采用環(huán)形緩沖進(jìn)行改善，環(huán)形緩沖實(shí)現(xiàn)方案是定義兩個(gè)指針,分別指向有效數(shù)據(jù)的頭和尾.在存放數(shù)據(jù)和刪除數(shù)據(jù)時(shí)只是進(jìn)行頭尾指針的移動(dòng)。但是這種改進(jìn)方法還是不能解決第一個(gè)缺點(diǎn)以及第一個(gè)數(shù)據(jù)拷貝,只能解決第三個(gè)地方的數(shù)據(jù)拷貝(這個(gè)地方是拷貝數(shù)據(jù)最多的地方).第2種拆包方式會(huì)解決這兩個(gè)問題.

2、利用底層的緩沖區(qū)來進(jìn)行拆包

1. 由于TCP也維護(hù)了一個(gè)緩沖區(qū),所以我們完全可以利用TCP的緩沖區(qū)來緩存我們的數(shù)據(jù)，這樣一來就不需要為每一個(gè)連接分配一個(gè)緩沖區(qū)了。另一方面我們知道recv或者wsarecv都有一個(gè)參數(shù),用來表示我們要接收多長長度的數(shù)據(jù)。利用這兩個(gè)條件我們就可以對(duì)第一種方法進(jìn)行優(yōu)化。

2. 對(duì)于阻塞SOCKET來說，我們可以利用一個(gè)循環(huán)來接收包頭長度的數(shù)據(jù)，然后解析出代表包體長度的那個(gè)變量，再用一個(gè)循環(huán)來接收包體長度的數(shù)據(jù)。

26、講一下HTTP 請(qǐng)求頁面的過程？

• 有了 HTTP 服務(wù)器的 IP 地址之后，主機(jī)就能夠生成 TCP 套接字，該套接字將用于向 Web 服務(wù)器發(fā)送 HTTP GET 報(bào)文。
• 在生成 TCP 套接字之前，必須先與 HTTP 服務(wù)器進(jìn)行三次握手來建立連接。生成一個(gè)具有目的端口 80 的 TCP SYN 報(bào)文段，并向 HTTP 服務(wù)器發(fā)送該報(bào)文段。
• HTTP 服務(wù)器收到該報(bào)文段之后，生成 TCP SYN ACK 報(bào)文段，發(fā)回給主機(jī)。
• 連接建立之后，瀏覽器生成 HTTP GET 報(bào)文，并交付給 HTTP 服務(wù)器。
• HTTP 服務(wù)器從 TCP 套接字讀取 HTTP GET 報(bào)文，生成一個(gè) HTTP 響應(yīng)報(bào)文，將 Web 頁面內(nèi)容放入報(bào)文主體中，發(fā)回給主機(jī)。
• 瀏覽器收到 HTTP 響應(yīng)報(bào)文后，抽取出 Web 頁面內(nèi)容，之后進(jìn)行渲染，顯示 Web 頁面。

27、有哪些方面的因素會(huì)導(dǎo)致網(wǎng)站訪問慢？

1. 服務(wù)器出口帶寬不夠用

1. 本身服務(wù)器購買的出口帶寬比較。一旦并發(fā)量大的話，就會(huì)造成分給每個(gè)用戶的出口帶寬就小，訪問速度自然就會(huì)慢。

2. 跨運(yùn)營商網(wǎng)絡(luò)導(dǎo)致帶寬縮減。例如，公司網(wǎng)站放在電信的網(wǎng)絡(luò)上，那么客戶這邊對(duì)接是長城寬帶或聯(lián)通，這也可能導(dǎo)致帶寬的縮減。

2. 服務(wù)器負(fù)載過大，導(dǎo)致響應(yīng)不過來

可以從兩個(gè)方面入手分析：

1. 分析系統(tǒng)負(fù)載，使用 w 命令或者 uptime 命令查看系統(tǒng)負(fù)載。如果負(fù)載很高，則使用 top 命令查看 CPU ，MEM 等占用情況，要么是 CPU 繁忙，要么是內(nèi)存不夠。
2. 如果這二者都正常，再去使用 sar 命令分析網(wǎng)卡流量，分析是不是遭到了攻擊。一旦分析出問題的原因，采取對(duì)應(yīng)的措施解決，如決定要不要?dú)⑺酪恍┻M(jìn)程，或者禁止一些訪問等。

3. 數(shù)據(jù)庫瓶頸

1. 如果慢查詢比較多。那么就要開發(fā)人員或 DBA 協(xié)助進(jìn)行 SQL 語句的優(yōu)化。
2. 如果數(shù)據(jù)庫響應(yīng)慢，考慮可以加一個(gè)數(shù)據(jù)庫緩存，如 Redis 等。然后，也可以搭建 MySQL 主從，一臺(tái) MySQL 服務(wù)器負(fù)責(zé)寫，其他幾臺(tái)從數(shù)據(jù)庫負(fù)責(zé)讀。

4. 網(wǎng)站開發(fā)代碼沒有優(yōu)化好

例如 SQL 語句沒有優(yōu)化，導(dǎo)致數(shù)據(jù)庫讀寫相當(dāng)耗時(shí)。

28、針對(duì)網(wǎng)站訪問慢，怎么去排查？

1. 首先要確定是用戶端還是服務(wù)端的問題。當(dāng)接到用戶反饋訪問慢，那邊自己立即訪問網(wǎng)站看看，如果自己這邊訪問快，基本斷定是用戶端問題，就需要耐心跟客戶解釋，協(xié)助客戶解決問題。

“

不要上來就看服務(wù)端的問題。一定要從源頭開始，逐步逐步往下。

1. 如果訪問也慢，那么可以利用瀏覽器的調(diào)試功能，看看加載那一項(xiàng)數(shù)據(jù)消耗時(shí)間過多，是圖片加載慢，還是某些數(shù)據(jù)加載慢。

2. 針對(duì)服務(wù)器負(fù)載情況。?查看服務(wù)器硬件(網(wǎng)絡(luò)、CPU、內(nèi)存)的消耗情況。如果是購買的云主機(jī)，比如阿里云，可以登錄阿里云平臺(tái)提供各方面的監(jiān)控，比如 CPU、內(nèi)存、帶寬的使用情況。

3. 如果發(fā)現(xiàn)硬件資源消耗都不高，那么就需要通過查日志，比如看看 MySQL慢查詢的日志，看看是不是某條 SQL 語句查詢慢，導(dǎo)致網(wǎng)站訪問慢。

29、怎么去解決訪問慢問題？

1. 如果是出口帶寬問題，那么久申請(qǐng)加大出口帶寬。
2. 如果慢查詢比較多，那么就要開發(fā)人員或 DBA 協(xié)助進(jìn)行 SQL 語句的優(yōu)化。
3. 如果數(shù)據(jù)庫響應(yīng)慢，考慮可以加一個(gè)數(shù)據(jù)庫緩存，如 Redis 等等。然后也可以搭建MySQL 主從，一臺(tái) MySQL 服務(wù)器負(fù)責(zé)寫，其他幾臺(tái)從數(shù)據(jù)庫負(fù)責(zé)讀。
4. 申請(qǐng)購買 CDN 服務(wù)，加載用戶的訪問。
5. 如果訪問還比較慢，那就需要從整體架構(gòu)上進(jìn)行優(yōu)化咯。做到專角色專用，多臺(tái)服務(wù)器提供同一個(gè)服務(wù)。

·················END·················

你好，我是 lemon，一名計(jì)算機(jī)軟件工程師，雙非本科非科班，自學(xué)計(jì)算機(jī)基礎(chǔ)，現(xiàn)在某一線大廠，公眾號(hào)分享編程學(xué)習(xí)、個(gè)人思考，不止后端。歡迎關(guān)注，一起進(jìn)階，點(diǎn)擊下方名片，了解更多。