TCP的运输链接管理

TCP的运输链接管理

TCP是面向链接的协议，有三个阶段：链接创建、数据传送 和 链接释放。运输链接的管理就是使运输链接的简历和释放都能正常地进行。

在TCP链接创建过程当中要解决一下三个问题：

一、  要使每一方都可以确知对方的存在： 因此须要三次握手。

二、  要容许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）。

三、  可以对运输实体资源（如缓存大小、链接表中的项目等）进行分配：创建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.bubuko.com/infodetail-260176.html

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