2020年最新Java面試常問的計算機網絡方面問題

時間  2020-12-04
標籤 css html linux 面試 瀏覽器 緩存 安全 服務器 cookie 網絡 欄目 Java 简体版
原文   原文鏈接

GET 和 POST 的區別

（GET）請注意，查詢字符串（名稱/值對）是在 GET 請求的 URL 中發送的：/test/demo_form.asp?name1=value1&name2=value2css

  1. GET 請求可被緩存html

  2. GET 請求保留在瀏覽器歷史記錄中linux

  3. GET 請求可被收藏爲書籤面試

  4. GET 請求不該在處理敏感數據時使用瀏覽器

  5. GET 請求有長度限制緩存

  6. GET 請求只應當用於取回數據POST 方法（POST）請注意，查詢字符串（名稱/值對）是在 POST 請求的 HTTP 消息主體中發送的：POST /test/demo_form.asp HTTP/1.1Host: w3schools.comname1=value1&name2=value2安全

  7. POST 請求不會被緩存服務器

  8. POST 請求不會保留在瀏覽器歷史記錄中cookie

  9. POST 不能被收藏爲書籤網絡

  10. POST 請求對數據長度沒有要求

 

dns使用的協議

既使用TCP又使用UDP

  • 首先了解一下TCP與UDP傳送字節的長度限制：
  1. UDP報文的最大長度爲512字節，而TCP則容許報文長度超過512字節。當DNS查詢超過512字節時，協議的TC標誌出現刪除標誌，這時則使用TCP發送。一般傳統的UDP報文通常不會大於512字節。
  • 區域傳送時使用TCP，主要有一下兩點考慮：
  1. 輔域名服務器會定時（通常時3小時）向主域名服務器進行查詢以便了解數據是否有變更。若有變更，則會執行一次區域傳送，進行數據同步。區域傳送將使用TCP而不是UDP，由於數據同步傳送的數據量比一個請求和應答的數據量要多得多。
  2. TCP是一種可靠的鏈接，保證了數據的準確性。
  • 域名解析時使用UDP協議：
  1. 客戶端向DNS服務器查詢域名，通常返回的內容都不超過512字節，用UDP傳輸便可。不用通過TCP三次握手，這樣DNS服務器負載更低，響應更快。雖然從理論上說，客戶端也能夠指定向DNS服務器查詢的時候使用TCP，但事實上，不少DNS服務器進行配置的時候，僅支持UDP查詢包。

你們以爲本次面試題總結的寫得不錯的朋友，你們能夠轉發+關注，而後掃描下方二維碼獲取更多面試題以及答案— 掃描添加暗號：【CSDN】

 

冪等

一個冪等操做的特色是其任意屢次執行所產生的影響均與一次執行的影響相同。冪等函數，或冪等方法，是指可使用相同參數重複執行，並能得到相同結果的函數。這些函數不會影響系統狀態，也不用擔憂重複執行會對系統形成改變。例如，「getUsername()和setTrue()」函數就是一個冪等函數.

Cookies和session區別

  1. Cookies是一種可以讓網站服務器把少許數據儲存到客戶端的硬盤或內存，或是從客戶端的硬盤讀取數據的一種技術。Cookies是當你瀏覽某網站時，由Web服務器置於你硬盤上的一個很是小的文本文件，它能夠記錄你的用戶ID、密碼、瀏覽過的網頁、停留的時間等信息。session: 當用戶請求來自應用程序的 Web 頁時，若是該用戶尚未會話，則 Web 服務器將自動建立一個 Session 對象。當會話過時或被放棄後，服務器將終止該會話。cookie機制：採用的是在客戶端保持狀態的方案，而session機制採用的是在服務端保持狀態的方案。同時咱們看到因爲服務器端保持狀態的方案在客戶端也須要保存一個標識，因此session機制可能須要藉助cookie機制來達到保存標識的目的。

  2. Session是服務器用來跟蹤用戶的一種手段，每一個Session都有一個惟一標識：session ID。當服務器建立了Session時，給客戶端發送的響應報文包含了Set-cookie字段，其中有一個名爲sid的鍵值對，這個鍵值Session ID。客戶端收到後就把Cookie保存瀏覽器，而且以後發送的請求報表都包含SessionID。HTTP就是經過Session和Cookie這兩個發送一塊兒合做來實現跟蹤用戶狀態，Session用於服務端，Cookie用於客戶端

 

