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ù)?，它的基本原理就是每發(fā)完一個分組就停止發(fā)送，等待對方確認（回復(fù)ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發(fā)送成功，需要重新發(fā)送，直到收到確認后再發(fā)下一個分組。

在停止等待協(xié)議中，若接收方收到重復(fù)分組，就丟棄該分組，但同時還要發(fā)送確認。

優(yōu)缺點：

• 優(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) 確認丟失和確認遲到

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

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

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

優(yōu)缺點：

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

2、HTTPS的加密、解密的過程

​ 我們都知道HTTPS能夠加密信息，以免敏感信息被第三方獲取。所以很多銀行網(wǎng)站或電子郵箱等等安全級別較高的服務(wù)都會采用HTTPS 協(xié)議。HTTPS其實是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)。

1. 客戶端發(fā)起HTTPS請求

這個沒什么好說的，就是用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。

2. 服務(wù)端的配置

采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請。區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務(wù))。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然后發(fā)給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那么就生成一個隨即值。然后用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內(nèi)容。

5. 傳送加密信息

這部分傳送的是用證書加密后的隨機值，目的就是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務(wù)段解密信息

服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內(nèi)容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種算法混合在一起，這樣除非知道私鑰，不然無法獲取內(nèi)容，而正好客戶端和服務(wù)端都知道這個私鑰，所以只要加密算法夠彪悍，私鑰夠復(fù)雜，數(shù)據(jù)就夠安全。

7. 傳輸加密后的信息

這部分信息是服務(wù)段用私鑰加密后的信息，可以在客戶端被還原

8. 客戶端解密信息

客戶端用之前生成的私鑰解密服務(wù)段傳過來的信息，于是獲取了解密后的內(nèi)容。整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。

總結(jié)：

HTTPS 之所以保證數(shù)據(jù)可以安全保密傳輸，就是在建立 TCP 三次握手之后，還需要進行一次 SSL/TCL 加解密流程：（包含對稱加密和非對稱加密）

• 客戶使用 https 的URL訪問Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
• 首先服務(wù)器端需要向 CA 申請證書（其實就是一對公鑰和私鑰），然后服務(wù)端將私鑰保留，將公鑰發(fā)送給客戶端。
• 客戶端收到公鑰后，先對公鑰進行驗證（判斷是否過期，頒發(fā)機構(gòu)是否存在等）。如果公鑰驗證合法，則客戶端生成一個 隨機值（作為對稱加密的密鑰），并將其通過公鑰加密后傳遞給服務(wù)器端。
• 服務(wù)器端收到這個 被公鑰加密的隨機值 后，使用私鑰對其進行解密，獲取這一隨機值。之后，客戶端和服務(wù)器端進行數(shù)據(jù)通信時，就可以通過這一隨機值作為密鑰，對稱加密解密要傳輸?shù)臄?shù)據(jù)?。ㄋ^對稱加密就是，將信息和密鑰通過某種算法混合在一起，這樣除非知道密鑰，不然無法獲取傳輸?shù)膬?nèi)容）

什么是數(shù)字證書？

作用：解決身份認證問題。

過程：借助第三方權(quán)威機構(gòu) CA（數(shù)字證書認證機構(gòu)），將服務(wù)器公鑰放在數(shù)字證書（由數(shù)字證書認證機構(gòu)辦法）中，只要證書是可信的，公鑰就是可信的。

3、深入理解三次握手、四次揮手流程

兩張動圖--帶你搞懂TCP的三次握手與四次揮手

4、Spring AOP 如何實現(xiàn)（實現(xiàn)原理）

Sprign AOP 本質(zhì)是通過動態(tài)代理來實現(xiàn)的（JDK動態(tài)代理、CGLIB動態(tài)代理），利用截取消息的方式，對該消息進行裝飾，以取代原有對象。主要有以下幾個步驟。

1、獲取增強器，(例如被 Aspect 注解修飾的類)。

2、在創(chuàng)建每一個 bean 時，會檢查是否有增強器能應(yīng)用于這個 bean，簡單理解就是該 bean 是否在該增強器指定的 execution 表達式中。如果是，則將增強器作為攔截器參數(shù)，使用動態(tài)代理創(chuàng)建 bean 的代理對象實例。

3、當我們調(diào)用被增強過的 bean 時，就會走到代理類中，從而可以觸發(fā)增強器，本質(zhì)跟攔截器類似。

Spring 的 AOP 有哪幾種創(chuàng)建代理的方式?

Spring 中的 AOP 目前支持 JDK 動態(tài)代理和 Cglib 代理。

