HTTPS層次結(jié)構(gòu)

HTTPS層次結(jié)構(gòu)

對(duì)稱加密

對(duì)稱加密(也叫私鑰加密)指加密和解密使用相同密鑰的加密算法。有時(shí)又叫傳統(tǒng)密碼算法，就是加密密鑰能夠從解密密鑰中推算出來，同時(shí)解密密鑰也可以從加密密鑰中推算出來。而在大多數(shù)的對(duì)稱算法中，加密密鑰和解密密鑰是相同的，所以也稱這種加密算法為秘密密鑰算法或單密鑰算法。

常見的對(duì)稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA。

非對(duì)稱加密

與對(duì)稱加密算法不同，非對(duì)稱加密算法需要兩個(gè)密鑰：公開密鑰（publickey）和私有密鑰（privatekey）；并且加密密鑰和解密密鑰是成對(duì)出現(xiàn)的。非對(duì)稱加密算法在加密和解密過程使用了不同的密鑰，非對(duì)稱加密也稱為公鑰加密，在密鑰對(duì)中，其中一個(gè)密鑰是對(duì)外公開的，所有人都可以獲取到，稱為公鑰，其中一個(gè)密鑰是不公開的稱為私鑰。

非對(duì)稱加密算法對(duì)加密內(nèi)容的長(zhǎng)度有限制，不能超過公鑰長(zhǎng)度。比如現(xiàn)在常用的公鑰長(zhǎng)度是 2048 位，意味著待加密內(nèi)容不能超過 256 個(gè)字節(jié)。

摘要算法

數(shù)字摘要是采用單項(xiàng)Hash函數(shù)將需要加密的明文“摘要”成一串固定長(zhǎng)度（128位）的密文，這一串密文又稱為數(shù)字指紋，它有固定的長(zhǎng)度，而且不同的明文摘要成密文，其結(jié)果總是不同的，而同樣的明文其摘要必定一致。“數(shù)字摘要“是HTTPS能確保數(shù)據(jù)完整性和防篡改的根本原因。

數(shù)字簽名

數(shù)字簽名技術(shù)就是對(duì)“非對(duì)稱密鑰加解密”和“數(shù)字摘要“兩項(xiàng)技術(shù)的應(yīng)用，它將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對(duì)收到的原文產(chǎn)生一個(gè)摘要信息，與解密的摘要信息對(duì)比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗(yàn)證信息的完整性。 數(shù)字簽名的過程如下： 明文 --> hash運(yùn)算 --> 摘要 --> 私鑰加密 --> 數(shù)字簽名。

數(shù)字簽名有兩種功效：

能確定消息確實(shí)是由發(fā)送方簽名并發(fā)出來的，因?yàn)閯e人假冒不了發(fā)送方的簽名。

數(shù)字簽名能確定消息的完整性。

注意： 數(shù)字簽名只能驗(yàn)證數(shù)據(jù)的完整性，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍。

數(shù)字證書

為什么要有數(shù)字證書？

對(duì)于請(qǐng)求方來說，它怎么能確定它所得到的公鑰一定是從目標(biāo)主機(jī)那里發(fā)布的，而且沒有被篡改過呢？亦或者請(qǐng)求的目標(biāo)主機(jī)本本身就從事竊取用戶信息的不正當(dāng)行為呢？這時(shí)候，我們需要有一個(gè)權(quán)威的值得信賴的第三方機(jī)構(gòu)（一般是由政府審核并授權(quán)的機(jī)構(gòu)）來統(tǒng)一對(duì)外發(fā)放主機(jī)機(jī)構(gòu)的公鑰，只要請(qǐng)求方這種機(jī)構(gòu)獲取公鑰，就避免了上述問題的發(fā)生。

數(shù)字證書的頒發(fā)過程

用戶首先產(chǎn)生自己的密鑰對(duì)，并將公共密鑰及部分個(gè)人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實(shí)身份后，將執(zhí)行一些必要的步驟，以確信請(qǐng)求確實(shí)由用戶發(fā)送而來，然后，認(rèn)證中心將發(fā)給用戶一個(gè)數(shù)字證書，該證書內(nèi)包含用戶的個(gè)人信息和他的公鑰信息，同時(shí)還附有認(rèn)證中心的簽名信息（根證書私鑰簽名）。用戶就可以使用自己的數(shù)字證書進(jìn)行相關(guān)的各種活動(dòng)。數(shù)字證書由獨(dú)立的證書發(fā)行機(jī)構(gòu)發(fā)布，數(shù)字證書各不相同，每種證書可提供不同級(jí)別的可信度。

