三次握手图片(三次握手过程)

个人感觉是7，第三次握手就发送了握手完成的标号
呃呃

答:如下图所示。客户端主动发出请求，并令其SYN=1， 并设置S1Q序号值等于X;服务器端接收到请求之后进行响应，发送SYN=1，ACK=1，表示同意建立连接，开始分配服务器资源。同时服务器端发送序号seq=y，服务器期待收到的数据序号ack=x+1;客户端收到服务器的期待以后，并发送序号seq=x+1对应的数据，同时ack=y+1表示期待收到序号为y+1对应的数据;

两将军问题：红蓝两军作战，蓝军战斗力强大，红1军或红2军与其单独作战都打不过蓝军，所以需要红一军与红二军联合对蓝军发起进攻，红军1首先通知红军2明早10点发起总攻，如图1-1，红军2接到消息需要回复“好的红军1，我已经收到你得消息，确认明早10点发动总攻”。因为消息传递路线必须经过蓝军营地，所以双方传递消息的信使很有可能被蓝军俘获。为了确保消息的可靠性，红1、红2双方在发出一个消息之后都想得到对方的消息回执。但是这会导致消息无线循环下去，如图1-2。那么如何解决这个可靠性的问题呢，其实没有办法解决，只要保证双方各自都有一次成功的发送、回执就可以了。两将军问题也存在网络世界里，客户端、服务器建立连接不可能无限的确认下去，只要保证客户端和服务器分别对自己的收、发能力做一次确认即可，如下图。 客户端和服务器分别对自己的收、发能力做一次确认至少需要3次握手。3次握手的具体过程、状态如下：（1）首先客户端和服务器都处于CLOSED状态。（2）服务器处于LISTEN状态，具体为服务器调用Socket、bind、listen函数，进入阻塞状态。（3）客户端发送SYN（同步序列编号），发送完毕客户端进入SYN_SENT状态。（4）服务端收到SYN，发送SYN+ASK，发送完毕进入SYN_RCVD状态。（5）客户端收到服务端发来的SYN+ASK，发送服务端等待的ASK，发送完毕客户端进入ESTABLISHED状态，准备数据传输,到此客户端已经满足了对自己收发能力的一次验证。（6）服务端收到客户端发来的ASK，与客户端一样，到此服务端也已经满足了对自己收发能力的一次验证，所以也进入ESTABLISHED状态，准备数据传输。（7）准备开始传输数据TCP断开连接有两种情况或者说是场景，1 客户端先断开连接，当然也可能是服务器先断开连接，总之是一前一后。 2 双方同时发起断开连接操作。下面分别介绍两种场景：（1）客户端先发起断开连接操作，客户端向服务端发送FIN，发送完毕客户端进入FIN_WAIT_1状态。（2）服务端收到客户端发来的FIN，服务端发送ACK，发送完毕进入CLOSED_WAIT状态。（3）客户端收到服务端的ACK回复，客户端进入FIN_WAIT_2状态，如果后面服务端没有回应客户端，在TCP协议层面来讲，客户端将永远停留在这个状态了，不过还好，操作系统着这块做了处理，有一个超时时间。（4）此时TCP连接进入半关闭状态，即客户端主，服务端从的这条线路已经关闭，不过服务端主，客户端从的这条线路还处于打开状态。（5）服务端向客户端发送FIN，发送完毕，服务端进入LAST_ASK状态。（6）客户端收到服务端的FIN后回复服务端ACK，回复完毕进入TIME_WAIT状态，为什么要进入这个状态？因为第6步是客户端的最后一条回复，服务端很有可能收不到，收不到服务端就会重发，所以客户端还要等待一会。（7）服务端收到客户端的ACK回复之后，不再做响应，回到初始的CLOSED状态，在连接池中等待下一次的复用。（8）客户端保持TIME_WAIT状态，超时之后同样进入CLOSED状态。场景二（1）客户端、服务器双方同时发送FIN，双方同时进入FIN_WAIT_1状态（2）双方都接到了对方的ACK，此时双方都会进入CLOSING状态。（3）双方同时进入TIME_WAIT状态，为什么要进入这个状态而不是直接进入CLOSED状态呢？假设客户端和服务端本次是第X次建立连接、关闭连接。如果立即关闭，随后建立第X+1次连接，建立连接成功之后，第X次的丢包的数据有可能绕了一大圈又回来了，那就会出现数据错误，为了避免这种情况所以要进入TIME_WAIT状态，以保证旧连接的数据不会再回来。（4）TIME_WAIT超时之后，双双进入CLOSED状态。有了上面对TCP连接3次握手4次挥手的介绍，再来理解TCP的状态图就不困难了，无非就是对TCP连接3次握手4次挥手过程的打包概述而已。

