面試整理-計算機網路部分
1、計算機網路學習筆記
1、OSI與TCP/IP各層的結構與功能，都有哪些協議？
TCP/IP 5層模型：應用、傳輸、網路、資料鏈路、物理
TCP/IP 4層模型：應用、傳輸、網路、網路介面
各層次對應裝置：
閘道器：應用層、傳輸層（閘道器在傳輸層上以實現網路互連，是最複雜的網路互連裝置，僅用於兩個高層協議不同的網路互連。閘道器的結構也和路由器類似，不同的是互連層。閘道器既可以用於廣域網互連，也可以用於區域網互連）
路由器：網路層（路由選擇、儲存轉發）
交換機：資料鏈路層、網路層（識別資料包中的MAC地址資訊，根據MAC地址進行轉發，並將這些MAC地址與對應的埠記錄在自己內部的一個地址表中）
網橋：資料鏈路層（將兩個LAN連起來，根據MAC地址來轉發幀）
集線器（Hub）：物理層（純硬體裝置，主要用來連線計算機等網路終端）
中繼器：物理層（在位元級別對網路訊號進行再生和重定時，從而使得它們能夠在網路上傳輸更長的距離）
各埠對應的服務：
2、TCP和UDP的區別。
TCP即傳輸控制協議，UDP即使用者資料報協議，他們的區別主要有以下幾點：
TCP協議是面向連線的，傳送資料之前需要建立連線；UDP協議是無連線的，傳送資料之前不需要建立連線
TCP協議提供可靠的傳輸服務；UDP協議提供不可靠的傳輸服務
TCP傳送資料大小會受傳送視窗、接收視窗及MSS（最大報文段）限制，因此會分為多段傳送；UDP傳送資料大小即為資料本身大小
TCP擁有眾多反饋機制與附加機制；UDP沒有反饋機制
TCP傳輸速度較慢；UDP傳輸速度較快
總的來說，TCP協議提供面向連線的，可靠的傳輸服務，但速度較慢，適合檔案下載等傳輸任務；UDP協議提供無連線的，不可靠的傳輸服務，但速度較快，適合媒體流等看重傳輸速度的傳輸任務。
3、TCP報文結構。
其中：
Source port：源埠，16位，說明發送端的埠號
Destination port：目的埠，16位，說明接收端的埠號
Sequence number：序列號，32位，說明這個資料的序號，從而接收端接收後可以進行排序，避免接收錯序
Acknowledgement number：確認號，ACK，32位，表示說明這是對哪個資料的確認，表明期待接收編號為x的資料段，小於x的資料段已經成功接收並交給了上層
TCP header length：TCP頭部長度，4位，由於TCP頭部中帶有option，而option的長度不固定，因此需要標識頭部的長度
0（灰色那段）：padding，6位，無實際作用
標誌位：6位，作用分別如下：
URG：說明資料部分是否有緊急資料，可能導致亂序問題，因此並不會在實際中被使用
ACK：說明確認號是否有效
PSH：告訴接收方將緩衝區的資料儘快交給上層，可能會導致資料丟失，因此不會在實際中被使用
RST：重置連線，將連線強制中斷
SYN：同步標識，建立連線時使用
FIN：結束標識，關閉連線時使用
Window size：視窗大小，16位，傳送端告訴接收端自己的傳送視窗的緩衝區大小
Checksum：校驗和，16位
Urgent pointer：緊急資料指標，16位，說明資料段中哪一段資料是緊急資料
Options：0或32位，選項部分
Data：資料部分
4、TCP的三次握手與四次揮手，各個狀態名稱與含義，TIMEWAIT的作用。
各個狀態的意義如下：
LISTEN - 偵聽來自遠方TCP埠的連線請求；
SYN-SENT -在傳送連線請求後等待匹配的連線請求；
SYN-RECEIVED - 在收到和傳送一個連線請求後等待對連線請求的確認；
ESTABLISHED- 代表一個開啟的連線，資料可以傳送給使用者；
FIN-WAIT-1 - 等待遠端TCP的連線中斷請求，或先前的連線中斷請求的確認；
FIN-WAIT-2 - 從遠端TCP等待連線中斷請求；
CLOSE-WAIT - 等待從本地使用者發來的連線中斷請求；
CLOSING -等待遠端TCP對連線中斷的確認；
LAST-ACK - 等待原來發向遠端TCP的連線中斷請求的確認；
TIME-WAIT -等待足夠的時間以確保遠端TCP接收到連線中斷請求的確認；
CLOSED - 沒有任何連線狀態；
三次握手，TCP建立連線的過程：
1、客戶機發起請求，客戶端進入SYN_SEND狀態，等待伺服器端確認。
- SYN為1：說明發起新的連線
- SEQ為x：說明這個段的序列號是多少，伺服器收到後會調整接收的滑動視窗為x+1(表明下一次要接收的段的序列號為x+1)，一般隨機選取x
- 指定視窗大小的值：客戶機說明自己的接收視窗目前還可容納多少資料
2、伺服器響應請求，伺服器端進入SYN_RECV狀態。
- ACK為1：表示確認接收請求
- ACK號為x+1：表示接受了序列號位x及以下的資料，期待序列號為x+1的資料
- SYN為1：說明伺服器同意新的連線建立(只是同意，還沒有沒有分配埠資源)
- SEQ為y：說明這個段的序列號是多少，客戶機收到後會調整接收的滑動視窗為y+1(表明下一次要接收的段的序列號為y+1)，與x沒有關係
- 指定視窗大小的值：伺服器說明自己的接收視窗目前還可容納多少資料
3、伺服器響應請求，客戶端和伺服器端進入ESTABLISHED狀態。
- ACK為1：表示確認接收請求
- ACK號為y+1：表示接受了序列號位y及以下的資料，期待序列號為y+1的資料
- SEQ為x+1：說明這個段的序列號是多少，伺服器收到後會調整接收的滑動視窗為x+2(表明下一次要接收的段的序列號為x+2)
為什麼需要三次握手呢？一次握手，兩次握手為什麼不行呢？
原因如下：
一次握手：客戶機根本不知道連線的有效性
- 有可能這次握手請求根本沒有到達伺服器或者直接被伺服器拒絕。
兩次握手：伺服器無法確認該請求的合法性，如果是兩次握手伺服器將立即分配埠資源造成資源浪費，可能使得其它客戶機無法連線
- 傳送方請求連線的包在信道里面停留了很長時間，使得連線都釋放掉了這個包才到
- 會遭遇SYN泛洪攻擊：一臺惡意的主機偽造自己的IP向伺服器請求連線
四次揮手，TCP釋放連線的過程：
1、釋放連線的發起方發起釋放連線請求
- FIN為1：結束位為1，說明發起方的傳送過程已經結束，不會再向對方傳送實際資料
- SEQ為x：序列號為x
2、釋放連線的接收方回覆釋放連線請求
- ACK為1：表示確認接收請求
- ACK號為x+1：表示接受了序列號位x及以下的資料，期待序列號為x+1的資料
3、釋放連線的接收方同意釋放連線請求
- FIN為1：結束位為1，說明發起方的傳送過程已經結束，不會再向對方傳送實際資料
- SEQ為y：序列號為y
4、釋放連線的發起方回覆釋放連線請求
- ACK為1：表示確認接收請求
- ACK號為y+1：表示接受了序列號位x及以下的資料，期待序列號為y+1的資料
四次揮手中第二次是否可以去掉？
不能, 如果去掉第2次揮手。試想有一種情況，當Client傳送了FIN報文給Server，而Server這時候還想傳遞一些資訊給客戶端，如果沒有第二次握手，Server這時候直接傳送剩下的資料，那客戶端怎麼知道Server是否收到了自己傳送的關閉請求呢？如果Client知道Server接收到了自己傳送的關閉報文，那Client可以大膽的接收Server傳送的剩餘資料，因為它知道Server不會消耗太多的時間在剩餘資料上。如果Client不知道Server有沒有真正收到的關閉報文，那它自己難免會忐忑，自己在接收Server傳遞的剩餘資料的同時，要不要再次傳送新的關閉報文呢？亦或者一直等待Server端的ACK，那萬一Server端沒有收到FIN，也不會發送ACK，那是強制關閉還是一直等待呢？
TIMEWAIT:
發起方在第四次握手發出ACK後會等待一段時間後再正式釋放連線，這段時間被稱為TIME_WAIT。會有TIME_WAIT的原因主要是保證接收方能夠收到對於FIN的ACK，如果ACK在返回的過程中丟失會導致接收方超時，這時會再發一個FIN給到發起方，因此這一段時間正好是ACK返回時間加上重發的FIN到達發起方的時間。另一個原因是如果沒有TIME_WAIT就馬上建立了新的連線，那麼網路中遺留下來的舊的資料包將可能會干擾接收方的接收，接收方無法識別出是新的資料包還是舊的資料包，因此在TIME_WAIT接收到的其它資料包會被丟棄。
5、TCP阻塞控制。
由於傳送方到接收方之間的通道是公用的，因此如果傳送方不考慮中間通道的容量隨意傳送就可能出現擁塞，擁塞會導致延遲嚴重，甚至大量丟包，因此我們需要進行擁塞控制。
擁塞控制的關鍵在於控制傳送端的傳送速率，傳送端的傳送速率受到傳送視窗大小的限制，因此在TCP的擁塞控制中實際控制的是傳送端的傳送視窗大小。
當出現以下兩種情況之一時，我們斷定傳輸出現了擁塞：
- 連續(三個)的序號為x的ACK：說明序號為x的TCP資料段很可能丟失
- 超時時間到來前未收到ACK
當出現擁塞時，我們主要有以下方法進行擁塞控制：
AIMD（additive increase multiplicative decrease）：
意思即加性增加乘性減少，其初始阻塞視窗大小為任意值。
當我們每成功傳輸一個TCP資料段，擁塞視窗大小加1MSS（最大報文大小），此為加性增加；而當我們發現傳輸出現擁塞時，擁塞視窗大小減半，此為乘性減少。
這種演算法的問題在於增加的速度慢，丟包代價大。
慢啟動：
慢啟動的初始時擁塞視窗大小為1MSS（因此叫慢啟動演算法），最大為65535MSS（視窗大小隻有16bit，因此最大也只能這麼大）。慢啟動演算法開始時每成功傳輸一個TCP資料段，擁塞窗開大小也是增加1MSS，但當其發現擁塞時，會首先確定一個闕值：闕值為當前視窗大小的一半，然後根據不同的機制進行處理：
Tahoe機制：
出現擁塞時視窗大小會變回1MSS，但當視窗大小小於闕值時，傳輸成功視窗大小加倍（指數增長），大於闕值後改為加性增長。
Reno機制：
出現擁塞視窗大小直接變為闕值。（也稱為快速恢復機制）
6、TCP滑動視窗與回退N指標協議。
滑動視窗協議：
- 傳送端和接收端分別設定傳送視窗和接收視窗。
- 三次握手的時候，客戶端把自己的緩衝區大小也就是視窗大小發送給伺服器，伺服器迴應是也將視窗大小發送給客戶端，伺服器客戶端都知道了彼此的視窗大小。
- 比如主機A的傳送視窗大小為5，主機A可以向主機B傳送5個單元，如果B緩衝區滿了，A就要等待B確認才能繼續傳送資料。
- 如果B緩衝區中有1個報文被程序讀取，主機B就會回覆ACK給主機A，接收視窗向前滑動，報文中視窗大小為1，就說明A還可以傳送1個單元的資料，傳送視窗向前滑動，之後等待主機B的確認報文。
只有接收視窗向前滑動併發送了確認時，傳送窗口才能向前滑動。
1、位元滑動視窗協議
上面說的只是滑動視窗協議的理論，實際應用中又有不同。首先就是停等協議(stop－and－wait)，這時接受方的視窗和傳送方的視窗大小都是1，1個位元就夠表示了，所以也叫1位元滑動視窗協議。傳送方這時自然傳送每次只能傳送一個，並且必須等待這個資料包的ACK，才能傳送下一個。雖然在效率上比較低，頻寬利用率明顯較低，不過在網路環境較差，或是頻寬本身很低的情況下，還是適用的。
2、後退N幀協議
由於停等協議要為每一個幀進行確認後才繼續傳送下一幀，大大降低了通道利用率，因此又提出了後退n協議，這裡傳送的視窗大小為n，接受方的視窗仍然為1。後退n協議中，傳送方在發完一個數據幀後，不停下來等待應答幀，而是連續傳送若干個資料幀，即使在連續傳送過程中收到了接收方發來的應答幀，也可以繼續傳送。且傳送方在每傳送完一個數據幀時都要設定超時定時器。只要在所設定的超時時間內仍收到確認幀，就要重發相應的資料幀。如：當傳送方傳送了N個幀後，若發現該N幀的前一個幀在計時器超時後仍未返回其確認資訊，則該幀被判為出錯或丟失，此時傳送方就不得不重新發送出錯幀及其後的N幀。
例子：
假設n=9：首先發送方一口氣傳送10個數據幀，前面兩個幀正確返回了，資料幀2出現了錯誤，這時傳送方被迫重新發送2-8這7個幀，接受方也必須丟棄之前接受的2-8這幾個幀。 後退n協議的好處無疑是提高了效率，但是一旦網路情況糟糕，則會導致大量資料重發，反而不如上面的停等協議，實際上這是很常見的。
3、選擇重傳協議
在後退n協議中，接收方若發現錯誤幀就不再接收後續的幀，即使是正確到達的幀，這顯然是一種浪費。重傳協議便是用來解決這個問題。原理也很簡單，接收端總會快取所有收到的幀，當某個幀出現錯誤時，只會要求重傳這一個幀，只有當某個序號後的所有幀都正確收到後，才會一起提交給高層應用。重傳協議的缺點在於接受端需要更多的快取。
7、HTTP的報文結構。
Http協議（Hypertext Transfer Protocol）即超文字傳輸協議，它是一個應用層的基於TCP的無狀態的協議，一般的通訊過程為：建立連線、傳送請求、響應請求、釋放連線。其報文結構分為請求頭與響應頭兩種：
請求頭：
請求頭的第一行為請求行，其包括了三部分重要內容：
1、請求方法：主要為Get、Post等方法
2、URL：即請求的地址
3、協議版本：主要有Http1.0和Http1.1兩種
4、請求頭接下來是請求頭部（也叫頭域），頭域的長度是不固定的，每一個頭域屬性的格式為：欄位名：值（如：Range：請求範圍）
5、頭域下面是一行空行，表示頭域的結束。
6、空行下來就是請求要提交的資料。
響應頭：
與請求頭類似，響應頭的第一行為響應行，主要包含如下三部分內容：
1、版本：使用的Http協議版本
2、狀態碼：表示處理結果狀態的數值，由三位數字組成，第一位數字表示響應的型別，主要有以下幾種：
- 1XX：表示伺服器已接收了客戶端請求，客戶端可繼續傳送請求
- 2XX：表示伺服器已成功接收到請求並進行處理
- 3XX：表示伺服器要求客戶端重定向
- 4XX：表示客戶端的請求有非法內容
- 5XX：表示伺服器未能正常處理客戶端的請求而出現意外錯誤
3、原因短語：一串用於解釋返回該狀態碼原因的字串
4、響應行下來是響應頭域，與請求頭類似。
5、響應頭域下來是一行空行表示響應頭域的結束。
6、最後是響應頭的響應實體內容。
8、HTTP的狀態碼含義。
狀態碼位於響應頭的響應行中，表示伺服器處理結果的情況，由三位數字組成，第一位數字表示響應的型別，主要有以下幾種：
1、1XX：表示伺服器已接收了客戶端請求，客戶端可繼續傳送請求
100 (Continue/繼續)
如果伺服器收到頭資訊中帶有100-continue的請求，這是指客戶端詢問是否可以在後續的請求中傳送附件。在這種情況下，伺服器用100允許客戶端繼續或用417 (Expectation Failed)告訴客戶端不同意接受附件。這個狀態碼是 HTTP 1.1中新加入的。
101 (Switching Protocols/轉換協議)
101 狀態碼是指伺服器將按照其上的頭資訊變為一個不同的協議。這是 HTTP 1.1中新加入的。
2、2XX：表示伺服器已成功接收到請求並進行處理
200 (OK/正常)
200 的意思是一切正常。一般用於相應GET和POST請求。
201 (Created/已建立)
201表示伺服器在請求的響應中建立了新文件；應在定位頭資訊中給出它的URL。
202 (Accepted/接受)
202告訴客戶端請求正在被執行，但還沒有處理完。
203 (Non-Authoritative Information/非官方資訊)
狀態碼203是表示文件被正常的返回，但是由於正在使用的是文件副本所以某些響應頭資訊可能不正確。這是 HTTP 1.1中新加入的。
204 (No Content/無內容)
在並沒有新文件的情況下，204確保瀏覽器繼續顯示先前的文件。這各狀態碼對於使用者週期性的過載某一頁非常有用，並且你可以確定先前的頁面是否已經更新。但是，這種方法對通過重新整理響應頭資訊或等價的HTML標記自動過載的頁面起作用，因為它會返回一個204狀態碼停止以後的過載。但基於JavaScript指令碼的自動過載在這種情況下仍然需要能夠起作用。
205 (Reset Content/重置內容)
重置內容205的意思是雖然沒有新文件但瀏覽器要重置文件顯示。這個狀態碼用於強迫瀏覽器清除表單域。這是 HTTP 1.1中新加入的。
206 (Partial Content/區域性內容)
206是在伺服器完成了一個包含Range頭資訊的區域性請求時被髮送的。這是 HTTP 1.1中新加入的。
3、3XX：表示伺服器要求客戶端重定向
300 (Multiple Choices/多重選擇)
300表示被請求的文件可以在多個地方找到，並將在返回的文件中列出來。如果伺服器有首選設定，首選項將會被列於定位響應頭資訊中。
301 (Moved Permanently)
301狀態是指所請求的文件在別的地方；文件新的URL會在定位響應頭資訊中給出。瀏覽器會自動連線到新的URL。
302 (Found/找到)
與301有些類似，只是定位頭資訊中所給的URL應被理解為臨時交換地址而不是永久的。注意：在 HTTP 1.0中，訊息是臨時移動(Moved Temporarily)的而不是被找到。
303 (See Other/參見其他資訊)
這個狀態碼和 301、302 相似，只是如果最初的請求是 POST，那麼新文件（在定位頭資訊中給出）藥用 GET 找回。這個狀態碼是新加入 HTTP 1.1中的。
304 (Not Modified/為修正)
當客戶端有一個快取的文件，通過提供一個 If-Modified-Since 頭資訊可指出客戶端只希望文件在指定日期之後有所修改時才會過載此文件，用這種方式可以進行有條件的請求。304是指緩衝的版本已經被更新並且客戶端應重新整理文件。另外，伺服器將返回請求的文件及狀態碼 200。
305 (Use Proxy/使用代理)
305表示所請求的文件要通過定位頭資訊中的代理伺服器獲得。這個狀態碼是新加入 HTTP 1.1中的。
307 (Temporary Redirect/臨時重定向)
瀏覽器處理307狀態的規則與302相同。307狀態被加入到 HTTP 1.1中是由於許多瀏覽器在收到302響應時即使是原始訊息為POST的情況下仍然執行了錯誤的轉向。只有在收到303響應時才假定瀏覽器會在POST請求時重定向。新增這個新的狀態碼的目的很明確：在響應為303時按照GET和POST請求轉向；而在307響應時則按照GET請求轉向而不是POST請求。該狀態碼是新加入HTTP 1.1中的。
4、4XX：表示客戶端的請求有非法內容
400 (Bad Request/錯誤請求)
400指出客戶端請求中的語法錯誤。
401 (Unauthorized/未授權)
401表示客戶端在授權頭資訊中沒有有效的身份資訊時訪問受到密碼保護的頁面。這個響應必須包含一個WWW-Authenticate的授權資訊頭。
403 (Forbidden/禁止)
403的意思是除非擁有授權否則伺服器拒絕提供所請求的資源。這個狀態經常會由於伺服器上的損壞檔案或目錄許可而引起。
404 (Not Found/未找到)
404狀態每個網路程式設計師可能都遇到過，他告訴客戶端所給的地址無法找到任何資源。它是表示“沒有所訪問頁面”的標準方式。
405 (Method Not Allowed/方法未允許)
405指出請求方法(GET, POST, HEAD, PUT, DELETE, 等)對某些特定的資源不允許使用。該狀態碼是新加入 HTTP 1.1中的。
406 (Not Acceptable/無法訪問)
406表示請求資源的MIME型別與客戶端中Accept頭資訊中指定的型別不一致。406是新加入 HTTP 1.1中的。
407 (Proxy Authentication Required/代理伺服器認證要求)
407與401狀態有些相似，只是這個狀態用於代理伺服器。該狀態指出客戶端必須通過代理伺服器的認證。代理伺服器返回一個Proxy-Authenticate響應頭資訊給客戶端，這會引起客戶端使用帶有Proxy-Authorization請求的頭資訊重新連線。該狀態碼是新加入 HTTP 1.1中的。
408 (Request Timeout/請求超時)
408是指服務端等待客戶端傳送請求的時間過長。該狀態碼是新加入 HTTP 1.1中的。
409 (Conflict/衝突)
該狀態通常與PUT請求一同使用，409狀態常被用於試圖上傳版本不正確的檔案時。該狀態碼是新加入 HTTP 1.1中的。
410 (Gone/已經不存在)
410告訴客戶端所請求的文件已經不存在並且沒有更新的地址。410狀態不同於404，410是在指導文件已被移走的情況下使用，而404則用於未知原因的無法訪問。該狀態碼是新加入 HTTP 1.1中的。
411 (Length Required/需要資料長度)
411表示伺服器不能處理請求（假設為帶有附件的POST請求），除非客戶端傳送Content-Length頭資訊指出傳送給伺服器的資料的大小。該狀態是新加入 HTTP 1.1的。
412 (Precondition Failed/先決條件錯誤)
412狀態指出請求頭資訊中的某些先決條件是錯誤的。該狀態是新加入 HTTP 1.1的。
413 (Request Entity Too Large/請求實體過大)
413告訴客戶端現在所請求的文件比伺服器現在想要處理的要大。如果伺服器認為能夠過一段時間處理，則會包含一個Retry-After的響應頭資訊。該狀態是新加入 HTTP 1.1的。
414 (Request URI Too Long/請求URI過長)
414狀態用於在URI過長的情況時。這裡所指的“URI”是指URL中主機、域名及埠號之後的內容。該狀態是新加入 HTTP 1.1的。
415 (Unsupported Media Type/不支援的媒體格式)
415意味著請求所帶的附件的格式型別伺服器不知道如何處理。該狀態是新加入 HTTP 1.1的。
416 (Requested Range Not Satisfiable/請求範圍無法滿足)
416表示客戶端包含了一個伺服器無法滿足的Range頭資訊的請求。該狀態是新加入 HTTP 1.1的。
417 (Expectation Failed/期望失敗)
如果伺服器得到一個帶有100-continue值的Expect請求頭資訊，這是指客戶端正在詢問是否可以在後面的請求中傳送附件。在這種情況下，伺服器也會用該狀態(417)告訴瀏覽器伺服器不接收該附件或用100狀態告訴客戶端可以繼續傳送附件。該狀態是新加入 HTTP 1.1的。
5、5XX：表示伺服器未能正常處理客戶端的請求而出現意外錯誤
500 (Internal Server Error/內部伺服器錯誤)
500是常用的“伺服器錯誤”狀態。
501 (Not Implemented/未實現)
501狀態告訴客戶端伺服器不支援請求中要求的功能。例如，客戶端執行了如PUT這樣的伺服器並不支援的命令。
502 (Bad Gateway/錯誤的閘道器)
502被用於充當代理或閘道器的伺服器；該狀態指出接收伺服器接收到遠端伺服器的錯誤響應。
503 (Service Unavailable/服務無法獲得)
狀態碼503表示伺服器由於在維護或已經超載而無法響應。
504 (Gateway Timeout/閘道器超時)
該狀態也用於充當代理或閘道器的伺服器；它指出接收伺服器沒有從遠端伺服器得到及時的響應。該狀態是新加入 HTTP 1.1的。
505 (HTTP Version Not Supported/不支援的 HTTP 版本)
505狀態碼是說伺服器並不支援在請求中所標明 HTTP 版本。該狀態是新加入 HTTP 1.1的。
9、HTTP Request的幾種型別。
在Http中主要包含以下請求方法：
GET： 請求指定的頁面資訊，並返回實體主體
HEAD： 只請求頁面的首部。
POST： 請求伺服器接受所指定的文件作為對所標識的URI的新的從屬實體
PUT： 從客戶端向伺服器傳送的資料取代指定的文件的內容
DELETE： 請求伺服器刪除指定的頁面
OPTIONS： 允許客戶端檢視伺服器的效能
TRACE： 請求伺服器在響應中的實體主體部分返回所得到的內容
PATCH： 實體中包含一個表，表中說明與該URI所表示的原內容的區別
MOVE： 請求伺服器將指定的頁面移至另一個網路地址
COPY： 請求伺服器將指定的頁面拷貝至另一個網路地址
LINK： 請求伺服器建立連結關係
UNLINK： 斷開連結關係
WRAPPED： 允許客戶端傳送經過封裝的請求
CONNECT：用於動態切換到隧道的代理
其中Http1.0僅支援GET、HEAD和POST，其餘方法均為Http1.1新增。值的注意的是：GET方法與POST方法類似，但GET方法引數寫在URL上，POST引數寫在請求實體內容中，且GET方法引數不大於1024Byte，POST則沒有限制。
10、HTTP1.1與HTTP1.0的區別。
Http1.0與Http1.1主要有以下區別：
- 是否允許複用連線：Http1.0不允許，響應請求後就斷開連線，Http1.1允許且預設開啟連線複用
- Host頭域：Http1.0沒有，Http1.1有
- 狀態碼：Http1.1比Http1.0多了100,101（轉換協議）,203（非官方資訊）,205（重置內容）等狀態碼
- 請求方式：Http1.0只有GET、HEAD和POST方法，Http1.1新增了其他多種方法
11、HTTP怎麼處理長連線。
長連線，指在一個連線上可以連續傳送多個數據包，在連線保持期間，如果沒有資料包傳送，需要雙方發鏈路檢測包。
連線→資料傳輸→保持連線(心跳)→資料傳輸→保持連線(心跳)→……→關閉連線（一個TCP連線通道多個讀寫通訊）。
心跳包：
- 檢測長連線的重要技術手段。
- 可以由伺服器傳送：定時向客戶端傳送小資料，根據回執判斷客戶端是否線上。
- 也可由客戶端傳送：定時向伺服器傳送小資料，報告客戶端當前線上。
Http協議是一個短連線、無狀態的基於TCP的協議，預設的流程是：建立連線-->傳送請求-->響應請求-->斷開連線。
在Http1.1中加入了保持長連線的功能，可以通過Http頭域屬性Connection:keep-alive開啟。
另外，我們也可以使用Http輪詢來模擬長連線的過程。
Http長輪詢：
http 長輪詢是server 收到請求後如果有資料，立刻響應請求；如果沒有資料 就會停留一段時間，這段時間內，如果 server 請求的資料到達（如查詢資料庫或資料的邏輯處理完成），就會立刻響應；如果這段時間過後，還沒有資料到達，則以空資料的形式響應http請求；若瀏覽器收到的資料為空，會再次傳送同樣的http請求到server；
缺點：
server 沒有資料到達時，http連線會停留一段時間，這會造成伺服器資源浪費；
短輪詢：
http 短輪詢是 server 收到請求 不管是否有資料到達都直接響應http 請求；如果瀏覽器收到的資料為空，則隔一段時間，瀏覽器又會發送相同的http請求到server 以獲取資料響應；
缺點：
訊息互動的實時性較低（server端到瀏覽器端的資料反饋效率低）
異同點：
相同點：
當server 的資料不可達時，基於http長輪詢和短輪詢 的http請求，都會 停留一段時間；
不同點：
http長輪詢是在伺服器端的停留，而http 短輪詢是在 瀏覽器端的停留；
效能總結：
不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的TCP連線數是有上限的，這種輪詢很容易把連線數頂滿；
12、Cookie和Session的作用與原理。
由於Http協議是一種短連線的、無狀態的協議，因此如果我們一般無法獲取客戶端以前的請求資訊與狀態資訊。
為了解決這個問題，儲存請求的狀態，Cookie和Session出現了。簡單來說，Cookie存於客戶端，而Session存於伺服器，它們都儲存和使用者歷史請求相關的資訊。在傳送Http請求時Cookie或SessionId會隨被加入請求引數中一起發給伺服器，伺服器根據Cookie的資訊或SessionId查詢到的Session資訊來得知客戶端的狀態資訊，進而進行進一步的相關操作。
Cookie
- cookie被儲存於客戶端
- cookie在RFC（請求註釋）有定義
- 與cookie相關的頭域引數有cookie和set-cookie
Session
- session被儲存與伺服器
- session並沒有在Http協議中有明確的定義
- session通過sessionId來區分不同的使用者
- 與cookie相比，儲存在伺服器的session顯得更為安全
- session通常的實現方法有兩種：
（1）通過cookie實現，在cookie中儲存sessionId
（2）回寫URL實現，在網頁的連線中加入sessionId
13、電腦上訪問一個網頁，整個過程是怎樣的？
- 我們在瀏覽器中輸入網址，但電腦並不認識如此複雜的字串，因此電腦使用DNS服務解析出對應的IP地址
- 訪問網頁的過程基於Http協議，因此我們訪問網頁的過程實際上就是Http協議傳送請求和響應請求的過程
- Http協議是應用層協議，它基於傳輸層的TCP協議，TCP協議描述了程序與程序間如何通訊交流，把具體的傳輸過程交給下層的網路層
- 網路層由IP協議控制資料包的路由選擇和儲存轉發，但由於網路上的主機太多，IP協議管理不過來，因此又把網路主機分為多塊，在外部使用EGP外部閘道器協議，在內部使用IGP內部閘道器協議（包括RIP協議（路由資訊協議內部）與OSPF協議（開放式最短路徑優先外部））
- 當網路層的資料傳輸到乙太網後，就通過ARP協議獲取目標主機的MAC地址，最後把資料傳輸的任務交給資料鏈路層處理
14、Ping的整個過程。ICMP協議是什麼？
ICMP即Internet Control Message Protocol，網路控制報文協議，是一個網路層的用於在IP主機、路由器之間傳遞控制訊息的協議。控制訊息是指網路通不通、主機是否可達、路由是否可用等網路本身的訊息。這些控制訊息雖然並不傳輸使用者資料，但是對於使用者資料的傳遞起著重要的作用。
其中Ping是ICMP協議中的指令之一，其主要作用的是檢查網路的連通情況和檢測網路的速度。
Ping的過程主要有如下步驟：
- 檢查本地ARP快取，查詢目標主機的MAC地址
- 如果沒有找到MAC地址，使用ARP協議獲取目標主機MAC地址，並放入ARP快取
- 發出ICMP echo request包，接收ICMP echo reply包
15、C/S模式下使用Socket通訊，幾個關鍵函式。
對於Java Socket程式設計而言，有兩個概念，一個是Server-Socket(port)，一個是Socket（ip，port）。服務端和客戶端之間通過Socket建立連線，之後它們就可以進行通訊了。首先ServerSocket將在服務端監聽某個埠，當發現客戶端有Socket來試圖連線它時，它會accept該Socket的連線請求，同時在服務端建立一個對應的Socket與之進行通訊。這樣就有兩個Socket了，客戶端和服務端各一個。
對於Socket之間的通訊其實很簡單，服務端往Socket的輸出流裡面寫東西，客戶端就可以通過Socket的輸入流讀取對應的內容。Socket與Socket之間是雙向連通的，所以客戶端也可以往對應的Socket輸出流裡面寫東西，然後服務端對應的Socket的輸入流就可以讀出對應的內容。
16、IP地址分類。
IP地址分為IPv4地址（32位）和IPv6地址（128位），在此我們討論IPv4地址。
IP地址由兩部分（網路部分和主機部分）組成，可以分為有類網和無類網兩類。
有類網：
有類網分為以下5種：
- A類網：第一位為0，後7位為網路號，剩餘24位為主機號，10.0.0.0~10.255.255.255 即10.0.0.0/8。
- B類網：前兩位為10，後14位為網路號，剩餘16位為主機號，172.16.0.0~172.31.255.255即172.16.0.0/12。
- C類網：前三位為110，後21位為網路號，剩餘8位為主機號，192.168.0.0~192.168.255.255 即192.168.0.0/16。
- D類網（不可用）：前四位為1110，後28位為多播地址。
- E類網（不可用）：前四位為1111，被保留。
除了D類網與E類網不能使用外，A、B和C類網IP均可用來表示一臺主機。我們一般根據自己網路中主機的多少來選擇A、B還是C類網，但一般而言網路中的主機數目都不會剛好等於有類網提供的主機數，於是經常會造成有多餘的IP地址浪費，因此我們有了無類網。
無類網：
無類網加入了子網掩碼的概念。子網掩碼是一個32位地址，用於將某個IP地址劃分成網路地址和主機地址兩部分。在子網掩碼中我們以1表示為網路號，例：255.255.255.0表示前24位為網路號。
17、路由器和交換機的區別。
路由器工作於網路模型的網路層，其主要的功能是路由選擇與儲存轉發，路由器上還能開啟ACL訪問控制列表（報文過濾器）、NAT地址轉換等功能，擴充套件網路應用。
交換機工作於網路模型的資料鏈路層，其主要的功能是泛洪、儲存轉發、過濾和自學習，交換機還能夠隔離衝突域，並劃分VLAN。
18、各種協議介紹。
ARP：
1：首先，每個主機都會在自己的ARP緩衝區中建立一個ARP列表，以表示IP地址和MAC地址之間的對應關係。
2：當源主機要傳送資料時，首先檢查ARP列表中是否有對應IP地址的目的主機的MAC地址，如果有，則直接傳送資料，如果沒有，就向本網段的所有主機發送ARP資料包，該資料包包括的內容有：源主機 IP地址，源主機MAC地址，目的主機的IP 地址。
3：當本網路的所有主機收到該ARP資料包時，首先檢查資料包中的IP地址是否是自己的IP地址，如果不是，則忽略該資料包，如果是，則首先從資料包中取出源主機的IP和MAC地址寫入到ARP列表中，如果已經存在，則覆蓋，然後將自己的MAC地址寫入ARP響應包中，告訴源主機自己是它想要找的MAC地址。
4：源主機收到ARP響應包後。將目的主機的IP和MAC地址寫入ARP列表，並利用此資訊傳送資料。如果源主機一直沒有收到ARP響應資料包，表示ARP查詢失敗。
RARP：
作用是完成硬體地址到IP地址的對映，主要用於無盤工作站，因為給無盤工作站配置的IP地址不能儲存。工作流程：在網路中配置一臺RARP伺服器，裡面儲存著IP地址和MAC地址的對映關係，當無盤工作站啟動後，就封裝一個RARP資料包，裡面有其MAC地址，然後廣播到網路上去，當伺服器收到請求包後，就查詢對應的MAC地址的IP地址裝入響應報文中發回給請求者。因為需要廣播請求報文，因此RARP只能用於具有廣播能力的網路。
TFTP：是TCP/IP協議族中的一個用來在客戶機與伺服器之間進行簡單檔案傳輸的協議，提供不復雜、開銷不大的檔案傳輸服務。
HTTP： 超文字傳輸協議，是一個屬於應用層的面向物件的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。
NAT：網路地址轉換屬接入廣域網(WAN)技術，是一種將私有（保留）地址轉化為合法IP地址的轉換技術。
DHCP：動態主機配置協議，是一種讓系統得以連線到網路上，並獲取所需要的配置引數手段，使用UDP協議工作。具體用途：給內部網路或網路服務供應商自動分配IP地址，給使用者或者內部網路管理員作為對所有計算機作中央管理的手段。
19、DNS域名系統，及其工作原理。
什麼是DNS：
一種組織成域層次結構的計算機和網路命名系統，它用於TCP/IP網路，他所提供的服務是用於將主機名和域名轉換為IP地址的工作。它基於UDP服務，埠53。該應用一般不直接為使用者使用，而是為其他應用服務，如HTTP，SMTP等在其中需要完成主機名到IP地址的轉換。
DNS資料庫中的名稱形成一個分層樹狀結構稱為域名稱空間。域名包含單個標籤分割點。例如：www.qq.com.。
DNS域名空間的組織方式：
DNS服務的工作過程：
當 DNS 客戶
