本文分文五大部分，第一部分總綱說明計算機網路層次劃分的三種模型，一到四部分以TCP/IP協議模型作為劃分標準，分別說明各層作用和最常見的面試題，最后總結網路綜合面試題，歷時六天全文一千字，
其他經典面試題參考程式員田同學

一、總綱

寫過代碼的同學就多多少少接觸過GET、POST、HTTP、TCP等名詞，很多基礎不扎實的同學并不知道它們都是什么東西，其實這些名詞都是計算機網路中各層的協議，計算機網路分層主要是三種分法，OSI七層模型、TCP\IP四層模型、學習型五層協議，

1、計算機各層協議及作用

OSI 的七層協議體系結構的概念清楚，理論也較完整，但它既復雜又不實用，

TCP/IP 體系結構則不同，但它現在卻得到了非常廣泛的應用，TCP/IP 是一個四層體系結構，它包含應用層，運輸層，網際層和網路介面層（用網際層這個名字是強調這一層是為了解決不同網路的互連問題），不過從實質上講，TCP/IP 只有上面的三層，因為下面的網路介面層并沒有什么具體內容，

因此在學習計算機網路的原理時往往采用折中的辦法，即綜合 OSI 和 TCP/IP 的優點，采用 一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚，有時為了方便，也可把底下兩層稱為網路介面層，

TCP（傳輸控制協議）和IP（網際協議） 是先定義的兩個核心協議，所以才統稱為TCP/IP協議族

七層網路體系結構各層的主要功能：

• 應用層：為應用程式提供互動服務，在互聯網中的應用層協議很多，如域名系統DNS，支持萬維網應用的HTTP協議，支持電子郵件的SMTP協議等，

• 表示層：主要負責資料格式的轉換，如加密解密、轉換翻譯、壓縮解壓縮等，

• 會話層：負責在網路中的兩節點之間建立、維持和終止通信，如服務器驗證用戶登錄便是由會話層完成的，

• 運輸層：有時也譯為傳輸層，向主機行程提供通用的資料傳輸服務，該層主要有以下兩種協議：

  • TCP：提供面向連接的、可靠的資料傳輸服務；
  • UDP：提供無連接的、盡最大努力的資料傳輸服務，但不保證資料傳輸的可靠性，

• 網路層：選擇合適的路由和交換結點，確保資料及時傳送，主要包括IP協議、路由器，

• 資料鏈路層：資料鏈路層通常簡稱為鏈路層，將網路層傳下來的IP資料包組裝成幀，并再相鄰節點的鏈路上傳送幀，包括交換機，

• 物理層：實作相鄰節點間位元流的透明傳輸，盡可能屏蔽傳輸介質和通信手段的差異，

  本章節是學習下面章節的基礎，只有明白網路分層中各層的作用才能準備判斷TCP、HTTP位于網路協議中的哪一層，

二、應用層

應用層的任務是通過應用行程間的互動來完成特定網路應用，應用層協議定義的是應用行程間的通信和互動的規則，

對于不同的網路應用需要不同的應用層協議，在互聯網中應用層協議很多，如域名系統 DNS，支持萬維網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等，

1、http和https區別

①HTTP請求由三部分組成

①請求行，請求方法欄位、URL欄位、HTTP協議版本（例如：GET /index.html HTTP/1.1）

②請求頭，key-value形式（User-Agent：產生請求的瀏覽器型別，Accept：客戶端可識別的內容型別串列，Host：主機地址）

③請求資料，POST請求中key-value形式發送，

②HTTP版本更新

HTTP 協議有 HTTP/1.0 版本和 HTTP/1.1 版本，HTTP1.1 默認保持長連接（當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP資料的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接，Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟體（如Apache）中設定這個時間，實作長連接要客戶端和服務端都支持長連接，）資料傳輸完成了保持 TCP 連接不斷開（不發 RST 包、不四次握手），等待在同域名下繼續用這個通道傳輸資料，

