基于 Java面試 32個核心必考點完全解析（上）【附視頻地址】中的 操作系統與計算機網絡 相關面試題做記錄。

進程與線程的區別與聯系（資源的占用，切換效率，通信方式）

簡單介紹一下進程的切換過程

操作系統中的進程調度算法

經常使用的 Linux 命令，使用場景

OSI 七層模型

簡述 TCP \ UDP的區別

TCP 如何實現可靠性傳輸

TCP 的三次握手和四次揮手過程

為什么 TCP 關閉鏈接時需要 TIME_WAIT 狀態，為什么要等 2MSL？

一次完整的 HTTP 請求過程（DNS TCP HTTP）

簡述 HTTP 中 GET 和 POST 的區別

HTTP2 與 HTTP 之間的區別

一、進程與線程的區別與聯系（資源的占用，切換效率，通信方式）

進程

進程是資源分配的基本單位，用來管理資源（例如：內存，文件，網絡等資源）

進程控制塊 (Process Control Block, PCB) 描述進程的基本信息和運行狀態，所謂的創建進程和撤銷進程，都是指對 PCB 的操作。（PCB是描述進程的數據結構）

線程

線程是獨立調度的基本單位。

一個進程中可以有多個線程，它們共享進程資源。

QQ 和瀏覽器是兩個進程，瀏覽器進程里面有很多線程，例如 HTTP 請求線程、事件響應線程、渲染線程等等，線程的并發執行使得在瀏覽器中點擊一個新鏈接從而發起 HTTP 請求時，瀏覽器還可以響應用戶的其它事件。

區別

Ⅰ 擁有資源

進程是資源分配的基本單位，但是線程不擁有資源，線程可以訪問隸屬進程的資源。

Ⅱ 調度

線程是獨立調度的基本單位，在同一進程中，線程的切換不會引起進程切換，從一個進程中的線程切換到另一個進程中的線程時，會引起進程切換。

Ⅲ 系統開銷

由于創建或撤銷進程時，系統都要為之分配或回收資源，如內存空間、I/O 設備等，所付出的開銷遠大于創建或撤銷線程時的開銷。類似地，在進行進程切換時，涉及當前執行進程 CPU 環境的保存及新調度進程 CPU 環境的設置，而線程切換時只需保存和設置少量寄存器內容，開銷很小。

Ⅳ 通信方面

線程間可以通過直接讀寫同一進程中的數據進行通信，但是進程通信需要借助 IPC。

進程通信

進程同步與進程通信很容易混淆，它們的區別在于：

• 進程同步：控制多個進程按一定順序執行；
• 進程通信：進程間傳輸信息。

進程通信是一種手段，而進程同步是一種目的。也可以說，為了能夠達到進程同步的目的，需要讓進程進行通信，傳輸一些進程同步所需要的信息。

1. 管道

管道是通過調用 pipe 函數創建的，fd[0] 用于讀，fd[1] 用于寫。

#include <unistd.h> int pipe(int fd[2]);

它具有以下限制：

• 只支持半雙工通信（單向交替傳輸）；
• 只能在父子進程或者兄弟進程中使用。

2. FIFO

也稱為命名管道，去除了管道只能在父子進程中使用的限制。

#include <sys/stat.h> int mkfifo(const char *path, mode_t mode); int mkfifoat(int fd, const char *path, mode_t mode);

FIFO 常用于客戶-服務器應用程序中，FIFO 用作匯聚點，在客戶進程和服務器進程之間傳遞數據。

3. 消息隊列

相比于 FIFO，消息隊列具有以下優點：

• 消息隊列可以獨立于讀寫進程存在，從而避免了 FIFO 中同步管道的打開和關閉時可能產生的困難；
• 避免了 FIFO 的同步阻塞問題，不需要進程自己提供同步方法；
• 讀進程可以根據消息類型有選擇地接收消息，而不像 FIFO 那樣只能默認地接收。

4. 信號量

它是一個計數器，用于為多個進程提供對共享數據對象的訪問。

5. 共享存儲

允許多個進程共享一個給定的存儲區。因為數據不需要在進程之間復制，所以這是最快的一種 IPC。

需要使用信號量用來同步對共享存儲的訪問。

多個進程可以將同一個文件映射到它們的地址空間從而實現共享內存。另外 XSI 共享內存不是使用文件，而是使用內存的匿名段。

