我参加了下一代Web会议，所以写了些备忘录

2 年 ago

宇, 华

1 minute

我一直只是在听后半段的对话，所以没有记笔记呢，哈哈。
因为我也有一些自己的想法，所以正在考虑如何在这个基础上添加。

服务器首选

@cubicdaiya

服务器性能这个话题非常细分且严格。

对于监测这个话题，我无论如何都避免不了提及到它…

我是否觉得网络纪律正在下降？

由于智能手机的普及，性能的重点已经发生了变化
API请求数量增加了

@cubicdaiya
网络访问量占比10％。
虽然转为JSON API后要做的事减少了，但要求的性能却在提高。

在调整中，你注意什么问题，或者你做了哪些改进？

通过观察网站的流量情况，检查哪个地方出现了拥堵。

CPU的使用率正在上升
在一台服务器上有三四万个连接
进行异步处理的部分
将其放入消息队列并由后台的JobWorker来处理

如何处理难以实现高速化的请求？

@cubicdaiya
需要事务的部分成为了瓶颈。输入/输出瓶颈。
用钞票来打。
将主服务器的数据缓存在Redis中。

很难对无法进行缓存的部分进行速度优化。这真是非常困难。我们需要改变规格。

现金策略是如何执行的？

现金是否是银色子弹？
如何权衡易于操作性与之间的折衷？

重要的是数据是否被再利用，如果序列化/反序列化花费太多时间，反而会降低性能。关键是在哪个层面使用缓存。

@cubicdaiya
用于显示所有用户共享的数据
类似排行榜的数据
以用户为单位进行缓存→难道不担心发生意外吗？

可能是文化的问题…
登录后显示的内容不缓存的政策让我很担心。
是缓存的错吧？不对的。我不喜欢这种交互。

这不也涉及到语言选择吗？

我努力让Ruby易于操作哈哈。主要开发语言是？

@xcir
大家都喜欢PHP
只要是合适的，什么都可以。

@cubicdaiya
最近一段时间内，CPU性能已经达到了瓶颈，多核已经成为主流。因此，选择一门易于操作的语言很关键。若想使用多进程来完成任务，由于开销过大，效率并不会有明显提高。因此，在选择框架时应选用非常轻量级的。

请求数量变得越来越多。
一个请求的开销开始显示出作用来。

关于Web服务器的中间件。

这次的重点是这个方面
Varnish你们使用得有多深入？
Nginx呢？

@xcir
我已经了解了一些基本的内容
ESI、存储器…
4.1版本发布后，能够进行更多的调整
现在可以通过加工响应来实现一些操作
开发环境中也使用了Varnish来提高性能

検索サーバー约10台采用Nginx进行负载均衡
通过HTTP发送推送通知请求
使用lua或者mruby进行扩展
通过少量的处理能处理大量的请求的架构

Varnish最近的动态

Varnish对于HTTP/2也有考虑吗？
Varnish对于HTTPS的支持态度如何？
Varnish对于SSL/TLS不感兴趣吗？

网络连接问题

在海外，经常会出现无法连接的情况，你在处理海外连接时有什么特别的技巧？

每个国家的商业习惯不同，因此应用程序会有所区别。
在美国，与日本不同，延迟问题存在。
进行了一些限制TLS握手的措施等等。

@xcir
我对CDN的重要性有着深刻的印象，
尽管在日本并不太受重视。

@mirakui
使用不同的路径可能会导致语言不同
我们在美国东部放置了负载均衡服务器
→ 因为不管请求来自哪里，都会统一变得慢呢哈哈

随便割断海底电缆，哈哈。

“Opera mini非常厉害”
它可以自动将图片缩小
也可以通过AJAX等在服务器端进行渲染
在东南亚地区很流行
听说工程师们都被它折磨得筋疲力尽呢~

关于CDN

随着时间的推移，难道不是小企业无法避免地不得不使用CDN吗？对于小企业来说，在各个国家建立服务器是不可行的。

