分類: 不負責主機評論

再次確認企業郵件的對應資料 (hibox 的mx 設定)

hibox_wp

我們在前篇裡：
如何將我所註冊的網域空間，透過cpanel修改，改指向到其他商業郵件呢？

教大家如何把網域的mx作指向；
在今天我們遇到一個資料不對稱的狀況，導致設定不正確。
在這邊提出讓大家了解一下。

閱讀全文 再次確認企業郵件的對應資料 (hibox 的mx 設定)

建立服務單

自2012-07月，unethost.com改使用whmcs這一套帳務控制台時，whmcs有內建一套ticket system(服務單系統)，在此之前，都是由客服透過msn，e-mail…等，進行線上處理客戶問題。

msn是同步溝通的工具，對客戶是速度快立即性的回覆。在另一方面，我們為了提升回覆的品質，比如說，相當的技術問題，需由工程人員(或協力廠商)提供專業的意見，這時處理就會需要時間作業，這種情況下，使用msn就不是那麼的適用。

再加上，msn後來的版本不穩，或是每日的e-mail過多，都會導致回覆的速度變慢，漏信，降低了服務品質。

為了提升服務品質，我們直接參考國外的做法，使用ticket system。在國外，不論各行各業，很早就發生過這樣的問題(尤其是英國，美國，服務業已經相當成熟的地方)，所以他們已經有著標準處理程序及系統，稱為 ticket system 或是 help desk。

在引導客戶的使用上，部分已習慣使用msn的客戶，向我們表達過，不習慣去改用服務單的連絡方式。簡單講，客戶習慣同步的溝通，而我們改用非同步的方式。

經過一年多的磨合，大多的客戶，都已能接受服務單的使用，並持續性的使用，
在此也要感謝，能配合我們去改版的客戶，由您的幫助，unethost.com才能持續的茁壯。

下圖是截至目前為止，處理的服務單截圖。已處理完成1493個服務單。
(系統一接收到資料，就存於資料庫，所以也不會漏信)。

 

open: 尚未處理的。
answered: 已回覆客戶，但未處理完。
closed: 已解決。
knowledge:  可轉為知識庫。

 

 

主機商選購指南

本篇文章是一篇帶有強烈置入性行銷的文章。請大家多多包涵。

作為一個主機商，由於客戶中有許多常常三天兩頭有被DDoS, 被放木馬之類的問題，本公司在累積了無數的經驗(?客訴)之後, 對於安全性的議題有著異常的執著與重視。要提高安全性，確保php程式碼沒有漏洞的部分，是客戶端在管的。但是，要確保php的版本沒有漏洞的部分，則是主機商的事。

升級php, 升級mysql, 升級apache, 更換ip，這一類的事，由於會影響到客戶的程式，對於主機商而言算是苦差事。但是，不升級也不行。不升級的話，漏洞就會一直存在。是否應該升級？何時最好一定要升級，其實這個問題，也是有客觀的參考。

以美國的五大主機商為例子，hostgator和webhostingpad都已經升級PHP 5.3了。( 這些資訊，我是直接用官網去查的 )

而台灣地區，搜尋「虛擬主機」這個關鍵字，google出來第一頁的主機商之中，大間的5、6家裡，幾乎都還是使用PHP 5.2.17版。(台灣的同胞怎麼這麼不重視資訊安全啊？ 這不是已經應該要升級很久了嗎？ )只有一家有升級PHP 5.3。這一家，呃，當然不是敝公司，因為unethost.com的google rank在很多頁之後。但是，本公司升級PHP 5.3是老早以前的事。官網的主機已經升級到 PHP 5.3.22版了。

最後要在這邊順便講解一下，如何看php的版本。如果是用chrome來當browser 的話，先按Ctrl + shift + i，選Network，按F5，之後，點選一個php網頁。看到最下方，應該會有一串字串 X-Powered-By:，例如：

X-Powered-By: PHP/5.3.22

這就是了！

如何選購外國的虛擬主機？

一般而言，選購外國的虛擬主機，台灣人的首選，是以美國、日本為主。日本的話，由於日文還是比較不比英文普遍，大多數人還是先考慮美國。

我看了許多網站評比美國的虛擬主機，說了一堆服務幾分？有沒有送google adword？身為主機商的我，我覺得，這些都不是客戶要的。客戶要的東西，對客戶而言，最重要的東西：(1)線路品質 (2)價格。其它的什麼google adword？客服如何？機器的軟体是不是最新的？這些常常都不是客戶最在意的事。

讓我來解釋一下，什麼是線路品質的觀念吧：
我們用ping這個command去連遠端的主機的話，可以得到一個數字，叫做RTT。這個數字，對於傳輸有莫大的影響。怎麼說呢？ 以unethost的美國西岸主機來講，RTT約是150ms多。雖然主機本身的頻寬是100Mbps，但是，對於單一的TCP連線，考慮TCP的slow start effect & congestion control效應之後，理論上的最高速是4.3Mbps 或是500 kbyte/sec。當然，現代的瀏覽器已經有做平行的連線，一般而言最多是十條。但是平行的連線是對多個小檔，可以加速，如果是一個單一的大檔，或是說一個PHP生成的動態頁面，就一定會被這個速度所限制。

這個RTT如何影響單一連線的最高速，其實是有計算公式的。大家要是記不住，概念上是RTT愈小，單一連線的最高速限愈大。詳細推導的流程是：TCP在傳輸的時候，電腦會對每一條TCP連線生成一個Slilding window(滑動窗戶)。這個window的大小，必須等於BDP = bandwidth delay product 。也就是說，這個滑動窗戶的大小 = 頻寬 乘上 RTT。由於一般來講，大部分的人用的電腦OS是windows，內建的TCP演算法也不是最新的，所以Slilding window size是固定的：64kbytes。這種時候，頻寬就可以由 ( Slilding window size/ RTT)來算出。