6. 套接字

與其它通信機制不同的是，它可用于不同機器間的進程通信。

二、簡單介紹一下進程的切換過程

• 就緒狀態（ready）：等待被調度
• 運行狀態（running）：運行中
• 阻塞狀態（waiting）：等待資源

應該注意以下內容：

• 只有就緒態和運行態可以相互轉換，其它的都是單向轉換。就緒狀態的進程通過調度算法從而獲得 CPU 時間，轉為運行狀態；而運行狀態的進程，在分配給它的 CPU 時間片用完之后就會轉為就緒狀態，等待下一次調度。
• 阻塞狀態是缺少需要的資源從而由運行狀態轉換而來，但是該資源不包括 CPU 時間，缺少 CPU 時間會從運行態轉換為就緒態。
• 進程只能自己阻塞自己，因為只有進程自身才知道何時需要等待某種事件的發生

三、操作系統中的進程調度算法

不同環境的調度算法目標不同，因此需要針對不同環境來討論調度算法。

1. 批處理系統

批處理系統沒有太多的用戶操作，在該系統中，調度算法目標是保證吞吐量和周轉時間（從提交到終止的時間）。

1.1 先來先服務

先來先服務 first-come first-serverd（FCFS）

按照請求的順序進行調度。

有利于長作業，但不利于短作業，因為短作業必須一直等待前面的長作業執行完畢才能執行，而長作業又需要執行很長時間，造成了短作業等待時間過長。

1.2 短作業優先

短作業優先 shortest job first（SJF）

按估計運行時間最短的順序進行調度。

長作業有可能會餓死，處于一直等待短作業執行完畢的狀態。因為如果一直有短作業到來，那么長作業永遠得不到調度。

1.3 最短剩余時間優先

最短剩余時間優先 shortest remaining time next（SRTN）

按估計剩余時間最短的順序進行調度。

2. 交互式系統

交互式系統有大量的用戶交互操作，在該系統中調度算法的目標是快速地進行響應。

2.1 時間片輪轉

將所有就緒進程按 FCFS （先來先服務） 的原則排成一個隊列，每次調度時，把 CPU 時間分配給隊首進程，該進程可以執行一個時間片。當時間片用完時，由計時器發出時鐘中斷，調度程序便停止該進程的執行，并將它送往就緒隊列的末尾，同時繼續把 CPU 時間分配給隊首的進程。

時間片輪轉算法的效率和時間片的大小有很大關系。因為進程切換都要保存進程的信息并且載入新進程的信息，如果時間片太小，會導致進程切換得太頻繁，在進程切換上就會花過多時間。

2.2 優先級調度

為每個進程分配一個優先級，按優先級進行調度。

為了防止低優先級的進程永遠等不到調度，可以隨著時間的推移增加等待進程的優先級。

2.3 多級反饋隊列

如果一個進程需要執行 100 個時間片，如果采用時間片輪轉調度算法，那么需要交換 100 次。

多級隊列是為這種需要連續執行多個時間片的進程考慮，它設置了多個隊列，每個隊列時間片大小都不同，例如 1,2,4,8,…。進程在第一個隊列沒執行完，就會被移到下一個隊列。這種方式下，之前的進程只需要交換 7 次。

每個隊列優先權也不同，最上面的優先權最高。因此只有上一個隊列沒有進程在排隊，才能調度當前隊列上的進程。

可以將這種調度算法看成是時間片輪轉調度算法和優先級調度算法的結合。

3. 實時系統

實時系統要求一個請求在一個確定時間內得到響應。

分為硬實時和軟實時，前者必須滿足絕對的截止時間，后者可以容忍一定的超時。

四、經常使用的 Linux 命令，使用場景

awk

逐行掃描文件（從第 1 行到最后一行），尋找含有目標文本的行，如果匹配成功，則會在該行上執行用戶想要的操作；反之，則不對行做任何處理。

awk 的主要特性之一是其處理文本文件中數據的能力，它會自動給一行中的每個數據元素分配一個變量

awk 命令的基本格式為：

[root@localhost ~]# awk [選項] '腳本命令' 文件名

top

實時顯示進程信息。

示例：兩秒鐘刷新一次

# top -d 2

netstat

查看占用端口的進程

示例：查看特定端口的進程

