3C

標籤: 潭子電動車

  • 鼓勵民眾採用電動車，台延長免稅優惠五年

    鼓勵民眾採用電動車，台延長免稅優惠五年

    台灣現行的買電動車免徵貨物稅優惠原將於2017年一月底到期，但為推動民眾繼續採購電動車，政府通過修正草案，將貨物稅免徵優惠延長五年，希望能來5,000輛以上的採購。

    現行的電動車免徵貨物稅優惠適用於於純電動車。只要民眾購買純電力電動小客車且完成登記，該車輛在新台幣140萬元以下部分的貨物稅可享有免徵優惠，超過的部分則依照比例課稅。

    財政部推估，電動車貨物稅免徵推估可在2017~2022年的五年之間帶動5,939輛電動汽車、15萬輛電動機車的銷售量，將帶來24億元新台幣的稅損；但因銷售預期將增加，營業稅等稅收預計會增加43億元新台幣，一來一往下可創造新台幣19.55億元的稅收，並帶動943.99億元的相關產值。

    不過，立委對於財政部的推算並不樂觀。有立委表示，經濟部先前針對自用客車、中型巴士與大型巴士所推出的電動車免貨物稅措施，達成率不到2成。而目前台灣只有765輛電動汽車，5年免徵貨物稅優惠的目標，相當於需增加5,174輛才能達成。

    經濟部次長沈榮津回應，許多國家都對電動車有優惠扶植措施，台灣也順應此一潮流。成效不如預期的主因是車用電池的供應狀況仍不夠穩定，希望能透過稅務優惠帶動電動車需求成長，拉動電池產業。

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

    ※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

    ※教你寫出一流的銷售文案?

    ※聚甘新

  • 最新研究：全球「水塔」面臨多重威脅 喜馬拉雅列亞洲最脆弱

    摘錄自2019年12月10日中新網北京報導

    據中國科學院青藏高原研究所消息，括中國科學家在內的全球科學家對被稱為「水塔」—地球78個高山冰川水系統的最新研究評估顯示，全球「水塔」正面臨氣候變化、人口增長、水資源管理不善、其他地緣政治因素等多重威脅，形勢岌岌可危。

    這項最新評估研究由全球32位科學家合作撰寫，獲得中科院院士、冰川學家姚檀棟牽頭的中科院專項資助，並發表於《自然》期刊。

    地球78個基於高山冰川的水系統被稱為高山「水塔」，其通過冰川、積雪、湖泊和河流來儲藏與運送水，為全球19億人（約佔全球總人口的1/4）提供水資源。亞洲以印度河「水塔」受依賴度最高也最為脆弱，它由喜馬拉雅山脈的廣大地區組成，覆蓋阿富汗、中國、印度和巴基斯坦部分地區。

    姚檀棟提醒說，如果全球氣溫升幅超過攝氏2度，亞洲「水塔」氣溫則會劇增至4度，到2060-2070年會出現更大規模的冰川退卻。冰川消減後，以季節性冰川融水補給為主的河流能夠提供的淡水量也會隨之減少，下游地區人口可能會面臨淡水資源減少的問題。

    本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • 龍芯團隊完成CoreCLR MIPS64移植，已在github開源

    龍芯團隊完成CoreCLR MIPS64移植，已在github開源

    國產龍芯的軟件生態之中.NET不會缺席，畢竟 C# 與 .NetCore/Mono 也是全球幾大主流的編程語言和運行平台之一，最近一段時間聽到太多的鼓吹政務領域不支持.NET， 大家都明白這是某些人為了自己的利益打壓使用.NET技術的公司，我今天寫這篇文章就是想通過龍芯團隊的行動告訴更多人一起來推動.NET技術在中國的發展。希望龍芯廠商、支持龍芯的國產操作系統廠商能高度重視這個問題，主動加入 .Net Core 社區，加入.NET基金會，积極貢獻代碼，儘快做好適配工作。

    龍芯團隊一直在做net core的mips64移植工作，2020年6月18日完成了里程碑性的工作，在.NET Core 3.1分支上完成了MIPS64 的移植工作，目前已經在github上開源，開源地址：https://github.com/gsvm/coreclr 。具體說明可以參見 https://github.com/dotnet/runtime/issues/38069。 龍芯團隊正在做移植后的測試工作，已經完成了 9500 多項測試，ASP.NET Core示例程序 FlightFinder 已經可以在MIPS64 上正常運行，具體可以參看 https://github.com/dotnet/runtime/issues/4234。

    龍芯團隊還在github上面為龍芯.NET 建立了一個倉庫 https://github.com/gsvm/loongson-dotnet，用於關於龍芯的.NET信息，工作和下載，開源協議採用和.NET Core一樣的MIT協議。 根據這個倉庫的信息，龍芯團隊將在不久的將來發布.NET Core 3.1版本，然後升級到https://github.com/dotnet/runtime ，也就是.NET 5了。目前這項工作正在緊鑼密鼓的進行，非常歡迎大家的積极參与貢獻，包括issue或者PR，如果您有任何問題或需要任何支持，請隨時提交問題或通過电子郵件:aoqi@loongson.cn 與龍芯團隊聯繫。

    在文章的最後，我向你分享一個龍芯團隊成員 xiangzhai 在這個 https://github.com/xiangzhai/mono/issues/2 提到了指令集相關的編程的一些相關知識：

    OpenJDK、CorelCLR、mono都太大了，比較小的虛擬機例子可以看看PSP模擬器： https://github.com/xiangzhai/ppsspp-jit-mips64/commits/mips64-port-dev

    CoreCLR官方的文檔不錯：下降、寄存器分配、代碼生成 https://github.com/dotnet/runtime/blob/master/docs/design/coreclr/jit/ryujit-overview.md

    CoreCLR代碼生成常用調試方法： dotnet/runtime#606

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • Thunk函數的使用

    Thunk函數的使用

    編譯器的求值策略通常分為傳值調用以及傳名調用，Thunk函數是應用於編譯器的傳名調用實現，往往是將參數放到一個臨時函數之中，再將這個臨時函數傳入函數體，這個臨時函數就叫做Thunk 函數。

    求值策略

    編譯器的求值策略通常分為傳值調用以及傳名調用，在下面的例子中，將一個表達式作為參數進行傳遞，傳值調用以及傳名調用中實現的方式有所不同。

    var x = 1;

function s(y){
    console.log(y + 1); // 3
}

s(x + 1);

    在上述的例子中，無論是使用傳值調用還是使用傳名調用，執行的結果都是一樣的，但是其調用過程不同：

    • 傳值調用：首先計算x + 1，然後將計算結果2傳遞到s函數，即相當於調用s(2)。
    • 傳名調用：直接將x + 1表達式傳遞給y，使用時再計算x + 1，即相當於計算(x + 1) + 1。

    傳值調用與傳名調用各有利弊，傳值調用比較簡單，但是對參數求值的時候，實際上還沒用到這個參數，有可能造成沒有必要的計算。傳名調用可以解決這個問題，但是實現相對來說比較複雜。

    var x = 1;

function s(y){
    console.log(y + 1); // 3
}

