网络传输协议TCP和UDP
TCP与UDP的区别
- TCP面向连接的,传输数据时,需要进行三次握手建立连接。UDP是无连接的,发送数据之前不需建立连接
- TCP通过确认和重传机制,提供可靠的服务。即通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达,而UDP不保证可靠传输,只是尽可能得交付
- TCP面向字节流,而将数据看成一连串无结构的字节流。UDP是面向报文的,UDP没有拥塞控制,因此网络出现拥塞不会使源主机发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
- 每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一,多对多的交互通信
- TCP的逻辑通信信道是全双工的可靠信道,UDP是不可靠信道
TCP的三次握手和四次挥手
三次握手
置位概念:根据TCP的包头字段,存在3个重要的标识ACK、SYN、FIN
ACK:表示验证字段 SYN:位数置1,表示建立TCP连接 FIN:位数置1,表示断开TCP连接
- 由客户端发送建立TCP连接的请求报文,其中报文中包含seq序列号,是由发送端随机生成的,并且将报文中的SYN字段置为1,表示需要建立TCP连接。(SYN=1,seq=x,x为随机生成数值)
- 由服务端回复客户端发送的TCP连接请求报文,其中包含seq序列号,是由回复端随机生成的,并且将SYN置为1,而且会产生ACK字段,ACK字段数值是在客户端发送过来的序列号seq的基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP建立请求已得到验证。(SYN=1,ACK=x+1,seq=y,y为随机生成数值)这里的ack加1可以理解为是确认和谁建立连接。
- 客户端收到服务端发送的TCP建立验证请求后,会使自己的序列号加1表示,并且再次回复ACK验证请求,在服务端发过来的seq上加1进行回复。(SYN=1,ACK=y+1,seq=x+1)
四次挥手过程说明:
- 客户端发送断开TCP连接请求的报文,其中报文中包含seq序列号,是由发送端随机生成的,并且还将报文中的FIN字段置为1,表示需要断开TCP连接。(FIN=1,seq=x,x由客户端随机生成)
- 服务端会回复客户端发送的TCP断开请求报文,其包含seq序列号,是由回复端随机生成的,而且会产生ACK字段,ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复,以便客户端收到信息时,知晓自己的TCP断开请求已经得到验证。(FIN=1,ACK=x+1,seq=y,y由服务端随机生成)
- 服务端在回复完客户端的TCP断开请求后,不会马上进行TCP连接的断开,服务端会先确保断开前,所有传输到A的数据是否已经传输完毕,一旦确认传输数据完毕,就会将回复报文的FIN字段置1,并且产生随机seq序列号。(FIN=1,ACK=x+1,seq=z,z由服务端随机生成)
- 客户端收到服务端的TCP断开请求后,会回复服务端的断开请求,包含随机生成的seq字段和ACK字段,ACK字段会在服务端的TCP断开请求的seq基础上加1,从而完成服务端请求的验证回复。(FIN=1,ACK=z+1,seq=h,h为客户端随机生成)
至此TCP断开的4次挥手过程完毕
11种状态
三次握手图解
- 一开始,建立连接之前服务器和客户端的状态都为CLOSED;
- 服务器创建socket后开始监听,变为LISTEN状态;
- 客户端请求建立连接,向服务器发送SYN报文,客户端的状态变为SYN_SENT;
- 服务器收到客户端的报文后向客户端发送ACK和SYN报文,此时服务器的状态变为SYN_RCVD;
- 然后,客户端收到ACK、SYN,就向服务器发送ACK,客户端状态变为ESTABLISHED;
- 服务器端收到客户端的ACK后变为ESTABLISHED。此时3次握手完成,连接建立!
四次挥手
由于TCP连接是全双工的,断开连接会比建立连接麻烦一点点。
- 客户端先向服务器发送FIN报文,请求断开连接,其状态变为FIN_WAIT1;
- 服务器收到FIN后向客户端发送ACK,服务器的状态围边CLOSE_WAIT;
- 客户端收到ACK后就进入FIN_WAIT2状态,此时连接已经断开了一半了。如果服务器还有数据要发送给客户端,就会继续发送;
- 直到发完数据,就会发送FIN报文,此时服务器进入LAST_ACK状态;
- 客户端收到服务器的FIN后,马上发送ACK给服务器,此时客户端进入TIME_WAIT状态;
- 再过了2MSL长的时间后进入CLOSED状态。服务器收到客户端的ACK就进入CLOSED状态。
至此,还有一个状态没有出来:CLOSING状态。
CLOSING状态表示: 客户端发送了FIN,但是没有收到服务器的ACK,却收到了服务器的FIN,这种情况发生在服务器发送的ACK丢包的时候,因为网络传输有时会有意外。
• LISTEN:等待从任何远端TCP 和端口的连接请求。
• SYN_SENT:发送完一个连接请求后等待一个匹配的连接请求。
• SYN_RECEIVED:发送连接请求并且接收到匹配的连接请求以后等待连接请求确认。
• ESTABLISHED:表示一个打开的连接,接收到的数据可以被投递给用户。连接的数据传输阶段的正常状态。
• FIN_WAIT_1:等待远端TCP 的连接终止请求,或者等待之前发送的连接终止请求的确认。
• FIN_WAIT_2:等待远端TCP 的连接终止请求。
• CLOSE_WAIT:等待本地用户的连接终止请求。
• CLOSING:等待远端TCP 的连接终止请求确认。
• LAST_ACK:等待先前发送给远端TCP 的连接终止请求的确认(包括它字节的连接终止请求的确认)
• TIME_WAIT:等待足够的时间过去以确保远端TCP 接收到它的连接终止请求的确认。
• TIME_WAIT 两个存在的理由:
• 可靠的实现tcp全双工连接的终止;
• 允许老的重复分节在网络中消逝。
• CLOSED:不在连接状态(这是为方便描述假想的状态,实际不存在)
TCP流量控制
流量控制
如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。流量控制策略就是控制发送者的发送速度,使得接收者来得及接收,达到不丢失分组的目的。流量控制是构成TCP可靠性的一方面
流量控制主要使用滑动窗口机制实现。下面以上图讲解滑动窗口(也叫接受窗口rwnd)的细节
主机A向主机B发送数据,开始双方确定的窗口值为400字节,这两个是前提条件。开始A发送了200字节,之后发生了分组丢失现象,B调整接受窗口大小为300字节。之后A又连续发送了300字节。此时A已经不能发送数据,需等待B的窗口信号。之后B调整窗口为100字节。接收到100字节数据后,调整窗口值为0,表示暂时不想接受数据。总共B调整了三次窗口大小,进行了三次流量控制
假如,B向A发送了零窗口的报文段后不久,B的接收缓存又有了一些存储空间。于是B向A发送了rwind=400的报文段,然而这个报文段在传送中丢失 了。A一直等待收到B发送的非零窗口的通知,而B也一直等待A发送的数据。这样就死锁了。为了解决这种死锁状态,TCP为每个连接设有一个持续计时器。只 要TCP连接的一方收到对方的零窗口通知,就启动持续计时器,若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。
TCP拥塞控制
拥塞的概念:
在某段时间,对网络中的某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变化,这种情况叫拥塞。网络拥塞往往是由许多因素引起的,简单的提高节点处理机的速度或者扩大结点缓存的存储空间并不能解决拥塞问题。拥塞问题的是指往往是整个系统的各个部分不匹配,只有各个部分平衡了,问题才会得到解决。
拥塞控制:
防止过多的数据注入到网络,导致网络中的路由器或链路过载。
流量控制和拥塞控制的区别:
可以看出流量控制是一个端到端的问题,而拥塞控制是一个全局性问题,设计到所有的主机、所有的路由器。
慢开始:乘法增加
发送方维持一个拥塞窗口cwnd,大小取决于网络的拥塞程度,动态地在变化。发送窗口小于等于拥塞窗口,而发送窗口一定不能超过接收窗口。发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就增大一些,以便把更多的分组发送出去。但是只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络的分组数。
开始时,如果发送大量数据包,容易导致网络中路由器缓冲空间耗尽,从而发生拥塞。所以新建连接时,cwnd初始化为1个最大报文段(MSS)大小,每经过一个迭代,拥塞窗口就乘以2,所以也称为乘法增加阶段。拥塞窗口不可能一直增大,所以一般会设置一个慢开始门限ssthresh.
当cwnd<ssthresh时,使用慢开始算法。
当cwnd>ssthresh时,改用拥塞避免算法。
拥塞避免:加法增大
一旦达到慢开始的初始门限ssthresh,就进入了拥塞避免阶段。每一个迭代,拥塞窗口加1,而不是加一倍
快重传
快重传算法规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。快重传策略是为了防止TCP连接因等待重传计时器超时而空闲较长的时间。
快恢复
快重传和快恢复是搭配使用的,快重传完成后,立即执行快恢复算法。将ssthresh门限设置为当前拥塞窗口的一半,之后将拥塞窗口设置为新的ssthresh门限(即减半), 进入拥塞避免阶段。
这里可能会有人有疑问,为什么不直接进入慢开始阶段,更彻底得避免拥塞。主要的原因是考虑到如果网络出现拥塞得话,就不会收到多次重复确认,所以发送方认为网络可能没有出现拥塞,所以不执行慢开始算法,而是将cwnd设置为新得ssthresh门限,执行拥塞避免算法
参考链接 https://www.cnblogs.com/wxgblogs/p/5616829.html