《码渣的进阶》——计算机网络——TCP

1。TCP传输控制协议:

报头:

在这里插入图片描述
建立连接:三次握手
1。TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN(监听)状态
2。TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文,此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时,TCP客户端进程进入了 SYN-SENT(同步已发送状态)状态。TCP规定, SYN报文段(SYN=1的报文段)不能携带数据,但需要消耗掉一个序号。
3。TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD(同步收到)状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
4。TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1,确认序号是 y+1,自己的序列号是 x+1.
5。此时,TCP连接建立,客户端进入ESTABLISHED(已建立连接)状态。当服务器收到客户端的确认后也进入ESTABLISHED状态,此后双方就可以开始通信了。

断开连接:四次挥手
	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个相同的确认应答,那么重传接收端需要的数据。
	因为有可能是因为网络拥塞导致接收端延迟收到数据包的。而接收端如果没有收到某确认应答,不重传,因为可能是确认应答丢失,可以通过后面序号的确认应答确认接收端已经收到数据包。

在这里插入图片描述
在这里插入图片描述
流量控制:
如果接收端接收太慢,就缩小窗口大小,发送端收到信息之后减慢发送速度,如果接收端缓冲区满了,就关闭窗口,发送端定期发送探测数据包(因为窗口更新通知可能丢失,所以探测包表示发送端没有收到窗口更新通知),如果收到窗口更新通知则继续发送。

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

UDP不可靠连接,主要用于高速传输和实时性要求高的场景。

发布了9 篇原创文章 · 获赞 4 · 访问量 146
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览