# 7. 擴展 協議強制規定接收方必須讀取并忽略掉所有未知幀類型的幀。雙方必須在逐跳原則（hop-by-hop basis）基礎上協商使用新的幀，這些幀的狀態無法被改變，并且也不受流控制。 是否應該允許添加擴展的這個話題在制定http2協議的時候被反復討論了很久。在draft-12之后，最終確定允許添加擴展。 但擴展不再是協議本身的一部分，它被記錄在核心協議規范之外。到目前為止，有兩種曾被http2工作組包含在協議里的幀，很可能率先被納入協議的擴展部分。這兩個曾被當作“原生”的幀非常流行，所以接下來我會詳細討論它們。 ## 7.1. 備選服務（Alternative Services） 隨著http2逐漸被接受，我們有理由猜測，相對于HTTP 1.x，TCP連接會更長且被保持的更久。對客戶端來講，最好是到每個主機/站點的每一條連接都可以做盡可能多的事情，這也需要每個連接保持開啟更長的時間。 但這會影響到HTTP負載均衡器的正常工作，比如在一個網站想建議客戶端連接到另外一個主機的時候。通常，網站此舉的目的在照顧性能，但也可能是正常維護或類似原因。 服務器將會通過發送Alt-Svc頭（或者http2的ALTSVC幀）來告知客戶端另一個備選服務。即另外一條指向不同的服務源、主機或端口，但卻能獲取同樣內容的路由。 客戶端可以嘗試異步的連接到該服務，或者可用的話就選擇備選方案。 **7.1.1. 機會型TLS（Opportunistic TLS）** Alt-Svc頭部允許服務器通過`http://`告訴客戶端：同樣的內容也可以通過TLS連接來獲取。 這是個還在討論中的功能。這樣的連接會導致未認證的TLS，并且在任何地方也不會被廣播為“安全”，同時不會在客戶端界面上出現任何鎖標識，所以沒法讓用戶知道這其實不是常規的HTTP連接。這就是很多人強烈反對機會型TLS的原因。 ## 7.2. 阻塞（Blocked） 當有數據需要被發送，但流控制卻禁止發送任何數據時，此類型的幀將會被發送**僅**一次。這種幀設計的目的在于，如果你接收到了此幀，那么連接中必然有錯誤發生或者是得到了低于期望的傳輸速度。 在此幀被放到協議擴展部分之前，draft-12中的一段話： > 阻塞幀被包含在此版本的草案中作為實驗，如果沒有得到良好的反饋，就把它刪除。