将 IPv6 照进现实,我们需要做些什么?
其中 Connected by ('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx 为服务端看到的手机地址,34102为对应的端口号,那么这个地址和端口号是不是手机自身的呢,去手机上看一下: odin:/ $ busyboxnetstat Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.84.66.147:43623 111.13.134.131:443 CLOSE_WAIT tcp 0 0 10.84.66.147:46051 140.205.34.21:443 ESTABLISHED tcp 0 0 ::ffff:10.84.66.147:49856 ::ffff:112.13.64.13:5333 ESTABLISHED tcp 0 0 ::ffff:10.84.66.147:37201 ::ffff:39.106.239.196:443 ESTABLISHED tcp 0 0 ::ffff:10.84.66.147:55440 ::ffff:118.194.55.183:5223 ESTABLISHED tcp 0 0 2409:8928:84e:995:3b4a:38ce:8ead:1972:34102 2400:3200:1000:xxxx:::80ESTABLISHED 从上面输出来看,运营商的中间设备没有做 NAT,也没有做 PAT,服务端看到了手机发出的原始的源地址和源端口,当然防火墙还是有的,主动从服务端还是不能访问手机。 MTU问题 从协议头来看 v4 和 v6 有一个比较重要的差异就是 Don’t Fragment bit 这个位一直开的,也就是由于一直是开的所以在 IPv6 的头里面就没有明示这个字段,如果有fragment 就会增加一个 Fragemention Header。由于网络中间支持 v6 的路由器不会对对 IPv6 包进行分片,所以如果一个包过大那么路由器会产生 ICMP6 Type2 数据包,内含 Packet Too Big (PTB) 和 MTU 信息返回给发送方,这样机制看上去比较好,但是由于中间设备可能会过滤掉 PTB 数据包造成这样的通知发送方收不到影响正常传输,因此发送方最好在开始的时候就不要发送过大的数据包,目前一个建议参考值 MTU 是1280字节。 未结束的结束语 IPv6 的序幕刚刚拉开,这篇文章也仅是粗浅的初步分析,抛砖引玉。随着时间的推移,文中的一些举例也可能随着网络演进或者策略更改而变化,所以若有不对的地方还请见谅,希望在后面的过程中能够积累沉淀出更多的实践和思考,提升 IPv6 下的业务体验。 【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件,转载请联系原作者】 戳这里,看该作者更多好文
(编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |