u8棒球比分:BlogJava - 棒球比分大小怎么算|网站//www.355548.live/專注于Java技術zh-cnSat, 27 Jun 2020 14:08:19 GMTSat, 27 Jun 2020 14:08:19 GMT60Android?;畬尤朊諾椒牌汗怨砸加沒Ъ影酌グ?附7大機型加白示例) - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/06/24/435553.htmlJack JiangJack JiangWed, 24 Jun 2020 05:55:00 GMT//www.355548.live/jb2011/archive/2020/06/24/435553.html//www.355548.live/jb2011/comments/435553.html//www.355548.live/jb2011/archive/2020/06/24/435553.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435553.html//www.355548.live/jb2011/services/trackbacks/435553.htmlu8棒球比分:1、引言

IM在Android上的?;釵侍餼T詡詞蓖ㄑ鍛穆厶澈圖際躒豪銼惶致?,自從Android 8.0后系統大大降低了后臺運行應用的?;釗萑潭齲ㄏ曇?a target="_blank" style="color: #1d58d1; text-decoration-line: none;">Android P正式版即將到來:后臺應用?;?、消息推送的真正噩夢》),?;畬雍誑萍己嶁械氖貝肓思際趼慕錐?,真要實現?;?,技術難度越來越大。

不過話說回來,既然用黑科技進行?;釷茿ndriod技術的逆潮流,那何不回頭是岸,做個“良民”?

本文將以某款線上的IM產品為例,介紹它是如何引導用戶在多款主流機型上加白名單的,并分享了該款IM中已制作完成的多達7款主流Andriod機型的詳細加白FAQ頁面資源(含完整HTML+圖片),方便您進行參考、學習和研究,希望能為你的應用開發帶來幫助。

特別申明:本文示例中的資源來自某款真實的IM產品,僅供學習和研究,請勿用作非法用途,如有侵權,請告之于我。

學習交流:

- 即時通訊/推送技術開發交流5群:215477170[推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

本文已同步發布于“即時通訊技術圈”公眾號,歡迎關注:

▲ 本文在公眾號上的鏈接是:https://mp.weixin.qq.com/s/JqWloZLBYicpxElVL_HKYw ,原文鏈接是://www.52im.net/thread-3033-1-1.html

2、Android?;?,變的越來越不可能了

IM產品在Android上的?;釵侍獯釉縉詰南低嘲姹鏡較衷?,從未有人停止過嘗試。即時通訊通訊網也隨著Andriod系統版本的升級,持續整理了很多篇相關文章,比如下面這些(文章的順序按照Android系統的版本從低到高)。

上面這些文章,我們可以看到,自從Android 8.0(即Andriod P)以后,IM以及其它需要在后臺?;畹牟?,存活難度越來越高,黑科技幾乎都不起作用了。

于是,一些技術從牛們只能從更深的Android系統層面嘗試突破系統的?;釹拗?,比如這兩篇:《史上最強Android?;釧悸罰荷釗肫飾鎏諮禩IM的進程永生技術》、《Android進程永生技術終極揭密:進程被殺底層原理、APP應對被殺技巧》。

正如上面兩篇文章,為了跟系統作斗爭,可謂斗智斗勇。但Android系統的歷史進程終究無人能阻擋,越來越嚴格的?;釹拗埔丫茿ndroid官方及各大手機廠商的共識。

好吧,之前費盡心機折騰的各種黑科技,如今就像浮云一樣。。。

 

3、死磕?;??別做夢了,回頭是岸

正如上節所述,鑒于Andriod?;畋淶腦嚼叢講豢贍?,很多原本靠黑科技?;畹牟?,開始重新審視?;羆際跏迪?,到底是把?;詈誑萍頰馓趼紛叩膠?,還是回歸Android官方最佳實踐(乖乖引導用戶手動設置白名單)?

我個人認為,后者是?;羆際醴⒄溝謀厝喚峁?,就像之前分享的這篇文章里所做的嘗試一樣:《2020年了,Android后臺?;罨褂邢仿??看我如何優雅的實現!》,規范地引導用戶“加白”。

放棄“黑科技”,并不意味著技術不行,回歸“良民”,反而變的一身輕松。

 

4、調用系統代碼引導用戶加白名單,也不完美

之前整理的《2020年了,Android后臺?;罨褂邢仿??看我如何優雅的實現!》一文,是按照不同的機型,自動適配代碼并在代碼中調用系統的加白名單設置功能。

比如像下面這樣的代碼調用:

▲ 以下代碼引用自《2020年了,Android后臺?;罨褂邢仿??看我如何優雅的實現!

會彈出這樣一個窗口:

這個方法確實不錯,但因為機型不同、同機型的ROOM版本不同,代碼的兼容處理,可能會相當復雜,所以方法雖好,但也并不能一勞永逸的解決所有問題。

5、應用內提供更多機型的“加白”FAQ幫助,是一個補充辦法

正如上節所示,調用系統代碼引導用戶加白名單確實算的上“優雅”,但在不同的機型、同機型的不同系統版本上,可能差異很大,代碼兼容性是個頭疼的問題,總之這不是個百分百完美的辦法。

這就需要一個補充手段,比如我們可以針對大量不同的機型,針對它的最行或最常用系統版本,在應用內以FAQ幫助網頁的方式,為用戶提供幫助。

比如可以在手機里打開像下面這樣FAQ網頁頁面:

至少能在調用系統代碼無法實現的情況下,可以讓用戶自主找到解決問題的辦法。而這便是本文要分享,下節內容會以一個市面上做的比較好的IM應用為例,為你提供一個完整示例。

6、一個完整的“加白”FAQ幫助示例

最近發現的一款市面上的IM應用(此產品跟即時通訊網無任何關系,僅僅是作為技術研究參考對象而已),它內置的“加白”FAQ幫助就很完善。

以下是從該款IM中截下來的圖: 

 

以下是該款IM應用中的運行演示視頻(點此打開視頻鏈接):

 

目前該應用中FAQ幫助已覆蓋7款主流Andriod機,以下是完整示例頁面鏈接:

可以看到,這款IM里的“加白”FAQ做的還是比較細、覆蓋的機型也比較典型, 如果你有類似的想法或需求,完全可以參考這款產品的實現。尤其在一些特定的場景(比如企業內部的IM等)下,這種方式還是能解決大部分終端用戶的問題的。

7、覆蓋7款主流機型的“加白”FAQ頁面靜態資源(附件下載)

我整理了上節中提到的這款IM產品中的全部“加白”FAQ幫助頁面靜態資源,覆蓋7款主流Andriod機型,如果你也需要同樣的東西,可以參考這份完整的示例實現,打包到手機中使用之。

以下是這份靜態資源示例的內容(圖太長,已截掉了一部分): 

以下是這份靜態資源示例的打包附件:

請從原文附件中下載://www.52im.net/thread-3033-1-1.html

附錄:更多精品資源匯總

[1] 精品源碼下載:

Java NIO基礎視頻教程、MINA視頻教程、Netty快速入門視頻 [有源碼]

輕量級即時通訊框架MobileIMSDK的iOS源碼(開源版)[附件下載]

開源IM工程“蘑菇街TeamTalk”2015年5月前未刪減版完整代碼 [附件下載]

微信本地數據庫破解版(含iOS、Android),僅供學習研究 [附件下載]

NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰 [附件下載]

NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰 [附件下載]

NIO框架入門(二):服務端基于MINA2的UDP雙向通信Demo演示 [附件下載]

NIO框架入門(一):服務端基于Netty4的UDP雙向通信Demo演示 [附件下載]

用于IM中圖片壓縮的Android工具類源碼,效果可媲美微信 [附件下載]

高仿Android版手機QQ可拖拽未讀數小氣泡源碼 [附件下載]

一個WebSocket實時聊天室Demo:基于node.js+socket.io [附件下載]

Android聊天界面源碼:實現了聊天氣泡、表情圖標(可翻頁) [附件下載]

高仿Android版手機QQ首頁側滑菜單源碼 [附件下載]

開源libco庫:單機千萬連接、支撐微信8億用戶的后臺框架基石 [源碼下載]

分享java AMR音頻文件合并源碼,全網最全

微信團隊原創Android資源混淆工具:AndResGuard [有源碼]

一個基于MQTT通信協議的完整Android推送Demo [附件下載]

Android版高仿微信聊天界面源碼 [附件下載]

高仿手機QQ的Android版鎖屏聊天消息提醒功能 [附件下載]

高仿iOS版手機QQ錄音及振幅動畫完整實現 [源碼下載]

Android端社交應用中的評論和回復功能實戰分享[圖文+源碼]

Android端IM應用中的@人功能實現:仿微博、QQ、微信,零入侵、高可擴展[圖文+源碼]

仿微信的IM聊天時間顯示格式(含iOS/Android/Web實現)[圖文+源碼]

Android版仿微信朋友圈圖片拖拽返回效果 [源碼下載]

[2] 精品文檔和工具下載:

計算機網絡通訊協議關系圖(中文珍藏版)[附件下載]

史上最全即時通訊軟件簡史(精編大圖版)[附件下載]

重磅發布:《阿里巴巴Android開發手冊(規約)》[附件下載]

阿里技術結晶:《阿里巴巴Java開發手冊(規約)-終極版》[附件下載]

基于RTMP協議的流媒體技術的原理與應用(技術論文)[附件下載]

獨家發布《TCP/IP詳解 卷1:協議》CHM版 [附件下載]

良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]

