，是這個世界上最神奇的語言與動作，我們可以用笑來對抗地心引力帶來的面容衰老，也可以用微笑釋放善意，與世界和睦相處。而攝影師則承擔著更重的責任，他要將這些最動人的笑容，通過鏡頭記錄下來，再將這份感動，傳遞給更多人。

本次影賽評委從紀實、人像等不同的題材中，精挑細選出了本次影賽的優勝名單。恭喜以下獲獎者！

一等獎2名 獎品為希捷2T移動硬盤1個+獲獎作品定制明信片一套

（以下排名不分先后）

HelloMover-平凡人給我最多感動

http://bbs.fengniao.com/forum/10690131.html

評委點評：作者多達36張的投稿作品，主角均是我們身邊再平凡不過的普通人。從他的作品中，我們能讀出這些小人物豁達的笑容里夾雜著堅忍、悲傷或喜悅，也折射出更真實、更復雜的歲月故事。作者將李宗盛寫過的一句歌詞“平凡的人給我最多感動。”作為組圖名稱，也希望這組照片能給與大家片刻的思考與震撼。

huph007-旅途中的動人微笑

http://bbs.fengniao.com/forum/10690058.html

評委點評：這組作品多是作者于旅途中捕捉到的笑容瞬間，雖是旅拍作品，但依然把握住了“決定性瞬間”。畫面角度構圖變化多樣，人物的笑容是照片的中心主題，但因為環境的加入更有故事感。

二等獎4名 獎品為富圖寶八爪魚支架1個+獲獎作品定制明信片一套

（以下排名不分先后）

雨萌-錫蘭的微笑

http://bbs.fengniao.com/forum/10696790.html

評委點評：在斯里蘭卡十天的旅行中，作者印象最深的是當地居民的微笑；無論是老人還是小孩，他們的微笑無不透著一份平和、淡然。在旅行中沒有過多的時間進行思考，精彩的瞬間往往轉瞬即逝，作者憑借著扎實的基本功，很好地利用光線，突出畫面中最想表達的部分，令人印象深刻。

Andy_wan-清邁綿羊牧場

http://bbs.fengniao.com/forum/10695933.html

評委點評：這組旅拍作品，無論是從模特的服裝搭配還是妝發造型都能看出拍攝者的用心。一組好的人像作品，絕不只是因為有一位好看的模特。場景的選擇、光線的把握，模特的情緒，與環境的互動，都是一組優秀作品不可缺少的元素。

北緯18度大叔-被一對老夫婦所感動

http://bbs.fengniao.com/forum/10696366.html

評委點評：這組照片是作者在海邊拍攝時，記錄了一對白發老人在海邊自拍的場景。老爺爺熟練地支上三腳架、架好手機、彎腰構圖，當他按下屏幕拍攝按鈕的時候再迅速來到老伴身旁，兩人默契的擺好造型等到拍攝時刻。這組圖不僅記錄了老人發自內心的幸福笑容，還有著兩代攝影人因攝影而結緣的感動。這讓我想起前幾天的話題，“攝影人是孤獨的嗎”？也許很多時候在攝影路上我們是孤軍前行的，但從照片里傳遞出去的情感，因為攝影收獲的滿足感和幸福感，都讓我們不再孤獨。

stvezou-群芳爭艷

http://bbs.fengniao.com/forum/10701736.html

評委點評：近年來，古風人像已經成為大熱的題材，但一次性拍“四美人”的作品，還是比較少見的。多人拍攝難度比單人拍攝要大得多，如何在一個場景中展現安排人物位置，如何在組圖中展現主角的個性等等都是需要被考慮到。作者的這組作品，不僅模特妝發講究，拍攝場景古色古香，在拍攝時也都也都安排了讀書寫字的場景，在后期處理時運用了仿畫意的手法，更突顯古典中國風的韻味。

三等獎8名獎品為大號鏡頭內膽包1個+獲獎作品定制明信片一套

（以下排名不分先后）

江浙人士-笑意寫在臉上

http://bbs.fengniao.com/forum/10702601.html

作者點評：尼泊爾是一個GDP指數不高的國家，但尼泊爾人的臉上，常常洋溢著自然、自足的笑意。作者記錄下尼泊爾人民的用微笑，將人與人之間的友愛自然地傳遞了出去。

小豬的一些事情-你的微笑.心中的陽光

http://bbs.fengniao.com/forum/10692239.html

評委點評：兒童攝影人像攝影中困難較大的一種，因為每個小孩子天性都很活潑，能讓他們乖乖站住可不是件簡單事。只有通過不停的抓拍才能捕捉到她們非常可愛的一面。作者拍攝的這組作品，不僅記錄下了這對混血雙胞胎姐妹微笑、調皮的瞬間，也很好地利用了一些道具、環境表現兒童天真無邪的一面，清新的色調更是為整組照片加分不少！

賓得小金-赤木晴子的JK制服

http://bbs.fengniao.com/forum/10696636.html

評委點評：與作者的標題一樣，照片里的女生無論是發型還是臉型，都很容易讓人聯想到熱血動漫《灌籃高手》中赤木晴子這位經典角色。樹下淡淡的笑容，校園走道中不經意的抬頭瞬間，都很符合“初戀女神”的形象。如果組圖能再加入一些球場的畫面，也許更能引起大家對青春的回憶吧！

沐靈兒ml-你說霞染天光，風月琳瑯

http://bbs.fengniao.com/forum/10703420.html

評委點評：作者用淺色的前景和后期柔光效果，營造出了一種朦朧夢幻的感覺。整組照片加入了一些局部、特寫的拍攝，不僅豐富了畫面，也更突出女性柔美的特質。模特的妝發、照片的色調都很有一種80年代畫報的感覺，很讓人眼前一亮。

良牙-暹粒少年們

http://bbs.fengniao.com/forum/10701957.html

評委點評：這組暹粒少年的笑容極具感染力呀，僅是看著照片，都讓人忍不住也嘴角上揚了起來。這組照片濃郁的色彩讓人印象深刻，不知道這是不是就是傳說中富士獨有的色彩呢？

糜MIvision-校園jk小清新

http://bbs.fengniao.com/forum/10702867.html

評委點評：這組照片總共有三個場景，教室、走廊和樹林，無論是哪一組圖，都可以單獨被當做單一場景人像攝影的教科書。即使在教室這一環境中，也通過模特的動作表情等展現出了不一樣的情緒，讓人感受到專屬于少女的美感。不同的視角和構圖讓組圖變得豐富起來，絲毫不會有重復感。

顧小白Hala-尤克里里的夏天

http://bbs.fengniao.com/forum/10702253.html

評委點評：這組照片的場景和服裝都是以白色系為主，作者加入了一些鮮艷顏色的道具，例如粉色的尤克里里和彩色的發夾等，使畫面清新的同時又不失活潑。另外值得一提的是，這組照片模特皮膚顏色和質感都很清透，配合甜美的笑容，非常有夏天的感覺。

愛拍照小小胖-粉紅天使的微笑

http://bbs.fengniao.com/forum/10700810.html

評委點評：作者在拍攝這組照片時，選擇了一片有大面積干凈的色塊的場景，再輔佐以一些幾何線條，就構成了這樣一組糖果色的作品。明快的粉紅色調，女生甜美的笑容，當你看見這樣的畫面時，心里會不會感覺很暖很甜蜜呢？

回帖組 優秀獎10名蜂鳥酒后攝影師帆布包一個+定制明信片一張

wofeiyu3721

評委點評：飛來的鴿子剛好落入小女孩的帽子中，好像為女孩兒插上了一對翅膀。美極了！

鐺鐺熊

評委點評：工人的皮膚留下了歲月的印記，但他的笑容依舊有力量。這張照片的光影、色調都很棒，是張有內容的環境人像。

耳總老白

評委點評：即使牙齒都掉光了，還是要笑對人生啊！

二寶0918

評委點評：這是這次入圍作品中不太一樣的一張。這只貓咪失去了一只眼睛，雖然在大家的認知中，動物可能沒有表情，但這張作品里，貓咪嘴角的弧度就像在微笑一樣。

