tcp握手协议(Tcp握手协议)

本文主要内容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是可靠的。

答: 服务器的SYN泛洪攻击。大致是这样的，在三次握手过程当中，服务器在第二次握手中就进行TCP相关资源分配，而对于一些恶意程序来说，它可以伪造大量的SYN，然后使得服务器不断地为其分配资源，而恶意程序不对其发送ACK确认，因此导致大量的服务器资源被耗尽。

TCP握手协议 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接.第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手. 完成三次握手,客户端与服务器开始传送数据
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认。第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态。 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据。简版：首先A向B发SYN(同步请求)，然后B回复SYN+ACK(同步请求应答)，最后A回复ACK确认，这样TCP的一次连接(三次握手)的过程就建立了。三次握手我们先明确两个定义：1，client为数据发送方2，server为数据接收方好，下面进行三次握手的总结：1，client想要向server发送数据，请求连接。这时client向服务器发送一个数据包，其中同步位(SYN)被置为1，表明client申请TCP连接，序号为j。2，当server接收到了来自client的数据包时，解析发现同步位为1，便知道client是想要简历TCP连接，于是将当前client的IP、端口之类的加入未连接队列中，并向client回复接受连接请求，想client发送数据包，其中同步位为1，并附带确认位ACK=j+1，表明server已经准备好分配资源了，并向client发起连接请求，请求client为建立TCP连接而分配资源。 3，client向server回复一个ACK，并分配资源建立连接。server收到这个确认时也分配资源进行连接的建立。
A与B建立TCP连接时：首先A向B发SYN（同步请求），然后B回复SYN+ACK（同步请求应答），最后A回复ACK确认，这样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存活时间。

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba