Java面試題 -網絡

1. TCP建⽴連接的過程

三次握⼿：

1. 第⼀次握⼿(客戶端發送syn包到服務器端)：客戶端發送syn包到服務器端，進⼊syn_send狀態，等待服務器端的確認；
2. 第⼆次握⼿(服務器返回syn+ack包給客戶端)：服務器端收到客戶端的syn包，發送syn+ack包給客戶端，進⼊syn_recv狀態；
3. 第三次握⼿(客服端返回ack包給服務端)：客戶端收到服務器端的syn+ack包，發送個ack包到服務器端，⾄此，客戶端與服務器端進⼊established狀態；
4. 握⼿過程中傳送的包不包含任何數據，連接建⽴後纔會開始傳送數據，理想狀態下，TCP連接⼀旦建⽴，在通信雙⽅的任何⼀⽅主動關閉連接前，TCP連接都會⼀直保持下去。

2. TCP斷開連接的過程

四次ഀ⼿：

1. 第一次揮⼿：主動關閉⽅發送fin包到被動關閉⽅，告訴被動關閉⽅我不會再給你發送數據了；
2. 第⼆次揮⼿：被動關閉⽅收到syn包，發送ack給對⽅，確認序號爲收到序號+1；
3. 第三次揮⼿：被動關閉⽅也也發送fin包給主動關閉⽅，告訴對⽅我也不會給你發送數據了；
4. 第四次揮⼿：主動關閉⽅收到syn包，發送ack給對⽅，⾄此，完成四次揮⼿；

3. 瀏覽器發⽣302跳轉背後的邏輯？

瀏覽器在原請求地址的響應的Location域找到要跳轉的URI執⾏跳轉。

瀏覽器輸⼊URL後發⽣了什麼：

1. DNS域名解析；
2. 建⽴TCP連接；
3. 發送HTTP請求；
4. 服務器處理請求；
5. 返回響應結果；
6. 關閉TCP連接；
7. 瀏覽器解析HTML；
8. 瀏覽器佈局渲染；

4. HTTP協議的交互流程。 HTTP和HTTPS的差異， SSL的交互流程？

Http協議：

1. 建⽴TCP連接；
2. 發送HTTP請求；
3. 服務器處理請求；
4. 返回響應結果；
5. 關閉TCP連接；

http三次握⼿：

第⼀次握⼿：客戶端發送syn包(syn=j)到服務器，並進⼊SYN_SEND狀態，等待服務器確認；

第⼆次握⼿：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時⾃⼰也發送⼀個SYN包（syn=k），即SYN+ACK包，此時服務器進⼊SYN_RECV狀態；

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

HTTPS協議：

• HTTPS協議就是基於SSL的HTTP協議
• HTTPS使⽤與HTTP不同的端⼝（HTTPS80 ， HTTPSS443）提供了身份驗證與加密通信⽅法，被⼴泛⽤於互聯⽹上安全敏感的通信。

1.客戶端請求SSL連接，並將⾃⼰⽀持的加密規則發給⽹站。

2.服務器端將⾃⼰的身份信息以證書形式發回給客戶端。證書⾥⾯包含了⽹站地址，加密公鑰，以及證書的頒發機構。

3.獲得證書後，客戶要做以下⼯作

• 驗證證書合法性
• 如果證書受信任，客戶端會⽣成⼀串隨機數的密碼，並⽤證書提供的公鑰進⾏加密。
  將加密好的隨機數發給服務器。

4.獲得到客戶端發的加密了的隨機數之後，服務器⽤⾃⼰的私鑰進⾏解密，得到這個隨機數，把這個隨機數作爲對稱加密的密鑰。（利⽤⾮對稱加密傳輸對稱加密的密鑰）

5.之後服務器與客戶之間就可以⽤隨機數對各⾃的信息進⾏加密，解密。

