【面試基礎】計算機網絡常見面試題整理

 

綜述：

 按照5層協議來看，建議各位重點關注上三層的理論基礎，從搜集到的面試題來看，數據鏈路層和物理層很少有涉及。所以掌握應用層、傳輸層、網絡層，應對面試就已經足夠。

面試題：

1.請簡述TCP\UDP的區別？

	TCP	UDP
是否連接	面向連接	面向非連接
傳輸可靠性	可靠的	不可靠的
應用場合	傳輸大量的數據	少量數據
速度	慢	快

1.TCP面向連接，UDP無連接。
2.TCP面向字節流（文件傳輸），UDP是面向報文的，UDP沒有擁塞控制，因此網絡出現擁塞不會使源主機的發送速率降低（對IP電話，實時視頻會議等）。
3.TCP首部開銷20字節，UDP的首部開銷小，只有8個字節。
4.TCP提供可靠的服務。也就是說，通過TCP連接傳送的數據，無差錯，不丟失，不重復，且按序到達;UDP盡最大努力交付，即不保證可靠交付。
5.每一條TCP連接只能是點到點的；UDP支持一對一，一對多，多對一和多對多的交互通信。
6.TCP的邏輯通信信道是全雙工的可靠信道，UDP則是不可靠信道。

2.請簡單說一下你了解的端口及對應的服務？

 

3.TCP/IP網絡協議以及各層協議？

OSI分層 （7層）：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
TCP/IP分層（4層）：網絡接口層、 網際層、運輸層、 應用層。
五層協議 （5層）：物理層、數據鏈路層、網絡層、運輸層、 應用層。
每一層的協議如下：
物理層：RJ45、CLOCK、IEEE802.3 （中繼器，集線器，網關）
數據鏈路：PPP、FR、HDLC、VLAN、MAC （網橋，交換機）
網絡層：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、 （路由器）
傳輸層：TCP、UDP、SPX
會話層：NFS、SQL、NETBIOS、RPC
表示層：JPEG、MPEG、ASII
應用層：FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS

4.TCP/UDP分別對應的應用有哪些？

 

5.說一說TCP的三次握手？為什么三次？（2次或者4次怎么樣）

 抽象描述就是：

 

 

• 客戶端–發送帶有 SYN 標志的數據包–一次握手–服務端
• 服務端–發送帶有 SYN/ACK 標志的數據包–二次握手–客戶端
• 客戶端–發送帶有帶有 ACK 標志的數據包–三次握手–服務端

  

三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數據的發送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發送與接收是正常的。

第一次握手：Client 什么都不能確認；Server 確認了對方發送正常，自己接收正常

第二次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：對方發送正常，自己接收正常

第三次握手：Client 確認了：自己發送、接收正常，對方發送、接收正常；Server 確認了：自己發送、接收正常，對方發送、接收正常

所以三次握手就能確認雙發收發功能都正常，缺一不可。

  

6.簡析TCP的四次分手？三次揮手可以嗎？

抽象描述：

 

TCP連接是全雙工的，因此每個方向都必須單獨進行關閉。
1.客戶端A發送一個FIN，用來關閉客戶A到服務器B的數據傳送，並發送一個自己的ISN（u）
2.服務器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1（u+1）。同時發送一個自己的ISN(v)
3.服務器B關閉與客戶端A的連接，發送一個FIN、ACK給客戶端A，確認號為收到的序號加1（u+1），與上一次不變。同時發送一個自己的ISN（w）
4.客戶端A發送ACK報文確認，並將確認序號設置為收到序號加1（w+1），序列號就是上一次的確認號（u+1）

任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后進入半關閉狀態。當另一方也沒有數據再發送的時候，則發出連接釋放通知，對方確認后就完全關閉了TCP連接。

