1. 程式人生 > >【面試必備】硬核!30 張圖解 HTTP 常見的面試題

【面試必備】硬核!30 張圖解 HTTP 常見的面試題

每日一句英語學習,每天進步一點點:

前言

在面試過程中,HTTP 被提問的概率還是比較高的。小林我搜集了 5 大類 HTTP 面試常問的題目,同時這 5 大類題跟 HTTP 的發展和演變關聯性是比較大的,通過問答 + 圖解的形式由淺入深的方式幫助大家進一步的學習和理解 HTTP 。

  1. HTTP 基本概念
  2. Get 與 Post
  3. HTTP 特性
  4. HTTPS 與 HTTP
  5. HTTP/1.1、HTTP/2、HTTP/3 演變
提綱

正文

01 HTTP 基本概念

HTTP 是什麼?描述一下

HTTP 是超文字傳輸協議,也就是HyperText Transfer Protocol。

能否詳細解釋「超文字傳輸協議」?

HTTP的名字「超文字協議傳輸」,它可以拆成三個部分:

  • 超文字
  • 傳輸
  • 協議
三個部分

1. 「協議」

在生活中,我們也能隨處可見「協議」,例如:

  • 剛畢業時會籤一個「三方協議」;
  • 找房子時會籤一個「租房協議」;
三方協議和租房協議

生活中的協議,本質上與計算機中的協議是相同的,協議的特點:

  • 「協」字,代表的意思是必須有兩個以上的參與者。例如三方協議裡的參與者有三個:你、公司、學校三個;租房協議裡的參與者有兩個:你和房東。
  • 「儀」字,代表的意思是對參與者的一種行為約定和規範。例如三方協議裡規定試用期期限、毀約金等;租房協議裡規定租期期限、每月租金金額、違約如何處理等。

針對 HTTP 協議,我們可以這麼理解。

HTTP 是一個用在計算機世界裡的協議。它使用計算機能夠理解的語言確立了一種計算機之間交流通訊的規範(兩個以上的參與者),以及相關的各種控制和錯誤處理方式(行為約定和規範)。

2. 「傳輸」

所謂的「傳輸」,很好理解,就是把一堆東西從 A 點搬到 B 點,或者從 B 點 搬到 A 點。

別輕視了這個簡單的動作,它至少包含兩項重要的資訊。

HTTP 協議是一個雙向協議。

我們在上網衝浪時,瀏覽器是請求方 A ,百度網站就是應答方 B。雙方約定用 HTTP 協議來通訊,於是瀏覽器把請求資料傳送給網站,網站再把一些資料返回給瀏覽器,最後由瀏覽器渲染在螢幕,就可以看到圖片、視訊了。

請求 - 應答

資料雖然是在 A 和 B 之間傳輸,但允許中間有中轉或接力。

就好像第一排的同學想穿遞紙條給最後一排的同學,那麼傳遞的過程中就需要經過好多個同學(中間人),這樣的傳輸方式就從「A < --- > B」,變成了「A <-> N <-> M <-> B」。

而在 HTTP 裡,需要中間人遵從 HTTP 協議,只要不打擾基本的資料傳輸,就可以新增任意額外的東西。

針對傳輸,我們可以進一步理解了 HTTP。

HTTP 是一個在計算機世界裡專門用來在兩點之間傳輸資料的約定和規範。

3. 「超文字」

HTTP 傳輸的內容是「超文字」。

我們先來理解「文字」,在網際網路早期的時候只是簡單的字元文字,但現在「文字」。的涵義已經可以擴充套件為圖片、視訊、壓縮包等,在 HTTP 眼裡這些都算做「文字」。

再來理解「超文字」,它就是超越了普通文字的文字,它是文字、圖片、視訊等的混合體最關鍵有超連結,能從一個超文字跳轉到另外一個超文字。

HTML 就是最常見的超文字了,它本身知識純文字檔案,但內部用很多標籤定義了圖片、視訊等的連結,在經過瀏覽器的解釋,呈現給我們的就是一個文字、有畫面的網頁了。

OK,經過了對 HTTP 裡這三個名詞的詳細解釋,就可以給出比「超文字傳輸協議」這七個字更準確更有技術含量的答案:

HTTP 是一個在計算機世界裡專門在「兩點」之間「傳輸」文字、圖片、音訊、視訊等「超文字」資料的「約定和規範」。