# netstat -anp | grep port

less

查看文件內容

less 命令的作用和 more 十分類似，都用來瀏覽文本文件中的內容，不同之處在于，使用 more 命令瀏覽文件內容時，只能不斷向后翻看，而使用 less 命令瀏覽，既可以向后翻看，也可以向前翻看。

[root@localhost ~]# less [選項] 文件名

grep

查找文件內容

能夠在一個或多個文件中，搜索某一特定的字符模式（也就是正則表達式），此模式可以是單一的字符、字符串、單詞或句子。

grep 命令的基本格式如下：

[root@localhost ~]# grep [選項] 模式 文件名

tail

顯示文件結尾的內容

經常用于實時查看項目日志信息

[root@localhost logs]# tail -f dev.log

五、OSI 七層模型

五層協議

• 應用層 ：提供用戶接口，特指能夠發起網絡流量的程序，比如客戶端程序：QQ，MSN，瀏覽器等；服務器程序：web服務器，郵件服務器，流媒體服務器等等。數據單位為報文。
• 傳輸層 ：提供的是進程間的通用數據傳輸服務。由于應用層協議很多，定義通用的運輸層協議就可以支持不斷增多的應用層協議。運輸層包括兩種協議：
  • 傳輸控制協議 TCP，提供面向連接、可靠的數據傳輸服務，數據單位為報文段；
  • 用戶數據報協議 UDP，提供無連接、盡最大努力的數據傳輸服務，數據單位為用戶數據報。
  • TCP 主要提供完整性服務，UDP 主要提供及時性服務。
• 網絡層 ：為主機間提供數據傳輸服務，而運輸層協議是為主機中的進程提供服務。網絡層把運輸層傳遞下來的報文段或者用戶數據報封裝成分組。（負責選擇最佳路徑 規劃IP地址）
  • 路由器查看數據包目標IP地址，根據路由表為數據包選擇路徑。路由表中的類目可以人工添加（靜態路由）也可以動態生成（動態路由）。
• 數據鏈路層 ：不同的網絡類型，發送數據的機制不同，數據鏈路層就是將數據包封裝成能夠在不同的網絡傳輸的幀。能夠進行差錯檢驗，但不糾錯，監測處錯誤丟掉該幀。
  • 幀的開始和結束，透明傳輸，差錯校驗
• 物理層 ：物理層解決如何在連接各種計算機的傳輸媒體上傳輸數據比特流，而不是指具體的傳輸媒體。物理層的主要任務描述為：確定與傳輸媒體的接口的一些特性，即：
  • 機械特性：例接口形狀，大小，引線數目
  • 電氣特性：例規定電壓范圍 ( -5V 到 +5V )
  • 功能特性：例規定 -5V 表示 0，＋5V 表示 1
  • 過程特性：也稱規程特性，規定建立連接時各個相關部件的工作步驟

ISO七層模型中表示層和會話層

• 表示層 ：數據壓縮、加密以及數據描述。這使得應用程序不必擔心在各臺主機中表示/存儲的內部格式（二進制、ASCII，比如亂碼）不同的問題。
• 會話層 ：建立會話，如session認證、斷點續傳。通信的應用程序之間建立、維護和釋放面向用戶的連接。通信的應用程序之間建立會話，需要傳輸層建立1個或多個連接。
• 說明：五層協議沒有表示層和會話層，而是將這些功能留給應用程序開發者處理。

六、簡述 TCP \ UDP的區別

在 TCP/IP 網絡體系結構中，TCP（傳輸控制協議，Transport Controll Protocol、UDP（用戶數據報協議，User Data Protocol）是傳輸層最重要的兩種協議，為上層用戶提供級別的通信可靠性。

傳輸控制協議（TCP）：TCP（傳輸控制協議）定義了兩臺計算機之間進行可靠的傳輸而交換的數據和確認信息的格式，以及計算機為了確保數據的正確到達而采取的措施。協議規定了TCP軟件怎樣識別給定計算機上的多個目的進程如何對分組重復這類差錯進行恢復。協議還規定了兩臺計算機如何初始化一個 TCP 數據流傳輸以及如何結束這一傳輸。TCP最大的特點就是提供的是面向連接、可靠的字節流服務。

