源目端口号 32位序号(4字节) 32位确认号(4字节) 4位首部长度
6位保留位 6位标志位 16位窗口大小 16位检验和 16位紧急指针
下面具体分析各部分的作用
源目端口号:各占2个字节,分别写入源端口和目的端口;即表示来源和目标的进程
32位序号:占4个字节,TCP连接中传送的字节流中的每个字节都按顺序编号。例如,一段报文的序号字段值是 1 ,而携带的数据共有100字段,显然下一个报文段(如果还有的话)的数据序号应该从101开始
32位确认号:占4个字节,是期望收到对方下一个报文的第一个数据字节的序号。例如,B收到了A发送过来的报文,其序列号字段是501,而数据长度是200字节,这表明B正确的收到了A发送的到序号700为止的数据。因此,B期望收到A的下一个数据序号是701,于是B在发送给A的确认报文段中把确认号置为701;
4位首部长度:占4位,它指出TCP报文的数据距离TCP报文段的起始处有多远
***6位保留位:***占6位,保留今后使用,但目前应都位0
6位标志位:1、紧急URG,当URG=1,表明紧急指针字段有效。告诉系统此报文段中有紧急数据(即当URG=1时,,优先处理数据)
2、确认ACK,仅当ACK=1时,确认号字段才有效。TCP规定,在连接建立后所有报文的传输都必须把ACK置1
3、推送PSH,当两个应用进程进行交互式通信时,有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应,这时候就将PSH=1
4、复位RST,当RST=1,表明TCP连接中出现严重差错,必须释放连接,然后再重新建立连接;
5、同步SYN,在连接建立时用来同步序号。当SYN=1,ACK=0,表明是连接请求报文,若同意连接,则响应报文中应该使SYN=1,ACK=1
6、终止FIN,用来释放连接。当FIN=1,表明此报文的发送方的数据已经发送完毕,并且要求释放
16位窗口大小:占2字节,指的是通知接收方,发送本报文你需要有多大的空间来接受(即预留多大空间存储)
16位检验和:占2字节,校验首部和数据这两部分
16位紧急指针:占2字节,指出本报文段中的紧急数据的字节数
• 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers);
• 第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
• 第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手;
在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于SYN_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。
TIME_WAIT状态
TIME_WAIT状态存在有两个原因。
**<1>可靠终止TCP连接。如果最后一个ACK报文因为网络原因被丢弃,此时server因为没有收到ACK而超时重传FIN报文,处于TIME_WAIT状态的client可以继续对FIN报文做回复,向server发送ACK报文。
**<2>**保证让迟来的TCP报文段有足够的时间被识别和丢弃。连接结束了,网络中的延迟报文也应该被丢弃掉,以免影响立刻建立的新连接。
追问:为什么需要三次?
TCP是可靠的传输控制协议,三次握手能保证数据可靠传输又能提高传输效率。
来看俩次的情况
如果TCP的握手是两次:
<1>如果client发给server的SYN报文因为网络原因,延迟发送。由于client没有收到server对SYN的确认报文,会重发SYN报文,服务器和回复ACK,连接建立。数据发送完毕,这条连接被正常关闭。这时,延迟的SYN报文发到了server,server误以为这是client重新发送的同步报文,又回复了一个ACK,和client建立了连接。
<2>如果server给client发送的ACK报文因为网络原因,报文被丢弃,此时server认为已经建立好连接,但是client没有收到确认报文,认为没有建立好连接。client会重发SYN报文,此时server已经处于就绪状态,认为已经建立好连接。
接下来看四次的情况
–1.client给server发送SYN同步报文;
–2.server收到SYN后,给client回复ACK确认报文;
–3.server给client发送SYN同步报文;
–4.client给server发送ACK确认报文。
第2.3步之间,server和client没有任何的数据交互,分开发送相当于多发了一次TCP报文段,SYN和ACK标识只是TCP报头的一个标识位。很明显,这两步可以合并,从而提高连接的速度和效率。
因此有了tcp的三次握手
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不可用,并通知应用程序。如果一条连接的连续传输次数超过设定的“连接最大重传次数”,则该连接被认为不可用,该连接会被关闭并通知应用程序。1. TCP是以字节为单位传输的,SCTP是以数据块为单位传输的
(此部分来源csdn)