tcp三次握手tcp协议的三次握手

TCP连接建立过程中为什么需要“三次握手”

第一次握手做什么？ 请求端(客户端)会向服务端(被请求端)发送一个tcp报文，申请打开某一个端口。

因为没有数据，所以这个报文仅包含一个tcp头。

其中： SYN=1；当建立一个新的连接时， SYN标志变1。

序号；序号用来标识从客户端向服务端发送的数据字节流。

此时客户端进入SYN_SENT状态。

第二次握手做什么？ 服务端收到客户端的SYN包，也会发一个只包含tcp头的报文给客户端。

ACK=1；服务端确认收到信息 确认序号；客户端序号+1，作为应答 SYN=1；因为tcp的连接是双向的，服务端作为应答的同时请求建立连接。

此时服务端进入SYN_RECV状态 第三次握手做什么？ ACK=1；客户端确认收到信息 确认序号；服务端序号+1，作为应答 此时客户端进入ESTABLISHED状态，服务端收到ACK后也会进入此状态 可见，客户端和服务端都保留了对方的序号，这三次握手缺少任何一步都无法实现这一目标。

在三次握手过程中，出现了一些中间状态。

tcp的三次握手和举例

TCP三次握手 TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接: 位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急) Sequence number(顺序号码) Acknowledge number(确认号码) 第一次握手：主机A发送位码为syn=1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机; 第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包 第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

完成三次握手，主机A与主机B开始传送数据。

TCP三次握手和四次挥手是什么意思？

1、建立连接协议（三次握手） 　　（1）客户端发送一个带SYN标志的TCP报文到服务器。

这是三次握手过程中的报文1。

　　（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。

因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。

　　（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。

　　2、连接终止协议（四次挥手） 　　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。

这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。

收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。

首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

　　（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。

　　（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。

和SYN一样，一个FIN将占用一个序号。

　　（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。

　　（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

　　CLOSED:这个没什么好说的了，表示初始状态。

　　LISTEN:这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。

　　SYN_RCVD:这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上stat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个ACK报文不予发送。

因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。

　　SYN_SENT:这个状态与SYN_RCVD遥想呼应，当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。

SYN_SENT状态表示客户端已发送SYN报文。

　　ESTABLISHED： 这个容易理解了，表示连接已经建立了。

　　FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。

而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。

而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以stat看到。

　　FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。

　　TIME_WAIT:表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。

如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

　　CLOSING:这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。

正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的ACK报文，再收到对方的FIN报文。

但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。

什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

　　CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。

怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。

接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。

所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

　　LAST_ACK:这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。

tcp协议三次握手都有哪些标志数据包

tcp三次握手过程中涉及的tcp标识有SYN，ACK，这是正常情况。

异常情况下可能有RST，例如向一个没有开放的端口发SYN，就会得到RST。

图1：本机10000端口开放，3次握手成功情况。

图2：本机10000端口未开放，3次握手失败情况。

PS：端口开放在这里标识端口是否listen

tcp协议的三次握手

三次握手-简介 所谓的“三握手”：对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据 量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。

为了提供可靠的传送，TCP 在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。

TCP 总是用来发送大批量的数据。

当应用程序在收到数据后要做出确认时也要用到TCP。

TCP握手协议 在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 三次握手协议 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念： 未连接队列：在三次握手协议中，服务器维护一个未连接队列，该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。

这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

Backlog参数：表示未连接队列的最大容纳数目。

SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

注意，每次重传等待的时间不一定相同。

半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。

有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。

[1] * SYN：同步标志 同步序列编号(Synchronize Sequence Numbers)栏有效。

该标志仅在三次握手建立TCP连接时有效。

它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。

在这里，可以把TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。

通过TCP连接交换的数据中每一个字节都经过序列编号。

在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。

*ACK：确认标志 确认编号(Acknowledgement Number)栏有效。

大多数情况下该标志位是置位e799bee5baa6e59b9ee7ad9431333332633035的。

TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。

*RST：复位标志 复位标志有效。

用于复位相应的TCP连接。

*URG：紧急标志 紧急(The urgent pointer) 标志有效。

紧急标志置位， *PSH：推标志 该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。

在处理 或 rlogin 等交互模式的连接时，该标志总是置位的。

*FIN：结束标志 带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数据。

[编辑本段]三次握手协议-工作原理 由于TCP 需要时刻跟踪，这需要额外开销，使得TCP 的格式有些显得复杂。

下面就让我们看一个TCP 的 三次握手协议 经典案例，这是后来被称为MITNICK 攻击中KEVIN 开创了两种攻击技术： TCP 会话劫持和SYN FLOOD（同步洪流） 在这里我们讨论的是TCP 会话劫持的问题。

先让我们明白TCP 建立连接的基本简单的过程。

为了建设一个小型的模仿环境我们假设有3 台接入互联网的机器。

A 为攻击者操纵的攻击机。

B 为中介跳板机器（受信任的服务器）。

C 为受害者使用的机器（多是服务器），这里把C 机器锁定为目标机器。

A 机器向B机器发送SYN 包，请求建立连接，这时已经响应请求的B 机器会向A 机器回应SYN/ACK表明同意建立连接，当A 机器接受到B 机器发送的SYN/ACK 回应时，发送应答ACK 建立 A 机器与B 机器的网络连接。

这样一个两台机器之间的TCP 通话信道就建立成功了。

B 终端受信任的服务器向C 机器发起TCP 连接，A 机器对服务器发起SYN 信息，使C 机器不能响应B 机器。

在同时A 机器也向B 机器发送虚假的C 机器回应的SYN 数据包，接收到SYN 数据包的B 机器（被C 机器信任）开始发送应答连接建立的SYN/ACK 数据包，这时C 机器正在忙于响应以前发送的SYN 数据而无暇回应B 机器，而A 机器的攻击者预测出B 机器包的序列号（现在的TCP 序列号预测难度有所加大）假冒C 机器向B 机器发送应答ACK 这时攻击者骗取B 机器的信任，假冒C 机器与B 机器建立起TCP 协议的对话连接。

这个时候的C 机器还是在响应攻击者A 机器发送的SYN 数据。

TCP 协议栈的弱点：TCP 连接的资源消耗，其中包括：数据包信息、条件状态、序列号等。

通过故意不完成建立连接所需要的三次握手过程，造成连接一方的资源耗尽。

通过攻击者有意的不完成建立连接所需要的三次握手的全过程，从而造成了C 机器的资源耗尽。

序列号的可预测性，目标主机应答连接请求时返回的SYN/ACK 的序列号是可预测的。