"Advanced code slag" - computer network --TCP

1. TCP Transmission Control Protocol:

报头:

Here Insert Picture Description
To establish a connection: three-way handshake
1. TCP server process to create a Transmission Control Block TCB, always ready to accept connection requests from the client process, the server at this time to enter the LISTEN (monitor) state
2. TCP client process is to create a transmission control block the TCB, and then issues a connection request packet to the server, and the synchronization flag bit packet header of the SYN = 1, while selecting an initial sequence number seq = x, In this case, TCP client process enters the SYN-sENT (sent synchronous state) state. TCP predetermined, the SYN segment (SYN = 1 segment) can not carry data, but requires a number consumed.
3. After the TCP server receives the request message, if you agree connections, it is a confirmation message. Acknowledgment packets ACK = 1, SYN = 1, an acknowledgment sequence number is x + 1, but also initializes a sequence number seq = y for itself, at this time, TCP server process passes to the SYN-RCVD (received synchronization) state . This message can not carry data, but also have to consume a number.
4. TCP client process after receiving confirmation yet, the server would like to give confirmation. Acknowledgment message ACK = 1, an acknowledgment sequence number is y + 1, its own serial number. 1 is + X.
. 5. At this time, TCP connection is established, the client enters ESTABLISHED (established connection) state. When the server receives confirmation client also enters ESTABLISHED state, then the two sides can start the communication.

断开连接:四次挥手
	1。客户端进程发出连接释放报文,并且停止发送数据。
	释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
	2。服务器收到连接释放报文,发出确认报文,ACK=1,确认序号为 u+1,并且带上自己的序列号seq=v,此时服务端就进入了CLOSE-WAIT(关闭等待)状态。
	TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
	3。客户端收到服务器的确认请求后,此时客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最终数据)
	4。服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,确认序号为v+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
	5。客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,确认序号为w+1,而自己的序列号是u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
	6。服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
	
为什么要三次握手和四次挥手?
	自己通过收到的回应来确保对方收到了自己的消息。
	
	形象的三次握手:(打电话场景)
		1。客:你好?(客:它有没有听见我的声音啊?服:这谁啊?)
		2。服:你好!(服:客户能听见吗?喂喂??客:原来没死所)
		3。客:哦哦原来你在啊!......噼里啪啦......(服:哦哦它听见了,那么开始接受数据)
		
	形象的四次挥手:(打电话场景)
		1。客:好了我说完了。(客:它晓得我不说了吗?服:哦它说完了)
		2。服:那你闭嘴吧。......(客:明知道我不说了它还噼里啪啦)
		3。服:好了我也说完了。(服:它晓得了不?客:终于不说了)
		4。客:我晓得了拜拜。(客:我说我晓得了它听到没有啊?服:啥子态度!挂断)此时客户端处于TIME_WAIT状态
		5。2×MSL之后(客:好嘛,它没有问说明它晓得了。挂断)
		
确认应答:
	每个字节都有自己的序号,每一个数据包发送之后都会有回应,发送端可以通过回应的编号知道接收端收到了哪些数据包。
	
超时重传:
	如果在特定的时间内没有收到确认应答的消息,就重传数据包,并且TCP是可以根据序号判断哪些 数据包是重复的,可以去重复。(但是这种方式太慢了,不适用)
	
滑动窗口:
	窗口:允许不接收确认应答就可以发送数据的最大值。
	滑动窗口:确认应答之后这个窗口就会向前滑动,操作系统会有一个缓冲区来记录哪些数据还没有发送,只有收到确认应答的数据才可以从缓冲区中去掉。
	
快重传:
	在滑动窗口的基础上,如果发送端连续接受到3个相同的确认应答,那么重传接收端需要的数据。
	因为有可能是因为网络拥塞导致接收端延迟收到数据包的。而接收端如果没有收到某确认应答,不重传,因为可能是确认应答丢失,可以通过后面序号的确认应答确认接收端已经收到数据包。

Here Insert Picture Description
Here Insert Picture Description
Flow control:
If the receiver receives too slow, to reduce the window size, slowing rate after the sender receives the transmission message, the receiving terminal if the buffer is full, to close the window, the sender periodically sends a probe packet (because the update notification window It may be lost, so the probes indicate the sender does not receive an update notification window), if you receive an update notification window will continue to send.

拥塞控制:
	判断网络拥塞:少量丢包就重传,大量丢包就是网络拥塞。
	控制:
		慢启动:
			先发送少量数据包,收到回应之后加大数据包的发送量,指数级增长,达到阈值之后按线性方式增长,发生网络拥塞之后重新慢开始并且阈值减小。
			
延迟应答:
	因为窗口是缓慢增大的,延迟一点点应答可以在应答的数据包中看到自己的窗口大小比较大,这样发送端发送数据就会快一点。
	
	
总结:
	保证可靠性的机制:
		序列号
		校验和
		确认应答
		超时重传
		流量控制
		拥塞控制
		
	提高性能的机制:
		滑动窗口
		快重传
		延迟应答
		
	计时器:
		TIME_WAIT
		超时重传定时器
		保活定时器
		
	和UDP对比:
		TCP可靠连接,主要用于可靠的文件传输上。

UDP connections are not reliable, mainly for high-speed real-time requirements and transmission scenarios.

Released nine original articles · won praise 4 · Views 132

Guess you like

Origin blog.csdn.net/qq_42661628/article/details/103996890