計網面試題

 

（1） 建立TCP服務器的各個系統調用

建立TCP服務器連接的過程中主要通過以下系統調用序列來獲取某些函數，這些系統調用主要包括：socket（），bind（），listen（），accept（），send（）和recv（）。
詳見：建立TCP 服務器的系統調用

（2） 繼上一題，說明socket網絡編程有哪些系統調用？其中close是一次就能直接關閉的嗎，半關閉狀態是怎么產生的？

復制代碼

1 2 3 4 5 6 7 8

socket()    創建套接字   bind()      綁定本機端口    connect()   建立連接     （TCP三次握手在調用這個函數時進行） listen()    監聽端口 accept()    接受連接 recv(), read(), recvfrom()  數據接收 send(), write(), sendto()   數據發送 close(), shutdown() 關閉套接字

使用close()時，只有當套接字的引用計數為0的時候才會終止連接，而用shutdown()就可以直接關閉連接

詳見：網絡編程Socket之TCP之close/shutdown詳解

TCP連接與斷開詳解： https://www.cnblogs.com/felixzh/p/8359066.html

（3） 對路由協議的了解與介紹。內部網關協議IGP包括RIP，OSPF，和外部網關協議EGP和BGP.

• RIP“路由信息協議(Route Information Protocol)”的簡寫，主要傳遞路由信息，通過每隔30秒廣播一次路由表，維護相鄰路由器的位置關系，同時根據收到的路由表信息使用動態規划的方式計算自己的路由表信息。RIP是一個距離矢量路由協議,最大跳數為16跳,16跳以及超過16跳的網絡則認為目標網絡不可達。

• OSPF：詳見：https://zhuanlan.zhihu.com/p/41341540

（4） UDP如何實現可靠傳輸

因為UDP是無連接的協議，所以在傳輸層上無法保證可靠傳輸，要想實現可靠傳輸，只能從應用層實現。需要實現seq/ack機制，重傳機制和窗口確認機制。

就要接收方收到UDP之后回復個確認包，發送方有個機制，收不到確認包就要重新發送，每個包有遞增的序號，接收方發現中間丟了包就要發重傳請求，當網絡太差時候頻繁丟包，防止越丟包越重傳的惡性循環，要有個發送窗口的限制，發送窗口的大小根據網絡傳輸情況調整，調整算法要有一定自適應性。

作者：姚冬
鏈接：https://www.zhihu.com/question/283995548/answer/661809748
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

（5） TCP和UDP的區別

• TCP是面向連接的協議，提供的是可靠傳輸，在收發數據前需要通過三次握手建立連接，使用ACK對收發的數據進行正確性檢驗。而UDP是無連接的協議，不管對方有沒有收到或者收到的數據是否正確。
• TCP提供流量控制和擁塞控制，而UDP沒有。
• TCP對系統資源的要求高於UDP，所以速度也比UDP慢。
• TCP數據包是沒有邊界的，會出現粘包的問題，UDP包是獨立的，不會出現粘包問題。
• 所以在應用方面，如果強調數據的完整性和正確性用TCP，當要求性能和速度的時候，使用UDP更加合適。

注：單憑TCP是不能保證完整性的，要是有黑客偽造TCP包，是無法識別的。

（6） TCP和UDP相關的協議與端口號

TCP族的協議有HTTP，HTTPS，SMTP，TelNet，FTP等，UDP族的協議有DNS，DHCP等等。
詳見：https://blog.csdn.net/qq_22080999/article/details/81105051

（7） TCP（UDP，IP）等首部的認識（http請求報文構成）

TCP的頭部大致包括：源端口，目的端口，序號，確認號，偏移位，標志位，校驗和等等

UDP的頭部則包括：源端口，目的端口，長度，校驗和。

IP數據包的頭部包括：源IP地址，目的IP地址，協議，校驗和，總長度等等

詳見：https://blog.csdn.net/zhangliangzi/article/details/52554439

（8） 網頁解析的過程與實現方法

這里僅展示瀏覽器解析服務器響應的過程，URL解析和交互的完整過程在(9)

• 首先是html文檔解析，瀏覽器會將html文檔生成解析樹，也就是DOM樹，它由dom元素以及屬性節點組成。
• 然后瀏覽器加載過程中如果遇到了外部css文件或者圖片資源，還會另外發送請求來獲取css文件和資源，這個請求通常是異步的，不會影響html文檔的加載。
• 不過如果瀏覽器在加載時遇到了js文件，則會掛起渲染的線程，等待js文件加載解析完畢才恢復html的渲染線程。
• 然后是css解析，將css文件解析為樣式表對象來渲染DOM樹。

  （9） 在瀏覽器中輸入URL后執行的全部過程（如www.baidu.com）重點、熱門問題