@xcir
我在使用。
@cubicdaiya
CDN的需求越来越多。像是需要有WAF功能，附带图像管理功能，或者通过API请求进行CDN通信。

前台的瓶颈已经转移到了应用的层面上，感觉在提升。

服务器架构

gRPC Gateway的讨论

@yugui 原文是需要中文翻译成英文的吗？请提供所需翻译的具体句子。

使用Protocol Buffers在HTTP/2传输的库
gRPC很棒。
不好的地方→这就是gRPC Gateway补上的地方
它与基于JSON的API不兼容。

如果要与外部系统进行协作，服务器推送并不总是必要的。由于系统内部和外部的要求不同，需要作为中间人。

你对在内部通信中使用类似gRPC的特定通信方式有什么想法？

制作

作为一名工程师，我想要尝试使用它，因为它的生命周期很长，所以很难冒险。

传统的是SOAP。
REST over HTTP1 还不算是传统的。
为了避免过多跳转，gRPC Gateay 是不错的选择。

HTTP/2是对HTTP1的补充规范，所以是否无缝过渡还是存在疑问的吗？

HTTP连接的连接池，不就是类似于数据库连接池的思路吗？

在HTTP2的基础上，gRPC是一种自定义协议的一个例子。

节俭没有前途…

安全

@nishimunea
让我们学习服务器端的安全性吧
不过服务器端的安全性基本上已经齐全了
不需要研究新的领域。

@kinugawamasato
XSS很有趣

网页开发者似乎没有太多解决浏览器问题的倾向。

W3C 缺乏全面性
各个企业凭借各自擅长的领域汇聚而成

规范性不明确…
应该变得更具有系统性和全面性。

当进行Bug追踪时？
从规格开始
检查安全性的发布说明，可能会发现内存泄漏等问题，但在规格方面很少发现Bug。这是在蓝海中。
通过对浏览器的二进制分析，找到了功能。

HTTP2

@jxck ：你好，能否请你用中文给我解答一下这个问题？

目前HTTP/2的情况

5月份RFC7540被制定，
在此之前大致定案，
主要浏览器已经支持HTTP/2协议，
H2O、Nginx、Apache也都支持，
Java方面，Jetty已经支持。

libcurl已经支持HTTP/2。

通过使用HTTP/2，是否能够创建比1更快的Web，目前还是不确定的未来。

HTTP/2会变得更快吗？

延迟的情况

从HTTP1变为HTTP/2后，同时连接数从6增加到了100。

但仅仅这样就能加快速度吗？

以往我们是按顺序下载的。
在HTTP/2中，HTML、图像和CSS都会一起下载。

有时候需要花费一些时间才能完成渲染。

这个优先级的规范是存在的，但是由于客户端（浏览器）没有正确发送请求，所以速度不会加快。
就像Firefox一样。
优先级的规范是可选的。

由于HTTP/2依赖于单个TCP连接，所以如果TCP出现问题，所有内容都会变得非常缓慢且破坏性。

优先级是实验性实现。

我该怎么办？

在H2O中，我们根据请求的内容提前确定要发送的东西。
内容的优先级应该由制作方而不是客户端知道。

Safari可能会变得相对较快。

请求拦截（大型资源、异步请求）的测量非常重要。

优先级：在H2O的下一个版本中，由于MIME-TYPE不足以满足需求，我们将通过查询参数来实现。如果不正确使用此功能，性能将无法提升。

在发送和不能发送的情况下，应该会有优先级。
能否在这时控制是很重要的。
如果可以像Google那样监控并动态处理套接字缓冲区就好了，但是因为做不到这一点，所以优先级有些微妙。

关于服务器推送

HTTP2比起HTTP1更出色之處→ 不易受到延遲的影響

可以使用吗？
有时会变得更快。
戏剧性地起作用的情况是飞机上的通信。
一般的Wi-Fi没有那么大。
可以用来减少1RTT的物品。

缓存控制很困难
没有比较客户端和服务器持有状态的方法
这可能是不必要的争议

