linuxsocket3次握手,【关于TCP那些事】TCP3次握手与4次挥手

TCP是面向连接的&＃xff0c;每对客户端到服务器之间成功连接&＃xff0c;从建立到关闭都会经历3次握手与4次挥手的过程。

一、三次握手

(1)第一次握手&＃xff1a;建立连接时&＃xff0c;客户端A发送SYN包(SYN&＃61;j)到服务器B&＃xff0c;并进入SYN_SEND状态&＃xff0c;等待服务器B确认。

(2)第二次握手&＃xff1a;服务器B收到SYN包&＃xff0c;必须确认客户A的SYN(ACK&＃61;j&＃43;1)&＃xff0c;同时自己也发送一个SYN包(SYN&＃61;k)&＃xff0c;即SYN&＃43;ACK包&＃xff0c;此时服务器B进入SYN_RECV状态。

(3)第三次握手&＃xff1a;客户端A收到服务器B的SYN&＃xff0b;ACK包&＃xff0c;向服务器B发送确认包ACK(ACK&＃61;k&＃43;1)&＃xff0c;此包发送完毕&＃xff0c;客户端A和服务器B进入ESTABLISHED状态&＃xff0c;完成三次握手。

完成三次握手&＃xff0c;客户端与服务器开始传送数据。

二、4次挥手

当客户端和服务器通过三次握手建立了TCP连接以后&＃xff0c;当数据传送完毕&＃xff0c;肯定是要断开TCP连接的啊。那对于TCP的断开连接&＃xff0c;这里就有了神秘的“四次分手”。

1. 第一次分手&＃xff1a;主机1(可以使客户端&＃xff0c;也可以是服务器端)&＃xff0c;设置Sequence Number和Acknowledgment Number&＃xff0c;向主机2发送一个FIN报文段&＃xff1b;此时&＃xff0c;主机1进入FIN_WAIT_1状态&＃xff1b;这表示主机1没有数据要发送给主机2了&＃xff1b;

2. 第二次分手&＃xff1a;主机2收到了主机1发送的FIN报文段&＃xff0c;向主机1回一个ACK报文段&＃xff0c;Acknowledgment Number为Sequence Number加1&＃xff0c;主机2进入CLOSE_WAIT状态&＃xff1b;主机1进入FIN_WAIT_2状态&＃xff1b;主机2告诉主机1&＃xff0c;我“同意”你的关闭请求&＃xff1b;

3. 第三次分手&＃xff1a;主机2向主机1发送FIN报文段&＃xff0c;请求关闭连接&＃xff0c;同时主机2进入LAST_ACK状态&＃xff1b;

4. 第四次分手&＃xff1a;主机1收到主机2发送的FIN报文段&＃xff0c;向主机2发送ACK报文段&＃xff0c;然后主机1进入TIME_WAIT状态&＃xff1b;主机2收到主机1的ACK报文段以后&＃xff0c;就关闭连接&＃xff1b;此时&＃xff0c;主机1等待2MSL后依然没有收到回复&＃xff0c;则证明Server端已正常关闭&＃xff0c;那好&＃xff0c;主机1也可以关闭连接了。

FIN_WAIT_1: 这个状态要好好解释一下&＃xff0c;其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是&＃xff1a;FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时&＃xff0c;它想主动关闭连接&＃xff0c;向对方发送了FIN报文&＃xff0c;此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后&＃xff0c;则进入到FIN_WAIT_2状态&＃xff0c;当然在实际的正常情况下&＃xff0c;无论对方何种情况下&＃xff0c;都应该马上回应ACK报文&＃xff0c;所以FIN_WAIT_1状态一般是比较难见到的&＃xff0c;而FIN_WAIT_2状态还有时常常可以用netstat看到。(主动方)

FIN_WAIT_2&＃xff1a;上面已经详细解释了这种状态&＃xff0c;实际上FIN_WAIT_2状态下的SOCKET&＃xff0c;表示半连接&＃xff0c;也即有一方要求close连接&＃xff0c;但另外还告诉对方&＃xff0c;我暂时还有点数据需要传送给你(ACK信息)&＃xff0c;稍后再关闭连接。(主动方)