通常來說：如果被代理對象實現(xiàn)了接口，則使用 JDK 動態(tài)代理，否則使用 Cglib 代理。另外，也可以通過指定 proxyTargetClass=true 來實現(xiàn)強制走 Cglib 代理。

JDK 動態(tài)代理和 Cglib 代理的區(qū)別?

1、JDK 動態(tài)代理本質(zhì)上是實現(xiàn)了被代理對象的接口，而 Cglib 本質(zhì)上是繼承了被代理對象，覆蓋其中的方法。

2、JDK 動態(tài)代理只能對實現(xiàn)了接口的類生成代理，Cglib 則沒有這個限制。但是 Cglib 因為使用繼承實現(xiàn)，所以 Cglib 無法代理被 final 修飾的方法或類。

3、在調(diào)用代理方法上，JDK 是通過反射機制調(diào)用，Cglib是通過FastClass 機制直接調(diào)用。FastClass 簡單的理解，就是使用 index 作為入?yún)?，可以直接定位到要調(diào)用的方法直接進行調(diào)用。

4、在性能上，JDK1.7 之前，由于使用了 FastClass 機制，Cglib 在執(zhí)行效率上比 JDK 快，但是隨著 JDK 動態(tài)代理的不斷優(yōu)化，從 JDK 1.7 開始，JDK 動態(tài)代理已經(jīng)明顯比 Cglib 更快了。

5、摘要算法：HTTPS如何方式數(shù)據(jù)發(fā)生了篡改？

作用：防止數(shù)據(jù)被篡改。

摘要算法：實現(xiàn)數(shù)據(jù)完整性，能夠為數(shù)據(jù)生成獨一無二的指紋，指紋用于校驗數(shù)據(jù)的完整性，解決了被篡改的風險。

過程

1、客戶端發(fā)送明文前，會通過摘要算法算出明文的指紋，發(fā)送時明文和指紋一同加密，發(fā)送給服務(wù)器。

2、服務(wù)器解密后，用相同的摘要算法算出發(fā)送過來的明文，通過比較客戶端攜帶的指紋和當前指紋做比較，若相同，則說明數(shù)據(jù)是完整的。

6、介紹一下JVM運行時數(shù)據(jù)區(qū)：堆與棧

JVM棧：

JVM棧是線程私有的，每個線程創(chuàng)建的同時都會創(chuàng)建JVM棧，JVM棧中存放的為當前線程中局部基本類型的變量（java中定義的八種基本類型：boolean、char、byte、short、int、long、float、double）， 非基本類型的對象在JVM棧上僅存放一個指向堆上的引用地址，JVM棧的空間是在物理內(nèi)存上分配的，而不是從堆上分配。 由于JVM棧是線程私有的，因此其在內(nèi)存分配上非常高效，并且當線程運行完畢后，這些內(nèi)存也就被自動回收。 當JVM棧的空間不足時，會拋出 StackOverflowError 的錯誤，可以通過 -Xss 來指定棧的大小

堆（Heap） ：

Heap是大家最為熟悉的區(qū)域，它是JVM用來存儲對象實例以及數(shù)組值的區(qū)域，可以認為Java中所有通過 new 創(chuàng)建的對象的內(nèi)存都在此分配， Heap中的對象的內(nèi)存需要等待GC進行回收，Heap在 32 位的操作系統(tǒng)上最大為 2G ，在 64 位的操作系統(tǒng)上則沒有限制， 其大小通過 -Xms 和 -Xmx 來控制，-Xms 為JVM啟動時申請的最小Heap內(nèi)存，默認為物理內(nèi)存的 1/64 但小于 1G，-Xmx 為JVM可申請的最大Heap內(nèi)存，默認為物理內(nèi)存的 1/4 ，默認當空余堆內(nèi)存小于 40% 時，JVM會增大Heap的大小到 -Xmx 指定的大小 ，可通過 -XX:MinHeapFreeRatio= 來指定這個比例，當空余堆內(nèi)存大于 70% 時，JVM會將Heap的大小往 -Xms 指定的大小調(diào)整，可通過 -XX:MaxHeapFreeRatio= 來指定這個比例， 但對于運行系統(tǒng)而言，為了避免頻繁的Heap Size的大小，通常都會將 -Xms 和 -Xmx 的值設(shè)成一樣，因此這兩個用于調(diào)整比例的參數(shù)通常是沒用的。其實jvm中對于堆內(nèi)存的分配、使用、管理、收集等有更為精巧的設(shè)計，具體可以在JVM堆內(nèi)存分析中進行詳細介紹。 當堆中需要使用的內(nèi)存超過其允許的大小時，會拋出 OutOfMemory 的錯誤信息。

