一次探索https的經歷

最近在弄本身的github blog，但是每次打開瀏覽器進去這個https有點辣眼睛，爲何會出現圖中這種狀況呢？

---

1.我打開geogle瀏覽器的開發者工具，很奇怪我上午查看elements項有報錯，可是晚上再看卻沒有報錯，錯誤重現率並非100%，我暫時理解爲瀏覽器是接受這個錯誤的，我打開歷史記錄，錯誤信息爲：Blocked loading mixed active content "..."，我繼續查找錯誤信息，Mixed Content Blocking，這裏我接觸到一個Mixed Content，那麼問題來了：
what's Mixed Content?

What is Mixed Content? When a user visits a page served over HTTP,
their connection is open for eavesdropping and man-in-the-middle
(MITM) attacks. When a user visits a page served over HTTPS, their
connection with the web server is authenticated and encrypted with SSL
and hence safeguarded from eavesdroppers and MITM attacks.
However, if an HTTPS page includes HTTP content, the HTTP portion can
be read or modified by attackers, even though the main page is served
over HTTPS. When an HTTPS page has HTTP content, we call that content
「mixed」. The webpage that the user is visiting is only partially
encrypted, since some of the content is retrieved unencrypted over
HTTP. The Mixed Content Blocker blocks certain HTTP requests on HTTPS
pages.

簡單來講，當咱們訪問http頁面時，咱們的鏈接是容易遭受被竊聽和中間人攻擊的，總而言之是很不安全的。可是當咱們訪問一個https頁面時，咱們的鏈接是被SSL驗證和加密的，所以可以被保護起來，免受監聽者和中間人攻擊之害，也就是說，https是安全的鏈接方式。可是，若是一個https頁面中包含有http鏈接，咱們就稱這種狀況爲「mixed」，頁面只有部分安全（https部分），還有一部分是不加密的（http部分），那麼整個頁面也是不安全的。
因而便會出現上面的狀況，OK，那我點擊那個辣眼睛的東西看看：

果真加載了不安全的腳本，

那麼接下來的任務很簡單，找到那個腳本，而後fix a website with blocked mixed content，

The best strategy to avoid mixed content blocking is to serve all the
content as HTTPS instead of HTTP.

For your own domain, serve all content as HTTPS and fix your links.
Often, the HTTPS version of the content already exists and this just
requires adding an "s" to links - http:// to https://.

However, in some cases, the path may just be incorrect to the media in

1. There are online as well as offline tools (depending on your

2. system) such as linkchecker to help resolve this.

For other domains, use the site's HTTPS version if available. If HTTPS
is not available, you can try contacting the domain and asking them if
they can make the content available via HTTPS.

通過和localhost:4000生成的頁面進行對比，我發現，我所引用的jiathis並無生效，
我先嚐試第一種方法，將"http"轉換成"https",很尷尬，即便是在本地預覽都沒法加載出來了，上面介紹的第二種方法是經過一些外鏈檢測工具，例如linkchecker來檢查我所引用的鏈接是否爲死連接，結果顯然不是。
OK,雖然不成功，可是我注意到它是直接在<script>標籤中利用src屬性引用的外部文件，我以爲這裏能夠優化一下，讓其以無阻塞腳本方式運做：
原代碼：

<script type="text/javascript" src="https://v3.jiathis.com/code/jia.js" charset="utf-8"></script>

改以後：

<script type="text/javascript">
var duoshuoQuery = {short_name:"evison"};
    (function() {
        var ds = document.createElement('script');
        ds.type = 'text/javascript';ds.async = true;
        ds.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') + '//v3.jiathis.com/code/jia.js';
        ds.charset = 'UTF-8';
        (document.getElementsByTagName('head')[0] 
         || document.getElementsByTagName('body')[0]).appendChild(ds);
    })();
</script>

這裏對https和http作了一個選擇判斷，可是很遺憾貌似這個插件就是沒有https支持，這樣改過以後在本地瀏覽是無誤的，可是deploy到github上仍是mixed content狀態，百度了一下發現確實如今沒有支持https的社會化分享按鈕，可是提出了一個解決方案，即將腳本複製到本地，經過路徑來引用腳本，我以爲能夠嘗試一下。結果是連本地都沒法加載出來了。下面是一個解決方案--在https站點使用jiathis,可是因爲條件限制，留待之後嘗試！最後的結果是我把沒有在網站上顯示的jiathis組件刪除。

---

2.通過了上面的嘗試，雖然最終結果木有成功，可是我仍然想弄懂下面這三個問題.

• http?

• https?

• ssl?

---

http的理解
http（超文本傳輸協議）是一種屬於應用層的面向對象的協議，是用於從web服務器傳輸超文本到本地瀏覽器的的傳送協議。http是基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。

---

http的特色

• 支持客戶/服務器模式

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑

• HTTP容許傳輸任意類型的數據對象，正在傳輸的類型由Content-Type加以標記

• HTTP是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

• HTTP是無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

---

URL

• URL(Uniform Resource Locator) 地址用於描述一個網絡上的資源：
  schema://host[:port#]/path/.../;url-params[#anchor]

scheme //有咱們很熟悉的http、https、ftp以及著名的ed2k，迅雷的thunder等。
host   //HTTP服務器的IP地址或者域名
port  //HTTP服務器的默認端口是80，這種狀況下端口號能夠省略。若是使用了別的端   口，必須指明，例如tomcat的默認端口是8080 http://localhost:8080/
path   //訪問資源的路徑
url-params  //所帶參數
query-string    //發送給http服務器的數據
anchor //錨點定位

---

Get和Post方法的區別

• Http協議定義了不少與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用於描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應着對這個資源的查，改，增，刪4個操做。 咱們最多見的就是GET和POST了。GET通常用於獲取/查詢資源信息，而POST通常用於更新資源信息.

• GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數據放在HTTP包的Body中.

• GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制

• GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值

• GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.

---

http狀態碼

• 1xx:信息，服務器收到請求，須要請求者繼續執行操做

• 2xx:成功，操做被成功接收並處理

• 3xx:重定向，須要進一步的操做以完成請求

• 4xx:客戶端錯誤，請求包含語法錯誤或沒法完成請求

• 5xx:服務器錯誤，服務器在處理請求的過程當中發生了錯誤
  狀態碼大全

---

https
先來看看其全程：Hyper Text Transfer Protocol over Secure Socket Layer，能夠理解爲http的安全版。HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL，用於安全的http數據傳輸。

---

區別
超文本傳輸協議HTTP協議被用於在Web瀏覽器和網站服務器之間傳遞信息。HTTP協議以明文方式發送內容，不提供任何方式的數據加密，若是攻擊者截取了Web瀏覽器和網站服務器之間的傳輸報文，就能夠直接讀懂其中的信息，所以HTTP協議不適合傳輸一些敏感信息，好比信用卡號、密碼等，其默認端口號爲80.
爲了解決HTTP協議的這一缺陷，須要使用另外一種協議：安全套接字層超文本傳輸協議HTTPS。爲了數據傳輸的安全，HTTPS在HTTP的基礎上加入了SSL協議，SSL依靠證書（採用https的服務器必須從CA （Certificate Authority）申請一個用於證實服務器用途類型的證書）來驗證服務器的身份，併爲瀏覽器和服務器之間的通訊加密，其默認端口號爲443。

---

ssl
security socket layer安全套接字層，在傳輸層對網絡鏈接進行加密。
SSL協議位於TCP/IP協議與各類應用層協議之間，爲數據通信提供安全支持。
SSL協議可分爲兩層：
SSL記錄協議（SSL Record Protocol）：它創建在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。
SSL握手協議（SSL Handshake Protocol）：它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

--END--