注意的是：證書是⼀個公鑰，這個公鑰是進⾏加密⽤的。⽽私鑰是進⾏解密⽤的。公鑰任何都知道，私鑰只有⾃⼰知道。這是⾮對稱加密。⽽對稱加密就是鑰匙只有⼀把，我們都知道。之所以⽤到對稱加密，是因爲對稱加密的速度更快。⽽⾮對稱加密的可靠性更⾼。

流程：客戶端請求–服務端發送證書（公鑰）–客戶端驗證證書，並⽣成隨機數，通過公鑰加密後發送給服務端–服務端⽤私鑰解密出隨機數–對稱加密傳輸數據。

HTTP與HTTPS的區別：

1. HTTPS協議需要申請證書。
2. HTTP是明⽂傳輸；HTTPS使⽤的是具有安全性的SSL加密傳輸協議
3. HTTP端⼝是80；HTTPS端⼝號是443
4. HTTP連接簡單⽆狀態；HTTPS由SSL+HTTP協議構件的可進⾏加密傳輸、身份驗證的⽹絡協議。

5. Rest和Http什麼關係？⼤家都說Rest很輕置，你對Rest⻛格如何理解?

Http是⼀種協議，Rest是⼀種軟件架構⻛格。

URL定位資源，⽤HTTP動詞（GET,POST,DELETE,DETC）描述操作。

GET表示查詢、POST表示新建、PUT表示更新、DELETE表示刪除等。

• GET /api/v1/user 獲取⽤戶列表
• GET /api/v1/user/1 獲取ID爲1的⽤戶
• POST /api/v1/user 新建⽤戶
• PUT /api/v1/user/1 更新ID爲1的⽤戶信息
• DELETE /api/v1/user/1 刪除ID爲1的⽤戶

1、概念：REST（英⽂：Representational State Transfer，簡稱REST，表現層狀態轉化），指的是⼀組架構約束條件和原則。滿⾜這些約束條件和原則的應⽤程序或設計就是 RESTful。

2、⼀種軟件架構⻛格，設計⻛格⽽不是標準，只是提供了⼀組設計原則和約束條件。它主要⽤於客戶端和服務器交互類的軟件。基於這個⻛格設計的軟件可以更簡潔，更有層次，更易於實現緩存等機制。

3、Restful架構：

1. 每⼀個URI代表⼀種資源；
2. 客戶端和服務器之間，傳遞這種資源的某種表現層；
3. 客戶端通過四個HTTP動詞(GET⽤來獲取資源，POST⽤來新建資源（也可以⽤於更新資源），PUT⽤來更新資源，DELETE⽤來刪除資源。)，對服務器端資源進⾏操作，實現"表現層狀態轉化”。

6. TCP的滑動窗⼝協議有什麼⽤？講講原理。

滑動窗⼝協議是傳輸層進⾏流控的⼀種措施，接收⽅通過通告發送⽅⾃⼰的窗⼝⼤⼩，從⽽控制發送⽅的發送速度，從⽽達到防⽌發送⽅發送速度過快⽽導致來不及接受。

7. HTTP協議都有哪些⽅法？

1. GET 請求獲取由Request-URI所標識的資源。
2. POST 在Request-URI所標識的資源後附加新的數據。
3. HEAD 請求獲取由Request-URI所標識的資源的響應消息報頭。
4. OPTIONS 請求查詢服務器的性能，或查詢與資源相關的選項和需
   求。
5. PUT 請求服務器存儲⼀個資源，並⽤Request-URI作爲其標識。
6. DELETE 請求服務器刪除由Request-URI所標識的資源。
7. TRACE 請求服務器回送收到的請求信息，主要⽤語測試或診斷。

8. 交換機與路由器的區別？

1、⼯作層次不同

• 最初的交換機⼯作在OSI模型中的數據鏈路層，⼯作原理簡單路由器⼯作在OSI模型中的⽹絡層，得更多協議信息，做更智能的轉發決策

2、數據轉發所依據的對象不同