7、強引用，軟引用和弱引用的區(qū)別？

在JDK 1.2之后，Java對引用的概念進行了擴充，將引用分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）四種，這四種引用強度依次逐漸減弱。

• 強引用就是指在程序代碼之中普遍存在的，類似 Object obj = new Object() 這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象。
• 軟引用用來描述一些還有用，但并非必需的對象。對于軟引用關(guān)聯(lián)著的對象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會把這些對象列進回收范圍之中并進行第二次回收。如果這次回收還是沒有足夠的內(nèi)存，才會拋出內(nèi)存溢出異常。 在JDK 1.2之后，提供了 SoftReference 類來實現(xiàn)軟引用。
• 弱引用也是用來描述非必需對象的，但是它的強度比軟引用更弱一些，被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾收集發(fā)生之前。當垃圾收集器工作時，無論當前內(nèi)存是否足夠，都會回收掉只被弱引用關(guān)聯(lián)的對象。 在JDK 1.2之后，提供了 WeakReference 類來實現(xiàn)弱引用。
• 虛引用也稱為幽靈引用或者幻影引用，它是最弱的一種引用關(guān)系。一個對象是否有虛引用的存在，完全不會對其生存時間構(gòu)成影響，也無法通過虛引用來取得一個對象實例。 為一個對象設(shè)置虛引用關(guān)聯(lián)的唯一目的就是希望能在這個對象被收集器回收時收到一個系統(tǒng)通知。在JDK 1.2之后，提供了 PhantomReference 類來實現(xiàn)虛引用

8、如何減少線程的上下文切換？

多線程競爭時，會引起上下文切換。

• 無鎖并發(fā)編程：用一些辦法來避免使用鎖，如將數(shù)據(jù)的ID按照Hash取模分段，不同線程處理不同段數(shù)據(jù)。
• CAS算法：Java的Atomic包使用CAS算法來更新數(shù)據(jù)，而不需加鎖。
• 使用最少線程：避免創(chuàng)建不需要的線程。
• 協(xié)程：在單線程里實現(xiàn)多任務(wù)的調(diào)度，維持多任務(wù)間的切換。

9、操作系統(tǒng)進程的調(diào)度策略

為了確定首先執(zhí)行哪個進程以及最后執(zhí)行哪個進程以實現(xiàn)最大 CPU 利用率，計算機科學家已經(jīng)定義了一些算法，它們是：

• 先到先服務(wù)(FCFS)調(diào)度算法 : 從就緒隊列中選擇一個最先進入該隊列的進程為之分配資源，使它立即執(zhí)行并一直執(zhí)行到完成或發(fā)生某事件而被阻塞放棄占用 CPU 時再重新調(diào)度。
• 短作業(yè)優(yōu)先(SJF)的調(diào)度算法 : 從就緒隊列中選出一個運行時間最短的進程為之分配資源，使它立即執(zhí)行并一直執(zhí)行到完成或發(fā)生某事件而被阻塞放棄占用 CPU 時再重新調(diào)度。
• 缺點：僅照顧了短進程而忽略了長進程。
• 時間片輪轉(zhuǎn)調(diào)度算法 : 時間片輪轉(zhuǎn)調(diào)度是一種最古老，最簡單，最公平且使用最廣的算法，又稱 RR(Round robin)調(diào)度。每個進程被分配一個時間片，時間片用盡則退出對CPU資源的使用。
• 優(yōu)先級調(diào)度 ： 為每個進程分配優(yōu)先級，首先執(zhí)行具有最高優(yōu)先級的進程**，依此類推。**具有相同優(yōu)先級的進程以 FCFS 方式執(zhí)行。可以根據(jù)內(nèi)存要求，時間要求或任何其他資源要求來確定優(yōu)先級。
• 存在的主要問題是：低優(yōu)先級進程無窮等待CPU。
• 多級隊列調(diào)度算法：將就緒隊列分成多個獨立的隊列，每個隊列都有自己的調(diào)度算法，隊列之間采用固定優(yōu)先級搶占調(diào)度。其中，一個進程根據(jù)自身屬性被永久、固定地分配到一個隊列中。
• 多級反饋隊列調(diào)度算法 ：目前被公認的一種較好的進程調(diào)度算法，UNIX 操作系統(tǒng)采取的便是這種調(diào)度算法。與多級隊列調(diào)度算法相比，其允許進程在隊列之間移動：若進程使用過多CPU時間，那么它會被轉(zhuǎn)移到優(yōu)先級更低的隊列；在較低優(yōu)先級隊列等待時間過長的進程會被轉(zhuǎn)移到更高優(yōu)先級隊列，以防止饑餓發(fā)生。

