tcp三次握手传输可靠吗(TCp三次握手)

tcp 为什么要三次握手？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。 第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。 注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立链接之后，谁都可能先开始通信。如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

三次握手的目的：是为了确认双方都有收发数据的能力。第一次：A->B，证明A有发消息的能力。第二次：->B&&B->A，证明B有收消息，并且有发消息的能力。第三次：A->B，证明A有收消息的能力。二次握手达不到目的，四次多余。当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

在多线程任务中，TCP任务通过三次握手能建立可靠的连接，但是经常会发生在数据传输或通信时发生网络突然断开或者长时间连接空循环监听而未进行操作，需要在软件设计时考虑程序运行中检测到服务器对客户端的这一“虚连接”现象。 如果主机崩溃，write是否阻塞取决于内核的tcp缓冲区，但read将一直阻塞，直到超时ETIMEOUT，或由于某些中间路由器的原因返回EHOSTUNREACH/ENETUNREACH。select不能检测到该情况。如果主机崩溃并重起，客户的write到达主机时主机响应RST，客户的read将返ECONNRESET。此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因。心跳机制有两种方法可以检测:1.TCP连接双方定时发握手消息2.利用TCP协议栈中的KeepAlive探测第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测,所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试)1）Windows平台C代码//定义结构及宏struct TCP_KEEPALIVE {u_longonoff;u_longkeepalivetime;u_longkeepaliveinterval;} ;#define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4)//KeepAlive实现TCP_KEEPALIVE inKeepAlive = {0}; //输入参数unsigned long ulInLen = sizeof(TCP_KEEPALIVE);TCP_KEEPALIVE outKeepAlive = {0}; //输出参数unsigned long ulOutLen = sizeof(TCP_KEEPALIVE);unsigned long ulBytesReturn = 0;//设置socket的keep alive为5秒，并且发送次数为3次inKeepAlive.onoff = 1;inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS,(LPVOID)&inKeepAlive, ulInLen,(LPVOID)&outKeepAlive, ulOutLen,&ulBytesReturn, NULL, NULL) == SOCKET_ERROR){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)!n"), WSAGetLastError()));}//定义结构及宏 struct TCP_KEEPALIVE { u_longonoff; u_longkeepalivetime; u_longkeepaliveinterval; } ; #define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4) //KeepAlive实现 TCP_KEEPALIVE inKeepAlive = {0}; //输入参数 unsigned long ulInLen = sizeof(TCP_KEEPALIVE); TCP_KEEPALIVE outKeepAlive = {0}; //输出参数 unsigned long ulOutLen = sizeof(TCP_KEEPALIVE); unsigned long ulBytesReturn = 0; //设置socket的keep alive为5秒，并且发送次数为3次 inKeepAlive.onoff = 1; inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔 inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间 if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL) == SOCKET_ERROR) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)!n"), WSAGetLastError())); }2）Linux平台C代码#include……////KeepAlive实现//下面代码要求有ACE,如果没有包含ACE,则请把用到的ACE函数改成linux相应的接口int keepAlive = 1;//设定KeepAliveint keepIdle = 5;//开始首次KeepAlive探测前的TCP空闭时间int keepInterval = 5;//两次KeepAlive探测间的时间间隔int keepCount = 3;//判定断开前的KeepAlive探测次数if(setsockopt(s,SOL_SOCKET,SO_KEEPALIVE,(void*)&keepAlive,sizeof(keepAlive)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt SO_KEEPALIVE error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPIDLE,(void *)&keepIdle,sizeof(keepIdle)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPIDLE error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPINTVL,(void *)&keepInterval,sizeof(keepInterval)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPINTVL error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPCNT,(void *)&keepCount,sizeof(keepCount)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t)setsockopt TCP_KEEPCNT error!n")));}心跳机制：定时发送一个自定义的结构体(心跳包)，让对方知道自己还活着，以确保连接的有效性。网络中的接收和发送数据都是使用WINDOWS中的SOCKET进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”。以确保链接的有效性。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项。系统默认是设置的是2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。心跳包一般来说都是在逻辑层发送空的包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀当然，这个自然是要由逻辑层根据需求去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。TCP连接异常断开后操作系统会告诉你，你查询套接字的状态会得到异常，或者当发现函数失败WSAGetLastError的时候也会得到内核的通知。// 发送回应消息int nSend = Send4IntMsg(sock, (char*)(LPCTSTR)strSendBuf,strSendBuf.GetLength(), errMsg);if (nSend < 0) //发送消息失败closesocket(sock);//重新连接 在B/S编程和UDP编程时才用到心跳。比如定期向web服务器发一个request证明自己在线。http协议是请求一下就断开了，每次都要重新连接，重新请求，这种情况下才有必要用心跳机制。一般的TCP通信都是长连接，不可能频繁连接和断开。对于长期保持连接的情况，一旦断开，操作系统底层都会通知你，你需要解决的是如何获取到系统的通知。