用戶數據報協議（UDP）：UDP（用戶數據報協議）是一個簡單的面向數據報的傳輸層協議。提供的是非面向連接的、不可靠的數據流傳輸。UDP不提供可靠性，也不提供報文到達確認、排序以及流量控制等功能。它只是把應用程序傳給IP層的數據報發送出去，但是并不能保證它們能到達目的地。因此報文可能會丟失、重復以及亂序等。但由于UDP在傳輸數據報前不用在客戶和服務器之間建立一個連接，且沒有超時重發等機制，故而傳輸速度很快。

對比

UDPTCP

是否連接	無連接	面向連接
是否可靠	不可靠傳輸，不使用流量控制和擁塞控制	可靠傳輸，使用流量控制和擁塞控制
連接對象個數	支持一對一，一對多，多對一和多對多交互通信	只能是一對一通信
傳輸方式	面向報文	面向字節流
首部開銷	首部開銷小，僅8字節	首部最小20字節，最大60字節
適用場景	適用于實時應用（IP電話、視頻會議、直播等）	適用于要求可靠傳輸的應用，例如文件傳輸

七、TCP 如何實現可靠性傳輸

應用數據被分割成 TCP 認為最適合發送的數據塊。

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

校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。

TCP 的接收端會丟棄重復的數據。

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

擁塞控制： 當網絡擁塞時，減少數據的發送。

ARQ協議： 也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認。在收到確認后再發下一個分組。

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

7.1 ARQ協議

自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送后一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

停止等待ARQ協議

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

優點： 簡單

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

1) 無差錯情況:

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

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

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

3) 確認丟失和確認遲到

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

連續ARQ協議

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

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

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

7.2 滑動窗口和流量控制

TCP 利用滑動窗口實現流量控制。流量控制是為了控制發送方發送速率，保證接收方來得及接收。 接收方發送的確認報文中的窗口字段可以用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置為 0，則發送方不能發送數據。

7.3 擁塞控制

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

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

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

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

八、TCP 的三次握手和四次揮手過程

TCP 首部格式

• 序號 seq ：用于對字節流進行編號，例如序號為 301，表示第一個字節的編號為 301，如果攜帶的數據長度為 100 字節，那么下一個報文段的序號應為 401。[301,400]為序號301的數據長度，下一個則為401
• 確認號 ack ：期望收到的下一個報文段的序號。例如 Server 正確收到 Client 發送來的一個報文段，序號為 501，攜帶的數據長度為 200 字節，因此 Server 期望下一個報文段的序號為 701，Server 發送給 Client 的確認報文段中確認號就為 701。
• 數據偏移 ：指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
• 確認 ACK ：當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立后所有傳送的報文段都必須把 ACK 置 1。
• 同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
• 終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，并要求釋放連接。
• 窗口 ：窗口值作為接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因為接收方的數據緩存空間是有限的。

TCP Flags

• URG：緊急指針標志
• ACK：確認序號標志
• PSH：push標志
• RST：重置連接標志
• SYN：同步序號，用于建立連接過程
• FIN：finish標志，用于釋放連接

三次握手

• 第一次握手：建立連接時，客戶端發送 SYN 包 [syn=j] 到服務器，并進入 SYN_SEND 狀態，等待服務器確認；

• 第二次握手：服務器收到 SYN 包，必須確認客戶的 SYN [ ack=j+1]，同時自己也會發送一個 SYN 包 [syn=k]，即 SYN+ACK 包，此時服務器進入 SYN_RECV 狀態；

• 第三次握手：客戶端收到服務器的 SYN+ACK包，想服務器發送確認包 ACK [ ack=k+1]，此包發送完畢，客戶端和服務器進入 ESTABLISHED 狀態，完成三次握手。

假設 Client 為客戶端，Server 為服務器端。

• 首先 Server 處于 LISTEN（監聽）狀態，等待客戶的連接請求。
• Client 向 Server 發送連接請求報文段，SYN=1，ACK=0，選擇一個初始的序號 seq = x, Client進入 SYN_SEND 狀態。
• Server 收到連接請求報文段，如果同意建立連接，則向 Client 發送連接確認報文段，SYN=1，ACK=1，確認號為 x+1，同時也選擇一個初始的序號 seq = y，服務器進入 SYN_RECV 狀態。
• Client 收到 Server 的連接確認報文段后，還要向 Server 發出確認，確認號為 ack = y+1，序號為 seq = x+1，Client 和Server 進入 ESTABLISHED 狀態。
• Client 的 TCP 通知上層應用進程，連接已經建立。
• Server 收到 Client 的確認后，連接建立。
• Server 的 TCP 收到主機 Client 的確認后，也通知其上層應用進程：TCP 連接已經建立。