10、什么是虛擬內(nèi)存？

虛擬內(nèi)存允許執(zhí)行任務(wù)的進程不必完全在內(nèi)存中。很多時候我們使用點開了很多占內(nèi)存的軟件，這些軟件占用的內(nèi)存可能已經(jīng)遠遠超出了我們電腦本身具有的物理內(nèi)存。 正是因為 虛擬內(nèi)存 的存在，通過 虛擬內(nèi)存 可以讓程序可以擁有超過系統(tǒng)物理內(nèi)存大小的可用內(nèi)存空間（把內(nèi)存擴展到硬盤空間）。

虛擬內(nèi)存的基本思想：

• 每個進程擁有獨立的地址空間，這個空間被分為大小相等的多個塊，稱為頁(Page)，每個頁都是一段連續(xù)的地址。
• 這些頁被映射到物理內(nèi)存，但并不是所有的頁都必須在內(nèi)存中才能運行程序。
• 當程序引用到一部分在物理內(nèi)存中的地址空間時，由硬件立刻進行必要的映射。
• 當程序引用到一部分不在物理內(nèi)存中的地址空間時，由操作系統(tǒng)負責將缺失的部分裝入物理內(nèi)存并重新執(zhí)行失敗的命令。
• 這樣，對于進程而言，邏輯上似乎有很大的內(nèi)存空間，實際上其中一部分對應(yīng)物理內(nèi)存上的一塊(稱為幀，通常頁和幀大小相等)，還有一些沒加載在內(nèi)存中的對應(yīng)在硬盤上

注意：

1、請求分頁系統(tǒng)、請求分段系統(tǒng)和請求段頁式系統(tǒng)都是針對虛擬內(nèi)存的，通過請求實現(xiàn)內(nèi)存與外存的信息置換。

2、如果虛擬內(nèi)存的頁并不存在于物理內(nèi)存中，會產(chǎn)生缺頁中斷，從磁盤中取得缺的頁放入內(nèi)存，如果內(nèi)存已滿，還會根據(jù)某種算法將磁盤中的頁換出。

頁面置換算法：

當發(fā)生缺頁中斷時，如果當前內(nèi)存中并沒有空閑的頁面，操作系統(tǒng)就必須在內(nèi)存選擇一個頁面將其移出內(nèi)存，以便為即將調(diào)入的頁面讓出空間。用來選擇淘汰哪一頁的規(guī)則叫做頁面置換算法，我們可以把頁面置換算法看成是淘汰頁面的規(guī)則。

• OPT 頁面置換算法（最佳頁面置換算法） ：最佳(Optimal, OPT)置換算法所選擇的被淘汰頁面將是以后永不使用的，或者是在最長時間內(nèi)不再被訪問的頁面,這樣可以保證獲得最低的缺頁率。但由于人們目前無法預(yù)知進程在內(nèi)存下的若千頁面中哪個是未來最長時間內(nèi)不再被訪問的，因而該算法無法實現(xiàn)。一般作為衡量其他置換算法的方法。
• FIFO（First In First Out） 頁面置換算法（先進先出頁面置換算法） : 總是淘汰最先進入內(nèi)存的頁面，即選擇在內(nèi)存中駐留時間最久的頁面進行淘汰。
• LRU （Least Currently Used）頁面置換算法（最近最久未使用頁面置換算法） ：LRU算法賦予每個頁面一個訪問字段，用來記錄一個頁面自上次被訪問以來所經(jīng)歷的時間 T，當須淘汰一個頁面時，選擇現(xiàn)有頁面中其 T 值最大的，即最近最久未使用的頁面予以淘汰。
• LFU （Least Frequently Used）頁面置換算法（最少使用頁面置換算法） : 該置換算法選擇在之前時期使用次數(shù)最少的頁面作為淘汰頁。

虛擬內(nèi)存的應(yīng)用與優(yōu)點：

適合多道程序設(shè)計系統(tǒng)，許多程序的片段同時保存在內(nèi)存中。

當一個程序等待它的一部分讀入內(nèi)存時，可以把CPU交給另一個進程使用。

優(yōu)點：

1、在內(nèi)存中可以保留多個進程，系統(tǒng)并發(fā)度提高。 2、解除了用戶與內(nèi)存之間的緊密約束，進程可以比內(nèi)存的全部空間還大。

局部性原理：

(1) 時間上的局部性：最近被訪問的頁在不久的將來還會被訪問。

(2) 空間上的局部性：內(nèi)存中被訪問的頁周圍的頁也很可能被訪問。

總結(jié)

本篇文章就到這里了，希望可以給你帶來一些幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！