为什么是三次握手
问题一：tcp为什么要三次握手 . 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发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁
问题二：TCP为什么要三次握手 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 Received2 SYN/ACK Received 问题三：tcp为什么要三次握手，而不能二次握手 tcp三次握手的目的是为了解决“网络中存在延迟的重复分组”的问题。
“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。
本来这是一个早已失效的报文段,但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。
假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。
问题四：TCP建立连接为什么是三次握手而不是两次握手 《计算机网络》（谢希仁 译）中讲了原因：
1.采用两次握手，那么若Client向Server发起的包A1如果在传输链路上遇到的故障，导致传输到Server的时间相当滞后，在这个时间段由于Client没有收到Server的对于包A1的确认，那么就会重传一个包A2，假设服务器正常收到了A2的包，然后返回确认B2包。由于没有第三次握手，这个时候Client和Server已经建立连接了。再假设A1包随后在链路中传到了Server，这个时候Server又会返回B1包确认，但是由于Client已经清除了A1包，所以Client会丢弃掉这个确认包，但是Server会保持这个相当于“僵尸”的连接。
所以采用两次握手，有可能会浪费Server的网络资源。
形象解释：
1，客户发一个暧昧的消息，给服务员
2，服务员收到，看了消息，很高兴，马上回信(此时客户还不知道服务收到)
3，客户特别高兴收到服务员关系确认的消息，(但是服务员还不知道客户收到了，如果没收到得重发，理论上来说，直到海枯石烂=-=)
4，服务员终于收到了客户关系确认的消息，悬着的心终于放下了5，于是客户跟服务员真正建立了 一条可靠的通道，毕竟两人都知道那是行得通的。。。
所以至少得三次才能确认关系
不用三次的话，server不能确定client是否收到自己的消息
如果没有收到，可能client根本没收到，或者client响应了，但server没收到
如果你用过对讲机你就会明白：
C ->S: 你能听到吗？
S->C: 听到。你能听到我吗？
C->S:听到。
问题五：理解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状态，完成三次握手。
通过这样的三次握手，客户端与服务端建立起可靠的双工的连接，开始传送数据。
三次握手的最主要目的是保证连接是双工的，可靠更多的是通过重传机制来保证的。
结果乙带着耳机听歌呢，根本没听到，没反应。甲心里想：跟你说话也没个音，不跟你说了，沟通失败。说明乙接受不到甲传过来的信息的情况下沟通肯定是失败的。
如果乙听到了甲说的话，那么第一次对话成功，接下来进行第二次对话。第二次对话：
如果乙听到了甲的话，做出了正确的应答，并且还进行了反问：我吃饭了，你呢？那么第二次握手成功。
通过前两次对话证明了乙能够听懂甲说的话，并且能做出正确的应答。
接下来进行第三次对话。第三次对话：
如果甲也做出了正确的应答：我也吃了。那么第三次对话成功，两人已经建立起了顺畅的沟通渠道，接下来开始持续的聊天。
通过第二次和第三次的对话证明了甲能够听懂乙说的话，并且能做出正确的应答。
为了保证服务端能收接受到客户端的信息并能做出正确的应答而进行前两次(第一次和第二次)握手，
为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次(第二次和第三次)握手。
------------------------------------------------------------第一次：甲 C 乙，乙反应
第二次：乙反应正确，乙 C 甲，第三次：甲正确反应，成功------------------------------------------------------------
问题六：为什么TCP连接需要三次握手分开需要四次握手 参考下面的图，可以理解一下。不过因为被动断开方可以把FIN和ACK用一个包发送，所以多数教材或资料上也是把断开理解为三次握手。
1、当主机A确认发送完数据且知道B已经接受完了，想要关闭发送数据口（当然确认信号还是可以发），就会发FIN给主机B。
2、主机B收到A发送的FIN，表示收到了，就会发送ACK回复。
3、但这是B可能还在发送数据，没有想要关闭数据口的意思，所以FIN与ACK不是同时发送的，而是等到B数据发送完了，才会发送FIN给主机A。
4、A收到B发来的FIN，知道B的数据也发送完了，回复ACK， A等待2MSL以后，没有收到B传来的任何消息，知道B已经收到自己的ACK了，A就关闭链接，B也关闭链接了。
问题七：简述TCP三次握手过程，并说明为什么要3次握手 A、B使用TCP作为传输层传输方式传递数据，流程大致概括如下：
A向B打一个招呼，说：你好，我想跟你建立一个tcp的连接，可以吗？B接收到A的招呼，如果愿意建立连接，会说：你好，可以的。A给B发的连接就建立成功了。
B在向A回答的时候，也会同时向A提出建立连接的申请（因为TCP是全双工的，双向的）：
B会向A说：你好，我也想跟你建立一个TCP的连接，可以吗？
A除了之前接收到B给自己的确认，还会接收到B发过来的申请，A收到这个申请后，会向B发出一个确认。
这时，B与A的连接也建立成功了。
这个过程叫做“TCP三次握手”，当双方都确认建立这个连接之后，就开始传递数据了。。这是一种可靠的传输方式。
问题八：TCP连接建立过程中为什么需要“三次握手” 第一次握手做什么？
请求端(客户端)会向服务端(被请求端)发送一个tcp报文，申请打开某一个端口。因为没有数据，所以这个报文仅包含一个tcp头。其中：
SYN=1；当建立一个新的连接时， SYN标志变1。
序号；序号用来标识从客户端向服务端发送的数据字节流。
此时客户端进入SYN_SENT状态。
第二次握手做什么？
服务端收到客户端的SYN包，也会发一个只包含tcp头的报文给客户端。
ACK=1；服务端确认收到信息
确认序号；客户端序号+1，作为应答
SYN=1；因为tcp的连接是双向的，服务端作为应答的同时请求建立连接。
此时服务端进入SYN_RECV状态
第三次握手做什么？
ACK=1；客户端确认收到信息
确认序号；服务端序号+1，作为应答
此时客户端进入ESTABLISHED状态，服务端收到ACK后也会进入此状态
可见，客户端和服务端都保留了对方的序号，这三次握手缺少任何一步都无法实现这一目标。在三次握手过程中，出现了一些中间状态。
问题九：为什么建立连接协议是三次握手，而关闭连接却是四次握手 为了安全保护。
TCP(Tran *** ission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议(UDP)是同一层内另一个重要的传输协议。在因特网协议族(Internet protocol suite)中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
问题十：TCP为何采用三次握手来建立连接，若采用二次握手可以吗？ 三次握手是为了防止已失效的连接请求再次传送到服务器端。 二次握手不可行，因为：如果由于网络不稳定，虽然客户端以前发送的连接请求以到达服务方，但服务方的同意连接的应答未能到达客户端。则客户方要重新发送连接请求，若采用二次握手，服务方收到重传的请求连接后，会以为是新的请求，就会发送同意连接报文，并新开进程提供服务，这样会造成服务方资源的无谓浪费。
采纳哦
三次握手,为什么么是三次,如果没有第三次会怎么样?
TCP协议中的三次握手是建立可靠连接的必要步骤。其中，第一次握手是客户端向服务器发送SYN请求报文，表示客户端想要建立连接；第二次握手是服务器收到SYN请求报文后，向客户端发送ACK确认报文，并同时发回自己的SYN请求报文，表示同意连接；第三次握手是客户端再次发送ACK确认报文，表示已经收到了服务器的SYN确认请求。如果没有第三次握手，那么服务器无法知道客户端是否成功接收到了服务器发回的SYN请求报文，从而可能出现一些意外情况，如重复发送SYN请求、连接超时等。这会导致连接建立失败，从而影响数据传输的可靠性和效率。因此，TCP协议中必须进行三次握手来确保双方都能够确认对方的请求，并成功建立连接。【摘要】
三次握手,为什么么是三次,如果没有第三次会怎么样?【提问】
TCP协议中的三次握手是建立可靠连接的必要步骤。其中，第一次握手是客户端向服务器发送SYN请求报文，表示客户端想要建立连接；第二次握手是服务器收到SYN请求报文后，向客户端发送ACK确认报文，并同时发回自己的SYN请求报文，表示同意连接；第三次握手是客户端再次发送ACK确认报文，表示已经收到了服务器的SYN确认请求。如果没有第三次握手，那么服务器无法知道客户端是否成功接收到了服务器发回的SYN请求报文，从而可能出现一些意外情况，如重复发送SYN请求、连接超时等。这会导致连接建立失败，从而影响数据传输的可靠性和效率。因此，TCP协议中必须进行三次握手来确保双方都能够确认对方的请求，并成功建立连接。【回答】
http的状态有哪些，怎么处理。【提问】
HTTP状态码分为五类，分别是：1xx：信息类。表示请求已经被接收，需要继续处理。2xx：成功类。表示请求已经被成功接收、理解、并接受。3xx：重定向类。表示客户端需要采取进一步的措施才能完成请求。4xx：客户端错误类。表示客户端提交的请求有错误。5xx：服务器错误类。表示服务器在处理请求时出现错误。针对不同的状态码，通常的处理方式如下：1xx：由于这些状态码只是信息类，所以大多数情况下不需要特殊处理。2xx：表示成功，可以根据具体的业务需求进行处理。3xx：通常需要将请求重定向到新的地址，或者提供更好的指引，让客户端进行下一步操作。4xx：通常需要告知客户端请求存在问题，并提供合理的提示或错误信息。5xx：通常需要通知客户端当前请求无法得到响应，并提供合理的提示或错误信息。同时需要及时修复服务器端的问题，确保服务可用性和稳定性。【回答】
http的状态码有哪些，怎么处理。【提问】
HTTP状态码是服务器向客户端返回的三位数代码，用于表示请求的处理结果。常见的HTTP状态码有以下几种：1xx：信息性状态码，表示服务器已经接收到了客户端的请求，正在处理中。2xx：成功状态码，表示服务器已经成功处理了请求。3xx：重定向状态码，表示需要客户端进一步的操作才能完成请求。4xx：客户端错误状态码，表示客户端发送的请求有问题或者无法被服务器所理解。5xx：服务器错误状态码，表示服务器在处理请求时发生了错误。当客户端向服务器发送请求时，服务器会返回一个相应的状态码。根据不同的状态码，我们可以采取不同的处理方式：1xx：这些状态码通常是指服务器正在处理请求，客户端不需要处理。2xx：这些状态码表示请求已经成功处理，客户端可以继续使用相关资源。3xx：这些状态码表示客户端需要执行一些额外的操作，比如跳转或者重新请求等。4xx：这些状态码表示客户端发送的请求出现了错误，可能是由于客户端的请求参数错误、权限不足等原因导致的。此时，客户端需要检查请求中的参数是否正确，并采取相应的措施修复问题。5xx：这些状态码表示服务器在处理请求时发生了错误，可能是【回答】
网络--三次握手
由高到低 应用层是体系结构中的最高层，直接为用户的应用进程（正在运行的程序）提供服务 。在因特网中的应用层协议很多，如支持万维网应用的 HTTP协议 ，支持文件传输的 FTP协议 ，支持电子邮件的 SMTP协议 等等。 运输层的任务是负责向 两个主机中进程之间的通信提供服务 。由于一个主机可同时运行多个进程，因此运输层有 复用 和 分用 的功能。 复用就是多个应用层进程可以同时使用下面运输层的服务，分用则是运输层把收到的信息分别交付给上面应用层中的相应的进程 。 运输层主要使用两种协议： 网络层负责为分组交换网上的不同 主机 提供通信服务。在发送数据的时候，网络层把运输层产生的报文段或者用户数据报封装成 分组 或 包 进行传送。在 TCP/IP 体系中，由于网络层使用 IP 协议，因此分组也叫 IP数据报 ，或简称 数据报 。 无论在哪一层传送的数据单元，习惯上都可以笼统地用“分组”来表示 因特网是一个很大的互联网，它由大量的 异构 网络通过 路由器 （router）相连接。因特网主要的网络层协议是无连接的 网际协议IP 和许多种路由选择协议，所以因特网的网络层也叫 网际层 或者 IP层 。 简称 链路层 。两个主机之间的数据传输总是在一段一段的链路上传送的，也就是说，在两个相邻结点之间（主机和路由器之间或者两个路由器之间）传送数据是直接传送的（点对点）。这时就需要使用专门的链路层的协议。 在两个相邻结点之间传送数据时，数据链路层把网络层交下来的 IP数据报 组装成 帧 （frame），在两个相邻结点间的链路上“ 透明 ”的传送 帧 中的数据。每一帧包括 数据 和必要的 控制信息 （如同步信息、地址信息、差错控制等）。典型的帧长是几百字节到一千多字节。 透明：某一个实际存在的事物看起来却好像不存在一样 。 在接收数据时， 控制信息 使接收端能够知道一个帧从哪个比特开始和到哪个比特结束，还使接收端能够检测到所收到的帧中有无差错，如发现错误，数据链路层就简单地 丢弃 这个出了差错的帧，以免继续浪费网络资源。如需改错，则交给 运输层的TCP协议 完成。 在物理层上传输数据的单位是 比特 。物理层的任务就是 透明地传送比特流 。 在因特网所使用的各种协议中，最重要的和最著名的就是 TCP 和 IP 两个协议。现在人们经常提起的 TCP/IP 并不一定是单指 TCP 和 IP 这两个具体的协议，而是表示因特网所使用的整个 TCP/IP协议族 （Protocol suite） TCP 运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段： 连接建立、数据传送和连接释放 。运输连接的管理就是使运输连接的建立和释放都能正常地进行。 在 TCP 建立连接的过程中要解决三个问题： TCP 连接的建立采用 客户服务器方式 。主动发起连接建立的应用进程叫做 客户 （Client），被动等待连接建立的应用程序叫做 服务器 （Server）。 假设 主机A 运行的是 TCP客户程序 ， 主机B 运行 TCP服务器程序 。最初两端的TCP进程都处在 CLOSED （关闭）状态。 A主动打开连接，而B被动打开连接。 B 的 TCP服务器 进程先创建 传输控制块TCB ，准备接受客户进程的连接请求。然后服务器就处于 LISTEN（收听）状态 ，等待客户的连接请求，如有，即作出反应。 A 的 TCP客户 进程也是首先创建 传输控制模块TCB ，然后向 B 发出 连接请求报文段 ， ——> 首部中的同步位 SYN = 1 ，同时选择一个初始序号 seq = x ， ——> TCP客户进入 SYN-SENT （同步以发送）状态。 注 ：TCP规定， SYN 报文段（即SYN = 1的报文段）不能携带数据，但要 消耗掉一个序号。 B 收到连接请求报文段后，如同意建立连接，则向 A 发送 确认 。 ——> 在确认报文段中把 SYN 位和 ACK 位都 置1 ，确认号是 ack = x+1 ，同时也为自己选择一个初始序号 seq = y 。（ 注 ：该确认报文段也不能携带数据，但同样要 消耗掉一个序号 。） ——> 这时， TCP服务器进程 进入 SYN-RCVD （同步收到）状态。 TCP客户 进程收到 B 的确认后，还要向 B 给出确认。 ——> 确认报文段的 ACK置1 ，确认号 ack = y+1 ，而自己的序号 seq = x + 1 ( 注 ：TCP规定， ACK报文段 可以携带数据，但 如果不携带数据则不消耗序号 ，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。) ——> 这时， TCP连接 已经建立， A 进入 ESTABLISHED （已建立连接）状态。 当 B 收到 A 的确认后也进入 ESTABLISHED 状态。 主要是为了防止已失效的连接请求报文段突然又传送到了 服务器主机B 假定 A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求，后来收到了确认，建立了连接，数据传输完毕后就释放了连接。这个过程中， A 共发送了两个请求报文段，其中第一个丢失，第二个到达了 B 。 于是就 可能有“已失效的连接请求报文段产生” ：假定一种异常的情况，即 A 发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间的滞留了，以致延误到第二个请求报文段连接释放以后的某个时间才到达 B 。本来这是一个已失效的报文段。但 B 收到此失效的连接请求报文段后，就误以为 A 又一次发出了一次新的连接请求，于是就向 A 发送 确认报文段 ，同意建立连接请求。假如不采用三次握手，那么只要 B 发出确认，新的连接就建立了。 由于现在 A 并没有发出建立连接的请求，所以不会理睬 B 的确认，也不会向 B 发送数据，但是 B 却以为新的运输连接已经建立了，并一直等待 A 发来数据。于是， B 的许多资源就这样被白白浪费了。 采用三次握手，A 不会向 B 的确认发出确认，B由于收不到确认，就知道A并没有要求要建立连接。