為什么TCP連接需要三次握手，兩次不可以嗎

為了初始化Sequence Number的初始值，

為了防止已失效的連接請求報文段突然又傳送到了服務端，占用服務器資源。 （假設主機Client為客戶端，主機Server為服務器端）

現假定出現一種異常情況，即Client發出的第一個連接請求報文段并沒有丟失，而是在某些網絡節點長時間滯留了，以致延誤到連接釋放以后的某個時間才到Server。本來這是一個已失效的報文段。但是Server收到此失效的連接請求報文段后，就誤認為是Client有發出一次新的連接請求。于是就向Client發出確認報文段，同意建立連接。假定不采用三次握手，那么只要Server發出確認，新的連接就建立了。

由于現在Client并沒有發出建立連接的請求，因此不會理睬Server的確認，也不會向Server發送數據。但Server卻以為新的運輸連接已經建立了，并一直等待Client發來數據。Server的許多資源就這樣白白浪費了。

Server會不斷重試直至超時，Linux默認等待63秒（1+2+4+8+16+32）才斷開連接。

采用三次握手的辦法可以防止上述現象的發生。例如在剛才的情況下，Client不會向Server的確認發出確認。Server由于收不到確認，就知道Client并沒有要求建立連接。

四次揮手

數據傳輸結束后，通信的雙方都可釋放連接。現在 Client 的應用進程先向其 TCP 發出連接釋放報文段，并停止再發送數據，主動關閉 TCP連接。

• Client 把連接釋放報文段首部的 FIN = 1，其序號 seq = u，Client 進入 FIN_WAIT_1狀態， 等待 Server 的確認。
• Server 發出確認，確認號 ack = u+1，而這個報文段自己的序號 seq = v。（TCP 服務器進程通知高層應用進程），Server進入 CLOSE_WAIT 狀態。
• 從 Client 到 Server 這個方向的連接就釋放了，TCP 連接處于半關閉狀態。Client 不能向 Server 發送數據；Server 若發送數據，Client 仍要接收。
• 當 Server 不再需要連接時，發送連接釋放請求報文段，FIN=1，Server進入 LAST_ACK 狀態。
• Client 收到后發出確認，進入 TIME-WAIT 狀態，接著發送一個ACK給Server，確認號為收到序號+1，Client等待 2 MSL（2*2 = 4 mins）時間后釋放連接。
• Server 收到 Client 的確認后釋放連接，進入CLOSED 狀態，完成四次揮手。

九、為什么 TCP 關閉鏈接時需要 TIME_WAIT 狀態，為什么要等 2MSL？

第一，為了保證 Client 發送的最后一個 ACK 報文能夠到達 Server。這個 ACK 報文段有可能丟失，因而使處在LAST-ACK 狀態的 Server 收不到對已發送的 FIN+ACK 報文段的確認。Server 會超時重傳這個 FIN+ACK 報文段，而 Client 就能在 2MSL 時間內收到這個重傳的FIN+ACK報文段。如果 Client 在 TIME-WAIT 狀態不等待一段時間，而是在發送完ACK報文段后就立即釋放連接，就無法收到 Server 重傳的 FIN+ACK 報文段，因而也不會再發送一次確認報文段。這樣，Server 就無法按照正常的步驟進入 CLOSED 狀態。
第二，Client 在發送完 ACK 報文段后，再經過2MSL時間，就可以使本連接持續的時間所產生的所有報文段都從網絡中消失。這樣就可以使下一個新的連接中不會出現這種舊的連接請求的報文段。

