基于 Java面試 32個核心必考點完全解析（上）【附視頻地址】中的 操作系統(tǒng)與計算機網(wǎng)絡(luò) 相關(guān)面試題做記錄。

進程與線程的區(qū)別與聯(lián)系（資源的占用，切換效率，通信方式）

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

操作系統(tǒng)中的進程調(diào)度算法

經(jīng)常使用的 Linux 命令，使用場景

OSI 七層模型

簡述 TCP \ UDP的區(qū)別

TCP 如何實現(xiàn)可靠性傳輸

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

為什么 TCP 關(guān)閉鏈接時需要 TIME_WAIT 狀態(tài)，為什么要等 2MSL？

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

簡述 HTTP 中 GET 和 POST 的區(qū)別

HTTP2 與 HTTP 之間的區(qū)別

一、進程與線程的區(qū)別與聯(lián)系（資源的占用，切換效率，通信方式）

進程

進程是資源分配的基本單位，用來管理資源（例如：內(nèi)存，文件，網(wǎng)絡(luò)等資源）

進程控制塊 (Process Control Block, PCB) 描述進程的基本信息和運行狀態(tài)，所謂的創(chuàng)建進程和撤銷進程，都是指對 PCB 的操作。（PCB是描述進程的數(shù)據(jù)結(jié)構(gòu)）

線程

線程是獨立調(diào)度的基本單位。

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

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

區(qū)別

Ⅰ 擁有資源

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

Ⅱ 調(diào)度

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

Ⅲ 系統(tǒng)開銷

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

Ⅳ 通信方面

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

進程通信

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

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

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

1. 管道

管道是通過調(diào)用 pipe 函數(shù)創(chuàng)建的，fd[0] 用于讀，fd[1] 用于寫。

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

它具有以下限制：

• 只支持半雙工通信（單向交替?zhèn)鬏?#xff09;；
• 只能在父子進程或者兄弟進程中使用。

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 常用于客戶-服務(wù)器應(yīng)用程序中，FIFO 用作匯聚點，在客戶進程和服務(wù)器進程之間傳遞數(shù)據(jù)。

3. 消息隊列

相比于 FIFO，消息隊列具有以下優(yōu)點：

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

4. 信號量

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

5. 共享存儲

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

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

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

6. 套接字

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

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

• 就緒狀態(tài)（ready）：等待被調(diào)度
• 運行狀態(tài)（running）：運行中
• 阻塞狀態(tài)（waiting）：等待資源

應(yīng)該注意以下內(nèi)容：

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

三、操作系統(tǒng)中的進程調(diào)度算法

不同環(huán)境的調(diào)度算法目標不同，因此需要針對不同環(huán)境來討論調(diào)度算法。

1. 批處理系統(tǒng)

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

1.1 先來先服務(wù)

先來先服務(wù) first-come first-serverd（FCFS）

按照請求的順序進行調(diào)度。

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

1.2 短作業(yè)優(yōu)先

短作業(yè)優(yōu)先 shortest job first（SJF）

按估計運行時間最短的順序進行調(diào)度。

長作業(yè)有可能會餓死，處于一直等待短作業(yè)執(zhí)行完畢的狀態(tài)。因為如果一直有短作業(yè)到來，那么長作業(yè)永遠得不到調(diào)度。

1.3 最短剩余時間優(yōu)先

最短剩余時間優(yōu)先 shortest remaining time next（SRTN）

按估計剩余時間最短的順序進行調(diào)度。

2. 交互式系統(tǒng)

交互式系統(tǒng)有大量的用戶交互操作，在該系統(tǒng)中調(diào)度算法的目標是快速地進行響應(yīng)。

2.1 時間片輪轉(zhuǎn)

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

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

2.2 優(yōu)先級調(diào)度

為每個進程分配一個優(yōu)先級，按優(yōu)先級進行調(diào)度。

為了防止低優(yōu)先級的進程永遠等不到調(diào)度，可以隨著時間的推移增加等待進程的優(yōu)先級。

2.3 多級反饋隊列

如果一個進程需要執(zhí)行 100 個時間片，如果采用時間片輪轉(zhuǎn)調(diào)度算法，那么需要交換 100 次。

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

每個隊列優(yōu)先權(quán)也不同，最上面的優(yōu)先權(quán)最高。因此只有上一個隊列沒有進程在排隊，才能調(diào)度當前隊列上的進程。

可以將這種調(diào)度算法看成是時間片輪轉(zhuǎn)調(diào)度算法和優(yōu)先級調(diào)度算法的結(jié)合。

3. 實時系統(tǒng)