MQTT協議手冊(中文翻譯版)[附件下載]

經典書籍《UNIX網絡編程》最全下載(卷1+卷2、中文版+英文版)[附件下載]

音視頻開發理論入門書籍之《視頻技術手冊(第5版)》[附件下載]

國際電聯H.264視頻編碼標準官方技術手冊(中文版)[附件下載]

Apache MINA2.0 開發指南(中文版)[附件下載]

網絡通訊數據抓包和分析工具 Wireshark 使用教程(中文) [附件下載]

最新收集NAT穿越(p2p打洞)免費STUN服務器列表 [附件下載]

高性能網絡編程經典:《The C10K problem(英文)》[附件下載]

即時通訊系統的原理、技術和應用(技術論文)[附件下載]

技術論文:微信對網絡影響的技術試驗及分析[附件下載]

華為內部3G網絡資料: WCDMA系統原理培訓手冊[附件下載]

網絡測試:Android版多路ping命令工具EnterprisePing[附件下載]

Android反編譯利器APKDB:沒有美工的日子里繼續堅強的擼

一款用于P2P開發的NAT類型檢測工具 [附件下載]

兩款增強型Ping工具:持續統計、圖形化展式網絡狀況 [附件下載]

Android?;畬尤朊諾椒牌汗怨砸加沒Ъ影酌グ?附7大機型加白示例)

[3] 精選視頻、演講PPT下載:

美圖海量用戶的IM架構零基礎演進之路(PPT)[附件下載]

開源實時音視頻工程WebRTC的架構詳解與實踐總結(PPT+視頻)[附件下載]

QQ空間百億級流量的社交廣告系統架構實踐(視頻+PPT)[附件下載]

海量實時消息的視頻直播系統架構演進之路(視頻+PPT)[附件下載]

YY直播在移動弱網環境下的深度優化實踐分享(視頻+PPT)[附件下載]

QQ空間移動端10億級視頻播放技術優化揭秘(視頻+PPT)[附件下載]

RTC實時互聯網2017年度大會精選演講PPT [附件下載]

微信分享開源IM網絡層組件庫Mars的技術實現(視頻+PPT)[附件下載]

微服務理念在微信海量用戶后臺架構中的實踐(視頻+PPT)[附件下載]

移動端IM開發和構建中的技術難點實踐分享(視頻+PPT)[附件下載]

網易云信的高品質即時通訊技術實踐之路(視頻+PPT)[附件下載]

騰訊音視頻實驗室:直面音視頻質量評估之痛(視頻+PPT)[附件下載]

騰訊QQ1.4億在線用戶的技術挑戰和架構演進之路PPT[附件下載]

微信朋友圈海量技術之道PPT[附件下載]

手機淘寶消息推送系統的架構與實踐(音頻+PPT)[附件下載]

如何進行實時音視頻的質量評估與監控(視頻+PPT)[附件下載]

Go語言構建高并發消息推送系統實踐PPT(來自360公司)[附件下載]

網易IM云千萬級并發消息處理能力的架構設計與實踐PPT [附件下載]

手機QQ的海量用戶移動化實踐分享(視頻+PPT)[附件下載]

釘釘——基于IM技術的新一代企業OA平臺的技術挑戰(視頻+PPT)[附件下載]

微信技術總監談架構:微信之道——大道至簡(PPT講稿)[附件下載]

Netty的架構剖析及應用案例介紹(視頻+PPT)[附件下載]

聲網架構師談實時音視頻云的實現難點(視頻采訪)

滴滴打車架構演變及應用實踐(PPT講稿)[附件下載]

微信海量用戶背后的后臺系統存儲架構(視頻+PPT)[附件下載]

在線音視頻直播室服務端架構最佳實踐(視頻+PPT)[附件下載]

從0到1:萬人在線的實時音視頻直播技術實踐分享(視頻+PPT)[附件下載]

微信移動端應對弱網絡情況的探索和實踐PPT[附件下載]

Android版微信從300KB到30MB的技術演進(PPT講稿)[附件下載]

從零開始搭建瓜子二手車IM系統(PPT)[附件下載]

極光分享:高并發海量消息推送系統架構演進(視頻+PPT)[附件下載]

微信紅包系統可用性設計實踐(PPT) [附件下載]

微信紅包數據架構演變(PPT) [附件下載]

百度網盤千萬節點的P2P架構設計(PPT) [附件下載]

瓜子IM智能客服系統的數據架構設計(PPT) [附件下載]

基于C++構建微信客戶端跨平臺開發框架(PPT) [附件下載]

(本文同步發布于://www.52im.net/thread-3033-1-1.html



Jack Jiang 2020-06-24 13:55 發表評論
]]>
如何優雅地停止SPRING BATCH中的REMOTE CHUNKING JOB - 棒球比分大小怎么算|网站//www.355548.live/paulwong/archive/2020/06/23/435547.htmlpaulwongpaulwongTue, 23 Jun 2020 03:00:00 GMT//www.355548.live/paulwong/archive/2020/06/23/435547.html//www.355548.live/paulwong/comments/435547.html//www.355548.live/paulwong/archive/2020/06/23/435547.html#Feedback0//www.355548.live/paulwong/comments/commentRss/435547.html//www.355548.live/paulwong/services/trackbacks/435547.html 1、什么時候發出停止指令
2、如何等待遠程STEP的完成

一般停止JOB,可用JobOperator.stop(long executionId)來停止,但這個無法確定什么時候發出停止指令,如果是在CHUNK的處理中途發出,則會出現回滾的現象。
BATCH_STEP_EXECUTION - 棒球比分大小怎么算|网站 thead tr {background-color: ActiveCaption; color: CaptionText;} th, td {vertical-align: top; font-family: "Tahoma", Arial, Helvetica, sans-serif; font-size: 8pt; padding: 4px; } table, td {border: 1px solid silver;} table {border-collapse: collapse;} thead .col0 {width: 173px;} .col0 {text-align: right;} thead .col1 {width: 82px;} .col1 {text-align: right;} thead .col2 {width: 282px;} thead .col3 {width: 164px;} .col3 {text-align: right;} thead .col4 {width: 161px;} thead .col5 {width: 161px;} thead .col6 {width: 109px;} thead .col7 {width: 127px;} .col7 {text-align: right;} thead .col8 {width: 109px;} .col8 {text-align: right;} thead .col9 {width: 118px;} .col9 {text-align: right;} thead .col10 {width: 117px;} .col10 {text-align: right;} thead .col11 {width: 142px;} .col11 {text-align: right;} thead .col12 {width: 150px;} .col12 {text-align: right;} thead .col13 {width: 166px;} .col13 {text-align: right;} thead .col14 {width: 137px;} .col14 {text-align: right;} thead .col15 {width: 109px;} thead .col16 {width: 156px;} thead .col17 {width: 161px;}
STEP_EXECUTION_ID VERSION STEP_NAME JOB_EXECUTION_ID START_TIME END_TIME STATUS COMMIT_COUNT READ_COUNT FILTER_COUNT WRITE_COUNT READ_SKIP_COUNT WRITE_SKIP_COUNT PROCESS_SKIP_COUNT ROLLBACK_COUNT EXIT_CODE EXIT_MESSAGE LAST_UPDATED
2304 169 step2HandleXXX 434 2020-06-22 16:27:54 2020-06-22 16:32:46 STOPPED 167 5010 0 4831 0 155 0 161 STOPPED org.springframework.batch.core.JobInterruptedException 2020-06-22 16:32:46