TCP粘包和拆包產生的緣由

  1. 應用程序寫入數據的字節大小大於套接字發送緩衝區的大小
  2. 進行MSS大小的TCP分段。MSS是最大報文段長度的縮寫。MSS是TCP報文段中的數據字段的最大長度。數據字段加上TCP首部纔等於整個的TCP報文段。因此MSS並非TCP報文段的最大長度，而是：MSS=TCP報文段長度-TCP首部長度
  3. 以太網的payload大於MTU進行IP分片。MTU指：一種通訊協議的某一層上面所能經過的最大數據包大小。若是IP層有一個數據包要傳，並且數據的長度比鏈路層的MTU大，那麼IP層就會進行分片，把數據包分紅託乾片，讓每一片都不超過MTU。注意，IP分片能夠發生在原始發送端主機上，也能夠發生在中間路由器上。

 

TCP粘包和拆包的解決策略

  1. 消息定長。例如100字節。
  2. 在包尾部增長回車或者空格符等特殊字符進行分割，典型的如FTP協議
  3. 將消息分爲消息頭和消息尾。
  4. 其它複雜的協議，如RTMP協議等。

 

三次握手

第一次握手：創建鏈接時，客戶端發送syn包(syn=j)到服務器，並進入SYN_SEND狀態，等待服務器確認；

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

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

完成三次握手，客戶端與服務器開始傳送數據

 

四次揮手

  1. 客戶端先發送FIN，進入FIN_WAIT1狀態
  2. 服務端收到FIN，發送ACK，進入CLOSE_WAIT狀態，客戶端收到這個ACK，進入FIN_WAIT2狀態
  3. 服務端發送FIN，進入LAST_ACK狀態
  4. 客戶端收到FIN，發送ACK，進入TIME_WAIT狀態，服務端收到ACK，進入CLOSE狀態

TIME_WAIT的狀態就是主動斷開的一方（這裏是客戶端），發送完最後一次ACK以後進入的狀態。而且持續時間還挺長的。客戶端TIME_WAIT持續2倍MSL時長，在linux體系中大概是60s，轉換成CLOSE狀態

TIME_WAIT

TIME_WAIT 是主動關閉連接時造成的，等待2MSL時間，約4分鐘。主要是防止最後一個ACK丟失。 因爲TIME_WAIT 的時間會很是長，所以server端應儘可能減小主動關閉鏈接

CLOSE_WAIT

CLOSE_WAIT是被動關閉鏈接是造成的。根據TCP狀態機，服務器端收到客戶端發送的FIN，則按照TCP實現發送ACK，所以進入CLOSE_WAIT狀態。但若是服務器端不執行close()，就不能由CLOSE_WAIT遷移到LAST_ACK，則系統中會存在不少CLOSE_WAIT狀態的鏈接。此時，多是系統忙於處理讀、寫操做，而未將已收到FIN的鏈接，進行close。此時，recv/read已收到FIN的鏈接socket，會返回0。

爲何須要 TIME_WAIT 狀態？

假設最終的ACK丟失，server將重發FIN，client必須維護TCP狀態信息以即可以重發最終的ACK，不然會發送RST，結果server認爲發生錯誤。TCP實現必須可靠地終止鏈接的兩個方向(全雙工關閉)，client必須進入 TIME_WAIT 狀態，由於client可能面 臨重發最終ACK的情形。

爲何 TIME_WAIT 狀態須要保持 2MSL 這麼長的時間？

若是 TIME_WAIT 狀態保持時間不足夠長(好比小於2MSL)，第一個鏈接就正常終止了。第二個擁有相同相關五元組的鏈接出現，而第一個鏈接的重複報文到達，干擾了第二個鏈接。TCP實現必須防止某個鏈接的重複報文在鏈接終止後出現，因此讓TIME_WAIT狀態保持時間足夠長(2MSL)，鏈接相應方向上的TCP報文要麼徹底響應完畢，要麼被 丟棄。創建第二個鏈接的時候，不會混淆。

TIME_WAIT 和CLOSE_WAIT狀態socket過多

若是服務器出了異常，百分之八九十都是下面兩種狀況：

1.服務器保持了大量TIME_WAIT狀態

2.服務器保持了大量CLOSE_WAIT狀態，簡單來講CLOSE_WAIT數目過大是因爲被動關閉鏈接處理不當致使的。

 

一次完整的HTTP請求過程

域名解析 --> 發起TCP的3次握手 --> 創建TCP鏈接後發起http請求 --> 服務器響應http請求，瀏覽器獲得html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶

 

講一下長鏈接

1、基於http協議的長鏈接

  1. 在HTTP1.0和HTTP1.1協議中都有對長鏈接的支持。其中HTTP1.0須要在request中增長」Connection： keep-alive「 header纔可以支持，而HTTP1.1默認支持.
  • http1.0請求與服務端的交互過程:
  1. 客戶端發出帶有包含一個header：」Connection： keep-alive「的請求
  2. 服務端接收到這個請求後,根據http1.0和」Connection： keep-alive「判斷出這是一個長鏈接,就會在response的header中也增長」Connection： keep-alive「,同是不會關閉已創建的tcp鏈接.
  3. 客戶端收到服務端的response後,發現其中包含」Connection： keep-alive「，就認爲是一個長鏈接，不關閉這個鏈接。並用該鏈接再發送request.轉到a)

