TCP(Transmission Control Protoco)协议属于计算机网络体系中的运输层。运输层的任务是负责向主机中应用层进程之间的通信提供通用的数据传输服务。所以可以通俗理解TCP协议就是进程间数据通讯传输协议。根据不同应用,运输层主要使用TCP和UDP两种协议之一。
第一次握手:客户端TCP进程也先建立传输控制块TCB,然后向服务端发送连接请求报文段,此时SYN=1,随机选定一个初始序号seq=x,,此报文不能携带数据,但是要消耗掉一个序号,发送完毕后,客户端进入SYN-SENT(同步已发送)状态
第二次握手:服务端收到客户端请求连接报文段后,若同意建立连接,则发送确认报文,确认报文中SYN=1、ACK=1,确认号ack=x+1,同时随机选定一个自己序号seq=y,确认报文段同样不能携带数据,但是也要消耗掉一个序号,发送完毕后服务端进入SYN-RCVD(同步收到)状态
第三次握手:客户端收到确认报文后,检查ACK=1,ack=x+1是否正确,若正确,则向服务端发送确认报文,确认报文中ACK=1,ack=y+1,seq=x+1,发送后进入ESTAB-LISHED状态,服务端收到确认报文后,也进入ESTAB-LISHED状态,此时双方TCP连接正式建立。
假设现在TCP连接是两次握手机制,如下图server在收到client的连接请求,确认后就进入ESTAB-LISHED状态,会存在这样一种问题:
client发送连接请求报文,由于网络原因,长时间阻塞在某个网络节点上了,于是client重传了一次请求连接报文,第二次请求报文正常达到server,连接正常建立,数据传输完毕后,释放连接。但是假设此时第一次发送的请求报文并没有丢失,而是延误一段时间才到达server,这本是已失效的连接请求报文段,但是server收到后,会以为是client重新发送的连接请求,于是向client发送确认报文后,进入ESTAB-LISHED状态,但是client并没有发出新建连接的请求,就会忽略server的确认报文,server却在一直等待client发送数据,导致server资源浪费严重。
SCTP(Stream Control Transmission Protocol,流控制传输协议)是IETF(Internet Engineering Task Force,因特网工程任务组)在2000年定义的一个传输层(Transport Layer)协议,是提供基于不可靠传输业务的协议之上的可靠的数据报传输协议。SCTP的设计用于通过IP网传输SCN(Signaling Communication Network,信令通信网)窄带信令消息。后期广泛用于EPC网络中的S6a/S1/Sgs/Sv等接口中。
TCP接收端确认的是收到的字节数,SCTP接收端确认的是接收到的数据块。SCTP的这种数据块(被称为DATA CHUNK)通常会携带应用的一个数据包,或者说是应用要发送的一个消息。
在实际的应用中,TCP发送方的可以将应用程序需要发送的多个消息打包到一个TCP包里面发出去。比如,应用程序连续调用两次send()向对端发送两条消息,TCP协议可能把这两条消息都打包放在同一个TCP包中。接收端在收到这个TCP包时,回给对端的ACK只是表明自己接收到了多少个字节,TCP协议本身并不会把收到的数据重新拆散分成两条应用层消息并通知应用程序去接收。事实上,应用程序可能只需要调用一次receive(),就会把两条消息都收上来,然后应用需要根据应用程序自己定义的格式去拆成两条消息。
与TCP不同,SCTP是将应用程序的每次调用sendmsg()发送的数据当作一个整体,放到一个被称为DATA CHUNK的数据块里面,接收端也是以DATA CHUNK为单位接收数据,并重新组包,通知应用程序接收。通常,应用程序每次调用recvmesg()都会收到一条完整的消息。
在SCTP的发送端,多条短的应用层消息可以被SCTP协议打包放在同一个SCTP包中,此时在SCTP包中可以看到多个DATA CHUNK。另一方面,一条太长(比如,超过了路径MTU)的应用层消息也可能被SCTP协议拆分成多个片段,分别放在多个DATA CHUNK并通过不同的SCTP包发送给对端。这两种情况下,SCTP的接收端都能重新组包,并通知应用程序去接收。
TCP的两端都只能用一个IP来建立连接,连接建立之后就只能用这一对IP来相互收发消息了。如果这一对IP之间的路径出了问题,那这条TCP连接就不可用了。
SCTP不一样的地方是,两端都可以绑定到多个IP上,只要有其中一对IP能通,这条SCTP连接就还可以用。
体现在socket API中,TCP只能bind一个IP,而SCTP可以bind到多个IP。
一条SCTP连接里面,可以区分多条不同的流(stream),不同的流之间的数据传输互不干扰。这样做理论上的好处是,如果其中某一条流由于丢包阻塞了,那只会影响到这一条流,其他的流并不会被阻塞。但是实际上,如果某一条流由于丢包阻塞,其他的流通常也会丢包,被阻塞,最后导致所有的流都被阻塞,SCTP连接中断。
在同一条stream里面,SCTP支持有序/无序两种传输方式,应用程序在调用sendmsg()的时候,需要指定用哪一条stream传输,以及指定这条要发送的消息是需要有序传输还是无序传输的。如果在传输过程中丢包,则有序传递模式可能会在接收端被阻塞,而无序传输模式不会在接收端被阻塞。
TCP连接建立过程,容易受到DoS攻击。在建立连接的时候,client端需要发送SYN给server端,server端需要将这些连接请求缓存下来。通过这种机制,攻击者可以发送大量伪造的SYN包到一个server端,导致server端耗尽内存来缓存这些连接请求,最终无法服务。
SCTP的建立过程需要四步握手,server端在收到连接请求时,不会立即分配内存缓存起来,而是返回一个COOKIE。client端需要回送这个COOKIE,server端校验之后,从cookie中重新获取有效信息(比如对端地址列表),才会最终建立这条连接。这样,可以避免类似TCP的SYN攻击。
应用程序对此感知不到,对应用程序来说,不管是TCP还是SCTP,都只需要在server端listen一个socket,client调用connect()去连接到一个server端。
SCTP协议本身有heartbeat机制来监控连接/路径的可用性。
前面说过,SCTP两端都可以bind多个IP,因此同一条SCTP连接的数据可以采用不同的IP来传输。不同的IP传输路径对应一条path,不同的path都可以由heartbeat或者是数据的传输/确认来监控其状态。
如果heartbeat没相应,或者是数据在某条path超时没收到确认导致重传,则认为该path有一次传输失败。如果该path的连续传输失败次数超过path的连续重传次数,则认为该path不可用,并通知应用程序。如果一条连接的连续传输次数超过设定的“连接最大重传次数”,则该连接被认为不可用,该连接会被关闭并通知应用程序。
确认用户数据的无错误和无复制传输;
数据分段以符合发现路径最大传输单元的大小;
在多数据流中用户信息的有序发送,带有一个选项,用户信息可以按到达顺序发送;
选择性的将多个用户信息绑定到单个SCTP包;
通过关联的一个终端或两个终端多重宿主支持来为网络故障规定容度。