TCP协议点滴

以前写网络程序的时候，对TCP协议了解的少，出些问题，很是抓狂。

没事的时候在看看TCP协议，加深理解.

TCP协议
三次握手过程描述
第一次握手:建立连接时，客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时
服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入
ESTABLISHED状态,完成三次握手. 这部分是百度百科里面的内容，没事也可以看看TCPIP协议那本书就是有点老。

TCP正常的关闭过程 四次握手过程
(FIN_WAIT_1)A --FIN--> B(CLOSE_WAIT)
(FIN_WAIT_2)A <--ACK-- B(CLOSE_WAIT)
(TIME_WAIT) A <--FIN-- B(LAST_ACK)
(TIME_WAIT) A --ACK->  B(CLOSED)
A端首先发送一个FIN请求给B端,要求关闭,发送后A端的TCP状态变更为FIN_WAIT_1,接收到FIN请求后B端的TCP状态
变更为CLOSE_WAIT
B接收到ACK请求后,B回一个ACK给A端,确认接收到的FIN请求,接收到ACK请求后,A端的TCP状态变更为FIN_WAIT_2.
B端在发送一个FIN请求给A端,与链接的过程3次握手过程不一样,这个FIN请求之所以并不是与上一个请求一起发送,
之所以如此处理,是因为TCP是双通道的,允许在发送ACK请求后,并不马上发送FIN请求,即只关闭A到B端的数据流,
任然允许B端到A端的数据流.这个ACK请求发送之后,B端的TCP状态变更为LAST_ACK,A端的状态变更为TIME_WAIT.
A端接收到B端的FIN请求后,再回B端一个ACK消息,对上一个FIN请求进行确认,到此时B端状态变更为CLOSED,socket可以关闭.

这部分是这个博客的内容觉得说的通俗易懂，我懒的自己描述了，他的网址http://ayufox.iteye.com/blog/646898

TIME_WAIT案例:这个juven提到的content集群 积累大量TIME_WAIT链接，导致服务不稳定，CPU负载变得很高的案例，http://www.juvenxu.com/2014/01/19/a-note-of-performance-optimisation-on-tcp-timewait/。

理解TCP四次握手关闭，对这个案例会理解更深。

 

http://www.iteye.com/topic/1110883  网络编程中Nagle算法和Delayed ACK的测试 丹尼斯大神的

http://blog.sina.com.cn/s/blog_560e310001014o06.html redis链接过多的一个解决方法

其它待续。