TCP的运输连接管理
TCP是面向连接的协议，有三个阶段：连接建立、数据传送 和 连接释放。运输连接的管理就是使运输连接的简历和释放都能正常地进行。
在TCP连接建立过程中要解决一下三个问题：
1、 要使每一方都能够确知对方的存在： 所以需要三次握手。
2、 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。
3、 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配：建立TCB。
TCP连接的建立采用跟客户-服务器模式。主动发起连接建立的应用进程叫做客户端，而被动等待连接建立的应用进程叫做服务器。
*TCP三次握手 四次挥手
http://blog.csdn.net/whuslei/article/details/6667471
建立连接时：首先服务器被动打开处于listen状态，客户端启动后向服务器发送syn报文，服务器收到后发送syn+ack报文，然后客户端再向服务器发送ack报文；此时连接建立；可以发送数据；
当客户端已经没有数据要发送给服务器时，客户端想服务器发送fin报文，服务器收到后发送ack确认自己收到了，此时客户端不能在向服务器发送数据了，但服务器仍然可给客户端发送数据，当服务器发送完数据后，服务器发送一个fin报文告诉客户端我已经发完数据了，客户端回复一个ack确认报文，接下来，客户端会等待2MSL时间，因为确认报文可能中途丢失，如果在这2MSL等待时间内服务器没有发来任何消息说明服务器已经收到了报文，这是客户端就可以关闭了，服务端在收到ack报文时也可以关闭；
MSL（Maximum Segment Lifetime）即最长报文段寿命，RFC建议为2分钟，具体实现时可以使用更小的值。
保活计时器（keepalive timer）：
当客户端发生故障时，服务端不能再收到客户端的数据，因此应当有措施是服务器不要白白等待下去。服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两小时。若两小时没有收到客户的数据，服务器就发送一个探测报文段，以后则每隔75秒发送一次。若一连发送了10个探测报文段后仍无客户的响应，服务器就认为客户端出了故障，接着就关闭这个连接。在这期间，若客户端重新启动收到了探测报文，则客户端发送一个复位信息，让服务器关闭连接。
状态转移图，异常转移，课后习题。
为什么需要三次握手和四次挥手？
三次握手：严格来说即使N次握手也不能保证双方百分百成功建立连接，因为只要最后一次确认丢失，双方就处于一种信息不对称的状态（这种不对称是当前时间点的不对称，对这个时间点以前的信息对称的）。成功建立连接的标志应该是：互相都知道对方都准备好传输数据，这种情况至少需要三次握手。以A为客户端，B为服务器端为例， 假如只使用一次握手：A向B发送了一个报文，然后双方都认为连接建立，这种情况其实已经相当于UDP无连接了，没有任何意义；假如使用二次握手：A向B发送syn报文，B向A发送一个ACK报文（可能也报文syn字段），这时B已经知道了A要向他建立连接，双方的信息基本对称了，然而此时B到A的报文段有可能丢失，那么A就无法判断B是否收到了自己的连接请求，A状态未知，B也知道A的这种情况，所以需要第三次握手，即A想B发出ACK报文，这时双方都知道对方都已经准备好传输数据（之前的的时间点准备好，当前的状态仍然是不对称）。
以上只是考虑了数据包丢失的情况，如果出现数据包延迟达到，就会出现“已失效的连接请求报文段”，比如A向B发送的连接请求报文延迟达到B，B误以为是新的连接请求，然后接受发出ACK报文，如果是二次握手B此时就进入了establishing 状态，但这是种错误的状态，因为A早已放弃这个连接了。
总之多少次握手都无法保证百分百成功建立连接，因为最后一次报文可能出现丢失，延迟达到等各种情况。三次握手成功只是能说明双方现在已经有相当高的概率可以正常通信了。
四次挥手：四次挥手实际上就是两个FIN报文和两个ACK报文，这四个报文必不可少。A没有数据要发送了必然会向B发送一个fin报文，B必然要回复个ACK报文。为什么B不能学习三次握手将fin和ack合二为一？，因为B受到fin报文后要通知上层应用程序，上层应用程序可能数据没有发送完毕，这时就不能发送fin，即使是发送完了，B也不应该将两者合二为一（通知上层应用可能需要很多时间，这些都是不确定的），最好的方法就是先发送ACK告诉对方，然后在合适的时机发送自己的fin。
在 TCP C/S 模式下，当 TCP 客户端想断开的时候，不能用 shutdown 和 closesocket 与 TCP 服务器断开，只有让 TCP 服务器端主动断开（TCP 客户端被动断开），TCP 客户端的端口才能立刻被释放。http://blog.csdn.net/HackerJLY/article/details/6116857
服务器端能不能主动断开连接？
可以，但是主动断开连接的一方要等待2MSL，在这期间内核不会释放资源，这对服务器来说是不利的。
断开连接后需要做哪些处理工作？
回收资源：socket、内存、端口号。
TCP 长连接和短连接
参考文献：http://www.cnblogs.com/liuyong/archive/2011/07/01/2095487.html
http://www.cnblogs.com/cswuyg/p/3653263.html
http://blog.chinaunix.net/uid-26000296-id-3758651.html
http://blog.sina.com.cn/s/blog_9720724f0101feg4.html
短连接: 指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接;
一般银行、http服务器都使用短连接。短连接一般是一对多。
长连接: 指在一个TCP连接上可以连续发送多个数据包，在TCP连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接；p2p、数据库连接。
通常的短连接操作步骤是： 连接→数据传输→关闭连接；
而长连接通常就是： 连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接；
KeepAlive
参考文献：
http://www.cnblogs.com/cswuyg/p/3653263.html
KeepAlive在TCP和http中有不同的含义；
TCP中keepalive在上文中的保活计时器中已经说明；
http中的keepalive的意义实际上是使用持久连接（长连接），以前对于每个http请求都是建立一次连接。这样每个连接只能传输一个http请求和响应，为了提高效率，可以在HTTP的头域中增加Connection选项。当设置为Connection:keep-alive表示开启，设置为Connection:close表示关闭。显示一个页面往往需要几十个请求，用持久连接的方式只需要建立一次连接就行。
网络编程之TCP和UDP