那「HTTP 是用於從網際網路伺服器傳輸超文字到本地瀏覽器的協議HTTP」 ,這種說法正確嗎?

這種說法是不正確的。因為也可以是「伺服器< -- >伺服器」,所以採用兩點之間的描述會更準確。

HTTP 常見的狀態碼,有哪些?

五大類 HTTP 狀態碼

1xx

1xx 類狀態碼屬於提示資訊,是協議處理中的一種中間狀態,實際用到的比較少。

2xx

2xx 類狀態碼錶示伺服器成功處理了客戶端的請求,也是我們最願意看到的狀態。

「200 OK」是最常見的成功狀態碼,表示一切正常。如果是非 HEAD 請求,伺服器返回的響應頭都會有 body 資料。

「204 No Content」也是常見的成功狀態碼,與 200 OK 基本相同,但響應頭沒有 body 資料。

「206 Partial Content」是應用於 HTTP 分塊下載或斷電續傳,表示響應返回的 body 資料並不是資源的全部,而是其中的一部分,也是伺服器處理成功的狀態。

3xx

3xx 類狀態碼錶示客戶端請求的資源傳送了變動,需要客戶端用新的 URL 重新發送請求獲取資源,也就是重定向。

「301 Moved Permanently」表示永久重定向,說明請求的資源已經不存在了,需改用新的 URL 再次訪問。

「302 Found」表示臨時重定向,說明請求的資源還在,但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭裡使用欄位 Location,指明後續要跳轉的 URL,瀏覽器會自動重定向新的 URL。

「304 Not Modified」不具有跳轉的含義,表示資源未修改,重定向已存在的緩衝檔案,也稱快取重定向,用於快取控制。

4xx

4xx 類狀態碼錶示客戶端傳送的報文有誤,伺服器無法處理,也就是錯誤碼的含義。

「400 Bad Request」表示客戶端請求的報文有錯誤,但只是個籠統的錯誤。

「403 Forbidden」表示伺服器禁止訪問資源,並不是客戶端的請求出錯。

「404 Not Found」表示請求的資源在伺服器上不存在或未找到,所以無法提供給客戶端。

5xx

5xx 類狀態碼錶示客戶端請求報文正確,但是伺服器處理時內部發生了錯誤,屬於伺服器端的錯誤碼。

「500 Internal Server Error」與 400 型別,是個籠統通用的錯誤碼,伺服器發生了什麼錯誤,我們並不知道。

「501 Not Implemented」表示客戶端請求的功能還不支援,類似“即將開業,敬請期待”的意思。

「502 Bad Gateway」通常是伺服器作為閘道器或代理時返回的錯誤碼,表示伺服器自身工作正常,訪問後端伺服器發生了錯誤。

「503 Service Unavailable」表示伺服器當前很忙,暫時無法響應伺服器,類似“網路服務正忙,請稍後重試”的意思。

http 常見欄位有哪些?

Host

客戶端傳送請求時,用來指定伺服器的域名。

Host: www.A.com

有了 Host 欄位,就可以將請求發往「同一臺」伺服器上的不同網站。

Content-Length 欄位

伺服器在返回資料時,會有 Content-Length 欄位,表明本次迴應的資料長度。

Content-Length: 1000

如上面則是告訴瀏覽器,本次伺服器迴應的資料長度是 1000 個位元組,後面的位元組就屬於下一個迴應了。

Connection 欄位

Connection 欄位最常用於客戶端要求伺服器使用 TCP 持久連線,以便其他請求複用。

image

HTTP/1.1 版本的預設連線都是持久連線,但為了相容老版本的 HTTP,需要指定 Connection 首部欄位的值為 Keep-Alive

Connection: keep-alive

一個可以複用的 TCP 連線就建立了,直到客戶端或伺服器主動關閉連線。但是,這不是標準欄位。

Content-Type 欄位

Content-Type 欄位用於伺服器迴應時,告訴客戶端,本次資料是什麼格式。

Content-Type: text/html; charset=utf-8

上面的型別表明,傳送的是網頁,而且編碼是UTF-8。

客戶端請求的時候,可以使用 Accept 欄位宣告自己可以接受哪些資料格式。