證書包含哪些內(nèi)容

證書頒發(fā)機(jī)構(gòu)的名稱。

證書本身的數(shù)字簽名。

證書持有者公鑰。

證書簽名用到的Hash算法。

驗(yàn)證證書的有效性

瀏覽器默認(rèn)都會(huì)內(nèi)置CA根證書，其中根證書包含了CA的公鑰：

證書頒發(fā)的機(jī)構(gòu)是偽造的：瀏覽器不認(rèn)識(shí)，直接認(rèn)為是危險(xiǎn)證書

證書頒發(fā)的機(jī)構(gòu)是確實(shí)存在的，于是根據(jù)CA名，找到對(duì)應(yīng)內(nèi)置的CA根證書、CA的公鑰。用CA的公鑰，對(duì)偽造的證書的摘要進(jìn)行解密，發(fā)現(xiàn)解不了，認(rèn)為是危險(xiǎn)證書。

對(duì)于篡改的證書，使用CA的公鑰對(duì)數(shù)字簽名進(jìn)行解密得到摘要A，然后再根據(jù)簽名的Hash算法計(jì)算出證書的摘要B，對(duì)比A與B，若相等則正常，若不相等則是被篡改過的。

證書可在其過期前被吊銷，通常情況是該證書的私鑰已經(jīng)失密。較新的瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實(shí)現(xiàn)了在線證書狀態(tài)協(xié)議（OCSP）以排除這種情形：瀏覽器將網(wǎng)站提供的證書的序列號(hào)通過OCSP發(fā)送給證書頒發(fā)機(jī)構(gòu)，后者會(huì)告訴瀏覽器證書是否還是有效的。

1、2點(diǎn)是對(duì)偽造證書進(jìn)行的，3是對(duì)于篡改后的證書驗(yàn)證，4是對(duì)于過期失效的驗(yàn)證。

SSL 與 TLS

SSL (Secure Socket Layer，安全套接層)。

SSL為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密(Encryption)技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上之傳輸過程中不會(huì)被截取，當(dāng)前為3.0版本。

SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。 SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

TLS (Transport Layer Security，傳輸層安全協(xié)議)

用于兩個(gè)應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。 TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1，它是寫入了 RFC 的。該協(xié)議由兩層組成： TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。較低的層為 TLS 記錄協(xié)議，位于某個(gè)可靠的傳輸協(xié)議（例如 TCP）上面。

SSL/TLS協(xié)議作用：

認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器。

加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取。

維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。

TLS比SSL的優(yōu)勢(shì)

對(duì)于消息認(rèn)證使用密鑰散列法：TLS 使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時(shí)，該代碼確保記錄不會(huì)被變更。SSLv3.0還提供鍵控消息認(rèn)證，但HMAC比SSLv3.0使用的（消息認(rèn)證代碼）MAC 功能更安全。

增強(qiáng)的偽隨機(jī)功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。

改進(jìn)的已完成消息驗(yàn)證：TLS和SSLv3.0都對(duì)兩個(gè)端點(diǎn)提供已完成的消息，該消息認(rèn)證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。

一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實(shí)現(xiàn)交換的證書類型。

特定警報(bào)消息：TLS提供更多的特定和附加警報(bào)，以指示任一會(huì)話端點(diǎn)檢測(cè)到的問題。TLS還對(duì)何時(shí)應(yīng)該發(fā)送某些警報(bào)進(jìn)行記錄。

SSL、TLS的握手過程

SSL與TLS握手整個(gè)過程如下圖所示，下面會(huì)詳細(xì)介紹每一步的具體內(nèi)容：

SSL、TLS的握手流程圖

HTTPS握手流程圖

客戶端首次發(fā)出請(qǐng)求

由于客戶端(如瀏覽器)對(duì)一些加解密算法的支持程度不一樣，但是在TLS協(xié)議傳輸過程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務(wù)端，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務(wù)端。除此之外，客戶端還要產(chǎn)生一個(gè)隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)一方面需要在客戶端保存，另一方面需要傳送給服務(wù)端，客戶端的隨機(jī)數(shù)需要跟服務(wù)端產(chǎn)生的隨機(jī)數(shù)結(jié)合起來產(chǎn)生后面要講到的 Master Secret 。

