整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
當您網上沖浪時，HTTP 協議無處不在。當您瀏覽網頁、獲取一張圖片、一段視頻時，HTTP 協議就正在發生。
本篇將盡可能用簡短的例子和必要的說明來讓您了解基礎的 HTTP 知識。
目錄：
互聯網是有關 web 客戶端和 web 服務器之間的通信。
HTTP（HyperText Transfer Protocol）又叫超文本傳輸協議。本質上就是一個協定好雙方如何進行交流溝通的約定。
這就好比我在一起玩游戲的朋友群里發送一條 「1？」 的消息，朋友們就立即知道是在詢問今晚是不是要一起游戲的意思。
但是如果我給其他人發送 「1？」 就可能出現問題：他們不知道我在說什么。
調皮地給我媽發了一下試試...
本質上，這就是 HTTP 協議所代表的含義。我們已經同意，如果我們以特定的方式發送消息，則服務器就會理解消息的意圖并作出回應。
1989 年 3 月，互聯網還只屬于少數人。在這一互聯網的黎明期，HTTP 誕生了。
來源：《圖解HTTP》
1989年，當時還在歐洲核子研究組織（CERN）工作的蒂姆·伯納斯·李（Tim Berners-Lee）提出了一種能讓遠隔兩地的研究者們共享知識的設想。
蒂姆·伯納斯·李 來源：wiki
最開始稱為 Mesh，后來在 1990 年實施期間將其重命名為 World Wide Web（萬維網）。它基于現有的 TCP/IP 協議構建，包括 4 個部分：
這四部分在 1990 年底完成。雖然此時 Web 頁面只能顯示單純的文本內容，瀏覽器也只能顯示呆板的文字信息，不過這已經基本滿足了建立 Web 站點的初衷，實現了信息資源共享。
1991 年創建的第一個網頁
以下就是 HTTP/0.9 的請求內容：
GET /page.html
用唯一可用的 GET 方法向目標服務器獲取指定的文檔。（一旦連接到服務器，協議、服務器、端口號這些都不是必須的）
響應也極其簡單：只包含文檔本身。
<HTML>
網頁的內容
</HTML>
這意味著 HTTP/0.9 只能夠傳輸 HTML 文件。一旦出現問題，一個特殊的包含問題描述信息的 HTML 文件將被發回，供人們查看。
由于 HTTP/0.9 協議的應用十分有限，加之 HTTP 使用量和 HTML 的高速發展，瀏覽器和服務器迅速擴展其內容使其用途更廣：
----------HTTP/0.9請求----------
GET /page.html
----------HTTP/1.0請求----------
GET /page.html HTTP/1.0 -> 新增協議版本
----------HTTP/0.9響應----------
<HTML>
....
</HTML>
----------HTTP/1.0響應----------
200 OK -> 新增狀態碼
<HTML>
....
</HTML>
HTTP/0.9 規范大約只有一頁，而 HTTP/1.0 在 RFC-1945 中定義的規范則足足有 60 頁。這說明 HTTP 已經成長為一個重要的工具。
盡管 HTTP/1.0 從 HTTP/0.9 有了很大的飛躍，但仍然存在許多必須解決的已知缺陷。例如與 TCP 協議交互不良、沒有充分考慮緩存等問題。
拿與 TCP 協議交互不良舉例。由于 HTTP 是基于 TCP 建立的，所以通訊之前需要建立連接，通訊結束之后需要斷開連接。
HTTP/1.0 每一次的通訊都需要建立并斷開連接，這無疑增加了無謂的通信開銷。
文檔 RFC 1945 定義了 HTTP/1.0，但它是狹義的，并不是官方標準。所以實際運用起來非常地混亂。所以實際上自 1995 年開始，即 HTTP/1.0 文檔發布的下一年，就開始修訂 HTTP 的第一個標準化版本。
HTTP/1.1 在 1997 年 1 月以 RFC 2068 文件發布。HTTP/1.1 消除了大量歧義內容并引入了多項改進：
一個典型的請求流程， 所有請求都通過一個連接實現，看起來就像這樣：
由于 HTTP 的可擴展性——創建新的頭部和方法是很容易的——HTTP 協議穩定使用了超過 15 年。期間不斷對 HTTP/1.1 協議進行修訂（RFC 2616、RFC 7230、RFC 7235），為 HTTP/2.0 作了十足的鋪墊。
這些年來，網頁愈漸變得復雜，甚至演變成了獨有的應用，可見媒體的播放量，增進交互的腳本大小也增加了許多：更多的數據通過 HTTP 請求被傳輸。
在 2010 年到 2015 年，谷歌通過實踐證明了實驗性的 SPDY 協議的可行性，這成為了后來 HTTP/2 協議的基礎。
來源：https://www.keycdn.com/support/spdy-protocol
HTTP/2 在 HTTP/1.1 有幾處基本的不同：
*注：這里 HTTP/2 并不是合并成一個包，而是分成多個 Stream 發送，這里只是為了繪畫方便。
大家可以通過點擊這里直觀感受到 HTTP/2 比 HTTP/1.1 快了多少。
詳細的 HTTP/2 優秀的地方可以參看下 4 鏈接
在 2015 年 5 月正式標準化后，HTTP/2 取得了極大的成功，在 2016 年 7 月前，8.7% 的站點已經在使用它。高流量的站點最迅速普及，在數據傳輸上節省了可觀的成本和支出。
這種迅速的普及率很可能是因為 HTTP2 不需要站點和應用做出改變：使用 HTTP/1.1 和 HTTP/2 對他們來說是透明的。
擁有一個最新的服務器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和服務器的更新，而不需 Web 開發者做什么，用的人自然就增加了。
隨著 HTTP/2 的發布，就像先前的 HTTP/1.x 一樣，HTTP 沒有停止進化。HTTP 的擴展性依然被用來添加新的功能。
HTTP 的進化證實了它良好的擴展性和簡易性，釋放了很多應用程序的創造力并且情愿使用這個協議。
HTTP/3 是即將到來的第三個主要版本的 HTTP 協議。與前任協議不同，在 HTTP/3 中，將棄用 TCP 協議，改為使用 UDP 協議和 QUIC 協議實現。
此變化主要為了解決 HTTP/2 中存在的隊頭阻塞問題。由于 HTTP/2 在單個 TCP 連接上使用了多路復用，受到 TCP 擁塞控制的影響，少量的丟包就可能導致整個 TCP 連接上的所有流被阻塞。
截至 2021 年 1 月，HTTP/3 仍然是草案狀態。
HTTP 協議在設計之初就沒有充分考慮安全性的問題。所以基于 HTTP 的這些應用都承擔著如下的幾個風險：
HTTPS（HTTP over SSL）采取嵌套新一層安全套接字層（Secure Socket Layer,SSL）來解決網絡傳輸的安全性問題。
加密是很容易聯想到的解決方法。但如何保證傳輸加密方法的過程不被竊聽呢？
這時候非對稱加密的出現解決了這一大難題。它把密碼革命性地分成公鑰和私鑰，由于兩個秘鑰并不相同，所以稱為非對稱加密。
舉個例子，假設我們現在需要加密的字符是 520，我們加密的方法是把這個數乘以 91，并把結果的最后三位公布出來：
注：這里的 91 相當于公鑰，任何人都可以知道。
解密我們當然不能通過除以 91 來完成，而是通過 x11，取出結果后三位來還原：
注：這里的 x11 相當于私鑰，只有解密方才知道。
這是因為 91*11=1001，任何一個三位數乘以 1001 顯然后三位是不會變的。這大概就是非對稱加密的原理了，基于這個原理我們通信的雙方就可以各自生成自己的公鑰私鑰并進行相對安全的通信了。
非對稱加密通信演示
上面的過程看似無懈可擊，但在 TCP/IP 的端到端的通信里，路途遙遠，夜長夢多。
如果在第二步的時候，信息被黑客截取，在嚴刑拷打之下知道了這是傳輸公鑰的信息。那么完全可以自己生成一對密鑰和公鑰，冒充是彼此來傳輸自己的秘鑰。
加密危機之后，又產生了信任危機。我們需要一個有公信力的組織來證明身份，這個問題就得到了解決。
這個可信的組織就是頒發 HTTPS 證書的組織 CA（Certificate Authority）。每次有客戶端或者服務端想要公開自己的公鑰時，都需要向 CA 做出申請，通過后 CA 會頒發一個與公開公鑰綁定的數字證書。(了解更多證書)
進行 HTTPS 通信時，服務器會把證書發送給客戶端，客戶端取得其中的公開密鑰之后，先進行驗證，如果驗證通過，就可以開始通信。
在之前介紹比特幣原理的時候，我們提到過一種哈希算法。它的作用是能把任意長度的輸入編程固定長度的二進制輸出。
注：為了簡化右邊為 16 進制數
在 HTTPS 中，有一種新的摘要算法，可以簡單理解為是對于內容的一種壓縮。所以但凡內容變化一丁點，哪怕是一個標點符號，壓縮之后的數字哈希也不對。
客戶端在發送明文之前會通過摘要算法算出明文的 「指紋」，發送的時候把 「指紋 + 明文」 一同加密成密文后，發送給服務器。
服務器解密后，用相同的摘要算法算出發送過來的明文，通過比較客戶端攜帶的 「指紋」 和當前算出的 「指紋」 做比較，若 「指紋」 相同，說明數據是完整的。
盡管聽上去 HTTPS 就是更安全的 HTTP，但也有許多細節方面的不同：
來源：我沒有三顆心臟
作者：我沒有三顆心臟
們選擇客戶關系管理（CRM）應用做演示。 本文主要講解低代碼工具配置生成應用的主體流程，更多的細節需要參考文檔。
先從大邁云官網下載安裝低代碼工具,地址www.mvcx.net/download.html。 當然你如果手邊有其他的低代碼工具，可以直接使用， 基礎層面的功能相差不大。
分六個主要步驟完成配置：
1、配置數據表與字段
2、設置數據表關聯
3、配置枚舉項
4、配置用戶角色
5、配置菜單及授權
6、配置可用頁面
官方演示地址: https://center.mvcx.net/web/index.html#/apps/doc/128
一、配置數據表與字段
客戶關系管理（CRM）中，我們選擇具有代表性的多張數據表用作配置。 分別是客戶/財務合同/產品/財務合同明細/回款明細/開票明細 ， 每張表都配置了一系列字段。
數據表的細節參考官方演示的Excel表格。 按照Excel模板整理完多張表的字段，在后臺一次性導入，創建數據結構。 一次性導入的目的，是為了項目有個整體的規劃性，避免后面頻繁修改數據表。后期可對數據結構（表與字段) 進行修改， 對單表增加字段，需要走完整的配置流程。 添加字段\字段授權\綁定字段到頁面。
在創建數據結構的同時，我們可以選擇同時創建默認操作頁，包括表單頁，列表查詢頁，展示頁等， 自動化地完成基礎CRUD功能。
二、設置數據表關聯
在后臺數據表->數據關聯中設置表之間關系，等同于數據庫外鍵。
財務合同 - N:1 - 客戶
財務合同明細 - N:1 - 產品
財務合同明細 - N:1 - 財務合同
回款明細 - N:1 - 財務合同
開票明細 - N:1 - 財務合同
這里不涉及多對多的關系，相對簡單。 設置完表關聯后， 絕大多數的交叉調用， 都由系統自動來完成，包括多表查詢，外鍵約束等。
三、配置枚舉項
這里我們要用到枚舉項有, 省份\公司類型\跟進狀態\審核狀態\合同類型\合同流程\合同進度\付款方式\產品狀態\結算方式等。
在后臺管理，基礎數據中設置， 然后把枚舉項綁定到對應字段，其他交給系統來完成。
四、配置用戶角色
在后臺管理->人員權限-> 角色權限里設置
企業管理系統，我們一般配置 user(普通用戶), sales(銷售) , manager(銷售經理) , finance (財務) ,admin (系統管理員）, hr（人力資源) 等。
后面我們會根據角色，給相應的人員授權不同功能。 角色不完全等同于公司里的職位， 很多時候一個人是身兼多個角色。
五、配置菜單及授權
在后臺管理 -> 菜單頁面 -> 可用菜單中操作
先創建一級菜單， 然后創建二級，三級菜單。 菜單配置路由，才能導航到特定頁,配置路由的簡單方式， 在菜單頁面->可用頁面中，點擊（+菜單），就把當前頁添加到了菜單項中，
對應的路由也已設置。 熟悉后可以手動設置路由項，開啟更多功能。 在菜單設置中，為當前菜單設置父菜單，以及排序。
對菜單進行角色授權，允許那些角色看到或使用那些菜單。 實時配置的菜單會在用戶第二次登陸后生效，或直接當前頁刷新網頁。菜單可以配置圖標, 顏色。這里我們分別設置客戶，合同，產品等相關菜單
六、配置可用頁面
在創建數據表時，系統已經默認創建了單表的表單頁，列表查詢頁，詳情展示頁等。 我們對系統生成的頁面進行進一步配置，來完善功能。 很多時候配置是設定交叉表的字段引用，系統會自動生成
絕大多數代碼。 各種頁面也存在組合形式，當前演示中，財務合同表單，就是組合頁面類型，附帶子表合同明細。 頁面需要授權，綁定到菜單才能正式使用。
系統內置了十多種通用的頁面模型， 這些模型都來自于常規應用的抽象，通過配置頁面就完成了終端用戶可用的功能。 很多功能都是PC端、移動端一起生成的。
這里的配置有比較多的細節、參數要調整 ，可以參考官方文檔，或者安裝應用后，直接看成型的配置。
配置完成后的演示截圖。
低代碼工具生成表單
低代碼工具生成列表
低代碼工具生成移動端
如果你有1-2年的編程經驗，可以很輕松地利用低代碼工具搭建一個基礎應用。
下面一個課時，我們將著重講低代碼編程的靈活性，怎樣適應各種定制化的場景。 近幾年來IT技術的發展，使得低代碼編程能夠覆蓋更廣的范圍。
請關注我們的公z號: 大邁云， 可直接在大邁云官網mvcx.net下載低代碼編程工具。
404頁面的目的是：告訴瀏覽者其所請求的頁面不存在或鏈接錯誤，同時引導用戶使用網站其他頁面而不是關閉窗口離開。
現在大部分開源系統都會為大家考慮到404頁面的跳轉引導，比如：z-blog/wordpress，都是很不錯的開源系統（注意不要用最原始的開源系統，而是采用帶有模板的系統）。菜鳥后院網站本身也是wordpress的開源程序，然后我們用robin模板。(花299元擁有和菜鳥后院一樣的網站，包括域名和1G阿里巴巴云空間)
搜索引擎使用 http 狀態碼來識別網頁的狀態。當搜索引擎獲得不正確的鏈接時，網站應該返回一個狀態代碼404，告訴搜索引擎放棄索引該鏈接。如果返回一個200或302狀態代碼，搜索引擎會對鏈接進行索引，導致許多不同的鏈接指向相同的頁面內容。結果，搜索引擎對這個網站的信任度大大降低。很多網站存在這個問題，那就是404頁面返回的是200或302狀態碼而不是404狀態碼。
1、做一個簡單的404頁面，命名如：404.html；
2、通過ftp把這個404頁面上傳到網站根目錄；
3、進入虛擬主機管理后臺，找到404頁面提交的入口，添加以上404頁面的地址，如：www.cnbackyard.com/404.html（一般空間服務商都有帶著種功能，也可以直接找他們技術客服完成這步操作）
4、輸入一個錯誤的鏈接進行訪問測試，隨便輸入，比如：www.cnbackyard.com/123.html，如果正確返回到404.html頁面，則算正確；
5、使用站長工具（http://tool.chinaz.com/pagestatus），輸入任意一個錯誤網址，檢查返回值是否為404。如果返回值是200，代表該主機商設置有誤，可以與其技術反饋。
以上操作方法對于一個seo初學者來說，還是有點復雜，同學們可以關注燃燈教育直播課程，參加我們的培訓，理解起來會更透徹一點。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