Accept: */*

上面程式碼中,客戶端宣告自己可以接受任何格式的資料。

Content-Encoding 欄位

Content-Encoding 欄位說明資料的壓縮方法。表示伺服器返回的資料使用了什麼壓縮格式

Content-Encoding: gzip

上面表示伺服器返回的資料採用了 gzip 方式壓縮,告知客戶端需要用此方式解壓。

客戶端在請求時,用 Accept-Encoding 欄位說明自己可以接受哪些壓縮方法。

Accept-Encoding: gzip, deflate

GET 與 POST

說一下 GET 和 POST 的區別?

Get 方法的含義是請求從伺服器獲取資源,這個資源可以是靜態的文字、頁面、圖片視訊等。

比如,你開啟我的文章,瀏覽器就會發送 GET 請求給伺服器,伺服器就會返回文章的所有文字及資源。

GET 請求

POST 方法則是相反操作,它向 URI 指定的資源提交資料,資料就放在報文的 body 裡。

比如,你在我文章底部,敲入了留言後點擊「提交」(暗示你們留言),瀏覽器就會執行一次 POST 請求,把你的留言文字放進了報文 body 裡,然後拼接好 POST 請求頭,通過 TCP 協議傳送給伺服器。

POST 請求

GET 和 POST 方法都是安全和冪等的嗎?

先說明下安全和冪等的概念:

  • 在 HTTP 協議裡,所謂的「安全」是指請求方法不會「破壞」伺服器上的資源。
  • 所謂的「冪等」,意思是多次執行相同的操作,結果都是「相同」的。

那麼很明顯 GET 方法就是安全且冪等的,因為它是「只讀」操作,無論操作多少次,伺服器上的資料都是安全的,且每次的結果都是相同的。

POST 因為是「新增或提交資料」的操作,會修改伺服器上的資源,所以是不安全的,且多次提交資料就會建立多個資源,所以不是冪等的。


03 HTTP 特性

你知道的 HTTP(1.1) 的優點有哪些,怎麼體現的?

HTTP 最凸出的優點是「簡單、靈活和易於擴充套件、應用廣泛和跨平臺」。

1. 簡單

HTTP 基本的報文格式就是 header + body,頭部資訊也是 key-value 簡單文字的形式,易於理解,降低了學習和使用的門檻。

2. 靈活和易於擴充套件

HTTP協議裡的各類請求方法、URI/URL、狀態碼、頭欄位等每個組成要求都沒有被固定死,都允許開發人員自定義和擴充。

同時 HTTP 由於是工作在應用層( OSI 第七層),則它下層可以隨意變化。

HTTPS 也就是在 HTTP 與 TCP 層之間增加了 SSL/TLS 安全傳輸層,HTTP/3 甚至把 TCPP 層換成了基於 UDP 的 QUIC。

3. 應用廣泛和跨平臺

網際網路發展至今,HTTP 的應用範圍非常的廣泛,從桌上型電腦的瀏覽器到手機上的各種 APP,從看新聞、刷貼吧到購物、理財、吃雞,HTTP 的應用片地開花,同時天然具有跨平臺的優越性。

那它的缺點呢?

HTTP 協議裡有優缺點一體的雙刃劍,分別是「無狀態、明文傳輸」,同時還有一大缺點「不安全」。

1. 無狀態雙刃劍

無狀態的好處,因為伺服器不會去記憶 HTTP 的狀態,所以不需要額外的資源來記錄狀態資訊,這能減輕伺服器的負擔,能夠把更多的 CPU 和記憶體用來對外提供服務。

無狀態的壞處,既然伺服器沒有記憶能力,它在完成有關聯性的操作時會非常麻煩。

例如登入->新增購物車->下單->結算->支付,這系列操作都要知道使用者的身份才行。但伺服器不知道這些請求是有關聯的,每次都要問一遍身份資訊。

這樣每操作一次,都要驗證資訊,這樣的購物體驗還能愉快嗎?別問,問就是酸爽!

對於無狀態的問題,解法方案有很多種,其中比較簡單的方式用 Cookie 技術。

Cookie 通過在請求和響應報文中寫入 Cookie 資訊來控制客戶端的狀態。

相當於,在客戶端第一次請求後,伺服器會下發一個裝有客戶資訊的「小貼紙」,後續客戶端請求伺服器的時候,帶上「小貼紙」,伺服器就能認得了了,

Cookie 技術

2. 明文傳輸雙刃劍

明文意味著在傳輸過程中的資訊,是可方便閱讀的,通過瀏覽器的 F12 控制檯或 Wireshark 抓包都可以直接肉眼檢視,為我們除錯工作帶了極大的便利性。

但是這正是這樣,HTTP 的所有資訊都暴露在了光天化日下,相當於資訊裸奔。在傳輸的漫長的過程中,資訊的內容都毫無隱私可言,很容易就能被竊取,如果裡面有你的賬號密碼資訊,那你號沒了。

3. 不安全

HTTP 比較嚴重的缺點就是不安全:

  • 通訊使用明文(不加密),內容可能會被竊聽。比如,賬號資訊容易洩漏,那你號沒了。
  • 不驗證通訊方的身份,因此有可能遭遇偽裝。比如,訪問假的淘寶、拼多多,那你錢沒了。
  • 無法證明報文的完整性,所以有可能已遭篡改。比如,網頁上植入垃圾廣告,視覺汙染,眼沒了。

HTTP 的安全問題,可以用 HTTPS 的方式解決,也就是通過引入 SSL/TLS 層,使得在安全上達到了極致。

那你在說下 HTTP/1.1 的效能如何?

HTTP 協議是基於 TCP/IP,並且使用了「請求 - 應答」的通訊模式,所以效能的關鍵就在這兩點裡。

1. 長連線

早期 HTTP/1.0 效能上的一個很大的問題,那就是每發起一個請求,都要新建一次 TCP 連線(三次握手),而且是序列請求,做了無畏的 TCP 連線建立和斷開,增加了通訊開銷。

為了解決上述 TCP 連線問題,HTTP/1.1 提出了長連線的通訊方式,也叫持久連線。這種方式的好處在於減少了 TCP 連線的重複建立和斷開所造成的額
外開銷,減輕了伺服器端的負載。

持久連線的特點是,只要任意一端沒有明確提出斷開連線,則保持 TCP 連線狀態。

短連線與長連線

2. 管道網路傳輸

HTTP/1.1 採用了長連線的方式,這使得管道(pipeline)網路傳輸成為了可能。

即可在同一個 TCP 連線裡面,客戶端可以發起多個請求,只要第一個請求發出去了,不必等其回來,就可以發第二個請求出去,可以減少整體的響應時間。

舉例來說,客戶端需要請求兩個資源。以前的做法是,在同一個TCP連線裡面,先發送 A 請求,然後等待伺服器做出迴應,收到後再發出 B 請求。管道機制則是允許瀏覽器同時發出 A 請求和 B 請求。

管道網路傳輸

但是伺服器還是按照順序,先回應 A 請求,完成後再回應 B 請求。要是 前面的迴應特別慢,後面就會有許多請求排隊等著。這稱為「隊頭堵塞」。

3. 隊頭阻塞

「請求 - 應答」的模式加劇了 HTTP 的效能問題。

因為當順序傳送的請求序列中的一個請求因為某種原因被阻塞時,在後面排隊的所有請求也一同被阻塞了,會招致客戶端一直請求不到資料,這也就是「隊頭阻塞」。好比上班的路上塞車。

隊頭阻塞

總之 HTTP/1.1 的效能一般般,後續的 HTTP/2 和 HTTP/3 就是在優化 HTTP 的效能。


04 HTTP 與 HTTPS

HTTP 與 HTTPS 有哪些區別?

  1. HTTP 是超文字傳輸協議,資訊是明文傳輸,存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷,在 TCP 和 HTTP 網路層之間加入了 SSL/TLS 安全協議,使得報文能夠加密傳輸。
  2. HTTP 連線建立相對簡單, TCP 三次握手之後便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之後,還需進行 SSL/TLS 的握手過程,才可進入加密報文傳輸。
  3. HTTP 的埠號是 80,HTTPS 的埠號是 443。
  4. HTTPS 協議需要向 CA(證書權威機構)申請數字證書,來保證伺服器的身份是可信的。

HTTPS 解決了 HTTP 的哪些問題?

HTTP 由於是明文傳輸,所以安全上存在以下三個風險:

  • 竊聽風險,比如通訊鏈路上可以獲取通訊內容,使用者號容易沒。
  • 篡改風險,比如強制入垃圾廣告,視覺汙染,使用者眼容易瞎。
  • 冒充風險,比如冒充淘寶網站,使用者錢容易沒。
HTTP 與 HTTPS 網路層

HTTPS 在 HTTP 與 TCP 層之間加入了 SSL/TLS 協議,可以很好的解決了上述的風險:

  • 資訊加密:互動資訊無法被竊取,但你的號會因為「自身忘記」賬號而沒。
  • 校驗機制:無法篡改通訊內容,篡改了就不能正常顯示,但百度「競價排名」依然可以搜尋垃圾廣告。
  • 身份證書:證明淘寶是真的淘寶網,但你的錢還是會因為「剁手」而沒。

可見,只要自身不做「惡」,SSL/TLS 協議是能保證通訊是安全的。

HTTPS 是如何解決上面的三個風險的?

  • 混合加密的方式實現資訊的機密性,解決了竊聽的風險。
  • 摘要演算法的方式來實現完整性,它能夠為資料生成獨一無二的「指紋」,指紋用於校驗資料的完整性,解決了篡改的風險。
  • 將伺服器公鑰放入到數字證書中,解決了冒充的風險。

1. 混合加密

通過混合加密的方式可以保證資訊的機密性,解決了竊聽的風險。

混合加密

HTTPS 採用的是對稱加密和非對稱加密結合的「混合加密」方式:

  • 在通訊建立前採用非對稱加密的方式交換「會話祕鑰」,後續就不再使用非對稱加密。
  • 在通訊過程中全部使用對稱加密的「會話祕鑰」的方式加密明文資料。

採用「混合加密」的方式的原因:

  • 對稱加密只使用一個金鑰,運算速度快,金鑰必須保密,無法做到安全的金鑰交換。
  • 非對稱加密使用兩個金鑰:公鑰和私鑰,公鑰可以任意分發而私鑰保密,解決了金鑰交換問題但速度慢。

2. 摘要演算法

摘要演算法用來實現完整性,能夠為資料生成獨一無二的「指紋」,用於校驗資料的完整性,解決了篡改的風險。

校驗完整性

客戶端在傳送明文之前會通過摘要演算法算出明文的「指紋」,傳送的時候把「指紋 + 明文」一同
加密成密文後,傳送給伺服器,伺服器解密後,用相同的摘要演算法算出傳送過來的明文,通過比較客戶端攜帶的「指紋」和當前算出的「指紋」做比較,若「指紋」相同,說明資料是完整的。

3. 數字證書

客戶端先向伺服器端索要公鑰,然後用公鑰加密資訊,伺服器收到密文後,用自己的私鑰解密。

這就存在些問題,如何保證公鑰不被篡改和信任度?

所以這裡就需要藉助第三方權威機構 CA (數字證書認證機構),將伺服器公鑰放在數字證書(由數字證書認證機構頒發)中,只要證書是可信的,公鑰就是可信的。

數子證書工作流程

通過數字證書的方式保證伺服器公鑰的身份,解決冒充的風險。

HTTPS 是如何建立連線的?其間互動了什麼?

SSL/TLS 協議基本流程:

  • 客戶端向伺服器索要並驗證伺服器的公鑰。
  • 雙方協商生產「會話祕鑰」。
  • 雙方採用「會話祕鑰」進行加密通訊。

前兩步也就是 SSL/TLS 的建立過程,也就是握手階段。

SSL/TLS 的「握手階段」涉及四次通訊,可見下圖:

HTTPS 連線建立過程

SSL/TLS 協議建立的詳細流程:

1. ClientHello

首先,由客戶端向伺服器發起加密通訊請求,也就是 ClientHello 請求。

在這一步,客戶端主要向伺服器傳送以下資訊:

(1)客戶端支援的 SSL/TLS 協議版本,如 TLS 1.2 版本。

(2)客戶端生產的隨機數(Client Random),後面用於生產「會話祕鑰」。

(3)客戶端支援的密碼套件列表,如 RSA 加密演算法。

2. SeverHello

伺服器收到客戶端請求後,向客戶端發出響應,也就是 SeverHello。伺服器迴應的內容有如下內容:

(1)確認 SSL/ TLS 協議版本,如果瀏覽器不支援,則關閉加密通訊。

(2)伺服器生產的隨機數(Server Random),後面用於生產「會話祕鑰」。

(3)確認的密碼套件列表,如 RSA 加密演算法。

(4)伺服器的數字證書。

3.客戶端迴應

客戶端收到伺服器的迴應之後,首先通過瀏覽器或者作業系統中的 CA 公鑰,確認伺服器的數字證書的真實性。

如果證書沒有問題,客戶端會從數字證書中取出伺服器的公鑰,然後使用它加密報文,向伺服器傳送如下資訊:

(1)一個隨機數(pre-master key)。該隨機數會被伺服器公鑰加密。

(2)加密通訊演算法改變通知,表示隨後的資訊都將用「會話祕鑰」加密通訊。

(3)客戶端握手結束通知,表示客戶端的握手階段已經結束。這一項同時把之前所有內容的發生的資料做個摘要,用來供服務端校驗。

上面第一項的隨機數是整個握手階段的第三個隨機數,這樣伺服器和客戶端就同時有三個隨機數,接著就用雙方協商的加密演算法,各自生成本次通訊的「會話祕鑰」。

4. 伺服器的最後迴應

伺服器收到客戶端的第三個隨機數(

相關推薦

面試必備30 圖解 HTTP 常見的面試題

每日一句英語學習,每天進步一點點: 前言 在面試過程中,HTTP 被提問的概率還是比較高的。小林我搜集了 5 大類 HTTP 面試常問的題目,同時這 5 大類題跟 HTTP 的發展和演變關聯性是比較大的,通過問答 + 圖解的形式由淺入深的方式幫助大家進一步的學習和理解 HTTP 。 HTTP 基本概念

15圖解Redis為什麼這麼快

作為一名服務端工程師,工作中你肯定和 Redis 打過交道。Redis 為什麼快,這點想必你也知道,至少為了面試也做過準備。很多人知道 Redis 快僅僅因為它是基於記憶體實現的,對於其它原因倒是模稜兩可。 那麼今天就和小萊一起看看: 圖注:- 思維導圖 -   基

面試必備探究一個數據包在網路中的心路歷程

每日一句英語學習,每天進步一點點: 前言 想必不少小夥伴面試過程中,會遇到「當鍵入網址後,到網頁顯示,其間發生了什麼」的面試題。 還別說,這真是挺常問的這題,前幾天坐在我旁邊的主管電話面試應聘者的時候,也問了這個問題。 這次,小林我帶大家一起探究下,一個數據包在網路中的心路歷程。 每個階段都有資料包的「

面試必備用了那麼多次 ping,是時候知道 ping 是如何工作的了

每日一句英語學習,每天進步一點點: 前言 在日常生活或工作中,我們在判斷與對方網路是否暢通,使用的最多的莫過於 ping 命令了。 “那你知道 ping 是如何工作的嗎?” —— 來自小林的靈魂拷問 可能有的小夥伴奇怪的問:“我雖然不明白它的工

面試必備透過源碼角度一步一步帶你分析 ArrayList 擴容機制

bject string else if _array 核心 ray 擴容 ++ cit 一 先從 ArrayList 的構造函數說起ArrayList有三種方式來初始化,構造方法源碼如下:/** 默認初始容量大小*/private static final int D