s(x + 1, x + 2);

    在上面這個例子中，函數s並沒有用到x + 2這個表達式求得的值，使用傳名調用的話只將表達式傳入而並未計算，只要在函數中沒有用到x + 2這個表達式就不會計算，使用傳值調用的話就會首先將x + 2的值計算然後傳入，如果沒有用到這個值，那麼就多了一次沒有必要的計算。Thunk函數就是作為傳名調用的實現而構建的，往往是將參數放到一個臨時函數之中，再將這個臨時函數傳入函數體，這個臨時函數就叫做Thunk 函數。

    var x = 1;

function s(y){
    console.log(y + 1); // 3
}

s(x + 1);

// 等同於

var x = 1;

function s(thunk){
    console.log(thunk() + 1); // 3
}

var thunk = function(){
    return x + 1;
}

s(thunk);

    Js中的Thunk函數

    Js中的求值策略是是傳值調用，在Js中使用Thunk函數需要手動進行實現且含義有所不同，在Js中，Thunk函數替換的不是表達式，而是多參數函數，將其替換成單參數的版本，且只接受回調函數作為參數。

    // 假設一個延時函數需要傳遞一些參數
// 通常使用的版本如下
var delayAsync = function(time, callback, ...args){
    setTimeout(() => callback(...args), time);
}

var callback = function(x, y, z){
    console.log(x, y, z);
}

delayAsync(1000, callback, 1, 2, 3);

// 使用Thunk函數

var thunk = function(time, ...args){
    return function(callback){
        setTimeout(() => callback(...args), time);
    }
}

var callback = function(x, y, z){
    console.log(x, y, z);
}

var delayAsyncThunk = thunk(1000, 1, 2, 3);
delayAsyncThunk(callback);

    實現一個簡單的Thunk函數轉換器，對於任何函數，只要參數有回調函數，就能寫成Thunk函數的形式。

    var convertToThunk = function(funct){
  return function (...args){
    return function (callback){
      return funct.apply(this, args);
    }
  };
};

var callback = function(x, y, z){
    console.log(x, y, z);
}

var delayAsyncThunk = convertToThunk(function(time, ...args){
    setTimeout(() => callback(...args), time);
});

thunkFunct = delayAsyncThunk(1000, 1, 2, 3);
thunkFunct(callback);

    Thunk函數在ES6之前可能應用比較少，但是在ES6之後，出現了Generator函數，通過使用Thunk函數就可以可以用於Generator函數的自動流程管理。首先是關於Generator函數的基本使用，調用一個生成器函數並不會馬上執行它裏面的語句，而是返回一個這個生成器的迭代器iterator 對象，他是一個指向內部狀態對象的指針。當這個迭代器的next()方法被首次（後續）調用時，其內的語句會執行到第一個（後續）出現yield的位置為止，yield后緊跟迭代器要返回的值，也就是指針就會從函數頭部或者上一次停下來的地方開始執行到下一個yield。或者如果用的是yield*，則表示將執行權移交給另一個生成器函數（當前生成器暫停執行）。

    function* f(x) {
    yield x + 10;
    yield x + 20;
    return x + 30;
}
var g = f(1);
console.log(g); // f {<suspended>}
console.log(g.next()); // {value: 11, done: false}
console.log(g.next()); // {value: 21, done: false}
console.log(g.next()); // {value: 31, done: true}
console.log(g.next()); // {value: undefined, done: true} // 可以無限next()，但是value總為undefined，done總為true

    由於Generator函數能夠將函數的執行暫時掛起，那麼他就完全可以操作一個異步任務，當上一個任務完成之後再繼續下一個任務，下面這個例子就是將一個異步任務同步化表達，當上一個延時定時器完成之後才會進行下一個定時器任務，可以通過這種方式解決一個異步嵌套的問題，例如利用回調的方式需要在一個網絡請求之後加入一次回調進行下一次請求，很容易造成回調地獄，而通過Generator函數就可以解決這個問題，事實上async/await就是利用的Generator函數以及Promise實現的異步解決方案。

    var it = null;

function f(){
    var rand = Math.random() * 2;
    setTimeout(function(){
        if(it) it.next(rand);
    },1000)
}

function* g(){ 
    var r1 = yield f();
    console.log(r1);
    var r2 = yield f();
    console.log(r2);
    var r3 = yield f();
    console.log(r3);
}

it = g();
it.next();

    雖然上邊的例子能夠自動執行，但是不夠方便，現在實現一個Thunk函數的自動流程管理，其自動幫我們進行回調函數的處理，只需要在Thunk函數中傳遞一些函數執行所需要的參數比如例子中的index，然後就可以編寫Generator函數的函數體，通過左邊的變量接收Thunk函數中funct執行的參數，在使用Thunk函數進行自動流程管理時，必須保證yield后是一個Thunk函數。
    關於自動流程管理run函數，首先需要知道在調用next()方法時，如果傳入了參數，那麼這個參數會傳給上一條執行的yield語句左邊的變量，在這個函數中，第一次執行next時並未傳遞參數，而且在第一個yield上邊也並不存在接收變量的語句，無需傳遞參數，接下來就是判斷是否執行完這個生成器函數，在這裏並沒有執行完，那麼將自定義的next函數傳入res.value中，這裏需要注意res.value是一個函數，可以在下邊的例子中將註釋的那一行執行，然後就可以看到這個值是f(funct){...}，此時我們將自定義的next函數傳遞后，就將next的執行權限交予了f這個函數，在這個函數執行完異步任務后，會執行回調函數，在這個回調函數中會觸發生成器的下一個next方法，並且這個next方法是傳遞了參數的，上文提到傳入參數後會將其傳遞給上一條執行的yield語句左邊的變量，那麼在這一次執行中會將這個參數值傳遞給r1，然後在繼續執行next，不斷往複，直到生成器函數結束運行，這樣就實現了流程的自動管理。

    function thunkFunct(index){
    return function f(funct){
        var rand = Math.random() * 2;
        setTimeout(() => funct({rand:rand, index: index}), 1000)
    }
}

function* g(){ 
    var r1 = yield thunkFunct(1);
    console.log(r1.index, r1.rand);
    var r2 = yield thunkFunct(2);
    console.log(r2.index, r2.rand);
    var r3 = yield thunkFunct(3);
    console.log(r3.index, r3.rand);
}

function run(generator){
    var g = generator();

    var next = function(data){
        var res = g.next(data);
        if(res.done) return ;
        // console.log(res.value);
        res.value(next);
    }

    next();
}

run(g);

    每日一題

    https://github.com/WindrunnerMax/EveryDay

    參考

    https://www.jianshu.com/p/9302a1d01113