在 HTTP/1.0 中，默認使用的是短連接（瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接），也就是說，瀏覽器和服務器每進行一次 HTTP 操作，就建立一次連接，任務結束就中斷連接，從 HTTP/1.1 起，默認使用的是長連接，用以保持連接特性，

• HTTP 1.0

  1. 短連接：每次發送請求都要重新建立tcp請求，即三次握手，非常浪費性能
  2. 無host頭域，也就是http請求頭里的host，
  3. 不允許斷點續傳，而且不能只傳輸物件的一部分，要求傳輸整個物件

• HTTP 2.0

? 1.頭部壓縮，雙方各自維護一個header的索引表，使得不需要直接發送值，通過發送key縮減頭部大小

? 2.多路復用，使用多個stream，每個stream又分幀傳輸，使得一個tcp連接能夠處理多個http請求

? 3.可以使用服務端推送

• HTTP3.0

  1. 基于google的QUIC協議，而quic協議是使用udp實作的
  2. 減少了tcp三次握手時間，以及tls握手時間
  3. 解決了http 2.0中前一個stream丟包導致后一個stream被阻塞的問題
  4. 優化了重傳策略，重傳包和原包的編號不同，降低后續重傳計算的消耗
  5. 連接遷移，不再用tcp四元組確定一個連接，而是用一個64位亂數來確定這個連接
  6. 更合適的流量控制

③HTTPS原理

在學習HTTPS原理之前我們先學習兩個計算機網路中加密的概念，

對稱加密：通信雙方都使用同一個秘鑰進行加密和解密，無法解決首次把秘鑰發送給對方時，很容易被截獲的問題，

非對稱加密：公鑰和私鑰組成一個密鑰對，用私鑰加密的資料，只有對應的公鑰才能解密，用公鑰加密的資料，只有對應的私鑰才能解密，通信雙方的手里都有一套自己的密鑰對，通信之前雙方會先把自己的公鑰都發送給對方，然后 對方拿這個公鑰來加密要發送的資料，接收方用自己的私鑰對其解密，問題是速度慢，

將HTTP變成HTTPS時，這時候需要一個 證書頒發機構（CA），證書中包括簽發者、證書用途、使用者的公鑰私鑰和 Hash 演算法、證書到期時間等，另外使用 數字簽名 這一技術：使用 CA 自帶的 Hash 演算法對證書內容進行 Hash 得到一個摘要（指紋），再用 CA 的私鑰加密，生成數字簽名，接收者收到證書時，使用同樣的 Hash 演算法再次生成訊息摘要，然后用 CA 的公鑰對數字簽名解密，將它和訊息摘要對比，就知道有沒有被篡改，

④HTTPS和HTTP對比

2、GET和POST區別

最重要的區別就是get產生一個TCP資料包，而post產生兩個TCP資料包，

對于get的請求，瀏覽器會把瀏覽器的header和data一起發送出去，服務器回應200，對于post，瀏覽器先發送header，瀏覽器回應100，瀏覽器再發送data，服務器回應200，也就是說get只需要汽車跑一趟就把貨送到了，而post需要跑兩趟，第一趟先去和服務器打個招呼告訴它我等下要送貨過來，開門迎接我，第二趟就是把貨送過去，

據研究，在網路環境好的情況下，發一次包的時間和發兩次包的時間查基本可以無視，而在網路環境差的情況下，兩次包的TCP在驗證資料包完整性上有很大的優勢，所以不推薦使用get來優化性能，當然，并不是所有的瀏覽器都會在post中發兩次tcp包，火狐瀏覽器就只發一次

下面我們看看get和post應用上的區別：

①get的引數通過URL傳遞，post放在request body（請求頭）中