黑森林老狼

評委點評：烏干達的孤兒們，即使生活不易，依然用力地笑著！

漫畫旅館

評委點評：不知道這位白衣天使說了什么話，讓這位爺爺哈哈大笑起來~

品茗攝雪

評委點評：這張照片很有趣味，雖然沒有露出大人的臉，卻從一只手臂中能讀出更多故事性。

秋河

評委點評：這兩位老哥倆也趕著時髦來自拍一張，但好像不太習慣露出笑容呢。

十八度灰先生

評委點評：黃色的帽子和綠色的小鏟子都為畫面增添了一點顏色，孩子的笑容也十分有感染力。

跳水的狼

評委點評：這張作品的顏色鳥醬特別喜歡！橙紅色的主調和女孩兒的笑容相稱極了！

鳥醬將于近日與以上獲獎人員私信溝通，各位獲獎者也可將id、聯系方式、收貨地址以私信形式先行發至鳥醬。請各位獲獎者于6月9日（下周日）前將以上信息與鳥醬確認完畢，逾期將視為放棄領獎。解釋權歸蜂鳥網所有。

沒有獲獎的朋友們也請再接再厲呀！鳥醬也在這里悄悄透露，下一次影賽信息將會于下周一發布！主題為：向往的生活~敬請期待啦！

歡迎關注 蜂鳥網微信公眾號：fengniaoweixin

言

當您網上沖浪時，HTTP 協議無處不在。當您瀏覽網頁、獲取一張圖片、一段視頻時，HTTP 協議就正在發生。

本篇將盡可能用簡短的例子和必要的說明來讓您了解基礎的 HTTP 知識。

目錄：

1. 什么是 HTTP？
2. HTTP 簡史；
3. HTTP 與 HTTPS；

Part 1. 什么是 HTTP？

互聯網是有關 web 客戶端和 web 服務器之間的通信。

HTTP（HyperText Transfer Protocol）又叫超文本傳輸協議。本質上就是一個協定好雙方如何進行交流溝通的約定。

這就好比我在一起玩游戲的朋友群里發送一條 「1？」 的消息，朋友們就立即知道是在詢問今晚是不是要一起游戲的意思。

但是如果我給其他人發送 「1？」 就可能出現問題：他們不知道我在說什么。

調皮地給我媽發了一下試試...

本質上，這就是 HTTP 協議所代表的含義。我們已經同意，如果我們以特定的方式發送消息，則服務器就會理解消息的意圖并作出回應。

Part 2. HTTP 簡史

1989 年 3 月，互聯網還只屬于少數人。在這一互聯網的黎明期，HTTP 誕生了。

來源：《圖解HTTP》

HTTP / 0.9 - 單行協議

1989年，當時還在歐洲核子研究組織（CERN）工作的蒂姆·伯納斯·李（Tim Berners-Lee）提出了一種能讓遠隔兩地的研究者們共享知識的設想。

蒂姆·伯納斯·李 來源：wiki

最開始稱為 Mesh，后來在 1990 年實施期間將其重命名為 World Wide Web（萬維網）。它基于現有的 TCP/IP 協議構建，包括 4 個部分：

• 一種表示超文本文檔的文本格式，即超文本標記語言（HTML）；
• 一種用于交換這些文檔的簡單協議，即 HyperText 傳輸協議（HTTP）；
• 一個客戶端可以顯示這些文檔，第一個 Web 瀏覽器稱為 WorldWideWeb。
• 一個可以訪問文檔的服務器；

這四部分在 1990 年底完成。雖然此時 Web 頁面只能顯示單純的文本內容，瀏覽器也只能顯示呆板的文字信息，不過這已經基本滿足了建立 Web 站點的初衷，實現了信息資源共享。

1991 年創建的第一個網頁

以下就是 HTTP/0.9 的請求內容：

GET /page.html

用唯一可用的 GET 方法向目標服務器獲取指定的文檔。（一旦連接到服務器，協議、服務器、端口號這些都不是必須的）

響應也極其簡單：只包含文檔本身。

<HTML>
  網頁的內容
</HTML>

