ref: https://javascript.plainenglish.io/what-is-http-3-and-why-does-it-matter-cb7d7b4b600f
這篇文章簡單的敘述何謂 HTTP/3,主要探討 HTTP/3 到底跟 HTTP/1, HTTP/2 的差異是什麼
HTTP/3,也可以稱為 HTTP ove QUIC,這對過往的 HTTP 來說帶來了巨大的改變,因為 HTTP/{1,2} 都是基於 TCP 來傳輸封包,而 HTTP/3 則是仰賴 QUIC (Google 於 2012 所開發的協定,底層基於 UDP)。
TCP 目前普遍被使用到各式各樣的網路應用程中,而 TCP 本身的設計到今日來看也是有不少為人詬病的地方,譬如說 TCP 當初發明的時空背景與當前網路環境已經不同,譬如網際網路中的頻寬大小等
所以後續也有不少的演算法想要針對 TCP 來進行改善,譬如 Congestion Control 相關就有不少演算法可以選擇。
另外一個更直接簡單的就是直接跳過 TCP,直接使用 UDP 做為底層傳輸協定並且於應用層級重新打造一個如 TCP 一樣可信賴的傳送方式,這也是 QUIC 這個協定的基本概念。
透過 QUIC 的幫助,作者提到 HTTP/3 能夠得到下列的好處
Faster request multiplexing
HTTP/2 以前, 瀏覽器每次都只能對 Server 發送一個 Request,這導致網頁讀取速度緩慢,而 HTTP/2 則試圖改善這個機制,不過 TCP 本身的設計就不是針對這類型的使用
譬如眾多封包中只要有一個失敗, TCP 本身就會針對所有發送的 Request 去進行一個重送的動作來確保封包傳輸正常。
HTTP/3 因為不再使用 TCP 為底層協定而是 UDP,所以當上述情況發生時,也只需要針對失敗的 Request 進行重送即可,也因為此協定帶來的好處, HTTP/3 的表現會相較於之前版本來得更快更穩。
Faster Encryption
HTTP/3 允許最初的 HTTP Request 以加密的形式去傳送。過往傳統的 HTTPS 封包傳輸過程中,最初的握手階段交換資訊時,這些還是基於非加密的形式,要等到握手完畢後才可以能力將接下來的資料進行加密。
而 QUIC 本身可以針對 Initial Connection 進行 TLS 的處理,這使得 HTTP/3 於加密方面可以更順利也更簡單。
文章後半部分提到關於目前 HTTP/3 實作的部分,有興趣的人可以參考參考原文
同時也有2部Youtube影片,追蹤數超過7,690的網紅暗黑悟空 Darkgoku,也在其Youtube影片中提到,大家記得訂閱 Facebook : https://www.facebook.com/%E6%9A%97%E9%BB%91%E6%82%9F%E7%A9%BA-darkgoku-383026532201992/ Instagram : https://www.instagram.com/db.dar...
udp是什麼 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
原文在這邊: https://www.teamblind.com/post/50-Reasons-Kubernetes-Sucks-S77O8VZ8
不知道大家看完有什麼想法
我個人認真看完後其實覺得真的是幹樵而已,可以單純當作幹話發洩文就好。有些理由沒什麼前後文,不知道想要表達什麼,有些感覺就是剛好自己踩到通點,基本上任何的軟體架構都可以有類似的議題
稍微看了一下
1. 難道你跑 openstack 就沒有這個感覺嗎? 我自己經驗是更痛苦
2. API 不相容這點我倒覺得還好,沒有遇到特別嚴重的,基本上 k8s 都會給予4-5個版本要使用者替換 apiVersion, 不看警告訊息無腦使用不能怪人
3. charts的問題應該是 Helm Charts 的問題,我倒覺得不是 k8s 自己的問題,不喜歡 charts 何不考慮 kustomize.
4,5 兩個應該是軟體發展一定會遇到的問題,任何系統遇到環境升級都是膽戰心驚吧?
9. 不確定是不是 kubectl 輸入到手酸XD,可以考慮 k9s?
10,11 最後談
13. 為什麼你會有一個兩年不升級的k8s叢集才是一個問題? 不如反過來問,如果你覺得兩年不升級沒問題,為什麼會突然想要升級
14. golang 中槍
19. 我覺得還是可以慢慢看,openstack 等VM為主題的 orchestration 實在是太不平易近人,學習曲線太高
...
32(a). 不太能理解 pause container 的問題是什麼XD,除非最小單位變成 Container 而不是 Pod,不然 Pause 的用途我還沒想到要怎麼取代
32(b). 完全同意, secret 帶來的好處只有透過編碼讓文件內容好處理,可以避掉一堆雙引號,分號等問題
10 跟 11 分別幹瞧了 overlay network 與 service mesh 兩個解決方案的痛點,我覺得很有趣的是這兩個點分別是從不同層面來解決問題。
早期大家碰到 Kubernetes 時都可能使用過 Flannel 這套 CNI,大部分情況下都是急於 VXLAN 來建置 overlay network,透過 UDP 標頭來重新包裝封包並且利用 Layer2,3,4 來重新搭建整個架構網路,是一個專注於底層網路L2-L4的解決方案
目前的 Service Mesh 的則是專注於 L7 的網路傳輸,期望能夠打造出一個串連不同 L7 應用程式的服務,譬如 HTTP,gRPC 等,讓這些應用程式的流量會根據不同 L7 的設定而有不同走法與走向。
只是為了轉發這些不同容器間的封包,最快速的做法就是大量利用已知的架構(iptables,route)等機制來控制各別網路連線,我覺得帶來的缺點就是架構非常龐大,規則非常複雜,大家除錯方式就是不停 restart/reboot,很少人真的能夠講清楚到底每個封包是怎麼被修改的
網路的世界真的非常有趣!
udp是什麼 在 矽谷牛的耕田筆記 Facebook 的最佳解答
最近跟大家分享一個 2020 年初左右的問題,這個問題的徵狀使用者透過 service 去存取相關服務時,會一直遲遲連接不上,直到 63 秒後服務才會通。
這個問題有兩種類型,一個是 63 秒後服務會通,一個則是 1 秒後會通,兩個背後的原因都一樣,這邊就來稍微簡介一下這個問題
# 發生條件
1. 使用 VXLAN 作為底層 Overlay Network,最常見的就是 Flannel 這套 CNI
2. Kubernetes 的版本不能太舊,至少要 1.16 以後,不過目前這個問題已經修復,所以現在要撞到除非特別指定版本
3. 使用的 Linux Kernel 版本也不能太新,目前該問題已經修復於大部分的 upstream
# 發生原因
1. VXLAN 本身是一個基於 UDP 的封裝協議,有一個已知的 bug 會使得其 checksum 發生錯誤,導致封包不會被遠端接收方給接收
2. kube-proxy 內關於 iptables 的設定沒有妥善,導致 VXLAN 封包會進行二次 SNAT
3. 第二次的 SNAT 就會觸發(1) 的 bug(當然還有其他條件,但是那些條件也剛好符合)
,最後導致封包的 checksum 不同,因此送到遠方就被拒絕
4. 底層的 TCP 建立連線時,會不停地嘗試,每次失敗都會等待更多時間,分別是1,2,4,8,16,32秒
5. 五次都失敗後, TCP 就會觸發重傳機制,下一次的重傳就不會進入到第二次的 SNAT,因此封包就不會踩到問題,因此通過
# 解決方法
1. 基本上這個問題要踩到要各方一起努力才會踩到,也因此修復方式也是多元化
2. Kernel 本身修復了關於 UDP 封裝的 Checksum 計算
3. Kubernetes 這邊則是針對 kube-proxy 進行強化,其使用的 iptables 規則會避免二次 SNAT 的情況
# 其他問題
1. 為什麼 TCP 重送後就不會踩到二次 SNAT? 這部分我看了相關的 issue 以及諸多文章都沒有看到解釋,都在探討 SNAT 後產生的 checksum,至於為什麼 TCP 重送後就通則是一個謎底
2. 為了解決這個謎體,我特別指定 kubernetes 版本並且重新編譯 Ubuntu 的 Linux Kernel 版本,盼望從 Kernel 中來觀察並且理解這個問題,目前已經有一些初步的進度。之後完成後會在撰寫文章跟大家分享這個問題
這個問題我認為非常有趣,也許自己的環境剛好沒有踩到,但是可以透過觀察不同的 issue 來研究各式各樣問題,也藉由這些過程來學習
相關 PR: https://github.com/kubernetes/kubernetes/pull/92035
udp是什麼 在 暗黑悟空 Darkgoku Youtube 的精選貼文
大家記得訂閱
Facebook : https://www.facebook.com/%E6%9A%97%E9%BB%91%E6%82%9F%E7%A9%BA-darkgoku-383026532201992/
Instagram : https://www.instagram.com/db.darkgoku/
如果有什麼意見的話,歡迎留言
喜歡的話, 請訂閱我頻度和給like
你的每一個點擊都是對我的支持,謝謝各位。
https://dbz-dokkanbattle.fandom.com/wiki/Super_Battle_Road
udp是什麼 在 全民瘋車Bar Youtube 的最佳解答
這次怡塵到南投參加小改款Mercedes-Benz C200公辦試駕
小改款C200主要重點就是除了將2.0引擎改為1.5T之外,首度導入Mild-hybrid的48V輕型複合動力技術的EQ Boost科技,有效降低油耗,將動能回收轉換成電能,在ECO模式的滑行模式中將引擎自動關閉,也成就引擎啟動過程中更加安靜且幾無震動等優點,並額外提供14hp/160Nm動力輸出。
究竟EQ Boost在實際上路後讓C200將較以往有什麼不同呢?就讓怡塵在影片中告訴大家吧!
什麼是23P?
23P是賓士安全及智慧駕駛輔助系統中選配套件其中一項代碼,包含了智能駕駛輔助,含Distronic智能定速測距輔助及智能轉向輔助/閃避轉向輔助/主動防撞輔助含路口車流辨識、行人偵測及車道壅塞防撞輔助/主動盲點輔助含離車警示輔助/主動車道維持輔助/Pre-Safe Plus主動後方安全防護等6項防護。
-
※訂閱全民瘋車Bar:
https://goo.gl/LRfZZ9
※怡塵FB粉絲團按讚:
https://goo.gl/VVsjmx
※怡塵IG追蹤:
https://goo.gl/GMM1Vd
-
合作請來信:
[email protected]
udp是什麼 在 6. UDP段格式 的推薦與評價
乙太網首部:源MAC地址是00:05:5d:61:58:a8,目的MAC地址是00:05:5d:67:d0:b1,上層協議類型0x0800表示IP。 IP首部:每一個位元組0x45包含4位版本號和4位首部長度,版本號 ... ... <看更多>