網頁設計的專業首選

網站莫名開始出現無法順利解析 IP 位址，或是使用者來造訪網站時連線反應變慢、無法連線情形，可能要注意是否為 EDNS 所影響!   EDNS 是什麼呢?     2019 年 2 月 1 日，Google、IBM、Cloudflare 等多家公共 DNS（Public Domain Name System）服務商，將開始正式導入使用 EDNS 符合性驗證，EDNS ( Extension Mechanisms for DNS)主要是應用在提升 DNS 安全性使用，而運用要點在於由 DNS 用戶端發起，用來擴充以往傳統的 DNS 傳輸資訊封包，並配合數位簽章在資訊當中加入加密與驗證的編碼，來確保網站方與瀏覽方在互動資訊的同時，能夠保障資訊傳遞的安全性、正確性，達到有效的資料防護。   在 DNS 伺服器當中，一般通常直接影響網站和郵件信箱的連線運作，所以 DNS 伺服器管理軟體或相關設備如果不支援 EDNS 協定技術，將造成 DNS 無法順利解析或解析反應變慢等問題，這部分如果是自行架設 DNS 伺服器的企業行號更需要特別留意軟體與硬體是否能及時更新與支援上此項技術。   以上提到了相關的技術與影響層面，但如果無法評判造成網站時連線反應變慢、無法連線等情形的話，也不能完全確定是否為 EDNS 所影響，因此，我們可以透過以下檢測工具進行瞭解：   簡易對"網址"或"伺服器地址"進行測試，可以使用：   EDNS Compliance Tester     自行架設 DNS 伺服器測試，可以參考測試方法：   DNS flag day      經過了分析與瞭解，相信大家都能更清楚 EDNS 協定技術的應用，如果在這方面或是網頁設計等設定上遇到困難，也歡迎洽詢本公司，協助設計、規劃與管理! 

在IIS管理員工具中，安裝完成 "URL Rewrite轉址擴充功能"時，站台就能透過伺服器的判別程式進行自動轉址，先前我們介紹過在站台IIS設定檔案中，可以應用指令方式在"web.config檔案中進行轉址"設定，但其實在安裝完成URL Rewrite轉址擴充功能的同時，我們也是能夠透過IIS管理員工具介面中的URL Rewrite功能進行圖形化介面設定的。     進入URL Rewrite功能設定介面後，在右上方動作中，可選取"新增規則" 由新增規則視窗中，選擇空白規則 命名規則名稱，設定模式的判讀應用，並展開條件列表 從條件中，新增規則 輸入判讀網址條件，且在模式的部分填入我們要辦別的實際網址進行測試 從測試中輸入要測試的網址，可以從結果中看到是否正確 建立完規則後，選擇"重新導向"的動作的模式進行判別後的動作 再將需要導向前往的網址設定在重新URL，之後選擇導向的型態，一般都是永久(301)