面試必備透過原始碼角度一步一步帶你分析 ArrayList 擴容機制

該文已加入開源文件:JavaGuide(一份涵蓋大部分Java程式設計師所需要掌握的核心知識)。地址:https://github.com/Snailclimb... 一 先從 ArrayList 的建構函式說起 ArrayList有三種方式來初始化,構造方法原始

面試必備透過原始碼角度一步一步帶你走近阿里

一 先從 ArrayList 的建構函式說起 ArrayList有三種方式來初始化,構造方法原始碼如下: /** * 預設初始容量大小 */ private static final int DEFAULT_CAPACITY = 10; private stat

面試必備常見Java面試題大綜合

一、Java基礎1、Arrays.sort實現原理和Collections.sort實現原理答:Collections.sort方法底層會呼叫Arrays.sort方法,底層實現都是TimeSort實現的。TimSort演算法就是找到已經排好序資料的子序列,然後對剩餘部分排序,然後合併起來.2、foreach

面試必備手撕程式碼,你怕不怕?

Part 1.生產者-消費者問題這絕對是屬於重點了,不管是考察對於該重要模型的理解還是考察程式碼能力,這都是一道很好的考題,所以很有必要的,我們先來回顧一下什麼是生產者-消費者問題; 問題簡單回顧 如果想學習Java工程化、高效能及分散式、深入淺出。微服務、Spring,MyBatis,Netty原始碼分