實時系統(tǒng)要求一個請求在一個確定時間內(nèi)得到響應(yīng)。

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

四、經(jīng)常使用的 Linux 命令，使用場景

awk

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

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

awk 命令的基本格式為：

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

top

實時顯示進程信息。

示例：兩秒鐘刷新一次

# top -d 2

netstat

查看占用端口的進程

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

# netstat -anp | grep port

less

查看文件內(nèi)容

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

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

grep

查找文件內(nèi)容

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

grep 命令的基本格式如下：

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

tail

顯示文件結(jié)尾的內(nèi)容

經(jīng)常用于實時查看項目日志信息

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

五、OSI 七層模型

五層協(xié)議

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

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

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

六、簡述 TCP \ UDP的區(qū)別

在 TCP/IP 網(wǎng)絡(luò)體系結(jié)構(gòu)中，TCP（傳輸控制協(xié)議，Transport Controll Protocol、UDP（用戶數(shù)據(jù)報協(xié)議，User Data Protocol）是傳輸層最重要的兩種協(xié)議，為上層用戶提供級別的通信可靠性。

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

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

對比

UDPTCP

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

七、TCP 如何實現(xiàn)可靠性傳輸

應(yīng)用數(shù)據(jù)被分割成 TCP 認為最適合發(fā)送的數(shù)據(jù)塊。

TCP 給發(fā)送的每一個包進行編號，接收方對數(shù)據(jù)包進行排序，把有序數(shù)據(jù)傳送給應(yīng)用層。

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

TCP 的接收端會丟棄重復(fù)的數(shù)據(jù)。

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

擁塞控制： 當網(wǎng)絡(luò)擁塞時，減少數(shù)據(jù)的發(fā)送。

ARQ協(xié)議： 也是為了實現(xiàn)可靠傳輸?shù)?#xff0c;它的基本原理就是每發(fā)完一個分組就停止發(fā)送，等待對方確認。在收到確認后再發(fā)下一個分組。

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

7.1 ARQ協(xié)議

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

停止等待ARQ協(xié)議

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

優(yōu)點： 簡單

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

1) 無差錯情況:

發(fā)送方發(fā)送分組,接收方在規(guī)定時間內(nèi)收到,并且回復(fù)確認.發(fā)送方再次發(fā)送。

2) 出現(xiàn)差錯情況（超時重傳）:

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

3) 確認丟失和確認遲到

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

連續(xù)ARQ協(xié)議

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

優(yōu)點： 信道利用率高，容易實現(xiàn)，即使確認丟失，也不必重傳。

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

7.2 滑動窗口和流量控制

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

7.3 擁塞控制

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

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

TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復(fù)。在網(wǎng)絡(luò)層也可以使路由器采用適當?shù)姆纸M丟棄策略（如主動隊列管理 AQM），以減少網(wǎng)絡(luò)擁塞的發(fā)生。

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

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

TCP 首部格式

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

TCP Flags

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

三次握手

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

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

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

假設(shè) Client 為客戶端，Server 為服務(wù)器端。

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

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

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

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

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

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

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

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

四次揮手

數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可釋放連接。現(xiàn)在 Client 的應(yīng)用進程先向其 TCP 發(fā)出連接釋放報文段，并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉 TCP連接。

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

九、為什么 TCP 關(guān)閉鏈接時需要 TIME_WAIT 狀態(tài)，為什么要等 2MSL？

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

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

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

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

服務(wù)器出現(xiàn)大量CLOSE_WAIT 狀態(tài)的原因。

對方關(guān)閉socket連接，我方忙于讀或?qū)?#xff0c;沒有及時關(guān)閉連接：①檢查代碼，特別是釋放資源的代碼；②檢查配置，特別是處理請求的線程配置。

獲取Linux服務(wù)器中tcp連接的不同狀態(tài)的數(shù)量

[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連接

發(fā)送HTTP請求

服務(wù)器處理請求并返回HTTP報文

瀏覽器解析渲染頁面

連接結(jié)束

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

附：HTTP狀態(tài)碼

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

十一、簡述 HTTP 中 GET 和 POST 的區(qū)別

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

十二、HTTP2 與 HTTP 之間的區(qū)別

HTTP1.1和HTTP1.0的區(qū)別主要有：

1、緩存處理

2、帶寬優(yōu)化以及網(wǎng)絡(luò)連接的使用

3、錯誤通知的管理

4、安全性及完整性

HTTP2.0的新特性

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

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

十三、參考

• JavaGuide-計算機網(wǎng)絡(luò)
• fullstack-tutorial-計算機網(wǎng)絡(luò)
• 百度百科-TCP/UDP協(xié)議

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。