CLOSE_WAIT&＃xff1a;这种状态的含义其实是表示在等待关闭。怎么理解呢&＃xff1f;当对方close一个SOCKET后发送FIN报文给自己&＃xff0c;你系统毫无疑问地会回应一个ACK报文给对方&＃xff0c;此时则进入到CLOSE_WAIT状态。接下来呢&＃xff0c;实际上你真正需要考虑的事情是察看你是否还有数据发送给对方&＃xff0c;如果没有的话&＃xff0c;那么你也就可以 close这个SOCKET&＃xff0c;发送FIN报文给对方&＃xff0c;也即关闭连接。所以你在CLOSE_WAIT状态下&＃xff0c;需要完成的事情是等待你去关闭连接。(被动方)

LAST_ACK: 这个状态还是比较容易好理解的&＃xff0c;它是被动关闭一方在发送FIN报文后&＃xff0c;最后等待对方的ACK报文。当收到ACK报文后&＃xff0c;也即可以进入到CLOSED可用状态了。(被动方)

TIME_WAIT:表示收到了对方的FIN报文&＃xff0c;并发送出了ACK报文&＃xff0c;就等2MSL后即可回到CLOSED可用状态了。如果FINWAIT1状态下&＃xff0c;收到了对方同时带FIN标志和ACK标志的报文时&＃xff0c;可以直接进入到TIME_WAIT状态&＃xff0c;而无须经过FIN_WAIT_2状态。(主动方)

CLOSED:表示连接中断。

三、TCP所有状态

LISTEN,SYN_SENT,SYN_RECV,ESTABLISHED

FIN_WAIT1,CLOSE_WAIT,FIN_WAIT2,LAST_ACK,TIME_WAIT,CLOSE

1、LISTENING状态

FTP服务启动后首先处于侦听(LISTENING)状态。

2、ESTABLISHED状态

ESTABLISHED的意思是建立连接。表示两台机器正在通信。

3、CLOSE_WAIT

对方主动关闭连接或者网络异常导致连接中断&＃xff0c;这时我方的状态会变成CLOSE_WAIT 此时我方要调用close()来使得连接正确关闭

4、TIME_WAIT

我方主动调用close()断开连接&＃xff0c;收到对方确认后状态变为TIME_WAIT。TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)&＃xff0c;以此来确保旧的连接状态不会对新连接产生影响。处于TIME_WAIT状态的连接占用的资源不会被内核释放&＃xff0c;所以作为服务器&＃xff0c;在可能的情况下&＃xff0c;尽量不要主动断开连接&＃xff0c;以减少TIME_WAIT状态造成的资源浪费。

四&＃xff64;TCP重要状态

4.1 SYN_RECV

服务端收到建立连接的SYN没有收到ACK包的时候处在SYN_RECV状态。有两个相关系统配置&＃xff1a;

1&＃xff0c;net.ipv4.tcp_synack_retries &＃xff1a;INTEGER

默认值是5

对于远端的连接请求SYN&＃xff0c;内核会发送SYN &＃xff0b; ACK数据报&＃xff0c;以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN&＃43;ACK 数目。不应该大于255&＃xff0c;默认值是5&＃xff0c;对应于180秒左右时间。通常我们不对这个值进行修改&＃xff0c;因为我们希望TCP连接不要因为偶尔的丢包而无法建立。

2&＃xff0c;net.ipv4.tcp_synCOOKIEs

一般服务器都会设置net.ipv4.tcp_synCOOKIEs&＃61;1来防止SYN Flood攻击。假设一个用户向服务器发送了SYN报文后突然死机或掉线&＃xff0c;那么服务器在发出SYN&＃43;ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)&＃xff0c;这种情况下服务器端一般会重试(再次发送SYN&＃43;ACK给客户端)并等待一段时间后丢弃这个未完成的连接&＃xff0c;这段时间的长度我们称为SYN Timeout&＃xff0c;一般来说这个时间是分钟的数量级(大约为30秒-2分钟)。