舉個例子：A 和 B 打電話，通話即將結束后，A 說“我沒啥要說的了”，B回答“我知道了”，但是 B 可能還會有要說的話，A 不能要求 B 跟着自己的節奏結束通話，於是 B 可能又巴拉巴拉說了一通，最后 B 說“我說完了”，A 回答“知道了”，這樣通話才算結束。

為什么要等待一個Time_Wait階段（2MSL）？

客戶端接收到服務器端的 FIN 報文后進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設置的時間 2MSL。這么做有兩個理由：

• 確保最后一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文，那么就會重新發送連接釋放請求報文，A 等待一段時間就是為了處理這種情況的發生。

• 等待一段時間是為了讓本連接持續時間內所產生的所有報文都從網絡中消失，使得下一個新的連接不會出現舊的連接請求報文。

7.簡述ARP地址解析協議工作原理？

每台主機都有一個ARP列表，存放IP地址和MAC地址的對應關系。
當源主機向目標主機發送數據時，首先查看ARP列表中IP地址對應的目標主機的MAC地址，如果找到則直接發送數據；如果找不到，就向該網段中的所有主機發送ARP請求包，里面存放源IP地址，源MAC地址，目標IP地址。
當該網段中的所有主機收到該ARP響應包之后，首先查看目標ip地址是否與自己相匹配，如果不是則忽略，如果是，就將源ip地址和源MAC地址存放到自己的ARP列表中，然后將自己的MAC地址存放到ARP響應包中發送給源主機；
目標主機收到ARP響應包，則取出對應的IP和MAC地址存放到ARP列表中，並發送數據。若未收到則ARP查詢失敗。
廣播ARP請求，單播ARP響應。

 

8.簡述ICMP、TFTP、HTTP、NAT、DHCP協議？

ICMP : 因特網控制報文協議。它是TCP/IP協議族的一個子協議，用於在IP主機、路由器之間傳遞控制消息。主要用於ping功能

TFTP：是TCP/IP協議族中的一個用來在客戶機和服務器之間進行簡單的文件傳輸的協議，提供不復雜、開銷不大的文件傳輸服務

HTTP：超文本傳輸層協議，是一個屬於應用層的面向對象的協議

NAT協議：網絡地址轉換接入廣域網（WAN）技術，是一種將私有地址轉換為合法IP地址的轉換技術

DHCP協議：動態主機配置協議，使用UDP協議工作。給內部的網絡和網絡服務供應商自動的分配IP地址。

RARP是逆地址解析協議，作用是完成從硬件地址到IP地址的映射，RARP只能用於具有廣播能力的網絡。封裝一個RARP的數據包里面有MAC地址， 然后廣播到網絡上，當服務器收到請求包后，就查找對應的MAC地址的IP地址裝入到響應報文中發送給請求者。

9.TCP 協議如何保證可靠傳輸？

1. 應用數據被分割成 TCP 認為最適合發送的數據塊。
2. TCP 給發送的每一個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。
3. 校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
4. TCP 的接收端會丟棄重復的數據。
5. 流量控制： TCP 連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發送端發送接收端緩沖區能接納的數據。當接收方來不及處理發送方的數據，能提示發送方降低發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
6. 擁塞控制： 當網絡擁塞時，減少數據的發送。
7. ARQ協議： 也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認后再發下一個分組。
8. 超時重傳： 當 TCP 發出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段。

10.ARQ協議？

　　自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。

　　它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。

　　如果發送方在發送后一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

停止等待ARQ協議

• 停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認（回復ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發送成功，需要重新發送，直到收到確認后再發下一個分組；
• 在停止等待協議中，若接收方收到重復分組，就丟棄該分組，但同時還要發送確認；

優點： 簡單

缺點： 信道利用率低，等待時間長

1) 無差錯情況:

發送方發送分組,接收方在規定時間內收到,並且回復確認.發送方再次發送。

2) 出現差錯情況（超時重傳）:

停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送過的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協議中若收到重復分組，就丟棄該分組，但同時還要發送確認。連續 ARQ 協議 可提高信道利用率。發送維持一個發送窗口，凡位於發送窗口內的分組可連續發送出去，而不需要等待對方確認。接收方一般采用累積確認，對按序到達的最后一個分組發送確認，表明到這個分組位置的所有分組都已經正確收到了。

3) 確認丟失和確認遲到

• 確認丟失 ：確認消息在傳輸過程丟失。當A發送M1消息，B收到后，B向A發送了一個M1確認消息，但卻在傳輸過程中丟失。而A並不知道，在超時計時過后，A重傳M1消息，B再次收到該消息后采取以下兩點措施：1. 丟棄這個重復的M1消息，不向上層交付。 2. 向A發送確認消息。（不會認為已經發送過了，就不再發送。A能重傳，就證明B的確認消息丟失）。
• 確認遲到 ：確認消息在傳輸過程中遲到。A發送M1消息，B收到並發送確認。在超時時間內沒有收到確認消息，A重傳M1消息，B仍然收到並繼續發送確認消息（B收到了2份M1）。此時A收到了B第二次發送的確認消息。接着發送其他數據。過了一會，A收到了B第一次發送的對M1的確認消息（A也收到了2份確認消息）。處理如下：1. A收到重復的確認后，直接丟棄。2. B收到重復的M1后，也直接丟棄重復的M1。

連續ARQ協議

連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位於發送窗口內的分組可以連續發送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已經正確收到了。

優點： 信道利用率高，容易實現，即使確認丟失，也不必重傳。

缺點： 不能向發送方反映出接收方已經正確收到的所有分組的信息。 比如：發送方發送了 5條 消息，中間第三條丟失（3號），這時接收方只能對前兩個發送確認。發送方無法知道后三個分組的下落，而只好把后三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經發送過的 N 個消息。

11.簡述下TCP的擁塞控制、滑動窗口、流量控制？

滑動窗口

　　TCP 利用滑動窗口實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。

 　   接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。

　　將窗口字段設置為 0，則發送方不能發送數據。

擁塞控制

　　在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的數據注入到網絡中，這樣就可以使網絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網絡能夠承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發送端發送數據的速率，以便使接收端來得及接收。

　　為了進行擁塞控制，TCP 發送方要維持一個 擁塞窗口(cwnd) 的狀態變量。擁塞控制窗口的大小取決於網絡的擁塞程度，並且動態變化。發送方讓自己的發送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。

　　TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網絡層也可以使路由器采用適當的分組丟棄策略（如主動隊列管理 AQM），以減少網絡擁塞的發生。

• 慢開始： 慢開始算法的思路是當主機開始發送數據時，如果立即把大量數據字節注入到網絡，那么可能會引起網絡阻塞，因為現在還不知道網絡的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd初始值為1，每經過一個傳播輪次，cwnd加倍。
• 擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送放的cwnd加1.
• 快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢復丟失的數據包。沒有 FRR，如果數據包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或復制的數據包被發送。有了 FRR，如果接收機接收到一個不按順序的數據段，它會立即給發送機發送一個重復確認。如果發送機接收到三個重復確認，它會假定確認件指出的數據段丟失了，並立即重傳這些丟失的數據段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 　當有單獨的數據包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數據信息包在某一段很短的時間內丟失時，它則不能很有效地工作。

流量控制

流量控制是為了控制發送方發送速率，保證接收方來得及接收。

接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置為 0，則發送方不能發送數據。

實際上，為了避免此問題的產生，發送端主機會時不時的發送一個叫做窗口探測的數據段，此數據段僅包含一個字節來獲取最新的窗口大小信息。

 

12.在瀏覽器中輸入網址之后執行會發生什么？

總體來說分為以下幾個過程:

1. DNS解析
2. TCP連接
3. 發送HTTP請求
4. 服務器處理請求並返回HTTP報文
5. 瀏覽器解析渲染頁面
6. 連接結束

