第一次握手:建立连接时,客户端发送SYN到服务器,并进入SYN_SENT状态
第二次握手:服务器收到请求后,回送SYN+ACK信令到客户端,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到SYN+ACK包,向服务器发送确认ACK包,客户端进入ESTABLISHED状态,服务器收到请求后也进入ESTABLISHED状态,完成三次握手,此时TCP连接成功,客户端与服务器开始传送数据
1、客户端发起连接
2、服务端确认
3、客户端再次响应回复确认 TCP三次握手成功
1、问:第二次确认不就可以了么?
答:为了确认客户端是否已经收到了服务端发出的信息,如果服务端发出的信息没有得到有效回复,那么超出时间后服务端会在次发送重连信息,直到超时丢弃,第三步中如果服务器没有收到客户端的最终ACK确认报文,会一直处于SYN_RECV状态,将客户端IP加入等待列表,并重发第二步的SYN+ACK报文。重发一般进行3-5次,大约间隔30秒左右轮询一次等待列表重试所有客户端。另一方面,服务器在自己发出了SYN+ACK报文后,会预分配资源为即将建立的TCP连接储存信息做准备,这个资源在等待重试期间一直保留。更为重要的是,服务器资源有限,可以维护的SYN_RECV状态超过极限后就不再接受新的SYN报文,也就是拒绝新的TCP连接建立。 DDOS来了解一下
比如: A说 中午帮我带个咖啡
B说:中午啥咖啡, 然后A一直不回复,长期等待中,再说一次A还是不回复,B就直接会无视说这个逗逼
又或者说 B说:中午啥咖啡
A回: 你喝啥我就喝啥, 这样就能建立一次有效的连接。
2、问:TCP建立连接为什么是三次握手
第一次握手成功:说明客户端的数据可以被服务端收到,说明客户端的发功能可用,说明服务端的收功能可用。但客户端自己不知道数据是否被接收
第二次握手成功:说明服务端的数据可以被客户端收到,说明服务端的发功能可用,说明客户端的收功能可用。同时客户端知道自己的数据已经正确到达服务端,自己的发功能正常。但是服务端自己不知道数据是否被接收
第三次握手成功:说明服务端知道自己的数据已经正确到达客户端端,自己的发功能正常。至此服务成功建立
数据连接大致如图
当客户端与服务端建立连接之后,客户端向服务端先发送数据,分片发送, 服务端接收完数据之后会返回一个确认信息,说明已经接收完了,如果客户端没有收到这个ack,那么服务端重发一个ack信息.
1、问:如果客户端发送数据完成,客户端就挂了,服务端接收到的文件完整么?
客户端发送按MTU将数据到服务端 (客户端一次会将数据全部发送过来),服务端接收到数据在内核态中,由内核态复制到用户态,这段数据是完整的,所以说在客户端传输完就断开,并不会影响到数据的完整性,就是唯一一点要确认的是 客户端发送到服务端的数据是完整的么? 这里可以用md5值来看一下检验。
1、第一次挥手:客户端发送[fin+ack]请求,说明的确没有数据在在传输了,此时状态为fin_wait1;
2、第二次挥手:服务端接收到客户端的请求,确认可以断开连接发送[ack]确认,此时状态为close_wait,客户端收到确认信息状态信息改为fin_wait2,
3、第三次挥手:然后会在发送一个自己本身断开的请求[fin,ack],服务端就连接断开了,状态位为last_ack;
4、第四次挥手:客户端发送最后一次的确认信息[ack],此时状态为time_wait,服务端收到后将状态改为close关掉状态
大白话就是:A: 老大我吃完我走了
B:好的, (A这时准备开走)那你走吧,
A:老大下次再见哈
当数据传输完成之后,会产生四次挥手,状态如下
原文:http://blog.51cto.com/xiong51/2110924