客戶端需要提供如下信息：

支持的協(xié)議版本，比如TLS 1.0版。

一個(gè)客戶端生成的隨機(jī)數(shù)，稍后用于生成”對(duì)話密鑰”。

支持的加密方法，比如RSA公鑰加密。

支持的壓縮方法。

服務(wù)端首次回應(yīng)

服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要確定加密協(xié)議的版本，以及加密的算法，然后也生成一個(gè)隨機(jī)數(shù)，以及將自己的證書發(fā)送給客戶端一并發(fā)送給客戶端，這里的隨機(jī)數(shù)是整個(gè)過程的第二個(gè)隨機(jī)數(shù)。

服務(wù)端需要提供的信息：

協(xié)議的版本

加密的算法

隨機(jī)數(shù)

服務(wù)器證書

客戶端再次回應(yīng)

客戶端首先會(huì)對(duì)服務(wù)器下發(fā)的證書進(jìn)行驗(yàn)證，驗(yàn)證通過之后，則會(huì)繼續(xù)下面的操作，客戶端再次產(chǎn)生一個(gè)隨機(jī)數(shù)（第三個(gè)隨機(jī)數(shù)），然后使用服務(wù)器證書中的公鑰進(jìn)行加密，以及放一個(gè)ChangeCipherSpec消息即編碼改變的消息，還有整個(gè)前面所有消息的hash值，進(jìn)行服務(wù)器驗(yàn)證，然后用新秘鑰加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器，確保正式通信前無誤。

客戶端使用前面的兩個(gè)隨機(jī)數(shù)以及剛剛新生成的新隨機(jī)數(shù)，使用與服務(wù)器確定的加密算法，生成一個(gè)Session Secret。

ChangeCipherSpec

ChangeCipherSpec是一個(gè)獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。

服務(wù)器再次響應(yīng)

服務(wù)端在接收到客戶端傳過來的第三個(gè)隨機(jī)數(shù)的 加密數(shù)據(jù)之后，使用私鑰對(duì)這段加密數(shù)據(jù)進(jìn)行解密，并對(duì)數(shù)據(jù)進(jìn)行驗(yàn)證，也會(huì)使用跟客戶端同樣的方式生成秘鑰，一切準(zhǔn)備好之后，也會(huì)給客戶端發(fā)送一個(gè) ChangeCipherSpec，告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài)，準(zhǔn)備使用加密套件和 Session Secret加密數(shù)據(jù)了。之后，服務(wù)端也會(huì)使用 Session Secret 加密一段 Finish 消息發(fā)送給客戶端，以驗(yàn)證之前通過握手建立起來的加解密通道是否成功。

后續(xù)客戶端與服務(wù)器間通信

確定秘鑰之后，服務(wù)器與客戶端之間就會(huì)通過商定的秘鑰加密消息了，進(jìn)行通訊了。整個(gè)握手過程也就基本完成了。

值得特別提出的是： SSL協(xié)議在握手階段使用的是非對(duì)稱加密，在傳輸階段使用的是對(duì)稱加密，也就是說在SSL上傳送的數(shù)據(jù)是使用對(duì)稱密鑰加密的！因?yàn)榉菍?duì)稱加密的速度緩慢，耗費(fèi)資源。其實(shí)當(dāng)客戶端和主機(jī)使用非對(duì)稱加密方式建立連接后，客戶端和主機(jī)已經(jīng)決定好了在傳輸過程使用的對(duì)稱加密算法和關(guān)鍵的對(duì)稱加密密鑰，由于這個(gè)過程本身是安全可靠的，也即對(duì)稱加密密鑰是不可能被竊取盜用的，因此，保證了在傳輸過程中對(duì)數(shù)據(jù)進(jìn)行對(duì)稱加密也是安全可靠的，因?yàn)槌丝蛻舳撕椭鳈C(jī)之外，不可能有第三方竊取并解密出對(duì)稱加密密鑰！如果有人竊聽通信，他可以知道雙方選擇的加密方法，以及三個(gè)隨機(jī)數(shù)中的兩個(gè)。整個(gè)通話的安全，只取決于第三個(gè)隨機(jī)數(shù)（Premaster secret）能不能被破解。

其他補(bǔ)充