②get在URL中的引數是有長度限制的，而post沒有，GET 方式提交的資料最多只能是 1024 位元組，理論上POST 沒有限制，可傳較大量的資料，其實這樣說是錯誤的，不準確的：“GET 方式提交的資料最多只能是 1024 位元組"，因為 GET 是通過 URL 提交資料，那么 GET 可提交的資料量就跟URL 的長度有直接關系了，而實際上，URL 不存在引數上限的問題，HTTP 協議規范沒有對 URL 長度進行限制，這個限制是特定的瀏覽器及服務器對它的限制，IE 對URL 長度的限制是2083 位元組(2K+35)，對于其他瀏覽器，如Netscape、FireFox 等，理論上沒有長度限制，其限制取決于作業系統的支持，

③get只能進行URL編碼，而post支持多種，

④get只接受ASSIC字符，而post沒有限制，

⑤post比get安全，因為get的引數暴露在URL中，

3、常見HTTP狀態碼

三、傳輸層

1、TCP和UDP的區別

①TCP面向連接，而UDP是無連接的

②TCP可靠（HTTP、HTTPS、FTP），UDP不可靠（視頻、DNS）

③TCP只支持點對點通信，而UDP支持1對1，1對多，多對1，多對多的通信模式

④TCP是面向位元組流的，UDP是面向報文的

⑤TCP有擁塞控制，UDP沒有擁塞控制，適合媒體通信

⑥TCP首部開銷（20位元組）比UDP首部開銷（8個位元組）要大

2、TCP三次握手四次揮手*

①標志位

標志位一共有6種，分別是：

1. SYN(synchronous)： 發送/同步標志，用來建立連接，和下面的第二個標志位ACK搭配使用，連接開始時，SYN=1，ACK=0，代表連接開始但是未獲得回應，當連接被回應的時候，標志位會發生變化，其中ACK會置為1，代表確認收到連接請求，此時的標志位變成了 SYN=1，ACK=1，
2. ACK(acknowledgement)：確認標志，表示確認收到請求，
3. PSH(push) ：表示推送操作，就是指資料包到達接收端以后，不對其進行佇列處理，而是盡可能的將資料交給應用程式處理；
4. FIN(finish)：結束標志，用于結束一個TCP會話；
5. RST(reset)：重置復位標志，用于復位對應的TCP連接，
6. URG(urgent)：緊急標志，用于保證TCP連接不被中斷，并且督促中間層設備盡快處理，

此外，還有兩個序號：

1. Sequence number ：順序號，發送資料包中的第一個位元組的序列號，一般為小寫的seq，

2. Acknowledge number：確認號，一般為小寫的ack，回應前面的seq，值為seq+1，

   在理解三次握手和四次揮手時結合圖，看三到四遍便可理解

②三次握手（請求鏈接）

所謂三次握手，是指建立一個TCP連接時，需要客戶端和服務器總共發送3個包， 三次握手的目的是連接服務器指定埠，建立TCP連接,并同步連接雙方的順序號和確認號并交換 TCP資訊，

第一次握手：客戶端Client發送位碼為SYN＝1，隨機產生seq=x的資料包到服務器，服務器Server由SYN=1知道，客戶端Client要求建立聯機；

第二次握手：服務器Server收到請求后要確認聯機資訊，向客戶端Client發送ack=(客戶端Client請求連接時的seq)+1，SYN=1，ACK=1，產生seq=y的包,代表接收到連接請求并且向客戶端再次確認；

第三次握手：客戶端Client收到后檢查ack是否正確，即第一次發送的seq+1，以及位碼ACK是否為1，代表收到了服務器端發過來的確認資訊，之后客戶端Client會再向服務器發送ack=(服務器Server的seq+1)，ACK=1，服務器Server收到后確認ack 值與ACK=1，連接建立成功，

③四次揮手（請求斷開）

客戶端Client行程發出連接釋放報文，并且停止發送資料，其中FIN=1，順序號為seq=m（等于前面已經傳送過來的資料的最后一個位元組的序號加1），此時，客戶端Client進入FIN-WAIT-1（終止等待1）狀態， TCP規定，FIN報文段即使不攜帶資料，也要消耗一個序號，