https://segmentfault.com/a/1190000017211798
http://www.ruanyifeng.com/blog/2015/05/thunk.html

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • Spring中基於xml的AOP

    Spring中基於xml的AOP

    1、Aop 全程是Aspect Oriented Programming 即面向切面編程，通過預編譯方式和運行期動態代理實現程序功能的同一維護的一種技術。Aop是oop的延續，是軟件開發中的 一個熱點，也是Spring框架中一個重要的內容。是函數式編程的一個衍生範例，利用Aop可以對業務邏輯各個部分進行分割，從而使得業務邏輯各部分之間的耦合度降低，提高程序的可重用行，提高了開發效率。簡單的說就是把我們程序中的重複代碼抽取出來，在需要執行的時候，使用動態代理的技術，在不修改源碼的基礎上已有的方法進行增強，（使用動態代理的方式實現）

    相關術語

    JoinPoint：鏈接點 那些被攔截到的點，在spring中，這些點指的是方法，因為spring只支持方法類型的連接點

    Pointcut：切入點   是指我們要對哪些JoinPont進行攔截的定義

    Advice：通知/增強  攔截到Joinpoint之後所要做的事情就是通知

    通知類型：前置通知、後置通知、異常通知、最終通知、環繞通知

    Introduction：引介   是一種特殊的通知，在不修改類代碼的前提下，Introduction可以在運行期為類動態的添加一些方法或field

    Target：目標對象，代理的目標對象

    Weaving 織入   是指把增強應用到目標對象來創建新的代理對象的過程，spring採用動態代理織入，而AspectJ採用編譯期織入和類裝載期織入

    Proxy：代理，一類類被Aop織入增強后，就產生一個結果代理類

    Aspect：切面   是切入點和通知（引介）的結合

    在 spring 中，框架會根據目標類是否實現了接口來決定採用哪種動態代理的方式。

    基於XMl的AOP步驟

    1、創建Maven項目引入spring坐標

    <?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.mingqi</groupId>
    <artifactId>SpringIOC</artifactId>
    <packaging>pom</packaging>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>5.0.2.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.aspectj</groupId>
            <artifactId>aspectjweaver</artifactId>
            <version>1.8.7</version>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

    2、創建業務層接口：

    package com.mingqi.services;
public interface IAccountService {
    /**
     * 模擬登陸賬戶
     */
    void saveAccount();

    /**
     * 模擬更新賬戶
     * @param id
     */
    void updateAccount(int id);

    /**
     * 模擬刪除賬戶
     * @return
     */
    int deleteAccount();

}

    3.創建業務層實現類

    package com.mingqi.services.impl;
import com.mingqi.services.IAccountService;
public class AccountServicesImpl implements IAccountService {
    public void saveAccount() {
        System.out.println("執行了保存");
    }

    public void updateAccount(int id) {
        System.out.println("執行了更新"+id);
    }

    public int deleteAccount() {
        System.out.println("執行了刪除");
        return 0;
    }
}

    4、創建工具類

    package com.mingqi.utils;
import org.aspectj.lang.ProceedingJoinPoint;
/**
 * 用戶記錄日誌的工具類，裏面提供公共的代碼
 */
public class Logger {
    /**
     * 用於打印日誌：計劃讓其在切入點方法執行前執行（切入點方法就是業務層方法）
     */
    public  void beforePrintLog(){
        System.out.println("Logger類中的pringLog方法開始記錄日誌了。。。");
    }
    public  void afterReturningPrintLog()
    {
        System.out.println("後置通知Logger類中的beforePrintLog方法開始記錄日誌了。。。");
    }
    /**
     * 異常通知
     */
    public void afterThrowingPrintLog()
    {
        System.out.println("異常通知Logger類中的afterThrowingPrintLog方法開始記錄日誌了。。。");

    }
    /**
     * 最終通知
     */
    public void afterPrintLog()
    {
        System.out.println("最終通知Logger類中的afterPrintLog方法開始記錄日誌了。。。");
    }

    /**
     * 環繞通知
     * 問題  當我們配置了環繞通知以後，切入點方法沒有執行，而通知方法執行了
     * 分析： 通過對比動態代理中的環繞通知代碼，發現動態代理中的環繞通知有明確的切入點方法調用，而我們的代碼中沒有
     * 解決： Spring 框架為我們提供了一個接口：ProceedingJoinPoint。該接口有一個方法proceed（），此方法就相當於明確調用切入點的方法
     *        該接口可以作為環繞通知的參數方法，在程序執行時，spring框架會為我們提供該接口的實現類供我們使用
     * spring中的環繞通知
     *      他是spring框架為我們提供的一種可以在代碼中手動控制增強方法何時會執行的方式
     * @param pjp
     * @return
     */
    public Object aroundPringLog(ProceedingJoinPoint pjp){
        Object rtValue = null;
        try{
            Object[] args = pjp.getArgs();//得到方法執行所需的參數

            System.out.println("Logger類中的aroundPringLog方法開始記錄日誌了。。。前置");

            rtValue = pjp.proceed(args);//明確調用業務層方法（切入點方法）

            System.out.println("Logger類中的aroundPringLog方法開始記錄日誌了。。。後置");

            return rtValue;
        }catch (Throwable t){
            System.out.println("Logger類中的aroundPringLog方法開始記錄日誌了。。。異常");
            throw new RuntimeException(t);
        }finally {
            System.out.println("Logger類中的aroundPringLog方法開始記錄日誌了。。。最終");
        }
    }
}

    4、創建bean配置文件

    <?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop.xsd">
       <!-- 配置spring的IOC，把service對象配置進來-->
       <bean id="accountSevice" class="com.mingqi.services.impl.AccountServicesImpl"></bean>
       <!-- spring 中基於xml的Aop配置步驟
         1、把通知Bean也交給spring來管理
         2、使用aop：config標籤表名開始aop的配置
         3、使用aop:aspect標籤表明配置切面
             id屬性：是給切面提供一個唯一標識
             ref屬性：是指定通知類的id
         4、在aop:aspect標籤的內部使用對應的標籤來配置通知的類型
             我們現在的示例是讓printlog方法在切入點方法執行之前執行，所以是前置通知
             aop:before:標識前置通知
                method屬性： 用於指定Logger類中的方法哪個是前置通知
                pointcut屬性： 用於指定切入點表達式，該表達式的含義指的是對業務層中的哪些方法增強
                切入點表達式的寫法：
                   關鍵字：execution（表達式）
                   表達式：  訪問修飾符 返回值 包名.包名.包名....類名.方法名(參數列表)
                   標準的寫法： public void com.mingqi.service.impl.AccountServiceImpl.saveAccount()
                   訪問修飾符可以省略：void com.mingqi.service.impl.AccountServiceImpl.saveAccount()
                   返回值可以使用通配符，標識任意返回值：* com.mingqi.service.impl.AccountServiceImpl.saveAccount()
                   包名可以使用通配符，表示任意包，但是有幾級包就需要寫幾個*  *.*.*.*.*.AccountServiceImpl.saveAccount()
                   包名可以使用..代表當前包及其子包：* *.AccountServiceImpl.saveAccount()
                   類名和方法名都可以使用*來實現統配 * *..*.*();
                   參數列表： 可以直接寫數據類型:
                                 基本類型直接寫名稱：int
                                 引用類型寫包名.類名的方式： java.lang.String
                                可以使用通配符來標識任意類型，單必須有參數
                                可以使用..標識有無參數均可，有參數可以是任意類型

                      全通配寫法：
                    * *..*.*(..)
                   實際開發中 切入點表達式的通常寫法：
                          切到業務層實現類的所有方法，* com.mingqi.service.impl.*.*(..);
         -->
       <!-- 配置Logger類-->
       <bean id="logger" class="com.mingqi.utils.Logger"></bean>
       <!--使用aop：config標籤表名開始aop的配置-->
       <aop:config>
              <aop:pointcut id="pt1" expression="execution(* com.mingqi.services.impl.*.*(..))"></aop:pointcut>
              <!--使用aop:aspect標籤表明配置切面-->
              <aop:aspect id="LogAdvice" ref="logger">
                     <!-- 配置前置通知：在切入點方法執行之前執行
                     <aop:before method="beforePrintLog" pointcut-ref="pt1"></aop:before>-->

                     <!-- 配置後置通知：在切入點方法正常執行之後值。它和異常通知永遠只能執行一個
                          <aop:after-returning method="afterReturningPrintLog" pointcut-ref="pt1"></aop:after-returning>-->
                     <!-- 配置異常通知：在切入點方法執行產生異常之後執行。它和後置通知永遠只能執行一個
                         <aop:after-throwing method="afterThrowingPrintLog" pointcut-ref="pt1"></aop:after-throwing>-->
                     <!-- 配置最終通知：無論切入點方法是否正常執行它都會在其後面執行
                        <aop:after method="afterPrintLog" pointcut-ref="pt1"></aop:after>-->
                     <!-- 配置環繞通知 詳細的註釋請看Logger類中-->
                        <aop:around method="aroundPringLog" pointcut-ref="pt1"></aop:around>
                    </aop:aspect>
             </aop:config>
       </beans>

    6、創建測試類

    package com.mingqi.test;
