三次握手和四次挥手详细过程

TCP三次握手过程：

　　三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

　　第一次握手：Client什么都不能确认，Server确认对方发送正常，确认自己接受正常

　　第二次握手：Client确认自己发送，接受正常，对方发送，接受正常，Server确认对方发送正常，自己接受正常

　　第三次握手：全部确认完毕

 

　　同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

　　确认ACK，仅当ACK=1时，确认号字段才有效。

　　TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号

  

　　具体的步骤

　　　　发送方先发送SYN=1，ACK=0， 表示请求，同时携带一个seq=i的序号，以及mss=100（能接受每个TCP包最大为100个字节），win=100（我的滑动窗口大小是100个字节），这几个大小都是客户端决定的。

　　　　接受方再发送SYN=1，ACK=1，表示同意连接，同时携带确认好ack=i+1,在携带一个seq=j的序号，同时也会发送服务端的mss，win

　　　　发送方再发送ACK=1，表示确认，同时携带确认号ack=j+1,携带序号seq=i+1

 

关于第三次握手：

　　防止已失效的请求报文段突然又传送到了服务端而产生连接的误判（针对服务端）

　　　　比如：客户端发送了一个连接请求报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段B该服务端，而后 正常建立连接，数据传输完毕，并释放了连接。但是请求报文段A延迟了一段时间后，又到了服务端，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。那么问题来了，假如这里没有三次握手，这时服务端只要发送了确认，新的连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在 一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。

　　针对客户端

　　　　假如没有第三次握手，在第二次握手失败的时候，服务端发出去请求就认为连接成功了。所以开始发送数据，客户端其实都没有收到第二次握手，都不知道服务端建立的什么样的序列号，可能会服务器发来的数据都忽略掉了。 

　  在第三次握手失败时：

　　　　当第三次握手失败时的处理操作，可以看出当失败时服务器并不会重传ack报文，而是直接发送RTS报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

　　关于SYN Flood 攻击：

　　　　攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

　　　　1． 无效连接监视释放 
　　　　　　这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“ 
　　　　2． 延缓TCB分配方法 
　　　　　　SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB（线程控制块）资源，从而占用了系统资源，因此有俩种技术来解决这一问题 

　　　　　　Syn Cache技术 
　　　　　　　　这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB 
　　　　　　Syn Cookie技术 
　　　　　　　　Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源 
　　　　3． 使用SYN Proxy防火墙 
　　　　　　原理：对试图穿越的SYN请求进行验证之后才放行

　　　keepalive如何工作？TCP连接会自动断开吗? 客户端出现故障怎么办？

　　　　　　TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
　　　　　　在此描述中，我们称使用存活选项的那一段为服务器，另一端为客户端。也可以在客户端设置该选项，且没有不允许这样做的理由，但通常设置在服务器。如果连接两端都需要探测对方是否消失，那么就可以在两端同时设置（比如NFS）。

　　　　　　若在一个给定连接上，两小时之内无任何活动，服务器便向客户端发送一个探测段。（我们将在下面的例子中看到探测段的样子。）客户端主机必须是下列四种状态之一：

　　　　　　　　1) 客户端主机依旧活跃（up）运行，并且从服务器可到达。从客户端TCP的正常响应，服务器知道对方仍然活跃。服务器的TCP为接下来的两小时复位存活定时器，如果在这两个小时到期之前，连接上发生应用程序的通信，则定时器重新为往下的两小时复位，并且接着交换数据。

　　　　　　　　2) 客户端已经崩溃，或者已经关闭（down），或者正在重启过程中。在这两种情况下，它的TCP都不会响应。服务器没有收到对其发出探测的响应，并且在75秒之后超时。服务器将总共发送10个这样的探测，每个探测75秒。如果没有收到一个响应，它就认为客户端主机已经关闭并终止连接。

　　　　　　　　3) 客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。

　　　　　　　　4) 客户端主机活跃运行，但从服务器不可到达。这与状态2类似，因为TCP无法区别它们两个。它所能表明的仅是未收到对其探测的回复。

 

　　　　　　服务器不必担心客户端主机被关闭然后重启的情况（这里指的是操作员执行的正常关闭，而不是主机的崩溃）。当系统被操作员关闭时，所有的应用程序进程（也就是客户端进程）都将被终止，客户端TCP会在连接上发送一个FIN。收到这个FIN后，服务器TCP向服务器进程报告一个文件结束，以允许服务器检测这种状态。

　　　　　　在第一种状态下，服务器应用程序不知道存活探测是否发生。凡事都是由TCP层处理的，存活探测对应用程序透明，直到后面2，3，4三种状态发生。在这三种状态下，通过服务器的TCP，返回给服务器应用程序错误信息。（通常服务器向网络发出一个读请求，等待客户端的数据。如果存活特征返回一个错误信息，则将该信息作为读操作的返回值返回给服务器。）在状态2，错误信息类似于“连接超时”。状态3则为“连接被对方复位”。第四种状态看起来像连接超时，或者根据是否收到与该连接相关的ICMP错误信息，而可能返回其它的错误信息。

 　　　　