不要抖机灵，三次握手即是在最快最省力的情况下做出的选择比如在红军时代，A连和B连分在左右翼，约定在几时几分一同发起打击。这个几时几分的信息就需要人工通过通讯员来走路传递。所以A连指挥官派出通讯员。这是第一次。假设通讯员到达了B连，并且告知了B连指挥官几时几分，B连指挥官一定会让通讯员再回去通知A连指挥官，可怜的通讯员只能冒着危险返回A连，因为A连指挥官看不到通讯员返回的话，不知道几时几分这个信息到底传达到了B连没有。这是第二次。现在B连指挥官开始担心通讯员是否回到了A连，如果没回到，B连指挥官会设身处地的想一想A连指挥官见不到返回的通讯员，肯定是不敢打的，所以B连指挥官最盼望的是再次看到通讯员出现在B连，所以A连指挥官会让通讯员再回B连一次。这是第三次。这就是三次握手
简化三次握手流程 从图片可以得到三次握手可以简化为：C发起请求连接S确认，也发起连接C确认我们再看看每次握手的作用：第一次握手：S只可以确认自己可以接受C发送的报文段第二次握手：C可以确认 S收到了自己发送的报文段，并且可以确认自己可以接受S发送的报文段第三次握手：S可以确认 C收到了自己发送的报文段总结：三次握手，对于每一方来说，可以确认两个信息：1.确认 自己可以接受对方发来的报文段2.确认 对方收到了自己的报文一旦这两个得到确认，连接就建立起来了，后面才开始传送数据关于为什么要三次握手，大家从握手过程也可以看得出。不过书上是这样的解释：谢希仁的《计算机网络》说：防止已失效的连接请求报文段突然又传给server “已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。（此时因为client没有发起建立连接请求，所以client处于CLOSED状态，接受到任何包都会丢弃，谢希仁举的例子就是这种场景）但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。