1. 首先是域名解析，客戶端使用DNS協議將URL解析為對應的IP地址；
2. 然后建立TCP連接，客戶端與服務器通過三次握手建立TCP連接；
3. 接着是http連接，客戶端向服務器發送http連接請求； （http連接無需額外連接，直接通過已經建立的TCP連接發送）
4. 服務器對客戶端發來的http請求進行處理，並返回響應；
5. 客戶端接收到http響應，將結果渲染展示給用戶。

   （10） 網絡層分片的原因與具體實現

   因為在鏈路層中幀的大小通常都有限制，比如在以太網中幀的最大大小（MTU）就是1500字節。如果IP數據包加上頭部后大小超過1500字節，就需要分片。

IP分片和完整IP報文差不多擁有相同的IP頭，16位ID域對於每個分片都是一致的，這樣才能在重新組裝的時候識別出來自同一個IP報文的分片。在IP頭里面，16位識別號唯一記錄了一個IP包的ID，具有同一個ID的IP分片將會重新組裝；而13位片偏移則記錄了某IP片相對整個包的位置；而這兩個表中間的3位標志則標志着該分片后面是否還有新的分片。這三個標志就組成了IP分片的所有信息(將在后面介紹)，接受方就可以利用這些信息對IP數據進行重新組織。
詳見：https://blog.csdn.net/gettogetto/article/details/72851734

（11） TCP的三次握手與四次揮手的詳細介紹（TCP連接建立與斷開是熱門問題）

• 三次握手

第一次握手：首先client給server發送連接請求報文，在這個報文中，包含了SYN=1，client_seq=任意值i，發送之后處於SYN-SENT狀態，這是第一次握手

第二次握手：server端接收到了這個請求，並分配資源，同時給client返回一個ACK報文，這個報文中呢包含了這些字段，標志位SYN和ACK都為1，而小ack為i+1，此時位於SYN-RCVD狀態，這是第二次握手

第三次握手：client收到server發來的ACK信息后呢，他會看到server發過來的小ack是i+1，這時他知道了server收到了消息，也給server回一個ACK報文，報文中同樣包含了ACK=1這樣的消息，同時呢，還包括了client_ack=k+1這樣的字段，這樣呢三次握手之后，連接就建立了，client進入established（已建立連接）狀態

• 四次揮手斷開連接：

TCP斷開連接通常是由一方主動，一方被動的，這里我們假設client主動，server被動
第一次揮手：當client沒有數據要發送給server了，他會給server發送一個FIN報文，告訴server：“我已經沒有數據要發給你了，但是你要是還想給我發數據的話，你就接着發，但是你得告訴我你收到我的關閉信息了”，這是第一次揮手，揮手之后client進入FIN_WAIT_1的第一階段

第二次揮手：當server收到client發來的FIN報文后，告訴client：“我收到你的FIN消息了，但是你等我發完的”此時給client返回一個ACK信息，並且呢ack=seq+1，這是第二次揮手，揮手之后呢server進入CLOSE_WAIT階段，而client收到之后處於FIN_WAIT_2第二階段

第三次揮手：當server發完所有數據時，他會給client發送一個FIN報文，告訴client說“我傳完數據了，現在要關閉連接了”，然后呢server變成LAST_ACK狀態，等着client最后的ACK信息，這是第三次揮手

第四次揮手：當client收到這個FIN報文時，他會對這個消息進行確認，即給server發ACK信息，但是它不相信網絡，怕server收不到信息，它會進入TIME_WAIT狀態，萬一server沒收到ACK消息它可以可以重傳，而當server收到這個ACK信息后，就正式關閉了tcp連接，處於CLOSED狀態，而client等待了2MSL這樣長時間后還沒等到消息，它知道server已經關閉連接了，於是乎他自己也斷開了，這是第四次揮手，這樣tcp連接就斷開了

（12） TCP握手以及每一次握手客戶端和服務器端處於哪個狀態

見上

（13） 為什么使用三次握手，兩次握手可不可以？（重點，熱門問題）

如果使用兩次握手的話，三次握手中的最后一次缺失，服務器不能確認客戶端的接收能力。

舉兩個例子，第一種是黑客會偽造大量SYN請求發送給服務器，服務器立即確認並建立連接，分配資源，但是這一系列連接並不是真實存在的，這大大浪費了服務器的資源並且阻塞了正常用戶的連接，這種也叫SYN洪泛攻擊。第二種是服務器返回給客戶端的ACK數據包可能會在傳輸的過程中丟失，而客戶端沒有收到該ACK數據包而拒絕接收服務器接下來發送的數據，於是服務器一直在發送，客戶端一直在拒絕，形成死鎖。

（14） TIME_WAIT的意義（為什么要等於2MSL）

TIME_WAIT是指四次揮手中客戶端接收了服務端的FIN報文並發送ACK報文給服務器后，仍然需要等待2MSL時間的過程。雖然按道理，四個報文都發送完畢，我們可以直接進入CLOSE狀態了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。如果客戶端發送的ACK發生丟失，服務器會再次發送FIN報文給客戶端，所以TIME_WAIT狀態就是用來重發可能丟失的ACK報文。

（15） 超時重傳機制（不太高頻）

（16） TCP怎么保證可靠性？

（校序重流擁）

• 校驗和
  發送的數據包的二進制相加然后取反，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。

• 確認應答+序列號
  TCP給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。

• 超時重傳
  當TCP發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

• 流量控制
  TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發送端發送接收端緩沖區能接納的數據。當接收方來不及處理發送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP使用的流量控制協議是可變大小的滑動窗口協議。
  接收方有即時窗口（滑動窗口），隨ACK報文發送

• 擁塞控制
  當網絡擁塞時，減少數據的發送。
  發送方有擁塞窗口，發送數據前比對接收方發過來的即使窗口，取小

慢啟動、擁塞避免、快速重傳、快速恢復

（17） 流量控制的介紹，采用滑動窗口會有什么問題（死鎖可能，糊塗窗口綜合征）？

所謂流量控制就是讓發送方發送速率不要過快，讓接收方來得及接收。利用TCP報文段中的窗口大小字段來控制發送方的發送窗口不大於接收方發回的窗口大小就可以實施流量控制。

考慮一種特殊的情況，就是接收方若沒有緩存足夠使用，就會發送零窗口大小的報文，此時發送放將發送窗口設置為0，停止發送數據。之后接收方有足夠的緩存，發送了非零窗口大小的報文，但是這個報文在中途丟失的，那么發送方的發送窗口就一直為零導致死鎖。

解決這個問題，TCP為每一個連接設置一個持續計時器（persistence timer）。只要TCP的一方收到對方的零窗口通知，就啟動該計時器，周期性的發送一個零窗口探測報文段。對方就在確認這個報文的時候給出現在的窗口大小（注意：TCP規定，即使設置為零窗口，也必須接收以下幾種報文段：零窗口探測報文段、確認報文段和攜帶緊急數據的報文段）。

（18） tcp滑動窗口協議

詳見 TCP-IP詳解：滑動窗口SlidingWindow和TCP滑動窗口

TCP的滑動窗口用來控制接收方和發送方的發送速率，避免擁塞的發生。滑動窗口其實就是接收端的緩沖區大小，用來告訴發送方對它發送的數據有多大的緩沖空間。在接收方的滑動窗口已知的情況下，當接收方確認了連續的數據序列之后，發送方的滑動窗口向后滑動，發送下一個數據序列。

接收方會在每個ACK數據包中附帶自己當前的接受窗口（滑動窗口）的大小，方便發送方進行控制。

（19） 擁塞控制和流量控制的區別

擁塞控制是防止過多的數據注入到網絡中，導致網絡發生擁塞；而流量控制是防止發送方一下子發送過多的數據到接收方，導致接收方緩存放不下。兩種算法都是對發送方的行為進行控制的。

（20） TCP擁塞控制，算法名字？（極其重要）

防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載，擁塞控制自然也是控制發送者的流量，擁塞控制有四種算法，慢啟動、擁塞避免，快速重傳和快速恢復

發送方維持一個擁塞窗口 cwnd ( congestion window )的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口等於擁塞窗口和接受窗口的較小值。

（1）慢啟動。慢啟動算法的思路是當主機開始發送數據時，先以比較小的擁塞窗口進行發送，然后每次翻倍，也就是說，由小到大逐漸增加擁塞窗口的大小，而這個大小是指數增長的，即1、2、4、8、16
*為了防止擁塞窗口cwnd增長過大引起網絡擁塞，還要另外設置一個慢啟動閾值ssthresh狀態變量，當擁塞窗口的大小超過慢啟動閾值的時候（ cwnd > ssthresh 時），停止使用慢開始算法而改用擁塞避免算法

（2）擁塞避免。擁塞避免算法的思路是讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。

（3）快速重傳。當發送端連續收到三個重復的ack時，表示該數據段已經丟失，需要重發。此時慢啟動閾值ssth變為原來一半，擁塞窗口cwnd變為ssth+3，然后+1+1的發（每一輪rtt+1）

（4）快速恢復。當超過設定的時間沒有收到某個報文段的ack時，表示網絡擁塞，慢啟動閾值ssth變為原來一半，擁塞窗口cwnd=1，進入慢啟動階段

（21） http協議與TCP的區別與聯系

聯系：Http協議是建立在TCP協議基礎之上的，當瀏覽器需要從服務器獲取網頁數據的時候，會發出一次Http請求。Http會通過TCP建立起一個到服務器的連接通道，當本次請求需要的數據傳輸完畢后，Http會立即將TCP連接斷開，這個過程是很短的。

區別：HTTP和TCP位於不同的網絡分層。TCP是傳輸層的協議，定義的是數據傳輸和連接的規范，而HTTP是應用層的，定義的是數據的內容的規范。
建立一個TCP請求需要進行三次握手，而由於http是建立在tcp連接之上的，建立一個http請求通常包含請求和響應兩個步驟。

（22） http/1.0和http/1.1的區別

HTTP 協議老的標准是 HTTP/1.0 ，目前最通用的標准是 HTTP/1.1 。
HTTP1.0 只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個 TCP 連接，但是最新的http/1.0加入了長連接，只需要在客戶端給服務器發送的http報文頭部加入Connection:keep-alive
HTTP 1.1 支持持久連接，默認進行持久連接，在一個 TCP 連接上可以傳送多個 HTTP 請求和響應，減少了建立和關閉連接的消耗和延遲。

（23） http的請求方法有哪些？get和post的區別。

HTTP的請求方法包括GET，POST，PUT，DELETE四種基本方法。（四種方法中只有POST不是操作冪等性的）

get和post的區別：

1. get方法不會修改服務器上的資源，它的查詢是沒有副作用的，而post有可能會修改服務器上的資源
2. get可以保存為書簽，可以用緩存來優化，而post不可以
3. get把請求附在url上，而post把參數附在http包的包體中
4. 瀏覽器和服務器一般對get方法所提交的url長度有限制，一般是1k或者2k，而對post方法所傳輸的參數大小限制為80k到4M不等
5. post可以傳輸二進制編碼的信息，get的參數一般只支持ASCII

   （24） http的狀態碼 403 201等等是什么意思

   詳見 HTTP狀態碼的含義

常見的狀態碼有：

• 200 - 請求成功
• 301 - 資源（網頁等）被永久轉移到其它URL
• 404 - 請求的資源（網頁等）不存在
• 500 - 內部服務器錯誤
• 400 - 請求無效
• 403 - 禁止訪問

（25） http和https的區別，由http升級為https需要做哪些操作

http 是超文本傳輸協議，信息是明文傳輸， https 則是具有安全性的 ssl 加密傳輸協議
http 和 https 使用的是完全不同的連接方式，用的端口也不一樣，前者是 80 ，后者是 443
http 的連接很簡單，是無狀態的； HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比http 協議安全。
https 協議需要到 ca 申請證書，一般免費證書較少，因而需要一定費用
https://www.cnblogs.com/wqhwe/p/5407468.html

（26） https的具體實現，怎么確保安全性

SSL是傳輸層的協議

https包括非對稱加密和對稱加密兩個階段，在客戶端與服務器建立連接的時候使用非對稱加密，連接建立以后使用的是對稱加密。

1. 客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接
2. Web服務器收到客戶端請求后，會將網站的公鑰傳送一份給客戶端，私鑰自己保存。
3. 客戶端的瀏覽器根據雙方同意的安全等級，生成對稱加密使用的密鑰，稱為會話密鑰，然后利用網站的公鑰將會話密鑰加密，並傳送給網站
4. Web服務器利用自己的私鑰解密出會話密鑰。
5. Web服務器利用會話密鑰加密與客戶端之間的通信，這個過程是對稱加密的過程。

服務器第一次傳給客戶端的公鑰其實是CA對網站信息進行加密的數字證書

客戶端的對稱加密密鑰其實是三個隨機數的哈希（1. 客戶端第一次給服務端發送請求時附帶的隨機數 2. 服務器返回時的隨機數 3. 客戶端收到返回時的隨機數）

（27） TCP三次握手時的第一次的seq序號是怎樣產生的 （字節提前批）

第一次的序號是隨機序號，但也不是完全隨機，它是使用一個ISN算法得到的。

seq = C + H (源IP地址，目的IP地址，源端口，目的端口)。其中，C是一個計時器，每隔一段時間值就會變大，H是消息摘要算法，輸入是一個四元組（源IP地址，目的IP地址，源端口，目的端口）。

（28） 一個機器能夠使用的端口號上限是多少，為什么？可以改變嗎？那如果想要用的端口超過這個限制怎么辦？

65536.因為TCP的報文頭部中源端口號和目的端口號的長度是16位，也就是可以表示2^16=65536個不同端口號，因此TCP可供識別的端口號最多只有65536個。但是由於0到1023是知名服務端口，所以實際上還要少1024個端口號。

而對於服務器來說，可以開的端口號與65536無關，其實是受限於Linux可以打開的文件數量，並且可以通過MaxUserPort來進行配置。

（29） 對稱密碼和非對稱密碼體系

https://blog.csdn.net/qq_29689487/article/details/81634057

• 對稱加密：加密和解密使用的密鑰是同一個
  • 優點：計算量小，算法速度快，加密效率高 缺點：密鑰容易泄漏。不同的會話需要不同的密鑰，管理起來很費勁
  • 常用算法：DES，3DES，IDEA，CR4，CR5，CR6，AES
• 非對稱加密：需要公鑰和私鑰，公鑰用來加密，私鑰用來解密
  • 優點：安全，不怕泄漏 缺點：速度慢
  • 常用算法：RSA，ECC，DSA

    （30） 數字證書的了解（高頻）

    

權威CA使用私鑰將網站A的信息和消息摘要（簽名S）進行加密打包形成數字證書。公鑰給客戶端。

網站A將自己的信息和數字證書發給客戶端，客戶端用CA的公鑰對數字證書進行解密，得到簽名S，與手動將網站的信息進行消息摘要得到的結果S*進行對比，如果簽名一致就證明網站A可以信任。

（31） 服務器出現大量close_wait的連接的原因以及解決方法

close_wait狀態是在TCP四次揮手的時候收到FIN但是沒有發送自己的FIN時出現的，服務器出現大量close_wait狀態的原因有兩種：

• 服務器內部業務處理占用了過多時間，都沒能處理完業務；或者還有數據需要發送；或者服務器的業務邏輯有問題，沒有執行close()方法
• 服務器的父進程派生出子進程，子進程繼承了socket，收到FIN的時候子進程處理但父進程沒有處理該信號，導致socket的引用不為0無法回收

處理方法：

• 停止應用程序

• 修改程序里的bug

  （32） 消息摘要算法列舉一下，介紹MD5算法，為什么MD5是不可逆的，有什么辦法可以加強消息摘要算法的安全性讓它不那么容易被破解呢？（百度安全一面）

• 消息摘要算法有MD家族（MD2，MD4，MD5），SHA家族（SHA-1,SHA-256）和CRC家族（CRC8,CRC16,CRC32）等等

• MD5算法介紹：
  MD5以512位分組來處理輸入的信息，且每一分組又被划分為若干個小分組（16個32位子分組），經過一些列的處理后，算法輸出由四個散列值（32位分組組成的128位散列值。）

1. MD5首先將輸入的信息分成若干個512字節長度的分組，如果不夠就填充1和若干個0。
2. 對每個512字節的分組進行循環運算。使用四個幻數對第一個分組的數據進行四輪變換，得到四個變量。
3. 接下來對其中三個使用線性函數進行計算，與剩下一個相加，並賦值給其中某個變量，得到新的四個變量，重復16次這個過程，得到的四個變量作為幻數，與下一個分組進行相似的計算。
4. 遍歷所有分組后得到的四個變量即為結果。

詳見：https://blog.csdn.net/weixin_39640298/article/details/84555814

• 為什么不可逆：因為MD5在進行消息摘要的過程中，數據與原始數據相比發生了丟失，所以不能由結果進行恢復。

• 加強安全性：加鹽（加隨機數）

  （33） 單條記錄高並發訪問的優化

  服務器端：

• 使用緩存，如redis等

• 使用分布式架構進行處理

• 將靜態頁面和靜態資源存儲在靜態資源服務器，需要處理的數據使用服務器進行計算后返回