　　　　如果客户端没有收到服务端的第二次回应客户端会怎么做?

 　　　　　　超时重传机制，在SYN-SEND阶段没有收到回应，会重发第一次握手，但这个重传的时间，和重传的设置是可以手动设置的。

 

四次挥手过程：

　　任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭的状态。当另一方再没有数据发送的时候，发出连接释放通知，自己确认后就完全关闭TCP连接。

　　例：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

 　 终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；

　   具体的过程：

　　A端发送FIN=1，表示请求释放，seq=i

　　B端发送ACK=1，表示确认字段有效，ack=i+1，seq=m

　　B端发送FIN=1，表示请求释放,seq=j

　　A端发送ACK=1，表示确认有效,seq=j+1,发送以后，进入TIME——WAIT状态，B端收到ACK报文段，就关闭连接，A端等待2MSL后依旧没有收到回复，证明B端正常关闭，则A端关闭

　　1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

　　2、他还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过经过2MSL（报文段最大存货时间的两倍），就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器

　　为什么连接的时候需要3次，而断开的时候需要四次？

     　　TCP建立连接要进行3次握手,而断开连接要进行4次,这是由于TCP的半关闭造成的,因为TCP连接是全双工的（数据可在两个方向上同时传递）。所以进行关闭时每个方向上都要单独进行关闭,这个单方向的关闭就叫半关闭。关闭的方法是一方完成它的数据传输后,就发送一个FIN来向另一方通告将要终止这个方向的连接，收到这个FIN表示这个方向上再没有数据流动，但是收到FIN的那一端仍然可以发送数据。但在发生这个过程以后，服务端可能需要继续发送数据（这个阶段是close_wait）,在服务端也确保需要关闭的时候，服务端再发送FIN，尝试去关闭。

 

RST标志位：

　　在TCP协议中RST表示复位，用来异常的关闭连接。

　　会出现RST的一些情况：

　　1.端口未打开：

　　　　比如主机A向B发出SYN请求，表示连接B的8000端口，当B上没有打开8000端口的时候，会向主机A发送一个RST。

　　2.请求超时：

　　　　有89、27两台主机。主机89向主机27发送了一个SYN，表示希望连接8888端口，主机27回应了主机89一个SYN表示可以连接。但是主机27却很不友好，莫名其妙的发送了一个RST表示我不想连接你了。

后来经过排查发现，在主机89上的程序在建立了socket之后，用setsockopt的SO_RCVTIMEO选项设置了recv的超时时间为100ms。而我们看上面的抓包结果表示，从主机89发出SYN到接收SYN的时间多达110ms。（从15:01:27.799961到15:01:27.961886， 小数点之后的单位是微秒）。因此主机89上的程序认为接收超时，所以发送了RST拒绝进一步发送数据。

　　3.RST攻击

　　　　A和服务器B之间建立了TCP连接，此时C伪造了一个TCP包发给B，使B异常的断开了与A之间的TCP连接，就是RST攻击了。实际上从上面RST标志位的功能已经可以看出这种攻击如何达到效果了。

　　那么伪造什么样的TCP包可以达成目的呢？我们至顶向下的看。

　　　　假定C伪装成A发过去的包，这个包如果是RST包的话，毫无疑问，B将会丢弃与A的缓冲区上所有数据，强制关掉连接。

　　　　如果发过去的包是SYN包，那么，B会表示A已经发疯了（与OS的实现有关），正常连接时又来建新连接，B主动向A发个RST包，并在自己这端强制关掉连接。

 　　　 这两种方式都能够达到复位攻击的效果。似乎挺恐怖，然而关键是，如何能伪造成A发给B的包呢？这里有两个关键因素，源端口和序列号。

一个TCP连接都是四元组，由源IP、源端口、目标IP、目标端口唯一确定一个连接。所以，如果C要伪造A发给B的包，要在上面提到的IP头和TCP头，把源IP、源端口、目标IP、目标端口都填对。这里B作为服务器，IP和端口是公开的，A是我们要下手的目标，IP当然知道，但A的源端口就不清楚了，因为这可能是A随机生成的。当然，如果能够对常见的OS如windows和linux找出生成source port规律的话，还是可以搞定的。

　　　  序列号问题是与滑动窗口对应的，伪造的TCP包里需要填序列号，如果序列号的值不在A之前向B发送时B的滑动窗口内，B是会主动丢弃的。所以我们要找到能落到当时的AB间滑动窗口的序列号。这个可以暴力解决，因为一个sequence长度是32位，取值范围0-4294967296，如果窗口大小像上图中我抓到的windows下的65535的话，只需要相除，就知道最多只需要发65537（4294967296/65535=65537）个包就能有一个序列号落到滑动窗口内。RST包是很小的，IP头＋TCP头也才40字节，算算我们的带宽就知道这实在只需要几秒钟就能搞定。

　　　  那么，序列号不是问题，源端口会麻烦点，如果各个操作系统不能完全随机的生成源端口，或者黑客们能通过其他方式获取到source port，RST攻击易如反掌，后果很严重。