服務器Server收到連接釋放報文，發出確認報文，ACK=1，ack=m+1，并且帶上自己的順序號seq=n，此時，服務器Server就進入了CLOSE-WAIT（關閉等待）狀態，TCP服務器通知高層的應用行程，客戶端Client向服務器的方向就釋放了，這時候處于半關閉狀態，即客戶端Client已經沒有資料要發送了，但是服務器Server若發送資料，客戶端Client依然要接受，這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間，

客戶端Client收到服務器Server的確認資訊后，此時，客戶端Client就進入FIN-WAIT-2（終止等待2）狀態，等待服務器Server發送連接釋放報文（在這之前還需要接受服務器Server發送的最后的資料），

服務器Server將最后的資料發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=m+1，由于在半關閉狀態，服務器Server很可能又發送了一些資料，假定此時的順序號為seq=p，此時，服務器Server就進入了LAST-ACK（最后確認）狀態，等待客戶端Client的確認，

客戶端Client收到服務器Server的連接釋放報文后，必須發出確認，ACK=1，ack=p+1，而自己的順序號是seq=m+1，此時，客戶端Client就進入了TIME-WAIT（時間等待）狀態，注意此時TCP連接還沒有釋放，必須經過2*MSL（最長報文段壽命）的時間后，當客戶端Client撤銷相應的TCB（保護程式）后，才進入CLOSED狀態，TIME_WAIT 需要等待 2MSL，在大量短連接的情況下，TIME_WAIT會太多，這也會消耗很多系統資源，對于服務器來說，在 HTTP 協議里指定 KeepAlive（瀏覽器重用一個 TCP 連接來處理多個 HTTP 請求），由瀏覽器來主動斷開連接，可以一定程度上減少服務器的這個問題，

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

④握手三次揮手四次原因

服務器在收到客戶端的 FIN 報文段后，可能還有一些資料要傳輸，所以不能馬上關閉連接，但是會做出應答，回傳 ACK 報文段.

接下來可能會繼續發送資料，在資料發送完后，服務器會向客戶單發送 FIN 報文，表示資料已經發送完畢，請求關閉連接，服務器的ACK和FIN一般都會分開發送，從而導致多了一次，因此一共需要四次揮手，

⑤二次握手行不行

（1）為了防止已經失效的連接請求報文突然又傳送到了服務器端（網路堵塞的原因）

如果客戶端發出的連接請求報文并未丟失而是在某個網路結點長時間堵塞了，導致延誤到連接釋放以后的某個時間才到達服務器，這時服務器誤以為是客戶端發出了一個新的連接請求，于是就向客戶端發送確認資料包，同意建立連接，

如果不采用三次握手，那么只要服務器端發送確認資料包，連接就建立成功了，由于客戶端并未發出連接請求，所以不會理睬服務器的確認，也不與服務器通信，而這個時候服務器一直在等待客戶端發送資料，這樣服務器就白白浪費了資源，如果采用三次握手，那么服務器端密鑰收到來自客戶端的確認，就知道客戶端并沒有請求建立連接，就不會建立連接，

（2）三次握手才能讓雙方均確認自己和對方的發送和接收能力都正常，

第一次握手：客戶端只是發送處請求報文段，什么都無法確認，而服務器可以確認自己的接收能力和對方的發送能力正常；

第二次握手：客戶端可以確認自己發送能力和接收能力正常，對方發送能力和接收能力正常；

第三次握手：服務器可以確認自己發送能力和接收能力正常，對方發送能力和接收能力正常；

可見三次握手才能讓雙方都確認自己和對方的發送和接收能力全部正常，這樣就可以愉快地進行通信了，

（3）告知對方自己的初始序號值，并確認收到對方的初始序號值，

TCP 實作了可靠的資料傳輸，原因之一就是 TCP 報文段中維護了序號欄位和確認序號欄位，通過這兩個欄位雙方都可以知道在自己發出的資料中，哪些是已經被對方確認接收的，這兩個欄位的值會在初始序號值得基礎遞增，如果是兩次握手，只有發起方的初始序號可以得到確認，而另一方的初始序號則得不到確認，