import com.mingqi.services.IAccountService;
import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class SpringIoc {
    @Test
    public void TestAccount()
    {
        ApplicationContext ac= new ClassPathXmlApplicationContext("beam.xml");
        IAccountService accountService=(IAccountService) ac.getBean("accountSevice");
        accountService.saveAccount();
        accountService.updateAccount(22);
        accountService.deleteAccount();
    }
}

     

     

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • Gogoro升級iQ System 智慧系統3.1，搭載韌體升級FOTA新功能

    Gogoro升級iQ System 智慧系統3.1，搭載韌體升級FOTA新功能

    Gogoro Smartscooter 智慧雙輪的車主們，將能再度感受到，他們擁有的不僅是一台電動機車，而是一部不斷進化的雙輪電腦！Gogoro 於16 日正式推出搭載最新功能的「iQ System 智慧系統3.1」，包含空中韌體升級FOTA（Firmware-Over-The-Air）服務。這項科技可讓車主自行利用智慧型手機及Gogoro App 進行遠程升級，只要有穩定的網路訊號，車主都可以DIY 自行操作，無需再花時間返回服務中心。

    Gogoro 產品企劃經理王光祖表示：「Gogoro 擁有最先進、穩定、安全的技術， 也是目前台灣二輪車市場中，唯一運用空中韌體升級FOTA 的品牌。Gogoro 的車主不但可以透過韌體更新，感受智慧雙輪的聰明程度，更可隨著技術與功能的改進而持續升級，時時感受車子越騎越新的快感。」

    這是繼Gogoro 去年11月初發表「iQ System 智慧系統3.0」後，更進一步的升級版本。重點在於提供更直覺、方便、有感的使用體驗，包括更長時間的高速騎乘，更充沛的爬坡動力，以及從容地面對天氣變化，是第一台可以針對嚴寒或酷熱的氣候有動態調配溫度保護機制的二輪機車。其中在爬坡動力的改進，目前已經有車主在臉書分享經驗。游先生提到：「一路到山頂都是以前從來沒有過的充沛動力感！」網友Alex Yeh 則表示：「車速感覺不會掉太多，還是會有充沛的動力上山！」

    此外，因應部分Gogoro 車主曾發生不小心將手機或智慧鑰匙鎖在置物廂中的問題，之前在「iQ System 智慧系統3.0」時，便已在Gogoro App 中增加「車廂開關設定」的選項，置物箱打開後若在90 秒內關上時，就可以自動解鎖。 此次更新則更加優化了這個貼心的功能，即使在交換電池後，只要在放回電池的90 秒內關上座墊，一樣會自動解鎖，不需再次掏出智慧鑰匙即可上路，讓交換電池的過程更加流暢。

    （合作媒體：。圖片出處：Gogoro）

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • 鋰電池原料暴漲，電動車產業受影響

    鋰電池原料暴漲，電動車產業受影響

    鋰電池關鍵材料鈷、鋰價格暴漲，令電池乃至電動車製造商成本控制面臨極大壓力。

    鈷的國際報價四月中旬來到每磅27.5美元，寫下八年新高記錄。從2017年初以來，鈷價累計漲幅達90%，對照一年之前，更是跳增2.5倍。根據主要交易機構官員表示，鈷的身價節節升高，主因需求看漲，市場預先囤貨所致。（日經新聞）

    另外，鋰價近兩年翻升約三倍，電池製造商的成本上漲壓力可以想見，這將進一步轉嫁至電動車製造商身上。據估計，鈷約佔電池製造成本的兩成。

    特斯拉大眾化電動車Model 3預計在今年稍晚量產，目前特斯拉已收到40萬輛預購訂單。除了特斯拉之外，日產新一代Leaf電動車也即將上市，這些均為鈷與鋰等電池材料提供炒作題材。

    （本文內容由授權使用。圖片出處：wikipedia）

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • 編碼的道與禪

    該文章發布在github中，如果您覺得寫的還不錯的話，可以 star 一下進行支持，傳送門：TechShare。

    Bob 大叔在《代碼整潔之道》一書的前言打趣着說，當你寫的代碼在經受代碼審查時，如果審查者憤怒的吼道“What the fuck is this shit?”等言辭激烈的詞語時，那說明你寫的是 Bad Code；如果審查者只是漫不經心的吐出幾個“What the fuck?”，那說明你寫的是 Good Code。這就是衡量代碼質量的唯一標準——每分鐘罵出“What the fuck?”的頻率。

    想寫出整潔的代碼很難，有一部分原因在於糟糕的代碼太容易編寫。想快點完成任務時，考慮不周全時，忽略安全時，隨意命名時，參數過多時，嵌套太深時，未及時更改註釋時，違反法則時，重複你自己時等等情形，我們有太多的機會來製造糟糕的代碼。只有嚴肅對待自己的代碼，了解哪些事情會使我們的代碼變味，才有可能寫出整潔的代碼。

    寫代碼和寫文章在某種程度上有相似之處，好的文章一定有好的可讀性，寫代碼也一樣，只有優美乾淨的代碼才能具有良好的可讀性。編寫具有可讀性的代碼不光是保持有意義的命名就行，如果你想成為一名更好的程序員，寫代碼時你需要注意的有很多，比如：

    1. 規範本地變量的位置
    2. 使函數盡量短小
    3. 調用者盡可能放在被調用者上面
    4. 保持代碼擁有良好的格式
    5. 編寫只做一件事的函數
    6. 函數參數不要超過三個
    7. 暴露時序耦合
    8. 使用異常代替返回錯誤碼

    除此之外，你還須牢記眾多設計原則，如：

    1. 開放封閉原則（OCP）
    2. 迪米特法則
    3. 依賴倒置原則（DIP）
    4. 單一職責原則（SRP）
    5. 里氏替換原則（LSP）
    6. 不要重複（DRY）
    7. 你不會需要它（YAGNI）

    當然僅有這些是不夠的，這不是騎自行車，學寫整潔代碼得花許多功夫，必須不斷實踐，從失敗中提取代碼的壞味道並從中得到啟發。

    編寫整潔代碼，你需要牢記並遵守很多東西，但這並不是循規蹈矩和刻板，而是對簡單之美、代碼之美的追求。代碼整潔之道，是編寫優秀代碼的一種方法，其核心是儘力使代碼保持簡單——Keep It Simple, Stupid。判斷一個人寫的代碼的好壞，不是看它的代碼寫的有多複雜，而是看他有沒有把複雜的事物抽象出來並用簡單的方式去描述它，此外這個人對代碼的態度也至關重要，大多數時候我們並不能從一開始就把代碼寫的很完美，當我們需要快速做出一個原型，或者一開始代碼看起來不錯，但新的需求使現有的設計無法滿足，如果不對設計進行改動的話，那麼代碼就會變的醜陋，如果你熱愛自己正在做的事情，崇尚代碼之美，那麼你就會有足夠的動力去重構它、完善它，而不是破壞結構使代碼腐爛。

    保持簡單、追求簡單，我想這就是編碼之中的禪意，一種追求本真的境界。這種禪在 Python 的設計哲學中體現的淋漓盡致，讓我們在 Python 解釋器中輸入“import this”，來看看經典的 Python 之禪。

    • Beautiful is better than ugly.
      優美勝於醜陋。
    • Explicit is better than implicit.
      顯式勝於隱式。
    • Simple is better than complex.
      簡單勝於複雜。
    • Complex is better than complicated.
      複雜勝於難懂。
    • Flat is better than nested.
      扁平勝於嵌套。
    • Sparse is better than dense.
      分散勝於密集。
    • Readability counts.
      可讀性應當被重視。
    • Special cases aren’t special enough to break the rules. Although practicality beats purity.
      儘管實用性會打敗純粹性，特例也不能凌駕於規則之上。
    • Errors should never pass silently. Unless explicitly silenced.
      除非明確地使其沉默，錯誤永遠不應該默默地溜走。
    • In the face of ambiguity, refuse the temptation to guess.
      面對不明確的定義，拒絕猜測的誘惑。
    • There should be one– and preferably only one –obvious way to do it.
      用一種方法，最好只有一種方法來做一件事。
    • Although that way way not be obvious at first unless you’re Dutch.
      雖然一開始這種方法並不是顯而易見的，但誰叫你不是Python之父呢。
    • Now is better than never. Although never is often better than right now.
      做比不做好，但立馬去做有時還不如不做。
    • If the implementation is hard to explain, it’s a bad idea.
      如果實現很難說明，那它是個壞想法。
    • If the implementation is easy to explain, it may be a good idea.
      如果實現容易解釋，那它有可能是個好想法。
    • Namespaces are one honking great idea – let’s do more of those!
      命名空間是個絕妙的想法，讓我們多多地使用它們吧！

    道着重於方法，禪着重於態度，讓我們把這兩者相結合，做一個有追求的程序員，為成為軟件匠人而奮鬥吧。

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • TLS1.2協議設計原理

    TLS1.2協議設計原理

    目錄

    • 前言
    • 為什麼需要TLS協議
    • 發展歷史
    • 協議設計目標
    • 記錄協議
      • 握手步驟
      • 握手協議
        • Hello Request
        • Client Hello
        • Server Hello
        • Certificate
        • Server Key Exchange
        • Certificate Request
        • Server Hello Done
        • Client Certificate
        • Client Key Exchange
        • Certificate Verify
        • Finished
      • 改變密碼標準協議
      • 警報協議
      • 應用程序數據協議
    • 結語
    • 參考文獻

    前言

    最近對TLS1.2協議處理流程進行了學習及實現，本篇文章對TLS1.2的理論知識和處理流程進行分析，TLS協議的實現建議直接看The Transport Layer Security (TLS) Protocol Version 1.2

    為什麼需要TLS協議

    通常我們使用TCP協議或UDP協議進行網絡通信。TCP協議提供一種面向連接的、可靠的字節流服務。但是TCP並不提供數據的加密，也不提供數據的合法性校驗。

    我們通常可以對數據進行加密、簽名、摘要等操作來保證數據的安全。目前常見的加密方式有對稱加密和非對稱加密。使用對稱加密，雙方使用共享密鑰。

    但是對於部署在互聯網上的服務，如果我們為每個客戶端都使用相同的對稱加密密鑰，那麼任何人都可以將數據解密，那麼數據的隱私性將得不到保障。

    如果我們使用非對稱密鑰加密，客戶端使用服務端的公鑰進行公鑰加密，服務端在私鑰不泄露的情況下，只有服務端可以使用私鑰可以對數據進行解密，從而保障數據的隱私性，但是非對稱加密比對稱加密的成本高得多。

    我們可以採用對稱加密和非對稱加密相結合的方式實現數據的隱私性的同時性能又不至於太差。

    1. 首先客戶端和服務端通過一個稱為密鑰交換的流程進行密鑰協商及交換密鑰所系的信息。
    2. 通過公鑰加密對稱密鑰保證對稱密鑰的安全傳輸。
    3. 服務端使用私鑰解密出對稱密鑰。
    4. 最後雙方使用協商好的對稱密鑰對數據進行加解密。

    TLS協議就是實現了這一過程安全協議。TLS是在TCP之上，應用層之下實現的網絡安全方案。在TCP/IP四層網絡模型中屬於應用層協議。TLS協議在兩個通信應用程序之間提供數據保密性和數據完整性，另外還提供了連接身份可靠性方案。

    UDP則使用DTLS協議實現安全傳輸，和TLS協議類似。

    發展歷史

    TLS協議的前身SSL協議是網景公司設計的主要用於Web的安全傳輸協議，這種協議在Web上獲得了廣泛的應用。

    • 1994年，網景公司設計了SSL協議的1.0版，因為存在嚴重的安全漏洞，未公開。
    • 2.0版本在1995年2月發布，但因為存在數個嚴重的安全漏洞(比如使用MD5摘要、握手消息沒有保護等)，2011年RFC 6176 標準棄用了SSL 2.0。
    • 3.0版本在1996年發布，是由網景工程師完全重新設計的，同時寫入RFC，較新版本的SSL/TLS基於SSL 3.0。2015年，RFC 7568 標準棄用了SSL 3.0。
    • 1999年，IETF將SSL標準化，並將其稱為TLS（Transport Layer Security）。從技術上講，TLS 1.0與SSL 3.0的差異非常微小。
    • TLS 1.1在RFC 4346中定義，於2006年4月發表,主要修復了CBC模式的BEAST攻擊等漏洞。

      微軟、Google、蘋果、Mozilla四家瀏覽器業者將在2020年終止支持TLS 1.0及1.1版。

    • TLS 1.2在RFC 5246中定義，於2008年8月發表，添加了增加AEAD加密算法，如支持GCM模式的AES。
    • TLS 1.3在RFC 8446中定義，於2018年8月發表，砍掉了AEAD之外的加密方式。

    協議設計目標

    1. 加密安全：TLS應用於雙方之間建立安全連接，通過加密，簽名，數據摘要保障信息安全。
    2. 互操作性：程序員在不清楚TLS協議的情況下，只要對端代碼符合RFC標準的情況下都可以實現互操作。
    3. 可擴展性：在必要時可以通過擴展機制添加新的公鑰和機密方法，避免創建新協議。
    4. 相對效率：加密需要佔用大量CPU，尤其是公鑰操作。TLS協議握手完成后，通過對稱密鑰加密數據。TLS還集成了會話緩存方案，減少需要從頭建立連接的情況。

    記錄協議

    TLS協議是一個分層協議，第一層為TLS記錄層協議(Record Layer Protocol)，該協議用於封裝各種高級協議。目前封裝了4種協議：握手協議（Handshake Protocol）、改變密碼標準協議（Change Cipher Spec Protocol）、應用程序數據協議（Application Data Protocol）和警報協議（Alert Protocol）。

    Change Cipher Spec Protocol在TLS1.3被去除。

    記錄層包含協議類型、版本號、長度、以及封裝的高層協議內容。記錄層頭部為固定5字節大小。

    在TLS協議規定了，如接收到了未定義的協議協議類型，需要發送一個unexpected_message警報。

    握手步驟

    • 當客戶端連接到支持TLS協議的服務端要求創建安全連接並列出了受支持的算法套件（包括加密算法、散列算法等），握手開始。
    • 服務端從客戶端的算法套件列表中指定自己支持的一個算法套件，並通知客戶端，若沒有則使用一個默認的算法套件。
    • 服務端發回其数字證書，此證書通常包含服務端的名稱、受信任的證書頒發機構（CA）和服務端的公鑰。
    • 客戶端確認其頒發的證書的有效性。
    • 為了生成會話密鑰用於安全連接，客戶端使用服務端的公鑰加密隨機生成的密鑰，並將其發送到服務端，只有服務端才能使用自己的私鑰解密。
    • 利用隨機數，雙方生成用於加密和解密的對稱密鑰。這就是TLS協議的握手，握手完畢后的連接是安全的，直到連接（被）關閉。如果上述任何一個步驟失敗，TLS握手過程就會失敗，並且斷開所有的連接。

    握手協議

    TLS 握手協議允許服務端和客戶端相互進行身份驗證，並在應用程序協議傳輸或接收其第一個字節數據之前協商協議版本、會話ID、壓縮方法、密鑰套件、以及加密密鑰。

    完整的TLS握手流程，流程如下

      Client                                                       Server

  ClientHello                  -------->
                                                          ServerHello
                                                          Certificate*
                                                    ServerKeyExchange*
                                                  CertificateRequest*
                                <--------              ServerHelloDone
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                                    [ChangeCipherSpec]
                                <--------                     Finished
  Application Data             <------->             Application Data
    • 表示可選步驟或與實際握手情況相關。比如重建已有連接，服務端無需執行Certificate，再比如使用RSA公鑰加密時，無需ServerKeyExchange。
      握手協議消息必須按上面流程的發送數據進行發送，否則需要以致命錯誤告知對方並關閉連接。

    完整的握手流程有時候也被稱為2-RTT流程，即完整的握手流程需要客戶端和服務端交互2次才能完成握手。

    交互應用請求到響應的交互時間被稱為往返時間(Round-trip Time)

    握手協議的結構如下，其中協議頭的ContentType固定為22，接下來是TLS版本號，TLS1.2為0303，最後是用2字節表示長度。

    握手協議類型包含以下：

    • hello_request：0
    • client_hello：1
    • server_hello：2
    • certificate：3
    • server_key_exchange ：12
    • certificate_request：13
    • server_hello_done：14
    • certificate_verify：15
    • client_key_exchange：16
    • finished：20

    Hello Message是具體的握手協議類型內容，不同協議內容有所不同。

    Hello Request

    Hello Request消息用於客戶端與服務端重新協商握手，該消息可能由服務端在任何時刻發送。Hello Request消息非常簡單，沒有其他冗餘信息。

    當客戶端收到了服務端的Hello Request時可以有以下4種行為：

    • 當客戶端正在協商會話，可以忽略該消息。
    • 若客戶端未在協商會話但不希望重新協商時，可以忽略該消息。
    • 若客戶端未在協商會話但不希望重新協商時，可以發送no_renegotiation警報。
    • 若客戶端希望重新協商會話，則需要發送ClientHello重新進行TLS握手。

    服務端發送完HelloRequest消息，可以有以下幾種行為：

    • 服務端發送了HelloRequest消息，但未收到ClientHello時，可以通過致命連接警報關閉連接。
    • 服務端發送了HelloRequest消息，必須等待握手協商處理完成后才可以繼續處理應用數據消息。

    Finished和Certificate的握手消息驗證不包括該消息的hash。

    Client Hello

    當客戶端首次與服務端建立連接或需要重新協商加密握手會話時，需要將Client Hello作為第一條消息發送給服務端。

    Client Hello消息包含了許多重要信息，包括客戶端版本號、客戶端隨機數、會話ID、密鑰套件、壓縮方式、擴展字段等。

    • 客戶端版本號：客戶端支持的最新TLS版本號，服務端會根據該協議號進行協議協商。
    • 32位隨機數：客戶端生成的32位隨機數。前4位是Unix時間戳，該時間戳為1970年1月1日0點以來的秒數。不過TLS並沒有強制要求校驗該時間戳，因此允許定義為其他值。後面28位為一個隨機數。

      通過前4字節填寫時間方式，有效的避免了周期性的出現一樣的隨機數。使得”隨機”更加”隨機”。
      在TLS握手時，客戶端和服務端需要協商數據傳輸時的加密密鑰。為了保證加密密鑰的安全性。密鑰需要通過客戶端和服務端一起生成。客戶端和服務端都提供一個32位的隨機數，通過該隨機數使用基於HMAC的PRF算法生成客戶端和服務端的密鑰。

    • 會話ID：用於表示客戶端和服務端之間的會話。實際的會話ID是由服務端定義的，因此即使是新的連接，服務端返回的會話ID可能也會和客戶端不一致，由於會話ID是明文傳輸的，因此不能存放機密信息。
      • 若會話ID是新的，則客戶端和服務端需要建立完整的TLS握手連接流程。
      • 若會話ID是較早連接的會話ID，則服務端可以選擇無需執行完整的握手協議。
    • 算法套件：客戶端將支持的加密算法組合排列后發送給服務端，從而和服務端協商加密算法。服務端根據支持算法在ServerHello返回一個最合適的算法組合。
      算法套件的格式為TLS_密鑰交換算法_身份認證算法_WITH_對稱加密算法_消息摘要算法，比如TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,密鑰交換算法是DHE,身份認證算法是RSA,對稱加密算法是AES_256_CBC,消息摘要算法是SHA256，由於RSA又可以用於加密也可以用於身份認證，因此密鑰交換算法使用RSA時，只寫一個RSA,比如TLS_RSA_WITH_AES_256_CBC_SHA256
    • 壓縮方式：用於和服務端協商數據傳輸的壓縮方式。由於TLS壓縮存在安全漏洞，因此在TLS1.3中已經將TLS壓縮功能去除，TLS1.2算法也建議不啟用壓縮功能。
    • 擴展字段：可以在不改變底層協議的情況下，添加附加功能。客戶端使用擴展請求其他功能，服務端若不提供這些功能，客戶端可能會中止握手。對於擴展字段的詳細定義可以看Transport Layer Security (TLS) Extensions

    客戶端發送完 ClientHello 消息后，將等待 ServerHello 消息。 服務端返回的任何握手消息（HelloRequest 除外）將被視為致命錯誤。

    Server Hello

    當服務端接收到ClientHello，則開始TLS握手流程， 服務端需要根據客戶端提供的加密套件，協商一個合適的算法簇，其中包括對稱加密算法、身份驗證算法、非對稱加密算法以及消息摘要算法。若服務端不能找到一個合適的算法簇匹配項，則會響應握手失敗的預警消息。

    • 版本號：服務端根據客戶端發送的版本號返回一個服務端支持的最高版本號。若客戶端不支持服務端選擇的版本號，則客戶端必須發送protocol_version警報消息並關閉連接。

      若服務端接收到的版本號小於當前支持的最高版本，且服務端希望與舊客戶端協商，則返回不大於客戶端版本的服務端最高版本。
      若服務端僅支持大於client_version的版本，則必須發送protocol_version警報消息並關閉連接。
      若服務端收到的版本號大於服務端支持的最高版本的版本，則必須返回服務端所支持的最高版本。

    • 32位隨機數：服務端生成的32位隨機數，生成方式和客戶端一樣。服務端生成隨機數的可以有效的防範中間人攻擊，主要是通過防止重新握手后的重放攻擊。

    • 會話ID：用於表示客戶端和服務端之間的會話。若客戶端提供了會話ID，則可以校驗是否與歷史會話匹配。

      • 若不匹配，則服務端可以選擇直接使用客戶端的會話ID或根據自定義規則生成一個新的會話ID，客戶端需要保存服務端返回的會話ID當作本次會話的ID。

      • 若匹配，則可以直接執行1-RTT握手流程，返回ServerHello后直接返回ChangeCipherSpec和Finished消息。

            Client                                                Server

    ClientHello                   -------->
                                                    ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
    [ChangeCipherSpec]
    Finished                      -------->
    Application Data              <------->     Application Data

        在Finished消息中和完整握手一樣都需要校驗VerifyData。

    • 算法套件：服務端根據客戶端提供的算法套件列表和自己當前支持算法進行匹配，選擇一個最合適的算法組合，若沒有匹配項，則使用默認的TLS_RSA_WITH_AES_128_CBC_SHA。

      TLS1.2協議要求客戶端和服務端都必須實現密碼套件TLS_RSA_WITH_AES_128_CBC_SHA

    • 壓縮方式：用於和服務端協商數據傳輸的壓縮方式。由於TLS壓縮存在安全漏洞，因此在TLS1.3中已經將TLS壓縮功能去除，TLS1.2算法也建議不啟用壓縮功能。

    • 擴展字段：服務端需要支持接收具有擴展和沒有擴展的ClientHello。服務端響應的擴展類型必須是ClientHello出現過才行，否則客戶端必須響應unsupported_extension嚴重警告並中斷握手。

    RFC 7568要求客戶端和服務端握手時不能發送{3,0}版本，任何收到帶有協議Hello消息的一方版本設置為{3,0}必須響應protocol_version警報消息並關閉連接。

    通過ClientHello和ServerHello，客戶端和服務端就協商好算法套件和用於生成密鑰的隨機數。

    Certificate

    假設客戶端和服務端使用默認的TLS_RSA_WITH_AES_128_CBC_SHA算法，在ServerHello完成后，服務端必須將本地的RSA證書傳給客戶端，以便客戶端和服務端之間可以進行非對稱加密保證對稱加密密鑰的安全性。
    RSA的證書有2個作用：

    • 客戶端可以對服務端的證書進行合法性進行校驗。
    • 對Client Key Exchange生成的pre-master key進行公鑰加密，保證只有服務端可以解密，確保對稱加密密鑰的安全性。

    發送給客戶端的是一系列證書，服務端的證書必須排列在第一位，排在後面的證書可以認證前面的證書。
    當客戶端收到了服務端的ServerHello時，若客戶端也有證書需要服務端驗證，則通過該握手請求將客戶端的證書發送給服務端，若客戶端沒有證書，則無需發送證書請求到服務端。

    證書必須為X.509v3格式。

    Server Key Exchange

    使用RSA公鑰加密，必須要保證服務端私鑰的安全。若私鑰泄漏，則使用公鑰加密的對稱密鑰就不再安全。同時RSA是基於大數因式分解。密鑰位數必須足夠大才能避免密鑰被暴力破解。

    1999年，RSA-155 (512 bits) 被成功分解。
    2009年12月12日，RSA-768 (768 bits)也被成功分解。
    在2013年的稜鏡門事件中，某個CA機構迫於美國政府壓力向其提交了CA的私鑰，這就是十分危險的。

    相比之下，使用DH算法通過雙方在不共享密鑰的情況下雙方就可以協商出共享密鑰，避免了密鑰的直接傳輸。DH算法是基於離散對數，計算相對較慢。而基於橢圓曲線密碼（ECC）的DH算法計算速度更快，而且用更小的Key就能達到RSA加密的安全級別。ECC密鑰長度為224~225位幾乎和RSA2048位具有相同的強度。

    ECDH:基於ECC的DH算法。

    另外在DH算法下引入動態隨機數，可以避免密鑰直接傳輸。同時即使密鑰泄漏，也無法解密其他消息，因為雙方生成的動態隨機數無法得知。

    在密碼學中該特性被稱為前向保密

    DHE: 通過引入動態隨機數，具有前向保密的DH算法。
    ECDHE：通過引入動態隨機數，具有前保密的ECDH算法。

    Certificate Request

    當需要TLS雙向認證的時候，若服務端需要驗證客戶端的證書，則向客戶端發送Certificate Request請求獲取客戶端指定類型的證書。

    • 服務端會指定客戶端的證書類型。
    • 客戶端會確定是否有合適的證書。

    Server Hello Done

    當服務端處理Hello請求結束時，發送Server Hello Done消息，然後等待接收客戶端握手消息。客戶端收到服務端該消息，有必要時需要對服務端的證書進行有效性校驗。

    Client Certificate

    當客戶端收到了服務端的CertificateRequest請求時，需要發送Client Certificate消息，若客戶端無法提供證書，則仍要發送此消息，消息內容可以不包含證書。

    Client Key Exchange

    客戶端接收到ServerHelloDone消息后，計算密鑰，通過發送Client Key Exchange消息給服務端。客戶端和服務端通過Key Exchange消息交換密鑰，使得雙方的主密鑰協商達成一致。

    以RSA的密鑰協商為例。在ClientHello和ServerHello分別在客戶端和服務端創建了一個32位的隨機數。客戶端接收到Server Hello Done消息時，生成最後一個48位的預主密鑰。通過服務端提供的證書進行公鑰加密，以保證只有服務端的私鑰才能解密。

    其中預主密鑰的前2位要求使用Client Hello傳輸的TLS版本號（存在一些TLS客戶端傳遞的時協商后的TLS版本號，對該版本號檢查時可能會造成握手失敗）。

    需要注意的是，若RSA證書的填空格式不正確，則可能會存在一個漏洞導致客戶端發送的PreMasterSecret被中間人解密造成數據加密的對賬密鑰泄漏。可以看下Attacking RSA-based Sessions in SSL/TLS

    Certificate Verify

    若服務端要求客戶端發送證書，且客戶端發送了非0長度的證書，此時客戶端想要證明自己擁有該證書，則需要使用客戶端私鑰簽名一段數據發送給服務端繼續驗證。該數據為客戶端收發的所有握手數據的hash值（不包括本次消息）。

    Finished

    當發送完Change Cipher Spec消息后必須立即發送該消息。當該消息用於驗證密鑰交換和身份驗證過程是否成功。

    Finished消息是第一個使用協商的算法簇進行加密和防篡改保護的消息。一旦雙方都通過了該消息驗證，就完成了TLS握手。
    VerifyData為客戶端收發的所有握手數據的hash值（不包括本次消息）。與Certificate Verify的hash值可能會不一樣。如果發送過Certificate Verify消息，服務端的握手消息會包含Certificate Verify握手的數據。

    需要注意的是，握手數據不包括協議頭的握手協議明文數據（服務端返回Finished的驗證握手數據是包含接收到客戶端的Finished的明文hash值）。

    Finished消息數據加密和Appilication Data一致，具體數據加密在Application Data段進行說明。

    改變密碼標準協議

    改變密碼標準協議是為了在密碼策略中發出信號轉換信號。 該協議由一條消息組成，該消息在當前（不是掛起的）連接狀態下進行加密和壓縮。 消息由值 1 的單個字節組成。

    在接收到該協議后，所有接收到的數據都需要解密。

    警報協議

    警報消息傳達消息的嚴重性（警告或致命）和警報的說明。具有致命級別的警報消息會導致立即終止連接。
    若在改變密碼標準協議前接收到警報消息，是明文傳輸的，無需解密。

    與其他消息一樣，警報消息按當前連接狀態指定進行加密和壓縮。在接收到改變密碼標準協議後接收到警報協議，則需要進行解密。解密后即為警報協議明文格式。

    加密的Alert消息和加密數據一樣，都需要遞增加密序號，在數據解密時，遞增解密序號。

    應用程序數據協議

    當客戶端和服務端Finished發送完畢並驗證通過後，握手就結束了。後續所有數據都會使用握手協商的對稱密鑰進行數據加密。

    TLS協議實現了數據加密和MAC計算。一般來說有3種加密模式，分別為：

    1. Mac-then-Encrypt：在明文上計算MAC，將其附加到數據，然後加密明和+MAC的完整數據。
    2. 加密和MAC：在明文上計算MAC，加密明文，然後將MAC附加到密文的末尾
    3. Encrypt-then-Mac：加密明文，然後在密文上計算MAC，並將其附加到密文。

    TLS協議使用的是Mac-then-Encrypt。首先將加密的序號、ContentType、數據長度、數據進計算HMAC-SHA256摘要。然後將摘要拼接到數據后，通過PKCS7格式對摘要+MAC數據進行填充對其和加密塊大小一致。最後摘要+MAC+對其填充塊進行加密。

    需要注意的是應用程序數據消息有最大長度限制2^14 + 2048，當超過長度后，數據需要分段傳輸。每一段都當作單獨的數據段進行單獨MAC地址並加密。

    結語

    TLS1.2版本是目前最常用的TLS協議，TLS1.3版本於2018年發表，目前並沒有廣泛使用。
    使用TLS1.2需要注意以下幾點:

    1. 若使用RSA非對稱加密，則需要盡可能使用2048位長度的密鑰。
    2. 盡可能可以使用具有前向安全性的加密算法，如ECDHE算法進行非對稱加密。
    3. 使用AEAD認證加密(GCM)代替CBC塊加密。

    參考文獻

    1. The Transport Layer Security (TLS) Protocol Version 1.2
    2. TLS發展歷史
    3. 前向安全性
    4. TLS/SSL 協議詳解 (30) SSL中的RSA、DHE、ECDHE、ECDH流程與區別
    5. TLS Extensions
    6. Session會話恢復：兩種簡短的握手總結SessionID&SessionTicket
    7. Why using the premaster secret directly would be vulnerable to replay attack?
    8. Why does the SSL/TLS handshake have a client and server random?
    9. Transport Layer Security (TLS) Extensions
    10. 什麼是AEAD加密
    11. Padding Oracle Attacks
    12. Lucky13攻擊
    13. Padding Oracle Attack
    14. ssl perfect forward secrecy
    15. Transport Layer Security (TLS) Session Resumption without Server-Side State
    16. Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
    17. DTLS協議中client/server的認證過程和密鑰協商過程

    本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化

  • 2016國際IoT車用光電技術趨勢研討會論壇

    隨著車輛科技進化，光電產品扮演更重要的角色，全球車用光電市場在2016-2019年間將以年複合成長率17.36%擴大。 由於未來智慧交通、智慧車（Smart Car）仍需要光電技術作為解決方案，「車輛、光電、LED照明」三大跨領域產業合作新紀元。未來「IOT×車用光電」將匯集國內LED上中下游產業與汽車零組件供應廠商， 包括車用LED／LD／OLED產品、車用顯示產品、車用光學影像產品、車用電子系統，以及材料及製程／檢測設備等，展現車用光電發展的產品技術新趨勢。
    今年首度舉辦的「國際IOT車用光電技術趨勢研討會論壇」在規劃上特別著重在國內業界相當重視的智慧車用感測及IOT技術、智慧車燈技術、車用顯示及光學元件技術、智慧車 聯網技術等相關議題的分享。 為突顯國內產業在此一應用技術上的發展成果，也特別在展覽會場中規劃出IOT車用光電專區邀集國內大廠共同展出，為國內目前最專業與豐富的研討會議， 敬邀您親自前來交流。

    本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

    【其他文章推薦】

    ※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

    ※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

    ※Google地圖已可更新顯示潭子電動車充電站設置地點!!

    ※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

    ※別再煩惱如何寫文案,掌握八大原則!

    ※網頁設計最專業,超強功能平台可客製化