這意味著 HTTP/0.9 只能夠傳輸 HTML 文件。一旦出現問題，一個特殊的包含問題描述信息的 HTML 文件將被發回，供人們查看。

HTTP/1.0 - 構建可擴展性

由于 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 頭的概念，無論是請求還是響應，允許傳輸其他信息，使協議更靈活以及更具擴展性；

• 在 HTTP 頭的幫助下，具備了除傳輸純文本的 HTML 文件以外，還可以傳輸其他類型文檔的能力（歸功于 Content-Type 頭）；

HTTP/0.9 規范大約只有一頁，而 HTTP/1.0 在 RFC-1945 中定義的規范則足足有 60 頁。這說明 HTTP 已經成長為一個重要的工具。

盡管 HTTP/1.0 從 HTTP/0.9 有了很大的飛躍，但仍然存在許多必須解決的已知缺陷。例如與 TCP 協議交互不良、沒有充分考慮緩存等問題。

拿與 TCP 協議交互不良舉例。由于 HTTP 是基于 TCP 建立的，所以通訊之前需要建立連接，通訊結束之后需要斷開連接。

HTTP/1.0 每一次的通訊都需要建立并斷開連接，這無疑增加了無謂的通信開銷。

HTTP/1.1 - 標準化的協議

文檔 RFC 1945 定義了 HTTP/1.0，但它是狹義的，并不是官方標準。所以實際運用起來非常地混亂。所以實際上自 1995 年開始，即 HTTP/1.0 文檔發布的下一年，就開始修訂 HTTP 的第一個標準化版本。

HTTP/1.1 在 1997 年 1 月以 RFC 2068 文件發布。HTTP/1.1 消除了大量歧義內容并引入了多項改進：

• 連接可以復用，節省了多次打開 TCP 連接加載網頁文檔資源的時間；

• 增加管線化技術，允許在第一個應答被完全發送之前就發送第二個請求，以降低通信延遲；

• 支持響應分塊；

• 引入額外的緩存控制機制，在 HTTP Cache-Control 標頭中引入了很多可以選擇的選項；
• 引入內容協商機制，包括語言，編碼，類型等，并允許客戶端和服務器之間約定以最合適的內容進行交換；
• 能夠使不同域名配置在同一個 IP 地址的服務器上。

一個典型的請求流程， 所有請求都通過一個連接實現，看起來就像這樣：

超過 15 年的擴展

由于 HTTP 的可擴展性——創建新的頭部和方法是很容易的——HTTP 協議穩定使用了超過 15 年。期間不斷對 HTTP/1.1 協議進行修訂（RFC 2616、RFC 7230、RFC 7235），為 HTTP/2.0 作了十足的鋪墊。

HTTP/2.0 - 為更優異的表現

這些年來，網頁愈漸變得復雜，甚至演變成了獨有的應用，可見媒體的播放量，增進交互的腳本大小也增加了許多：更多的數據通過 HTTP 請求被傳輸。

在 2010 年到 2015 年，谷歌通過實踐證明了實驗性的 SPDY 協議的可行性，這成為了后來 HTTP/2 協議的基礎。

來源：https://www.keycdn.com/support/spdy-protocol

HTTP/2 在 HTTP/1.1 有幾處基本的不同：

• HTTP/2 是二進制協議而不是文本協議，不再可讀。頭信息和數據體都是二進制（體積更小），并且統稱為幀(frame)。

• 這是一個復用協議，可以多路復用。并行的請求能在同一個鏈接中處理，移除了 HTTP/1.x 中順序和阻塞的約束;

*注：這里 HTTP/2 并不是合并成一個包，而是分成多個 Stream 發送，這里只是為了繪畫方便。

大家可以通過點擊這里直觀感受到 HTTP/2 比 HTTP/1.1 快了多少。

• 壓縮了 Headers。因為 Headers 在一系列請求中常常是相似的，其移除了重復和傳輸重復數據的成本。實現這一功能的算法被稱為 HPACK 算法;

• 其允許服務器在客戶端緩存中填充數據，通過一個叫服務器推送的機制來提前請求；