對(duì)于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對(duì)客戶端進(jìn)行驗(yàn)證，以保證數(shù)據(jù)傳送給了安全的合法的客戶端。服務(wù)端可以向客戶端發(fā)出 Cerficate Request 消息，要求客戶端發(fā)送證書對(duì)客戶端的合法性進(jìn)行驗(yàn)證。比如，金融機(jī)構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會(huì)向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

PreMaster secret前兩個(gè)字節(jié)是TLS的版本號(hào)，這是一個(gè)比較重要的用來核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào)，因?yàn)樵贑lient Hello階段，客戶端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號(hào)給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端，從而對(duì)數(shù)據(jù)進(jìn)行破解。所以，服務(wù)端需要對(duì)密文中解密出來對(duì)的PreMaster版本號(hào)跟之前Client Hello階段的版本號(hào)進(jìn)行對(duì)比，如果版本號(hào)變低，則說明被串改，則立即停止發(fā)送任何消息。

session的恢復(fù)

有兩種方法可以恢復(fù)原來的session：一種叫做session ID，另一種叫做session ticket。

session ID

session ID的思想很簡(jiǎn)單，就是每一次對(duì)話都有一個(gè)編號(hào)（session ID）。如果對(duì)話中斷，下次重連的時(shí)候，只要客戶端給出這個(gè)編號(hào)，且服務(wù)器有這個(gè)編號(hào)的記錄，雙方就可以重新使用已有的”對(duì)話密鑰”，而不必重新生成一把。

session ID是目前所有瀏覽器都支持的方法，但是它的缺點(diǎn)在于session ID往往只保留在一臺(tái)服務(wù)器上。所以，如果客戶端的請(qǐng)求發(fā)到另一臺(tái)服務(wù)器，就無法恢復(fù)對(duì)話

session ticket

客戶端發(fā)送一個(gè)服務(wù)器在上一次對(duì)話中發(fā)送過來的session ticket。這個(gè)session ticket是加密的，只有服務(wù)器才能解密，其中包括本次對(duì)話的主要信息，比如對(duì)話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對(duì)話密鑰了。

目前只有Firefox和Chrome瀏覽器支持。

總結(jié)

https實(shí)際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護(hù)航，主要用到對(duì)稱加密、非對(duì)稱加密、證書，等技術(shù)進(jìn)行客戶端與服務(wù)器的數(shù)據(jù)加密傳輸，最終達(dá)到保證整個(gè)通信的安全性。

如何部署https加密

加密App及網(wǎng)頁通訊可確保使用者信息安全，越來越多的網(wǎng)站已經(jīng)開始使用更安全的https加密傳輸協(xié)議。因此任何新站點(diǎn)或新的web應(yīng)用都應(yīng)該上線前啟用https加密， 確保用戶體驗(yàn)和業(yè)務(wù)未受影響。使用https協(xié)議就意味著需要在服務(wù)器上部署SSL證書。

為你的網(wǎng)站和應(yīng)用啟用https加密，需要使用全球信任的SSL證書，即根證書內(nèi)置在所有平臺(tái)的證書，并且選擇國(guó)際化的CA，可以保證長(zhǎng)久提供穩(wěn)定、可靠、安全的SSL數(shù)字證書服務(wù)。

亞洲誠信是賽門鐵克（Symantec）亞太區(qū)首席安全技術(shù)專家戰(zhàn)略合作伙伴，提供國(guó)際知名的Symantec SSL證書可滿足ATS的各項(xiàng)要求，在SSL證書管理、監(jiān)控和風(fēng)險(xiǎn)評(píng)測(cè)等擁有業(yè)內(nèi)領(lǐng)先的技術(shù)解決方案和高效專業(yè)化的技術(shù)支持服務(wù)，能夠幫助用戶快捷且正確配置SSL證書。

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認(rèn)為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請(qǐng)及時(shí)與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會(huì)在5工作日內(nèi)聯(lián)系您，一經(jīng)查實(shí)，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://jstctz.cn/20472.html

上一篇：<Tomcat 6 服務(wù)器證書安裝配置指南 下一篇：巴西銀行網(wǎng)站攻擊案例分析>

相關(guān)開發(fā)語言

• java 使用ssl，tls 證書認(rèn)證

  日期：2018-04 瀏覽次數(shù)：6845

• nginx配置ssl雙向證書

  日期：2017-02 瀏覽次數(shù)：3513