13.HTTP的狀態碼知道哪一些？

200 ：請求成功，成功返回網頁
301 ：資源（網頁等）被永久轉移到其它URL
302 ：資源（網頁等）被臨時轉移到其它URL
304 ：請求未修改、命中緩存
401 ：未授權
403 ：服務器拒絕請求
404 ：請求的網頁或資源不存在
500 ：內部服務器錯誤，無法完成請求
502 ：錯誤網關
503 ：請求未完成，服務器臨時過載或宕機
504 ：網關超時

14.HTTP長連接,短連接？

在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。

而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭加入這行代碼：

Connection:keep-alive

在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用於傳輸HTTP數據的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接需要客戶端和服務端都支持長連接。

HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。

短連接：Client 向 Server 發送消息，Server 回應 Client，然后一次讀寫就完成了，這時候雙方任何一個都可以發起 close 操作，不過一般都是 Client 先發起 close 操作。短連接一般只會在 Client/Server 間傳遞一次讀寫操作。

短連接的優點：管理起來比較簡單，建立存在的連接都是有用的連接，不需要額外的控制手段。

長連接：Client 與 Server 完成一次讀寫之后，它們之間的連接並不會主動關閉，后續的讀寫操作會繼續使用這個連接。

在長連接的應用場景下，Client 端一般不會主動關閉它們之間的連接，Client 與 Server 之間的連接如果一直不關閉的話，隨着客戶端連接越來越多，Server 壓力也越來越大，這時候 Server 端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致 Server 端服務受損；如果條件再允許可以以客戶端為顆粒度，限制每個客戶端的最大長連接數，從而避免某個客戶端連累后端的服務。

長連接和短連接的產生在於 Client 和 Server 采取的關閉策略，具體的應用場景采用具體的策略。

 

15.HTTP是不保存狀態的協議,如何保存用戶狀態?

HTTP 是一種不保存狀態，即無狀態（stateless）協議。也就是說 HTTP 協議自身不對請求和響應之間的通信狀態進行保存。那么我們保存用戶狀態呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是通過服務端記錄用戶的狀態。典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之后就可以標識這個用戶並且跟蹤這個用戶了（一般情況下，服務器會在一定時間內保存這個 Session，過了時間限制，就會銷毀這個Session）。

在服務端保存 Session 的方法很多，最常用的就是內存和數據庫(比如是使用內存數據庫redis保存)。既然 Session 存放在服務器端，那么我們如何實現 Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。

Cookie 被禁用怎么辦?

最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。

 

16.Cookie的作用是什么?和Session有什么區別？

Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式，但是兩者的應用場景不太一樣。

Cookie 一般用來保存用戶信息 比如①我們在 Cookie 中保存已經登錄過得用戶信息，下次訪問網站的時候頁面可以自動幫你登錄的一些基本信息給填了；②一般的網站都會有保持登錄也就是說下次你再訪問網站的時候就不需要重新登錄了，這是因為用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據 Token 值來查找用戶即可(為了安全考慮，重新登錄一般要將 Token 重寫)；③登錄一次網站后訪問網站其他頁面不需要重新登錄。Session 的主要作用就是通過服務端記錄用戶的狀態。 典型的場景是購物車，當你要添加商品到購物車的時候，系統不知道是哪個用戶操作的，因為 HTTP 協議是無狀態的。服務端給特定的用戶創建特定的 Session 之后就可以標識這個用戶並且跟蹤這個用戶了。

Cookie 數據保存在客戶端(瀏覽器端)，Session 數據保存在服務器端。

Cookie 存儲在客戶端中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。

17.HTTP 1.0和HTTP 1.1的主要區別是什么?

HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用於現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在：

