1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        為什么 IPv6 難以取代 IPv4

        共 4559字,需瀏覽 10分鐘

         ·

        2020-07-31 18:22


        為什么這么設計(Why’s THE Design)是一系列關于計算機領域中程序設計決策的文章,我們在這個系列的每一篇文章中都會提出一個具體的問題并從不同的角度討論這種設計的優(yōu)缺點、對具體實現(xiàn)造成的影響。如果你有想要了解的問題,可以在文章下面留言。

        網(wǎng)絡層協(xié)議承擔了分組(Packet)轉發(fā)和路由選擇兩大功能,它能夠為上層提供在不同主機之間運輸分組的職責,IP 協(xié)議作為網(wǎng)絡層協(xié)議,它雖然只能提供無連接的、不可靠的服務,但是它在今天的互聯(lián)網(wǎng)中起到了極其關鍵的作用。

        圖 1 - 互聯(lián)網(wǎng)協(xié)議簇

        在一般情況下,當我們想要訪問其他主機提供的服務時,都需要通過 IP 地址來訪問目標主機,只有擁有了 IP 地址才能在互聯(lián)網(wǎng)上被其他主機訪問。IP 地址就像家庭住址,我們需要保證所有主機 IP 地址的唯一性,這樣才能找到正確的主機。

        作為在 1974 年誕生的 IP 協(xié)議[^1],第一個主要版本 IPv4 使用 32 位表示地址,總共可以提供 2^32 (4,294,967,296) 個 IP 地址[^2]。42 億個 IP 地址雖然看起來很多,但是可用的 IPv4 地址數(shù)量在最近幾年一直在減少,早在 2011 年,頂級的 IPv4 地址就已經(jīng)被全部分配出去了[^3]。

        圖 2 - IPv4 地址的小數(shù)表示

        為了解決 IP 地址即將被耗盡的問題,IETF 在 1998 年就發(fā)布了 IPv6 協(xié)議的草稿[^4]并在 2017 年正式成為互聯(lián)網(wǎng)標準[^5]。IPv6 使用 128 位的 IP 地址,總共可以表示 2^128 個地址,IPv6 甚至可以為地球上的沙子分配獨立的地址[^6]:

        新版本的互聯(lián)網(wǎng)協(xié)議 IPv6 不僅能夠一勞永逸地解決 IP 地址即將被耗盡的問題,還能提高網(wǎng)絡的傳輸速度以及安全性。IPv6 協(xié)議的設計者最初認為隨著 IPv4 地址的快速減少,IPv6 會被快速采納,它們最初估計 IPv6 協(xié)議會在 2003 年在全球部署,但是從今天的角度來看,這些預測還是過于樂觀了[^7]。

        本文想要分析的問題是,為什么 IPv6 協(xié)議有如此之多的好處并且能夠解決 IPv4 的地址短缺問題,但是哪怕在最初預估的 2003 年后又過了 17 年,IPv6 協(xié)議也沒有被大規(guī)模采納。我們在這里會討論以下幾個原因:

        • NAT 技術很大程度上緩解了 IPv4 地址短缺的問題;
        • IPv6 協(xié)議在設計時沒有考慮與 IPv4 的兼容性問題;
        • 更細粒度的管控 IPv4 地址并回收閑置的資源;

        NAT

        網(wǎng)絡地址轉換(Network Address Translation、NAT)是一種在 IP 數(shù)據(jù)包通過路由器時修改網(wǎng)絡地址的技術,它能夠將當前地址空間中的 IP 地址映射到另一個地址空間。當切換網(wǎng)絡或者上游的 ISP 出現(xiàn)改變時,NAT 技術可以避免修改網(wǎng)絡中全部節(jié)點的 IP,我們可以將 NAT 技術理解成一個轉換表,其中存儲著外部地址和端口到內部地址和端口的轉換關系。

        圖 3 - 網(wǎng)絡地址轉換技術

        當數(shù)據(jù)包從內部訪問外部網(wǎng)絡時,NAT 會為當前請求分配一個端口、覆寫數(shù)據(jù)包中的源地址和端口并將地址和端口信息存儲到本地的轉換表中;當數(shù)據(jù)包從外部進入網(wǎng)絡內部時,NAT 會根據(jù)數(shù)據(jù)包的 IP 地址和端口號查找到私有網(wǎng)絡中對應的主機和端口號并覆寫數(shù)據(jù)包中的目的地址和端口。

        圖 4 - NAT 轉換表

        通過 NAT 這一中間層,我們不僅可保護私有的網(wǎng)絡,還能緩解 IP 地址的短缺問題。不過 NAT 技術也并不是只有好處,它也帶來了很多的問題,在 NAT 網(wǎng)絡下的主機并不能與對端建立起真正的端到端連接,也不能參與部分因特網(wǎng)協(xié)議[^8],除此之外,NAT 協(xié)議帶來的以下問題也備受爭議[^9]:

        1. NAT 使用的端口號是用于進程尋址的,而不是用于主機尋址的;
        2. NAT 路由器作為第三層(網(wǎng)絡層)的設備,它應當只處理達到網(wǎng)絡層的分組;
        3. NAT 違反了主機應當直接彼此對話的原則;

        雖然 NAT 帶來了很多的爭議和問題,但是 NAT 已經(jīng)成為了整個互聯(lián)網(wǎng)中廣泛使用的技術,工程師也嘗試通過各種 NAT 穿越技術來解決它帶來的問題,例如:SOCKS、UPnP 和 ALG 等[^10]。

        兼容性

        軟件和協(xié)議都會遵循當下以及可預測的未來進行設計,但是我們很難預測未來的具體走勢,當下的設計也會隨著場景的變換變得逐漸不適用。所有的軟件和協(xié)議都是需要更新迭代的,在更新的過程中我們就需要考慮兼容性,兼容性一般可以分成向前兼容(Forward compatibility)和向后兼容(Backward compatibility)兩種:

        • 向前兼容:老版本系統(tǒng)可以接收并處理新版本系統(tǒng)產生的數(shù)據(jù);
        • 向后兼容:新版本系統(tǒng)可以接收并處理老版本系統(tǒng)產生的數(shù)據(jù);
        圖 5 - 系統(tǒng)的兼容性

        這兩種不同的兼容性可以起到不同的作用,如果 IPv6 協(xié)議與 IPv4 是向前兼容的,那么用于處理 IPv4 協(xié)議的硬件設備可以不用更新就能處理 IPv6 的數(shù)據(jù),不過不更新系統(tǒng)也無法享受 IPv6 帶來的好處;如果 IPv6 協(xié)議與 IPv4 協(xié)議是向后兼容的,那么 IPv6 的硬件可以同時處理 IPv4 和 IPv6 的數(shù)據(jù)包,只要使用 IPv6 設備替換 IPv4 設備就可以給整個網(wǎng)絡無縫升級。

        如果 IPv4 和 IPv6 能夠具有向前兼容性或者向后兼容性,那么 IPv6 協(xié)議的推進也可能也沒有這么復雜,但是 IPv6 協(xié)議在設計時就沒有考慮與更早版本協(xié)議的兼容性。雖然 IPv4 和 IPv6 雖然都是 IP 協(xié)議,不過因為它們兩者互不兼容,所以我們只能通過雙協(xié)議棧、隧道技術或者 NAT64 實現(xiàn)協(xié)議的過渡:

        圖 6 - 雙協(xié)議棧

        IPv6 協(xié)議想要擺脫歷史的包袱,實現(xiàn)完全不兼容的設計是可以理解的,在過去幾十年應用 IP 協(xié)議的過程中,我們遇到了很多的問題,如果要背著歷史的包袱繼續(xù)前行也不是不可以,但是作為互聯(lián)網(wǎng)的核心協(xié)議,雖然 IP 協(xié)議的設計者承認 IPv6 沒有實現(xiàn)向前兼容是最大的錯誤[^11],但是作者認為通過不兼容的方式快速擺脫歷史的包袱從長期來看也是好事。

        地址管控

        IPv4 的地址雖然從總體上來看確實是稀缺資源,不過與其他的稀缺資源一樣,如何合理分配資源并提供使用率一直都是比較大的問題。IANA(Internet Assigned Numbers Authority) 和 RIR(Regional Internet Registries) 是負責分配 IP 地址的組織,除了一些為專有網(wǎng)絡預留的 IP 地址之外,剩余的地址一般都是通過子網(wǎng)以地址塊的形式分配。

        在互聯(lián)網(wǎng)協(xié)議的早期開發(fā)階段,子網(wǎng)是通過 IP 地址最左側的 8 位劃分子網(wǎng),但是因為這種方式只允許劃分 256 個網(wǎng)絡,所以在 1981 年被分類網(wǎng)絡架構(Classful Network Architecture)迅速替代。分類網(wǎng)絡架構中包含 A、B 和 C 三類網(wǎng)絡[^12]:

        Class網(wǎng)絡數(shù)主機數(shù)
        A12816,777,214
        B16,38465,534
        C2,097,152254

        A 類地址只能分配給 128 個不同的網(wǎng)絡,每個網(wǎng)絡中可以包含 1,600 萬主機,而 C 類地址可以分配給 200 萬組織,網(wǎng)絡中可以包含 200 多個主機。通過對 IP 地址的分類,我們能夠更合理地分配 IP 地址塊,不過雖然它對 IP 地址進行了分類,但是它對地址的劃分還是比較粗糙。

        IETF 在 1993 年提出的無類別域間路由(Classless Inter-Domain Routing、CIDR)替代了分類網(wǎng)絡架構,CIDR 基于可變長子網(wǎng)掩碼(Variable-length Subnet Masking、VLSM),它的主要目的有兩個[^13]:

        1. 緩解互聯(lián)網(wǎng)中路由器中轉發(fā)表的增長速度;
        2. 緩解 IPv4 地址耗盡的速度;

        分類網(wǎng)絡架構中對地址的劃分還是有些過于理想,過小的地址塊往往不夠用、稍大的地址塊卻會造成較大的浪費。與分類網(wǎng)絡架構只使用 8、16 和 24 固定長度的子網(wǎng)掩碼將 IP 地址塊劃分成三類不同,CIDR 會使用可變長度的子網(wǎng)掩碼來劃分地址塊,如下所示的 CIDR 表示中,N 表示前綴長度,它可以是從 0 到 32 的任意值:

        A.B.C.D/N

        A.B.C.D/8、A.B.C.D/16A.B.C.D/24 就可以分別表示分類網(wǎng)絡架構中的 A、B 和 C 三類不同的地址塊,同時也可以使用其他的數(shù)字更靈活的表示特定網(wǎng)絡數(shù)和主機數(shù)的子網(wǎng)。

        除了更細粒度的地址分配之外,回收不再使用的 IP 資源并投入再利用也是延長 IPv4 壽命的重要手段,不過在這里我們就不做展開了。從 IP 地址的分配中,我們能看到資源從充足到稀缺,人對于資源使用態(tài)度的轉變,從最開始粗糙的分配方式到后來細粒度的管控,充足的資源總是會被濫用,只有當資源真正變得稀缺時,我們才開始精打細算。

        總結

        IPv4 協(xié)議從 1981 年發(fā)布到今天已經(jīng)過去了將近 40 年,在過去的這段時間里,它作為互聯(lián)網(wǎng)協(xié)議簇中的重要協(xié)議承擔著分組轉發(fā)和路由選擇的重要責任,隨著網(wǎng)絡環(huán)境和終端設備變得越來越復雜,我們也需要更多的 IP 地址滿足今天的需求。

        圖 7 - 訪問 Google 的 IPv6 協(xié)議采納率[^14]

        IPv6 協(xié)議擺脫了很多歷史的包袱輕裝前行,雖然越來越多的網(wǎng)站和網(wǎng)絡設備都開始支持 IPv6,但是因為很多原因 IPv6 最終也很難完全取代 IPv4 協(xié)議,我們重新回顧一下本文的內容:

        • NAT 技術可以很大程度上緩解 IPv4 的地址短缺問題并且能夠保護私有內部的網(wǎng)絡,提供防火墻的功能;
        • IPv4 與 IPv6 協(xié)議完全不兼容,我們需要引入雙協(xié)議棧、隧道技術或者 NAT64 解決兼容性問題,而應用這些技術也需要額外的成本;
        • 通過對資源的細粒度管控并回收不再使用的 IP 地址,可以延緩 IP 地址耗盡的時間;

        工程師的想象力是無窮的,在過去的十幾年間,我們嘗試通過各種辦法為 IPv4 協(xié)議續(xù)命延緩 IP 資源耗盡的時間,不過在可預見的未來 IPv4 協(xié)議也終將被 IPv6 替代,我們也會擁有幾乎用不完的 IP 地址。到最后,我們還是來看一些比較開放的相關問題,有興趣的讀者可以仔細思考一下下面的問題:

        • IPv5 協(xié)議是做什么的?為什么沒有聽說過 IPv5 協(xié)議?
        • 你覺得 IPv6 協(xié)議的份額會在多久之后超過 IPv4?

        如果對文章中的內容有疑問或者想要了解更多軟件工程上一些設計決策背后的原因,可以在博客下面留言,作者會及時回復本文相關的疑問并選擇其中合適的主題作為后續(xù)的內容。




        推薦閱讀



        學習交流 Go 語言,掃碼回復「進群」即可


        站長 polarisxu

        自己的原創(chuàng)文章

        不限于 Go 技術

        職場和創(chuàng)業(yè)經(jīng)驗


        Go語言中文網(wǎng)

        每天為你

        分享 Go 知識

        Go愛好者值得關注


        瀏覽 48
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            卡戴珊裸乳无打码 | 国产666 | 久久久久国色AV免费观看麻豆 | 欧美操操逼| 日本人妖中文字幕久久 | 男女牲交全免费 | 日本三级网 | 大粗鸡巴久久久久久久久 | 成人午夜视频精品 | 夜夜嗨AV一区二区三区Y.S下载 |