另外SPRING BATCH也不會等遠程STEP執行完成,就將JOB的狀態設為Complete。

發出停止的指令應通過ChunkListener達成:

public class ItemMasterChunkListener extends ChunkListenerSupport{
    
    private static final Logger log = LoggerFactory.getLogger(ItemMasterChunkListener.class);
    
    
    @Override
    public void beforeChunk(ChunkContext context) {
        log.info("ItemMasterProcessor.beforeChunk");
    }


    @Override
    public void afterChunk(ChunkContext context) {
        log.info("ItemMasterProcessor.afterChunk");
        if(XXXX.isStoppingOrPausing()) {
            log.info("context.getStepContext().getStepExecution().setTerminateOnly()");
            context.getStepContext().getStepExecution().setTerminateOnly();
        }
    }


    @Override
    public void afterChunkError(ChunkContext context) {
        log.info("ItemMasterProcessor.afterChunkError");
    }


}


配置BEAN:

@Bean
@StepScope
public ItemMasterChunkListener novaXItemMasterChunkListener() {
     return new ItemMasterChunkListener();
}
    
this.masterStepBuilderFactory
                    .<X, X>get("step2Handle")
                    .listener(itemMasterChunkListener())
                    .build();


由于是在CHUNK完成的時候發出停止指令,就不會出現ROLLBACK的情況。

等待遠程STEP完成,通過讀取MQ上的MESSAGE是否被消費完成,PENDDING的MESSAGE為0的條件即可。

public class JobExecutionListenerSupport implements JobExecutionListener {

    /* (non-Javadoc)
     * @see org.springframework.batch.core.domain.JobListener#afterJob()
     
*/
    @Override
    public void afterJob(JobExecution jobExecution) {
        Integer totalPendingMessages = 0;
        String queueName = "";
        
        
        String messageSelector = "JOB_EXECUTION_ID=" + jobExecution.getJobInstance().getInstanceId();
        do{
            totalPendingMessages = 
                    this.jmsTemplate.browseSelected(queueName, messageSelector, 
                                (session, browser) -> 
                                    Collections.list(browser.getEnumeration()).size()
                            );
            
            String brokerURL = null;
            if(jmsTemplate.getConnectionFactory() instanceof JmsPoolConnectionFactory) {
                JmsPoolConnectionFactory connectionFactory =
                        (JmsPoolConnectionFactory)jmsTemplate.getConnectionFactory();
                ActiveMQConnectionFactory activeMQConnectionFactory =
                        (ActiveMQConnectionFactory)connectionFactory.getConnectionFactory();
                brokerURL = activeMQConnectionFactory.getBrokerURL();
            } else if(jmsTemplate.getConnectionFactory() instanceof CachingConnectionFactory) {
                CachingConnectionFactory connectionFactory =
                        (CachingConnectionFactory)jmsTemplate.getConnectionFactory();
                ActiveMQConnectionFactory activeMQConnectionFactory =
                        (ActiveMQConnectionFactory)connectionFactory.getTargetConnectionFactory();
                brokerURL = activeMQConnectionFactory.getBrokerURL();
            }
            
            LOGGER.info("queueName = {}, {}, totalPendingMessages = {}, url={}", 
                    queueName, messageSelector, totalPendingMessages, brokerURL);
            Assert.notNull(totalPendingMessages, "totalPendingMessages must not be null.");
            try {
                Thread.sleep(5_000);
            } catch (InterruptedException e) {
                LOGGER.error(e.getMessage(), e);
            }
        } while(totalPendingMessages.intValue() > 0);
        
    }

    /* (non-Javadoc)
     * @see org.springframework.batch.core.domain.JobListener#beforeJob(org.springframework.batch.core.domain.JobExecution)
     
*/
    @Override
    public void beforeJob(JobExecution jobExecution) {
    }

}


這樣整個JOB就能無異常地停止,且會等待遠程STEP完成。

Reference:
https://docs.spring.io/spring-batch/docs/4.1.3.RELEASE/reference/html/common-patterns.html#stoppingAJobManuallyForBusinessReasons

https://stackoverflow.com/questions/13603949/count-number-of-messages-in-a-jms-queue

https://stackoverflow.com/questions/55499965/spring-batch-stop-job-execution-from-external-class

https://stackoverflow.com/questions/34621885/spring-batch-pollable-channel-with-replies-contains-chunkresponses-even-if-job




paulwong 2020-06-23 11:00 發表評論
]]>
轉戰嗶哩嗶哩bilibili - 棒球比分大小怎么算|网站//www.355548.live/max/archive/2020/06/22/435545.htmlMaxMaxMon, 22 Jun 2020 12:10:00 GMT//www.355548.live/max/archive/2020/06/22/435545.html//www.355548.live/max/comments/435545.html//www.355548.live/max/archive/2020/06/22/435545.html#Feedback0//www.355548.live/max/comments/commentRss/435545.html//www.355548.live/max/services/trackbacks/435545.htmlhttps://space.bilibili.com/472924697/video。


Max 2020-06-22 20:10 發表評論
]]>
VisualGC IDEA插件(原創) - 棒球比分大小怎么算|网站//www.355548.live/beansoft/archive/2020/06/19/435533.htmlBeanSoftBeanSoftFri, 19 Jun 2020 14:42:00 GMT//www.355548.live/beansoft/archive/2020/06/19/435533.html//www.355548.live/beansoft/comments/435533.html//www.355548.live/beansoft/archive/2020/06/19/435533.html#Feedback0//www.355548.live/beansoft/comments/commentRss/435533.html//www.355548.live/beansoft/services/trackbacks/435533.html閱讀全文

BeanSoft 2020-06-19 22:42 發表評論
]]>
IM開發干貨分享:我是如何解決大量離線消息導致客戶端卡頓的 - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/06/17/435523.htmlJack JiangJack JiangWed, 17 Jun 2020 05:47:00 GMT//www.355548.live/jb2011/archive/2020/06/17/435523.html//www.355548.live/jb2011/comments/435523.html//www.355548.live/jb2011/archive/2020/06/17/435523.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435523.html//www.355548.live/jb2011/services/trackbacks/435523.html閱讀全文

Jack Jiang 2020-06-17 13:47 發表評論
]]>
愛奇藝技術分享:輕松詼諧,講解視頻編解碼技術的過去、現在和將來 - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/06/10/435503.htmlJack JiangJack JiangWed, 10 Jun 2020 03:54:00 GMT//www.355548.live/jb2011/archive/2020/06/10/435503.html//www.355548.live/jb2011/comments/435503.html//www.355548.live/jb2011/archive/2020/06/10/435503.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435503.html//www.355548.live/jb2011/services/trackbacks/435503.html1、內容點評

本文以輕松幽默的語氣,講解了視頻編解碼的一些基本常識,并以愛奇藝為例,講述了視頻編解碼技術在國內的發展以及未來的一些展望。

▼ 閱讀本文需要有一些音視頻編解碼技術的基礎,否則請先閱讀以下文章:

即時通訊音視頻開發(一):視頻編解碼之理論概述

即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹

即時通訊音視頻開發(三):視頻編解碼之編碼基礎

即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門

本文并未就具體的視頻編解碼概念進行深入的討論,目的是盡可能以淺顯易懂的方式讓讀者輕松了解本文標題想呈現的內容。如果您想深入了解視頻編解碼技術,可繼續閱讀以下文章。

▼ 以下是比較深入的視頻編解碼相關文章:

即時通訊音視頻開發(四):視頻編解碼之預測技術介紹

即時通訊音視頻開發(五):認識主流視頻編碼技術H.264

即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢

即時通訊音視頻開發(十七):視頻編碼H.264、VP8的前世今生

即時通訊音視頻開發(十八):詳解音頻編解碼的原理、演進和應用選型

移動端實時音視頻直播技術詳解(四):編碼和封裝

[觀點] WebRTC應該選擇H.264視頻編碼的四大理由

▼ 愛奇藝技術產品團隊還分享了其它兩篇文章,有興趣也可以讀一讀:

愛奇藝移動端網絡優化實踐分享:網絡請求成功率優化篇

愛奇藝技術分享:愛奇藝Android客戶端啟動速度優化實踐總結

歡迎關注“即時通訊技術圈”,更多好文會同步發布在公眾號:

(本文同步發布于://www.52im.net/thread-3028-1-1.html

2、正文引言

初夏最火的造型是什么?不少人可能會脫口而出——“淡黃的長裙,蓬松的頭發。。。”

就連我這個上古時期的老年人,都開始每周四和周六準時點開愛奇藝首頁,吸一口青春美少女們。原因無他,后疫情灰色時期,還有什么能比漂亮小姐姐的燦爛笑容更能讓人感覺到人間值得呢?而我上一次真情實感追完的的女團選秀,可能要追溯到……《超級女聲》。

 

不管自己pick的姐姐妹妹能不能順利出道,至少今天在屏幕上欣賞她們的顏,絕對是一件超幸福的事兒。既不用忍受電視的“馬賽克畫質”,還能隨時隨地掏出手機來欣賞妹妹們今日份的可愛。

 

不知道大家有沒有同一種快樂,那就是用4G網絡看藍光1080P,已經沒有“流量焦慮”了,出現緩沖旋轉“小菊花”的情況的幾率也在悄然減少。這種觀看體驗的優化,除了通信網絡環境的改變之外,締造這種視覺快樂的一項關鍵技術——視頻編碼,就像是宇宙中的暗物質——鮮為人知,但十分重要。

簡單來說:視頻編碼技術的升級,能夠讓你用更少的流量、更低的帶寬、更快的速度,看更高清晰度的視頻畫面。比如《青春有你2》溢出屏幕的元氣少女感,是不是比2005年的朦朧美更令人心動呢?

 

習慣了1080P高清的用戶,絕對不愿意再回到480P的自動馬賽克時代了。那么,視頻編碼到底在高清視頻的烹制中,發揮了怎樣神奇的化學反應?搞秀之余,不妨來了解一下視頻編碼的前世今生,看看無數科技巨頭如何圍繞它撕得花紅柳綠。

3、曾今的視頻編碼標準,是IT巨頭們“跑馬圈地”的游戲

曾今的視頻編碼標準,巨頭們爭相“入股”,視頻編碼標準有何誘人之處?

思科、微軟、蘋果、谷歌、奈飛等這些大名鼎鼎的巨頭,為什么都覺得視頻編碼技術這波“入股不虧”,非要pick助其出道?

回答這個問題之前,有必要先簡單解釋一下,視頻編碼技術究竟是干什么的?

簡單來說:就是將視頻壓縮成一定的格式,去除掉其中的空間冗余和時間冗余,形成更適合存儲和傳輸的碼流。之所以需要被編碼壓縮,最主要原因就是原始視頻的數據量過于龐大。高清視頻文件往往高達1G以上,如果本地播放也就算了,一旦需要將其上傳、分享給他人,傳輸網絡和存儲設備都扛不住那么巨大的數據量。

所以視頻平臺就需要對所播放的文件進行重構:

  • 1)通過壓縮編碼將數據量變小,以方便傳輸;
  • 2)再依靠解壓縮在用戶端解碼,將視頻圖像還原出來。

簡單總結就是:編碼效率決定了你的手機能下載多少部高清視頻。

 

如果你經歷過一晚上不關機終于下好一部2G大小的視頻,卻發現播放器彈出一行大字——“該視頻無法播放”的絕望,那一定會鼓掌歡迎編解碼技術的更新。

 

當然,一些“有流量任性”的小伙伴也會選擇直接用4G網絡在線觀看視頻,這時候視頻大小可就沒什么影響了吧?

這么想可就太天真了。視頻編碼技術越強,傳輸需要占用的帶寬也就更小,就像堤壩沒有加固,但沖擊河道的流水變小了,自然也就不會出現出水口淤塞的問題,看視頻卡頓、掉幀的事故也就不會上演了。

比如此次疫情期間,網絡流量比例不斷增加,為互聯網服務商帶來極大的挑戰,傳統的解決方案就是在網絡帶寬有限的前提下,降低視頻的清晰度。如,YouTube、亞馬遜旗下Prime Video、Netflix等一眾互聯網視頻提供商都在歐洲、印度、澳大利亞等國家降低了視頻畫質,用戶只能默認收看標清視頻。

可是,吃慣了高清這盤珍饈,哪個用戶還愿意忍受低畫質的粗茶淡飯呢?為了留住挑剔的內容食客們,平臺們不得不想盡辦法,提升對視頻的烹飪技藝。

那么,讓我們得以隨時隨地追劇追綜的視頻編解碼技術,到底有哪些呢?

目前,國際上主要有幾種主流的視頻編解碼標準(國際上音視頻編碼技術的標準化),包括VPx(VP8,VP9),H.26x(H.264,H.265),AVS(AVS1,AVS2),AVx(AV1)等等。視頻平臺們用某一種通用編碼格式標準,自己開發編碼器,就可以用更厲害的標準批量生產視頻了。

可詳讀以下相關文章:

即時通訊音視頻開發(五):認識主流視頻編碼技術H.264

即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢

即時通訊音視頻開發(十七):視頻編碼H.264、VP8的前世今生

[觀點] WebRTC應該選擇H.264視頻編碼的四大理由

這些標準都是什么?到底哪個更厲害?為什么每個字符我都認識但完全不知道是干什么的?甚至還有種被張含韻張韶涵張涵予張予曦張馨予等支配的恐懼,傻傻分不清楚……別急,其實就算是流媒體從業者,也很少有人將它們搞清楚。其實吧,只需要了解三個關鍵點,你就能輕松變成“技術派”碾壓不少業內人士了。

簡單來說:不同的視頻編碼標準,就是圍繞三個要素所展開的“量子糾纏”的。

4、視頻編碼標準要素之一:高清

上世紀90年代,第一代視頻編碼標準H.261和MPEG-1就開始出現,其后幾乎每十年就有一次迭代更新。

啟動視頻編碼技術不斷演進的核心要素,還是人們對于高清、更高清的不斷追求。

視頻編碼技術每進化一代,視頻壓縮效率都至少提高了一倍。比如十幾年前第二代視頻編碼標準VP8 和 H.264,只能應用在低于HD的中小分辨率視頻上,稍微兼顧一點1080P分辨率。而2012年愛立信公司推出了首款H.265編解碼器,所引領的第三代視頻編碼HEVC標準就只需H.264一半帶寬,即可播放相同質量的視頻。

啥意思的?如果你是一個擁有過MP4設備的互聯網早期弄潮兒,同樣大的存儲空間,你可以多下載一倍大小的視頻,告別四處借硬盤的苦日子。

在線看視頻則更爽了,基于編解碼標準,智能手機、平板等移動設備也能夠直接在線播放 1080P 的全高清視頻,還支持4K 和 8K 超高清。也就是說,只要有內容方愿意生產8K視頻,平臺就能給你100%還原出畫面來,而不用受最高清晰度720P這樣的限制。

那么,為什么HEVC標準推出2年后,采用AV1格式的消費類設備又開始出現呢?因為移動互聯網的爆發,原有的編碼標準依然不能完全解決帶寬消耗的問題。所以更高效的視頻編碼標準如AVS3、H.266等,也都相繼被研發人員安排上了。

為什么視頻平臺關于編碼標準的“墻頭”這么多?

