网络知识

1. http1.0/http1.1/http2.0之间有什么区别？

HTTP1.0和HTTP1.1的一些区别

1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

 

HTTPS与HTTP的一些区别

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

 

HTTP2.0和HTTP1.X相比的新特性

• 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
• 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
• header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
• 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

2、项目中采用了哪些容灾措施？

容灾分为两大类：

• • 数据级容灾

异地容灾系统有本地数据的一个副本，数据可以是本地生产数据的实时复制，也可以比本地数据稍微落后。如配置mysql数据库主从热备份。

 

• • 应用级容灾

在数据级容灾基础上，在异地建立一套与本地生产系统相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当本地系统发生灾难时，异地系统可以提供完全可用的生产环境。

 

比较流行的集中容灾解决方案有：

一对一备灾

两地三中心

多对一统一备灾

现代备灾方式

参考：https://wenku.baidu.com/view/40b46c7b7f1922791788e854.html

 

3、多机房、异地机房部署问题

异地双活（多机房部署）

 

异地多活的好处包括异地灾备、提升（南方电信）用户访问速度、提升海外用户访问速度、降低部署成本（如：北京机房机架费太贵了）等。通过实践发现优势包括异地容灾、动态加速、流量均衡、在线压测等，而挑战包括增加研发复杂度、存储成本增加等。

异地多活面临的挑战

机房之间的延时：微博北京的两个核心机房间延时在1ms左右，但北京机房到广州机房则有近40ms的延时。对比一下，微博核心Feed接口的总平均耗时也就在120ms左右。微博Feed会依赖几十个服务上百个资源，如果都跨机房请求，性能将会惨不忍睹；

专线问题：为了做广州机房外部，微博租了两条北京到广州的专线，成本巨大。同时单条专线的稳定性也很难保障，基本上每个月都会有或大或小的问题；

数据同步问题：MySQL如何做数据同步？HBase如何做数据同步？还有各种自研的组件，这些统统要做多机房数据同步。几十毫秒的延时，加上路途遥远导致的较弱网络质量（我们的专线每个月都会有或大或小的问题），数据同步是非常大的挑战；

依赖服务部署问题：如同阿里目前只做了交易单元的“异地双活”，微博部署时也面临核心服务过多依赖小服务的问题。将小服务全部部署改造成本、维护成本过大，不部署则会遇到之前提到的机房之间延时导致整体性能无法接受的问题；

配套体系问题：只是服务部署没有流量引入就不能称为“双活”，而要引入流量就要求配套的服务和流程都能支持异地部署，包括预览、发布、测试、监控、降级等都要进行相应改造；

方案选型时需要考虑的一些维度：

能否整业务迁移：如果机器资源不足，建议优先将一些体系独立的服务整体迁移，这样可以为核心服务节省出大量的机架资源。如果这样之后，机架资源仍然不足，再做异地多活部署；

服务关联是否复杂：如果服务关联比较简单，则单元化、基于跨机房消息同步的解决方案都可以采用。不管哪种方式，关联的服务也都要做异地多活部署，以确保各个机房对关联业务的请求都落在本机房内；

是否方便对用户分区：比如很多游戏类、邮箱类服务由于用户可以很方便分区就非常适合单元化，而SNS类的产品因为关系公用等问题不太适合单元化；

谨慎挑选第二机房：尽量挑选离主机房较近（网络延时在10ms以内）且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉，可以集中精力处理核心业务的异地双活问题。同时，专线的成本占比也比较小。以北京为例，做异地多活建议选择天津、内蒙古、山西等地的机房；

控制部署规模：在数据层自身支持跨机房服务之前，不建议部署超过两个的机房。因为异地两个机房，异地容灾的目的已经达成，且服务器规模足够大各种配套的设施也会比较健全，运维成本也相对可控。当扩展到三个点之后，新机房基础设施磨合、运维决策的成本等都会大幅增加；

消息同步服务化：建议扩展各自的消息服务，从中间件或者服务层面直接支持跨机房消息同步，将消息体大小控制在10k以下，跨机房消息同步的性能和成本都比较可控。机房间的数据一致性只通过消息同步服务解决，机房内部解决缓存等与消息的一致性问题。跨机房消息同步的核心点在于消息不能丢，微博由于使用的是MCQ，通过本地写远程读的方式，可以很方便的实现高效稳定的跨机房消息同步；

4、怎么解决网络连接中的timewait问题？

Timewait的作用：

1.我们都知道的是time_wait太短或者取消，可能会使上一个连接延迟的数据包（关闭连接，但是没有关闭完全），所以延迟的数据包可能被新的连接收到，从而影响到新连接的数据。

2.第二个作用是采用正常的time_wait机制会防止最后一个对FIN的ACK丢失

 

TIME_WAIT存在的两个理由：

1 可靠的实现TCP全双工连接的终止

2 允许老的重复的分节在网络上的消逝

 

解决服务器连接状态TIME_WAIT过多问题：

1、开启apache的keepalive选项

2、有关内核级别的keepalive和time_await的优化调整

其它解决方法

1）可以改为长连接，但代价较大，长连接太多会导致服务器性能问题，而且PHP等脚本语言，需要通过proxy之类的软件才能实现长连接；

2）修改ipv4.ip_local_port_range，增大可用端口范围，但只能缓解问题，不能根本解决问题；

3）客户端程序中设置socket的SO_LINGER选项；

4）客户端机器打开tcp_tw_recycle和tcp_timestamps选项；

5）客户端机器打开tcp_tw_reuse和tcp_timestamps选项；

6）客户端机器设置tcp_max_tw_buckets为一个很小的值；