Hi，欢迎来到 卡瓦邦噶！我是 laixintao，现在生活在新加坡。我的工作是 SRE，喜欢在终端完成大部分工作，对各种技术都感兴趣。我从 2013 年开始写这个博客，写的内容很广泛，运维的方法论，编程的思考，工作的感悟，除了技术内容之外，还会分享一些读书感想，旅行游记，电影和音乐等。欢迎留下你的评论。
声明：本博客内容仅代表本人观点，和我的雇主无关。本博客承诺不含有 AI 生成的内容，所有内容未加说明均为博主原创，一经发布自动进入公有领域，本人放弃所有权利。转载无需本人同意。但是依然建议在转载的时候留下本博客的链接，因为这里的很多内容在发布之后会还会不断地继续更新和追加内容。
虽然这个系列的文章都是聚焦于如何通过分析网络抓包文件，结合网络知识，来解决实际的问题的，但是分析之前的步骤——抓包，也是同样重要！很显然，如果不会抓包，那么网络分析去分析什么呢？
抓得一手好包也是很厉害的！笔者遇到过很多次情况，虽然我们无法直接定位根因，但是同事能够精准地捕获到问题的现象，把问题描述给相关的网络专家，传给他们抓包文件，专家一看到准确的抓包文件，就可以很快解决问题了！
可惜的是，抓包的技巧无法像网络分析那样可以通过文章来出谜题，来让读者小试牛刀。所以，这篇文章就来写一下一些常用的抓包方式和技巧，希望能补齐这一块内容。
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。要格外注意。
除了我们熟悉的 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 国际 协议。
小陈最近为团队的 HTTP 服务开发了一个高性能网关，用户的请求会先经过小陈开发的网关，网关对 HTTP Header 做一系列的校验，如果没有问题，会把请求转发给真实服务器（Real Server，简称为 RS）。网关经过测试，性能非常高，请求可以在 2ms 内完成转发。于是小陈很高兴，自己写的代码马上就能在线上服务十几万的真实用户了！现在，距离能够上线就差最后一步——压力测试，能不能支持十几万的用户同时在线，这时候就要拉出来溜溜了。
压力测试的时候发现，单机 QPS 总是在 5 万左右就无法继续提高了，虽说这个性能也够了，但是瓶颈到达的时候，CPU 和 内存的利用率都很低。无法充分利用硬件资源，这在当下「降本增效」的公司运动中解释不了呀！于是小陈撸起袖子，进行一番排查，势必找到瓶颈，榨干硬件资源。
经过查看日志，小陈发现这个网关的日志中有一些连接建立失败 (Failed to establish a new connection) 的情况。为什么连接会建立失败呢？难道是压测环境的网络出了问题？抓包看看就知道了！
小陈在网关侧进行抓包，得到的抓包文件如下。
对着抓包文件看了半天，小陈还是没有看出来个所以然。所幸，团队里有一个网络专家（就是你！）小陈只好来请求专家的帮助。
请下载上面这个抓包文件，用 Wireshark 打开，解释一下小陈的网关软件为什么会出现 Failed to establish a new connection 的错误？（答案会在下一篇博客揭晓）
这篇文章是计算机网络实用技术系列文章中的一篇，这个系列正在连载中，我计划用这个系列的文章来分享一些网络抓包分析的实用技术。这些文章都是总结了我的工作经历中遇到的问题，经过精心构造和编写，每个文件附带抓包文件，通过实战来学习网路分析。
如果本文对您有帮助，欢迎扫博客右侧二维码打赏支持，正是订阅者的支持，让我公开写这个系列成为可能，感谢！
没有链接的目录还没有写完，敬请期待……
与本博客的其他页面不同，本页面使用 署名-非商业性使用-禁止演绎 4.0 国际 协议。
看到一个 Golang 的模式，用一个 function 来实现一个 interface，function 本身就是 interface 的实现。初次看到看了好久才想明白。在这里记录一下。
以 Golang 内置库中的 server.go1 为例。Handler 的定义如下：
|
1 2 3 |
type Handler interface { ServeHTTP(ResponseWriter, *Request) } |
如果我们要定义一个 Handler，需要这么写：
|
1 2 3 4 5 6 7 8 9 |
// 定义一个结构体 type MyHandler struct{} // 实现 http.Handler 接口的方法 func (h MyHandler) ServeHTTP(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello from MyHandler!") } http.Handle("/hello", MyHandler{}) |
有两个问题：略显啰嗦；距离函数内容最近的 ServeHTTP 是一个 interface 规定的具体的名字，这个函数名字不能变，但是又没有意义，所有的 Handler function 都要写成这个名字。
我们现在写 Golang 显然不是这么写的。我们会这样定义一个 Handler：
|
1 2 3 4 |
func myHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, World!") } http.Handle("/hello", http.HandlerFunc(myHandler)) |
为什么我们可以这么写呢？因为源代码中有这样几行2：
|
1 2 3 4 5 6 7 8 9 10 |
// The HandlerFunc type is an adapter to allow the use of // ordinary functions as HTTP handlers. If f is a function // with the appropriate signature, HandlerFunc(f) is a // [Handler] that calls f. type HandlerFunc func(ResponseWriter, *Request) // ServeHTTP calls f(w, r). func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) { f(w, r) } |
虽然这里的注释只有短短几行，但是意义深刻。
首先，第一行定义的 type HandlerFunc func(ResponseWriter, *Request) 让我们的 myHanlder 函数变成了一个 type HandlerFunc 类型。
然后，所有的 HandlerFunc 对象都有一个方法，叫做 ServeHTTP，这就实现了 Handler 这个 interface。实现的内容，就是调用对象本身，对象本身是一个函数，所以就是调用这个函数。
综上，所有符合 ServeHTTP(w ResponseWriter, r *Request) 签名的函数都可以转换成 HandlerFunc 对象，（虽然它是函数，但是函数也是对象。）即所有签名如此的函数，都可以是一个 Handler 了。
我们就可以这么写：
|
1 2 3 4 |
func myHandler(w http.ResponseWriter, r *http.Request) { fmt.Fprintln(w, "Hello, World!") } http.Handle("/hello", http.HandlerFunc(myHandler)) |
那么为什么不直接把 Handler 定义成一个函数呢？
|
1 |
type Handler func(ResponseWriter, *Request) |
就可以实现一样的效果了。
这是因为，Handler 可以变得很复杂，比如，Golang 的 middleware 本质上就是基于 Handler 的链式调用来实现的。复杂的 Handler 需要维护一些内部的状态，这种情况下，struct 就比 function 好用很多了。比如 httpauth3 这个库，就先初始化成 Handler 再使用。
那如果还是把 Handler 定义成一个 function，三方库规定在使用的时候，先初始化一个三方库定义的对象，然后三方库提供兼容 Handler 的函数，好像能达到一样的效果？
这样的话，多个 middleware 的入参和返回是不一样的对象，就无法串起来了。而如果把 Handler 定义成一个标准库里面的对象，就可以做到：middleware 接收的是一个 Handler，返回的还是一个 Handler4。只要 middleware 是这样的接口，它们就可以串联使用。
还有一个有趣的一点，Golang 里面不光函数可以实现 interface，任何类型都可以5。（Golang 还真是一切皆对象呢。）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
type Counter uint64 func (i *Counter) ServeHTTP(w http.ResponseWriter, r *http.Request) { *i++ response := fmt.Sprintf("%v", *i) w.Write([]byte(response)) } func main() { var c Counter http.Handle("/count", &c) http.ListenAndServe(":8080", nil) } |