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

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

簡(jiǎn)單介紹一下進(jìn)程的切換過程

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

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

OSI 七層模型

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

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

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

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

一次完整的 HTTP 請(qǐng)求過程（DNS TCP HTTP）

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

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

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

進(jìn)程

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

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

線程

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

一個(gè)進(jìn)程中可以有多個(gè)線程，它們共享進(jìn)程資源。

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

區(qū)別

Ⅰ 擁有資源

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

Ⅱ 調(diào)度

線程是獨(dú)立調(diào)度的基本單位，在同一進(jìn)程中，線程的切換不會(huì)引起進(jìn)程切換，從一個(gè)進(jìn)程中的線程切換到另一個(gè)進(jìn)程中的線程時(shí)，會(huì)引起進(jìn)程切換。

Ⅲ 系統(tǒng)開銷

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

Ⅳ 通信方面

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

進(jìn)程通信

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

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

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

1. 管道

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

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

它具有以下限制：

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

2. FIFO

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

#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 用作匯聚點(diǎn)，在客戶進(jìn)程和服務(wù)器進(jìn)程之間傳遞數(shù)據(jù)。

3. 消息隊(duì)列

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

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

4. 信號(hào)量

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

5. 共享存儲(chǔ)

允許多個(gè)進(jìn)程共享一個(gè)給定的存儲(chǔ)區(qū)。因?yàn)閿?shù)據(jù)不需要在進(jìn)程之間復(fù)制，所以這是最快的一種 IPC。

需要使用信號(hào)量用來同步對(duì)共享存儲(chǔ)的訪問。

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

6. 套接字

與其它通信機(jī)制不同的是，它可用于不同機(jī)器間的進(jìn)程通信。

二、簡(jiǎn)單介紹一下進(jìn)程的切換過程

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

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

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

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

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

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

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

1.1 先來先服務(wù)

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

按照請(qǐng)求的順序進(jìn)行調(diào)度。

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

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

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

按估計(jì)運(yùn)行時(shí)間最短的順序進(jìn)行調(diào)度。

長(zhǎng)作業(yè)有可能會(huì)餓死，處于一直等待短作業(yè)執(zhí)行完畢的狀態(tài)。因?yàn)槿绻恢庇卸套鳂I(yè)到來，那么長(zhǎng)作業(yè)永遠(yuǎn)得不到調(diào)度。

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

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

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

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

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

2.1 時(shí)間片輪轉(zhuǎn)

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

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

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

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

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

2.3 多級(jí)反饋隊(duì)列

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

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

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

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

3. 實(shí)時(shí)系統(tǒng)

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

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

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

awk

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

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

awk 命令的基本格式為：

[root@localhost ~]# awk [選項(xiàng)] '腳本命令' 文件名

top

實(shí)時(shí)顯示進(jìn)程信息。

示例：兩秒鐘刷新一次

# top -d 2

netstat

查看占用端口的進(jìn)程

示例：查看特定端口的進(jìn)程

# netstat -anp | grep port

less

查看文件內(nèi)容

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

[root@localhost ~]# less [選項(xiàng)] 文件名

grep

查找文件內(nèi)容

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

grep 命令的基本格式如下：

[root@localhost ~]# grep [選項(xiàng)] 模式 文件名

tail

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

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

ISO七層模型中表示層和會(huì)話層

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

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

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

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

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

對(duì)比

UDPTCP

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

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

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

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

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

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

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

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

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

超時(shí)重傳： 當(dāng) TCP 發(fā)出一個(gè)段后，它啟動(dòng)一個(gè)定時(shí)器，等待目的端確認(rèn)收到這個(gè)報(bào)文段。如果不能及時(shí)收到一個(gè)確認(rèn)，將重發(fā)這個(gè)報(bào)文段。

7.1 ARQ協(xié)議

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

停止等待ARQ協(xié)議

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

優(yōu)點(diǎn)： 簡(jiǎn)單

缺點(diǎn)： 信道利用率低，等待時(shí)間長(zhǎng)

1) 無差錯(cuò)情況:

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

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

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

3) 確認(rèn)丟失和確認(rèn)遲到

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

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

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

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

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

7.2 滑動(dòng)窗口和流量控制

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

7.3 擁塞控制

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

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

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

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

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

TCP 首部格式

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

TCP Flags

• URG：緊急指針標(biāo)志
• ACK：確認(rèn)序號(hào)標(biāo)志
• PSH：push標(biāo)志
• RST：重置連接標(biāo)志
• SYN：同步序號(hào)，用于建立連接過程
• FIN：finish標(biāo)志，用于釋放連接

三次握手

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

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

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

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

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

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

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

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

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

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

Server會(huì)不斷重試直至超時(shí)，Linux默認(rèn)等待63秒（1+2+4+8+16+32）才斷開連接。

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

四次揮手

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

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

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

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

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

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

因?yàn)槿p工，發(fā)送方和接收方都需要FIN報(bào)文和ACK報(bào)文。

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

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

獲取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 請(qǐng)求過程（DNS TCP HTTP）

總體來說分為以下幾個(gè)過程:

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

TCP連接

發(fā)送HTTP請(qǐng)求

服務(wù)器處理請(qǐng)求并返回HTTP報(bào)文

瀏覽器解析渲染頁面

連接結(jié)束

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

附：HTTP狀態(tài)碼

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

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

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

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

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

1、緩存處理

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

3、錯(cuò)誤通知的管理

4、安全性及完整性

HTTP2.0的新特性

• 新的二進(jìn)制格式（Binary Format），HTTP1.x的解析是基于文本?；谖谋緟f(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性，要做到健壯性考慮的場(chǎng)景必然很多，二進(jìn)制則不同，只認(rèn)0和1的組合。基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯。
• 多路復(fù)用（MultiPlexing），即連接共享，即每一個(gè)request都是是用作連接共享機(jī)制的。一個(gè)request對(duì)應(yīng)一個(gè)id，這樣一個(gè)連接上可以有多個(gè)request，每個(gè)連接的request可以隨機(jī)的混雜在一起，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請(qǐng)求里面。
• **header壓縮，**如上文中所言，對(duì)前面提到過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控制臺(tái)可以查看是否啟用H2。

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

十三、參考

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

總結(jié)

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

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