• CA和證書，SSL

  日期：2017-09 瀏覽次數(shù)：3752

• 阿里云申請(qǐng)免費(fèi)SSL(CA)證書(二)

  日期：2017-12 瀏覽次數(shù)：3598

• certbot配置網(wǎng)站SSL安全證書

  日期：2018-12 瀏覽次數(shù)：4907

• HTTPS協(xié)議：概述以及證書申請(qǐng)流程

  日期：2016-12 瀏覽次數(shù)：4667

• 菜鳥教程——http和Https、SSL

  日期：2017-07 瀏覽次數(shù)：13713

• 一文讀懂Go的net/http標(biāo)準(zhǔn)庫

  日期：2017-12 瀏覽次數(shù)：3588

• 微信、iOS、安卓如何配置HTTPS加密

  日期：2018-06 瀏覽次數(shù)：4338

• Nginx 配置 HTTPS 服務(wù)器

  日期：2018-05 瀏覽次數(shù)：4520

• 阿里云申請(qǐng)免費(fèi)SSL(CA)證書(一)

  日期：2017-12 瀏覽次數(shù)：3627

• SSL和 HTTPS

  日期：2017-06 瀏覽次數(shù)：4054

• 阿里云證書服務(wù)使用教程（下篇）

  日期：2018-01 瀏覽次數(shù)：4023

• SSL雙向認(rèn)證以及證書的制作和使用

  日期：2016-12 瀏覽次數(shù)：3979

• 微信小程序HTTPS證書申請(qǐng)搭建教程

  日期：2018-08 瀏覽次數(shù)：4490

• 【譯】如何創(chuàng)建SSL自簽名證書

  日期：2017-12 瀏覽次數(shù)：3797

• 安裝SLL證書（HTTPS）

  日期：2016-09 瀏覽次數(shù)：6557

• 網(wǎng)站大限將至？速效救心丸看這里！

  日期：2018-07 瀏覽次數(shù)：3280

• HTTPS請(qǐng)求證書的種類

  日期：2016-12 瀏覽次數(shù)：3298

• 阿里云免費(fèi)證書DV SSL申請(qǐng)過程記錄

  日期：2018-10 瀏覽次數(shù)：3449

• 生產(chǎn)ssl證書

  日期：2018-10 瀏覽次數(shù)：3557

• iOS安全系列之二：HTTPS進(jìn)階

  日期：2018-09 瀏覽次數(shù)：3647

• EV SSL證書

  日期：2018-02 瀏覽次數(shù)：3672

• 蘋果網(wǎng)店 SSL 證書的烏龍？

  日期：2015-05 瀏覽次數(shù)：3595

• SSL證書生成

  日期：2018-09 瀏覽次數(shù)：3379

• HTTPS時(shí)代全面來臨!你的網(wǎng)站安全嗎?

  日期：2018-06 瀏覽次數(shù)：3504

• git忽略ssl證書

  日期：2017-02 瀏覽次數(shù)：3939

• 安裝ssl證書失敗的一種原因

  日期：2018-02 瀏覽次數(shù)：4409

• HTTPS證書

  日期：2018-02 瀏覽次數(shù)：4275

• https-為你的博客加入SSL

  日期：2016-12 瀏覽次數(shù)：3642

最新網(wǎng)站建設(shè)案例

• 

  - 響應(yīng)式 -

  自適應(yīng)

  北京墨臣建筑設(shè)計(jì)事務(wù)所品牌官網(wǎng)

• 

  - 響應(yīng)式 -

  自適應(yīng)

  中山市艾菲特?zé)麸椨邢薰竟倬W(wǎng)建設(shè)

• 

  - 響應(yīng)式 -

  自適應(yīng)

  克萊門特酒業(yè)響應(yīng)式網(wǎng)站建設(shè)

• 

  - 品牌型案例 -

  自適應(yīng)

  廣州逸林假日酒店官網(wǎng)建設(shè)

• 

  - 企業(yè)官網(wǎng) -

  自適應(yīng)

  深圳市好會(huì)通科技有限公司官網(wǎng)建設(shè)

• 

  - 品牌型案例 -

  自適應(yīng)

  BOWLIVING家居網(wǎng)站設(shè)計(jì)建設(shè)

• 

  - 品牌型案例 -

  自適應(yīng)

  悅居Kaisuites品牌網(wǎng)站建設(shè)