将来可能需要双向请求，但作为加速方法可能不会被使用。

服务器启动程序可能会使用它。

在H2O的最新版本中，具备让客户端在Cookie中保存缓存状态并使服务器推送的功能。

除了速度之外，还有其他的价值吗？

还有其他需要谈论的事情吗？

双向性
一旦连接上了，就平等。
→ 这会有什么变化吗？
P2P扩展。
使服务器能够通过GET与客户端进行通信。
但由于会改变当前的语义，所以并不会立即发生什么变化。
作为通用协议的HTTP/2

下一次对HTTP的修订更加容易了。
在HTTP1之前几乎没有扩展的余地。

虽然只能通过HTTPS使用HTTP/2，但从安全的角度来看，这是一个很好的安全网络。

HTTP/2基本上会变得更快！通过浏览器和服务器的支持，它最终会变快。
服务器的负载将减少。
在以TLS为前提的时代，通信负荷会增加，因此这个好处更加显著。

谷歌也通过整合会话以提高效益并获得剩余价值。

HTTP/2是超文本传输协议的一种吗？

HTTP/2 不使用是否会致命？嗯，那倒不是那么严重。

如果说存在导入的障碍，那就只是提升所需的劳力或其他相关方面。

减少服务器数量

只要能快一秒，销售额就会提高几个百分点，这是值得的。

值不值得去验证一下呢

如果使用HTTP/2，则不再需要分片和合并，但最好有一个可以动态切换的框架。还存在内容优化的问题。

如果是移动优先的网站，只要针对iOS9和iOS10进行切换，应该可以将其变成仅支持HTTP/2的网站。

HTTP/2缺少什么？

HTTP3仍在专注于TLS1.3上，由于TLS1.3无法满足需求而出现的问题。

该协议本身是双向交互的规范。
为了与现有的HTTP相匹配，被强制施加了服务器和客户端的限制。
它将成为完全的P2P。

请求-响应模型是个问题
我们希望能够实现双向交流
将来会越来越多出现

WebSocket在HTTP/2中无法使用。

QUIC 是什么？

谷歌正在开发的基于UDP的功能
为什么选择UDP？
为了解决TCP的问题。
为了消除由数据包丢失导致的瓶颈问题。
0RTT是无法在HTTP/2中突破的障碍。

将HTTP/2进一步提升

如果TCP等进行标准化，变化需要很长时间。
所以，让我们自己用UDP来做吧，这就是流程。

如果有TLS1.3的库，实现HTTP/2协议大约需要一个星期左右，而QUIC协议可能需要数倍的时间。

微软开发了QUIC的实现。
游戏开发者们对此有要求。

我應該往哪裡去呢？

为什么发生了如此大的变化呢，这是什么意思呢？

过去的技术债务正在极尽所能地偿还，我们能跟上吗？如果跟不上的话，那可能会变成债务。HTTP1将会继续存在…

因为那里有协议，所以想要见识高度。
所以要进行实施。

从一开始网页就不容易，只是黑盒子的内容被揭示出来而已。

监控

@songmu
@mikeda
@rrreeeyyy
@fujiwara

为什么要进行监视？

为了找到遇到困境时会感到不便的事物
为了应对未来做好准备
容量规划

为了优化系统而存在的东西。

优化基础设施成本

每隔多久获取一次

用1分钟完成，找不到任何质量下降的痕迹，虽然只是几秒钟。

由于人类能够感知的最小单位只有1秒，所以想要抓住这个机会。
但是这样做会导致死亡，所以目前不能实现。

监视是一个困难的问题

真实的。

只有在操作中，才能明白在中间件上应该监视什么。
有太多的取值，或者不需要查看，或者缺少必要的内容。
很难概括。
并且它将成为一个秘密酱。

尽量避免安装太多新的中间件。

时间序列数据库

Datadog正在使用Cassandra
Datadog正在使用Kafka

关于Fluentd的讨论

Fluentd的影响非常大，我认为它带来了几乎实时的日志处理。