tcp三次握手表情包(tcp和udp的区别表情包)

在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN-ACK应答表示接收到了这个消息，最后客户机再以ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。 TCP连接的第一个包，非常小的一种数据包。SYN 攻击包括大量此类的包，由于这些包看上去来自实际不存在的站点，因此无法有效进行处理。每个机器的欺骗包都要花几秒钟进行尝试方可放弃提供正常响应。第二 、详实的资料补充：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）。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报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。最后有2个问题的回答，我自己分析后的结论（不一定保证100%正确） 这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

对的，主机先后通过TCP PORT 61532 和 61532 与对端 的 TCP PORT 80 建立了两个三次握手连接

tcp三次握手过程中涉及的tcp标识有SYN，ACK，这是正常情况。异常情况下可能有RST，例如向一个没有开放的端口发SYN，就会得到RST。图1：本机10000端口开放，3次握手成功情况。图2：本机10000端口未开放，3次握手失败情况。PS：端口开放在这里标识端口是否listen

三次握手-简介　　所谓的“三握手”：对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据 量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，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)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。 　　*RST：复位标志 　　复位标志有效。用于复位相应的TCP连接。 　　*URG：紧急标志 　　紧急(The urgent pointer) 标志有效。紧急标志置位， 　　*PSH：推标志 　　该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 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 的序列号是可预测的。
第一次，A向B发送连接请求第二次，B同意连接请求，并等待A的连接第三次，A连接到B不停的发送连接请求的，即第一次，可以耗空对方服务器资源，叫SYN碎片攻击，同时SYN扫描存活计算机的速度也很快

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并没有要求建立连接。