• 交換機是利⽤物理地址（MAC地址），確定轉發的⽬的地址。（MAC固化硬件，⼀般不可更改）
• 路由器是利⽤IP地址，確定轉發的⽬的地址。（IP通常爲⽹關或系統⾃動分配的）

3、是否可以分割⼴播域

• 傳統的交換機可以分割衝突域，不能分割⼴播域，⽽路由器可以分割⼴播域
• 由交換機連接的⽹段仍然屬於同⼀⼴播域，⼴播數據報會在交換機連接的所有⽹段上傳播，某些情況導致通信擁೿和安全漏洞。連接到路由器上的⽹段被分配成不同的⼴播域，所以，⼴播數據不穿過路由器
• 雖然三層交換機可以分割⼴播域，但是⼦⼴播域之間不能通信，還是需要路由器

4、路由器提供了防⽕牆的服務

• 路由器僅僅轉發特定地址的數據包，不傳送不⽀持路由協議的數據包，不傳送未知⽬標⽹絡數據包，從⽽可以防⽌⼴播⻛暴。

5、表

• ⼆層交換機上存在MAC表，三層交換機上存在路由表、MAC表、ARP表，路由器上存在路由表和ARP表。
• 總之，交換機在具體的城域⽹中扮演着VLAN透傳的⻆⾊，就是橋。路由器的每⼀個端⼝都是⼀個獨⽴的⼴播域和衝突域，⽽交換機是隻有⼀個⼴播域和端⼝數量的衝突域。

9. Socket⽹絡通信、NIO流以及多線程處理技術，Netty、Mina？

1、socket⽹絡通信：（NIO流以及多線程處理技術）：

• BIO:阻塞式，線程池初始時創建⼀定量線程，超過則等待；
• NIO:⾮阻塞式，不同的線程⼲專業的事情，提⾼系統吞吐量；
• NIO+異步處理：讓少量的線程做⼤量的事情；

2、Mina：
Apache Mina是⼀個能夠幫助⽤戶開發⾼性能和⾼伸縮性⽹絡應⽤程序的框架。它通過Java nio技術基於TCP/IP和UDP/IP協議提供了抽象的、事件驅動的、異步的API。採⽤⾮阻塞⽅式的異步傳輸，⽀持批量傳輸數據。mina框架簡單⾼效，完成了底層的線程管理，內置
編碼器能夠滿⾜⼤多數⽤戶的需求，省去了消息編碼和解碼的⼯作。

3、Netty：
本質是JBoss開發的⼀個jar包，⽬的是開發⾼性能、⾼可靠性的⽹絡服務和客戶端服務；提供異步⾮阻塞的、事件驅動的⽹絡應⽤程序的NIO框架和⼯具；處理socket；通過Future-Listener機制，⽤戶可以⽅便的主動獲取或者通過通知機制獲得IO操作結果。

10. http協議（報⽂結構，斷點續傳，多線程下載，什麼是⻓連接）

概念：

• i. HTTP協議是Hyper Text Transfer Protocol（超⽂本傳輸協議）的縮寫,是⽤於從萬維⽹（WWW:World Wide Web ）服務器傳輸超⽂本到本地瀏覽器的傳送協議。
• ii. HTTP是⼀個基於TCP/IP通信協議來傳遞數據（HTML ⽂件, 圖⽚⽂件, 查詢結果等）。
• iii. HTTP是⼀個屬於應⽤層的⾯向對象的協議，由於其簡捷、快速的⽅式，適⽤於分佈式超媒體信息系統。它於1990年提出，經過⼏年的使⽤與發展，得到不斷地完善和擴展。⽬前在WWW中使⽤的是HTTP/1.0的第六版，HTTP/1.1的規範化⼯作正在進⾏之中，⽽且HTTP-NG(Next Generation of HTTP)的建議已經提出。
• iv. HTTP協議⼯作於客戶端-服務端架構爲上。瀏覽器作爲HTTP客戶端通過URL向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。

主要特點：