1. 長連接 : 在HTTP/1.0中，默認使用的是短連接，也就是說每次請求都要重新建立一次連接。HTTP 是基於TCP/IP協議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個長連接，可以用個長連接來發多個請求。HTTP 1.1起，默認使用長連接 ,默認開啟Connection： keep-alive。 HTTP/1.1的持續連接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應報文之前就能接着發送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應后才能發送下一個請求。
2. 錯誤狀態響應碼 :在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。
3. 緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標准，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
4. 帶寬優化及網絡連接的使用 :HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，並且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和連接。

18.HTTP 和 HTTPS 的區別？

1. 端口 ：HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。
2. 安全性和資源消耗： HTTP協議運行在TCP之上，所有傳輸的內容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS 運行在TCP之上。所有傳輸的內容都經過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。
   • 對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
   • 非對稱加密：密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等

19.簡述HTTP中GET和POST的區別？

從原理性看：

• 根據HTTP規范，GET用於信息獲取，而且應該是安全和冪等的
• 根據HTTP規范，POST請求表示可能修改服務器上資源的請求

從表面上看：

• GET請求的數據會附在URL后面，POST的數據放在HTTP包體
• POST安全性比GET安全性高

20.HTTP 協議包括哪些請求？

• GET：對服務器資源的簡單請求
• POST：用於發送包含用戶提交數據的請求

------------以及------------

• HEAD：類似於GET請求，不過返回的響應中沒有具體內容，用於獲取報頭
• PUT：傳說中請求文檔的一個版本
• DELETE：發出一個刪除指定文檔的請求
• TRACE：發送一個請求副本，以跟蹤其處理進程
• OPTIONS：返回所有可用的方法，檢查服務器支持哪些方法
• CONNECT：用於ssl隧道的基於代理的請求

21.UDP\TCP的首部格式？

 

 

 

 

 

TCP 首部格式比 UDP 復雜。

序號：用於對字節流進行編號，例如序號為 301，表示第一個字節的編號為 301，如果攜帶的數據長度為 100 字節，那么下一個報文段的序號應為 401。

確認號：期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號為 501，攜帶的數據長度為 200 字節，因此 B 期望下一個報文段的序號為 701，B 發送給 A 的確認報文段中確認號就為 701。

數據偏移：指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。

控制位：八位從左到右分別是 CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。

CWR：CWR 標志與后面的 ECE 標志都用於 IP 首部的 ECN 字段，ECE 標志為 1 時，則通知對方已將擁塞窗口縮小；

ECE：若其值為 1 則會通知對方，從對方到這邊的網絡有阻塞。在收到數據包的 IP 首部中 ECN 為 1 時將 TCP 首部中的 ECE 設為 1；

URG：該位設為 1，表示包中有需要緊急處理的數據，對於需要緊急處理的數據，與后面的緊急指針有關；

ACK：該位設為 1，確認應答的字段有效，TCP規定除了最初建立連接時的 SYN 包之外該位必須設為 1；

PSH：該位設為 1，表示需要將收到的數據立刻傳給上層應用協議，若設為 0，則先將數據進行緩存；

RST：該位設為 1，表示 TCP 連接出現異常必須強制斷開連接；

SYN：用於建立連接，該位設為 1，表示希望建立連接，並在其序列號的字段進行序列號初值設定；

FIN：該位設為 1，表示今后不再有數據發送，希望斷開連接。當通信結束希望斷開連接時，通信雙方的主機之間就可以相互交換 FIN 位置為 1 的 TCP 段。

每個主機又對對方的 FIN 包進行確認應答之后可以斷開連接。不過，主機收到 FIN 設置為 1 的 TCP 段之后不必馬上回復一個 FIN 包，而是可以等到緩沖區中的所有數據都因為已成功發送而被自動刪除之后再發 FIN 包；

窗口：窗口值作為接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因為接收方的數據緩存空間是有限的。

 22.TCP粘包、拆包及解決辦法

為什么常說 TCP 有粘包和拆包的問題而不說 UDP ？

由前兩節可知，UDP 是基於報文發送的，UDP首部采用了 16bit 來指示 UDP 數據報文的長度，因此在應用層能很好的將不同的數據報文區分開，從而避免粘包和拆包的問題。

 