試想一下,如果你用的是一個高分辨率配置的智能手機,但視頻只能到480P的清晰度,為硬件高配置花的錢不就白瞎了嗎?有的用戶為了防止觀看卡頓或模糊,還得額外下一個完美解碼、格式工廠之類的第三方解碼器,將視頻轉化一下才能看。

而只要視頻平臺支持更高效率的編解碼標準,就能實現低帶寬下播放高清視頻不卡頓的效果。有現炒的熱菜,誰還愿意等打包的盒飯呢?所以細心的讀者會發現,編碼技術的不斷升級,開始讓第三方編碼工具悄悄退出了追劇黨的工具箱。

 

5、視頻編碼標準要素之二:專利

盡管用戶體驗是視頻編碼技術的首要進化原則,但專利所帶來的限制與成本,也成為產業風云迭起的重要誘因。

由GE、Technicolor、杜比,飛利浦和三菱等組建的H.265專利聯盟HEVC Advance,就向使用該標準的廠商收取專利費。

因此,不少開源標準逐漸崛起。其中谷歌打造的VP9標準就是最負盛名的一個。不僅在實際效率上與HEVC/H.265接近,大大優于H.264及它的前身VP8,而且可以對專利免費使用。很快,YouTube全面支持VP9超高清流媒體節目,Netflix、蘋果等也加入其中。

當年,愛奇藝的《破冰行動》無疑是熱度最高的"爆款劇"之一,一度引起風靡,高清流暢的畫面質感為其加分增色不少,就采用了基于VP9標準開發的全新編碼器,就采用了基于VP9標準開發的全新編碼器面部細節等方面畫面真實感尤為顯著。

 

而我國自主知識產權的第二代信源編碼標準AVS的出現,更與專利有著不解之緣。

大家的童年有沒有出現過DVD這種物件,租一部劇不用等更新一個周末看完的快樂,不亞于今天購買視頻平臺尊貴的“VIP中P”會員。但中國的DVD行業曾經也遇到過一次嚴重的專利?;?。

2002年,一批出口的DVD產品因為技術專利費的繳納問題沒有解決而被扣押。于是同年6月,數字音視頻編解碼技術標準工作組成立,2006年,第一代視頻編碼標準AVS1推出,壓縮效率和H.264相當,并且每個編解碼器只象征性得收取1元專利費,對互聯網上的軟件服務更是免收專利費,從此擺脫了只能使用國際標準、被高額專利費卡脖子的窘境。

可以說,目前主流的兩大標準VP9和AVS,都是在專利的鎖鏈中生長出來的自由之翼。

6、視頻編碼標準要素之三:壟斷

既然VP9已經開源了,那就抱緊谷歌大腿等大佬迭代再應用不就好了嗎?一個國家的大部分視頻都坐落在某一個標準體系上,等于將標準的議價權交到了別人手中,面對這種“壟斷優勢”,谷歌表示,我瘋起來可能連自己都打,為了不作惡還是趕緊給自己培養個對手吧……

所以2015年,一個由谷歌倡議并參與,試圖替代VP9和HEVC/H.265的新標準組織成立了,那就是開放媒體聯盟Alliance for Open Media(AOM)。這個新的開源標準很快吸引了Adobe、亞馬遜、AMD、奈飛、Facebook、思科、蘋果、英特爾、英偉達等等巨頭的參與。中國的愛奇藝也率先加入了AOM聯盟。

這個由30多家領先的高科技公司組成的會員制聯盟,很快開發出了新一代開源的視頻編碼標準AV1(AOMedia Video Codec 1.0),也就是今天能讓我們看到高清版《青春有你2》,特別是選秀舞臺上的說唱、勁舞的畫面更加清晰平滑的“后臺”。

 

AV1之所以在產業端迅速上馬,成為包括奈飛、YouTube、BBC、愛奇藝等一眾平臺的推行目標,主要就是在用戶體驗上太能打了。

更高的編碼效率、更低的碼率,同等質量可以節省20%以上的帶寬。舉個例子,就是下載整期1080P版《青春有你2》,原本需要10G的手機存儲,而AV1標準下只需要8G就能搞定,剩下2G空間咱們存點PLMM(漂亮妹妹)的高清大圖舔顏它不香嗎?

在線觀看也很爽,不僅妹妹們的臉看起來會更清晰,而且高清播放所占的帶寬也更小,同時下載個東西、刷個微博啥的,也不會因為網絡擁擠而卡頓。

作為視頻觀眾,誰不愿意平臺默默地為我們殫精竭慮,周全每一點流量、帶寬和存儲卡呢?

 

不難看出,視頻編碼標準迭代,既是技術天花板的層層上探,也是整個視頻平臺必須攻占的體驗高地。

7、如今,國內的視頻平臺正在搶跑編碼標準“賽道”

具體到國內視頻平臺上,關于編碼標準目前競爭身位如何,未來還有哪些硬仗要打,都是值得我們重點關注的話題。我們不妨具體到某一個平臺的探索經歷之中,用歷史觀的視角來捋一捋,視頻編碼技術到底給中國這片土地的網民,帶來了哪些體驗上的蝶變。

比如:以愛奇藝為例,2016年愛奇藝在萬能播放器上線了AVS2格式,是當時國內唯一支持這一標準的平臺;也是國內第一個實現VP9標準、AV1標準并應用的視頻廠商??梢運翟詒嗦氡曜劑煊?,無論是技術領先度、布局完善度上,都能夠從一定程度代表中國流媒體產業的關鍵抉擇。

有了標準,是不是只需要拿來直接上手呢?答案顯然是否定的。

拿愛奇藝來說,我們的標準探索之旅,又是如何的呢?

我們就以當前效率最高的AV1標準為例,其算法運算復雜度高,所需要的編碼時間很長,這樣把平臺所有視頻都處理一遍,可能會等來用戶一句“奶奶你等的AV1格式上線了”!

所以,為了提高編碼效率,讓處理效果能夠快速細致,又不影響編碼質量,達到工業應用標準,標準編碼器就要靠各個平臺發揮自主能動性了。

以愛奇藝為例,對每一代開源技術都保持緊密跟進的同時,也會發揮自身的技術特長來進行針對性的迭代,讓同一標準在愛奇藝平臺上的應用有更優秀的表現。

比如VP9標準推出時,愛奇藝的技術團隊就根據開源的版本VP9編碼器進行了專門的算法優化,所開發的QVP9編碼器的速率是開源版本的5.4倍左右。作為國內首先支持VP9的視頻廠商,其畫面質量在快速鏡頭、輪廓邊緣、面部細節等方面真實感尤為顯著,壓縮效率比市面主流的標準更是提升了一倍??贍芤彩竊誆恢瘓跫?,突然發現視頻中那些高速打斗的場面似乎更加細膩流暢了,人物的皮膚也變得更加立體和容易辨別,連女主角額頭的青春痘都是那么的昭然若揭……

 

而伴隨著用戶在移動場景下觀看視頻的訴求越來越高,比如我本人就喜歡在地鐵上刷短視頻,別問,問就是流量多有錢任性!這時候要保證流暢不卡頓,主打PC端的VP9可能就有點不夠了,所以對移動端設備更友好的AV1,在推出后也很快被安排的明明白白。

獨立研發的QAV1編碼器,不僅比H265減小將近一半的帶寬,節省40%以上碼率。而且速度比開源編碼器SVT-AV1還快出5倍左右。比如同樣是看《青春有你2》,用QAV1展示的畫面效果更棒、顏值更高,反而還更省帶寬,直接幫助我節省了不少流量,讓滿額限速來的更晚一些。

 

8、展望未來,5G讓視頻編解碼技術有了更多的想象空間

目前,首批應用 AV1 的電影已經在愛奇藝上線,用戶可以在電腦瀏覽器端和安卓移動端觀看。做到這一步,很難嗎?

答案是肯定的。舉個例子,終端硬件解碼芯片的成熟,與某項標準能否發揮價值有直接關系。比如H.265在硬件支持上比較廣泛,就與蘋果、高通、英特爾等的芯片都支持H.265的硬件解碼器有關。

所以編碼器往往需要結合具體的應用場景來進行改進和深度優化。