面試必備手撕代碼,你怕不怕?

建議 快速排序算法 後續遍歷 任務 一點 編程 thread類 選擇 很多 Part 1.生產者-消費者問題這絕對是屬於重點了,不管是考察對於該重要模型的理解還是考察代碼能力,這都是一道很好的考題,所以很有必要的,我們先來回顧一下什麽是生產者-消費者問題; 問題簡單回顧 如

面試必備如何在10億數中找出前1000大的數?

作者:channingbreeze | 微信公眾號:網際網路偵察小史是一個應屆生,雖然學的是電子

MongoDB--副本集基本資訊面試必備

副本集的概念 副本集是一組伺服器,其中有一個是主伺服器(primary),用於處理客戶端請求;還有多個備份伺服器(secondary),用於儲存主伺服器的資料副本。如果主伺服器崩潰了,備份伺服器會自動將其中一個成員升級為新的主伺服器。 副本集特徵:  · N 個節點的叢集  ·

面試必備小夥伴栽在了JVM的記憶體分配策略。。。

週末有小夥伴留言說上週面試時被問到記憶體分配策略的問題,但回答的不夠理想,小夥伴說之前公號裡看過這一塊的文章的,當時看時很清楚,也知道各個策略是幹嘛的,但面試時腦子裡清楚,心裡很明白,但嘴裡就是說不清楚,說出來的就是像雲像霧又像風,最後面試官說他應該是不清楚這一塊的內容 這裡給小夥伴要再次說明下,任何知識點,

