-
TCP三次握手
首先三次握手的目的是为了在客户端和服务器端建立连接。第一次握手:客户端发送syn包(syn=j)到服务器端,进入syn_sent状态。(syn同步序列编号)
第二次握手:服务器收到syn包,必须确认用户的syn(ack=j+1),同时自己也要发送一个syn包 (syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕, 客户端和服务器端进入ESTABLISHED(TCP连接成功)状态,完成三次握手。 -
为什么ack返回值是seq+1
实际是确认收到的序列,并告诉发送端,下次发送的序列号从哪开始。 -
能不能两次握手?为什么?
不能。两次握手会使得已经失效的连接请求报文再次建立连接,造成错误以及不必要的资源浪费。
客户端发送给服务器端的请求连接报文可能没有丢失,只是在网络节点滞留时间过长。
当客户端没有收到服务器端的确认包时,以为服务器没有收到,客户端会再次发送报文,并且建立连接,完成数据的传输。
如果已经失效的请求报文最终还是到达了服务器端,服务器端向客户端发送确认包,两者建立连接,会造成资源的不必要的浪费。
而如果是三次握手,服务器端向客户端发送连接请求时,客户端不会发送确认包,服务器端就知道客户端没有请求了。 -
为什么TCP要三次握手?两次行不行?
不行。TCP三次握手就是客户端和服务器端互相告知对方的序列起始号,并确认对方已经收到序列号起始值。如果只有两次,服务器端的序列号无法得到确认。 -
三次握手的最后一次丢失会发生什么?
服务器端没有收到客户端的ack确认包,服务器会根据TCP的超时重传机制,依次等待3,6,12秒重新发送syn/ack数据包到客户端,如果发送完之后还是没有收到客户端的ack确认包,就关闭此次连接。 客户端以为连接已经建立,当发送数据到服务器时,服务器会发送RST包到客户端,客户端就知道第三次握手失败。 -
请你说一下TCP断连过程,以及单向连接关闭后还能否通信
四次挥手过程:
客户端A向服务器B发送FIN,用来关闭客户端到服务器端的数据发送;
服务器B接收到客户端A发来的FIN包后,向客户端发送确认包ACK;
等待一段(wait)时间之后,服务器向客户端发送FIN包,表示关闭服务器到客户端的数据发送;
客户端接收到服务器端的FIN包之后,发送ACK确认包。
等待2MSL之后,连接断开。 -
为什么要进行四次挥手
三次握手时是将syn和ack放在一个报文中发送;
而四次挥手时,当接收到对方的FIN时,仅表示对方没有数据发送,而服务器端可能有数据进行发送,因此只是先发回一个确认报文ACK,等自己数据发送完毕之后,在发送FIN到客户端。 -
为什么TCP挥手每两次之间有一个wait等待时间
主动关闭的一方调用完close之后,进入wait状态。如果这时候网络突然断开,主动关闭的一方接收不到来自被动关闭方的断开连接请求,就需要一个定时器,如果定时器超时还是没收到来自被动方发送的FIN,就直接释放这个连接。 -
为什么客户端最后还要等待2MSL,为什么还有个TIME-wait的时间等待?
(1) 确保主动方发送的ACK报文发送成功。
如果主动方发送的ACK报文被动方没有收到,被动方会重新发送ACK+FIN报文,主动方就会在2MSL时间段内收到这个重传报文,给出回应。
(2)为了保证在新的连接请求中不会出现旧的连接请求报文。
客户端发送完ACK报文之后,在这个时间内可以使本次连接时间内产生的所有请求报文段都从网络中消失。 -
如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75s发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。 -
Tcp如果有大量的time-wait怎么处理
一个TCP/IP连接断开以后,会通过TIME_WAIT的状态保留一段时间,时间过了才会释放这个端口,当端口接受的频繁请求数量过多的时候,就会产生大量的TIME_WAIT状态的连接,这些连接占着端口,会消耗大量的资源。面对这种情况 可以通过修改TCP/IP的内核参数,来及时的处理这些状态。
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’