擊上方?Java編程技術樂園，輕松關注！及時獲取有趣有料的技術文章
文章很好，耐心閱讀，記得點贊和關注哦~
前幾天和同事討論起CGI的性能、CGI為什么是一項落后的技術的時候，發現其實很多人對CGI等的網關技術并不熟悉。這里相信很多同學也都聽過CGI、fastCGI、WSGI等的詞語，但是應該很多同學都分辨不清它們的區別和聯系，本篇文章，就和大家一起探討這些技術的發展簡史。而本篇文章標題的GI，指的就是Gateway Interface（網關接口）的縮寫。
了解網關接口之前，我們需要先弄清楚兩個東西，Web服務器和Web應用程序。什么是Web服務器？什么是Web應用程序？雖然在我的Django小程序課程里面，有對這兩者的區別展開來介紹，但是這里考慮到很多同學并沒有學習這門課，所以我們先把這兩個概念弄清楚，否則在后面討論起網關接口，也只會一知半解。
首先，什么是Web服務器。Web服務器是服務于網站后臺的一個軟件，是常駐于物理服務器的一個計算機程序。Web服務器可以向瀏覽器等Web客戶端提供文檔，也可以放置網站文件，讓全世界瀏覽；可以放置數據文件，讓全世界下載。目前最主流的三個Web服務器是Apache、 Nginx 、IIS。
Apache是世界使用排名第一的Web服務器軟件。它可以運行在幾乎所有廣泛使用的計算機平臺上，由于其跨平臺和安全性被廣泛使用，是最流行的Web服務器端軟件之一。它快速、可靠并且可通過簡單的API擴充，將Perl/Python等解釋器編譯到服務器中。
Nginx是一款輕量級的Web服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like 協議下發行。其特點是占有內存少，并發能力強，事實上Nginx的并發能力在同類型的網頁服務器中表現較好，中國大陸使用Nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。
這里先簡單討論一下Nginx和Apache的區別，在資源上，Nginx占用的內存更少；在性能上，Nginx的并發能力更強；在社區方面，Nginx和Apache都擁有廣泛的使用者，Apache的插件會比Nginx豐富一些。另外Nginx的功能比Apache要豐富一些，Nginx除了作為Web服務器以外，也經常作為反向代理服務器等使用，而Apache則主要作為Web服務器去使用。
還有IIS，IIS是微軟公司在Windows Server提供的一個Web服務器，一般部署在Windows系統上，也有一定的使用者。
了解了Web服務器，我們接著了解一下Web應用程序。
Web應用程序一般指的是完成業務邏輯的程序，比如熟悉Python語言的，經常會用Django、Flask、Tornado等框架來完成業務邏輯的處理，接受請求，返回結果；熟悉Java語言的，則經常會使用Spring、Spring Boot來完成業務邏輯處理；熟悉PHP語言的，則常用ThinkPHP、Laravel、CI等等框架來完成Web后臺的開發；還有Golang、Node.js等等，都會有相應的框架來完成Web請求的處理。
這些就是定義為Web應用程序的東西，也就是我們常說的Web框架，比如一個Pythoner問另外一個Pythoner，你一般使用什么Web框架呀？這個就是Web應用程序。
那么Web服務器和Web應用程序有啥區別？其實在前面的描述里面，我已經說的比較清楚了，Web應用程序主要是完成業務邏輯的處理，Web服務器則主要是進行外部請求的接收和轉發。這里需要注意的是，我們一般不應該把業務邏輯放在Web服務器上去處理，雖然說Web服務器支持廣泛的腳本來進行拓展，但是我們一般情況下還是不應該把業務邏輯放在Web服務器去處理，比如攔截請求、鑒權處理等等的操作。
看到這里可能有些人又會有疑問了，在開發Web應用的時候，我們直接就可以把應用跑起來接受請求了呀，為啥還需要Web服務器的存在。比如說使用Django的時候，直接輸入命令python manage.py runserver，就可以接收請求了，為啥還需要Web服務器呢。
這主要是從性能上去考慮的，Web應用雖然在開發階段就可以通過一些命令來啟動服務，但是這些功能主要是提供調試所使用的，真正部署上線的時候，如果流量較大，性能是不行的，所以需要有Web服務器的存在。Web服務器是專門用于接收外部請求并處理的軟件，所以Web服務器在性能上會比Web應用更佳，畢竟術業有專攻。Web服務器處理靜態資源請求(CSS、JS、HTML、圖片)等，性能會比Web應用更好。另外對于一些非靜態資源的請求，則需要轉發到后臺Web應用。
到這里，我們基本分清楚Web服務器和Web應用的區別了，這里面我們注意一個關鍵詞“轉發”，當Web服務器接受請求的時候，會把請求轉發到后臺Web應用去處理，我們本篇文章的主角，GI就工作在這個轉發的過程中。
CGI
終于輪到主角“網關接口”。前面介紹了GI工作的地方，接下來我們就來一起探討一下現在有哪些GI，他們有哪些特點和區別。
首先是CGI，CGI是Common Gateway Interface （通用網關接口）的縮寫。CGI是一項古老的技術。最初是在1993年由美國國家超級電腦應用中心（NCSA）為NCSA HTTPd Web服務器開發的。CGI的原理非常簡單粗暴，在支持CGI的Web服務器下，只需要寫一個簡單的腳本，然后在腳本中輸出內容，這些內容就會返回給前臺。舉個簡單的例子，使用Python實現一個hello.py：
#!/usr/bin/env python
print 'Hello, World! Hello CGI.然后把他改名為hello.cgi，部署到Web服務器下，當請求到達的時候，打印的字符串就會通過Web服務器返回到頁面。我們常常稱這種應用為console application (也可以稱作command-line interface programs) 的程序，這樣的腳本稱為CGI腳本。
CGI工作完整的原理是這樣的：
一句話就是 Web 服務器中的 CGI 進程將接收到的 HTTP 請求數據讀取到環境變量中，通過標準輸入轉發給CGI程序；當CGI程序處理完成后，Web 服務器中的CGI進程從標準輸出中讀取返回數據，并轉換回 HTTP 響應消息格式，最終將頁面呈現給用戶。然后 Web 服務器關閉掉這個 CGI 進程。
可以說 CGI 協議特別擅長處理 Web 服務器和 Web 應用的通信問題。然而，它有一個嚴重缺陷，對于每個請求都需要重新 fork 出一個 CGI 進程，處理完成后立即關閉。當請求量比較大時，會有嚴重的性能問題，因為頻繁的創建進程和回收進程，會占用非常多的服務器資源。因為CGI的性能問題，于是新一代的CGI技術，FastCGI應運而生。
快速通用網關接口（Fast Common Gateway Interface／FastCGI）是一種讓交互程序與Web服務器通信的協議。FastCGI是早期通用網關接口（CGI）的增強版本。
FastCGI致力于減少網頁服務器與CGI程序之間交互的開銷，從而使服務器可以同時處理更多的網頁請求。
而FastCGI的工作原理是這樣的：
所以FastCGI可以看作是解決原始CGI性能問題的一個升級版本。
WSGI：全稱是Web Server Gateway Interface，Web服務器網關接口，WSGI不是服務器，Python模塊，框架，API或者任何軟件，只是一種規范，描述前面Web服務器如何與Web應用通信的規范。
前面介紹網關接口的時候介紹了CGI、FastCGI等，那這里的WSGI主要是Python為Web服務器和Web應用程序之間通信而設計的。在Python中，常見的Web框架Tornado、Django、Flask都支持使用WSGI和Web服務器進行通信，而在采用WSGI協議的時候，則常常安裝uWSGI模塊來完成通信。
與WSGI類似的還有一個ASGI，ASGI也是由Python實現的一類網關接口，這里的A指的是Async，異步的意思。ASGI是WSGI的擴展，支持除了原來的HTTP以外的WebSocket等的網絡協議。
終于來到Java陣營了，在前面的CGI、FastCGI、WSGI等等，主要都是PHP、C++、Python等語言實現Web應用程序和Web服務器通信的網關接口，尤其是CGI、FastCGI，在以前C++、PHP大行其道的時候，它們擁有廣泛的用戶基礎，像騰訊等大企業，由于歷史的關系，內部系統中還有很多保留著CGI、FastCGI等技術。那么在Java的陣營下，一般使用什么技術作為Web服務器和Web應用框架之間的通信呢？
Servlet，談到Java不得不談的一項技術，全稱Server Applet，是用Java編寫的服務器端程序，可以看做是前面我們介紹的Web應用程序。其主要功能在于交互式地瀏覽和修改數據，生成動態Web內容。Servlet最初誕生在1997年，最新的一個版本Servlet4.0于2017年9月份推出，Servlet擁有廣泛的用戶群體。
如果說Servlet是應用程序，那Servlet容器就是包含應用程序的Web服務器，常見的Servlet容器就有我們熟知的湯姆貓(Tomcat)、Jetty等，Servlet容器管理著Servlet應用，我們的Servlet程序一般通過Servlet容器對外進行服務。
隨著Docker容器技術和K8S容器編排技術的成熟，今天微服務技術也是非常熱門，而微服務離不開的Spring Boot、Spring Cloud的其中，就有Servlet、Servlet容器的身影。
我們說說Spring Boot，對于Spring Boot，大家都被他快捷的開發和部署方式所吸引，Spring Boot是由早期的Spring框架發展而來的，其設計目的是用來簡化新Spring應用的初始搭建以及開發過程。在我們開發使用Spring Boot開發Web后臺的時候，我們在寫完邏輯代碼的時候，在本地只需要點擊運行，就能通過瀏覽器進行調試，頗為方便；這和前面我們使用PHP、Python開發Web程序非常類似，我們在使用Flask、Tornado等框架開發Web程序的時候，也可以通過簡單的啟動，就可以在本地通過瀏覽器去調試。但是這里是有一些區別的，我們說Flask、Tornado等框架是Web應用框架，沒有說他們是Web服務器，他們通過前面介紹的網關接口(GI)通信，但是在使用Spring Boot的時候，卻很少說需要把它部署在Web服務器Apache、Nginx之下，一般部署Spring Boot應用的時候，我們直接把它打包成jar包，就可以在服務器跑起來對外服務了。這是為什么呢？
其實Spring Boot內嵌了Servlet容器Tomcat，也就是Spring Boot既充當了Web應用程序的角色，也充當了Web服務器的角色，在開發Spring Boot應用程序的過程中，我們是先通過代碼實現了Web應用程序的邏輯，處理請求和應答，而Servlet容器的部分，完全不需要我們去配置，這就是Spring Boot簡單、便捷，高效的開發效率的原因，所以現在很多同學都喜歡使用Spring Boot去開發Web的后臺。Spring Boot提供了簡單的開發模式，但是也帶來一些問題，比如說很多同學根本無法分清楚Web應用程序和Web服務器的區別等等。
最后簡單的回顧一下今天這篇文章，我們主要是介紹了現在Web后端各種網關接口，包括CGI、FastCGI、WSGI等，在理解這些之前，我們需要弄懂Web服務器和Web應用程序，而網關接口，就是主要工作在Web服務器和Web應用程序之間的。最后我們還介紹了Java陣營的技術，在Java現在大行其道的Spring Boot框架里面，我們不再特意強調Web服務器和Web應用程序，Spring Boot框架是把兩個融合在一起的一個框架，Spring Boot可以便捷的開發和部署Web程序，就是因為內部包含了一個叫Tomcat的Servlet容器，也就是Web服務器。
最后希望這篇文章對大家捋清楚Web后臺技術和網關接口都能有一定的幫助
來源：慕課網
作者：咚咚嗆
鏈接：http://www.imooc.com/article/298214
出處：https://www.cnblogs.com/xuanyuan/p/12326610.html
頭條號：大數據與云原生
微信公眾號：大數據與云原生
創作不易，在滿足創作共用版權協議的基礎上可以轉載，但請以超鏈接形式注明出處。
為了方便閱讀，微信公眾號已按分類排版，后續的文章將在移動端首發，想學習云原生相關知識，請關注我。
“老周，有人找你”
一大早，361殺毒公司的老周就被吵醒。
今天的陽光很明媚，老周伸了伸懶腰，這才踱步走向工作室。
“是誰一大早的就來吵吵，壞了我的瞌睡”，聽得出來，老周有點不太高興。
“咚咚～”，老周微微抬頭一瞥，只見一甜美女子出現在工作室的門前。
老周一下從座椅上彈了起來，三步并作兩步，走到女子面前，作出歡迎的手勢：“美女請進”
二人坐罷，老周扶了下鏡框，又整理了一下格子襯衣，一副溫文爾雅的作態，輕聲問到：“不知美女到訪，所為何事？”
女子倒是一副焦急的樣子，“您好，我是Chrome瀏覽器公司的小雪，最近我們訪問千度網、淘貝網的網頁中時常出現不少奇怪的廣告，一直被投訴，聽領導說361殺毒公司的周老師是這方面的專家，想請您幫忙診斷一下，到底這些廣告是怎么來的”
老周聽得有些不好意思，連連揮手，“原來是小雪姑娘，哪里哪里，勇斗病毒木馬，消滅流氓軟件本就是我361公司的分內之事，在下也只是盡一些綿薄之力罷了”。
“周老師別謙虛了，您之前揪出IE公司的木馬入侵的事跡已經傳遍整個Windows帝國了，大家都知道您的厲害。這一次廣告的問題，就拜托了”，小雪看著老周，彷佛眼里閃著星星。
“別客氣，這事兒包在我身上了”小雪起身，連說了幾句謝謝就離開了。
此刻，負責網絡數據過濾的大白正在忙碌著，突然一只手搭在了他的肩膀上，大白回頭一看，正是老周。
“老周，什么風把你吹到這里來了，你不在安全實驗室分析惡意代碼，跑我們網絡部門來干嘛？”
老周拍了下大白的肩膀，說到：“大白啊，有點事想請你幫幫忙，你幫我瞅瞅，Chrome瀏覽器的流量中是不是被插入廣告了？”
“就這事啊，前段時間發現路由器老給插入廣告，我就給做了特征屏蔽，原以為它們消停了，這才沒幾天又卷土重來了？”，大白說完調出了Chrome公司的流量，準備一看究竟。
大白越看眉頭鎖的越緊，“應該沒有吧，我看訪問千度網和淘貝網都是用的HTTPS協議，按理說路由器沒有可能插入廣告了啊”
“HTTPS協議？為什么用這個就沒法插入廣告？”，老周問到。
“這都不知道啊，你這361公司安全實驗室領導怎么當上去的啊”，大白一臉無語的表情。
老周有點難為情，“唉，老弟你也別取笑我了，這個術業有專攻嘛，我擅長病毒木馬代碼的分析，對網絡協議這塊確實知之甚少，勞煩大白老弟給說道說道”
大白似乎是感覺自己的話說的有些重了，也借坡下坎，“老周啊，剛才我跟你開玩笑的，你可別往心里去啊”。
“沒事沒事，你快給我說說這HTTPS協議，幫助我早點破案吧”“好嘞，你稍等啊”，說完，大白開始在白板上畫了起來。
“HTTPS ＝ HTTP ＋ SSL／TLS，這門技術，說簡單也簡單，說復雜也復雜。簡單來說，就是為了網絡數據的安全性，通過加密傳輸的方式來對傳統上網的HTTP流量進行保護”，大白一邊畫著圖一邊給老周講述。
“明白，那么問題來了，用什么加解密算法呢？對方如何知道用什么算法以及用什么密鑰解密呢？”，老周一下抓到了關鍵點。
“唉，問到點子上了。在正式傳輸數據之前，雙方會有一個協商過程，為后面所選擇的加密算法，以及要使用的密鑰達成一致。”
“那么問題又來了，這個協商的內容要是被別人知道了，他不就可以按圖索驥，解密傳輸的內容了嗎？”，老周的反應很快。
“老周果然是老周！加密算法被知道是無所謂了，畢竟算法都是公開的，關鍵在于這個用于后續加密的密鑰，這個才是需要保護的關鍵，這個不能讓別人知道”，說罷，大白又繼續畫起來。
“so？怎么保護這個密鑰呢？你倒是說啊”，老周有點著急了。
“注意哦，高能來了，雙方使用一個叫非對稱加密的方式來傳輸...”
"等一下"，老周打斷了大白，“非對稱加密，這是個什么意思？”
大白默默嘆了一口氣，“常見的加密方式叫對稱加密算法，所謂對稱，就是加密和解密使用同一個密鑰。那與此相對的，非對稱加密，就是說加密和解密使用的是不同的密鑰，明白了吧”
老周略微思索，點了點頭，“我知道了，你繼續剛才說的，怎么用這個非對稱加密算法來傳輸后面需要的密鑰呢”
大白繼續說到：“客戶端產生一個隨機數，使用公鑰加密，發給服務端，服務端使用私鑰解密取得這個隨機數，再根據這個隨機數和其他信息計算出一個key，就作為后續加密內容使用的密鑰了”
“等等，客戶端的公鑰是哪里來的？”
“最開始的時候，客戶端發來請求，服務端在響應中，會把公鑰告訴客戶端。好了，我畫完了，整個過程就是這樣的”，大白放下畫筆，一副完整的HTTPS協議握手過程圖浮現了出來：
老周反復端詳，許久總算開口：“過程我倒是看懂了，不過我總感覺這不多此一舉嗎，直接使用非對稱加密算法不就得了，這么折騰”
大白連連揮手，“你想的倒是簡單，非對稱加解密算法執行起來麻煩的多，耗費的時間會多很多倍，如果全程使用非對稱加密算法，那將會嚴重影響上網體驗。算法是個好算法，但用的代價也很大，所以權衡之下，好鋼用在刀刃上，就只用來傳輸密鑰，后面的正式數據傳輸，還是用常規的對稱加密算法，來的經濟劃算。”
老周點了點頭，一會兒低頭思考，一會兒又抬頭看著流程圖。
又過了許久，老周指著流程圖，再次提問：“我說大白，如果我在客戶端和服務端之間插入一個角色，對客戶端冒充服務端，對服務端又冒充客戶端，就能從中作梗，修改數據包，插入廣告了是吧？”
正在喝水的大白聽后嗆得連連咳嗽，“你說的就是中間人攻擊嘛！你當HTTPS是玩具嘛，這么容易就被劫持，笑話！注意看圖，那里有個認證環節，不是誰都能冒充的”老周又看了看圖，“怎么認證法，我倒是聽聽”
“在服務端的響應中，我前面說的公鑰是在一個叫證書的東西里面，這個證書就是用來標識服務端的身份的，是由權威機構頒發的，客戶端收到證書后，會檢查是否是可信任的，如果不受信任就會及時中止后面的流程。”
“那如何判斷一個證書是可信任的呢？”“帝國早已把受信任的證書安裝好了，屆時只需調用API查一下即可”
老周思來想去，總覺得哪里有問題，卻又說不上來。
一連過了幾天，老周依舊毫無頭緒，這事兒就這樣擱置了。福無雙至，禍不單行。這案子還沒弄明白，firefox公司又出事了。原來，361殺毒公司檢測到firefox秘密啟動了有木馬特征的進程，老周再一次帶隊前往勘查，firefox公司的小狐負責對接此事。
老周來到了firefox磁盤存儲目錄，打算先排查一下木馬文件是什么來頭。
“這是一堆什么數據？”，老周指著一堆文件問到。
“周老師，這是網頁緩存數據”，一旁的小狐回答。
“打開看看，看看能否找到一些攻擊痕跡”
老周環顧四周，指著另一堆文件問到：“這又是一堆什么數據？”
“周老師，這是一堆證書信息，HTTPS握手時認證服務器所用的，跟這次攻擊事件應該沒關系的”，小狐繼續解釋到。
“認證用？帝國不是存儲了受信認的證書嗎，你們還保存證書信息做什么？”，老周有些不解。
“帝國存儲的受信任證書我們可不認，誰知道那里面都是些什么證書，太不可靠了，我們firefox瀏覽器公司自己做認證，不用那一套”，小狐言語之間流露著些許得意。
聽完小狐的回答，老周突然愣住了，短暫的幾ms之后反應了過來，掏出了從Chrome公司拿來的千度網證書，打算請小狐看一下。
小狐接過證書，仔細察看，片刻之后一口咬定的說：“這證書有問題！”老周眼前閃過一道亮光，追問到：“哪里有問題？”
“這證書頒發機構叫ABSafe，不在我們受信任的列表中！再說了，我這里有緩存千度網的證書，根本不是這樣的，這肯定是假的，你看”
老周拿著兩個證書反復查看，不時點點頭，之前困擾多時的問題終于有了答案。
“我明白了，真相只有一個！一定是有人把這個ABSafe頒發機構安裝到了帝國受信任列表，以此騙過了Chrome公司！進行了HTTPS中間人劫持！YES！”，老周說完用力揮了揮拳頭。
“周老師，您在說什么啊，我怎么聽不懂？”，看著老周自言自語，小狐滿臉的問號。
老周叮囑同行的老齊繼續勘察，匆忙拜別小狐就離開了。
這天夜里，兩個黑影出現在了帝國受信任根證書倉庫。
“原來是有人把我們安裝的根證書給刪掉了，難怪剛才Chrome瀏覽器訪問千度網報了警告”，其中一個胖的黑影說到。
瘦的黑影捂住了胖子的嘴巴，“噓，你給我把著點風，我去重新裝上”
瘦的黑影躡手躡腳走了過去，從懷里掏出了一個東西。
“別動！安全檢查！”，突然一束光線射了過來，原來老周帶著隊伍在此潛伏多時了。
“竟然是你們，禁廣大師！千度網和淘貝網的廣告也是你們加的是吧？”，老周大聲質問。
胖瘦黑影面面相覷，老實交代了一切。
未完待續·······
彩蛋
“老齊，firefox公司的案子有什么發現嗎”
“老周，你還是再來一趟吧，情況有點復雜”