作者：李成文粹淋；
前言
最近在周報系統(tǒng)和格子機項目中都出現(xiàn)了在測試服能夠正常運行绢掰，部署到正式服之后就出現(xiàn)問題，這些問題的原因就是：一般測試服都沒有安全性的需求，所以都是使用http協(xié)議。但是正式服現(xiàn)在一般都是使用更加安全的https協(xié)議州丹。
問題
問題的關鍵就是在于這個協(xié)議的問題葛碧，瀏覽器默認是不允許在https里面調(diào)用http資源的蒜哀。在這里根據(jù)我所遇到的情況大概是這樣子的：
- 在IE瀏覽器瀏覽器中使用鏈接加載資源時會彈出一個對話框：
- 在微信的瀏覽器中引入圖片資源時會報一個警告(但是圖片會正常加載)：
- 在https頁面中向http地址發(fā)起ajax請求時罗心，瀏覽器會阻止掉這個請求，然后報一個Mixed Content的錯誤含思。
- 在https頁面中使用webSocket時需要注意崎弃，必須使用
wss協(xié)議才能夠發(fā)起連接，不然也會報錯：
問題分析
https協(xié)議與https協(xié)議的區(qū)別
在解決這個問題之前首先需要知道https是什么含潘，與http的區(qū)別在什么地方饲做。
https安全超文本傳輸協(xié)議：
它是一個安全通信通道，它基于HTTP開發(fā)调鬓，用于在客戶計算機和服務器之間交換信息艇炎，它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版腾窝。它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中缀踪，用于對數(shù)據(jù)進行壓縮和解壓操作，并返回網(wǎng)絡上傳送回的結(jié)果虹脯。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層驴娃。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信循集。）SSL使用40 位關鍵字作為RC4流加密算法唇敞，這對于商業(yè)信息的加密是合適的。HTTPS和SSL支持使用X.509數(shù)字認證，如果需要的話用戶可以確認發(fā)送者是誰疆柔≈渚總的來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸旷档、身份認證的網(wǎng)絡協(xié)議要比http協(xié)議安全模叙。
在URL前加https://前綴表明是用SSL加密的，你的電腦與服務器之間收發(fā)的信息傳輸將更加安全鞋屈。 Web服務器啟用SSL需要獲得一個服務器證書并將該證書與要使用SSL的服務器綁定范咨。
https與http的區(qū)別：
- https協(xié)議需要到ca申請證書，一般免費證書很少厂庇，需要交費渠啊。
- http是超文本傳輸協(xié)議，信息是明文傳輸权旷，https 則是具有安全性的ssl加密傳輸協(xié)議替蛉。
- http和https使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。
- http的連接很簡單,是無狀態(tài)的炼杖。
- HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸灭返、身份認證的網(wǎng)絡協(xié)議 要比http協(xié)議安全盗迟。
什么是混合內(nèi)容（Mixed Content）
很明顯上面報的錯都是與Mixed Content是有關系的坤邪，Mixed Content就是：
當用戶訪問使用HTTPS的頁面時，他們與web服務器之間的連接是使用SSL加密的罚缕，從而保護連接不受嗅探器和中間人攻擊艇纺。
如果HTTPS頁面包括由普通明文HTTP連接加密的內(nèi)容，那么連接只是被部分加密：非加密的內(nèi)容可以被嗅探者入侵邮弹，并且可以被中間人攻擊者修改黔衡，因此連接不再受到保護。當一個網(wǎng)頁出現(xiàn)這種情況時腌乡，它被稱為混合內(nèi)容頁面盟劫。
詳情可見：https://developer.mozilla.org/zh-CN/docs/Security/MixedContent
解決方案
相對協(xié)議
如果你的網(wǎng)站同時準備了https資源和http資源，那么使用相對協(xié)議可以實現(xiàn)根據(jù)當前網(wǎng)站的協(xié)議与纽，瀏覽器自行選擇通過https還是http發(fā)起請求侣签，而相對協(xié)議也是非常簡單的就是講URL的協(xié)議(http、https)去掉急迂。<img src="http://domain.com/img/logo.png">
這里一定要注意必須是網(wǎng)站同時有https和http的資源才會有效影所，否則請求會失敗，另外一般在正式服上線時都會劉改HOST地址僚碎，所以一般的ajax請求并不會出現(xiàn)問題猴娩，主要要注意的是一些單獨的請求地址會出現(xiàn)這樣的問題，如七牛云上傳所使用的地址是單獨的，所以有可能在正式服上線時沒有注意到卷中，另外就是使用
websocket時檢查一下正式服的socket地址是否是wss協(xié)議矛双。
總結(jié)
這次第一個出現(xiàn)的問題是在周報系統(tǒng)七牛上傳文件部分出現(xiàn)的，由于之前周報系統(tǒng)正式服可以通過http訪問到蟆豫，所以沒有出現(xiàn)問題背零，但是最近正式服換成了https，就導致文件無妨上傳无埃，當時在碰到問題時感覺比較奇怪徙瓶，明明測試服是正常的，為什么正式服會不正常嫉称，由于沒有正式服的賬號侦镇，所以調(diào)試的時候是在別人的電腦上面，當時控制臺好像并沒有打印報錯信息（有可能是自己沒有注意到）织阅，只是發(fā)現(xiàn)了在上傳文件時的第二個請求無法發(fā)送出去壳繁，當時也并沒有狀態(tài)碼（這里其實是請求根本就沒有發(fā)送出去，被瀏覽器給block掉了）荔棉。所以在解決問題的時候并沒有一個方向闹炉，最后是在老大的幫助下才了解到問題的所在的。
而在這一次問題中暴露出了一些問題润樱，比如：
- 在確定測試服正常的情況下自我感覺正式服應該不會有錯渣触，帶著這樣的心理去找問題就會忽視掉很多的細節(jié)問題。
- 當時只是發(fā)現(xiàn)請求沒發(fā)送出去壹若，卻沒有去找請求發(fā)送失敗的原因嗅钻。
- 沒有去尋找控制臺的報錯信息（當時沒有發(fā)現(xiàn)有錯誤信息，不知道是用戶瀏覽器的問題還是自己疏忽了店展，這個是本次沒有找到問題根源的關鍵所在）养篓，只是去關注了Network面板請求發(fā)送情況。
第二次是格子機的socket連接失敗赂蕴，這個問題主要是自己在拿到后端給的正式服socket地址時沒有檢查柳弄，沒有發(fā)現(xiàn)地址的協(xié)議是ws的導致在測試時才發(fā)現(xiàn)這個問題，在以后拿到后端給的地址時還是需要檢查一下再去使用概说。
