TCP连接握手为什么3次？断开为什么是4次？TCP的优化-SCTP协议

最新推荐文章于 2022-12-05 09:12:15 发布

小边同学

最新推荐文章于 2022-12-05 09:12:15 发布

阅读量1k

点赞数

分类专栏： NA 文章标签： sctp TCP

本文链接：https://blog.csdn.net/weixin_43726831/article/details/106458811

版权

NA 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

TCP

TCP(Transmission Control Protocol)传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP报头

在这里插入图片描述

16Bit-源端口：用来标识计算机中不同的应用进程
16Bit-目标端口：接收方的应用程序接口
32Bit-序列号：序列号是本报文段发送数据组的第一个字节的序号，每一个字节一个序号，如果说一个报文的序列号为100，此报文的数据部分有200字节，下一个报文段的序列号就为300，序列号保证了TCP传输的有序性
32Bit-确认号：只有当控制位中ack=1时，该确认号才生效，它指明下一个期待收到的字节序列号，表明该序列号之前的数据已经收到
4Bit-头部长度：TCP的长度时不确定的，报头不包含任何选项字段长度为20byte，4Bit的头部长度是做数据偏移，指示了数据区在报文段中的起始偏移值
6Bit-resv：为QOS做预留，TCP排队机制
6Bit-控制字段
1. URG：紧急指针标志，为1时表示TCP报头中紧急指针有效，为0时忽略紧急指针，没有意义
2. ACK：确认序列号标志，为1时确认号有效，为0时报文中不含确认信息
3. PSH：紧急数据标志，为1时表示带有紧急标志的数据，指接收方接收到该报文后，尽快交给应用程序
4. RST：重新连接标志，用于重置主机崩溃，错误连接，拒绝非法的报文段，拒绝连接
5. SYN：同步序号，用于建立连接的过程，在请求中，SYN=1和ACK=0表示，没有ACK确认，SYN=1和ACK=1，表示有ACK的确认
6. FIN：Finish标志，用于释放TCP连接，为1时，本地没有数据发送，即将终止本地数据流
16Bit-滑动窗口：滑动窗口大小，用来告知发送端的cache大小，控制数据发送的速率，做流量控制，最大65535
16Bit-校验和：做奇偶校验，此校验和针对于整个TCP报文段，包括头部和数据
16Bit-指针：控制位UGR=1时，该指针生效，是一个偏移量，和序列号字段中的值相加表示紧急数据的最后一个字节的序号，用于在发送紧急数据时
32Bit-选项填充字段：最常见的为MSS最大段长度，每个连接方通常在第一个报文段中指出该选项，表示本端能接受的最大段长度

TCP连接的三次握手

在这里插入图片描述

第一次握手： 客户端发出连接请求消息到服务端，SYN(SEQ=x)报文给服务器端，进入SYN_SEND状态
1. 服务端：此时服务端收到客户端的SYN，服务端知道自己与客户端是可以连接成功的
2. 客户端：此时客户端并不知道服务端是否收到自己的请求连接消息->第二次握手
第二次握手： 第二次握手是服务端发出确认包ACK，来确认收到客户端的请求连接消息，SYN(SEQ=y)ACK(ACK=x+1)，服务端进入SYN_RECV状态
第三次握手： 客户端收到服务端的SYN报文，回应一个ACK(ACK=y+1)报文，进入Established状态，服务器接收到客户端的ACK，进入Established状态

第一次是发出请求，第二次是应答，只有当客户端确定了自己能与服务端连接上才能开始收发数据，服务端只有收到客户端的请求才能进行信息的传递，这是最基本的

第三次是为了防止已经失效的连接请求报文突然又传到服务端(由于网络卡顿的原因)，当服务端再次收到SYN时，会认为客户端没有收到自己的ACK+SYN，会再次发送ACK+SYN，回造成资源的浪费，所以第三次是很有必要的，是客户端对服务端的再次确认。

TCP的可靠的传输控制协议，三次握手能保证数据可靠，又能提高传输效率

TCP为什么要三次握手？

为什么不是两次握手？

首先客户端与服务端建立TCP连接，客户端发出请求，服务端进行应答，这已经是两次握手了，如果通过这两次握手就直接连接TCP连接的话，会存在以下问题

