画出TCP的4次挥手过程,为什么需要四次,不能三次吗
根据协议,当接收到对方的FIN包后,TCP需要发送ACK进行确认,但是不能将FIN与ACK一并发送,因为在发送FIN前需要将buffer区域的包先发送完毕之后才能够发送FIN包,此时对方仍可以继续发送ACK包,待全部包确认对方收到后才能发送FIN包,保证所有数据传输完整。
解释一下TCP的TIME-WAIT,为什么取值为2MSL?
在四次挥手中,发起FIN的一端在接收到对方的ACK,接收到对方的FIN包后会发送ACK确认对方的FIN,并且进入TIME-WAIT状态,此状态下等待2MSL后将会结束连接。如果对方在发送FIN包2MSL后(发送MSL+接收MSL=2MSL时间长度)没有收到ACK,将会重发FIN包,对于本方而言,同样地发送ACK最长为MSL时间+接收对方没有收到ACK而重发FIN包最长也是MSL时间,因此为2MSL。
如果服务端中存在大量的TIME-WAIT请分析下原因
由于提出FIN的一方在发送完ACK后进入TIME-WAIT状态,是不会再收到任何响应信息,此时TCP需要等待2MSL时间之后关闭连接。如果存在大量TIME-WAIT状态,则说明有很多时长<2MSL的连接建立和断开。如果一个连接时长<2MSL,它在一个2MSL的周期内建立和断开的话必然会导致重叠的时间窗,这个时间窗内就会出现重复的TIME-WAIT状态。
TCP 的三次握手是哪三次
第一次:
发起连接一方发送SYN报文,处于SYN-SENT状态。
第二次:
接收方发送ACK报文,确认收到的SYN,并且发送SYN报文建立连接,处于SYN-RECEIVED状态。
第三次:
发起方收到ACK报文,处于ESTABLISHED状态,并且收到对方的SYN请求,发送ACK报文确认对方的请求;接收方收到ACK后处于ESTABLISHED状态。
为什么需要第三次握手,没有第三次握手会有什么问题吗
如果没有第三次握手,接收方处于SYN-RECEIVED状态,发送方接收到了ACK,处于ESTABLISHED状态,此时如果协议规定不需要第三次握手,那么发送方开始发送数据(正常状态下),接收方正常接收。但是如果没有三次握手,也就是发送方SYN+接收方ACK建立连接,此时可以确认发送方发往接收方的报文是可以正常发送接收,但是无法确定接收方发给发送方的报文是否能够正常接收。因此仍需要第三次握手,需要发送方响应才能够确保连接双方能够发送和接收对方的报文。
拥塞控制以及里面的算法?流量控制的协议?
流量控制:让对方能够直到自己可以接收的数据大小,发送端就会发送不超过这个限度(窗口大小)的数据。在TCP首部中有对应字段存放窗口大小的数值,当缓冲区面临数据溢出时,窗口大小就会被设置成一个更小的值告知发送方;当缓冲区大小为0时,缓冲区满的状态下接收端不会响应会延迟,此时接收方在超过重发超时时间后,会发送一个窗口探测包(仅含一个字节),若接收方缓冲区满,继续返回窗口大小0,发送方继续等待至重发超时时间;若窗口大小不为0,则按照窗口大小发送数据包。
拥堵控制:拥堵控制是为了避免启动时发送大量数据,定义了拥塞窗口的概念,大小为1MSS,每次收到一个ACK,窗口大小就会翻倍,这样从启动到正常发送数据窗口会变得越来大,并且取拥塞窗口和流量窗口的较小值。当发生超时重发时,拥塞窗口重置为1MSS,进行慢启动修正,减少连续发包导致的网络拥塞。同时,为了避免窗口大小指数增长,规定慢启动阈值,超过阈值后窗口大小增长只能以MSS * MSS / 窗口大小的比例放大,因此后续放大比例将小于一个MSS长度。
初始化时,阈值不定;发生超时重发后阈值会被设定为拥塞窗口的一半大小;在高速重发时会将窗口大小设置为当前窗口的一半,并将阈值设置为窗口大小+3MSS。
TCP报头格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TCP Header Format
UDP报头格式
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
User Datagram Header Format
TCP/UDP区别
TCP用于实现可靠传输,通过应答确认、顺序控制、重发等机制实现可靠传输;UDP用于高速传输和对实时性有要求的通信。