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

三次握手是为了防止已失效的连接请求再次传送到服务器端。 二次握手不可行，因为：如果由于网络不稳定，虽然客户端以前发送的连接请求以到达服务方，但服务方的同意连接的应答未能到达客户端。则客户方要重新发送连接请求，若采用二次握手，服务方收到重传的请求连接后，会以为是新的请求，就会发送同意连接报文，并新开进程提供服务，这样会造成服务方资源的无谓浪费。

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

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认； 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端不会产生死销、但会增大额外开销的流量，因为TCP 需要时刻跟踪
TCP是面向连接的协议 所以需要3次握手 如果2次就是DDOS攻击的一种了 叫做land攻击

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。 （1）TCP的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的报文段进行确认；主机A再次对主机B的确认进行确认。（2）采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。 （3）采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。
三次握手是为了防止已失效的连接请求再次传送到服务器端。 二次握手不可行，因为：如果由于网络不稳定，虽然客户端以前发送的连接请求以到达服务方，但服务方的同意连接的应答未能到达客户端。则客户方要重新发送连接请求，若采用二次握手，服务方收到重传的请求连接后，会以为是新的请求，就会发送同意连接报文，并新开进程提供服务，这样会造成服务方资源的无谓浪费。 采纳哦
三次握手是为了防止已失效的连接请求再次传送到服务器端。 二次握手不可行，因为：如果由于网络不稳定，虽然客户端以前发送的连接请求以到达服务方，但服务方的同意连接的应答未能到达客户端。则客户方要重新发送连接请求，若采用二次握手，服务方收到重传的请求连接后，会以为是新的请求，就会发送同意连接报文，并新开进程提供服务，这样会造成服务方资源的无谓浪费。

我们知道，3次握手完成两个重要的功能，既要双方做好发送数据的准备工作（双方都知道彼此已准备好），也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。 现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。7-06因为IP数据报的首部的总长度字段为16bit，因此IP数据报最大长度为216-1=65535字节(即64KB)，再减去IP首部(20字节)和TCP首部(20字节)，则为TCP报文段的最多字节即65495字节。能，当要传送的数据字节长度超过TCP报文的序号字段的最大序号时，则又重新从最小序号开始循环重复使用。因为序号字段有32位长，可对4GB的数据进行编号，这样就可以保证当序号重复使用时，旧序号的数据早已在网络中消失了。7-23因为以太网对应的MTU为1500字节，减去IP首部20字节，所以以太网上传送UDP用户数据报的最大大小为1480。8192整除1480可知应当划分为6个数据包片，前5个是1480字节，最后一个792字节。片偏移字段的值分别为：0， 1480/8 = 185， 1480*2/8 = 370， 1480*3/8 = 555， 1480*4/8 = 740， 1480*5/8 = 925。7-27发送时延 = 65535*8/(1*109) 秒。往返时延 = 2*10*10-3 = 0.02ms。总时延 = 往返时延+发送时延 = 0.02052428 秒吞吐量应为：65535*8 / 总时延 = 65535*8 / 0.02052428 = 25.5 Mb/s7-28具有相同编号的报文段不应该同时在网络中传输，必须保证，当序列号循环回来重复使用的时候，具有相同序列号的报文段已经从网络中消失。现在报文段的寿命为30秒，那么在30秒的时间内发送方发送的报文段的数目不能多于255个。 255×128×8÷30=8704b/s 所以，每一条TCP连接所能达到的最高数据率为8.704Kb/s。7-29264(字节)*8(位/字节)/(75*1012(b/s)) = 1967652.7(s) = 22.77(天)7-30一个TCP连接下面使用256kbit/s的链路，其端到端时延为128ms。经测试，发现吞吐量只有120kbit/s。试问发送窗口是多少？答：设发送窗口为X字节，假定一次最大发送量等于窗口值，那么，每发送一次都得停下来等待得到本窗口的确认，以得到新的发送许可，这样发送时延为8*x/(256*103) 秒。往返时延 = 128*2 = 256ms。总时延 = 往返时延+发送时延 = 256*10-3+8*X/(256*103) 秒吞吐量应为：8*X/总时延 = 8*X / (256*10-3+8*X/(256*103)) = 120*103所以：X = 7228 字节7-31传播时延 = 20 (km) / 200 (km/ms) = 0.1ms往返时延 = 2*传播时延 = 0.2ms发送时延 = 往返时延 = 0.2ms 发送速率 = 1*103*8 / (0.2*10-3) = 40*106 = 40Mb/s
客户A与服务器B建立连接。 三次握手主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。“已失效的连接请求报文段”是这样产生的：1.考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立的连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。2.假定现出现了一种异常情况。A发出的第一个连接请求报文段没有丢失，而是在某些网络节点长时间滞留了，以致厌恶到连接释放以后的某个时间才到达B.但B受到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。但其实A并没有发出新的连接请求，因此不回理睬B的确认，也不会像B发送数据。而B却以为新的运输链接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。因此，采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求连接。 希望可以帮到你！