經歷過很多面試和筆試，看過很多別人的面經，總結了很多計算機網絡面試題，希望能給面試的童鞋一些幫助。不過，我這裏就不想浪費筆墨描述問題的原理了，每個問題都附有答案，如果答案看不懂地方，可以自行百度或者看其他人的博客。我直接上題目了，不廢話。下載地址：http://download.csdn.net/detail/u012321815/9137245
1.HTTP回覆狀態碼：
答：1.200：成功；2.301：永久重定向，302：臨時重定向；3.400：服務器不理解請求語法（訪問參數錯誤），403：服務器拒絕訪問（權限不夠），404：服務器找不到網頁；4.500:服務器內部出錯，502：網關出錯，503：服務不可用。
2.HTTP請求報文格式：
答：HTTP報文是面向文本的，報文中每一個字段都是一些ASCII碼串，各個字段長度都不確定。
1.HTTP請求報文：報文有，請求行（request-line）、請求頭部（headers）、空行（blank line）、請求數據（request-body）四個部分組成。
HTTP協議請求方法：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。GET方法要求服務器把URL定位的資源放在響應報文的數據部分，回送給客戶端。請求參數和對應的值都附加在URL後面，用“？”隔開，參數之間用“&”隔開，傳遞長度受限制，不適合傳送私密數據和大量數據。POST將請求數據封裝在HTTP的請求數據中，以名稱/值的形式出現，可以傳輸大量數據。其中，URL長度限制每個不同的瀏覽器不同，比方說IE是2k+35個字節，不是協議本身對URL限制的。Tomcat對POST限制爲2M。
例如：GET/search?id=hp&psw=123456 HTTP/1.1
2.請求頭部：關鍵字/值對組成，每行一對，關鍵字和值用“:”隔開。典型頭有：Host，請求的主機名；Accept，客戶端可識別的內容類型列表。User-Agent，產生請求的瀏覽器類型。
3.空行：最後一個請求頭之後是一個空行，通知服務器不再有請求頭。
4.請求數據：POST中把數據放在請求數據中。
3.HTTP響應報文：
答：1.HTTP響應報文有，狀態行（status-line），消息報頭（headers），響應正文（blank line）三部分構成。
2.狀態行格式：HTTP版本狀態碼狀態碼的文本描述。
例如：HTTP/1.1 200 OK
4.TCP協議和UDP協議。
答：1.TCP協議是面向連接的，而UDP是無連接的。2.TCP保證數據傳輸的可靠性和順序性，而UDP無法保證。3.TCP報文頭結構複雜至少佔用20字節，系統開銷大，而UDP只有8字節(源和目的端口號、用戶數據長度、校驗和)。4.TCP報文有可能拆分發送，而UDP報文不會拆分也不會合並，保留了報文的邊界，所以不會出現粘包問題。
5.TCP如何保證可靠傳輸的。
答：1.應用數據被分割成TCP認爲最合適發送的數據塊；
2.當TCP發出一個段後，它就啓動一個定時器，等待目的端確認收到這個報文，如果不能及時收到一個確認，將重發這個報文段（超時重發）。3.當TCP收到發自TCP連接另一端的數據，它先對接收到數據進行校驗，對首部和數據部分都校驗，如果沒有差錯就發送確認響應；如果有差錯，就丟棄報文段，不發送確認響應，希望發送端超時重發。
4.TCP基於IP數據報傳輸，所以到達可能會失序，所以要TCP將對收到數據進行重新排序（對失序數據進行重新排序，然後交給應用層）；同時也可能接收到重複數據，會對重複數據丟棄（對重複數據丟棄）。這些都是通過序號和確認號來實現的。
5.TCP提供流量控制，防止緩衝區溢出，採用的是可變大小的滑動窗口協議。
6.TCP的半關閉。
1.半關閉：TCP提供了連接的一端在結束它的發送後還能接收到來自另一端數據的能力，這就是半關閉。客戶端發送FIN之後，就進入半關閉狀態。
2.TCP每個連接都管理四個定時器：1.重傳定時器；2.堅持定時器：是窗口大小信息保持不斷流動，即使另一端關閉了其接收窗口；3.保活定時器：可檢測到一個空閒連接的另一端何時崩潰或重啓；4.2MSL定時器。
7.OSI七層：
答：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
物理層：通過媒介傳輸比特,確定機械及電氣規範（比特Bit）
數據鏈路層：將比特組裝成幀和點到點的傳遞（幀Frame）
網絡層：負責數據包從源到宿的傳遞和網際互連（包PackeT）
傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）
會話層：建立、管理和終止會話（會話協議數據單元SPDU）
表示層：對數據進行翻譯、加密和壓縮（表示協議數據單元PPDU）
應用層：允許訪問OSI環境的手段（應用協議數據單元APDU）
1.物理層：RJ45、CLOCK、IEEE802.3（中繼器，集線器）
2.數據鏈路層：PPP、FR、HDLC、VLAN、MAC （網橋，交換機）
3.網絡層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、（路由器）
4.傳輸層：TCP、UDP、SPX
5.會話層：NFS、SQL、NETBIOS、RPC
6.表示層：JPEG、MPEG、ASII
7.應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS
8.IP分類：
A類地址：以0開頭，第一個字節範圍：0~127（1.0.0.0 - 126.255.255.255）；
B類地址：以10開頭，第一個字節範圍：128~191（128.0.0.0 - 191.255.255.255）；
C類地址：以110開頭， 第一個字節範圍：192~223（192.0.0.0 - 223.255.255.255）； 10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。（Internet上保留地址用於內部）
IP=網絡號+子網號+主機號；子網掩碼和IP相與就得到了網絡號，而子網號的位數等於網絡號減掉實際IP段網絡號，主機號位數等於32-網絡號-子網號。例如：IP是141.14.72.24，子網掩碼是255.255.192.0；這是一個B類地址，所以默認網絡號爲16位，然後IP和子網掩碼相與得到第三個8位段爲01000000，也就是說子網號佔兩位，那麼主機號就佔32-16-2=14位；網絡地址就是相與的結果，也就是141.14.64.0.同理，如果子網掩碼是255.255.224.0，那麼網絡地址還是一樣，但是子網號爲3位，主機號爲13位，主機數量就少了。
128.14.35.7/20這樣的表示方法是指前20位是網絡前綴，所以後12位爲主機號。也就是說這段地址最小地址是128.14.32.0，最大地址是128.14.47.255.
9.TCP建立三次握手，關閉四次揮手。
答：三次握手：客戶端給服務器發送SYN報文，也就是SYN=1，然後進入SYN-SEND狀態；然後服務端發送SYN+ACK報文，也就是SYN=1,ACK=1，服務端進入SYN-RCVD狀態；然後客戶端會發送確認報文ACK，客戶端進入ESTABLISHED狀態，服務端接收到ACK報文也進入ESTABLISHED狀態，然後他們之間就可以相互傳輸數據了。
四次揮手：客戶端發送FIN報文，也就是FIN=1，然後進入FIN-WAIT1狀態；服務端接收到FIN報文，回發一個ACK報文，自身進入CLOSE-WAIT狀態；客戶端接收到ACK報文後，就進入FIN-WAIT2狀態；服務端然後發送FIN報文，自身進入LAST-ACK狀態；客戶端接收到FIN報文，然後發送ACK報文，進入到TIME-WAIT狀態，然後等待2MSL（最大報文段生存時間）後關閉；服務端接收到ACK報文然後就關閉了。
備註：1.三次握手中有兩次確認，這是防止已失效的報文被重新傳送造成錯誤。比方說A的報文在某個網絡節點延時了，但是沒有被丟棄，然後重新發送給了B，如果這時沒有第二次確認，那麼B對接收到的失效的報文也要建立連接，但是實際上A並沒有發送，造成了B資源的浪費。
2.建立時三次，關閉時爲什麼要四次。因爲建立時，服務端的同步和應答SYN和ACK是同時回傳給客戶端的，但是關閉時，由於服務端有可能還有未接收完的信息，所以不能直接關閉，但是要給客戶端響應，所以只能先發一個ACK報文，然後等處理完所有信息之後，才能給客戶端發一個FIN報文告訴客戶端可以關閉了。
3.TCP的有限狀態機：可以說明結束的時候有三種情況，一種是正常的關閉，如上圖所示，經歷的是FIN-WAIT1->FIN-WAIT2->TIME-WAIT->CLOSED;還有第二種是如果服務端沒有要發送的內容，那麼收到客戶端的FIN後，直接發送ACK+FIN，所以經歷的狀態是FIN-WAIT1->TIME-WAIT->CLOSED。第三種情況是如果兩方同時發送FIN的話，那麼直接就發送ACK，經歷的狀態FIN-WAIT1->CLOSING->TIME-WAIT->CLOSED。
10.TCP報文格式：
答：1.端口號用來標識同一臺計算機不同進程。
2.序列號是該報文段首字節的字節流編號，比方說報文被分解成多個報文時，序列號就是報文段首字節在整個報文中的偏移量。
3.確認號是下一個期待的字節，比方說A從B裏接收到了100個字節數據了，那麼他的確認號就是101，這是他期望從B中獲取的下一個字節編號。
4.首部長度爲4位，單位是32位字，所以最多存的是4*15=60字節。由於5個是固定的20字節，所以選項長度最大爲40字節，也就是10個選項。
5.標誌位：URG：指示報文段裏存在這被髮送方的上層實體標記爲“緊急”的數據，URG=1時，其後的緊急指針指示緊急數據在當前數據段的位置，也就是相對於當前序列號的字節偏移量，TCP接收方必須通知上層實體。ACK：ACK=0時該數據段不包含確認信息；ACK=1時該報文段包含一個對已被成功接收報文段的確認。PSH：當PSH=1時接收方在接收到數據後立即將數據交給上層，而不是直到整個緩衝區滿。RST：用於重置一個已經混亂的連接，也可以用來拒絕一個無效的數據段或者拒絕一個連接請求。一般而言，如果你得到數據段被設置了RST，說明你這端有問題。SYN：用來建立連接過程，SYN=1和ACK=0說明數據段沒有使用捎帶的確認域，都等於1時說明連接應答捎帶了一個確認。
FIN：用於釋放一個連接，表示發送方已經沒有數據要傳輸了。
6.窗口大小：用於流控制，窗口大小指定了從被確認的字節算起可以發送多少字節，確保連接的任何一方都不會過快地發送過量的分組而淹沒另一方。
7.校驗和：提供額外的可靠性。TCP的checksum域爲0，如果數據域字節數爲奇數就額外加一個0字節。（校驗和算法：將所有的16位字取反碼累加，取累加結果作爲校驗和。接收方也同樣計算，結果應該全爲1.（不確定））
11.TCP粘包問題。
答：TCP粘包是在一次接收數據不能完全體現一個完整的消息數據。粘包原因：1.發送端需要等待緩衝區滿才發送出去造成粘包；2.接收方不及時接收緩衝區的包，造成多個包接收。解決方案：1.發送端編程設置有數據就立即發送；接收端優化程序設計、精簡接收進程工作量、提高接收進程優先級等及時接收數據包；還可以接收方控制，把一包數據按結構字段人爲控制分爲多次接收，然後合併。（封包和拆包）2.制定應用層的數據通信協議，通過協議規範接收的數據。比方說用4字節描述消息大小，或者制定結束符。
12.在瀏覽器輸入www.baidu.com後執行過程。
答：1、客戶端瀏覽器通過DNS解析到www.baidu.com的IP地址220.181.27.48，通過這個IP地址找到客戶端到服務器的路徑。客戶端瀏覽器發起一個HTTP會話到220.161.27.48，然後通過TCP進行封裝數據包，輸入到網絡層。
2、在客戶端的傳輸層，把HTTP會話請求分成報文段，添加源和目的端口，如服務器使用80端口監聽客戶端的請求，客戶端由系統隨機選擇一個端口如5000，與服務器進行交換，服務器把相應的請求返回給客戶端的5000端口。然後使用IP層的IP地址查找目的端。
3、客戶端的網絡層不用關心應用層或者傳輸層的東西，主要做的是通過查找路由表確定如何到達服務器，期間可能經過多個路由器，這些都是由路由器來完成的工作，我不作過多的描述，無非就是通過查找路由表決定通過那個路徑到達服務器。
4、客戶端的鏈路層，包通過鏈路層發送到路由器，通過鄰居協議查找給定IP地址的MAC地址，然後發送ARP請求查找目的地址，如果得到迴應後就可以使用ARP的請求應答交換的IP數據包現在就可以傳輸了，然後發送IP數據包到達服務器的地址。
13.TCP和UDP對應的協議
TCP對應的協議：
（1）FTP：定義了文件傳輸協議，使用21端口。
（2）Telnet：一種用於遠程登陸的端口，使用23端口，用戶可以以自己的身份遠程連接到計算機上，可提供基於DOS模式下的通信服務。
（3）SMTP：郵件傳送協議，用於發送郵件。服務器開放的是25號端口。
（4）POP3：它是和SMTP對應，POP3用於接收郵件。POP3協議所用的是110端口。
（5）HTTP：是從Web服務器傳輸超文本到本地瀏覽器的傳送協議。80端口
UDP對應的協議：
（1）DNS：用於域名解析服務，將域名地址轉換爲IP地址。DNS用的是53號端口。
（2）SNMP：簡單網絡管理協議，使用161號端口，是用來管理網絡設備的。由於網絡設備很多，無連接的服務就體現出其優勢。
（3）TFTP(TrivalFile Tran敏感詞erProtocal)，簡單文件傳輸協議，該協議在熟知端口69上使用UDP服務。
14.DNS。
當DNS客戶機需要在程序中使用名稱時，它會查詢DNS服務器來解析該名稱。客戶機發送的每條查詢信息包括三條信息：包括：指定的DNS域名，指定的查詢類型，DNS域名的指定類別。基於UDP服務，端口53. 該應用一般不直接爲用戶使用，而是爲其他應用服務，如HTTP，SMTP等在其中需要完成主機名到IP地址的轉換。
15.IP數據報格式：
16.以太網首部：
17.何時收到RST包：
答：1.端口未打開；2.請求超時；3.提前關閉；4.在一個已關閉的socket上收到數據。
18.TCP的流量控制。
答：使用窗口機制來進行流量控制的（receivewindow）。
1.建立連接開始，發送方發送一個窗口大小給接收方，接收方回傳一個窗口大小給發送方，兩者最小爲發送方的窗口大小設置值。
2.發送方每次發送的時候都是選擇窗口大小和MSS（最大報文段長度）中最小的字節長度進行發送報文段；因爲一般窗口大小都會大於MSS，所以可以連續發送多個報文段。
3.接收方在接收到報文段之後，存入緩存區，同時計算剩餘緩衝區大小，從而在發送確認報文時加上新設置的窗口大小給發送方，通知發送方更新發送窗口大小和滑動位置。
4.如果接收方沒有接收到某一段報文，會發送三次確認，接收方收到連續三次確認，會立即快速重發丟失報文段，而不是等到重發定時器時間到再重傳。這就是快速重傳機制。
5.發送方可以不用等到每次發送的報文段確認了才發下一個報文段，如果有個別報文段沒有確認，可以通過後面確認的報文段來確認而不用重發，一般來說，接收方可以每兩個報文段發送一次確認，提高效率。
6.如果接收方緩衝區已滿，這時回傳給發送方的窗口大小爲0，通知發送方不要再發，這時發送方會啓動一個堅持定時器，每隔一段時間，發送窗口大小設置成0，內容爲一個字節的報文，去探測接收方的窗口情況，如果緩衝區已經有空位，這時回傳給發送方的確認報文裏窗口大小就不是0，發送方又可以繼續發送。
7.6中有一個問題，就是接收方可能會每次只取走了緩衝區中幾個字節，而造成緩衝區不是滿的情況，導致發送方只能發送幾個字節報文，就是所謂的小段報文，大量的小段報文效率低下，所以引入了Nagle算法，如果緩衝區沒有空出MSS長度字節，那麼就不能讓發送方發送。
19.TCP的擁塞控制。
答：擁塞控制也是類似上述的窗口機制，這裏使用的是擁塞窗口（congestionwindow）。
1.慢開始。最初擁塞窗口大小設置成1個MSS長度字節，且設定一個慢開始門限ssthresh，沒有超過這個門限都是慢開始，超過就是擁塞避免算法。發送擁塞窗口大小報文段後，如果接收到確認，就翻倍，1、2、4、8、、、(如果門限是12，那麼8後面到12而不是到16)只要還是慢開始階段都是這樣。
2.如果達到門限值，這時就改變算法，採用增1方式，就是每次不是翻倍而是加一來改變窗口大小，這時增長就由指數變成線性。
3.如果發現網絡已經擁塞了，那麼把門限ssthresh設置成當前窗口大小的一半，實際窗口變成1，然後重新執行慢開始過程。如何判斷達到門限，這裏是通過沒有接收到回傳的確認報文來判斷已經擁塞了，從而改變算法的。
4.如果發現需要快速重傳，也就是接收到三次確認，那麼判斷當時網絡快要擁塞但還沒有擁塞，所以執行快速恢復機制，也就是說這時門限ssthresh設定成當前窗口的一半，但是不執行慢開始，而是設置當前窗口爲門限值，然後執行擁塞避免算法，即增一。
5.3的處理過程會導致網絡中多個TCP連接同時擁塞的時候，一下子都同時降到1，重新開始執行慢開始，這叫全局同步，會導致通信量突然下降，網絡恢復後又突然增多。因此採用RED（隨機早期檢測）算法。就是維持兩個參數，隊列最小門限和最大門限，來一個分組時計算平均隊列長度，丟棄大於最大門限的，保留小於最小門限的，在最大和最小之間的就按概率丟棄。
20. IP數據包校驗和算法和TCP數據包校驗和算法。
答：1、IP數據包校驗和：
1.寫入校驗和：1、把校驗和16位置爲0，也就是第11和12字節；2.按16位分拆頭部，包括源和目的地址，所以就有20字節，得到5個雙字節數據；3.把這5個數據相加，得到的數據如果高16位不爲0，那麼再分拆，得到高16位和低16位，然後反覆分拆和相加這高低16位，直到高16位爲0；4.把16位寫入校驗和16位。
2.驗證校驗和：不要上面的第一步，直接執行第2、3步，然後得到的校驗和如果取反不等於0，那麼表明校驗錯誤。
3.例如：IP頭爲：45000031 89F5 0000 6E06 0000(校驗和字段) DEB7455D C0A8 00DC。這個要計算髮送時的校驗和時：就是校驗和字段設置爲0，然後分拆成16位，然後相加，也就是4500 +0031 +89F5 + 0000 + 6e06+ 0000 + DEB7 + 455D + C0A8 + 00DC =3 22C4，然後是0003+22C4=22C7，所以校驗和爲~22C7=DD38，即校驗和字段填充的是DD38。
4.另外，接收端接收到校驗和，計算方式如下：以上面爲例，4500 + 0031 +89F5 + 0000 + 6E06+ DD38+ DEB7 + 455D + C0A8 + 00DC =3 FFFC，然後0003+FFFC=FFFF，然後取反~FFFF=0，故校驗和正確。
2.TCP數據包校驗和：
1.TCP僞頭部：源地址、目的地址、8位0、8位類型（TCP是6）、總長度（頭部和數據段）。
2.TCP的校驗和算法和IP一致，不過要計算的部分是：僞首部+頭部+數據段，這三部分都要進行校驗。
21.SSL/TLS和HTTPS
1.SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然後用公鑰加密信息，服務器收到密文後，用自己的私鑰解密。
2.保證公鑰不被篡改：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
3.公鑰加密計算量太大，如何減少耗用的時間？每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由於"對話密鑰"是對稱加密，所以運算速度非常快，而服務器公鑰只用於加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。
4.流程：1. 客戶端向服務器端索要並驗證公鑰。2. 雙方協商生成"對話密鑰"。3. 雙方採用"對話密鑰"進行加密通信。
5.握手階段四次通信：1.客戶端發出請求（clientHello）：（1）支持的協議版本，比如TLS 1.0版；（2）一個客戶端生成的隨機數，稍後用於生成"對話密鑰"；（3）支持的加密方法，比如RSA公鑰加密；（4）支持的壓縮方法。
2.服務器迴應（serverHello）：（1）確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信；（2）一個服務器生成的隨機數，稍後用於生成"對話密鑰"；（3）確認使用的加密方法，比如RSA公鑰加密；（4）服務器證書。
3.客戶端迴應：從證書中獲取服務器公鑰，然後發送三個信息：（1）一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
（2）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（3）客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
4.服務器最後迴應：計算生成本次會話的“會話密鑰”，發送兩個信息：（1）編碼改變通知，表示隨後的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。