⑥揮手三次行不行

三次和四次的區別就在于服務器連續給客戶端發了兩個報文，那把這兩個報文合并成一個不可以嗎？為什么呢？答案是不可以，首先客戶端發來請求斷開連接的報文，假設這個時候服務器端仍然在發送報文（因為是全雙工），如果是三次揮手，那么服務器只會確認客戶的斷開請求，客戶端不會說我還有資料沒有發送完，你要等等我，這樣會導致客戶端接收的資料不完整，

如果是四次揮手，那么服務器接收到客戶的斷開請求，會先說可以斷開，但是你要先等我發送完剩余的資料，然后說我剩余的資料發送完了，我要和你斷開連接

揮手程序之所以比握手程序多一次，就是因為握手程序只需要處理連接，而揮手程序需要處理連接和資料，

3、TCP協議保證可靠性

TCP主要提供了資料表檢驗和、序列號/確認應答、超時重傳、滑動視窗、擁塞控制和流量控制等方法實作了可靠性傳輸，

• 資料包校驗：目的是檢測資料在傳輸程序中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出回應，這時TCP發送資料端超時后會重發資料，

• 序列號/確認應答：

  序列號的作用不僅僅是應答的作用，有了序列號能夠將接收到的資料根據序列號排序，并且去掉重復序列號的資料，

  TCP傳輸的程序中，每次接收方收到資料后，都會對傳輸方進行確認應答，也就是發送ack報文，這個ack報文當中帶有對應的確認序列號，告訴發送方，接收到了哪些資料，下一次的資料從哪里發，

• 滑動視窗：滑動視窗既提高了報文傳輸的效率，也避免了發送方發送過多的資料而導致接收方無法正常處理的例外，

• 超時重傳：超時重傳是指發送出去的資料包到接收到確認包之間的時間，如果超過了這個時間會被認為是丟包了，需要重傳，最大超時時間是動態計算的，

• 擁塞控制：在資料傳輸程序中，可能由于網路狀態的問題，造成網路擁堵，此時引入擁塞控制機制，在保證TCP可靠性的同時，提高性能，

• 流量控制：TCP連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許另一端發送接收端緩沖區所能接納的資料，這可以防止較快主機致使較慢主機的緩沖區溢位，這就是流量控制，TCP使用的流量控制協議是可變大小的滑動視窗協議，

4、TCP的滑動視窗

在進行資料傳輸時，如果傳輸的資料比較大，就需要拆分為多個資料包進行發送，TCP 協議需要對資料進行確認后，才可以發送下一個資料包，這樣一來，就會在等待確認應答包環節浪費時間，

為了避免這種情況，TCP引入了視窗概念，視窗大小指的是不需要等待確認應答包而可以繼續發送資料包的最大值，

滑動視窗（Sliding window）是一種流量控制技術，早期的網路通信中，通信雙方不會考慮網路的擁擠情況直接發送資料，由于大家不知道網路擁塞狀況，同時發送資料，導致中間節點阻塞掉包，誰也發不了資料，所以就有了滑動視窗機制來解決此問題

滑動視窗協議是用來改善吞吐量的一種技術，即容許發送方在接收任何應答之前傳送附加的包，接收方告訴發送方在某一時刻能送多少包（稱視窗尺寸），

TCP中采用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩沖區可以用于接收資料，發送方可以通過滑動視窗的大小來確定應該發送多少位元組的資料，當滑動視窗為0時，發送方一般不能再發送資料報，但有兩種情況除外，一種情況是可以發送緊急資料，例如，允許用戶終止在遠端機上的運行行程，另一種情況是發送方可以發送一個1位元組的資料報來通知接收方重新宣告它希望接收的下一位元組及發送方的滑動視窗大小，

5、TCP擁塞機制

擁塞控制就是防止過多的資料注入網路，造成網路堵塞，擁塞控制和流量控制不同，擁塞控制是一個全域性程序，而流量控制是點對點通信的控制，擁塞控制的方法主要有四個演算法：