以AV1在愛奇藝的應用為例,為了更好地適應愛奇藝海量內容,QAV1通過對場景復雜度的預分析,實現了更加合理的碼率分配。對于簡單場景,QAV1可以自適應地降低碼率,在保證畫質的情況下節省用戶帶寬;同時對于復雜場景會適當提高碼率,給用戶帶來更高畫質的體驗。

 

目前,QAV1已經支持的功能包括多種速度檔次、多種碼率控制方式、8K視頻編碼等。這種與差異化環境相匹配的細節打磨,同時兼顧了網絡帶寬與用戶體驗。

萬眾期待的5G,自然也需要與之匹配的視頻編碼標準來呼應。以愛奇藝為例來說,AVS3應用已經在路上了,用移動智能手機看8K超高清視頻、瀏覽VR新聞資訊、與虛擬偶像互動……這些新娛樂體驗,或許都將借助視頻編碼的技術魔術,被呈現到我們眼前。

從愛奇藝的視頻編碼探索中,不難看到,技術的時代快車并不容易拿到船票的。唯有長期披荊斬棘,才能順利摘得王冠。

附錄:更多音視頻技術方面的資料

[1] 實時音視頻開發的精華資料:

即時通訊音視頻開發(一):視頻編解碼之理論概述

即時通訊音視頻開發(二):視頻編解碼之數字視頻介紹

即時通訊音視頻開發(三):視頻編解碼之編碼基礎

即時通訊音視頻開發(四):視頻編解碼之預測技術介紹

即時通訊音視頻開發(五):認識主流視頻編碼技術H.264

即時通訊音視頻開發(六):如何開始音頻編解碼技術的學習

即時通訊音視頻開發(七):音頻基礎及編碼原理入門

即時通訊音視頻開發(八):常見的實時語音通訊編碼標準

即時通訊音視頻開發(九):實時語音通訊的回音及回音消除概述

即時通訊音視頻開發(十):實時語音通訊的回音消除技術詳解

即時通訊音視頻開發(十一):實時語音通訊丟包補償技術詳解

即時通訊音視頻開發(十二):多人實時音視頻聊天架構探討

即時通訊音視頻開發(十三):實時視頻編碼H.264的特點與優勢

即時通訊音視頻開發(十四):實時音視頻數據傳輸協議介紹

即時通訊音視頻開發(十五):聊聊P2P與實時音視頻的應用情況

即時通訊音視頻開發(十六):移動端實時音視頻開發的幾個建議

即時通訊音視頻開發(十七):視頻編碼H.264、VP8的前世今生

即時通訊音視頻開發(十八):詳解音頻編解碼的原理、演進和應用選型

即時通訊音視頻開發(十九):零基礎,史上最通俗視頻編碼技術入門

實時語音聊天中的音頻處理與編碼壓縮技術簡述

網易視頻云技術分享:音頻處理與壓縮技術快速入門

學習RFC3550:RTP/RTCP實時傳輸協議基礎知識

基于RTMP數據傳輸協議的實時流媒體技術研究(論文全文)

聲網架構師談實時音視頻云的實現難點(視頻采訪)

淺談開發實時視頻直播平臺的技術要點

還在靠“喂喂喂”測試實時語音通話質量?本文教你科學的評測方法!

實現延遲低于500毫秒的1080P實時音視頻直播的實踐分享

移動端實時視頻直播技術實踐:如何做到實時秒開、流暢不卡

如何用最簡單的方法測試你的實時音視頻方案

技術揭秘:支持百萬級粉絲互動的Facebook實時視頻直播

簡述實時音視頻聊天中端到端加密(E2EE)的工作原理

移動端實時音視頻直播技術詳解(一):開篇

移動端實時音視頻直播技術詳解(二):采集

移動端實時音視頻直播技術詳解(三):處理

移動端實時音視頻直播技術詳解(四):編碼和封裝

移動端實時音視頻直播技術詳解(五):推流和傳輸

移動端實時音視頻直播技術詳解(六):延遲優化

理論聯系實際:實現一個簡單地基于HTML5的實時視頻直播

IM實時音視頻聊天時的回聲消除技術詳解

淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標

如何優化傳輸機制來實現實時音視頻的超低延遲?

首次披露:快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的?

Android直播入門實踐:動手搭建一套簡單的直播系統

網易云信實時視頻直播在TCP數據傳輸層的一些優化思路

實時音視頻聊天技術分享:面向不可靠網絡的抗丟包編解碼器

P2P技術如何將實時視頻直播帶寬降低75%?

專訪微信視頻技術負責人:微信實時視頻聊天技術的演進

騰訊音視頻實驗室:使用AI黑科技實現超低碼率的高清實時視頻聊天

微信團隊分享:微信每日億次實時音視頻聊天背后的技術解密

近期大熱的實時直播答題系統的實現思路與技術難點分享

福利貼:最全實時音視頻開發要用到的開源工程匯總

七牛云技術分享:使用QUIC協議實現實時視頻直播0卡頓!

實時音視頻聊天中超低延遲架構的思考與技術實踐

理解實時音視頻聊天中的延時問題一篇就夠

實時視頻直播客戶端技術盤點:Native、HTML5、WebRTC、微信小程序

寫給小白的實時音視頻技術入門提綱

微信多媒體團隊訪談:音視頻開發的學習、微信的音視頻技術和挑戰等

騰訊技術分享:微信小程序音視頻技術背后的故事

微信多媒體團隊梁俊斌訪談:聊一聊我所了解的音視頻技術

新浪微博技術分享:微博短視頻服務的優化實踐之路

實時音頻的混音在視頻直播應用中的技術原理和實踐總結

以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰

騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐

新浪微博技術分享:微博實時直播答題的百萬高并發架構實踐

技術干貨:實時視頻直播首屏耗時400ms內的優化實踐

愛奇藝技術分享:輕松詼諧,講解視頻編解碼技術的過去、現在和將來

>> 更多同類文章 ……

[2] 開源實時音視頻技術WebRTC的文章:

開源實時音視頻技術WebRTC的現狀

簡述開源實時音視頻技術WebRTC的優缺點

訪談WebRTC標準之父:WebRTC的過去、現在和未來

良心分享:WebRTC 零基礎開發者教程(中文)[附件下載]

WebRTC實時音視頻技術的整體架構介紹

新手入門:到底什么是WebRTC服務器,以及它是如何聯接通話的?

WebRTC實時音視頻技術基?。夯炯芄購托檎?/a>》

淺談開發實時視頻直播平臺的技術要點

[觀點] WebRTC應該選擇H.264視頻編碼的四大理由

基于開源WebRTC開發實時音視頻靠譜嗎?第3方SDK有哪些?

開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用

簡述實時音視頻聊天中端到端加密(E2EE)的工作原理

實時通信RTC技術棧之:視頻編解碼

開源實時音視頻技術WebRTC在Windows下的簡明編譯教程

網頁端實時音視頻技術WebRTC:看起來很美,但離生產應用還有多少坑要填?

了不起的WebRTC:生態日趨完善,或將實時音視頻技術白菜化

騰訊技術分享:微信小程序音視頻與WebRTC互通的技術思路和實踐

>> 更多同類文章 ……

(本文同步發布于://www.52im.net/thread-3028-1-1.html



Jack Jiang 2020-06-10 11:54 發表評論
]]>
網絡編程懶人入門(十二):快速讀懂Http/3協議,一篇就夠! - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/06/03/435478.htmlJack JiangJack JiangWed, 03 Jun 2020 15:18:00 GMT//www.355548.live/jb2011/archive/2020/06/03/435478.html//www.355548.live/jb2011/comments/435478.html//www.355548.live/jb2011/archive/2020/06/03/435478.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435478.html//www.355548.live/jb2011/services/trackbacks/435478.html本文中文譯文由作者“ably.io”發布于公眾號“高可用架構”,譯文原題:《深入解讀HTTP3的原理及應用》、英文原題:《HTTP/3 deep dive》(文末有譯文和原文鏈接),即時通訊網收錄時有少許改動,感謝原作者和譯者的分享。

1、引言

