通信三次握手(tcpip三次握手的通信过程是)

用于解决网络中出现重复请求报文的问题。第一次：首先A发送一个(SYN)到B，意思是A要和B建立连接进行通信，如果是只有一次握手，这样肯定是不行的，A压根都不知道B是不是收到了这个请求。第二次：B收到A要建立连接的请求之后，发送一个确认(SYN+ACK)给A，意思是收到A的消息了，B这里也是通的，表示可以建立连接。如果只有两次通信，这时候B不确定A是否收到了确认消息，有可能这个确认消息由于某些原因丢了。第三次：A如果收到了B的确认消息之后，再发出一个确认(ACK)消息，意思是告诉B，这边是通的，然后A和B就可以建立连接相互通信了。扩展资料：注意事项：刚接触网络编程时，感觉网络连接的建立、网络数据的收发、网络连接的断开这些操作仅仅是调用几个socket AIP就可以搞定的事情，跟网络中讲述的TCP三次握手等内容完全扯不上关系。listen函数：内核为任何一个给定的套接字维护两个队列 1.未完成连接状态（客户端发送的第一个SYN已经到服务器，服务器等待TCP三次握手完成，这些套接字处于SYN_RCVD状态）。参考资料来源：百度百科-三次握手
用于解决网络中出现重复请求报文
是用于解决网络服务的不可靠性。 个人认为关键在于：第一次握手保证连通性第二次握手保证数据传输 第三次握手保证传输结果双方一致

. 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在发出的分组超时后，重复发送同样的分组。这样就形成了死锁

#三次握手 客户端向服务器端发送SYN包，客户端进入SYN_SEND状态服务器端收到客户端发送的包返回ACK+SYN包，服务器端进入SYN_RECV状态客户端收到服务器端返回的包再发回ACK包，客户端进入ESTABLISHED状态，服务器端收到包也进入ESTABLISHED状态客户端状态：SYN_SENDESTABLISHED服务器端状态：SYN_RCVEESTABLISHED#四次挥手客户端发送FIN包询问服务器端是否能断开，客户端进入FIN_WAIT_1状态服务器端收到客户端发送的包并返回ACK包，服务器端进入CLOSE_WAIT状态服务器端准备好断开后，发送FIN包给客户端，服务器端进入LAST_ACK状态客户端收到服务器端发送的包后返回ACK包，客户端进入TIME_WAIT状态，服务器端收到包后进入CLOSED状态客户端状态：FIN_WAIT_1FIN_WAIT_2TIME_WAIT服务器端状态：CLOSE_WAITLAST_ACKCLOSED 如果有什么不懂的话可以去看看《Linux就该这么学》这本书，非常适合新手学习Linux。
三次握手： 第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。四次挥手与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

为什么要三次握手 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。 第四次握手：任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
只知道三次握手，A向B发送信息，B会向A返回一个收到确认的消息，A还会对这个确认消息发送一次再确认，所以一个消息要经过三次的消息交互才算发送完成，这就是三次握手

TCP/IP是很多的不同的协议组成，实际上是一个协议组，TCP用户数据报表协议(也称作TCP传输控制协议，Transport Control Protocol。可靠的主机到主机层协议。这里要先强调一下，传输控制协议是OSI网络的第四层的叫法，TCP传输控制协议是TCP/IP传输的6个基本协议的一种。两个TCP意思非相同。 )。TCP是一种可靠的面向连接的传送服务。它在传送数据时是分段进行的，主机交换数据必须建立一个会话。它用比特流通信，即数据被作为无结构的字节流。 通过每个TCP传输的字段指定顺序号，以获得可靠性。是在OSI参考模型中的第四层，TCP是使用IP的网间互联功能而提供可靠的数据传输，IP不停的把报文放到 网络上，而TCP是负责确信报文到达。在协同IP的操作中TCP负责：握手过程、报文管理、流量控制、错误检测和处理（控制），可以根据一定的编号顺序对非正常顺序的报文给予从新排列顺序。关于TCP的RFC文档有RFC793、RFC791、RFC1700。 在TCP会话初期，有所谓的“三握手”：对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步，根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系，并建立虚连接。为了提供可靠的传送，TCP在发送新的数据之前，以特定的顺序将数据包的序号，并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。由于TCP需要时刻跟踪，这需要额外开销，使得TCP的格式有些显得复杂

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包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。Backlog参数：表示未连接队列的最大容纳数目。SYN-ACK 重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。 半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。