2、發心跳包。每隔幾秒就發一個數據包過去

 

TCP如何保證可靠傳輸？

  1. 三次握手。
  2. 將數據截斷爲合理的長度。應用數據被分割成 TCP 認爲最適合發送的數據塊（按字節編號，合理分片）
  3. 超時重發。當 TCP 發出一個段後，它啓動一個定時器，若是不能及時收到一個確認就重發
  4. 對於收到的請求，給出確認響應
  5. 校驗出包有錯，丟棄報文段，不給出響應
  6. 對失序數據進行從新排序，而後才交給應用層
  7. 對於重複數據 ， 可以丟棄重複數據
  8. 流量控制。TCP 鏈接的每一方都有固定大小的緩衝空間。TCP 的接收端只容許另外一端發送接收端緩衝區所能接納的數據。這將防止較快主機導致較慢主機的緩衝區溢出。
  9. 擁塞控制。當網絡擁塞時，減小數據的發送。

 

詳細介紹http

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。

特色

  1. 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

  2. 靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

  3. 無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

  4. 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

  5. 支持B/S及C/S模式。

請求消息Request

  1. 請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本.
  2. 請求頭部，緊接着請求行（即第一行）以後的部分，用來講明服務器要使用的附加信息從第二行起爲請求頭部，HOST將指出請求的目的地.User-Agent,服務器端和客戶端腳本都能訪問它,它是瀏覽器類型檢測邏輯的重要基礎.該信息由你的瀏覽器來定義,而且在每一個請求中自動發送等等
  3. 空行，請求頭部後面的空行是必須的
  4. 請求數據也叫主體，能夠添加任意的其餘數據。

響應消息Response

  1. 狀態行，由HTTP協議版本號， 狀態碼， 狀態消息 三部分組成。
  2. 消息報頭，用來講明客戶端要使用的一些附加信息
  3. 空行，消息報頭後面的空行是必須的
  4. 響應正文，服務器返回給客戶端的文本信息。

狀態碼

  • 200 OK //客戶端請求成功
  • 301 Moved Permanently //永久重定向,使用域名跳轉
  • 302 Found // 臨時重定向,未登錄的用戶訪問用戶中心重定向到登陸頁面
  • 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解
  • 401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用
  • 403 Forbidden //服務器收到請求，可是拒絕提供服務
  • 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
  • 500 Internal Server Error //服務器發生不可預期的錯誤
  • 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常

http的方法

  1. get:客戶端向服務端發起請求，得到資源。請求得到URL處所在的資源。
  2. post:向服務端提交新的請求字段。請求URL的資源後添加新的數據。
  3. head:請求獲取URL資源的響應報告，即得到URL資源的頭部
  4. patch：請求局部修改URL所在資源的數據項
  5. put：請求修改URL所在資源的數據元素。
  6. delete：請求刪除url資源的數據

 

URI和URL的區別

URI，是uniform resource identifier，統一資源標識符，用來惟一的標識一個資源。Web上可用的每種資源如HTML文檔、圖像、視頻片斷、程序等都是一個來URI來定位的

URI通常由三部組成：

  1. 訪問資源的命名機制
  2. 存放資源的主機名
  3. 資源自身的名稱，由路徑表示，着重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL能夠用來標識一個資源，並且還指明瞭如何locate這個資源。URL是Internet上用來描述信息資源的字符串，主要用在各類WWW客戶程序和服務器程序上，特別是著名的Mosaic。採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄等。

URL通常由三部組成：

  1. 協議(或稱爲服務方式)
  2. 存有該資源的主機IP地址(有時也包括端口號)
  3. 主機資源的具體地址。如目錄和文件名等

 

HTTPS和HTTP的區別

  1. https協議須要到CA申請證書，通常免費證書不多，須要交費。
  2. http是超文本傳輸協議，信息是明文傳輸；https 則是具備安全性的ssl加密傳輸協 議。
  3. http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
  4. http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
  5. http默認使用80端口，https默認使用443端口

 

https是如何保證數據傳輸的安全

https實際就是在TCP層與http層之間加入了SSL/TLS來爲上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與服務器的數據加密傳輸，最終達到保證整個通訊的安全性。

  • SSL/TLS協議做用：
  1. 認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
  2. 加密數據以防止數據中途被竊取；
  3. 維護數據的完整性，確保數據在傳輸過程當中不被改變。

 

PS：若是以爲個人分享不錯，歡迎你們隨手點贊、轉發。

以上即是這次分享的面試題以及答案，若是以爲還不過癮，你們能夠關注個人公衆號-【Java爛豬皮】，裏面有往期的面試題以及最新的面試分享，關注後回覆：【666】便可免費獲取更多的Java架構進階vip學習資料

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程