JAVASE基础之TCP挥手握手
2017-11-09 19:34
281 查看
Tcp三次握手
客户端: 请求链接 SYN包(SYN=x)发送到服务端,进入了SYN_SEND状态,等待服务器确认;
服务端: 收到SYN包,必须确认SYN包(ACK=X+1),同时自己也发送了一个SYN(SYN=y)即(SYN+ACK包),此时服务器进入SYN_RECV状态;
客户端: 收到了服务器的SYN+ACK包,向服务器发送ACK包(ACK=y+1),此包发送完毕,两者进入ESTABLISHED状态,客户端服务端完成三次握手。
tcp标志位有6种:
SYN(synchronous建立联机)
ACK(acknowledgement确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
各个状态:
LISTEN-侦听连接请求。
SYN-SENT-在发送请求连接后等待匹配的连接请求。
SYN-RECV-在收到和发送一个连接请求后等待确认。
ESTABLISHED-代表一个打开的连接,数据可以传送给用户。
FIN-WAIT-1-等待远程TCP的连接中断请求,或先前的连接中断请求的确认。
FIN-WAIT-2-从远程TCP等待连接中段请求。
CLOSE-WAIT-等待从本地用户发来的连接中断请求。
CLOSING-等待远程TCP对连接中断的确认。
LAST-ACK-等待原来发向远程TCP的连接中断请求的确认。
TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认。
CLOSED-没有任何连接状态
四次挥手:
(主动方可以是客户端也可以是服务端,这里拿客户端举例)
客户端(Fin报文):发送一个FIN,用来关闭客户到服务的数据传送。
服务端(Ack报文):收到这个FIN,它发回一个ACK,确认序号为收到的序号+1。和SYN一样,一个FIN占一个序号。此时进入半关闭状态,只能接受数据不能发送。
服务端(Fin报文):服务器关闭与客户端的连接,发送一个FIN给客户端。
客户端 (Ack报文):客户端发送ACK确认,并将序号+1。然后进入等待状态(TIME_WAIT)状态,等待2MSL后依然没有回复则正常关闭。
为什么两次握手不行?
假如客户端发出的连接请求没有收到服务端的确认,一段时间后,客户端又重新向服务端发送连接请求,且建立成功,顺序完成数据传输。但是客户端第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到服务端,服务端以为是客户端又发起的新连接,于是服务端同意连接,并向客户端发回确认,但是此时客户端根本不会理会,服务端就一直在等待客户端发送数据,导致服务点的资源浪费。
客户端: 请求链接 SYN包(SYN=x)发送到服务端,进入了SYN_SEND状态,等待服务器确认;
服务端: 收到SYN包,必须确认SYN包(ACK=X+1),同时自己也发送了一个SYN(SYN=y)即(SYN+ACK包),此时服务器进入SYN_RECV状态;
客户端: 收到了服务器的SYN+ACK包,向服务器发送ACK包(ACK=y+1),此包发送完毕,两者进入ESTABLISHED状态,客户端服务端完成三次握手。
tcp标志位有6种:
SYN(synchronous建立联机)
ACK(acknowledgement确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
各个状态:
LISTEN-侦听连接请求。
SYN-SENT-在发送请求连接后等待匹配的连接请求。
SYN-RECV-在收到和发送一个连接请求后等待确认。
ESTABLISHED-代表一个打开的连接,数据可以传送给用户。
FIN-WAIT-1-等待远程TCP的连接中断请求,或先前的连接中断请求的确认。
FIN-WAIT-2-从远程TCP等待连接中段请求。
CLOSE-WAIT-等待从本地用户发来的连接中断请求。
CLOSING-等待远程TCP对连接中断的确认。
LAST-ACK-等待原来发向远程TCP的连接中断请求的确认。
TIME-WAIT-等待足够的时间以确保远程TCP接收到连接中断请求的确认。
CLOSED-没有任何连接状态
四次挥手:
(主动方可以是客户端也可以是服务端,这里拿客户端举例)
客户端(Fin报文):发送一个FIN,用来关闭客户到服务的数据传送。
服务端(Ack报文):收到这个FIN,它发回一个ACK,确认序号为收到的序号+1。和SYN一样,一个FIN占一个序号。此时进入半关闭状态,只能接受数据不能发送。
服务端(Fin报文):服务器关闭与客户端的连接,发送一个FIN给客户端。
客户端 (Ack报文):客户端发送ACK确认,并将序号+1。然后进入等待状态(TIME_WAIT)状态,等待2MSL后依然没有回复则正常关闭。
为什么两次握手不行?
假如客户端发出的连接请求没有收到服务端的确认,一段时间后,客户端又重新向服务端发送连接请求,且建立成功,顺序完成数据传输。但是客户端第一次发送的连接请求并没有丢失,而是因为网络节点导致延迟达到服务端,服务端以为是客户端又发起的新连接,于是服务端同意连接,并向客户端发回确认,但是此时客户端根本不会理会,服务端就一直在等待客户端发送数据,导致服务点的资源浪费。
相关文章推荐
- Linux网络基础——TCP握手与挥手
- TCP基础知识(二)三次握手与四次挥手
- 应聘复习基础笔记1:网络编程之TCP与UDP的优缺点,TCP三次握手、四次挥手、传输窗口控制、存在问题
- 计算机网络基础(四)TCP协议中的三次握手和四次挥手(图解)
- 四、Linux网络编程-TCP/IP基础(四)传输层协议TCP、TCP报文格式、连接三次握手、终止四次挥手
- 网络基础---TCP(端口号,TCP段格式,常见定时器,握手与挥手)
- 【网络基础】TCP协议之三次握手和四次挥手
- 简要分析并搞懂9个tcp基础包------三次握手 + 发送数据并收到确认 + 四次挥手
- 网络基础之TCP三次握手与四次挥手
- TCP窗口、三次握手、四次挥手
- wireshark抓包图解 TCP三次握手/四次挥手详解
- TCP协议的三次握手四次挥手
- TCP的三次握手和四次挥手,及抓包分析工具推荐
- TCP协议中的三次握手和四次挥手(图解)
- TCP的三次握手和四次挥手
- tcp为什么要三次握手四次挥手
- TCP相关(控制位、3次握手、4次挥手、端口号分类TIME_WAIT状态...)
- TCP协议中的三次握手和四次挥手(图解)
- TCP协议中的三次握手和四次挥手(图解)
- TCP三次握手、四次挥手及中间的11种状态