当网络卡顿时，客户端发送给服务端的SYN报文延迟发送时，客户端没有收到服务端的ACK报文，此时会认为没有收到，客户端重新发出SYN报文，服务端回复ACK，TCP建立连接完成，但是之后客户端延迟的SYN报文会再次到达服务端，服务端会再次回复一个ACK，又建立一次连接

当服务端发送的ACK报文，由于网络原因，不能到达客户端，但是服务端会认为已经建立TCP连接，进入就绪状态等待数据传输，此时客户端没有收到服务端的ACK报文，会再次发送SYN，但是此时服务端已经进入就绪状态，那么服务端会断开连接，重新再去发送ACK报文，与客户端重新建立连接
为什么不是四次握手？

如果是4次握手的话，会通过以下的方式：

第一次握手： 客户端给服务端发送SYN同步报文。
第二次握手： 服务端收到SYN后，给客户端回复ACK确认报文。
第三次握手： 服务端给客户端发送SYN同步报文。
第四次握手： 客户端给服务端发送ACK确认报文。

SYN和ACK只是TCP报头中的一个标识位，所以SYN和ACK可以在一个报头中定义，也就是说，第二步服务端的ACK，和第三步的ACK可以合为一步，SYN+ACK发送给客户端，这样就省了一步，提高效率

TCP连接的四次断开

在这里插入图片描述
是TCP的半关闭造成的，客户端和服务端都要进行关闭，才能彻底断开连接。

第一次挥手： 第一次挥手是客户端完成数据传送后，要与服务端断开TCP连接，此时会发送一个FIN报文，向服务端请求断开连接
第二次挥手： 第二次挥手是服务端收到客户端的FIN请求断开报文后，对客户端的请求的确认，向客户端发送ACK报文，表明自己已经收到客户端的消息
第三次挥手： 此时服务端知道客户端已经不会主动发送数据过来了，但是服务端自己还能主动发送消息，如果服务端此时没有数据要向客户端发送，会向客户端发送FIN请求报文，表明自己也要断开连接
第四次挥手： 第四次挥手是客户端对服务端FIN请求断开报文的确认，客户端向服务端进行确认，表名自己受到服务端的消息，此时四次挥手完毕，彻底断开连接

TCP是全双工的，客户端和服务端都可以向对象发送消息，所以断开需要双方都要发出请求，请求之后双方都要进行确认

SCTP协议

SCTP(Stream Control Transmission Protocol)是一种传输层的协议，与TCP/IP协议栈中与TCP和UDP类似，兼有两者特征

SCTP特性

SCTP是后来引入的一种新的协议，提供了和TCP一样的可靠、有序的数据传输功能，同时又能和UDP一样面对消息的方式来进行操作，保护消息边界

多宿主
多流
初始化保护
消息分帧
可配置的无序发送
平滑关闭

SCTP传输问题-多宿主

我们都知道TCP是以字节为单位来传输数据的，但SCTP是 以数据块为单位来传输数据的，这种数据块(DATA CHUNK)通常携带应用的一个数据包，或者是应用要发送的一个消息

SCTP是将应用程序的每次调用sendmsg()发送的数据当做一个整体，放到一个称为DATA CHUNK的数据块里面，接收端也是以数据块为单位来接收，并重新组包，通知应用程序接收，通常应用程序通过recvmesg()都会受到一条完整的消息.

SCTP多路径传输
在这里插入图片描述
TCP的两端都只能用一个IP来建立TCP连接，连接之后就能用这一对IP来相互收发消息，如果这一对IP之间的路径出现了问题，那么这条TCP连接就不可用了

SCTP，两端都可以绑定在多个IP上，只要其中一对IP能通，这条SCTP连接就还可以用

SCTP传输问题-多流&无序发送

一条SCTP连接里面，可以区分多条不同的流（stream），不同的流之间的数据传输互不干扰，如果某一条流由于丢包阻塞，其他的流通常也会丢包，被阻塞，最后导致所有的流都被阻塞，SCTP连接中断。
在这里插入图片描述
在同一条stream里面，SCTP支持有序/无序两种传输方式，应用程序在调用sendmsg()的时候，需要指定用哪一条stream传输，以及指定这条要发送的消息是需要有序传输还是无序传输的。如果在传输过程中丢包，则有序传递模式可能会在接收端被阻塞，而无序传输模式不会在接收端被阻塞。