tcp三次握手报文(tcp三次握手报文分析)

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

本文主要内容1、TCP数据包格式TCP数据包格式如下：注意到中间还有几个标志位：数据包格式当中，最重要的是理解序号和确认序号。TCP为什么是稳定可靠的，与序号与确认序号这套机制紧密相关，这也是TCP的精髓。2、TCP的三次握手众所周知，TCP协议是可靠的，而UDP协议是不可靠的。在一些场景中必须用TCP，比如说用户登录，必须给出明确答复是否登录成功等。而有些场景中，用户是否接收到数据则不那么关键，比如网络游戏当中，玩家射出一颗子弹，另外的玩家是否看到，完全取决于当前网络环境，如果网络卡顿，就会有玩家已经被射杀，但界面仍然刷新不出来的情况。这种情形适合UDP。为了保证TCP协议可靠，在建立连接之时就要得到保证。最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。（A、B关闭状态CLOSED——B收听状态LISTEN——A同步已发送状态SYN-SENT——B同步收到状态SYN-RCVD——A、B连接已建立状态ESTABLISHED）B服务器进程就处于LISTEN（收听）状态，等待客户的连接请求。若有，则作出响应。3、TCP的传输和确认TCP 传输的可靠性，可以用一句话归结：每收到对方数据，就发送 ACK 进行确定，发送方发送后没有收到 ACK 就隔一段时间重发。就是 A 向 B 发送消息（下面将 TCP 的报文直接看做是消息，消息一词跟 TCP 报文混用），B 收到消息后需要向 A 发送 ACK。这个 ACK 相当于返回结果，没有返回结果，A 就重新发送消息。归纳起来，A 有 3 种消息需要确认。另外 A 也可以发送 RST 消息，代表出错了。出错消息不需要确认。RST 也可以当成返回接口，替代正常的 ACK。返回 ACK，表示消息发送并处理成功，返回 RST 表示消息处理失败。因为通过网络传输，还有第三种结果，就是不确定成功失败。这样归纳起来。就有三种返回结果。这两种具体情况，A 根本识别不了，都只能重发。4、TCP的序号和确认序号A 向 B 发送消息，假如同时发送 a、b、c、d 消息，因为通过网络，这些消息的顺序并非固定的。而 B 返回 ACK 结果，这样就有一个问题，这个结果到底对应了哪个消息？另外当 A 超时重发后，原来的消息延时一段时候，又重新到达了 B，这样 B 就收到两条相同的消息，那么 B 怎么确定这两条消息是相同的呢？为了解决这个对应问题，每一条消息都需要有一个编号，返回结果也应该有一个编号。TCP 的序号可以看成是发送消息的编号，确认序号可以看成是返回结果的编号。有了编号，重复的消息才可以忽略，返回结果(ACK)才可以跟消息对应起来。当建立连接的时候，TCP 选定一个初始序号，之后每发送一个数据包（消息），就将序号递增，保证每发送不同的数据包，数据包的序号都是不同的。TCP 是这样处理的：SYN、FIN 也需要递增序号。不然 A 向 B 重发多个 SYN 或者 FIN, B 根本判断不了 SYN 是否相同，这样就不可以忽略重复的数据包了。当 TCP 发送 ACK 时，相当于返回结果，需要带有确认序号，以便跟发送的消息对应起来。当发送包编号为 a，递增长度为 len。其中 SYN 和 FIN 可以看成是递增长度为 1。这条消息可以这样表示为：现在来回顾三次握手过程。 A 发送序列号x给 B ， B 回复 A 确认号 x+ 1，同时发送序列号 y， A 接收到 B 的回复后，再回复确认号 y+1，同时发送序列号 x+1。给对方的回复一定是接收到的序号加1（或者是数据长度），这样对方才能知道我已经收到了，这样才能保证TCP是可靠的。