而上頭，本文所講的理論上限也就是這樣子算出來的。unethost的主機測速資料在這邊。

參考資料可以看下方的英文。

Sometimes, we are feeling slow Internet connection, but don’t know how we can measure the speed and what is right speed, download speed, TCP throughput, I can expect. Measuring and calculating TCP throughput is not that hard. See below famous TCP throughput formula.

RCV buffer size / RTT = Max TCP throughput = ? bps
** Buffer size is normally 65Kbps

ex) (64Kbyte x 8bit) / 0.17 = 3011764 bps = 3Mbps, (RTT=170ms)

To learn more about Internet Speed Issue, please check our article series within www.ipBalance.com

RCV Buffer size / TCP receive window size

– RCV buffer size is denoted as TCP receive window size. Window systems have 64Kbyte of window size as default (Window NT and Millennium have 8Kbytes of window size).  The TCP/IP standard allows for a receive window up to 65,535 bytes in size, which is the maximum value that can be specified in the 16-bit TCP window size field. Why 65Kbytes? Well, more accurate expression will be  65,535 = (2^16)-1. To improve TCP throughput, speed, performance whatever you called, in high speed connection or high delay network, you can increase TCP window size(reference RFC 1323). However, if transport link is not stable, it might give you worse performance. Packet loss or bottleneck in the network is the most likelyfactors that are leading to the TCP throughput reductions.

Optimal TCP window size

– Optimal RCV buffer size is considered to be 2 x BDP, where BDP is the Bandwidth * Delay Product

ex) RTT is 20 ms, and connection speed is 10 Mbps.
2 x (10Mbps/8 * .020s) = 50Kbytes

Well, default window size 65kbytes is not adequate for today’s network. In these days, most of network is 100Mbps or higher.

Round Trip Time(RTT)

– If you are not using TCP window scaling option (RFC 1323), TCP window size will be used as 64Kbytes. If then, Round Trip Time(RTT) is the main factor to decide TCP throughput between locations. 

RTT 10 ms => TCP throughput = 52428000 bps = 52Mbps
RTT 20 ms => TCP throughput = 26214000 bps = 26Mbps
RTT 50 ms => TCP throughput = 10485600 bps = 10Mbps
RTT 100 ms => TCP throughput = 5242800 bps = 5.2Mbps
RTT 150 ms => TCP throughput = 3495200 bps = 4.3Mbps
RTT 200 ms => TCP throughput = 2621400 bps = 2.5Mbps
RTT 300 ms => TCP throughput = 1747600 bps = 1.7Mbps
RTT 500 ms => TCP throughput = 1048560 bps = 1Mbps

** Used maximum TCP window size  = 65Kbytes = 65535

You can see the deficiency with the greater RTT.

 

lolipop

話說，我們這種當主機商的，通常都會買幾個域名，用來做為共用的域名，凡是有客戶不想要自己花錢買域名的，就直接用我們的公用的，他自己選一個子域名即可。

讓我們來看一下，日本人是怎麼做生意的，佩服啊！ XD
http://lolipop.jp/service/domain/list/

靠靠靠，lolipop.jp這家公司，居然準備了整整150種共用域名給客戶選…
客戶選擇使用免費的domain，也還有150種選擇…真是太用心了

而且，再來仔細看看：
這150個domain也不是亂選的，是有種類有意義的！
(1)流行類
(2)酷類
(3)簡短類
(4)有意義類
(5)可愛類
(6)怪怪類

以我個人來講，主機這個行業，能變化的東西不多，像日本的這家lolipop能在共用的域名這一塊，作出變化，做出差異化的服務，真是令我好生佩服。

 

主機植物園

首先，由於這篇文章是屬於不負責的主機評論，所以請大家當笑話看看就好了，不要太在意我的觀點。我也是小小主機商一個而已。XD

我的同業中，有一個還不錯的，叫他”主機植物園”好了，其實我覺得他滿會整合軟體的。他的官網，有一個很帥氣的slidedeck，就是一個可以左右捲動的特效。我覺得做得相當好，我一邊看就不知為何，讓我想起了我以前在slidedeck這個網站上，有看過類似的 javascript library。

嗯，這家主機商真的很有主機商的樣子，自己的網站就做了最佳示範：當然是適度地整合一些付費資源，才會做得又美又好囉！

如何挑選合適的主機商？

虛擬主機這個行業，老實說，進入的門檻並不高，只要會用WHM/Cpanel，就算linux的command不太熟，也是可以當個主機商。因為95%的事情，都可以靠cpanel來解決。也因為這樣子的結果，主機商眾多，反而讓消費者可以有多樣選擇的機會。

基本上，主機商無論國內外，都可以區分為大主機商和小主機商。什麼叫小主機商呢？我下個定義好了，全公司的員工5人以下的，夠小了吧。XD。老實說，就我對我同行的理解，還滿多這樣子的主機商，很多是一人公司。附帶一提，敝公司也是小主機商。

大主機商因為規模經濟的關系，其實比較能壓低商品的售價。小主機商的話，因為是老闆兼撞鐘的關系，服務是比較不打折扣的。客戶說聲要走人了，老闆是比誰都急。XD

所以我會建議：會需要客製化服務的可以考慮小主機商，他們會很認真地服務你。以價格為第一考量的客戶，則可以考慮大主機商。而如果你覺得你需要的服務，應該都是在cpanel/WHM可以cover的範圍內，這種情況，可能大主機商就可以搞定了。