- 什么是三次握手、四次挥手
- TCP在传输之前会进行三次沟通，一般称为“三次握手”，
- 传完数据断开的时候要进行四次沟通，一般称为“四次挥手”。
- TCP的特点有：
- 1、TCP是面向连接的运输层协议。应用程序在使用 TCP 协议之前，必须先建立 TCP 连接。在传送数据完毕后，必须释放已经建立的 TCP 连接。
- 2、每一条TCP连接只能有两个端点，每一条 TCP 连接只能是点对点的(一对一)。
- 3、TCP提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。
- 4、TCP提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接受缓存，用
- 5、面向字节流。TCP中的“流”指的是流入到进程或从进程流出的字节序列。
- TCP三次握手
- 第一次握手
- 客户机——>服务器发送SYN seq=200 随机序列号 ack=0 表示初次连接，表示当前没有接收数据
- SYN=1 ACK=0 表示连接请求报文
- 第二次握手
- 客户机——>服务器 发送服务器自己的随机序列号 ack=201（客户机——>服务器seq+1） seq =300 (随机序列号)
- 第三次握手
- 客户机——>服务器 seq=201(客户机——>服务器发送的随机序列号+1) ack=301（第二次握手服务器发送给客户机的随机序列号+1）
- TCP三次握手
- 小写的ack代表的是头部的确认号Acknowledge number， 缩写ack，是对上一个包的序号进行确认的号，ack=seq+1。
- 大写的ACK，用于标志的TCP包是否对上一个包进行了确认操作，如果确认了，则把ACK标志位设置成1
- 第一次挥手
- 客户机——>服务器 发送FIN （ FIN=M），用来关闭客户机到服务器的数据传送，客户机进入FIN_WAIT_1状态
- 第二次挥手
- 服务器——>客户机 服务器收到FIN后，发送一个ACk给客户机，确认序号为收到FIN值加1（ack=M+1）表示对客户机发送的数据进行确认。因为此时服务器可能还有数据需要发送，所以还需要进入第三次挥手
- 第三次挥手
- 服务器——>客户机 服务器在全部数发送完成后，发送一个FIN（FIN=N），用来关闭服务器到客户机的数据传送，服务器进入LAST_ACK状态。
- 再次发送一个fin，ack包，和ack包的序号、确认号是一样的,表示我也要释放连接
- 第四次挥手
- 客户机——>服务器 客户机在收到FIN后，客户机进入TIME_WAIT状态，接着发送一个ACK给服务器，确认序号为收到序号+1，服务器进入CLOSED状态，完成四次挥手
- 概念性的知识点
- 报文解析
- 1. 序号<seq>：
- 2. 确认序号<ack>：
- 32bit的确认号，是接收数据方期望收到发送方的下一个报文段的序号，因此确认序号应当是上次已成功收到数据字节序号加1
- 3. 紧急URG：当URG=1时，表示报文段中有紧急数据，应尽快传送。
- 4. 确认比特ACK：
- ACK = 1时代表这是一个确认的TCP包，取值0则不是确认包。
- 5. 推送比特PSH：当发送端PSH=1时，接收端尽快的交付给应用进程。
- 6. 复位比特（RST）：当RST=1时，表明TCP连接中出现严重差错，必须释放连接，再重新建立连接。
- 7. 同步比特SYN：
- 在建立连接是用来同步序号。SYN=1， ACK=0表示一个连接请求报文段。SYN=1，ACK=1表示同意建立连接。
- 8. 终止比特FIN：
- FIN=1时，表明此报文段的发送端的数据已经发送完毕，并要求释放传输连接。
- 扩展
- 1.为什么需要三次握手？为什么不能用两次握手进行连接？
- 假定C给S发送一个连接请求，S收到了这个请求，并发送了确认应答请求。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据。可是，C在S的应答在传输中被丢失的情况下（第二次握手丢失），将不知道S是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
- 2.如果已经建立了连接，但是客户端突然出现故障了怎么办？
- TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
- 3.关闭的时候却是四次握手？
- 关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。所以需要四步握手