OSI 沒學好，現在搞不清楚網路封包遺失偵測是在哪一層處理 >"<

TCP?

應該是 TCP 就可以處理掉，但是不知道為什麼有 application 層的通訊協定也自己實作偵測？

重複發明輪子說不定是想改變 TCP 原有的偵測行為

我之前一直以為 HTTPS 可以防止封包遺失，因為封包遺失解密會失敗。
但剛剛才知道和 SSL 完全沒關係 >"<

日 落 : 對完全沒有XD
HTTPS 只是三方握手時利用非對稱加密產生靜態密鑰，然後就不甘HTTPS的事了因為之後雙方都用靜態加密

TLS會防replay attack/packet duplication但不會幫忙重試…
application實作？用TCP不會吧…但如用HTTP3用了QUIC(UDP)就重新發明輪子自己做了，因為UDP不會補發，且TCP的補發機制不適合multiplex了後的情況

QUIC 會選用 UDP 就是要避免在網路不穩的環境底下一直重送資料 (ack?)，好險我不需要自己實作這些東西
原本是擔心 cifs 沒辦法處理調封包問題，想要改裝 restic/rest-server ，但 cifs 似乎會自己處理掉網路不穩的問題

其實 QUIC 底層會幫你處理一切重送的細節啦
不過在 TCP 的各種連線中, 通常是 TCP 自己在 ack 的來回階段確認有沒有掉包並且重送

附帶一提, 無線傳輸通常會有自己的重送機制, 不然等 TCP 觸發重送超級沒效率

聽起來整個麻煩，論文還是用抄的就好

🌻橘向日葵@呵𓁹‿𓁹 : 重送機制，是直接在硬體層處理掉嗎？
像是聯發科的 5G 晶片之類的

日 落 : 可以找找 LTE 的 ARQ 或 HARQ 機制, 但總之這個重送的過程會在無線段進行, 減少起始地與目的地之間的重送, 避免網路被送受信兩端的重傳轟炸

日 落 : Wifi也有自己的重傳，就是保障radio link那層的雜訊掉包。

但Wifi/LTE是保障link層，如果在整條path之中其他地方丟了包，wifi/LTE不會管。即是，如果你手機經Wifi上網去Google，去到router那層嘈音高了是會處理，但router出去ISP塞車而丟包了，又或ISP再往上塞車或任何原因丟包了，Wifi就理所當然不會管也不會知道。

日 落 : QUIC用UDP是為了…因為TCP的重傳機制是OS包辦的，但這麼多年來一直有新的更好的重傳算法，讓丟包恢復時間和各種性能等等有所提高。但這些研究成果要在所有OS落實的話都不知道等到何年馬月，Google就說算了，直接在Application層包辦。一來Chrome是他的，而Google的server side (Youtube等…)也可以自行推QUIC功能，這樣一推出來就馬上有一堆user受惠了，google的server/網絡性能也受惠。
而即使要更新算法換新版本的QUIC也可以更快 (可能幾周就搞定)，不用等全世界的OS都更新 (這可能幾十年都搞不定…想想Windows XP曾經活了多久)

感謝！

Google 的確常常搞一搞就變成 RFC 之類的，一個是使用者多，另一個就是提出的方案搞不好就接近最佳解 (或是沒有找到更好的方法)

不過即使TCP會重傳，application level通常也會做一些終極的retry。例如剛好切換網絡 (Wifi<>LTE…)、或Router ISP DHCP派了個新IP，IP必然會變，TCP必然會斷開。又，TCP的重傳有時會非常慢，最差情況會是以分鐘計才再重試或向application宣告斷線。
那Application可能會做一些auto-reconnect機制，盡快在網絡恢復正常後功能也恢復正常……

application 層處理網路連線問題應該很沒有效率吧？

日 落 : 用TCP作通訊的application，若然在application那一層是終極保底機制啦。
如link level (wifi, ethernet, LTE) retransmission是有局限性，TCP的也有局限性，最後防線就是application自己做。

而QUIC雖然implementation是和application一樣都在user space，但學術性來討論的話應該不算是application (OSI layer 7)，還是屬於OSI layer 4層面。只是，從來protocol 99%都是kernel space做，自Google這樣一搞就突破常規了。

apmk@住在「劏房」的 : 沒錯，各層依自己的需要做到該層有的封包驗證與重送是目前大家都能接受的現況
不過說真的OSI哪層大概就分類上可以當教材或聊天探討一下，實務上還有tunnel跟洋蔥這些東西，覺得UDP拆包行為不滿意要直通IP packet層自幹也可以，要戰戰不完的