相关链接：http://www.cnblogs.com/visily/archive/2013/03/15/2961190.html
http://www.cnblogs.com/obama/p/3292335.html
http://www.cnblogs.com/rainbow1122/p/7852021.html
1. 状态转移图
说明：粗箭头表示典型的客户端的行为；虚线箭头表示典型的服务器行为。
2. 相关问题思考
2.1 2次握手是否可以？
不可以，简单说，让双方都证实对方能发收。
知道对方能收是因为收到对方的因为收到而发的回应。
具体：
1：A发，B收， B知道A能发
2：B发，A收， A知道B能发收
3：A发，B收， B知道A能收
就是A为什么还要发送一次确认。为了防止已经失效的连接请求报文又突然传送到了B,而产生错误。假设一种异常，A发出的请求由于网络阻塞没有及时到达B，后又重传请求，之后B响应了，且建立了连接，之后连接又释放了。此时假设A发出的第一个请求到达B,B误以为是A再次请求连接，B建立连接，如果采用两次握手，此时连接建立，而A又不发送数据，浪费了B的资源。
计算机网络书解释：
这就很明白了，防止了服务器端的一直等待而浪费资源。
2.2 TCP为什么要4次挥手？
数据传输结束后，通信双方都可以释放连接。现在A和B都处于ESTABLISHED状态，A的应用进程向其TCP发出连接释放报文段，主动关闭TCP连接。A进入FIN_WAIT1（终止等待1）状态。然后B确认，B进入CLOSE_WAIT(关闭等待)状态。此时TCP处于半关闭状态，A已经没有数据要发送了，如果B仍要发送数据，B仍然接收。A收到B的确认后，就进入FIN_WAIT2（终止等待2）状态，等待B发出连接释放报文。 如果B已经没有向A发送的数据，则B发送请求释放报文，B进入LAST_ACK（最后确认）阶段，等待A的确认。A在收到B的请求后，要发出确认，然后进入TIME_WAIT（时间等待）状态。此时，连接还未释放，必须等待时间等待计时器设定的时间的2MSL后，A才进入CLOSED状态。
为什么最后要等一个TIME_WAIT时间呢？一：为了保证最后一个ACK能够到达B,防止丢失了，B重传，A不能回复确认。二是为了防止之前提到的“已经失效的连接请求报文段“出现在连接中”。A发送完最后一个ACK，再经过时间2MSL，可以使本连接产生的所有请求报文从网络中消失。
//
假设已设定MSL（最大段生存期，Maximum Segment Lifetime）数值，按照规则：当TCP执行一个主动关闭并发送最终的ACK时，连接必须处于TIME_WAIT状态并持续两倍于最大生存期的时间，这样就能够让TCP重新发送最终的ACK以避免被丢失的情况。重新发送最终的ACK并不是因为TCP重传了ACK（它们并不消耗序列号，也不会被TCP重传），而是因为通信另一方重传了它的FIN（它消耗一个序列号）。事实上，TCP总是重传FIN，知道它收到一个最终的ACK。
2.3 关闭一个TCP连接3次挥手是否可以？
可以。收到第一个fin报文后，它自己也不需要传送数据了，回应fin、ack报文，对方再回应ack，总共三次，挥手完毕。实际中抓报文，有很多这样的情况。
3. 相关命令
telnet
netstat
sock
4. 参考链接