完成"IIS安裝│建置伺服器"與瞭解"新增站台│IIS設定"的步驟後，我們便可以開始著手網頁站台的經營與維護，在先前我們針對了網站改版維護轉址時，介紹過設定"IIS的轉址指令"資訊，但對於許多初識 IIS 需要使用到轉址功能的朋友們可能會感到疑惑，有了指令，也在web.config檔案中進行設定了，卻反而出現了錯誤資訊，原因其實出在於 IIS URL rewrite 功能需要額外加載!   在IIS 管理員介面當中，我們可以使用右方"取得新的網頁平台元件"進行擴充功能。   由擴充視窗的搜尋欄位中，我們鍵入"URL Rewrite"關鍵字並進行搜尋，便能找擴充功能進行新增安裝。   開始接受安裝資訊進行安裝   在完成後，切記一定要"重新開啟"IIS管理員工具，便能在功能中找到"URL Rewrite"的功能，這樣在web.config檔案中進行轉址設定後，便不會在出現轉址錯誤資訊。

  在完成"IIS安裝│建置伺服器"的步驟後，我們將可以開始建立網頁站台，透過站台的開設，將網頁內容上架至網際網路。   我們可以在IIS管理員中，點擊右鍵選擇左方連線資訊管理欄位當中的「 站台」功能來新增網站。   在新增網站的欄位中，我們可以依序輸入：站台名稱、網站頁面存放的實體路徑資料夾、連接埠號(預設都是80，可以根據後續新增網站延伸ex:8001(1至655的數字))、主機名稱(網址名稱)   設定完後就可以看見剛剛在「站台」資訊下看見我們所新增的網頁站台   透過IIS管理員中右邊"瀏覽網站的選項"我們可以直接驗證網站是不是架設成功。     備註：如網站還處於測試階段，新增站台資訊中的"主機名稱(網址名稱)"欄位可以先不要填寫，網站一樣能用localhost/指定IP，搭配連接埠號來執行查看，Ex：http://localhost:8001    

  在網站架設的步驟中，建置伺服器是一項較為基礎的應用技術，雖然網站伺服器有許多不同種的系統環境，但從在最普遍的微軟(Microsoft)Windows 環境當中，安裝開啟「IIS管理員工具」進行設定後，就能夠使大眾一般文書作業電腦瞬間成為站台伺服器，並存放運行網頁內容。   在 Windows 10 環境當中，透過安裝IIS管理員服務並進行幾項簡單的設定就能將電腦轉變為網站伺服器。   由控制台當中選取：程式集   再選擇：開啟或關閉windows功能   並找到Internet Information ServicesàWorld Wide Web服務à應用程式開發功能à選擇(ASP、ASP.NET 3.5、ASP.NET 4.7)選項   經過開啟功能，我們再回到控制台進入"系統及安全性"部分   進入"系統管理工具"   就能看見Internet Information Services (IIS) 管理員   開啟後就能進入(IIS) 管理員 功能介面   也可以在瀏覽器當中輸入：http://localhost/ 或是 http://127.0.0.1/ 就能看到站台伺服器成功架設的歡迎畫面  

 HTTP 狀態碼(HTTP Status Code)，是一種在網站開發初期鮮少會接觸的狀態編碼，主要是應用在網站營運維護中，用來識別、導向、偵錯，伺服器、用戶與站台狀態的對應編碼，在正常運作情況下的網站是不太會特別看見 HTTP 狀態碼出現的，就算是導向型編碼也不會刻意出現在頁面中，因此這意味著大多數看見網站頁面出現明顯的狀態編碼時，網站連線上可能出現了錯誤，並需要經由網站管理人員進行判別瞭解與除錯。   猶如前面提到 HTTP 狀態碼 可以用來「識別、導向、偵錯」，其實狀態碼有明確的區分狀態對應方向類別，同時也使用了3位數字代碼進行區別，由狀態碼數字的大小位數進行代碼的分門別類，依序位數區分，一般總共分成了五大項目：   1.代碼-1XX-狀態訊息(Informational)   2.代碼-2XX-成功訊息 (OK)   3.代碼-3XX-重新導向 (Redirection)   4.代碼-4XX-客戶端錯誤 (Client Error)   5.代碼-5XX-伺服器錯誤 (Server Error)   從以上大分類中，能夠快速的讓站台管理人員們明白站台當下所呈現的狀態，再配合代碼中細項的數字標示，便能夠更精確的找到可能需要修正或排解的問題，算是協助網站管理人員們的一項指標代碼。

 就在今年 2018 年的5月份，Google  在官方網站上正式發布了 HTTPS 的基本安全指標化，明確的說明了將在今年的九月份依照 HTTPS 安全協定實施為基本指標化認定。本站先前分享過 Google 優先收錄 HTTPS 的安全網站特性，其中也提到了 Chrome 瀏覽器針對網站連線的協定分成了：安全、不安全、危險，3種明確標示來提醒使用者應用。   在 Google 官方發布這項公告前，Chrome 瀏覽器都只是額外將有使用 HTTPS 加密連線的網站標示為安全網站，但這次的公告中卻明白的告知了大眾，以往額外標註的 HTTPS 安全標示將會剔除使用!取而代之的是直接認定 HTTPS 為網站連線安全的「基本傳輸協定」，如果不是使用 HTTPS 加密連線技術的網站，將直接標示為「不安全性」來提醒使用者應用，算是很明確認定了 HTTPS 在網站基礎應用的必要性。   從2017年開始 Google 便開始推廣了網連線由原本的 HTTP 升級為 HTTPS ，從這樣的推廣過程中，站台設計、維護技術的應用也持續的提升進步，由 Google 統計在Windows 瀏覽器中 HTTPS 推廣至現今的普及率達到了 80% 以上，從這樣的成效上來看，Google 本次的公告也將帶領網站安全傳輸技術進入新的指標，讓所有的使用者能夠得到跟多安全的使用保障，面對 HTTPS 全面化應用的來臨，您的網站是否準備好了呢? 如果有您 HTTPS 申請、設定、應用上的疑問，歡迎盡速與本站連絡，本站將會誠摯地為您打造全面性的安全服務。  

   .app頂級網域名稱(TLD，Top-Level Domain)，開放註冊申請囉!由 Google 在2015年2月以 TLD 史上最高金額2.5億萬美元所競標下的 .app 頂級網域名稱的經營權，在本月(2018/5/8)開始透過各家註冊機構對外開放申請註冊網址應用了!      Google 旗下網域名稱註冊管理機構 Google Registry 透過 Google 官方資訊對外宣布了.app頂級網域名稱開放應用的資訊，如同域名由英文單字「application」的簡寫.app 命名，主要是提供「行動應用程式、雲端程式、網路程式、瀏覽器程式」等開發人員所能加以學習、交流、運用的安全網域名稱。      其中也特別強調了.app 是 TLD 當中首例預設直接使用 HTTPS 加密的傳輸模式，讓開發人員能夠更安全的將應用程式推廣至全球普及，透過HTTPS的加密特性，可以避免連線傳輸途中受到惡意廣告程式和 ISP 的入侵或跟蹤，同時也保障在開放的 Wi-Fi 環境中確保傳輸安全。      在.app的開放中，我們明顯瞭解到了 Google 對行動應用趨勢及HTTPS加密傳輸有著十分的重視，因此它也將是Google 宣告帶領網路走向未來 HTTPS 全面化的領導趨勢，從2018/5/8開始只需要先透過get.app確認.app的域名使用狀況後，就能開始選擇合作的註冊商進行.app網址申請囉!

 Google 在 2018 年新年一月份就發佈了 Mobile-friendly websites 這項消息，從訊息的開頭就提到了："行動科技正在改變世界。如果您尚未建立適合透過行動裝置瀏覽的網站，我們極力推薦您這麼做，因為大部分造訪您網站的人很可能都是使用行動裝置。"，由此開宗明義的讓所有人能明白，網站經營的趨勢已經正在行動化! Google 考量了除了近年建置的新網站之外，以往至今，大多數網頁站台都是從電腦版網站為基礎建構，面對來勢洶洶的行動化，如果您不知道自己的網站是否適合透過行動裝置瀏覽，Google 也貼心的推出了"行動裝置相容性測試"提供以往內容的檢測與改善建議。   行動裝置相容性測試這項服務有效的提供了客觀與專業的檢測和建議，不論對於有經營一定時日的傳統網站還是即將上線的新網站都提供了實質的剖析。   在檢測中主軸便以簡單明確的顯示告知當前的網站是否合適透過行動裝置瀏覽     從不適合透過行動裝置的分析可以大約瞭解，行動裝置的設計主要針對了：文字大小、閱讀方便性、內容寬度是否超出螢幕顯示範圍、設定檢視點、可點選的元素之間距離是否太近。這幾個項目進行審核，並提供改善建議。   根據建議修正的部分，將網站調整至正確的方向，便能有效改善頁面在行動裝至上的友善使用性，在進行改善檢測後，Google 也提供優先索引的提交功能，讓您的網站在行動裝置優化後能夠有效馬上受到搜尋引擎的重視與收納。

   HTTP/2是什麼?在網站伺服器與瀏覽器相互連結工作之間，使用了一項全球資訊網基礎的 HTTP(超文本傳輸協定) 通訊協定，其中最為廣泛應用的版本為1999年發布的 HTTP/1.1，也是網站伺服器與瀏覽器配合使用最久的協定版本，其中相隔經歷了16個年頭，在2015年時才又正式的發佈了最新的協定版本，那就是 HTTP/2（超文字傳輸協定第2版)，也是正式的準備取代 HTTP 1.1成為現今 HTTP 的實現標準。     相隔了十六年後的更新，HTTP/2 的釋出帶來了網站瀏覽的全新體驗，不僅讓網站瀏覽速度增加，也提供了更安全的連線資訊，同時更兼容了 HTTP/1.1 原有的GET/POST 操作、HTTP Status Code 和各種 HTTP Headers 都沒有改變，因此在不需要修改 HTML/CSS/JavaScript 網頁和你的後端程式伺服器端的情況下，只需要將網站伺服器軟體進行更新並設定，使用者使用支援 HTTP/2 的瀏覽器，就可以體驗這項優化的通訊協定。       HTTP/2 與 HTTP/1.1 相差別的幾項工作模式，其中包含了：     1.HTTP/2 協定建置在 HTTPS 安全連線之上，因此在更新 HTTP/2之前，網站必須要擁有 TLS/SSL 安全性憑證來保障安全連線。   2.在減少多個連線工作次數的情況下，瀏覽器只需單一網路連線就可以與網站伺服器進行連接。   3.由單一網路連線時達成同時傳輸多個 HTTP Request 和 Response，並擴充增加可以同時請求發送 CSS/JS/Images 等等資源。   4.優先權設計(Prioritization)，伺服器可以決定例如 CSS 或 JavaScript 檔案，哪些要優先傳送。   5.Header 壓縮，HTTP/2 處理了絕大部份重複的 Headers ，並在傳送前進型壓縮，有效減少了過多重複的資訊也縮短了冗長得傳輸過程。   6.HTTP/2 使用單一Binary 二進位的封包結構設計，對伺服器和瀏覽器來說，可以更快的解析傳輸資料。   7.伺服器主動推送資源(Server Push)，允許伺服器除了 HTML 之外，連同需要的 CSS/JavaScript/Images 檔案，主動推到瀏覽器的快取之中。     透過以上的調整與擴充功能，讓伺服器與瀏覽器在相互連結工作時能省下更多傳輸時間，也減少了原本複雜的資訊，並兼顧了網站傳輸安全，是項多方改善的優化協定，而應用上特別需注意部分為TLS/SSL 安全性憑證，網站原先使用 HTTP 改成 HTTPS 的這個過程需要較為注意，站內連結與需要連同更換。