圖搞懂 Flink 端到端精準一次處理語義 Exactly-once(深入原理,建議收藏)

### Flink 在 Flink 中需要端到端精準一次處理的位置有三個: ![Flink 端到端精準一次處理](https://cdn.jsdelivr.net/gh/sunmyuan/cdn/210130_8.png) - **Source 端**:資料從上一階段進入到 Flink 時,

搞定 Java 併發面試面試問的 Java 併發基礎見面試題總結

本文為 SnailClimb 的原創,目前已經收錄自我開源的 JavaGuide 中(61.5 k Star!【Java學習+面試指南】 一份涵蓋大部分Java程式設計師所需要掌握的核心知識。歡迎 Star!)。 另外推薦一篇原創:終極推薦!可能是最適合你的Java學習路線+方法+網站+書籍推薦! Jav

自制作業系統01講解計算機的啟動過程

本講只為講明白下面一個問題: 我們按下開機鍵後究竟發生了什麼? 好的,這似乎是好多人都特別想搞明白的一個問題,有時候非常納悶,為什麼一個看似這麼簡單的問題,就是搜不到一個直面問題的答案呢? 好問題,我也不知道為什麼會這樣,但我猜是因為: 其一,似懂非懂的人太多,他們其實也不知道究竟發生了什麼,所以只能模