TCP 三次握手过程不管是对于本科计算机网络学习还是考研考计网的同学来说都是必考的一个，所以要掌握 TCP 整个握手的过程显得尤为重要。 一、TCP 是什么？TCP是Transmission Control Protocol(传输控制协议) 的简称，它提供一种面向连接的、可靠的、基于字节流的传输层通信协议。在学习 TCP 握手过程之前，我们首先要了解 TCP 报文头部的一些标志信息，因为在 TCP 握手的过程中，要用到TCP报文头部的一些信息。TCP头部1.1 源端口和目的端口对于端口，我们可以这么理解：我们可以想象发送方很多的窗户，接收方也有很多的窗户，这些窗口都标有不同的端口号，源端口号和目的端口号就分别代表从哪个规定的串口发送到对方接收的窗口。不同的应用程序都有着不同的端口，比如HTTP端口80，SMTP端口25等。1.2 序号TCP是面向字节流的，在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。通俗一点的讲，每个字段在传送中用序列号来标记自己位置的，而这个字段就是用来完成双方传输中确保字段原始位置是按照传输顺序的。（发送方是数据是怎样一个顺序，到了接受方也要确保是这个顺序）1.3 确认号确认号是期望收到对方下一个报文段的第一个字节的序号。确认号 = N,则表示到序号N-1为止的所有数据都已经正确收到。例如：B正确收到了A发送过来的一个报文段，其序号字段值为500，而数据字段长度是200字节(序号501~700)，这表明B正确收到了A发送的到序号700为止的数据，因此B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。1.4 标志位TCP首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。今天我们只介绍我们用到的三个。1.4.1 确认ACK这个标志位可以理解为发送端发送数据到接收端，发送的时候 ACK置 为 0，一旦接收端接收数据之后，就将 ACK 置为 1，发送端接收到之后，就知道了接收端已经接收了数据。需要注意的一点是：当且仅当ACK = 1时，确认号字段才有效。TCP规定，在连接建立后，所有传送的报文段 都将ACK置为1。1.4.2 同步SYNSYN是同步序列号，在建立TCP连接时用来同步序号。当SYN=1，ACK=0时，表明这是一个连接请求报文段。若对方同意建立连接，则应在响应的报文段中使SYN=1，ACK=1。因此，SYN置为1就表示这是一个连接请求或连接接受报文。1.4.3 终止FIN当发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送方FIN标志位置为1后，表示此报文段的发送方数据发送完毕，请求释放连接。二 T CP三次握手过程TCP 三次握手的过程解决以下三个问题1.要是每一方都能确知对方的存在2.要允许双方协商一些参数(如窗口最大值，是否使用窗口扩大选项以及时间戳选项等)3.能够对运输实体资源(如缓冲大小、连接表中的项目等)进行分配掌握了这些，TCP 的三次握手就简单多了。下面我们就以动画形式进行拆解三次握手过程。初始状态 ：客户端处于closed(关闭)状态，服务器处于listen(监听)状态第一次握手 ：客户端发送请求报文将SYN = 1同步序列号和初始化序列号seq = x发送给服务端，发送完之后客户端处于SYN_Send状态。第二次握手 ：服务端受到SYN请求报文之后，如果同意连接，会以自己的同步序列号SYN(服务端) = 1、初始化序列号seq = y和确认序列号（期望下次收到的数据包）ack = x+ 1以及确认号ACK = 1报文作为应答，服务器为SYN_Receive状态。第三次握手 ： 客户端接收到服务端的SYN + ACK之后，知道可以下次可以发送了下一序列的数据包了，然后发送同步序列号ack = y + 1和数据包的序列号seq = x + 1以及确认号ACK = 1确认包作为应答，客户端转为established状态。三、为什么不能是一次、二次握手，而必须是三次握手？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况：A发出连接请求，但因连接请求报文丢失而未收到确认。于是A在重传一次连接请求，后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。在此过程中，A一共发送了两个连接请求报文段，其中一个丢失，第二个到达了B。没有已经失效的报文段。但现在出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以至延误到连接释放以后的某个时间才到达B。本来这是一个早已经失效的报文段，但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据，但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。 采用三次握手的办法可以防止上述现象的发生，例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

第一个报文是客户端发出的syn报文，表示客户端要发起通信 第二个报文是服务器发出的syn/ack报文，这个报文中的ack表示对客户端的syn报文的确认，这个报文中syn表示服务器也发起对客户端的请求第三个报文是客户端发出的ack报文，表示对服务器syn报文的确认 如此一来，通过三个报文就可以让双方彼此对通信做出确认了。
奇石又历数劫，但每次都化险为夷。邢云飞八十九岁寿终，以石陪葬，但不久石头又被盗墓贼窃走。

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连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次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状态还有时常常可以用netstat看到。　　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报文。