这些处在SYNC_RECV的TCP连接称为半连接&＃xff0c;并存储在内核的半连接队列中&＃xff0c;在内核收到对端发送的ack包时会查找半连接队列&＃xff0c;并将符合的requst_sock信息存储到完成三次握手的连接的队列中&＃xff0c;然后删除此半连接。大量SYNC_RECV的TCP连接会导致半连接队列溢出&＃xff0c;这样后续的连接建立请求会被内核直接丢弃&＃xff0c;这就是SYN Flood攻击。

能够有效防范SYN Flood攻击的手段之一&＃xff0c;就是SYN COOKIE。SYN COOKIE原理由D. J. Bernstain和 Eric Schenk发明。SYN COOKIE是对TCP服务器端的三次握手协议作一些修改&＃xff0c;专门用来防范SYN Flood攻击的一种手段。它的原理是&＃xff0c;在TCP服务器收到TCP SYN包并返回TCP SYN&＃43;ACK包时&＃xff0c;不分配一个专门的数据区&＃xff0c;而是根据这个SYN包计算出一个COOKIE值。在收到TCP ACK包时&＃xff0c;TCP服务器在根据那个COOKIE值检查这个TCP ACK包的合法性。如果合法&＃xff0c;再分配专门的数据区进行处理未来的TCP连接。

观测服务上SYN_RECV连接个数为&＃xff1a;7314&＃xff0c;对于一个高并发连接的通讯服务器&＃xff0c;这个数字比较正常。

4.2 CLOSE_WAIT

发起TCP连接关闭的一方称为client&＃xff0c;被动关闭的一方称为server。被动关闭的server收到FIN后&＃xff0c;但未发出ACK的TCP状态是CLOSE_WAIT。出现这种状况一般都是由于server端代码的问题&＃xff0c;如果你的服务器上出现大量CLOSE_WAIT&＃xff0c;应该要考虑检查代码。

4.3 TIME_WAIT

根据TCP协议定义的3次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态。TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟&＃xff0c;即240秒。TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接&＃xff0c;将导致服务器端存在大量的处于TIME_WAIT状态的socket&＃xff0c; 甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力&＃xff0c;甚至耗尽可用的socket&＃xff0c;停止服务。

5&＃xff64; 为什么需要TIME_WAIT&＃xff1f;

TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证。

原因有二&＃xff1a;

一、保证TCP协议的全双工连接能够可靠关闭

二、保证这次连接的重复数据段从网络中消失

和TIME_WAIT状态有关的系统参数有一般由3个&＃xff0c;常规设置如下&＃xff1a;

net.ipv4.tcp_tw_recycle &＃61; 1

net.ipv4.tcp_tw_reuse &＃61; 1

net.ipv4.tcp_fin_timeout &＃61; 30

net.ipv4.tcp_fin_timeout&＃xff0c;默认60s&＃xff0c;减小fin_timeout&＃xff0c;减少TIME_WAIT连接数量。

net.ipv4.tcp_tw_reuse &＃61; 1表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接&＃xff0c;默认为0&＃xff0c;表示关闭&＃xff1b;

net.ipv4.tcp_tw_recycle &＃61; 1表示开启TCP连接中TIME-WAIT sockets的快速回收&＃xff0c;默认为0&＃xff0c;表示关闭。

五、常用命令

1、windows 查看端口连接状态

C:\Users\Administrator>netstat -an|findstr 80|findstr TCP

2、linux

查看tcp各个连接状态的数量

TCP连接的情况&＃xff0c;统计命令&＃xff1a;

netstat -n | awk &＃39;/^tcp/ {&＃43;&＃43;S[$NF]} END {for(a in S) print a, S[a]}&＃39;

统计8080端口上有多少个TCP连接

netstat –tan | grep 8080 | wc –l

TCP连接中有多少个连接状态是ESTABLISHED

netstat –tan | grep 8080 | grep ESTABLISHED| wc -l

TCP连接中有多少个连接状态是CLOSE_WAIT

netstat –tan | grep 8080 | grep CLOSE_WAIT| wc -l

TCP连接中有多少个连接状态是TIME_WAIT

netstat –tan | grep 8080 | grep TIME_WAIT| wc -l

参考&＃xff1a;