上面做了個小實驗，設置了2個類型相同的 key，content-type；它們唯一不同的大小寫。可以看到結果，只保留了一個key，value值被拼接起來了。
域名解析的背景在以前，人們用IP進行互訪，後來發現IP太多不好記憶，便有了域名，比如 www.baidu.com，你一看就知道是百度搜尋引擎，而不需要管他的伺服器IP是多少，但是在最開始通信的時候，電腦路由器不認識域名，只認得IP啊，要怎麼去獲得對應的IP呢，這時候有了域名解析，就是去請求網絡上的DNS伺服器，讓他們來告訴你這個域名對應的IP是多少。
常見的DNS解析服務商有：阿里雲解析，萬網解析，DNSPod，新網解析，Route53（AWS），Dyn，Cloudflare等。
CDN加速前cdn加速前，域名解析過程如下：瀏覽器dns緩存
-> 系統dns緩存(Hosts文件)
-> 路由器dns緩存
-> 本地DNS伺服器(ISP運營服務提供商)
-> 本地DNS伺服器請求根域名伺服器(13個，不是只有13臺伺服器，分布在世界各地)，拿到dns記錄
-> 本地DNS伺服器根據拿到頂級域名伺服器的ip，去請求頂級域名伺服器(如.com頂級域名伺服器)
-> 本地DNS伺服器根據拿到二級域名伺服器的ip，去請求二級域名伺服器
-> ……
-> 直到X級域名伺服器返回我們目標域名對應的ip地址後，本地DNS伺服器緩存該dns記錄，然後返迴路由器
-> ……(層層緩存後，返回dns記錄結果)
-> 我們的客戶端拿到ip地址，利用該ip地址，封裝並發起http/http2請求。
備註：前面4個是遞歸查詢，一旦緩存可用，就直接返回，不會再進行後續步驟，後面是迭代查詢，最終獲取ip地址，才會返回。
不使用cdn時，利用ip發起請求的過程，如廣州的用戶要請求一個在北京的 IP 地址，過程如下：
廣州用戶 -> 廣州伺服器 -> 湖南伺服器 -> 湖北伺服器 -> 北京伺服器
這樣傳遞數據，就很浪費時間，那如果廣州伺服器就緩存了數據或資源呢，那不就可以就近獲取了。這便是cdn的部分策略了。
備註：TLD，意為頂級域名。
域名層級如下圖：
CDN（Content Delivery Network，內容分發網絡）是構建在現有網際網路基礎之上的一層智能虛擬網絡，通過在網絡各處部署節點伺服器，實現將源站內容分發至所有CDN節點，使用戶可以就近獲得所需的內容。
簡單的說，CDN的工作原理就是將您源站的資源緩存到位於全球各地的CDN節點上，用戶請求資源時，就近返回節點上緩存的資源，而不需要每個用戶的請求都回您的源站獲取，避免網絡擁塞、緩解源站壓力，保證用戶訪問資源的速度和體驗。
CDN的優點如下：
CDN服務縮短了用戶查看內容的訪問延遲，提高了用戶訪問網站的響應速度；(終端用戶內容獲取延時高，比如伺服器在北京，而用戶在廣州)
解決了源站網絡帶寬小、用戶訪問量大、網點分布不均等問題，緩解了源站的壓力；(中心伺服器負載過高，因為所有客戶端發起的請求都會打到伺服器上)
緩解甚至消除了不同運營商之間互聯的瓶頸造成的影響；
減輕了各省的出口帶寬壓力；
緩解了骨幹網的壓力；
優化了網上熱點內容的分布；
備註：第3~5點詳見參考連結[4]，第6點舉個例子，熱點內容的伺服器都在北京，如果我想獲取熱點內容，我就需要發送請求到北京的伺服器，但若有了cdn，我只需要就近伺服器獲取熱點內容，這樣就分攤優化熱點內容的分布了。
CDN節點緩存策略CDN通過在現有網絡中增加一層新的緩存節點，將源站的資源發布到最接近用戶的網絡節點，使得客戶端在請求時直接訪問到就近的CDN節點並命中該資源，減少回源情況，提高網站訪問速度。
CDN緩存節點可分為L1節點（一級節點）和L2節點（二級節點），請求的流程是：客戶端-->CDN_L1-->CDN_L2-->源站。CDN的L1節點分布在全國各省市，L2節點分布在幾個大區下，可以把L2節點理解為匯聚式節點，簡單架構如下圖所示。
CDN節點緩存策略如下：
客戶端向CDN節點發起連接請求，當L1節點有緩存資源時，會命中該資源，直接將數據返回給客戶端。當L1節點無緩存資源時，會向L2節點請求對應資源，如果L2節點有緩存資源，則將資源同步到L1節點，並返回給用戶；如果L2節點無緩存資源，則直接回客戶源站獲取資源，並按照配置的緩存策略進行緩存。
為了方便理解，再舉一個例子，假設有杭州移動節點L1-hz和寧波移動節點L1-nb兩個L1節點，這兩個L1節點都回源到同一個L2這個節點，源站在北京。這幾個CDN節點初始的時候都沒有用戶的緩存資源。當ABC三個用戶依次請求同一個圖片的時候，過程如下：
杭州移動用戶A被CDN調度到杭州移動L1-hz節點，L1-hz由於沒有緩存，則回源到L2，L2由於也沒有緩存，則回源到北京源站，請求到數據以後再返回給L1-hz，L1再返回給用戶A。
用戶A請求完以後，L1-hz和L2節點都有了緩存資源。此時杭州移動用戶B也開始訪問這個圖片，用戶B也被分配到了L1-hz節點，由於L1-hz已經有這個圖片的緩存了，因此不需要再去回源了，而是直接返回緩存給用戶B。
寧波移動用戶C此時也訪問了同一個圖片，用戶C被分配到了寧波移動節點L1-nb，由於L1-nb還沒有緩存，就會回源到L2，而L2已經有緩存，因此L2會直接返回緩存數據給L1-nb，然後L1-nb再返回給用戶B。此過程存在L1-nb向L2回源的過程，而L2不需要再去回源到源站了。
通過CDN加速，杭州用戶A和B可以直接從杭州節點讀取緩存數據，寧波用戶C可以直接從寧波節點讀取數據，不需要每一次都去請求北京伺服器了，提高了用戶側的訪問速度，降低了伺服器壓力。
備註：
CDN工作原理通過以下案例，可以進一步了解CDN的工作原理。
假設加速域名為www.a.com， 接入CDN網絡，開始使用加速服務後，當終端用戶（北京）發起HTTP請求時，處理流程如下圖所示。
當終端用戶（北京）向www.a.com 下的某資源發起請求時，首先向LDNS（本地DNS）發起域名解析請求。
LDNS檢查緩存中是否有www.a.com 的IP位址記錄。如果有，則直接返回給終端用戶；如果沒有，則向授權DNS查詢。
當授權DNS解析www.a.com 時，返回域名CNAME www.a.tbcdn.com 對應IP位址(實際就是DNS調度系統的ip地址)。
域名解析請求發送至DNS調度系統，DNS調度系統為請求分配最佳節點IP位址。
LDNS獲取DNS返回的解析IP位址。
用戶獲取解析IP位址。
用戶向獲取的IP位址發起對該資源的訪問請求。
如果該IP位址對應的節點已緩存該資源，則會將數據直接返回給用戶，例如，圖中步驟7和8，請求結束。
如果該IP位址對應的節點未緩存該資源，則節點向源站發起對該資源的請求。獲取資源後，結合用戶自定義配置的緩存策略，將資源緩存至節點，例如，圖中的北京節點，並返回給用戶，請求結束。
什麼資源可以被加速在HTTP請求的資源，請求可以分為靜態請求和動態請求。
備註：（以下為個人見解）
動態請求中，路由優化是指請求路徑優化為最短傳輸路徑(不用經過太多伺服器)；傳輸優化是指同時部署多個運營商的伺服器(比如電信、聯通、移動都部署上)，避免跨運營商間的請求轉換。
靜態內容可以在CDN上緩存多久，這個是根據CDN的緩存策略的。用戶通過亞馬遜雲/阿里雲/騰訊雲控制臺按照文件類型和目錄設置緩存時間，針對靜態資源配置指定目錄和文件後綴名的緩存過期時間和優先級，資源過期後，自動從CDN節點刪除。
CDN網絡的組成要素對於普通的Internet用戶，每個CDN節點就相當於一個放置在它周圍的網站伺服器. 通過對dns的接管，用戶的請求被透明地指向離他最近的節點，節點中CDN伺服器會像網站的原始伺服器一樣，響應用戶的請求。由於它離用戶更近，因而響應時間必然更快。
從上面圖中 虛線圈起來的那塊，就是CDN層,這層是位於 用戶端 和 站點伺服器群 之間。
DNS智能調度系統(比如f5的3DNS)
緩存功能服務
負載均衡設備(如lvs, F5的BIG/IP)
內容Cache伺服器(如squid）
共享存儲
名詞解釋 A記錄：解析域名到IPA記錄，即Address記錄，它並不是一個IP或者一個域名，我們可以把它理解為一種指向關係：域名 www.xx.com → 222.222.222.222
也就是當你訪問這些域名或者主機名的時候，DNS伺服器上會通過A記錄會幫你解析出相應的IP位址，以達到後續訪問目的。
所以A記錄是IP解析，直接將域名或主機名指向某個IP。
CNAME記錄，也叫別名記錄，相當於給A記錄中的域名起個小名兒，比如www.xx.com的小名兒就叫www.yy.com好了，然後CNAME記錄也和A記錄一樣，是一種指向關係，把小名兒www.yy.com指向了www.xx.com，然後通過A記錄，www.xx.com又指向了對應的IP：www.yy.com → www.xx.com → 111.111.111.111
這樣一來就能通過它的小名兒直接訪問111.111.111.111了。
這時候有人問：這不多了一步嘛，不嫌麻煩？
假如這個時候我又想給原域名取幾個小名兒，分別叫www.cc.com和www.kk.com那麼存在下列指向關係：
www.yy.com → www.xx.com → 111.111.111.111
www.cc.com → www.xx.com → 111.111.111.111
www.kk.com → www.xx.com → 111.111.111.111
突然伺服器的IP位址因為一些不可描述的原因要換了，不再是111.111.111.111了，換成了333.333.333.333，這時候你發現，只要把www.xx.com的指向修改一下即可：
域名 www.xx.com → 333.333.333.333
這時候你又發現了，原來他的小名兒不需要做更改，直接就能訪問伺服器，因為他們都只指向了www.xx.com，伺服器IP改動與否，它們不管。
那麼假如不用CNAME，直接做A記錄會怎樣？
www.yy.com → 111.111.111.111
www.cc.com → 111.111.111.111
www.xx.com → 111.111.111.111
www.kk.com → 111.111.111.111
那麼當111.111.111.111更改的時候，全部相關A記錄指向關係都要做更改，這時會很麻煩。
比較多的是用在CDN加速上。
舉個例子：假如你公司中的一臺IP為1.1.1.1的伺服器，註冊了域名為www.dd.com，要對外提供客戶訪問。隨著公司越做越大，訪問量也越來越多，伺服器頂不住了，你去找CDN提供商購買CDN加速服務，這個時候他們要求你的域名做個CNAME指向他們給你的一個域名叫www.xdd.com，當用戶訪問www.dd.com的時候，本地DNS會獲得CDN提供的CNAME域名：www.xdd.com，然後再次向DNS調度系統發出請求，通過DNS調度系統的智能分析，把這個www.xdd.com指向一個（離用戶最近的）CDN提供商的伺服器IP，讓用戶就近取到想要的資源（如訪問網站），這樣就可以大大降低了延遲。
當 cdn 緩存伺服器中沒有符合客戶端要求的資源的時候，緩存伺服器會請求上一級緩存伺服器，以此類推，直到獲取到，如果最後還是沒有，就會回到我們自己的伺服器(簡稱源站)去獲取資源。
回源的時機：
回源host回源host：回源host決定回源請求訪問到源站上的具體某個站點。
例子1：源站是域名源站為www.a.com, 回源host為www.b.com, 那麼實際回源是請求到 www.a.com 解析到的IP, 對應的主機上的站點www.b.com
例子2：源站是IP源站為1.1.1.1, 回源host為www.b.com,那麼實際回源的是1.1.1.1對應的主機上的站點 www.b.com
協議回源指回源時使用的協議和客戶端訪問資源時的協議保持一致，即如果客戶端使用 HTTPS 方式請求資源，當CDN節點上未緩存該資源時，節點會使用相同的 HTTPS 方式回源獲取資源；同理如果客戶端使用 HTTP 協議的請求，CDN節點回源時也使用HTTP協議。
TTLTTL，Time-To-Live，意思為一條域名解析記錄在DNS伺服器中的存留時間。當各地的DNS伺服器接受到解析請求時，就會向域名指定的NS伺服器(NS，Name Server，名稱伺服器，DNS是最著名的NS伺服器)發出解析請求從而獲得解析記錄；在獲得這個記錄之後，記錄會在DNS伺服器中保存一段時間，這段時間內如果再接到這個域名的解析請求，DNS伺服器將不再向NS伺服器發出請求，而是直接返回剛才獲得的記錄；而這個記錄在DNS伺服器上保留的時間，就是TTL值。
TTL的數值應該如何設置？
增大TTL值，減少域名解析時間。
減小TTL值，及時更新網絡。
邊緣節點邊緣節點，指距離最終用戶接入具有較少的中間環節的網絡節點。
CDN 調度策略CDN 調度是指通過各種策略將客戶端請求調度到合理的目標機房。以達到成本、質量（可用性、平均速度）的最佳控制。
調度形式一般有以下幾種：
DNS 調度
HTTP DNS 調度
302 調度
路由調度（Anycast）
DNS 調度基於請求端 local DNS 的出口 IP 歸屬地以及運營商的 DNS 調度。
DNS 調度的問題：
HTTP DNS 調度客戶端請求固定的 HTTP DNS 地址，根據返回獲取解析結果。可以提高解析的準確性(不像DNS調度，只能通過local DNS IP來做決策)，能很好的避免劫持等問題。
當然這種模式也有一些問題，例如客戶端每次加載URL都可能產生一次HTTP DNS查詢，這就對性能和網絡接入要求很高。
302調度基於客戶端 IP 和 302 調度集群進行實時的流量調度。
我們來看一個例子：
訪問 URL 連結後，此時請求到了調度群集上，我們能拿到的客戶端信息有 客戶端的出口IP（絕大多情況下是相同的），接下來算法和基於 DNS 的調度可以是一樣的，只是判斷依據由 local DNS 出口 ip 變成了客戶端的出口IP。
瀏覽器收到302回應，跟隨 Location 中的 URL，繼續發起 http 請求，這次請求的目標 IP 是CDN 邊緣節點，CDN節點會響應實際的文件內容。
302 調度的優勢：
302 調度的劣勢：
AnyCast BGP路由調度基於 BGP AnyCast 路由策略，只提供極少的對外 IP，路由策略可以很快的調整。
目前 AWS CloudFront、CloudFlare 都使用了這種方式，在路由層面進行調度。
這種方式可以很好地抵禦 DDOS 攻擊，降低網絡擁塞。
當然這種方式的成本和方案設計都比較複雜，所以國內的 CDN 目前還都是用 UniCast 的方式。
除了靜態資源，API 是否可以緩存？動態加速的對象是動態生成的網頁，動態加速一般是對針對內容（如資料庫信息等）在用戶與- 源站之間建立高速通道，通過路由優化、TCP加速等技術手段對動態內容進行加速，降低節點到源站之間的時延，從而大大降低了用戶訪問動態網頁的延遲。
其實這個問題我沒有找到比較合適的解答，以下是個人見解：
我們使用 cdn 的原因是，我們經常有一些比較頻繁請求且容量比較大的文件，並且更新頻率不那麼高的文件。這些文件如果我們都放在自己的伺服器上，對於客戶端，問題在於延長訪問時間；對於伺服器端是佔用伺服器端的資源。所以我們採用分布式的方式扔在 cdn 上。
但是 API請求不同，
首先API請求經常更新，就算是簡單的get請求，推送更新到所有 cdn 節點同樣是需要耗費資源(如帶寬，會對源站有壓力)的。
如果API請求是和用戶信息等相關聯的get請求，這種不適合進行cdn緩存，因為總是要進行回源，做緩存沒有意義，而且還不安全；
如果是post請求，那壓根不用考慮cdn；
cdn 判斷是否緩存是依靠 url，意味著cdn只能緩存 get 請求，所以cdn的應用範圍是有限的。
所以 API 是不適合放在 cdn 上的。但是如果你的內容是相對靜態的，不涉及和用戶信息關聯，更新不頻繁，那麼勉強可以考慮用cdn加速，如配置信息(但最好不要)。
資源的過期如何判定？cdn 是如何更新數據的？資源過期時間就是請求/響應頭部來判定(詳情請自行搜索 強緩存和協商緩存 等關鍵詞)。
那麼 cdn 是如何更新數據的？
不同運營商寬帶如何實現互相訪問的？通過BGP Peering(對等)等方式實現流量交換(相互訪問)，如兩家運營商約定在特定地點(網際網路交換點)集中進行流量交換。
所以如果你的運營商是電信，可以直接通過電信伺服器訪問你的目標IP，不需要經過交換轉換，那肯定能大幅提高訪問速度，當然還要看其他限制原因，如本市的電信，還是跨省的電信。
參考連結：
DNS缺點&升級方案(HttpDns，解決Local DNS劫持)
計算機網絡基礎之CDN
阮一峰的DNS 原理入門
不同運營商寬帶如何實現互相訪問的？
淘寶的cdn緩存方案，包括三級緩存結構、多副本清除CDN緩存方案等
CDN節點緩存策略、CDN工作原理、什麼資源可以被加速
CDN加速原理
什麼是CNAME
關於 cdn、回源等問題一網打盡
CDN 調度策略