詳細的 HTTP/2 優秀的地方可以參看下 4 鏈接

在 2015 年 5 月正式標準化后，HTTP/2 取得了極大的成功，在 2016 年 7 月前，8.7% 的站點已經在使用它。高流量的站點最迅速普及，在數據傳輸上節省了可觀的成本和支出。

這種迅速的普及率很可能是因為 HTTP2 不需要站點和應用做出改變：使用 HTTP/1.1 和 HTTP/2 對他們來說是透明的。

擁有一個最新的服務器和新點的瀏覽器進行交互就足夠了。只有一小部分群體需要做出改變，而且隨著陳舊的瀏覽器和服務器的更新，而不需 Web 開發者做什么，用的人自然就增加了。

后 HTTP/2 進化

隨著 HTTP/2 的發布，就像先前的 HTTP/1.x 一樣，HTTP 沒有停止進化。HTTP 的擴展性依然被用來添加新的功能。

HTTP 的進化證實了它良好的擴展性和簡易性，釋放了很多應用程序的創造力并且情愿使用這個協議。

HTTP/3 - 更好的未來

HTTP/3 是即將到來的第三個主要版本的 HTTP 協議。與前任協議不同，在 HTTP/3 中，將棄用 TCP 協議，改為使用 UDP 協議和 QUIC 協議實現。

此變化主要為了解決 HTTP/2 中存在的隊頭阻塞問題。由于 HTTP/2 在單個 TCP 連接上使用了多路復用，受到 TCP 擁塞控制的影響，少量的丟包就可能導致整個 TCP 連接上的所有流被阻塞。

截至 2021 年 1 月，HTTP/3 仍然是草案狀態。

小結

• HTTP/0.9 只能傳輸單一的 HTML 純文本，不夠靈活；
• HTTP/1.x 有連接無法復用、隊頭阻塞、協議開銷大和安全因素等多個缺陷；
• HTTP/2 通過多路復用、二進制流、Header 壓縮等等技術，極大地提高了性能，但是還是存在著問題的；
• QUIC 基于 UDP 實現，是 HTTP/3 中的底層支撐協議，該協議基于 UDP，又取了 TCP 中的精華，實現了即快又可靠的協議；

Part 3. HTTP 與 HTTPS

為什么需要 HTTPS

HTTP 協議在設計之初就沒有充分考慮安全性的問題。所以基于 HTTP 的這些應用都承擔著如下的幾個風險：

1. 使用明文（不加密）進行通信，內容可能會被竊聽；
2. 不驗證通信方的身份，通信方的身份有可能是偽裝的；
3. 無法驗證信息的完整性，也就是說信息可能是被篡改過的；

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 中，有一種新的摘要算法，可以簡單理解為是對于內容的一種壓縮。所以但凡內容變化一丁點，哪怕是一個標點符號，壓縮之后的數字哈希也不對。

客戶端在發送明文之前會通過摘要算法算出明文的 「指紋」，發送的時候把 「指紋 + 明文」 一同加密成密文后，發送給服務器。

服務器解密后，用相同的摘要算法算出發送過來的明文，通過比較客戶端攜帶的 「指紋」 和當前算出的 「指紋」 做比較，若 「指紋」 相同，說明數據是完整的。

HTTP 與 HTTPS 有什么不同？

盡管聽上去 HTTPS 就是更安全的 HTTP，但也有許多細節方面的不同：

1. HTTP 明文傳輸，存在安全風險的問題。HTTPS 則解決 HTTP 不安全的缺陷，在 TCP 和 HTTP 網絡層之間加入了 SSL/TLS 安全協議，使得報文能夠加密傳輸；
2. HTTP 連接建立相對簡單， TCP 三次握手之后便可進行 HTTP 的報文傳輸。而 HTTPS 在 TCP 三次握手之后，還需進行 SSL/TLS 的握手過程，才可進入加密報文傳輸;
3. HTTP 的端口號是 80，HTTPS 的端口號是 443;
4. HTTPS 協議需要向 CA（證書權威機構）申請數字證書，來保證服務器的身份是可信的;

來源：我沒有三顆心臟

作者：我沒有三顆心臟