①慢啟動：不要一開始就發送大量資料，先探測一下網路的擁塞程度，也就是說從小到大逐漸增加擁塞視窗的大小

②擁塞避免（AMDI：加法增大乘法減小）：讓擁塞視窗緩慢增大，每經過一個往返時間就將擁塞視窗+1,緩慢增大擁塞視窗

③快重傳：發送方只要一收到三個重復的確認就應該立即重傳對方并未收到的報文段，而不必繼續等待重傳計時器到達重傳時間，快重傳并不是取消重傳計時器，而是在某些情況下更早的重傳丟失的報文

④快恢復：為了減少因為擁塞導致的資料包丟失帶來的重傳時間，快重傳的機制是：

• 接收方如果一個包丟失，則對后續的包繼續發送針對該包的重傳請求；
• 一旦發送方接收到三個一樣的確認，就知道該包之后出現了錯誤，立刻重傳該包；
• 此時發送方開始執行“快恢復”演算法；
• 慢開始門限減半；
• cwnd設為慢開始門限減半后的數量；
• 執行擁塞避免演算法（高起點，線性增長）；

6、SYN攻擊

SYN洪泛攻擊屬于 DOS 攻擊的一種，它利用 TCP 協議缺陷，通過發送大量的半連接請求，耗費 CPU 和記憶體資源，

原理：

• 在三次握手程序中，服務器發送 [SYN/ACK] 包（第二個包）之后、收到客戶端的 [ACK] 包（第三個包）之前的 TCP 連接稱為半連接（half-open connect），此時服務器處于 SYN_RECV（等待客戶端回應）狀態，如果接收到客戶端的 [ACK]，則 TCP 連接成功，如果未接受到，則會不斷重發請求直至成功，
• SYN 攻擊的攻擊者在短時間內偽造大量不存在的 IP 地址，向服務器不斷地發送 [SYN] 包，服務器回復 [SYN/ACK] 包，并等待客戶的確認，由于源地址是不存在的，服務器需要不斷的重發直至超時，
• 這些偽造的 [SYN] 包將長時間占用未連接佇列，影響了正常的 SYN，導致目標系統運行緩慢、網路堵塞甚至系統癱瘓，

檢測：當在服務器上看到大量的半連接狀態時，特別是源 IP 地址是隨機的，基本上可以斷定這是一次 SYN 攻擊，

防范：

• 通過防火墻、路由器等過濾網關防護，

• 通過加固 TCP/IP 協議堆疊防范，如增加最大半連接數，縮短超時時間，

• SYN cookies技術，SYN Cookies 是對 TCP 服務器端的三次握手做一些修改，專門用來防范 SYN 洪泛攻擊的一種手段，

7、建立鏈接后出現故障

TCP設有一個保活計時器，客戶端如果出現故障，服務器不能一直等下去，白白浪費資源，服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，服務器就會發送一個探測報文段，以后每隔75秒鐘發送一次，若一連發送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接，

四、網路層

網路層的任務就是選擇合適的網間路由和交換結點，確保計算機通信的資料及時傳送，在發送資料時，網路層把運輸層產生的報文段或用戶資料報封裝成分組和包進行傳送，在 TCP/IP 體系結構中，由于網路層使用 IP 協議，因此分組也叫 IP 資料報 ，簡稱資料報，

互聯網是由大量的異構（heterogeneous）網路通過路由器（router）相互連接起來的，互聯網使用的網路層協議是無連接的網際協議（Intert Prococol） 和許多路由選擇協議，因此互聯網的網路層也叫做網際層或 IP 層，

1、IP相關

IP地址分類方式一：

IPv4：是一個32位的二進制數，通常被分為4個位元組，表示成 a.b.c.d 的形式.

其中a、b、c、d都是0~255之間的十進制整數，那么最多可以表示42億個，

