tls過程中，為何不用證書提供的公鑰加密數據或者加密私鑰，而要設計密鑰交換流程呢？
證書里的公鑰歸類於非對稱加密（Asymetric Cryptograghy），一個公鑰（Public Key）唯一對應一個私鑰（Private Key），公鑰加密的數據，私鑰可以解密，反之亦然。但這種非對稱加解密演算法耗費計算資源非常多，所以不適合數據流量的加密/解密，更適合用於認證對方的合法性（一次性的，所以耗費CPU就讓它耗費去吧），所以一般用於數字簽名，比如CA生成明文數字證書，然後將數字證書運行Hash演算法，生成Message Digest，用CA的私鑰加密Message Digest 即生成數字簽名（Digital Signature），這樣 明文數字證書 + 數字簽名 就是用戶拿到的數字證書（Certificate），任何擁有CA公鑰的個體，都可以解開數字簽名，意味著是CA私鑰加密無疑，因為公鑰與私鑰一一對應。
上文得到明文的數字證書+Message Digest，然後將明文數字證書運行相同的Hash演算法，得到本地的Message Digest，如果相同，表示數字證書沒有被篡改，安全可信，認證通過。
目前基於TLS的HTTPS通信，只是瀏覽器單向認證伺服器端的合法性，伺服器端提供自己的證書，瀏覽器認證伺服器合法就可以了，瀏覽器擁有伺服器的公鑰，而伺服器並沒有瀏覽器的公鑰，換句話說，如果採用證書公鑰加密，也只能是瀏覽器單向加密數據，伺服器用私鑰解密；而反向卻不可以。如果雙向認證，則瀏覽器都需要擁有自己的證書，目前這不現實。
目前的做法是：瀏覽器認證完伺服器，會協商Key Exchange方法，通常有兩種方法：
1 RSA演算法 瀏覽器生成一個Pre_Master_Key（隨機數）用伺服器的公鑰加密，傳輸給伺服器，然後雙方計算出Master_Key，以此推導出session key，MAC secret，這個session key 用於雙方加密/解密。
2 DH演算法 先生成Pre_Master_Key，再生成Master_Key，以此推導出session key，MAC secret，這個session key 用於雙方加密/解密。
採用對稱加密演算法如AES，相比非對稱加密演算法，計算資源消耗少，更適於大量的數據流量。
專業人士車小胖的答案很詳實，我補充另外一個考慮就是正向安全設計設計需要。
試想攻擊者記錄下了全部的傳輸數據，雖然短時間內無法得知加密的內容，但是只要時間足夠長，他總能夠發現密文對應的明文。比如alice加密後的密文是bob，那麼在足夠長的時間之後，攻擊者就能夠根據捕獲到的密文bob就能推算出明文alice。
另一個風險就是攻擊者記錄下了全部的傳輸數據。之後在某個特殊的時刻，攻擊者也獲得了傳輸的密鑰，那麼他就有能力破解加密內容。
在協商出隨機的加密密鑰之後按照對稱密鑰加密進行傳輸，在傳輸結束之後就丟棄加密的密鑰，那麼除非攻擊者在傳輸過程中就截獲了密鑰，不然攻擊者就只能保存下來等計算機技術發達之後暴力破解了。是我記錯了嗎，tls我記得是提供兩種密鑰協商方式的，一種是公鑰加密，一種是DH方式。
當然大家說的完美前向安全（pfs）是應用DH交換的一個好理由。
等我回頭重新學習一下tls密鑰協商再來更新回復。
=============================================
剛剛查了一下，RFC 5246中還是支持RSA的，不過在說明中有「如果想要pfs那麼請選擇DH」非對稱加密和對稱加密的效率確實不在一個量級。
可另外一個原因：服務端用私鑰加密了，豈不是任何人都能用公鑰解密？毫無隱私可言
公鑰密碼較慢，比如rsa演算法需要冪模運算，cpu並不適合這樣的運算，相反對稱加密演算法在設計時已經考慮到使用現有cpu支持的運算，比如shift，xor等cpu已有的指令，針對32位64位機器而設計，所以對稱密碼時間性能較好，intel cpu sse （2？）指令集還有專門用來做aes的指令。
綜上，公鑰密碼時間性能差，所以用於數字簽名和秘鑰交換等數據量較小的任務，加密交換會話密鑰後使用性能好的對稱密碼加密用戶數據
不過不考慮用戶從http web奔向https的體驗，那麼加密方式還可以跟堅固更繁瑣…
即使當前計算機計算能力突飛猛進，廣泛應用的https相較於傳統的http還是產生了可觀的延遲。
對於體驗至上的網路瀏覽，如果在每次訪問新網站的間隙就進行2048位的密鑰加解密，不僅大大增加了延遲，而且產生了更多安全數據的傳輸。這對於網頁瀏覽的體驗是致命的（其實去全站https的網站，諸位網友都已經明顯感覺到首次訪問的延遲了
證書作為信任鏈路里的一環，只是用來存儲到本地進行長期的單向站點身份驗證。用戶通過CA根證書來確認和鑒別該根下的其他該CA頒發給網站的證書真偽，獲取伺服器證書（公鑰在這裡）後，產生一個隨機值（對稱加密要用的客戶端私鑰），並用該證書加密傳給服務端用私鑰解密獲得客戶端隨機值（對稱加密鑰），然後雙方使用該密鑰對接下來的數據部分進行加密通信
再強調對稱加密（一般AES256）和非對稱加密（還是2048位我的媽）的cpu運算時間差距不是一般的大，樓上前輩都給出了參考預估。如果按照樓主的想法給tls強制每個環節用非對稱加密，可能現在所有web和app都要退回n年前的體驗了……
我們需要量子計算機嗯……因為intel擠牙膏現在的cpu， 2048位RSA私鑰解謎操作只能做到每秒幾百次，用來傳輸數據只能做到幾百KB/s，對稱加密演算法AES之類可以達到1GB/s
推薦閱讀：