HTTP3是HTTP協議的最新版本。從誕生之初,HTTP就是交換超文本文檔的首選應用層協議。多年來,為了跟上互聯網的發展,以及WWW上交換的內容種類增加,HTTP進行了幾次重大升級,而HTTP/3就是目前的最新版本。

本文將從HTTP/3的基本概念、技術原理、應用場景和如何使用它等方面進行介紹,確保在有限的篇幅內,能讓你通俗地理解它。


 

本文是系列文章中的第12篇,本系列文章的大綱如下:

網絡編程懶人入門(一):快速理解網絡通信協議(上篇)

網絡編程懶人入門(二):快速理解網絡通信協議(下篇)

網絡編程懶人入門(三):快速理解TCP協議一篇就夠

網絡編程懶人入門(四):快速理解TCP和UDP的差異

網絡編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優勢

網絡編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

網絡編程懶人入門(八):手把手教你寫基于TCP的Socket長連接

網絡編程懶人入門(九):通俗講解,有了IP地址,為何還要用MAC地址?

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議

網絡編程懶人入門(十一):一文讀懂什么是IPv6

網絡編程懶人入門(十二):快速讀懂Http/3協議,一篇就夠!》(本文)

學習交流:

- 即時通訊/推送技術開發交流5群:215477170 [推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

歡迎關注“即時通訊技術圈”,更多好文會同步發布在公眾號:

(本文同步發布于://www.52im.net/thread-3020-1-1.html

2、相關文章

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》(推薦)

技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》(推薦)

3、HTTP協議的演進史

在萬維網誕生之時,萬維網僅僅是一群交換超文本文件的計算機。在計算機之間交換文件是一個簡單的程序,包括請求和響應。在此基礎上設計了一個簡單的基于文本的協議。HTTP(超文本傳輸協議)應運而生。后來,它被起草成了一個標準化的IETF協議,定義在RFC 1945中,也被稱為HTTP/1.0。

多年來,HTTP從HTTP/1.0發展到HTTP/1.1,再到HTTP/2。在每一次迭代中,協議都增加了新的功能,以處理大量的需求,如應用層需求、安全考慮、會話處理和媒體類型等。要深入了解HTTP/2及其演進史,可詳讀《從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路》。

盡管經歷了幾次修訂,但HTTP的底層傳輸機制基本沒有變化。但是,隨著互聯網流量的激增,在移動電話的推動下,HTTP的傳輸機制在保證網頁瀏覽體驗的流暢性方面變得問題重重。

HTTP/3是為了處理HTTP/2.0的傳輸相關問題而生的,可以在各種設備上更快地訪問Web。它基于一個新的傳輸層協議,稱為QUIC(Quick UDP Internet Protocol),在UDP之上工作。這一選擇與之前版本的HTTP截然不同,之前版本都是基于TCP。TCP是一個比UDP更可靠的協議,那么為什么要在UDP之上重新設計HTTP的傳輸層呢?


 

讓我們來看看在TCP上運行HTTP的局限性,并深入了解一下基于QUIC協議的HTTP/3的設計思想。

4、什么是HTTP/3

當IETF正式標準化HTTP/2時,Google正在獨立構建一個新的傳輸協議,名為gQUIC。它后來成為新互聯網草案,并被命名為QUIC。gQUIC最初的實驗證明,在網絡條件較差的情況下,gQUIC在增強網頁瀏覽體驗方面的效果非常好。因此,gQUIC的發展勢頭越來越好,IETF的大多數成員贊成建立一個在QUIC上運行的HTTP新規范。這個新的倡議被稱為HTTP/3,以區別于當前的HTTP/2標準。


 

從語法和語義上看,HTTP/3與HTTP/2相似。HTTP/3遵循相同的請求和響應消息交換順序,其數據格式包含方法、標題、狀態碼和body。然而,HTTP/3的顯著的偏差在于協議層在UDP之上的堆疊順序。


 

有關QUIC的更多資料,可以看看《網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》、《技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解》。

5、HTTP/3 是如何工作的?

HTTP/3功能的核心是圍繞著底層的QUIC協議來實現的。在討論QUIC和UDP之前,我們有必要先列出TCP的某些限制,這也是導致QUIC發展的原因。

5.1 TCP可能會間歇性地掛起數據傳輸

如果一個序列號較低的數據段還沒有接收到,即使其他序列號較高的段已經接收到,TCP的接收機滑動窗口也不會繼續處理。這將導致TCP流瞬間掛起,在更糟糕的情況下,即使所有的段中有一個沒有收到,也會導致關閉連接。這個問題被稱為TCP流的行頭阻塞(HoL)。


 

5.2 TCP不支持流級復用

雖然TCP確實允許在應用層之間建立多個邏輯連接,但它不允許在一個TCP流中復用數據包。使用HTTP/2時,瀏覽器只能與服務器打開一個TCP連接,并使用同一個連接來請求多個對象,如CSS、JavaScript等文件。在接收這些對象的同時,TCP會將所有對象序列化在同一個流中。因此,它不知道TCP段的對象級分區。

5.3 TCP會產生冗余通信

TCP連接握手會有冗余的消息交換序列,即使是與已知主機建立的連接也是如此。


 

QUIC協議在以下設計選擇的基礎上,通過引入一些底層傳輸機制的改變,解決了這些問題。

1)選擇UDP作為底層傳輸層協議:在TCP之上建立新的傳輸機制,將繼承TCP的上述所有缺點。因此,UDP是一個明智的選擇。此外,QUIC是在用戶層構建的,所以不需要每次協議升級時進行內核修改。

2)流復用和流控:QUIC引入了連接上的多路流復用的概念。QUIC通過設計實現了單獨的、針對每個流的流控,解決了整個連接的行頭阻塞問題。


 

3)靈活的擁塞控制機制:TCP的擁塞控制機制是剛性的。該協議每次檢測到擁塞時,都會將擁塞窗口大小減少一半。相比之下,QUIC的擁塞控制設計得更加靈活,可以更有效地利用可用的網絡帶寬,從而獲得更好的吞吐量。

4)更好的錯誤處理能力:QUIC使用增強的丟失恢復機制和轉發糾錯功能,以更好地處理錯誤數據包。該功能對于那些只能通過緩慢的無線網絡訪問互聯網的用戶來說是一個福音,因為這些網絡用戶在傳輸過程中經常出現高錯誤率。

5)更快的握手:QUIC使用相同的TLS??榻邪踩?。然而,與TCP不同的是,QUIC的握手機制經過優化,避免了每次兩個已知的對等者之間建立通信時的冗余協議交換。


 

通過在QUIC之上構建基于HTTP/3的應用層,您可以獲得增強型傳輸機制的所有優勢,同時保留HTTP/2的語法和語義。但是,你也必須注意到,HTTP/2不能直接與QUIC集成,因為從應用到傳輸的底層幀映射是不兼容的。因此,IETF的HTTP工作組建議將HTTP/3作為新的HTTP版本,并根據QUIC協議的幀格式要求修改了幀映射。

除此之外,HTTP/3還使用了一種新的HTTP頭壓縮機制,稱為QPACK,是對HTTP/2中使用的HPACK的增強。在QPACK下,HTTP頭可以在不同的QUIC流中不按順序到達。與HTTP/2中的TCP確保數據包的按順序傳遞不同,QUIC流是不按順序傳遞的,在不同的流中可能包含不同的HTTP頭。因此,QPACK使用查找表機制對報頭進行編碼和解碼。

6、為什么HTTP/3很重要?

TCP已經有40多年的歷史了。它在1981年通過RFC 793從而標準化。多年來,它經歷了多次更新,是一個非常強大的傳輸協議,可以支持互聯網流量的增長。然而,由于設計上的原因,TCP從來就不適合處理有損無線環境中的數據傳輸。在互聯網的早期,有線網絡將網絡中的每一臺計算機連接起來。

現在,隨著智能手機和便攜式設備的數量超過臺式機和筆記本電腦的數量,超過50%的互聯網流量已經通過無線傳輸。這種趨勢給整體的網絡瀏覽體驗帶來了問題,其中最重要的是在無線覆蓋率不足的情況下,TCP中的行頭阻塞(關于TCP在移動網絡下的不足,請閱讀《5G時代已經到來,TCP/IP老矣,尚能飯否?》)。

