找到
5
篇与
计算机网络
相关的结果
-
Google、Facebook等均开始支持的HTTP3到底是个什么鬼？ 最近一段时间以来，关于HTTP/3的新闻有很多，越来越多的国际大公司已经开始使用HTTP/3了。   所以，HTTP/3已经是箭在弦上了，全面使用只是个时间问题，那么，作为一线开发者，我们也是时候了解下到底什么是HTTP/3，为什么需要HTTP/3了。 那么，本文就来讲解一下到底什么是HTTP/3？他用到了哪些技术？解决了什么问题？ HTTP/2 存在的问题 在撰写本文之前，我专门写了一篇文章《HTTP/2做错了什么？刚刚辉煌2年就要被弃用了！？》分析HTTP/2存在的问题以及背后的原因。 这里就不详细介绍了，强烈建议大家先阅读下这篇文章，有助于本文的学习。 在上一篇文章中我们提到过HTTP/2因为底层使用的传输层协议仍然是TCP，所以他存在着TCP队头阻塞、TCP握手延时长以及协议僵化等问题。 这导致HTTP/2虽然使用了多路复用、二进制分帧等技术，但是仍然存在着优化空间。 QUIC协议 我们知道，HTTP/2之所以”被弃用”，是因为他使用的传输层协议仍然是TCP，所以HTTP/3首要解决的问题就是绕开TCP。 那么如果研发一种新的协议，同样还是会因为受到中间设备僵化的影响，导致无法被大规模应用。所以，研发人员们想到了一种基于UDP实现的方式。 于是，Google是最先采用这种方式并付诸于实践的，他们在2013年推出了一种叫做QUIC的协议，全称是Quick UDP Internet Connections。 从名字中可以看出来，这是一种完全基于UDP的协议。 在设计之初，Google就希望使用这个协议来取代HTTPS/HTTP协议，使网页传输速度加快。2015年6月，QUIC的网络草案被正式提交至互联网工程任务组。2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（英语：HTTP over QUIC）重命名为HTTP/3。 所以，我们现在所提到的HTTP/3，其实就是HTTP over QUIC，即基于QUIC协议实现的HTTP。 那么，想要了解HTTP/3的原理，只需要了解QUIC就可以了。 QUIC协议有以下特点： 基于UDP的传输层协议：它使用UDP端口号来识别指定机器上的特定服务器。 可靠性：虽然UDP是不可靠传输协议，但是QUIC在UDP的基础上做了些改造，使得他提供了和TCP类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些TCP中存在的特性。 实现了无序、并发字节流：QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序，这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！ 快速握手：QUIC提供0-RTT和1-RTT的连接建立 使用TLS 1.3传输层安全协议：与更早的TLS版本相比，TLS 1.3有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更低，从而能降低协议的延迟。 那么，QUIC到底属于TCP/IP协议族中的那一层呢？我们知道，QUIC是基于UDP实现的，并且是HTTP/3的所依赖的协议，那么，按照TCP/IP的分层来讲，他是属于传输层的，也就是和TCP、UDP属于同一层。 如果更加细化一点的话，因为QUIC不仅仅承担了传输层协议的职责，还具备了TLS的安全性相关能力，所以，可以通过下图来理解QUIC在HTTP/3的实现中所处的位置。  接下来我们分别展开分析一下QUIC协议。先来看下他是如何建立连接的。 QUIC的连接建立 我们知道，TCP这种可靠传输协议需要进行三次握手，也正是因为三次握手，所以需要额外消耗1.5 RTT，而如果再加上TLS的话，则需要消耗3-4个 RTT连接。 那么，QUIC是如何建立连接的呢？如何减少RTT的呢？ QUIC提出一种新的连接建立机制，基于这种连接接机制，实现了快速握手功能，一次QUIC连接建立可以实现使用 0-RTT 或者 1-RTT 来建立连接。  QUIC在握手过程中使用Diffie-Hellman算法来保证数据交互的安全性并合并了它的加密和握手过程来减小连接建立过程中的往返次数。 Diffie–Hellman (以下简称DH)密钥交换是一个特殊的交换密钥的方法。它是密码学领域内最早付诸实践的密钥交换方法之一。 DH可以让双方在完全缺乏对方(私有)信息的前提条件下通过不安全的信道达成一个共享的密钥。此密钥用于对后续信息交换进行对称加密。 QUIC 连接的建立整体流程大致为：QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。客户端和服务器会使用新生的的密钥进行数据加解密。 以上过程主要分为两个步骤：初始握手（Initial handshake）、最终（与重复）握手（Final (and repeat) handshake），分别介绍下这两个过程。 初始握手（Initial handshake） 在连接开始建立时，客户端会向服务端发送一个打招呼信息，（inchoate client hello (CHLO)），因为是初次建立，所以，服务端会返回一个拒绝消息（REJ），表明握手未建立或者密钥已过期。  但是，这个拒绝消息中还会包含更多的信息（配置参数），主要有： Server Config：一个服务器配置，包括服务器端的Diffie-Hellman算法的长期公钥（long term Diffie-Hellman public value） Certificate Chain：用来对服务器进行认证的信任链 Signature of the Server Config：将Server Config使用信任链的叶子证书的public key加密后的签名 Source-Address Token：一个经过身份验证的加密块，包含客户端公开可见的IP地址和服务器的时间戳。 在客户端接收到拒绝消息（REJ）之后，客户端会进行数据解析，签名验证等操作，之后会将必要的配置缓存下来。 同时，在接收到REJ之后，客户端会为这次连接随机产生一对自己的短期密钥（ephemeral Diffie-Hellman private value） 和 短期公钥（ephemeral Diffie-Hellman public value）。 之后，客户端会将自己刚刚产生的短期公钥打包一个Complete CHLO的消息包中，发送给服务端。这个请求的目的是将自己的短期密钥传输给服务端，方便做前向保密，后面篇幅会详细介绍。  在发送了Complete CHLO消息给到服务器之后，为了减少RTT，客户端并不会等到服务器的响应，而是立刻会进行数据传输。 为了保证数据的安全性，客户端会自己的短期密钥和服务器返回的长期公钥进行运算，得到一个初始密钥（initial keys）。 有了这个初识密钥之后，客户端就可以用这个密钥，将想要传输的信息进行加密，然后把他们安全的传输给服务端了。  另外一面，接收到Complete CHLO请求的服务器，解析请求之后，就同时拥有了客户端的短期公钥和自己保存的长期密钥。这样通过运算，服务端就能得到一份和客户端一模一样的初始密钥（initial keys）。 接下来他接收到客户端使用初始密钥加密的数据之后，就可以使用这个初识密钥进行解密了，并且可以将自己的响应再通过这个初始密钥进行加密后返回给客户端。 所以，从开始建立连接一直到数据传送，只消耗了初始连接连接建立的 1 RTT 最终（与重复）握手 那么，之后的数据传输就可以使用初始密钥（initial keys）加密了吗？ 其实并不完全是，因为初始密钥毕竟是基于服务器的长期公钥产生的，而在公钥失效前，几乎多有的连接使用的都是同一把公钥，所以，这其实存在着一定的危险性。 所以，为了达到前向保密 (Forward Secrecy) 的安全性，客户端和服务端需要使用彼此的短期公钥和自己的短期密钥来进行运算。 在密码学中，前向保密（英语：Forward Secrecy，FS）是密码学中通讯协议的安全属性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。 那么现在问题是，客户端的短期密钥已经发送给服务端，而服务端只把自己的长期公钥给了客户端，并没有给到自己的短期密钥。 所以，服务端在收到Complete CHLO之后，会给到服务器一个server hello(SHLO)消息，这个消息会使用初始密钥（initial keys）进行加密。  这个CHLO消息包中，会包含一个服务端重新生成的短期公钥。 这样客户端和服务端就都有了对方的短期公钥（ephemeral Diffie-Hellman public value）。 这样，客户端和服务端都可以基于自己的短期密钥和对方的短期公钥做运算，产生一个仅限于本次连接使用的前向保密密钥 (Forward-Secure Key)，后续的请求发送，都基于这个密钥进行加解密就可以了。 这样，双方就完成了最终的密钥交换、连接的握手并且建立了QUIC连接。 当下一次要重新创建连接的时候，客户端会从缓存中取出自己之前缓存下来的服务器的长期公钥，并重新创建一个短期密钥，重新生成一个初识密钥，再使用这个初始密钥对想要传输的数据进行加密，向服务器发送一个Complete CHLO 请求即可。这样就达到了0 RTT的数据传输。  所以，如果是有缓存的长期公钥，那么数据传输就会直接进行，准备时间是0 RTT 以上，通过使用Diffie-Hellman算法协商密钥，并且对加密和握手过程进行合并，大大减小连接过程的RTT ，使得基于QUIC的连接建立可以少到1 RTT甚至0 RTT。 以下，是Google官网上面的一张关于QUIC连接建立的流程图，可以帮助大家理解这个过程。  另外，通过以上关于握手建立的过程，我们也可以知道，QUIC在整个过程中通过加解密的方式很好的保证了安全性。 多路复用 基于TCP的协议实现的HTTP有一个最大的问题那就是队头阻塞问题，那么，在这方面，QUIC是如何解决这个问题的呢？ TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。  但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。  类似于HTTP/2，QUIC在同一物理连接上可以有多个独立的逻辑数据流，这些数据流并行在同一个连接上传输，且多个数据流之间间的传输没有时序性要求，也不会互相影响。 数据流（Streams）在QUIC中提供了一个轻量级、有序的字节流的抽象化 QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序。这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！ 也就是说同一个连接上面的多个数据流之间没有任何依赖（不要求按照顺序到达），即使某一个数据包没有达到，也只会影响自己这个数据流，并不会影响到到其他的数据流。  连接迁移 对于TCP连接的识别，需要通过服务器和客户端过双方的ip和端口四个参数进行的。在网络切换的场景中，比如手机切换网络，那么自身的ip就会发生变化。这就导致之前的TCP连接就会失效，就需要重新建立。 这种场景对于移动端设备普及的今天来说，还是比较频繁的。 所以，在这一点上，QUIC进行了优化。 QUIC协议使用特有的UUID来标记每一次连接，在网络环境发生变化的时候，只要UUID不变，就能不需要握手，继续传输数据。 可靠性 TCP之所以被称之为可靠链接，不仅仅是因为他有三次握手和四次关闭的过程，还因为他做了很多诸如流量控制、数据重传、拥塞控制等可靠性保证。 这也是为什么一直以来都是以TCP作为HTTP实现的重要协议的原因。 那么，QUIC想要取代TCP，就需要在这方面也做出努力，毕竟UDP自身是不具备这些能力的。 TCP拥塞控制是TCP避免网络拥塞的算法，是互联网上主要的一个拥塞控制措施。经典的算法实现有很多，诸如TCP Tahoe 和 Reno、TCP Vegas、TCP Hybla、TCP New Reno、TCP Westwood和Westwood+以及TCP BIC 和 CUBIC等等。 QUIC协议同样实现了拥塞控制。不依赖于特定的拥塞控制算法，并且提供了一个可插拔的接口，允许用户实验。默认使用了 TCP 协议的 Cubic 拥塞控制算法。 关于流量控制，QUIC提供了基于stream和connection两种级别的流量控制，既需要对单个 Stream 进行控制，又需要针对所有 Stream 进行总体控制。 QUIC的连接级流控，用以限制 QUIC 接收端愿意分配给连接的总缓冲区，避免服务器为某个客户端分配任意大的缓存。连接级流控与流级流控的过程基本相同，但转发数据和接收数据的偏移限制是所有流中的总和。 弊端 以上，我们介绍了很多QUIC的相比较于TCP的优点，可以说这种协议相比较于TCP确实要优秀一些。 因为他是基于UDP的，并没有改变UDP协议本身，只是做了一些增强，虽然可以避开中间设备僵化的问题，但是，在推广上面也不是完全没有问题的。 首先，很多企业、运营商和组织对53端口（DNS）以外的UDP流量会进行拦截或者限流，因为这些流量近来常被滥用于攻击。 特别是一些现有的UDP协议和实现易受放大攻击（amplification attack）威胁，攻击者可以控制无辜的主机向受害者投放发送大量的流量。 所以，基于UDP的QUIC协议的传输可能会受到屏蔽。 另外，因为UDP一直以来定位都是不可靠连接，所以有很多中间设备对于他的支持和优化程度并不高，所以，出现丢包的可能性还是比较搞的。 总结 下表是我总结的HTTP/2和HTTP/3的异同点，有一些本文介绍过，有一些个人认为并不是特别重要的，本文中并没有提及，大家感兴趣的可以自行学习下。 特性 HTTP/2 HTTP/3 传输层协议 TCP 基于UDP的QUIC 默认加密 否 是 独立的数据流 否 是 队头阻塞 存在TCP队头阻塞 无 报头压缩 HPACK QPACK 握手时延 TCP+TLS 的 1-3 RTT 0-1 RTT 连接迁移 无 有 服务器推送 有 有 多路复用 有 有 流量控制 有 有 数据重传 有 有 拥塞控制 有 有 参考资料： https://http3-explained.haxx.se/ The QUIC Transport Protocol: Design and Internet-Scale Deployment https://www.codenong.com/cs106840038/ https://nan01ab.github.io/2018/12/QUIC.html https://medium.com/@chester.yw.chu/http-3-傳輸協議-quic-簡介-5f8806d6c8cd
-
Java 9 和Spring Boot 2.0纷纷宣布支持的HTTP/2到底是什么？ 关于HTTP/2，最近你可能没少听到过他，首先，如果你了解过Java 9的特性，那么你会发现在Java9中，提供了新的方式来处理HTTP调用，提供了新的HTTP Client，将替代HttpURLConnection，并提供对WebSocket和HTTP/2的支持。还有前两天刚刚发布的Spring Boot 2.0 的新特性中，也会看到，Spring Boot 2.0支持的Web容器中Tomcat、Undertow和Jetty均已支持HTTP/2。 那么，这篇文章，我们就来了解下，到底什么是HTTP/2。 HTTP 超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。 HTTP 协议是以 ASCII 码传输，基于请求与响应模式的、无状态的，建立在 TCP/IP 协议之上的应用层规范。。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。 HTTP协议主要的版本有3个，分别是HTTP/1.0、HTTP/1.1和HTTP/2。HTTPS是另外一个协议，简单讲是HTTP的安全版。 HTTP/1.0 1996年5月，HTTP/1.0 版本发布，为了提高系统的效率，HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。 请注意上面提到的HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。 我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。现在，随便打开一个网页，上面都会有很多图片、视频等资源，HTTP/1.0显然无法满足性能要求。 HTTP/1.1 为了解决HTTP/1.0存在的缺陷，HTTP/1.1于1999年诞生。相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接。所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。 引入了持久连接之后，在性能方面，HTTP协议有了明显的提升，基本可以用于日常使用，这也是这一版本一直延用至今的原因。当然还是有些力不从心的，后面会详细介绍。 关于HTTP/1.0和HTTP/1.1还有些其他区别，这里就不展开介绍了。网上也很多资料，可以自行查阅。 SPDY 虽然，HTTP/1.1在HTTP/1.0的基础上提供了持久连接，提升了很大的效率，但是，还是有很大的提升空间。 正所谓时势造英雄，正是因为HTTP存在着诸多不足，所以，才诞生了SPDY。2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。它的设计目标是降低 50% 的页面加载时间。SPDY主要提供了以下功能（后文介绍HTTP2的时候再详细介绍）： 多路复用（multiplexing）。多个请求共享一个tcp连接。 header压缩。删除或者压缩HTTP头 服务端推送。提供服务方发起通信，并向客户端推送数据的机制。 SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议。 实际上在 HTTP2 提出来之前，SPDY 流行了很长一段时间。当下很多著名的互联网公司都在自己的网站或 APP 中采用了 SPDY 系列协议（当前最新版本是 SPDY/3.1），因为它对性能的提升是显而易见的。主流的浏览器（谷歌、火狐、Opera）也都早已经支持 SPDY，它已经成为了工业标准。HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2。 HTTP/2 下图是Akamai 公司建立的一个官方的演示，主要用来说明在性能上HTTP/1.1和HTTP/2在性能升的差别。同时请求 379 张图片，HTTP/1.1加载用时4.54s，HTTP/2加载用时1.47s。 HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表。 下面来看下，HTTP/2相对于HTTP/1.1有哪些改进： 二进制分帧 在HTTP/2中，在应用层（HTTP2.0）和传输层（TCP或者UDP）之间加了一层：二进制分帧层。这是HTTP2中最大的改变。HTTP2之所以性能会比HTTP1.1有那么大的提高，很大程度上正是由于这一层的引入。 在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。 这种单连接多资源的方式，减少了服务端的压力，使得内存占用更少，连接吞吐量更大。而且，TCP连接数的减少使得网络拥塞状况得以改善，同时慢启动时间的减少，使拥塞和丢包恢复速度更快。 多路复用 多路复用允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。在HTTP1.1协议中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制，超过了这个限制的请求就会被阻塞。而多路复用允许同时通过单一的 HTTP2.0 连接发起多重的“请求-响应”消息。 HTTP2的请求的TCP的connection一旦建立，后续请求以stream的方式发送。每个stream的基本组成单位是frame（二进制帧）。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。 也就是说， HTTP2.0 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。就好比，我请求一个页面 http://www.hollischuang.com 。页面上所有的资源请求都是客户端与服务器上的一条 TCP 上请求和响应的！ header压缩 HTTP/1.1的header带有大量信息，而且每次都要重复发送。HTTP/2 为了减少这部分开销，采用了HPACK 头部压缩算法对Header进行压缩。 服务端推送 简单来讲就是当用户的浏览器和服务器在建立连接后，服务器主动将一些资源推送给浏览器并缓存起来的机制。有了缓存，当浏览器想要访问已缓存的资源的时候就可以直接从缓存中读取了。 参考资料 HTTP2.0 的总结 HTTP 1.0/1.1/2.0、HTTPS HTTP2.0,SPDY,HTTPS你应该知道的一些事 HTTP2.0关于多路复用的研究
-
常见的网站攻击手段及预防措施。 XSS XSS攻击的全称是跨站脚本攻击(Cross Site Scripting),为了不和层叠样式表 (Cascading Style Sheets,CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS,是WEB应用程序中最常见到的攻击手段之一。跨站脚本攻击指的是攻击者在网页中嵌入恶意脚本程序, 当用户打开该网页时,脚本程序便开始在客户端的浏览器上执行,以盗取客户端cookie、 盗取用户名密码、下载执行病毒木马程序等等。 有一种场景,用户在表单上输入一段数据后,提交给服务端进行持久化,其他页面上需要从服务端将数据取出来展示。还是使用之前那个表单nick,用户输入昵称之后,服务端会将nick保存,并在新的页面展现给用户,当普通用户正常输入hollis,页面会显示用户的 nick为hollis: hollis 但是,如果用户输入的不是一段正常的nick字符串,而是alert("haha"), 服务端会将这段脚本保存起来,当有用户查看该页面时,页面会出现如下代码: alert("haha") XSS该如何防御 XSS之所以会发生,是因为用户输入的数据变成了代码。因此,我们需要对用户输入的数据进行HTML转义处理,将其中的“尖括号”、“单引号”、“引号” 之类的特殊字符进行转义编码。 如今很多开源的开发框架本身默认就提供HTML代码转义的功能,如流行的jstl、Struts等等,不需要开发人员再进行过多的开发。使用jstl标签进行HTML转义,将变量输出,代码 如下: 只需要将escapeXml设置为true, jstl就会将变量中的HTML代码进行转义输出。 CSRF CSRF攻击的全称是跨站请求伪造(cross site request forgery), 是一种对网站的恶意利用,尽管听起来跟XSS跨站脚本攻击有点相似,但事实上CSRF与XSS差别很大,XSS利用的是站点内的信任用户,而CSRF则是通过伪装来自受信任用户的请求来利用受信任的网站。你可以这么理解CSRF攻击:攻击者盗用了你的身份,以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件、发短信、进行交易转账等等,甚至盗取你的账号。 假设某银行网站A,他以GET请求来发起转账操作,转账的地址为www.xxx.com/transfer.do?accountNum=10001&money=10000,accountNum参数表示转账的目的账户,money参数表示转账金额。 而某大型论坛B上,一个恶意用户上传了一张图片,而图片的地址栏中填的并不是图片的地址,而是前面所说的转账地址: 当你登陆网站A后,没有及时登出,这个时候你访问了论坛B,不幸的事情发生了,你会发现你的账户里面少了10000块…… 为什么会这样呢,在你登陆银行A的时候,你的浏览器端会生成银行A的cookie,而当你访问论坛B的时候,页面上的标签需要浏览器发起一个新的HTTP请求,以获得图片资源, 当浏览器发起请求的时候,请求的却是银行A的转账地址www.xxx.com/transfer.do?accoun tNum=10001&money=10000,并且会带上银行A的cookie信息,结果银行的服务器收到这个请求后,会认为是你发起的一次转账操作,因此你的账户里边便少了10000块。 CSRF的防御 cookie设置为HttpOnly CSRF攻击很大程度上是利用了浏览器的cookie,为了防止站内的XSS漏洞盗取cookie,需要在cookie中设置”HttpOnly”属性,这样通过程序(如JavascriptS脚本、Applet等)就无法读取到cookie信息,避免了攻击者伪造cookie的情况出现。 增加token CSRF攻击之所以能够成功,是因为攻击者可以伪造用户的请求,该请求中所有的用户验证信息都存在于cookie中,因此攻击者可以在不知道用户验证信息的情况下直接利用用户的cookie来通过安全验证。由此可知,抵御CSRF攻击的关键在于:在请求中放入攻击者所不能伪造的信息,并且该信息不存在于cookie之中。鉴于此,系统开发人员可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端进行token校验,如果请求中没有token或者token内容不正确,则认为是CSRF攻击而拒绝该请求。 通过Referer识别 根据HTTP协议,在HTTP头中有一个字段叫Referer,它记录了该HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求都来自于同一个网站。比如某银行的转账是通过用户访问http://www.xxx.com/transfer.do页面完成,用户必须先登录www.xxx.com,然后通过点击页面上的提交按钮来触发转账事件。当用户提交请求时,该转账请求的Referer值就会是提交按钮所在页面的URL(本例为www.xxx.com/transfer.do)。如果攻击者要对银行网站实施CSRF攻击,他只能在其他的网站构造请求,当用户通过其他网站发送请求到银行时,该请求的Referer的值是其他网站的地址,而不是银行转账页面的地址。因此,要防御CSRF攻击,银行网站只需要对于每一个转账请求验证其Referer值,如果是以www.xxx.com域名开头的地址,则说明该请求是来自银行网站自己的请求,是合法的。如果 Referer是其他网站的话,就有可能是CSRF攻击,则拒绝该请求。 SQL注入攻击 所谓SQL注入,就是通过把SQL命令伪装成正常的HTTP请求参数,传递到服务端,欺骗服务器最终执行恶意的SQL命令,达到入侵目的。攻击者可以利用SQL注入漏洞,查询非授权信息, 修改数据库服务器的数据,改变表结构,甚至是获取服务器root权限。总而言之,SQL注入漏洞的危害极大,攻击者采用的SQL指令,决定攻击的威力。当前涉及到大批量数据泄露的攻击事件,大部分都是通过利用SQL注入来实施的。 假设有个网站的登录页面,如下所示: 假设用户输入nick为zhangsan,密码为password1,则验证通过,显示用户登录: 否则,显示用户没有登录: SQL注入攻击原理 Connection conn = getConnection(); String sql = "select * from hhuser where nick = '" + nickname + "'" + " and passwords = '" + password + "'"; Statement st = (Statement) conn.createStatement(); ResultSet rs = st.executeQuery(sql); List userInfoList = new ArrayList(); while (rs.next()) { UserInfo userinfo = new UserInfo(); userinfo.setUserid(rs.getLong("userid")); userinfo.setPasswords(rs.getString("passwords")); userinfo.setNick(rs.getString("nick")); userinfo.setAge(rs.getInt("age")); userinfo.setAddress(rs.getString("address")); userInfoList.add(userinfo); } 当用户输入nick为zhangsan,密码为' or '1'='1的时候,意想不到的事情出现了,页面显示为login状态: 以上便是一次简单的、典型的SQL注入攻击。当然,SQL注入的危害不仅 如此,假设用户输入用户名zhangsan,在密码框输入' ;drop table aaa;-- 会发生什么呢? SQL注入攻击防御 使用预编译语句 预编译语句PreparedStatement是java.sql中的一个接口,继承自Statement接口。通过 Statement对象执行SQL语句时,需要将SQL语句发送给DBMS,由DBMS先进行编译后再执行。而预编译语句和Statement不同,在创建PreparedStatement对象时就指定了SQL语句,该语句立即发送给DBMS进行编译,当该编译语句需要被执行时,DBMS直接运行编译后的SQL语句,而不需要像其他SQL语句那样首先将其编译。 前面介绍过,引发SQL注入的根本原因是恶意用户将SQL指令伪装成参数传递到后端数据库执行, 作为一种更为安全的动态字符串的构建方法,预编译语句使用参数占位符来替代需要动态传入的参数,这样攻击者无法改变SQL语句的结构,SQL语句的语义不会发生改变,即便用户传入类似于前面' or '1'='1这样的字符串,数据库也会将其作为普通的字符串来处理。 使用ORM框架 由上文可见,防止SQL注入的关键在于对一些关键字符进行转义,而常见的一些ORM框架,如 ibatis、hibernate等,都支持对相应的关键字或者特殊符号进行转义,可以通过简单的配置, 很好的预防SQL注入漏洞,降低了普通的开发人员进行安全编程的门槛。 Ibatis的insert语句配置: insert into users(gmt_create,gmt_modified,userid,user_nick,address,age,sex) values(now(),now(),#userId#,#userNick#,#address#,#age#,#sex#) 通过#符号配置的变量,ibatis能够对输入变量的一些关键字进行转义,防止SQL注入攻击。 避免密码明文存放 对存储的密码进行单向Hash,如使用MD5对密码进行摘要,而非直接存储明文密码,这样的好处就是万一用户信息泄露,即圈内所说的被“拖库”,黑客无法直接获取用户密码,而只能得到一串跟密码相差十万八千里的Hash码。 处理好相应的异常 后台的系统异常,很可能包含了一些如服务器版本、数据库版本、编程语言等等的信息,甚至是数据库连接的地址及用户名密码,攻击者可以按图索骥,找到对应版本的服务器漏洞或者数据库漏洞进行攻击,因此,必须要处理好后台的系统异常,重定向到相应的错误处理页面,而 不是任由其直接输出到页面上。 文件上传漏洞 在上网的过程中,我们经常会将一些如图片、压缩包之类的文件上传到远端服务器进行保存, 文件上传攻击指的是恶意攻击者利用一些站点没有对文件的类型做很好的校验这样的漏洞, 上传了可执行的文件或者脚本,并且通过脚本获得服务器上相应的权利,或者是通过诱导外 部用户访问或者下载上传的病毒或者木马文件,达到攻击目的。 为了防范用户上传恶意的可执行文件和脚本,以及将文件上传服务器当做免费的文件存储服务器使用,需要对上传的文件类型进行白名单(非黑名单,这点非常重要)校验,并且限制上传文件的大小,上传的文件,需要进行重新命名,使攻击者无法猜测到上传文件的访问路径。 对于上传的文件来说,不能简单的通过后缀名称来判断文件的类型,因为恶意攻击可以将可执行文件的后缀名称改成图片或者其他的后缀类型,诱导用户执行。因此,判断文件类型需要使用更安全的方式。很多类型的文件,起始的几个字节内容是固定的,因此,根据这几个字节的内容,就可以确定文件类型,这几个字节也被称为魔数(magic number)。 DDoS攻击 DDoS(Distributed Denial of Service),即分布式拒绝服务攻击,是目前最为强大、最难以防御的攻击方式之一。要理解DDos,得先从DoS说起。 最基本的DoS攻击就是利用合理的客户端请求来占用过多的服务器资源,从而使合法用户无法得到服务器的响应。DDoS攻击手段是在传统的DoS攻击基础之上产生的一类攻击方式,传统的DoS攻击一般是采用一对一方式的,当攻击目标CPU速度、内存或者网络带宽等等各项性能指标不高的情况下,它的效果是明显的,但随着计算机与网络技术的发展,计算机的处理能力显著增加,内存不断增大,同时也出现了千兆级别的网络,这使得DoS攻击逐渐失去效果。这时候分布式拒绝服务攻击手段(DDoS)便应运而生了。你理解了DoS攻击以后, DDoS的原理就非常简单了,它指的是攻击者借助公共网络,将数量庞大的计算机设备联合起来作为 攻击平台,对一个或多个目标发动攻击,从而达到瘫痪目标主机的目的。通常,在攻击开始前,攻击者会提前控制大量的用户计算机,称之为“肉鸡”,并通过指令使大量的肉鸡在同一时刻对某个主机进行访问,从而达到瘫痪目标主机的目的。 DDoS的攻击有很多种类型,如依赖蛮力的ICMP Flood、UDP Flood等等,随着硬件性能的 提升,需要的机器规模越来越大,组织大规模的攻击越来越困难,现在已经不常见,还有就是依赖协议特征以及具体的软件漏洞进行的攻击,如Slowloris攻击,Hash碰撞攻击等等,这类攻击主要利用协议以及软件漏洞发起攻击,需要在特定环境下才会出现,更多的攻击者采用的是前面两种的混合方式,即利用了协议、系统的缺陷,又具备了海量的流量, 如SYN Flood、DNS Query Flood等等。 DNS Query Flood DNS Query Flood实际上是UDP Flood攻击的一种变形,由于DNS服务在互联网中不可替代的作用,一旦DNS服务器瘫痪,影响甚大。 DNS Query Flood攻击采用的方法是向被攻击的服务器发送海量的域名解析请求,通常,请求解析的域名是随机生成,大部分根本就不存在,并且通过伪造端口和客户端IP,防止查询请求被ACL过滤。被攻击的DNS服务器在接收到域名解析请求后,首先会在服务器上查找是否有对应的缓存, 由于域名是随机生成的,几乎不可能有相应的缓存信息,当没有缓存,并且该域名无法直接由该DNS服务器进行解析的时候,DNS服务器会向其上层DNS服务器递归查询域名信息,直到全球互联网的13台根DNS服务器。大量不存在的域名解析请求,给服务器带来了很大的负载,当解析请求超过一定量的时候,就会造成DNS服务器解析域名超时,这样攻击者便达成了攻击目的。 CC攻击 CC(Challenge Collapsar)攻击属于DDos的一种,是基于应用层HTTP协议 发起的DDos攻击,也被称为HTTP Flood。 CC攻击的原理是这样的,攻击者通过控制的大量“肉鸡”或者利用从互联网上搜寻的大量匿名的HTTP代理,模拟正常用户给网站发起请求直到该网站拒绝服务为止。大部分网站会通过CDN以及分布式缓存来加快服务端响应,提升网站的吞吐量,而这些精心构造的HTTP请求往往有意避开这些缓存,需要进行多次DB查询操作或者是一次请求返回大量的数据,加速系统 资源消耗,从而拖垮后端的业务处理系统,甚至连相关存储以及日志收集系统也无法幸免。
-
HTTP/2做错了什么？刚刚辉煌2年就要被弃用了！？ 最近一段时间以来，关于HTTP/3的新闻有很多，越来越多的国际大公司已经开始使用HTTP/3了。 所以，HTTP/3已经是箭在弦上了，全面使用只是个时间问题，那么，作为一线开发者，我们也是时候了解下到底什么是HTTP/3，为什么需要HTTP/3了。 于是，我准备开始写这篇文章，但是要想把HTTP/3的事情说清楚，一定绕不过的问题就是HTTP/2，所以写着写着，篇幅越来越多，于是我就把他们分成了上下两篇。 这一篇我们主要来回顾下HTTP/2，然后再来重点看一下HTTP/2存在哪些问题，为什么要被弃用。 HTTP/2 辉煌不在？ 虽然HTTP/2标准在2015年5月就以RFC 7540正式发表了，并且多数浏览器在2015年底就支持了。 但是，真正被广泛使用起来要到2018年左右，但是也是在2018年，11月IETF给出了官方批准，认可HTTP-over-QUIC成为HTTP/3。 2018年的时候，我写过一篇文章介绍《HTTP/2到底是什么？》，那时候HTTP/2还是个新技术，刚刚开始有软件支持，短短两年过去了，现在HTTP/3已经悄然而至了。 根据W3Techs的数据，截至2019年6月，全球也仅有36.5%的网站支持了HTTP/2。所以，可能很多网站还没开始支持HTTP/2，HTTP/3就已经来了。 所以，对于很多网站来说，或许直接升级HTTP/3是一个更加正确的选择。 回顾 HTTP/2 在阅读本文之前，强烈建议大家先阅读下《HTTP/2到底是什么？》这篇文章，这里面介绍了HTTP的历史，介绍了各个版本的HTTP协议的诞生的背景。 当你读到这里的时候，我默认大家对HTTP/2有了一定的基本了解。 我们知道，HTTP/2的诞生，主要是为了解决HTTP/1.1中的效率问题，HTTP/2中最核心的技术就是多路复用技术，即允许同时通过单一的HTTP/2.0连接发起多重的请求-响应消息。 同时还实现了二进制分帧、header压缩、服务端推送等技术。 从HTTP/1.0诞生，一直到HTTP/2，在这24年里，HTTP协议已经做过了三次升级，但是有一个关键的技术点是不变的，那就是这所有的HTTP协议，都是基于TCP协议实现的。 流水的HTTP，铁打的TCP。这是因为相对于UDP协议，TCP协议更加可靠。 虽然在HTTP/1.1的基础上推出HTTP/2大大的提升了效率，但是还是有很多人认为这只是个”临时方案”，这也是为什么刚刚推出没多久，业内就开始大力投入HTTP/3的研发与推广了。 而这背后的深层次原因也正是因为他还是基于TCP协议实现的。TCP协议虽然更加可靠，但是还是存在着一定的问题，接下来具体分析下。 HTTP/2 问题 队头阻塞 队头阻塞翻译自英文head-of-line blocking，这个词并不新鲜，因为早在HTTP/1.1时代，就一直存在着队头阻塞的问题。 但是很多人在一些资料中会看到有论点说HTTP/2解决了队头阻塞的问题。但是这句话只对了一半。 只能说HTTP/2解决了HTTP的队头阻塞问题，但是并没有解决TCP队头阻塞问题！ 如果大家对于HTTP的历史有一定的了解的话，就会知道。HTTP/1.1相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接（keep-alive）。 所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。 引入了持久连接之后，在性能方面，HTTP协议有了明显的提升。 另外，HTTP/1.1允许在持久连接上使用请求管道，是相对于持久连接的又一性能优化。 所谓请求管道，就是在HTTP响应到达之前，可以将多条请求放入队列，当第一条HTTP请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在高时延网络条件下，这样做可以降低网络的环回时间，提高性能。 但是，对于管道连接还是有一定的限制和要求的，其中一个比较关键的就是服务端必须按照与请求相同的顺序回送HTTP响应。 这也就意味着，如果一个响应返回发生了延迟，那么其后续的响应都会被延迟，直到队头的响应送达。这就是所谓的HTTP队头阻塞。 但是HTTP队头阻塞的问题在HTTP/2中得到了有效的解决。HTTP/2废弃了管道化的方式，而是创新性的引入了帧、消息和数据流等概念。客户端和服务器可以把 HTTP 消息分解为互不依赖的帧，然后乱序发送，最后再在另一端把它们重新组合起来。 因为没有顺序了，所以就不需要阻塞了，就有效的解决了HTTP对队头阻塞的问题。 但是，HTTP/2仍然会存在TCP队头阻塞的问题，那是因为HTTP/2其实还是依赖TCP协议实现的。 TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。 但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。 HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用，但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中，同一个域名只是用一个TCP连接。 所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的，那如果某一个请求造成了TCP队头阻塞，那么多个请求都会受到影响。 TCP握手时长 一提到TCP协议，大家最先想到的一定是他的三次握手与四次关闭的特性。 因为TCP是一种可靠通信协议，而这种可靠就是靠三次握手实现的，通过三次握手，TCP在传输过程中可以保证接收方收到的数据是完整，有序，无差错的。 但是，问题是三次握手是需要消耗时间的，这里插播一个关于网络延迟的概念。 网络延迟又称为 RTT（Round Trip Time）。他是指一个请求从客户端浏览器发送一个请求数据包到服务器，再从服务器得到响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。 我们知道，TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。 另外，如果使用的是安全的HTTPS协议，就还需要使用TLS协议进行安全数据传输，这个过程又要消耗一个RTT（TLS不同版本的握手机制不同，这里按照最小的消耗来算） 那么也就是说，一个纯HTTP/2的连接，需要消耗1.5个RTT，如果是一个HTTPS连接，就需要消耗3-4个RTT。 而具体消耗的时长根据服务器和客户端之间的距离则不尽相同，如果比较近的话，消耗在100ms以内，对于用来说可能没什么感知，但是如果一个RTT的耗时达到300-400ms，那么，一次连接建立过程总耗时可能要达到一秒钟左右，这时候，用户就会明显的感知到网页加载很慢。 升级TCP是否可行？ 基于上面我们提到的这些问题，很多人提出来说：既然TCP存在这些问题，并且我们也知道这些问题的存在，甚至解决方案也不难想到，为什么不能对协议本身做一次升级，解决这些问题呢？ 其实，这就涉及到一个”协议僵化“的问题。 这样讲，我们在互联网上浏览数据的时候，数据的传输过程其实是极其复杂的。 我们知道的，想要在家里使用网络有几个前提，首先我们要通过运行商开通网络，并且需要使用路由器，而路由器就是网络传输过程中的一个中间设备。 中间设备是指插入在数据终端和信号转换设备之间，完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。 在我们看不到的地方，这种中间设备还有很多很多，一个网络需要经过无数个中间设备的转发才能到达终端用户。 如果TCP协议需要升级，那么意味着需要这些中间设备都能支持新的特性，我们知道路由器我们可以重新换一个，但是其他的那些中间设备呢？尤其是那些比较大型的设备呢？更换起来的成本是巨大的。 而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协议需要通过操作系统内核来实现，而操作系统的更新也是非常滞后的。 所以，这种问题就被称之为”中间设备僵化”，也是导致”协议僵化”的重要原因。这也是限制着TCP协议更新的一个重要原因。 所以，近些年来，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用！ 放弃TCP？ 上面提到的这些问题的根本原因都是因为HTTP/2是基于TPC实现导致的，而TCP协议自身的升级又是很难实现的。 那么，剩下的解决办法就只有一条路，那就是放弃TCP协议。 放弃TCP的话，就又有两个新的选择，是使用其他已有的协议，还是重新创造一个协议呢？ 看到这里，聪明的读者一定也想到了，创造新的协议一样会受到中间设备僵化的影响。近些年来，因为在互联网上部署遭遇很大的困难，创造新型传输层协议的努力基本上都失败了！ 所以，想要升级新的HTTP协议，那么就只剩一条路可以走了，那就是基于已有的协议做一些改造和支持，UDP就是一个绝佳的选择了。 总结 因为HTTP/2底层是采用TCP协议实现的，虽然解决了HTTP队头阻塞的问题，但是对于TCP队头阻塞的问题却无能为力。 TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。 但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。 另外，TCP这种可靠传输是靠三次握手实现的，TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。如果是HTTPS那么消耗的RTT就更多。 而因为很多中间设备比较陈旧，更新换代成本巨大，这就导致TCP协议升级或者采用新的协议基本无法实现。 所以，HTTP/3选择了一种新的技术方案，那就是基于UDP做改造，这种技术叫做QUIC。 那么问题来了，HTTP/3是如何使用的UDP呢？做了哪些改造？如何保证连接的可靠性？UDP协议就没有僵化的问题了吗？ 这些问题我们在下一篇中深入分析。敬请期待！ 参考资料： https://http3-explained.haxx.se/ https://baike.baidu.com/item/中间设备/3688874 https://time.geekbang.org/column/article/150159 https://juejin.cn/post/6844903853985366023 https://time.geekbang.org/column/article/279164
-
都说IPv6的时代马上就要来了，到底什么是IPv6 ？ 据新华社北京11月26日电。近日,中共中央办公厅、国务院办公厅印发了《推进互联网协议第六版(IPv6)规模部署行动计划》，部署加快推进基于IPv6的下一代互联网规模工作。计划指出，到2018年末国内IPv6活跃用户数要达到2亿，2020年末达到5亿，2025年末中国IPv6规模要达到世界第一。 近日传出的消息称，由下一代互联网国家工程中心牵头发起的“雪人计划”已在全球完成25台IPv6根服务器架设，中国部署了其中的4台，打破了中国过去没有根服务器的困境。 中国比发达国家晚接入互联网20年，是互联网行业的后来者，虽然在互联网产品和互联网应用上是大国，但我们的操作系统还是国外的，我们在核心技术上仍有差距，想要在IPv4环境下进行技术创新，中国几乎没有什么机会了。但IPv6新的帧结构预留了一些可增加功能的字节，会有新的技术空间，在新的空间下，我们跟发达国家起步差不多，我们是有机会的。 国际互联网有八千多个标准，在IPv4时代，中国只提了中文编码标准。但目前中国就IPv6提出了一百多个标准，可以说IPv6为中国互联网发展打开了一个新的创新空间。 还有就是在IPv4时代，中国是没有根服务器的，新增几乎不可能，在IPv6新的体系下，为新增根服务器带来了希望，拥有根服务器则意味着中国在顶级域名上获得了解释权，而在过去这一解释权主要在美国手中。所以这也是一个机遇，这都会带动中国互联网发展。 IPv4地址枯竭 IPv4地址枯竭（英语：IPv4 address exhaustion），又称IPv4地址耗尽，为互联网通信协议第四版（IPv4）可使用的未核发地址完全用尽的状况。从1980年代晚期开始，已经开始意识到这个问题将会发生。IPv6的研发及布署，主要就是为了解决这个问题。 IP地址的全球性管理机构为互联网号码分配局（IANA），其下有五个局域网际网络注册管理机构（RIR）。由IANA管理的IPv4位址，于2011年1月31日完全用尽。其他五个区域的可核发地址，也随之陆续用尽：亚太地区在2011年4月15日用尽，欧洲地区在2012年9月14日，拉丁美洲及加勒比海地区在2014年6月10日，北美地区在2015年9月24日。目前全球仅剩主管非洲的AFRINIC预计2019年才会发放完所有的IPv4位址。 在理论上，IPv4最多可以提供232（约42.9亿）个IP地址，IANA及RIR可以用来核发的地址，各自约1千6百万8千个。在1991年11月，互联网工程任务组为了推迟这个问题发生的时间点，推出分类网络方案。1993年，推出网络地址转换（NAT）与无类别域间路由（CIDR）。但是这些过渡方案皆无法阻止地址枯竭问题的发生，只能减缓它的发生速度，最终的解决方案，仍然需要转换到IPv6。 中国是世界上互联网用户数量最多的国家，但人均只有0.45个IPv4地址。在IPv4的环境下，我国用户上网地址需要动态分配，人与地址没有固定的对应关系，用户溯源难，带来互联网安全和监管隐患。而且中国互联网用户人数还在增加，但现在全世界IPv4地址已经分完了，中国不可能拿到新的IPv4地址，所以IPv6地址对中国来说是最需要的。 再有，随着物联网技术的发展，物品上网的数量将超过人上网的数量，IP地址需求量更大。IPv6地址数量充足，为移动互联网、物联网等全新业务留有地址空间，足够支撑现有的和未来出现的新应用，更适应产业互联网的发展。美国人均有6个IPv4地址，但为了反恐需要地址溯源以及为了未来的发展，也积极向IPv6转型。 IPv6 IPv6指的是互联网协议第六版的缩写，其地址数可能比全世界的沙子还要多，足以解决目前IPv4地址量不足的问题。有人说，按照地球的容纳能力，IPv6足以构架出一个“星际网络”。 最新统计数据显示，截至2017年8月，25台IPv6根服务器在全球范围内已累计收到2391个递归服务器的查询，主要分布在欧洲、北美和亚太地区，一定程度上反映出全球IPv6网络部署和用户发展情况。从流量看，IPv6根服务器每日收到查询近1.2亿次。 IPv6 VS IPv4 在Internet上，数据以分组的形式传输。IPv6定义了一种新的分组格式，目的是为了最小化路由器处理的消息标头。由于IPv4消息和IPv6消息标头有很大不同，因此这两种协议无法互操作。但是在大多数情况下，IPv6仅仅是对IPv4的一种保守扩展。除了嵌入了互联网地址的那些应用协议（如FTP和NTPv3，新地址格式可能会与当前协议的语法冲突）以外，大多数传输层和应用层协议几乎不怎么需要修改就可以工作在IPv6上。 地址 IPv4 长度为 32 位（4 个字节）。IPv4 地址的文本格式为 nnn.nnn.nnn.nnn，其中 0