三次握手： 1. 主动发起连接请求端（客户端），发送 SYN 标志位，携带数据包、包号2. 被动接收连接请求端（服务器），接收 SYN，回复 ACK，携带应答序列号。同时，发送SYN标志位，携带数据包、包号3. 主动发起连接请求端（客户端），接收SYN 标志位，回复 ACK。被动端（服务器）接收 ACK —— 标志着 三次握手建立完成（ Accept()/Dial() 返回 ）四次挥手：1. 主动请求断开连接端（客户端）， 发送 FIN标志，携带数据包2. 被动接受断开连接端（服务器）， 发送 ACK标志，携带应答序列号。 —— 半关闭完成。3. 被动接受断开连接端（服务器）， 发送 FIN标志，携带数据包4. 主动请求断开连接端（客户端）， 发送 最后一个 ACK标志，携带应答序列号。—— 发送完成，客户端不会直接退出，等 2MSL时长。等 2MSL待目的：确保服务器 收到最后一个ACK滑动窗口：通知对端本地存储数据的 缓冲区容量。—— write 函数在对端 缓冲区满时，有可能阻塞。TCP状态转换：1. 主动发起连接请求端：CLOSED ——> 发送SYN ——> SYN_SENT(了解) ——> 接收ACK、SYN，回发 ACK ——> ESTABLISHED (数据通信)2. 主动关闭连接请求端：ESTABLISHED ——> 发送FIN ——> FIN_WAIT_1 ——> 接收ACK ——> FIN_WAIT_2 (半关闭、主动端)——> 接收FIN、回复ACK ——> TIME_WAIT (主动端) ——> 等 2MSL 时长 ——> CLOSED3. 被动建立连接请求端：CLOSED ——> LISTEN ——> 接收SYN、发送ACK、SYN ——> SYN_RCVD ——> 接收 ACK ——> ESTABLISHED (数据通信)4. 被动断开连接请求端：ESTABLISHED ——> 接收 FIN、发送 ACK ——> CLOSE_WAIT ——> 发送 FIN ——> LAST_ACK ——> 接收ACK ——> CLOSEDwindows下查看TCP状态转换：netstat -an | findstr  端口号Linux下查看TCP状态转换：netstat -an | grep  端口号TCP和UDP对比:TCP: 面向连接的可靠的数据包传递。 针对不稳定的 网络层，完全弥补。ACKUDP：无连接不可靠的报文传输。 针对不稳定的 网络层，完全不弥补。还原网络真实状态。优点                                                            缺点TCP：可靠、顺序、稳定                                     系统资源消耗大，程序实现繁复、速度慢UDP：系统资源消耗小，程序实现简单、速度快                          不可靠、无序、不稳定使用场景：TCP：大文件、可靠数据传输。 对数据的 稳定性、准确性、一致性要求较高的场合。UDP：应用于对数据时效性要求较高的场合。 网络直播、电话会议、视频直播、网络游戏。UDP-CS-Server实现流程：1.  创建 udp地址结构 ResolveUDPAddr(“协议”， “IP：port”) ——> udpAddr 本质 struct{IP、port}2.  创建用于 数据通信的 socket ListenUDP(“协议”, udpAddr ) ——> udpConn (socket)3.  从客户端读取数据，获取对端的地址 udpConn.ReadFromUDP() ——> 返回：n，clientAddr， err4.  发送数据包给 客户端 udpConn.WriteToUDP("数据"， clientAddr)UDP-CS-Client实现流程：1.  创建用于通信的 socket。 net.Dial("udp", "服务器IP：port") ——> udpConn (socket)2.  以后流程参见 TCP客户端实现源码。UDPserver默认就支持并发！------------------------------------命令行参数： 在main函数启动时，向整个程序传参。 【重点】语法： go run xxx.go   argv1 argv2  argv3  argv4 。。。xxx.exe:  第 0 个参数。argv1 ：第 1 个参数。argv2 ：第 2 个参数。argv3 ：第 3 个参数。argv4 ：第 4 个参数。使用： list := os.Args  提取所有命令行参数。获取文件属性函数：os.stat(文件访问绝对路径) ——> fileInfo 接口fileInfo 包含 两个接口。Name() 获取文件名。 不带访问路径Size() 获取文件大小。网络文件传输 —— 发送端（客户端）1.  获取命令行参数，得到文件名（带路径）filePathlist := os.Args2.  使用 os.stat() 获取 文件名（不带路径）fileName3.  创建 用于数据传输的 socket  net.Dial("tcp"， “服务器IP+port”) —— conn4.  发送文件名(不带路径)  给接收端， conn.write()5.  读取 接收端回发“ok”，判断无误。封装函数 sendFile(filePath, conn) 发送文件内容6.  实现 sendFile(filePath,  conn)1) 只读打开文件 os.Open(filePath)for {2) 从文件中读数据  f.Read(buf)3) 将读到的数据写到socket中  conn.write(buf[:n])4）判断读取文件的 结尾。 io.EOF. 跳出循环}网络文件传输 —— 接收端（服务器）1. 创建用于监听的 socket net.Listen() —— listener2. 借助listener 创建用于 通信的 socket listener.Accpet()  —— conn3. 读取 conn.read() 发送端的 文件名， 保存至本地。4. 回发 “ok”应答 发送端。5. 封装函数，接收文件内容 recvFile(文件路径)1) f = os.Create(带有路径的文件名)for {2）从 socket中读取发送端发送的 文件内容 。 conn.read(buf)3)  将读到的数据 保存至本地文件 f.Write(buf[:n])4)  判断 读取conn 结束， 代表文件传输完成。 n == 0  break}