Dubbo見面試題

有情懷,有乾貨,微信搜尋【三太子敖丙】關注這個不一樣的程式設計師。 本文 GitHub https://github.com/JavaFamily 已收錄,有一線大廠面試完整考點、資料以及我的系列文章。 前言 Dubbo 整體介紹的差不多了,今天就開始面試環節了,我會列舉一些常見的 Dubbo 面試題,只

樂智公仔店淘寶店鋪微店開業了

淘寶店鋪 小精靈 宮崎駿動漫 二維碼 空調被 掃一掃上面的二維碼,進入我們的淘寶店掃一掃上面的二維碼,進入樂智公仔店【微店】黑白熊 當您在感到疲憊的時候,午休時,可以有一條空調被是多麽美好的事兒。 當您想趴在桌上小憩是有個抱枕毛茸茸的趴在上面是多麽舒服的感覺。熊啊熊貓舒適、漂亮

面試 IO第十一篇 java IO

長度 HR 數據 比特 inpu 最小 str itl 部分 1.什麽是比特(Bit),什麽是字節(Byte),什麽是字符(Char),它們長度是多少,各有什麽區別   1》Bit最小的二進制單位 ,是計算機的操作部分 取值0或者1  2》Byte是計算機操作數據的最小單位

看一看最強翻譯機哪個好用呢?音樂天使告訴你

過去 看球 降落 inf 避免 www 是個 targe blank 近期的俄羅斯世界足球杯,讓不少球迷都為之瘋狂,我也不例外,為此訂了一張機票直飛俄羅斯的喀山,自己不會俄語,為了避免尷尬我購買了一部翻譯機-音樂天使隨身攜帶,而且剛好因為世界杯,俄羅斯那邊免簽證30天,對於