为什么tcp要三次握手(为什么使用三次握手)

tcp 为什么要三次握手？ 我们假设A和B是通信的双方。我理解的握手实际上就是通信，发一次信息就是进行一次握手。 第一次握手：A给B打电话说，你可以听到我说话吗？第二次握手：B收到了A的信息，然后对A说：我可以听得到你说话啊，你能听得到我说话吗？第三次握手：A收到了B的信息，然后说可以的，我要给你发信息啦！在三次握手之后，A和B都能确定这么一件事：我说的话，你能听到；你说的话，我也能听到。这样，就可以开始正常通信了。 注意：HTTP是基于TCP协议的，所以每次都是客户端发送请求，服务器应答，但是TCP还可以给其他应用层提供服务，即可能A、B在建立链接之后，谁都可能先开始通信。如果采用两次握手，那么只要服务器发出确认数据包就会建立连接，但由于客户端此时并未响应服务器端的请求，那此时服务器端就会一直在等待客户端，这样服务器端就白白浪费了一定的资源。若采用三次握手，服务器端没有收到来自客户端的再此确认，则就会知道客户端并没有要求建立请求，就不会浪费服务器的资源。
三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。

至少这样正常的三次交流双方都能够知道并且确认对方初始的序列号，也就是说主机1告诉主机2序列号，主机2回复主机1说收到了你的序列号并告诉主机1我的初始序列号是什么，主机1收到来自主机2的序列号以后，告诉主机2，我也收到你的序列号了。看一下对于特殊情况，这三次握手是如何处理的：这个时候，主机2对与这个过期的CR包，将会发送确认给主机1问问是否真的是有这个包，而对于过期的DATA包，主机2会识别到序列号不对而忽略。这个时候，主机2收到的CR包将被忽略，而DATA包也会因为序列号不对而被丢弃这时主机2会发送一个确认请求给主机1，问问他是否存在这个请求，而主机1回应说我已经放弃这个请求了，所以回复REJECT（ACK = y）拒绝主机2，主机2知道后就不再理会。假设主机1向主机2发送一个请求，这个请求在网络中游荡了好久，主机2还没有收到，这是主机1看见没有反应，放弃不再请求，而之前发送的这个请求才到达主机2：假设主机1向主机2发送的CR（seq = x）包以及DATA（seq = y, ACK = z）包都在网络中游荡了很久，而这时主机1已经和主机2建立了可靠的连接（seq = x + 100,ACK = y + 200）假设主机1向主机2发送的CR（seq = x）包以及DATA（seq = y, ACK = z）包都在网络中游荡了很久，而这时主机1与主机2并没有建立连接总之，三次握手后能够确保双方都能知道对方的初始序列号，而防止误收数据包的一个关键就是使用序列号进行确认

TCP 连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP 窗口大小信息。以下步骤概述了通常情况下客户端计算机联系服务器计算机的过程： 1. 客户端向服务器发送一个SYN置位的TCP报文，其中包含连接的初始序列号x和一个窗口大小（表示客户端上用来存储从服务器发送来的传入段的缓冲区的大小）。 2. 服务器收到客户端发送过来的SYN报文后，向客户端发送一个SYN和ACK都置位的TCP报文，其中包含它选择的初始序列号y、对客户端的序列号的确认x+1和一个窗口大小（表示服务器上用来存储从客户端发送来的传入段的缓冲区的大小）。 3. .客户端接收到服务器端返回的SYN+ACK报文后，向服务器端返回一个确认号y+1和序号x+1的ACK报文，一个标准的TCP连接完成。 TCP 使用类似的握手过程来结束连接。这可确保两个主机均能完成传输并确保所有的数据均得以接收TCP ClientFlagsTCP Server1 Send SYN (seq=x)----SYN---SYN Received 2 SYN/ACK Received <---SYN/ACK---- Send SYN (seq=y)， ACK (x+1) 3 Send ACK (y+1)----ACK---ACK Received， ConnectionEstablished w: ISN (Initial Sequence Number) oftheClientx: ISN of the Server 1. TCP的三次握手最主要是防止已过期的连接再次传到被连接的主机。 如果采用两次的话，会出现下面这种情况。 比如是A机要连到B机，结果发送的连接信息由于某种原因没有到达B机； 于是，A机又发了一次，结果这次B收到了，于是就发信息回来，两机就连接。 传完东西后，断开。 结果这时候，原先没有到达的连接信息突然又传到了B机，于是B机发信息给A，然后B机就以为和A连上了，这个时候B机就在等待A传东西过去。 2. 三次握手改成仅需要两次 握手，死锁是可能发生 考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。这样就形成了死锁

一、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存活时间。
简单而言 客户端发送一个SYN(同步序列编号),服务器收到后会发出一个SYN+ACK(确认标志)确认,客户端收到服务器发出SYN+ACK,也会向服务器确认发送一个ACK这样三次握手就完成了既然已经确认了发送方和接受方的信息 为什么还要进行握手?

tcp三次握手的目的是为了解决“网络中存在延迟的重复分组”的问题。 “已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。 假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。