Hi，欢迎来到 卡瓦邦噶！我是 laixintao，现在生活在新加坡。我的工作是 SRE，喜欢在终端完成大部分工作，对各种技术都感兴趣。我从 2013 年开始写这个博客，写的内容很广泛，运维的方法论，编程的思考，工作的感悟，除了技术内容之外，还会分享一些读书感想，旅行游记，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本博客承诺不含有 AI 生成的内容，所有内容未加说明均为博主原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
这篇博客是请求为什么超时了？这篇的答案和解析。
首先，通过这个抓包文件前几个包可以发现，服务器的网络是没有问题的，因为访问 DNS 或者 ubuntu apt 源都是通的。
这个问题有两个要点。第一点是，抓包文件并不是仅仅包含出问题的请求本身，还包含很多与问题无关的流量。不过现实的情况也往往如此，我们要在很多抓包和分析的时候过滤掉和问题无关的流量。
有一个非常好用的过滤方法，就是直接用 TCP 的 payload 内容进行过滤。比如，我们已经知道请求的目标是 example.com 了，那么 Host: example.com 必然会存在于 TCP 的 body 中，所以可以用以下的过滤条件：
tcp.payload contains "example.com"
（在之前的写的 网络抓包的技巧 中也介绍过，我们可以发送带有标记的请求，tcp.payload contains "xxx" 也是过滤出来这种标记请求的好方法）
用这个过滤条件可以得到以下的几个包，这就是我们要分析的请求了。
可以看到，我们发送给 exmaple.com 80 端口的包从来就没有得到过确认，于是一直在增大请求间隔并不断重试。
另一个奇怪的地方是，这个 TCP 请求没有 SYN 包被过滤出来，直接就开始发送 payload 了。这说明这个连接是在我们抓包之前就已经建立好的，所以我们没有看到连接建立的过程。
我们这个抓包文件的第一个包的时间是 37分52秒，而 HTTP 请求的第一个包时间是 39分28秒，间隔了 156 秒。这意味着这个 TCP 连接是至少在 156秒之前建立的，并且在建立之后，至少在 156秒 的时间内，没有发送过任何内容。
那么这个连接很可能因为 inactive 太久而被中间的网络设备丢弃了。如何定义 inactive？简单来说就是这个 TCP 连接上没有在一段时间内没有传输任何内容。
为什么网络设备会丢弃不活跃的 TCP 连接呢？因为机房的程序访问到公网要经过 NAT，防火墙等网络设备（其实和家用宽带是一样的，只不过家用路由器本质上是一个路由器+NAT+防火墙），而防火墙或 NAT 设备的内存只能保存有限的连接数，因为连接的保持需要内存，内存是有限的。它们普遍采用的策略是保留最近用到的连接，丢弃最旧没有有消息的连接。即使内存没有用完，一般在配置上也会设置一个连接最长的 inactive 时间，尤其是防火墙设备。
那么如何解决这个问题呢？首先如果不用长连接肯定就没问题了，每次需要发送 HTTP 请求的时候，都重新建立 TCP 连接。但这样成本就高了，TCP 连接不复用会浪费硬件资源，延迟也会升高。所以更好的方法是使用 Keepalive，即还是复用长连接，但是需要把长连接保持住。Keepalive 的原理，其实就是定时在 TCP 连接上发送 len=0 的包，即不包含 payload，类似于 duplicate ACK。发送空包不会对对端造成任何干扰，但是这些数据包会刷新中间的网络设备，避免连接失效。退一步讲，即使连接失效了，也可以通过 Keepalive 包来提前发现，避免用到的时候才通过超时发现问题。
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
小明是一名网络工程师，有一天，同事报告问题说：自己的程序发送 HTTP 请求在测试环境好好的，但是在线上环境就总是超时，而且很容易复现，需要网络工程师的帮助。
这里的场景是，在线上运行环境，去用 HTTP 请求一个第三方（在这个例子中，是 example.com 提供的服务）。
首先，小明和同事一起复现了问题，确定超时确实存在，然后他们在请求发送方进行抓包，在抓包的同时又复现了一次超时的情况。拿到抓包文件，小明一看，立即就发现问题了所在了……
请下载这个文件并分析超时问题的根因。（如果没有头绪，可以打开这个提示）
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
虽然这个系列的文章都是聚焦于如何通过分析网络抓包文件，结合网络知识，来解决实际的问题的，但是分析之前的步骤——抓包，也是同样重要！很显然，如果不会抓包，那么网络分析去分析什么呢？
抓得一手好包也是很厉害的！笔者遇到过很多次情况，虽然我们无法直接定位根因，但是同事能够精准地捕获到问题的现象，把问题描述给相关的网络专家，传给他们抓包文件，专家一看到准确的抓包文件，就可以很快解决问题了！
可惜的是，抓包的技巧无法像网络分析那样可以通过文章来出谜题，来让读者小试牛刀。所以，这篇文章就来写一下一些常用的抓包方式和技巧，希望能补齐这一块内容。
tcpdump 命令是我们最常用的抓包工具了1。
tcpdump -i eth0 icmp and host 1.1.1.1
这个命令就可以抓取到所有通过 eth0 去 ping 1.1.1.1 这个地址的包。
-i eth0 的意思是抓取指定的 interface，如果不指定，tcpdump 会默认选择一个。但是推荐每次都指定好这个参数，这样就没有不确定性了。如果使用 -i any 就可以抓取所有常规端口（文档的原文是 all regular network interfaces），但是什么属于「常规端口」就取决于操作系统的实现了。所以，建议也是如果要抓取多个 interface 来分析的话，就多开几个 tcpdump 进程，这样更加稳定一些。
这个参数非常有用，比如，在定位 ARP 问题的时候，我们需要确定每一个物理接口收发 ARP 的情况，就可以开多个进程分别 dump 每一个 interface 的网络；在定位 Linux 网络栈不通的情况时2，比如有 macvlan，vlan，veth 等复杂的 driver，可以用 tcpdump 对每一个接口 dump，看下包丢在哪里。
icmp and host 1.1.1.1 这个就是包过滤的表达式了，icmp 表示只抓取 icmp 协议，host 1.1.1.1 表示只抓取 src ip 或者 dst ip 是 1.1.1.1 的包。这种包过滤表达式其实是 pcap-filter(7)3 提供的，所以要想看语法是怎么定义的，看 pcap-filter 的文档就可以了。pcap-filter 支持的语法很灵活，能做的事情很多，基本上想抓什么样的包都可以写出来。但是我们没有必要把所有的语法都记住，因为常用的抓包都是比较简单的。可以找一个 tcpdump exmaple4 看一下，基本就够用了。其次，我们一般不会直接从 tcpdump 就分析出来问题原因，所以这个语法最重要的作用是把我们想要的包抓到，然后为了抓包性能更高，抓包文件更小，我们想要对抓包定义的更精确一些。其实，多抓一些包也没有什么问题，如果不确定怎么过滤出来 TCP SYN+ACK 的包，那不妨就把所有的 SYN 包全抓到，然后再用 Wireshark 这种工具来分析吧。最后，我们现在有 AI 了，用 AI 来写 pcap-filter 也是一个不错的方法，因为这种语法难写，但是很容易验证正确性。
Tcpdump 一些常用的其他参数如下：
-n 不解析主机名和端口号，保留原始的数字-v, -vv, -vvv v 越多表示输出的信息越详细-c 5 表示抓到 5 个包之后就退出-e 显示二层的 link layer header，这样就可以看到 MAC 地址了-Q 可以指定抓包方向，可以选的有 in, out, inout-A 可以展示包的内容，tcpdump 默认是只根据不同的协议展示 header 信息的。在线上排查问题的时候，我们往往需要通过特殊请求的关键字来定位到单个请求的情况进行排查，这样 -A 展示出来包的内容就格外有用。
这里分享一个特殊的技巧，就是发标记请求来定位问题。比如 A 通过 B 代理发请求给 C，现在网络不通，我们要定位 B 收到了请求没有，才知道是 B 的问题还是 C 的问题。但是 B 本身就有很多线上流量，怎么知道 A 发送的请求到达 B 了没有呢？我们可以在 B 进行 tcpdump：tcpdump -i eth0 tcp | grep asdf123 -A 10，然后我们从 A 发送一个请求：curl http://host-C.com/asdf123。asdf123 就是我们在请求里面放上的标记，如果 B 能够正常转发，我们就可以 match 到这个请求。当然了，这种技巧只适用于 HTTP 这种明文协议。
有些问题很难直接在 tcpdump 的终端分析出来问题，比如涉及 sequence number 分析的，重传分析之类的，我们需要人工对比 seq number，真是一项费眼睛的工作！所以如上所说，我们也经常在机器上用 tcpudmp 抓包保存成 .pcap 文件，下载到本地用 Wireshark 分析。Wireshark 就可以自动根据 sequence number 告诉我们重传等信息了！
具体的操作方式是，用 tcpdump -i eth0 -w file.pcap icmp 来进行抓包，-w file.pcap 表示把抓包文件保存为 file.pcap，抓包结束后，就可以把这个文件用 rsync 或者 scp 下载到本地，用 Wireshark 打开了。
.pcap 文件是一种标准的二进制抓包文件5，很多抓包分析工具都支持这种格式的解析，比如 tcpdump, wireshark, scapy 等等，如果想写代码进行更加定制化的分析，也可以用已有的库6解析，就如同用 json 库来解析 json 文件一样。
使用 -w 写入文件的时候有一个小问题，就是 tcpdump 原本的到终端的输出没有了。有两种方式可以解决，第一种是用 tcpdump 自带的 --print 功能：
tcpdump -i eth0 -w file.pcap --print
--print 会让 tcpdump 把内容输出到屏幕，即使当前使用了 -w 参数。
第二种就是用 tee，在写入文件的同时，也写入到 stdout。
tcpdump -i eth0 -U -w - | tee test.pcap | tcpdump -r -
其中，第一个 tcpdump 把抓包文件写入到 stdout（-w stdout，注意其中的 -U 表示按照 packet buffer，即来一个 packet 就输出一个到 stdout，而不是等 buffer 满了才进行输出），然后 tee 这里做了分流，把 stdin（tcpdump 的 stdout）同时输出到文件和 stdout。由于这里的 stdout 是 tcdpump 输出的二进制抓包内容，所以我们需要再用 tcpdump 解析这个二进制内容，-r - 表示从 stdin 读入。
还有一个技巧是 -s 参数，默认情况下 tcpdump 会保存所有抓到的内容，但是在分析某些问题的时候，尤其是 TCP 性能问题，我们其实不需要 TCP 传输的 payload 内容，只看 TCP 包的 header（序列号部分）就知道传输的速度了，所以可以用 -s 40 来只抓取前 40 个 bytes，有了 IP header 和 TCP header，就足够分析了。（如果担心有 TCP option 的存在，可以用 -s 54）
知道包是从哪里抓到的，很重要。在排查问题的时候，拿到抓包文件，应该第一时间确认抓包的位置。否则，就可能连自己看到的问题是现象还是根因都分不清楚。建议在复杂的结构中画一个拓扑图来对照分析，在定位 Linux 网络栈的问题时，如果接口拓扑非常复杂，也建议画一个拓扑图来分析。
可以从网络的多端抓包对照分析。发送端的抓包不一定等于接受端，尤其分析 TCP 问题的时候。可以同时在发送端和接收端进行抓包，然后对照分析。
在使用 tcpdump 的时候，要尤其注意，我们抓到的包已经经过了网卡驱动的处理，网卡驱动经常会帮 CPU 做一些 offload 的工作，比如把可能因网卡的 GRO/LRO 等特性，导致多个小包在抓包时被合并为一个较大的数据包，或者网卡帮助卸载了 vlan tag 等，我们用 tcpdump 抓到的包不一定是真正在网络上传输的包7。要格外注意。
注意抓包不要抓重。比如有人很喜欢用 tcpdump -i any ... 抓全部的包回来慢慢分析。然后下载下来抓包文件就吓坏了——重传率高达 50%！
在 Linux 中的网卡配置有 slave 和 master 的时候很容易发生这种情况，比如有 bonding 配置8，-i any 会从 slave 抓包包，从 master 又抓到一次，然后在 Wireshark 看来，所有的包都被重传了。实际是同一个包先后经过 slave 和 master 而已。
抓包的时候最好把相关 host 的 ICMP 协议包也一起抓了。因为 ICMP 是重要的 control message，TCP 在传输的时候，不光有 TCP 协议，可能还会用 ICMP 协议来传递一些信息。比如 PMTUD9，以及之前遇到过的这个问题10，都是涉及到 ICMP 包。如果只按照 TCP 协议来抓包，那这个重要的信息就错过了。
除了我们熟悉的 Linux 抓包，其实网络设备上也可以抓包的。我们一般叫它「端口镜像」技术，故名思义，原理就是把网络设备的一个端口的流量全部复制到另一个端口，而另一个端口连接的就是我们的抓包程序。
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
这个问题实际的原因是客户端的端口不够用了。
为什么端口会不够用呢？因为一个 TCP 连接的标志是四元组：
(src ip, src port, dst ip, dst port)
在这个场景中，代理服务器去连接 Real Server：
所以，能让 TCP 四元组不一样的字段，就只有 src port 了。
那么 Linux 服务器在连接远程服务器的 80 端口的时候，本地端口会用什么呢？答案是随机指定的。但是我们可以设置随机指定的范围。通过 sysctl -w net.ipv4.ip_local_port_range="32768 65535" 命令，可以让 client port 使用 32768 到 65535 之间的值。这样，低于 32768 的端口可以让其他服务 listen。
默认的端口就有 3 万个可用，所以大部分的情况下是很够用的。况且，这是在 client ip, dst ip, dst port 都确定的情况下最多可以建 3 万个连接。如果 dst ip 和 dst port 不固定，比如同一个 HTTP 服务在同一个 Server IP listen 了两个端口，那么就是最多 6 万个连接。如果部署多个实例，不同的 IP，那么每一个 IP 都可以是 3 万个连接。这么大的连接数量，一般来说代码性能甚至硬件（网卡）性能会首先到达瓶颈。
什么情况下会遇到端口不够用呢？
一种就是如上所说，一个代理程序去直连另一个真实服务器，两边的 IP 固定了，一边的端口固定了，那么 client 侧端口最多 3 万的话，在 QPS 大的情况下可能会遇到端口不够用的情况。
理论上最多可以有 3 万个并发，为什么在实际的情况中达不到这么高的并发呢？因为在一个 TCP 连接结束之后，这个 client port 并不是马上可以用来创建一个新的 TCP 连接。在 TCP 的状态机中，主动关闭 TCP 连接的一方会进入 TIME_WAIT 状态。需要在这个状态等待 2MSL （Maximum Segment Lifetime，最大报文生存时间，在 Linux 中，默认是 1 分钟的等待时间），然后这个 TCP 连接才会完全释放，client 端口才可以被重新用来建立新的 TCP 连接。
为什么要等呢？原因主要有二：
那么这种情况该如何解决呢？
首先可以调整参数，sysctl -w net.ipv4.ip_local_port_range="10000 65535" 就可以有更多的可用端口。
另一种就是用长连接，不那么频繁地建立连接，也就没有反复创建连接的端口问题了。
TIME_WAIT 状态的行为是可以通过参数调整的，通过 sysctl -w net.ipv4.tcp_tw_reuse=1 设置，可以让处于 TIME_WAIT 状态的端口用于创建新的 TCP 连接。（但是可能带来其他问题）
还有一种情况会遇到 local port 不够用，就是 NAT 设备，source IP 可能有很多，但是经过了 NAT，NAT 上的 TCP 连接就都是 NAT 的 IP 了，很容易造成四元组不够用。NAT 上面的问题最好的办法是增加出口 IP。
到这里，首先向读者致歉，在写分析的时候，我发现这个例子其实并不好完全通过抓包来分析解决。因为出问题的时候，客户端角度的包并没有发出来，抓包也就抓不到这个包。所以这个例子选的不合适。
这个例子最好的排查方法是通过客户端侧的网络状态来排查。直接通过 ss -s 命令，可以直接看到处于 timewait 状态的连接。
ss -s 命令查看连接状态如果很高（占用了可用 local 端口范围的大部分），就说明瓶颈在这里了。
通过 tcp.flags.syn==1 and tcp.dstport == 80 and tcp.srcport == 65531 这个条件来过滤，我们可以查看同一个 local port 建立连接的历史。
打开 Delta Time，可以看到这个端口每次复用的时间在 60s 之后了，和 Linux timewait 默认的等待时间一致，也可以判断出来是这种问题。
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
在之前的文章中介绍了网络的「分层」概念1，那么这一篇继续科普一下网络的基础，即「转发」这个概念。
为什么这么说呢？从前面网络的分层中我们已经知道，四层的网络协议是基于一种三层协议的，三层协议的数据包需要二层协议来承载（毕竟，我们不可能直接把三层数据包不经过二层直接传给别人），然后二层协议的数据包通过物理层发出去。物理层就是通信技术的知识了，可以说，到网络工程师这里第一层数字信号就是二层。在我们平时使用抓包工具抓包的时候，看的最外层数据包一般都是二层的包。
从网络设备的工作原理上讲也是这样，一个 IP 包从 src 传到 dst，中间经过了各种各样的网络设备，那么从 src 发出到 dst 收到，中间的网络设备修改了这个包的什么内容，才能一环接一环把它送到目的地呢？
交换机：不会修改任何内容，只查找自己的 mac 地址表转发走；
路由器：会根据 dst IP 查询下一跳应该发给哪一个 IP，但是下一跳的 IP 不会添加到数据包中。路由器会获取到下一跳对应的 MAC 地址，把数据包的 dst MAC 修改成下一跳的 MAC 然后转发出去。可以认为，此路由器出口 IP 和下一跳路由器入口的 IP 是在同一个子网中，所以每跳三层转发都是在同一个子网内的转发，即「所有的转发都是二层转发」。一般来说，路由器会有很多个物理接口，每一个物理接口都有 IP，互相连接的两个路由器的接口是在同一个子网（也有某些特殊的 P2P 网络可以不在同子网，甚至不需要配置 IP就能完成三层路由）。
可以看出来，如果不考虑 NAT 这种会改变 IP 的设备，三层及以上的内容（除了 TTL 会被路由器修改）的内容是基本不会改变的。而二层内容几乎每一次都在改变。
一个包从源发送到目的地，要经过的网络设备太多，遇到问题怎么排查呢？traceroute 是网络的世界中最常用的一个工具了。
它的原理是：发送 TTL=1 的 ping 包，故意让第 1 跳路由器无法完成转发，第 1 跳路由器只能丢弃这个包，并发送 ICMP time exceed 错误信息回来，这个 ICMP 是告诉我转发的时候出错了，源 IP 是发生因为 TTL 丢包的设备的 IP，目的 IP 就是我，因为错误是要告诉我的。于是我就知道了第 1 跳的 IP（即丢包的 IP）是什么了。如此炮制，继续发送 TTL=2 的包出去，拿到第二跳的地址。知道目的地收到了我的包并且回复 ICMP reply 回来。这样，我就知道了整条链路上所有的设备的 IP，就可以用来定位问题了。当然了，肯定有些设备因为「安全因素」的考虑，配置了不对丢包发回去 ICMP time exceed，这样，这一跳就是空的，我们拿不到它的 IP。
说起来，还有过一次挺有意思的讨论。一次面试的时候，我和人家讨论 traceroute 的原理，对方讲的很好—— 「发送 TTL=1 的包，再发送 TTL=2 的包，到那一跳的时候会因为 TTL 丢包，然后直接发送一个 ICMP 回来」。但是这里的「直接」很有意思，有多直接呢？我问：「直接的意思是，比如第 3 跳会直接发给 src IP 一个 ICMP，还是第三跳转发 ICMP 给第 2 跳，第 2 跳转发给第 1 跳，最后转发到 src IP ？」对方说：「是前者，会直接发给 src IP，因为是要立即告诉 sender 出错了。」
但是…… 候选人忽略了一个实际的问题——我们的 sender 和 R3 有物理连接吗？如果有物理连接，那么从发出的时候就不需要经过 R1 和 R2 了！说完之后他也恍然大悟，包是不可能隔空传递的！
谈到四层的时候，我认为流 (flow) 这个概念在四层上强调地不够。四层的数据流，就像小溪一样，源源不断从一个地方流到另一个地方，但是经过的路线总是一样的。
虽然在 IP 层每一跳都可能有多个下一跳设备可以选择，甚至多个设备的 cost 一样。那么在选路的时候，这一跳会根据 hash 算法来选择一个作为下一跳。hash 算法对于属于同一个流的数据包总会得到相同的结果，这样，就可以保证一个流的所有数据包经过的路线是一样的。比如，TCP 用来计算 hash 的 header 有 (src ip, src port, dst ip, dst port)，UDP 和 TCP 一样，ICMP 一般是 (src ip, dst ip)。这也取决于设备的配置和实现，不一定非要使用这些字段。比如，使用 (src MAC, dst MAC) 也可以，TCP 的 hash 也可以只使用 (src ip, dst ip)。只要保证一点：同一个流经过的路线是一样的，就可以了。
为什么要这样做呢？为了尽最大努力保证数据包的顺序，让接收到的顺序和发送的顺序是一致的。
但是 TCP 协议不是会保证包的顺序的一致性吗？是的。TCP 尽管可以帮我们纠正顺序，但是这不是免费的，TCP 需要在实现上利用 buffer 将乱序的包临时保存并且重新排列，然后再交给应用层。而且 TCP 协议可能认为收到的包乱序是网络堵塞了，然后会降低发送的速度。所以 IP 层会尽量保证包的到达顺序和发送顺序一致，但是不会完全保证。TCP 则会作为最后的兜底，完全保证顺序的一致性。
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。