昨天在小组的技术分享上，组长教我们怎样去调试一个服务器程序，收获很大。
1:ping 典型的 80或者23 这些端口，看看机器还活着么
2:telnet 看看我们的程序端口开着么(当然前提是TCP)
3:tcpdump 抓包，可以看看网络包的接受和发送速度，对于文本协议的调试更方便了。
啊。扯远了，主要还是在抓包的时候，应该四次挥手的TCP我们看到了3次，其中被动关闭方和FIN和对主动关闭方的ACK合并成了一个包。
我第一感觉很正常啊，因为右Nagle算法的存在。
我是这样理解的（我理解的是错的）
所谓Nagle算法，就是当我收到一个包的时候，并不立即发送对这个包的ACK确认，而是至多等待200ms(因为这是一个全局定时器)，把内核模块的ack确认和应用程序的数据组成一个包发出去。当被动关闭方收到主动关闭方的关闭FIN时，TCP内核模块并没有立即回复ACK确认，而是等待（至多200ms）应用程序调用了close之后，把被动关闭方的FIN和对主动关闭方的ACK确认一起发送了。
组长说我没有理解Nagle算法，结果和组长争执了半天。
回家后，自己动手测试，如果真是我所说的那样，当我关闭掉Nagle算法的时候，那应该能看到挥手的是4个包而不是3个包。
09:39:13.538063 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [S], seq 1375217039, win 32792, options [mss 16396,sackOK,TS val 773817 ecr 0,nop,wscale 7], length 0
09:39:13.538098 IP 127.0.0.1.5757 > 127.0.0.1.38963: Flags [S.], seq 3591125878, ack 1375217040, win 32768, options [mss 16396,sackOK,TS val 773817 ecr 773817,nop,wscale 7], length 0
09:39:13.538127 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [.], ack 1, win 257, options [nop,nop,TS val 773817 ecr 773817], length 0
09:39:19.117919 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [F.], seq 1, ack 1, win 257, options [nop,nop,TS val 775212 ecr 773817], length 0
09:39:19.118006 IP 127.0.0.1.5757 > 127.0.0.1.38963: Flags [F.], seq 1, ack 2, win 256, options [nop,nop,TS val 775212 ecr 775212], length 0
09:39:19.118040 IP 127.0.0.1.38963 > 127.0.0.1.5757: Flags [.], ack 2, win 257, options [nop,nop,TS val 775212 ecr 775212], length 0上面是我关闭掉Nagle算法之后抓包的包，前3个是握手，后3个是挥手。事实证明我错了。
赶紧查证《unix网络编程》和《TCP/IP详解1》，书上面明显的写着“Nagle算法指出：如果某个给定连接上有待确认数据，那么原本应该作为用户写操作之响应的在该连接上立即发送相应小分组的行为就不会发生，直到现有数据被确认为止".
读起来很拗口，我就用河南话说一下：
A---B：在么
A---B：我想你了
A---B：今晚有空么
B---A：在
B---A：我也想你了
B---A：今晚木有空。。。看看，追女神不应该是这样子，连着给女神发3条信息，女神也思考不过来啊，对女神也造成了精神损失。
试试下面的：
A---B：在么
B---A：嗯，在的
A---B：我想你了，今晚有空么
B---A：我在XXX等你。这就是开启Nagle算法的好处，手到禽来。Nagle算法就是说女神没有确认你的信息时候，就别在死缠烂打了，等女神回复的这段时候内，准备好接下来要说的话，别萝莉罗嗦的，把要说的一次说明白。
这下好了，不仅追到了女神，发的信息条数也少了，一条可是一毛钱啊，这在帝都的IT狗眼里也是很宝贵的。。。
不过呢，事物都有两面性，如果女神没看手机，或者过了10分钟才恢复，那这段时间自己动手就解决需求了。
所以，实际开发中，对于C/S的游戏，如果客户端每次收到对本次请求的回应之后，再发下一个包，我了个去，这卡的，玩家不骂死人才怪。这个时候就要关闭Nagle算法了，让客户端可以哗哗哗不停的发包去骚扰服务器。不过这可能会带来网络风暴，客户端本可以把两次的包合在一起的（当然是TCP内核模块干的事）。
我擦，怎么写不下去了，原来扯到女神身上了。
把当前大脑上下文切到tcpdump上，为什么挥手4次变3次呢。
因为ACK延迟算法。
A---B：今晚有空么
B---A：嗯
B---A：我在XXX等你
变成了下面这样
A---B：今晚有空么
B---A：有空，我在XXX等你ACK延迟算法，就是女神收到我的信息之后，不是立马回复一个“嗯，知道了”这中草蛋的话，而是在通知我她已经知道了的时候还一并把房间号告诉了我。
但是女神打字也是需要时间的啊，所以回复的ACK也要慢个200ms吧，等女神把“有空，我在XXX等你”打好之后，一并把“嗯”发过来。