IPv6：由于互聯網的蓬勃發展，IP地址的需求量愈來愈大，但是網路地址資源有限，使得IP的分配越發緊張，

為了擴大地址空間，擬通過IPv6重新定義地址空間，采用128位地址長度，每16個位元組一組，分成 8組十六進制數，表示成ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 ，號稱可以為全世界的每一粒沙子編上一個網址，這樣就解決了網路地址資源數量不夠的問題，

IP地址分類方式二：

公網地址( 萬維網使用)和 私有地址( 局域網使用)，192.168.開頭的就是私有址址，范圍即為

192.168.0.0--192.168.255.255，專門為組織機構內部使用

2、APR協議

網路層的ARP協議完成了IP地址與物理地址的映射，首先，每臺主機都會在自己的ARP緩沖區中建立一個ARP串列，以表示IP地址和MAC地址的對應關系，

當源主機需要將一個資料包要發送到目的主機時，會首先檢查自己ARP串列中是否存在該IP地址對應的MAC地址：如果有，就直接將資料包發送到這個MAC地址；如果沒有，就向本地網段發起一個ARP請求的廣播包，查詢此目的主機對應的MAC地址，

此ARP請求資料包里包括源主機的IP地址、硬體地址、以及目的主機的IP地址，網路中所有的主機收到這個ARP請求后，會檢查資料包中的目的IP是否和自己的IP地址一致，

如果不相同就忽略此資料包；如果相同，該主機首先將發送端的MAC地址和IP地址添加到自己的ARP串列中，如果ARP表中已經存在該IP的資訊，則將其覆寫，然后給源主機發送一個ARP回應資料包，告訴對方自己是它需要查找的MAC地址；源主機收到這個ARP回應資料包后，將得到的目的主機的IP地址和MAC地址添加到自己的ARP串列中，并利用此資訊開始資料的傳輸，如果源主機一直沒有收到ARP回應資料包，表示ARP查詢失敗，

五、總結

1、瀏覽器輸入URL的程序

①瀏覽器查詢DNS，獲得域名對應的IP地址（DNS尋址程序）

*先從瀏覽器快取找ip，因為瀏覽器會快取DNS記錄一段時間

*如果沒有找到，再從Host檔案查找是否有該域名對應的IP

*如果沒有找到，再從路由器快取找

*如果沒有找到，再從DNS快取找

*如果都沒有找到，就從瀏覽器域名服務器向根域名服務器查找，沒有找到就繼續迭代，直到找到為止

②瀏覽器獲得IP地址后，瀏覽器向服務器請求連接，發起三次握手

③連接建立起來后，瀏覽器向服務器發送http請求

④服務器接收到這個請求，并根據路徑引數映射到特定的請求處理器進行處理，并將視圖以及相應的結果回傳給瀏覽器

⑤瀏覽器決議并渲染視圖，若遇到對js，css檔案以及靜態圖片資源的參考，重復上述步驟向服務器請求資源

⑥瀏覽器根據請求到的資源，資料渲染頁面，最終向用戶呈現

個人總結二十三種設計模式全套總結：

一、設計模式概述

二、設計模式之工廠方法和抽象工廠

三、設計模式之單例和原型

四、設計模式之建造者模式

五、設計模式之代理模式

六、設計模式之配接器模式

七、設計模式之橋接模式

八、設計模式之組合模式

九、設計模式之裝飾器模式

十、設計模式之外觀模式

十一、設計模式之享元模式

行為型設計模式

十二、設計模式之責任鏈模式

十三、設計模式之命令模式

十四、設計模式之解釋器模式

十五、設計模式之迭代器模式

十六、設計模式之中介者模式

十七、設計模式之備忘錄模式

十八、設計模式之觀察者模式

十九、設計模式之狀態模式

二十、設計模式之策略模式

二十一、設計模式之模板方法模式

二十二、設計模式之訪問者模式

標籤：Java

上一篇：java 基礎——函式（方法）

下一篇：把Mybatis Generator生成的代碼加上想要的注釋