，是这个世界上最神奇的语言与动作，我们可以用笑来对抗地心引力带来的面容衰老，也可以用微笑释放善意，与世界和睦相处。而摄影师则承担着更重的责任，他要将这些最动人的笑容，通过镜头记录下来，再将这份感动，传递给更多人。

本次影赛评委从纪实、人像等不同的题材中，精挑细选出了本次影赛的优胜名单。恭喜以下获奖者！

一等奖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（证书权威机构）申请数字证书，来保证服务器的身份是可信的;

来源：我没有三颗心脏

作者：我没有三颗心脏