1. 簡單快速：客戶向服務器請求服務時，只需傳送請求⽅法和路徑。請求⽅法常⽤的有GET、HEAD、POST。每種⽅法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模⼩，因⽽通信速度很快。
2. 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
3. ⽆連接：⽆連接的含義是限制每次連接只處理⼀個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採⽤這種⽅式可以節省傳輸時間。
4. ⽆狀態：HTTP協議是⽆狀態協議。⽆狀態是指協議對於事務處理沒有記憶能⼒。缺少狀態意味着如果後續處理需要前⾯的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增⼤。另⼀⽅⾯，在服務器不需要先前信息時它的應答就較快。
5. ⽀持B/S及C/S模式。

11. get與post區別

1. 表單的method如果爲get,那麼所有的參數信息都會顯示在瀏覽器的地址欄，當我們使⽤瀏覽器地址欄輸⼊⽹址的⽅式來發送請求時,那麼該請求⼀定是get⽅式
2. 對於get⽅式,底層是將所有參數附加在請求資源的後⾯⼀起傳遞的，對於post⽅式,底層是將所有參數附加在請求參數的最後⼀⾏的下⼀⾏的下⼀⾏ Get請求的數據是被附在url之後（HTTP協議頭中），POST請求數據則放置在HTTP包的包體head中；
3. 對於get,post⽅式,servlet不同處理：doGet()，doPost();
4. 瀏覽器處理：重複訪問使⽤GET⽅法請求的⻚⾯，瀏覽器會使⽤緩存處理後續請求。使⽤POST⽅法的form提交時，瀏覽器基於POST將產⽣永久改變的假設，將讓⽤戶進⾏提交確認。

12. Nginx性能調優

1. 增加同時打開⽂件數open files數量；
2. 處理⼤量靜態⽂件的磁盤I/O時(此時worker進程是單線程的)，增加CPU核⼼數Worker Processes數量，提⾼計算能⼒；
3. 如果⽹站流量很⾼，則可以提升worker進程連接數Worker Connections(默認1024)；
4. 控制keep alive在10s-20s之間，減少連接的時間開銷；
5. 合理設置open file cache時間提⾼處理效率；
6. 提⾼⽹路帶寬；
7. 開啓壓縮傳輸數據gzip，設置壓縮級別gzip_comp_level爲1-2，再⾼效果不明顯並且浪費CPU了；
8. 擴展機器數量。

13. rpc和http的區別，使⽤場景：

<傳輸協議>

• RPC，可以基於TCP協議，也可以基於HTTP協議
• HTTP，基於HTTP協議

<傳輸效率>

• RPC，使⽤⾃定義的TCP協議，可以讓請求報⽂體積更⼩，或者使⽤HTTP2協議，也可以很好的減少報⽂的體積，提⾼傳輸效率
• HTTP，如果是基於HTTP1.1的協議，請求中會包含很多⽆⽤的內容，如果是基HTTP2.0，那麼簡單的封裝以下是可以作爲⼀個RPC來使⽤的，這時標準RPC框架更多的是服務治理

<性能消耗，主要在於序列化和反序列化的耗時>

• RPC，可以基於thrift實現⾼效的⼆進制傳輸
• HTTP，⼤部分是通過json來實現的，字節⼤⼩和序列化耗時都⽐thrift要更消耗性能

<負載均衡>

• RPC，基本都⾃帶了負載均衡策略
• HTTP，需要配置Nginx，HAProxy來實現

<服務治理（下游服務新增，重啓，下線時如何不影響上游調⽤者）>

• RPC，能做到⾃動通知，不影響上游
• HTTP，需要事先通知，修改Nginx/HAProxy配置

總結：RPC主要⽤於公司內部的服務調⽤，性能消耗低，傳輸效率⾼，服務治理⽅便。HTTP主要⽤於對外的異構環境，瀏覽器接⼝調⽤，APP接⼝調⽤，第三⽅接⼝調⽤等。