而 TCP 是基於字節流的，雖然應用層和 TCP 傳輸層之間的數據交互是大小不等的數據塊，但是 TCP 並沒有把這些數據塊區分邊界，僅僅是一連串沒有結構的字節流；另外從 TCP 的幀結構也可以看出，在 TCP 的首部沒有表示數據長度的字段，基於上面兩點，在使用 TCP 傳輸數據時，才有粘包或者拆包現象發生的可能。

 

什么是粘包、拆包？

假設 Client 向 Server 連續發送了兩個數據包，用 packet1 和 packet2 來表示，那么服務端收到的數據可以分為三種情況，現列舉如下：

 

第一種情況，接收端正常收到兩個數據包，即沒有發生拆包和粘包的現象。

 

 

第二種情況，接收端只收到一個數據包，但是這一個數據包中包含了發送端發送的兩個數據包的信息，這種現象即為粘包。這種情況由於接收端不知道這兩個數據包的界限，所以對於接收端來說很難處理。

 

 

第三種情況，這種情況有兩種表現形式，如下圖。接收端收到了兩個數據包，但是這兩個數據包要么是不完整的，要么就是多出來一塊，這種情況即發生了拆包和粘包。這兩種情況如果不加特殊處理，對於接收端同樣是不好處理的。

 

 

 

 

23.為什么會發生 TCP 粘包、拆包？

• 要發送的數據大於 TCP 發送緩沖區剩余空間大小，將會發生拆包。

• 待發送數據大於 MSS（最大報文長度），TCP 在傳輸前將進行拆包。

• 要發送的數據小於 TCP 發送緩沖區的大小，TCP 將多次寫入緩沖區的數據一次發送出去，將會發生粘包。

• 接收數據端的應用層沒有及時讀取接收緩沖區中的數據，將發生粘包。

粘包、拆包解決辦法

由於 TCP 本身是面向字節流的，無法理解上層的業務數據，所以在底層是無法保證數據包不被拆分和重組的，這個問題只能通過上層的應用協議棧設計來解決，根據業界的主流協議的解決方案，歸納如下：

• 消息定長：發送端將每個數據包封裝為固定長度（不夠的可以通過補 0 填充），這樣接收端每次接收緩沖區中讀取固定長度的數據就自然而然的把每個數據包拆分開來。

• 設置消息邊界：服務端從網絡流中按消息邊界分離出消息內容。在包尾增加回車換行符進行分割，例如 FTP 協議。

• 將消息分為消息頭和消息體：消息頭中包含表示消息總長度（或者消息體長度）的字段。

• 更復雜的應用層協議比如 Netty 中實現的一些協議都對粘包、拆包做了很好的處理。

24.提高網絡利用率

1、Nagle 算法

發送端即使還有應該發送的數據，但如果這部分數據很少的話，則進行延遲發送的一種處理機制。具體來說，就是僅在下列任意一種條件下才能發送數據。如果兩個條件都不滿足，那么暫時等待一段時間以后再進行數據發送。

• 已發送的數據都已經收到確認應答。

• 可以發送最大段長度的數據時。

2、延遲確認應答

接收方收到數據之后可以並不立即返回確認應答，而是延遲一段時間的機制。

• 在沒有收到 2*最大段長度的數據為止不做確認應答。

• 其他情況下，最大延遲 0.5秒 發送確認應答。

• TCP 文件傳輸中，大多數是每兩個數據段返回一次確認應答。

3、捎帶應答

在一個 TCP 包中既發送數據又發送確認應答的一種機制，由此，網絡利用率會提高，計算機的負荷也會減輕，但是這種應答必須等到應用處理完數據並將作為回執的數據返回為止。

 

 

 

 

參照：計算機網絡常見面試題 - 不懶人 - 博客園 (cnblogs.com)