• 將靜態資源盡可能在客戶端進行緩存

• 采用ngnix進行負載均衡 （nginx讀作恩靜埃克斯 = Engine X）

數據庫端：

• 數據庫采用主從賦值，讀寫分離措施
• 建立適當的索引
• 分庫分表

  （34） 介紹一下ping的過程，分別用到了哪些協議 （百度安全等）

  詳見：Ping原理與ICMP協議

ping是使用ICMP協議來進行工作的。 ICMP:網絡控制報文協議

• 首先，ping命令會構建一個ICMP請求數據包，然后由ICMP協議將這個數據包連同目的IP地址源IP地址一起交給IP協議。
• 然后IP協議就會構建一個IP數據報，並且在映射表中查找目的IP對應的mac地址，將其交給數據鏈路層。
• 然后數據鏈路層就會構建一個數據幀，附上源mac地址和目的mac地址發送出去。

目的主機接收到數據幀后，就會檢查包上的mac地址與本機mac是否相符，如果相符，就接收並把其中的信息提取出來交給IP協議，IP協議就會將其中的信息提取出來交給ICMP協議。然后構建一個ICMP應答包，用相同的過程發送回去。

（35） TCP/IP的粘包與避免介紹一下

因為TCP為了減少額外開銷，采取的是流式傳輸，所以接收端在一次接收的時候有可能一次接收多個包。而TCP粘包就是發送方的若干個數據包到達接收方的時候粘成了一個包。多個包首尾相接，無法區分。

導致TCP粘包的原因有三方面：

• 發送端等待緩沖區滿才進行發送，造成粘包
• 接收方來不及接收緩沖區內的數據，造成粘包
• 由於TCP協議在發送較小的數據包的時候，會將幾個包合成一個包后發送

避免粘包的措施：

• 通過編程，強制使TCP發生數據傳送，不必等到緩沖區滿
• 優化接收方接收數據的過程，使其來得及接收數據包，包括提高接收進程優先級等
• 設置固定長度的報文或者設置報文頭部指示報文的長度。

（36） 說一下TCP的封包和拆包

因為TCP是無邊界的流傳輸，所以需要對TCP進行封包和拆包，確保發送和接收的數據不粘連。

• 封包：封包就是在發送數據報的時候為每個TCP數據包加上一個包頭，將數據報分為包頭和包體兩個部分。包頭是一個固定長度的結構體，里面包含該數據包的總長度。
• 拆包：接收方在接收到報文后提取包頭中的長度信息進行截取。

  （37） 一個ip配置多個域名，靠什么識別？

• 靠host主機名區分
• 靠端口號區分

  （38） 服務器攻擊（DDos攻擊）

  （39）DNS的工作過程和原理

  
  DNS解析有兩種方式：遞歸查詢和迭代查詢
• 遞歸查詢 用戶先向本地域名服務器查詢，如果本地域名服務器的緩存沒有IP地址映射記錄，就向根域名服務器查詢，根域名服務器就會向頂級域名服務器查詢，頂級域名服務器向權限域名服務器查詢，查到結果后依次返回。
• 迭代查詢 用戶向本地域名服務器查詢，如果沒有緩存，本地域名服務器會向根域名服務器查詢，根域名服務器返回頂級域名服務器的地址，本地域名服務器再向頂級域名服務器查詢，得到權限域名服務器的地址，本地域名服務器再向權限域名服務器查詢得到結果

  （41）OSA七層協議和五層協議，分別有哪些

  OSI七層協議模型主要是：應用層（Application）、表示層（Presentation）、會話層（Session）、傳輸層（Transport）、網絡層（Network）、數據鏈路層（Data Link）、物理層（Physical）。

五層體系結構包括：應用層、傳輸層、網絡層、數據鏈路層和物理層。

（42）IP尋址和MAC尋址有什么不同，怎么實現的

通過MAC地址尋找主機是MAC地址尋址，通過IP地址尋找主機叫IP地址尋址。它們適用於不同的協議層，IP尋址是網絡層，Mac尋址是數據鏈路層。

http://c.biancheng.net/view/6388.html

https://blog.csdn.net/wxy_nick/article/details/9190693

IP尋址的過程（ARP協議）：主機A想通過IP地址尋找到目標主機，首先分析IP地址確定目標主機與自己是否為同一網段。如果是則查看ARP緩存，或者使用ARP協議發送廣播。如果不是，則尋找網關發送ARP數據包