tcp协议是一种面向连接的可靠协议，它规定在正式传输数据之前必须建立起连接关系，过程是a向b发送syn包，b收到后发送ack+syn包，a收到后向b发送ack包。这个过程称为三次握手，经过三次握手后发送的数据才会被接收。 利用tcp协议的攻击原理是a向b发送一个syn包，b返回ack+syn包，但a不再发送ack确认包，那么b将就这样一直等待a返回的确认包，占用了连接资源，这样的状况成为半开连接，直到连接超时才会关闭连接。如果a向b发送大量的syn包，b的网络连接资源将被耗尽，就构成了攻击。还有更坏的一种方式是在发送的syn包中把源地址设为一个不存在的地址，服务器向一个不存在的地址发送请求包自然得不到回应。

原理四个主要方面：一、tcp协议之连接建立、断开二、tcp协议之超时重传三、tcp协议之窗口管理四、tcp协议之拥塞控制TCP是一种面向有连接的协议，也就是说必须确认对方存在时才能发送数据而TCP通过检验和、序列号、确认应答、重发控制、连接管理、窗口控制等机制来实现可靠传输。1. 目的：TCP三次握手是客户端和服务器总共发三个数据包，通过三个数据包来确认主动发送能力和被动接收能力是否正常。2. 实质：通过指定的四元组（源地址、源端口、目标地址、目标端口）来建立TCP连接，同步双方各自发送序列号seq和确认号ACK，同时也会交换窗口大小信息三次握手过程的实现方式就是交换序列号seq。随便在网上找个地址，如果通过域名想看ip地址，可以ping下看连接。① 192.168.3.7发送[SYN]报文段至222.169.228.146，告知序列号x为0。② 222.169.228.146发送[SYN，ACK]报文段至192.168.3.7，告知序列号y为0，确认号ACK为x+1=1。③192.168.3.7发送[ACK]报文段至222.169.228.146，告知确认号ACK为y+1=1。报文段中的其他参数：MSS=1460：允许从对方接收到的最大报文段，图中为1460字节（指承载的数据，不包含报文段的头部）。win=8192：滑动窗口的大小为8192字节。SACK_PERM=1：开启选择确认。为什么会使用SACK：tcp确认方式不是一段报文段一确认，而是采用累积确认方式。服务器接收到的报文段无序所以序列号也是不连续，服务器的接收队列会出现空洞情况。为了解决空洞，提前了解当前空洞，应对丢失遗漏，采取重传。提前了解方式就是通过SACK选项信息，SACK信息包含接收方已经成功接收的数据块的序列号范围。而SACK_PERM字段为1表明，选择开启了SACK功能。网络层可能会出现丢失、重复、乱序的问题，tcp是提供可靠的数据传输服务的，为了保证数据的正确性，tcp协议会重传它认为的已经丢失的包。重传两种机制：一种基于时间重传，一种基于确认报文段提供的信息重传。RTT：数据完全发送完（完成最后一个比特推送到数据链路上）到收到确认信号的时间（往返时间）。RTO：重传超时时间（tcp发送数据时设置一个计时器，当计时器超时没有收到数据确认信息，引发超时而重传，判断的标准就是RTO）。思考：发送序列号为1、2、3、4这4个报文段，但是出现了序列号2报文段丢失，怎么办？发送端接收到seq1的确认报文（ACK=2）后，等待seq=2的确认报文。接收端当收到序列号为3的报文（2已丢失），发送ack为4的确认报文，发送端正等待ack为2的确认报文，面对跳跃的报文，那么发送端会一直等待，直到超出指定时间，重传报文2。为什么不跳跃确认呢？tcp是累积确认方式，如果确认报文3，那么意味着报文1和报文2都已经成功接收。超时处理方式：思考：上面计时器是以时间为标准重传，那么可以通过确认报文的次数来决定重传。发送端接收到seq1的确认报文（ACK=2）后，等待seq=2的确认报文。接收端收到报文3、4、5，但是没收到报文2，那么接收端发送三个ACK为2的确认报文，发送端收到这个三个确认报文，重传报文2。思考：如果快速重传中丢失包的地方很多（报文2，报文,7，报文9，报文30，报文300....），那么需要从头到尾都重传，这很蛋疼？思考：SACK重传对于接收到重复数据段怎样运作没有明确规定，通过DSACK重传可以让发送方知道哪些数据被重复接收了，而且明确是什么原因造成的。发送端没有收到100-199的ACK包，超过指定时间，重传报文。接收端都已经收到200-299的发送报文了，又来100-199是重复报文。再向发送端发送一个ACK报文，设置SACK 100-199,告知发送端，已经收到了100-199包，只是回应ACK包丢失。发送端发送包100-199，由于网络延迟，一直没有达到接收端。接收端连续发送三个ACK 200确认报文，触发快速重传，发送端收到了ACK 500的确认报文，表明之前的报文都已经交付成功。接收端又收到了延迟的报文100-199，再次向发送端发送一个SACK 100-199的ACK 500报文。发送端发现这是重复报文，判断为网络延迟造成的。计时器重传：根据超时，重传。快速重传：根据接收三次相同ACK报文，重传。选择确认重传：根据接收端提供的SACK信息，重传。DSACK重传：根据重复报文，明确丢失ACK报文还是网络延迟。Category1：已发送且已确认（已经收到ACK报文的数据）。Category2：已发送但未收到确认。Category3：即将发送。Category4：窗口移动前都不能发送。可用窗口：46-51字节。发送窗口：32-51字节。RCV.NXT：左边界RCV.WND：接收窗口RCV.NXT+RCV.WND：右边界接收端接收到序列号小于左边界，那么被认为重复数据而被丢弃。接收端接收到序列号大于右边界，那么被认为超出处理范围，丢弃。注意：tcp协议为累积ACK结构，只有当达到数据序列号等于左边界时，数据才不会被丢弃。如果窗口更新ACK丢失，对于发送端，窗口左边界右移，已发送数据得到ACK确认之后，左右边界距离减小，发送端窗口会减小，当左右边界相等时，称为零窗口。零窗口之后：接收端发送窗口更新能会发生窗口更新ACK丢失。<>解释：TCP是通过接收端的通告窗口来实现流量控制的，通告窗口指示了接收端可接收的数据量。当窗口值变为0时，可以有效阻止发送端继续发送，直到窗口大小恢复为非零值。当接收端重新获得可用空间时，会给发送端传输一个窗口更新告知其可继续发送数据。这样的窗口更新通常都不包含数据（纯ACK），接收端向发送端发送的窗口更新ACK可能丢失。结果双方处于等待状态，发生死锁。解决方案：发送端会采用一个持续计时器间歇性地查询接收端，看其窗口是否已增长。触发窗口探测，强制要求接收端返回ACK。发送几次探测，窗口大小还是0，那么断开连接。出现SWS的情况：① 接收端通告窗口太小。② 发送端发送的数据太小。解决方案：① 针对接收端：不应通告小窗口值[RFC1122]描述：在窗口可增至一个全长的报文段（接收端MSS）或者接收端缓存空间的一半（取两者中较小值）之前，不能通告比当前窗口更大的窗口值。标准：min（MSS , 缓存空间/2）。② 针对发送端：不应发送小的报文至少满足以下其一：（1）可以发送MSS字节的报文。window size >= MSS或者 数据大小>=MSS（2）数据段长度>=接收端通告过的最大窗口值的一半，才可以发送。收到之前发送的数据的ack回包，再发送数据，否则一直攒数据。（3） -1 没有未经确认的在传数据或者-2 连接禁用Nagle算法。tcp基于ACK数据包中的通告窗口大小字段实现了流量控制。当网络大规模通信负载而瘫痪，默认网络进入拥塞状态，减缓tcp的传输。发送方和接收方被要求承担超负荷的通信任务时，采取降低发送速率或者最终丢弃部分数据的方法。反映网络传输能力的变量称为拥塞窗口（cwnd）。通告窗口（awnd）。发送窗口swnd=min（cwnd，awnd）目的：tcp在用拥塞避免算法探寻更多可用带宽之前得到cwnd值，帮助tcp建立ACK时钟。[RFC5681] ：在传输初始阶段，由于未知网络传输能力，需要缓慢探测可用传输资源，防止短时间内大量数据注入导致拥塞。慢启动算法针对这一问题而设计。在数据传输之初或者重传计时器检测到丢包后，需要执行慢启动。拥塞窗口值：每收到一个ACK值，cwnd扩充一倍。所以假设没有丢包且每个数据包都有相应ACK值，在k轮后swnd=，成指数增长。SMSS是发送方的最大段大小。慢启动阶段，cwnd会指数增长，很快，帮助确立一个慢启动阙值（ssthresh）。有了阙值，tcp会进入拥塞避免阶段，cwnd每次增长值近似于成功传输的数据段大小，成线性增长。实现公式：cwnd+=SMSS*SMSS/cwnd刚建立连接使用慢启动算法，初始窗口为4，收到一次ACK后，cwnd变为8，再收到一次ACK后，cwnd变为16，依次继续，32、64，达到阙值ssthresh为64。开始使用拥塞避免算法，设置ssthresh为ssthresh/2，值为32。重新从初始窗口4，线性递增到ssthresh=32。当cwnd < ssthresh时，使用慢启动算法当cwnd > ssthresh时，使用拥塞避免算法应用快速恢复算法时机：启动快速重传且正常未失序ACK段达到之前。启动快速恢复算法。实现过程：① 将ssthresh设置为1/2 cwnd，将cwnd设置为ssthresh+3*SMSS。② 每接收一个重复ACK，cwnd值暂时增加1 SMSS。③当接收到新数据ACK后，将cwnd设置为ssthresh。参考:<>