TCP/UDP

| 标签 tcp  udp  syn  ack  fin  rst  psh  浏览次数: -
特点 TCP UDP
连接性 面向连接 面向非连接
可靠性 可靠 不可靠
传输效率

标识

  • SYN: 表示建立连接
  • FIN: 表示关闭连接
  • ACK: 表示响应
  • PSH: 表示有 DATA数据传输
  • RST: 表示连接重置

TCP

  • 概念

是一种面向连接的、可靠的、基于字节流的传输层通信协议。是专门为了在不可靠的互联网络上提供一个可靠的端到端字节流而设计的,面向字节流。 TCP 是通过重传、确认和校验和的方式来确保可靠

UDP

  • 概念

(用户数据报协议)是iso参考模型中一种无连接的传输层协议,提供面向操作的简单不可靠的非连接传输层服务,面向报文。

三次握手

三次握手的详述

首先Client端发送连接请求报文,Server段接受连接后回复ACK报文,并为这次连接分配资源。Client端接收到ACK报文后也向Server段发生ACK报文,并分配资源,这样TCP连接就建立了。

TCP三次握手

  • 第一次握手

起初客户端、服务端都处理CLOSED关闭状态,客户端发送一个tcp的syn(同步位, syn=1的报文不能携带数据)标志位置为1的包(连接请求)并随机产生一个值(seq=x 初始序号)给服务端,客户端进入SYN-SENT(同步已发送)状态。

  • 第二次握手

服务端收到数据包后由标志位SYN=1得知客户端请求建立连接,服务端将标志位SYN和ACK都置为1,ack=x+1(确认号),随机产生一个值seq=y,并将改数据包发送给客户端确认连接请求,服务端进入SYN-RCVD(同步收到)状态,此时操作系统为该TCP连接分配缓存和变量。

  • 第三次握手

客户端收到服务器的授予连接请求之后,检查ack是否为x+1,ACK是否为1,正确则将标志位、ACK置为1,ack=y+1,此时操作系统为该TCP连接分配TCP缓存和变量,并将该数据包发送给服务端,服务端检查ack是否为y+1,ACK是否为1,正确则连接建立成功,服务端和客户端进入ESTABLISHED(已建立连接)状态,完成三次握手,随后Client和Server就可以开始传输数据。

三次握手原因

主要为了防止已失效的连接请求报文段突然又传送到了B,因而产生错误。如A发出连接请求,但因连接请求报文丢失而未收到确认,于是A再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,A工发出了两个连接请求报文段,其中第一个丢失,第二个到达了B,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达B,此时B误认为A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接,不采用三次握手,只要B发出确认,就建立新的连接了,此时A不理睬B的确认且不发送数据,则B一致等待A发送数据,浪费资源。

Server端易受到SYN攻击?

服务器端的资源分配是在二次握手时分配的,而客户端的资源是在完成三次握手时分配的,所以服务器容易受到SYN洪泛攻击,SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server则回复确认包,并等待Client确认,由于源地址不存在,因此Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络拥塞甚至系统瘫痪。

  • 防范SYN攻击措施

降低主机的等待时间使主机尽快的释放半连接的占用,短时间受到某IP的重复SYN则丢弃后续请求。

四次挥手

数据传输结束后,通信的双方都可释放连接,A和B都处于ESTABLISHED状态。(A、B连接建立状态ESTABLISHED——A终止等待1状态FIN-WAIT-1——B关闭等待状态CLOSE-WAIT——A终止等待2状态FIN-WAIT-2——B最后确认状态LAST-ACK——A时间等待状态TIME-WAIT——B、A关闭状态CLOSED)

TCP四次挥手

  • 1.A的应用进程先向其TCP发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN-WAIT-1(终止等待1)状态,等待B的确认。
  • 2.B收到连接释放报文段后即发出确认报文段,(ACK=1,确认号ack=u+1,序号seq=v),B进入CLOSE-WAIT(关闭等待)状态,此时的TCP处于半关闭状态,A到B的连接释放。
  • 3.A收到B的确认后,进入FIN-WAIT-2(终止等待2)状态,等待B发出的连接释放报文段。
  • 4.B没有要向A发出的数据,B发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),B进入LAST-ACK(最后确认)状态,等待A的确认。
  • 5.A收到B的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),A进入TIME-WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,A才进入CLOSED状态。

为什么A在TIME-WAIT状态必须等待2MSL的时间?

MSL最长报文段寿命Maximum Segment Lifetime,MSL=2

  • 1.保证A发送的最后一个ACK报文段能够到达B。
  • 2.防止“已失效的连接请求报文段”出现在本连接中。

1)这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,B超时重传FIN+ACK报文段,而A能在2MSL时间内收到这个重传的FIN+ACK报文段,接着A重传一次确认,重新启动2MSL计时器,最后A和B都进入到CLOSED状态,若A在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到B重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则B无法正常进入到CLOSED状态。 2)A在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。

为什么连接的时候是三次握手,关闭的时候却是四次握手?

因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

对比

  • 1、tcp是基于连接的,可靠性高;udp是基于无连接的,可靠性较低;
  • 2、由于tcp是连接的通信,需要有三次握手、重新确认等连接过程,会有延时,实时性差;同时过程复杂,也使其易于被攻击;而udp无连接,无建立连接的过程,因而实时性较强,也稍安全;
  • 3、在传输相同大小的数据时,tcp首部开销20字节;udp首部开销只有8个字节,tcp报头比udp复杂,故实际包含的用户数据较少。tcp无丢包,而udp有丢包,故tcp开销大,udp开销较小;
  • 4、每条tcp连接只能是点到点的;udp支持一对一、一对多、多对一、多对多的交互通信。

结论

  • 如果对实时性要求高和高速传输的场合下需要使用udp;如果需要传输大量数据且对可靠性要求高的情况下应该使用tcp;在可靠性要求较低,追求效率的情况下应该使用udp。

参考

TCP三次握手和四次挥手过程


上一篇 snakefood分析python依赖     下一篇 更新PSU
目录导航