首先，感谢来自工程师冯文鹏冯工的投稿，谢谢！
什么是外链天窗问题？
当网页包含其它网站内容的链接（外链），即使采取双栈技术路线，全面升级网络和修改程序，但被引用的其它网站未升级，IPv6用户访问该网站时会出现响应缓慢，部分内容无法显示，部分功能无法使用等情况。
该问题被称为“天窗”问题。
外链处理基本思路
外链基本形式分为两种，一种是地址形式，一种是域名形式。
一般情况，解决ipv6-only天窗问题，需要至少两个Virtual Server协同配合实现。
第一个Virtual Server（主站VS），客户端请求到主站VS，主站VS返回的html代码中包含有其他外部IPv4站点的地址或域名。
第二个Virtual Server（外链VS），客户端收到主站VS返回的其他站点的v4的地址或域名，客户端会接着对这个返回的地址/域名发起请求，由于客户端为IPv6 only，所以对IPv4的站点是不具备访问能力的，因此，我们就需要给IPv4的外链进行一次IPv6的转换，这个转换一般是在链路负载上实现的。如果外链是一个只包含有IPv4地址的域名，那么，我们就要对域名和地址进行双重转换，使得客户端对主站内容所有链接的请求都首先到达这台链路负载，外部的链接由负载代理客户端去请求。
1.1.当外链为地址时
外链是地址的情况
地址形式的外链，一般我们需要修改body中的外链地址为链路负载转换后的IPv6地址，Alteon策略如下：
一般客户端浏览器的请求Header中会携带压缩指令“Accept-Encoding:gzip, deflate”，因为有这个Header，服务器的回包往往都会进行压缩，而Alteon是不会对服务器的回包进行解压的，最终导致对回包修改失败。
解决这个问题的方法，需要我们通过alteon在request方向去掉“Accept-Encoding: gzip, deflate”这个Header，然后才能对respond方向的回包修改成功。所以，完整的修改策略如下：
该策略与主站VS相关联，当有这个策略时，客户端收到的代码中外链的地址就被修改成了链路负载上地址是IPv6的vip地址，这个单独的外链VS会使用一个IPv4地址代理请求到真正的目的地址。
1.2.当外链为域名时
如果是域名的情况，在客户端请求主站VS的时候，所做的动作差不多，都是先去掉压缩指令“Accept-Encoding: gzip, deflate”，再替换body的内容，只不过这里是把地址换成了域名。
当然用来替换的域名，是与链路负载的外链VS绑定的，即，替换外链的域名解析出来的就是这个VS的v6地址。当然，获取外部域名对应的IPv4地址的方法有很多，ping，nslookup，dig都可以。
仅仅是做完这一步，请求很有可能是失败的，因为有些站点会验证request请求头中Host字段，当Host的字段验证不通过时，外链服务就会返回错误页面。
由于真实的目的域名，被篡改成了一个新的域名，客户端请求的时候，request中的Host插入的是链路负载给他的域名，而链路负载代理客户去访问真实的外链服务时，是不会修改request中的内容的，所以Host中的值就被原封不动的发送给了外链服务器。所以，我们还需要新建一条修改Host的策略：
而这一条策略是关联在外链VS上的。
外链问题该如何解决呢？见下次技术分享——Radware IPv6链外天窗案例-百度地图外链解决方案（二）
以上就是朝夕生活（www.30zx.com）关于“Radware IPv6外链天窗-百度地图外链解决方案（一）”的详细内容，希望对大家有所帮助！