2MSL 即兩倍的 MSL，TCP 的 TIME_WAIT 狀態也稱為 2MSL 等待狀態，當 TCP 的一端發起主動關閉，在發出最后一個 ACK 包后，即第3次握手完成后發送了第四次握手的 ACK 包后就進入了 TIME_WAIT 狀態，必須在此狀態上停留兩倍的 MSL 時間，等待 2MSL 時間主要目的是怕最后一個 ACK 包對方沒收到，那么對方在超時后將重發第三次握手的 FIN 包，主動關閉端接到重發的FIN包后可以再發一個 ACK 應答包。在 TIME_WAIT 狀態時兩端的端口不能使用，要等到 2MSL 時間結束才可繼續使用。當連接處于 2MSL 等待階段時任何遲到的報文段都將被丟棄。不過在實際應用中可以通過設置 SO_REUSEADDR 選項達到不必等待 2MSL 時間結束再使用此端口

為什么需要四次握手才能斷開連接？

因為全雙工，發送方和接收方都需要FIN報文和ACK報文。

服務器出現大量CLOSE_WAIT 狀態的原因。

對方關閉socket連接，我方忙于讀或寫，沒有及時關閉連接：①檢查代碼，特別是釋放資源的代碼；②檢查配置，特別是處理請求的線程配置。

獲取Linux服務器中tcp連接的不同狀態的數量

[root@dsd ~]# netstat -n | awk '/^tcp/{++S[$NF]}END{for (a in S) print a,S[a]}' ESTABLISHED 2

十、一次完整的 HTTP 請求過程（DNS TCP HTTP）

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

DNS解析 [瀏覽器緩存、路由器緩存、DNS緩存]

TCP連接

發送HTTP請求

服務器處理請求并返回HTTP報文

瀏覽器解析渲染頁面

連接結束

具體可以參考下面這篇文章：從輸入URL到頁面加載發生了什么？

附：HTTP狀態碼

• 1xx ：指示信息–表示請求已接受，繼續處理
• 2xx：成功-- 表示請求已被成功接收、理解、接受
• 3xx：重定向–要完成請求必須跟進一步的操作
• 4xx：客戶端錯誤：請求有語法錯誤或請求無法實現
• 5xx：服務端錯誤：服務器未能實現合法的請求

十一、簡述 HTTP 中 GET 和 POST 的區別

• GET 是用來從服務器上獲得數據，而 POST 是用來向服務器上傳遞數據；
• GET 將表單中數據的按照variable=value的形式，添加到action所指向的URL后面，并且兩者使用“?”連接，而各個變量之間使用“&”連接；POST 是將表單中的數據放在form的數據體中，按照變量和值相對應的方式，傳遞到action所指向URL；
• GET 是不安全的，因為在傳輸過程，數據被放在請求的URL中，而如今現有的很多服務器、代理服務器或者用戶代理都會將請求URL記錄到日志文件中，然后放在某個地方，這樣就可能會有一些隱私的信息被第三方看到。另外，用戶也可以在瀏覽器上直接看到提交的數據，一些系統內部消息將會一同顯示在用戶面前。POST的所有操作對用戶來說都是不可見的；
• GET 傳輸的數據量小，這主要是因為受URL長度限制；而POST可以傳輸大量的數據，所以在上傳文件只能使用 POST；
• GET 限制Form表單的數據集的值必須為ASCII字符；而 POST 支持整個ISO10646字符集；
• 從數據庫層面來看，GET請求方式符合冪等性和安全性，GET請求方式是做查詢操作，因此不會改變數據庫中原有的數據，認為符合安全性；POST請求方式是既不冪等又不安全，首先POST請求方式往數據庫中提交數據的，因此會改變數據庫中的數據。
• GET請求能夠被緩存，會保存在瀏覽器的瀏覽記錄中，以GET請求的URL能夠保存為瀏覽器書簽，而POST方式都不具備上述功能。

十二、HTTP2 與 HTTP 之間的區別

HTTP1.1和HTTP1.0的區別主要有：

1、緩存處理

2、帶寬優化以及網絡連接的使用

3、錯誤通知的管理

4、安全性及完整性

HTTP2.0的新特性

• 新的二進制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基于這種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。
• 多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。
• **header壓縮，**如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。
• 服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。目前，有大多數網站已經啟用HTTP2.0，例如YouTuBe，淘寶網等網站，利用chrome控制臺可以查看是否啟用H2。

https://blog.csdn.net/yanghaolong/article/details/90764913

十三、參考

• JavaGuide-計算機網絡
• fullstack-tutorial-計算機網絡
• 百度百科-TCP/UDP協議

總結

以上是生活随笔為你收集整理的面试 -- 操作系统与计算机网络的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。