Google的一些初步實驗證明,QUIC作為Google部分熱門服務的底層傳輸協議,極大地提高了速度和用戶體驗。部署QUIC作為YouTube視頻的底層傳輸協議,導致YouTube視頻流的緩沖率下降了30%,這直接影響了用戶的視頻觀看體驗。在顯示谷歌搜索結果時,也有類似的改善。

網絡條件較差的情況下提升非常明顯,這促使谷歌更加積極地完善該協議,并最終向IETF提出標準化。

由于這些早期的試驗所帶來的所有改進,QUIC已經成為帶領萬維網走向未來的重要因素。在QUIC的支持下,HTTP從HTTP/2到HTTP/3的改頭換面,朝著這個方向合理地邁出了一步。


 

7、HTTP/3的最佳用例

HTTP/3將改善我們上網的體驗,特別是在仍無法使用高速無線網絡的地區。盡管HTTP/2已經解決了一部分問題,然而HTTP/3更進一步。

7.1 物聯網(IoT)

HTTP可能不是物聯網的首選協議,但在某些情況下,基于HTTP的通信非常適合特定的應用。HTTP/3可以解決從傳感器收集數據的移動電話的無線連接損耗問題。這個問題同樣適用于安裝在車輛或可移動資產上的獨立IoT設備。通過HTTP來訪問這些設備,可以更加可靠。

7.2 大數據

全球各地的企業都在覺醒,意識到從多個部門收集數據的潛力,并將其整合成更大的信息共享API,供內部和外部受眾共享。這些API也為數據的貨幣化鋪平了道路,通過托管這些數據作為流API服務可以實現數據的貨幣化。隨著時間的推移,這些服務會吐出海量的數據。通過HTTP/3托管的流API將使它們比HTTP/2更健壯、更有彈性。

7.3 Web VR

隨著瀏覽器能力的提升,內容格局正在快速變化。其中一個領域就是基于網絡的VR。雖然還處于起步階段,但有很多的用例可以讓VR在加強協作方面發揮關鍵作用。網絡在促進VR互動方面占據了核心位置。VR應用需要更多的帶寬來渲染虛擬場景中的復雜細節,因此遷移到HTTP/3會大有收獲。

8、HTTP/3的局限性

過渡到HTTP/3不僅涉及到應用層的變化,還涉及到底層傳輸層的變化。因此,與它的前身HTTP/2相比,HTTP/3的采用更具挑戰性,因為后者只需要改變應用層。傳輸層承受著網絡中的大量中間層審查。這些中間層,如防火墻、代理、NAT設備等會進行大量的深度數據包檢查,以滿足其功能需求。因此,新的傳輸機制的引入對IT基礎設施和運維團隊來說有一些影響。

然而,HTTP/3被廣泛采用的另一個問題是,它是基于QUIC的,在UDP上運行。大多數的Web流量,以及IETF定義的知名服務都是在TCP之上運行的。這也是為什么長時間運行HTTP/3的UDP會話會被防火墻的默認數據包過濾策略所影響的原因。

隨著IETF正在進行的標準化工作,這些問題最終都會得到解決。此外,考慮到Google在早期QUIC實驗所顯示的積極結果,人們對HTTP/3的支持是壓倒性的,這將最終迫使中間層廠商標準化。

針對受限的IoT設備,HTTP/3由于過于繁瑣從而無法采用。許多IoT應用部署的設備的外形尺寸非常小。因此,它們的RAM和CPU功率都是有限的。為了使設備在電池功率、低比特率和有損連接等限制條件下高效運行,必須執行此要求。HTTP/3在現有的UDP之上,以QUIC的形式在傳輸層處理,增加了HTTP/3在整個協議棧中的占用空間。這使得HTTP/3較為笨重,不適合那些IoT設備。但這種情況很少出現,而且存在專門的協議,這就避免了直接在此類設備上支持HTTP的需要。此外,還有以物聯網為核心的協議,如MQTT。

9、開始使用HTTP/3

IETF的HTTP工作組正致力于在2020年后期發布HTTP/3。因此它還沒有被NGINX和Apache等主流web服務器正式支持。不過,有幾個lib可以用來實驗這個新協議,也提供了非官方的補丁。

以下是支持HTTP/3和QUIC傳輸lib的列表。請注意,這些實現都是基于互聯網標準草案某一個版本,而這個版本很可能會被更高的版本所取代,最終的標準會在RFC中發布。

1)Quiche :

Quiche提供了通過QUIC協議發送和接收數據包的底層編程接口。它還支持HTTP/3???,通過其QUIC協議實現發送HTTP數據包。除此之外,它還為NGINX服務器提供了一個非官方的補丁,可以安裝和托管一個能夠運行HTTP/3的Web服務器。除此以外,還提供了額外的程序來支持Android和iOS移動應用上使用HTTP/3。

2)Aioquic

Aioquic是QUIC的python實現。它還內置HTTP/3的測試服務器和客戶端庫。Aioquic建立在asyncio??櫓?,asyncio??槭荘ython的標準異步I/O框架。

3)Neqo

Neqo 是 Mozilla 使用 Rust 實現 QUIC 和 HTTP/3。

如果你想嘗試QUIC,請查看這個由QUIC工作組維護的QUIC協議的開源實現鏈接:https://github.com/quicwg/base-drafts/wiki/Implementations

(本文英文原文鏈接:點此進入、中文譯文鏈接:點此進入

附錄:更多有關HTTP協議的文章

網絡編程懶人入門(七):深入淺出,全面理解HTTP協議

技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解

讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)

Comet技術詳解:基于HTTP長連接的Web端實時通信技術

WebSocket詳解(四):刨根問底HTTP與WebSocket的關系(上篇)

WebSocket詳解(五):刨根問底HTTP與WebSocket的關系(下篇)

快速理解高性能HTTP服務端的負載均衡技術原理

一分鐘理解 HTTPS 到底解決了什么問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

即時通訊安全篇(八):你知道,HTTPS用的是對稱加密還是非對稱加密?

IM開發基礎知識補課(四):正確理解HTTP短連接中的Cookie、Session和Token

即時通訊安全篇(七):如果這樣來理解HTTPS原理,一篇就夠了

一分鐘理解 HTTPS 到底解決了什么問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

小白必讀:閑話HTTP短連接中的Session和Token

IM開發基礎知識補課:正確理解前置HTTP SSO單點登錄接口的原理

基于APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)

全面了解移動端DNS域名劫持等雜癥:原理、根源、HttpDNS解決方案等

美圖App的移動端DNS優化實踐:HTTPS請求耗時減小近半

HTTPS時代已來,打算更新你的HTTP服務了嗎?

移動端網絡優化之HTTP請求的DNS優化

(本文同步發布于://www.52im.net/thread-3020-1-1.html



Jack Jiang 2020-06-03 23:18 發表評論
]]>
美團點評的移動端網絡優化實踐:大幅提升連接成功率、速度等 - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/05/29/435474.htmlJack JiangJack JiangFri, 29 May 2020 04:06:00 GMT//www.355548.live/jb2011/archive/2020/05/29/435474.html//www.355548.live/jb2011/comments/435474.html//www.355548.live/jb2011/archive/2020/05/29/435474.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435474.html//www.355548.live/jb2011/services/trackbacks/435474.html閱讀全文

Jack Jiang 2020-05-29 12:06 發表評論
]]>
美團點評的移動端網絡優化實踐:大幅提升連接成功率、速度等 - 棒球比分大小怎么算|网站//www.355548.live/jb2011/archive/2020/05/29/435473.htmlJack JiangJack JiangFri, 29 May 2020 04:05:00 GMT//www.355548.live/jb2011/archive/2020/05/29/435473.html//www.355548.live/jb2011/comments/435473.html//www.355548.live/jb2011/archive/2020/05/29/435473.html#Feedback0//www.355548.live/jb2011/comments/commentRss/435473.html//www.355548.live/jb2011/services/trackbacks/435473.html閱讀全文

棒球比分大小怎么算 2020-05-29 12:05 發表評論
]]>
{ganrao}